Asset Tracker 2.0 - GPS Documentation

I just received the Asset Tracker 2.0 and I’ve been trying to get the GPS functioning to my expectations in the firmware code. I’ve been digging around for documentation and I can’t find anything beyond some of the code in this example:

I see this was updated recently to mention the U-Blox module. In the gpsOn() method, there are several commands that configure the antenna, update speed, etc.

However, when I try this logic in my code it doesn’t seem to make any difference (update speed never changes, external antenna is used even when I specify internal antenna, etc.). So I’m confused about whether this logic applies to the “old” Asset Tracker or the new one.

So, it would be great to have some documentation on interacting with the U-blox GPS module in the firmware.


Hello Mike,

We wanted to keep the current library forward compatible with the new ublox based asset tracker. The ublox module has some custom commands to choose external vs internal antenna. You should not see a change in update rate, but rather the number of satellite fixes and signal strength when choosing one (antenna) over the other.

I’ll add examples highlighting this behaviour. We are also working on an additional ublox specific library to support the new asset tracker.

I’d love additional feedback as you work with this new asset tracker.



Thanks for the quick reply! Specifically what I’m trying to figure out right now is how to get updates more frequently than 1 second. I tried the following:


But I still get updates once per second, when I believe the code above was supposed to make it update 5 times per second. Thoughts?

I’m greatly looking forward to the library/examples you mentioned above. If you have any insight into the update speed issue, that would help me keep moving forward for now.

Regarding the Asset Tracker itself, I’ve only focused on the GPS functionality so far to try and get my code working with the new version (I originally hooked it up on Asset Tracker v1). But I really like the new Grove connectors and I also like that it no longer needs the CR1220 battery (which would be a problem to replace out in the field).

My only major gripe with both the original and new Asset Tracker is actually with the enclosure. It’s waterproof, which is great, but the Asset Tracker can’t realistically be deployed with just the internal battery to power it. It needs external power through the USB port or screw-in terminals. So after I plug in the power cable, there is no way to close the box completely and it also loses its weatherproofing capabilities. I’m not sure what the intended solution is for that. Are we supposed to drill our own holes in the enclosure to route cables? Maybe so, but I just wanted to point that out as a problem everyone will experience. I’m open to any feedback on how to gracefully handle this with the current enclosure.


Hello @mike_b

The PMTK command set is specific for the MediaTek GPS module used in the previous asset tracker.

ublox uses its own set of commands to change/update its modes. For the time being, in order to unblock you, here are the commands you can use to change the update rates. We’ll add this in the new library.

uint8_t update1Hz[] =   {0xB5,0x62,0x06,0x08,0x06,0x00,0xE8,0x03,0x01,0x00,0x01,0x00,0x01,0x39};
uint8_t update5Hz[] =   {0xB5,0x62,0x06,0x08,0x06,0x00,0xC8,0x00,0x01,0x00,0x01,0x00,0xDE,0x6A};
uint8_t update10Hz[] =  {0xB5,0x62,0x06,0x08,0x06,0x00,0x64,0x00,0x01,0x00,0x01,0x00,0x7A,0x12};

Just send these out using

for(uint8_t i=0;i<14;i++)
        Serial1.write(update5Hz[i]); //send the command to gps module

I have not had a chance to test these commands. I should get it by tonight or tomorrow.

That’s a valid point. We would expect the user to drill hole when needed and use cable grommet to route the necessary cables out. It is very tricky to find a custom enclosure that comes with waterproof cable grommet without going into custom molds. I think we will consider it if there is enough demand. I have personally drilled holes in my enclosure to mount antenna connectors.

Hope this helps!

@mohit, could the command not also be sent using:

Serial1.write(update5HZ, sizeof(update5HZ));

Yeah, that works too. I think the loop allows one to add debugging lines in there if needed, but not required!

1 Like

Thanks @mohit and @peekay123 for the insight!

I tried this and unfortunately still don’t see a change in update speed:

Serial1.write(update5Hz, sizeof(update5Hz));

I’ll await @mohit’s findings on this configuration. I’m also curious about what documentation you’re reviewing to find out those commands.


1 Like


I was able to quickly test the commands with a Photon:

gps.begin(); //please use the default baud rate of 9600 for testing.
Serial1.write(update5Hz, sizeof(update5Hz)); 

^^ this above code did result in ublox spitting out data at a higher rate. I’m using the u-blox8-M8_ReceiverDescrProtSpec document for finding the relevant commands.

