Asset Tracker Ublox AssistNow

electron
Tags: #<Tag:0x00007fe22305f200>

#1

Hi

I’m looking at increasing the speed at which the GPS module acquires a location for the asset tracker V2.

Looking at the spec of the UBLOX chip it has ‘AssistNow’ which allows the satellite data to be downloaded and used so the location can be identified more quickly.

Has anyone got any example r help on doing this.
I’ve looked at https://gist.github.com/veproza/55ec6eaa612781ac29e7

I’m using the TinyGPSPlus library in my code - Would this be compatible with this idea???

Thanks.


#2

I haven’t seen anyone do it, but it’s possible. The main issue is that the AssistNow commands use the u-blox UBX protocol over serial (or I2C) and the TinyGPS++ parser doesn’t know how to process the UBX reply messages that indicate success or failure of the operation. It only process NEMA messages.


#3

Thanks. So i need to write / find a new process for the ublox chip…

I’ve registered for their Assisted GNSS service … so i can at least have ago…

I’ll report back when / if i get anywhere :wink:


#4

@medida, I have Assistnow working on a non-Particle (:speak_no_evil:) commercial device. The data you get from Assistnow is the raw configuration message that needs to be sent to the Ublox M8 device. It can exceed 1200 bytes and is ephemeral in that the data is only good for a short time (30s or so). Though their user manual indicates that you can configure the assistnow command to return ACKs, I never got it to work. Instead, another approach they suggest is to send each byte of the message with a small delay between bytes. This turned out to work very well with GPS locks taking < 2 secs instead of tens of seconds.

Note that I wrote a PUBX message parser instead of using NMEA strings. You do have to configure the UBlox to actually use AssistNow which is done via a PUBX command if I recall. Once setup, sending the assistnow data doesn’t require any “handling” since you only send the raw data and never get an ACK back.


#5

Thanks for that - Its nice to know there its possible.

I’m trying to tidy up a project i have which is a battery powered tracker… At present the GPS is working OK - but if it could obtain a location more quickly - then i can shut it down and hopefully save power. I realise that its a trade off from modem to GPS timings.

I thought their assistnow data was good for a few hours. although the tracker will only be activated once / twice aday… So i had been interested in the data which last a month…


#6

AssistNow Online is valid for ~2-4 hours but allows for much better accuracy. You need a cell connection every time you wake up and lock outside that validity window to get the benefit.

AssistNow Offline is valid for up to 35 days (depending on how much you download) but over the course of that 35 days the lock quality becomes progressively worse. Depending on your use-case the accuracy hit can be OK and can refresh periodically rather than go out to 35 days. Doesn’t require cell connection when waking up to lock.

See https://www.u-blox.com/sites/default/files/products/documents/MultiGNSS-Assistance_UserGuide_(UBX-13004360).pdf with a lot more detail. Includes a graph for relative accuracy if you really did let AssistNow Offline age out to a month.


#7

@medida, you are correct that the assistnow data can last some hours:

image

With a moving asset, this data gets old quickly. In my application, if the GSM modem can connect, the assistnow data is fetched which accelerates the “full” GPS position acquisition cycle. Without assistnow, the position takes longer to acquire.

In your case, since you will be connecting to the cloud once or twice a day, it doesn’t take much more power to do the assistnow fetch to accelerate your GPS lock.


#8

Thanks, I’ll get a test setup and see how it goes.
I’ve received my ublox token now as well :slight_smile:
Cheers for the help.


#9

So just a quick update on how this worked out…

Yes it got a position - but i was only wanting to get a position at most every 4 hours … but mainly once a day

It used so much power that the battery only last a few days - also the amount of data used - which is obvious - but its a big consideration

So sometimes it would acquire a GPS in a few seconds… others it would have to download the Assist data - and then calculate the position.


#10

Has anyone gotten this working yet? I am having trouble doing the HTTP request from ublox servers and would appreciate if anyone had some code how to do the HTTP GET on a particle Boron.


#11

I had it working - but I’ve not used the project for May 2019.

From memory - i did not find it any more accurate for the hassle.

Do you have the secrets.h setup OK - which has the ASSITNOW_TOKEN in it.
I’f your still stuck i’ll upload my project somewhere for you. Mine was based on the electron - but i have since cancelled the project due to the cost to manufacture devices was completed.


#12

You need an access token from ublox in order to access the AssistNow data. Do you have one?


#13

Yes I have a token. I can get data using U-Centre and send that via Serial to the device.
But i can’t get the right HTTP GET Request.

Here is my code

#include "HttpClient.h"

//Ublox AssistNow
HttpClient http;  
 http_header_t headers[] = {  
    { "Accept" , "*/*"},
    { NULL, NULL } // NOTE: Always terminate headers will NULL
 };
http_request_t request;  
http_response_t response; 

void setup(){
  Serial.begin(9600);
  Postrequest();
}

void loop(){
}

void Postrequest(){
  request.hostname = "online-live1.services.u-blox.com";
  request.path = "/GetOnlineData.ashx?token=redact;gnss=gps,glo;datatype=eph,alm,aux,pos";
  
  request.port = 80;
  http.get(request, response, headers);
  Serial.print("Response status: ");
  Serial.println(response.status);

  Serial.print("HTTP Response Body: ");
  Serial.println(response.body);
}

And here is the response

Response status: 200
HTTP Response Body: �b‼@↑

The response should be much longer. So clearly im not decoding something right.


#14

@jack4566, the AGPS message is binary data containing a set of UBX commands which can be sent to the Ublox directly. Don’t expect to see anything with println() and instead print out each byte of the response buffer in HEX format to see what you get.


#15

Right the information is not going to be readable but it should be more than 16 bytes. Not sure what I’m missing.


#16

@jack4566, how are you assessing the size of the response to be 16 bytes? Is the response buffer size set to the default 1024 bytes?


#17

I didnt change any of the buffer sizes, so yes?
Using this to determine size.

Serial.println((int)sizeof(response.body));

Code is above.
I am willing to PM you my token key if you want to run my code.


#18

response.body is a String object and requesting its size will not give you the actual length of the response but the static size of the object while the dynamic portion (aka the actual string content) is not part of that.

To request the length of a String object you’d use the respective method

Although for binary data this may be difficult unless the data is encoded (e.g. base64).

Also, as @peekay123 already pointed out the default (hence maximal) size of a response that can be accepted by the HttpClient library is 1023 bytes - anything beyond that would be discarded and never make it into the response.body string.

BTW, your function is called Postrequest() but then you are not POSTing but rather issuing a GET request.
While this won’t affect the outcome it’s still confusing and should be avoided for the sake of readability and maintainability.