Using Asset Tracker is just a mess

Troubleshooting
1

Hello,

just venting here. I have been using the asset tracker for a couple of days now, and honestly, it's a mess to understand how to use it.

First you go the "logical" route, aka add the "AssetTracker" library to your project. Impossible to get a GPS fix, even with an active GPS antenna connected and the call made to enable it (the red LED flashes though, but even leaving it in the garden for half an hour doesn't change a thing, with a charged LiPo connected). Then you start looking around and you realise that lots of info out there is either about the V1 or the V2, that the lib doesn't really specify what version it serves and that nearly no posts specify what version they talk about.

Next you find this:

In which the "official" suggestion is to not use the official particle hosted library, but a third party one, that's a completely different implementation and well, good luck figuring out how to use the accelerometer for instance.

Current state: still no GPS fix. Even worse, the gps LED doesn't even turn on after explicitly pulling D6 low.

    pinMode(D6, OUTPUT);
    digitalWrite(D6, LOW);

This should enable the GPS, no?

So you search a bit more, and then you find this:

Someone else with problems who simply wrote his own library to deal with the asset tracker V2.

I'm sorry but this is a complete mess. Is it not possible for each product to at least show how it is supposed to be used, and update that when a V2 is released? Right now I am looking at a Particle Electron on top of an Asset Tracker V2, with LiPo and USB (good luck debugging without serial connection) that simply all of the sudden stopped turning on and flashing the red LED. It's driving me crazy.

2

Sorry for such an experience. It does seem like Particle should deprecate the ā€œofficialā€ AssetTracker library. @rickkas7 (Particle Employee) has the best working library based on a different core (TinyGPS++):

8 Likes
3

I wrote my own library because I wanted to use some of the cool features of the GPS chip that is on the AssetTracker 2. I didnā€™t use TinyGPS++ because it uses the NMEA protocol and so doesnā€™t give access to the many features available.

NMEA is a generic GPS protocol that allows reading position but little else. Many useful features are only available when you use the protocol specific to the chip. Some of the features are: modes that are tuned for cars, pedestrians, jets, etc., setting movement sensitivity to ignore noise or small movements, speed and acceleration readings, sleep modes to limit power usage, and many more.
When I first tried using the AssetTracker 2 with the library for AssetTracker 1 it worked unless you tried to change any parameters. My library has some examples but if you decide to try my library you should read the comments in the header files and in the code to see how to add commands and queries. Those comments also include a link to the spec sheet for the GPS chip which describes the features and how to access them.
Lynd

1 Like
4

I just thought of a detail that may cause some people problems: The GPS wonā€™t work if you have the serial connection plugged into the AssetTracker 2; the connector blocks the satellite receiver. This makes it a pain to debug because you must keep disconnecting to your debugger connection to see actual GPS info.

5

I connected an active GPS antenna with a 3m cable :slight_smile: That should avoid that issue I hope.
I will continue working on it tomorrow, but the weird thing is that the red LED simply all of the sudden stopped working. I currently integrated ā€œAssetTracker2ā€ lib. Weā€™ll see if I have to switch to AssetTrackerRK.

BTW is it normal that all this stuff is so badly documented, not to say that documentation is non-existent? Where is the documentation that explains how to configure the accelerometer for instance, especially when using the AssetTrackerRK lib, that seems to have a completely different interface.

6

@Lynd, iā€™ve been trying your library, and I just deployed usage.ino. This is what I see on the serial output:

Serial monitor opened successfully:
$GNTXT,01,01,02,u-blox AG - www.u-blox.com*4E
$GNTXT,01,01,02,HW UBX-M8030 00080000*60
$GNTXT,01,01,02,ROM CORE 3.01 (107888)*2B
$GNTXT,01,01,02,FWVER=SPG 3.01*46
$GNTXT,01,01,02,PROTVER=18.00*11
$GNTXT,01,01,02,GPS;GLO;GAL;BDS*77
$GNTXT,01,01,02,SBAS;IMES;QZSS*49
$GNTXT,01,01,02,GNSS OTP=GPS;GLO*37
$GNTXT,01,01,02,LLC=FFFFFFFF-FFFFFFED-FFFFFFFF-FFFFFFFF-FFFFFF69*23
$GNTXT,01,01,02,ANTSUPERV=AC SD PDoS SR*3E
writeUBX: type: 608
B5,62,6,8,6,0,30,75,1,0,0,0,BA,21,
>24>47>4E>54>58>54>2C>30>31>2C>30>31>2C>30>32>2C>41>4E>54>53>54>41>54>55>53>3D>44parse: ACK_TYPE: message acked: 608
writeUBX: type: 601
B5,62,6,1,3,0,1,7,1,13,51,
parse: ACK_TYPE: message acked: 601
writeUBX: type: 624
B5,62,6,24,24,0,1,0,3,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,64,0,0,0,0,0,28,0,0,0,0,0,0,0,DE,6,
parse: ACK_TYPE: message acked: 624
writeUBX: type: 61E
B5,62,6,1E,14,0,0,0,0,0,3,1,0,0,0,0,0,0,2,A,0,0,10,10,0,0,68,FF,
parse: ACK_TYPE: message acked: 61E
writeUBX: type: 601
B5,62,6,1,3,0,1,9,1,15,55,
parse: ACK_TYPE: message acked: 601
GPS started

Yet the red light stays off and if I print the lat lon coordinates in the loop I get ā€œ0,0ā€.

Then I saw in another example that you added a timer object in wich you call ā€œupdateGPSā€, so I added that timer to the example code too. Didnā€™t change anything.

BTW am I correct in stating that if I pull D6 low the GPS should start getting a position and the red LED should flash, no matter what else is done in the code, or if this is through a library or not?

7

Well ā€¦ it seems the red light only starts flashing as soon as it has the slightest hint of a gps signal, and not when sitting on my desk blocked from any signal.

8

The debug info shows that the device is talking and functioning. You can look up those message types in the header file if you are interested what is being setup.
The device must be in full view of the sky and have the serial debug cable disconnected to get a GPS position fix.
It has been awhile since I worked on this and I donā€™t remember all the details like which pin does what or which LEDs mean what, but I could put the device in a south facing window and usually get a connection. How reliably it connects depends on where you are, what buildings are around causing echos, what trees are blocking the sky, etc.It takes quite a long time at first (a few minutes maybe?) but once it has connected it is quicker. The device allows reading how many satellites it sees and when I put it outside with full sky view it saw more satellites than when in the window. I think it reported 11 at my house.

9

What I have found (with GPS receivers in general) is that if I take one outside and let it get connected, itā€™s then more likely to connect indoors. I donā€™t know GPS very well but Iā€™ve always thought that is because it remembers the last location that it got a lock at, and thus doesnā€™t require as many satellites ā€œin viewā€ to re-establish a lock.

10

Just some background.
In order to calculate the position from the satellite data, the device needs to know where the individual satellites are supposed to be at any given time (at least for three of the satellites it can see).
That info is often refered to as the ā€œGPS almanacā€ which is sent in portions, low bandwith, embedded in the satellite data stream.
Hence a cold boot takes so long to get the initial fix since it first needs to collect enough info about the satellites themselves before it can make any sense of the actual location data (not much more than a precission timestamp to calculate the travel time of that data package at light speed) it receives off of them.

1 Like
11

I have it working now using the asset tracker 2 lib developed by @Lynd, and some of his example code.

Thanks

12

Are there implementations that periodically store the almanac data to non-volatile memory and use it and the current time on next cold boot to improve the precision of (reduce the error in) early position data? Since the time is in the data stream, the device wouldnā€™t need an RTC. Given the knowledge of where the satellites were last time and now, canā€™t you get a pretty good guess at where theyā€™ll be with some fairly quick number crunching at significant power savings compared to warm standby? Cold boot is so painfully slow.

Also, given that Particle devices are on the internet, can the almanac data be integrated from the Wi-Fi side channel for quicker fixes?

13

The almanac data is only valid for a limited periode, since satellites get in and out of view relatively quickly and IIRC you will only get the data of satellites that currently are visible to your device.

14

There is a discussion about how to avoid the boot delay in the documentation for the GPS receiver that used on the AssetTracker2: https://www.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_(UBX-13003221)_Public.pdf

The chip supports facilities to speed up the boot. Here is the introduction from that spec:

Users would ideally like GNSS receivers to provide accurate position information the moment they are turned
on. With standard GNSS receivers there can be a significant delay in providing the first position fix, principally
because the receiver needs to obtain data from several satellites and the satellites transmit that data slowly.
Under adverse signal conditions, data downloads from the satellites to the receiver can take minutes, hours or
even fail altogether.
Assisted GNSS (A-GNSS) is a common solution to this problem and involves some form of reference network of
receivers that collect data such as ephemeris, almanac, accurate time and satellite status and pass this onto to
the target receiver via any suitable communications link. Such assistance data enables the receiver to compute a
position within a few seconds, even under poor signal conditions.
The UBX-MGA message class provides the means for delivering assistance data to u-blox receivers and
customers can obtain it from the u-blox AssistNow Online or AssistNow Offline Services. Alternatively they can
obtain assistance data from third-party sources (e.g. SUPL/RRLP) and generate the appropriate UBX-MGA
messages to send this data to the receiver.

I tried to make the UbloxM8Q driver easy to modify to add support for other features supported by the receiver.

1 Like
15

ir_fuel,
I have a warning:
mccarr told me I messed up the documentation for parameter to gpsRate. You should provide the period rather than the rate. Here is the entire discussion:

From: mccarr notifications@github.com
Sent: Friday, May 11, 2018 2:19:46 AM
To: lyndw/AssetTracker2
Cc: lyndw; State change
Subject: Re: [lyndw/AssetTracker2] How to change update rate? (#1)

Hi Lynd,
A couple of comments:

The gpsRate function which is in the example (not t.gpsRate) actually must take a String as an input.
There is some mix up between rate and delay between measurements. The function gpsRate would suggest I give a rate input in Hz. E.g. 10 Hz. However I notice that this number is sent as the "Time between measurements" variables in the implementation in UBLOXM8Q_GPS library. So when I give 10 as an input to gpsRate, it's setting 10 ms delay between measurements which is actually 100 Hz. There should be some sort of conversion from rate -> measurement delay somewhere. The asset tracker cannot support 100Hz GPS frequency. I just tried putting gpsRate(100) and that worked!

incorrect frequency

message acked

So this is more a bit of confusing naming then something fundamentally wrong. However, good to let others know in the future that gpsRate() actually takes the delay between measurements as input, not the rate.

1 Like
16

Is there a way of understanding what the state is wrt getting a fix? As in how long it will still take? I find the behavior very erratic right now. Sometimes it goes quickly, sometimes it takes 15 minutes.

Is there a way of speeding this up thatā€™s explained somewhere for someone who isnā€™t a hard core hardware/embedded systems engineer? I am a software developer myself, with some notions of hardware, but extremely limited.

17

@ir_fuel, the Ublox NEO-M8 used in the asset tracker is a bit of a complex beast. You can use it by decoding the standard NMEA messages it produces or you can configure it to use Ubloxā€™s UBX messages instead.

One way to learn about how it works and what you can do with it is to download Ublox U-Centre (windows only I believe) application and run a simple Serial pass-through application on the Electron. That allows you to use U-Centre via the USB COM port to look into and control the NEO-M8. A cool feature of U-Centre is it shows all satellites being used by the NEO, lock status, lat-lon, a global map of the location and much more.

You can also apply for an AssistNow token to experiment with that feature as well. Using U-Centre also allows you to look at and adjust all available parameters. The trickiest thing for me was creating the correct NMEA or UBX configuration messages for my application. The documentation is helpful but you still need to calculate the correct CRC which can be a pain.

In one application, I disable NEMA messages and use two UBX messages (PUBX00 and PUBX04) to get position and time data (I use a customized version of TinyGPS). I also use AssistNow data, when possible, to reduce lock time significantly. In all other applications, I use TinyGPS++.

I have found that with or without an active antenna, a good view of the sky is important to get a lock. Since I develop in my basement workshop, I use a cheap GPS repeater to get the GPS signal into my workshop.

6 Likes
18

IIRC from my GPS days.

Time to first fix for a GPS RX ā€œcold bootā€ should be about 15 minutes. That includes signal lock to a single satellite for 12-ish minutes of almanac load (the same almanac is transmitted by all satellites) plus collection of ephemerides from the set of satellites being used in the position fix (specific per satellite). Think of the almanac as the course map of the constellation (good for months), with the ephemerides being the specific satellite corrections (good for hours).

With an almanac loaded, known time, and approximate location, subsequent RX boot will only require 60-ish seconds to position fix.

There are various ways to speed up cold boot such as Assisted-GPS with the almanac loaded via cellular etc, but I do not know if the Asset Tracker supports A-GPS.

2 Likes
19

Iā€™ve been using a slightly modified version of this library for more than a year now with a lot of success. Itā€™s written specifically for the asset tracker v2 GNSS unit, but Iā€™m using it for NEO-M8N module in my own variation of the asset tracker. Itā€™s very well written and uses UBX protocol. The module Iā€™m using has a passive ceramic antenna and very rarely gets a fix indoor, but outdoor, in the car, I usually get a fix within 30 to 60s in a cold start, and less than 3 sec in warm start (when a backup power is maintained for the GNSS module).

1 Like
20

Of course, you are right. I was conflating almanac and ephemeris here (or rather only mentioned the one and omitted the other out of lazyness :blush:).