1 Like


My mistake-- I’m going against the GPS library directly instead of using the Asset Tracker wrapper. I noticed that the wrapper has a 500ms delay after turning on the GPS, and now I know why. :slight_smile: Without the delay that update message never gets received by the GPS module.

I added the 500ms delay in my code and now the 5Hz updates work well. Thanks!

That document you linked is an excellent resource-- you might want to put a link to it somewhere in the official Asset Tracker documentation for those that want to get into the low level details.

I have another related question after browsing through the U-Blox document and maybe you have the answer to it from your travels. I noticed there is a PUBX POSITION message (p. 121) that contains some combined useful information from the GGA and RMC messages. However, when I monitor the serial output from the GPS I never see any PUBX messages.

Any idea how I can configure the GPS module to output the PUBX messages? I see p. 120 has a configuration message but I’m not sure if that’s what I need to use to include those messages, and I’m not sure how to send that configuration message to the GPS module either (the structure is different from the config messages we talked about above).



I look forward to this library being updated.

My trackers like to report that they have a fix when they, in fact, do not.

To clarify, bool gpsFix() returns true if a fix was obtained and then lost. The fix can be lost for hours, and gpsFix() will still return true.

1 Like

Hi @mohit,

Going back to my original comment about the external/internal antenna logic, I still can’t get this toggle to make any difference in my GPS output.

I tried using the sample code and even tried changing the setting by using U-Blox U-Center (I assume it’s the “Enable Supply Voltage Control Signal” checkbox), but it makes no difference in the signal strength or number of satellites.

No matter which way I have this setting toggled, the GPS module always seems to use my external antenna. If I unplug the external antenna the signal immediately disappears.

I am trying to analyze how using the internal patch antenna vs. the external antenna will affect my signal quality but I can’t seem to get it to switch away from the external antenna.

Please help!


@rickkas7, perhaps you can help on this?

The first thing I’d do is double-check that the software switch is actually switching as expected.

If using the official AssetTracker library the antennaInternal and antennaExternal methods of the AssetTracker should set the antenna. Note that gpsOn() sets the antenna to internal, so that will always be the default. And if you want to set external, you have to do so after gpsOn.

If doing it manually, the instructions in the earlier posts should work as well.

Flip the AssetTracker over and measure the voltage between the EXT_ANT_EN pad and GND, as shown here:

When using the internal antenna (on the board), the value will be 0-ish volts.

When using the external antenna it should be driven to 3.3V by the u-blox modem module.

1 Like

Since there is new activity on this topic, I’ll chime in.
I have an Asset Tracker 2 and I tried using the AssetDriver with it without much success. Here is what I have learned.

The AssetTracker driver uses commands that are specific for the gps receiver on the original Asset Tracker. Asset Tracker 2 uses a different receiver (u-blox M8Q) so all the ascii commands starting with $PMTK are ignored by the receiver. To get the most out of the u-blox receiver you must use binary (not ASCII strings) commands.

The documentation for Serial1.write(str, len) says the parameter must be a string, which implies it is null terminated. The u-blox binary commands usually include zeros in the command which will confuse Serial1.write() if it is expecting null terminated strings. However, I am not sure about this if you include the length parameter to Serial1.write().

Anyway, I wrote a new driver for the Asset Tracker 2 called AssetTracker2. It uses the u-blox driver I wrote called UbloxM8Q_GPS.
I have a new example for AssetTracker2 that isn’t published yet. If I could figure out how to update what is already published it would be there but for some reason republishing isn’t working.

1 Like

If the already published lib belongs to you, you can just increment the version number, reupload and republish the lib.
If it’s someone else’s lib, you can file a PR on the GitHub repo of the lib.

Thanks for the reply.
Is it necessary to do an upload before the publish? I guess that’s the step I missed.
The documentation for the CLI library publish command says:
"Remember that it’s necessary to publish every new version after uploading it before others can use it in their projects."
Now I understand this sentence! I thought it was just reminding me to republish.

The new example is there now, and I think I got the dependencies set correctly now too.

As you quoted

You can only publish (make visible to others) a library after you uploaded it - that is true for the first version just as much as for any subsequent revision :wink:
Otherwise you would not be able to first test the library in the IDEs properly before making it public.
Just testing a local copy (especially all the examples) and trusting that everything will work just as good via the IDE import prove overly optimistic :sunglasses:

1 Like