Sending Assisted GNSS (A-GNSS) to Bangle 2 GPS (AT6558)

I assume you have sent these one by one manually.

No, after one first message is pushed, when response is captured, I check if it is ACK class. If it is, I call pushing of second message, and so on, until the buffer's end is reached.

var EPO=new DataView(
  require("Storage").readArrayBuffer("ble_­epo_offline.bin"));
var i=0, h1=0, h2=0, len=0, cs=0, p=0, pe=0,s="";
function pushNextAGPSMessage(){
  while(i<EPO.byteLength){
  h1=EPO.getUint8(i);
  h2=EPO.getUint8(i+1);
  if(h1==0xBA && h2==0xCE){
    s="";
    len=EPO.getUint16(i+2,true)+10;
    p=i; pe=p+len;
    print("push ",h1,h2, p, len);
    while(p<pe){
      s+=",0x"+EPO.buffer[p].toString(16);
      Serial2.write(EPO.buffer[p]);
      p++;
    }
    print(s);
    print(prsMsgGPSEph({payload:EPO.buffer},­i+6));
    i=p;
    return;
  }else{i++;}
  }
}

D29.write(0);
Serial2.removeAllListeners();
Serial2.setup(9600,{rx:D30,tx:D31});
Serial2.removeAllListeners();
var msg;
Serial2.on('data', function(data){
//print(data);
  msg=parseCASIC(data);
  if(i<EPO.byteLength && typeof msg != 'undefined' && msg.class==0x05){ 
    msg=undefined;
    while(Serial2.available()>0)print('A');
    pushNextAGPSMessage();
  }
});

D29.write(1);

Serial2.println("$PCAS03,0,0,0,0,0,0,0,0­,0,,0,,,0*32");

i=0;
pushNextAGPSMessage();

this code is very experimental. And parseCASIC(data) is not here. it is part of CASIC module I am working on.

Thanks - sorry, if it seemed by response previously was a bit terse - it wasn't my intention :)

Anyway what would be a best or easiest way for Bangle2 app to download the SMA .bin file from URL, without a need to go to Apps site and run Assisted GPS manually?

Yeah, that is actually a whole other issue. The idea is eventually the Bangle.js-specific Gadgetbridge app for Android will run the App Loader website internally. It should then be able to run the AGPS upload code in the background (maybe at midnight?).

I'm not convinced. The code for the AGPS app is here:

@HughB I just don't understand. It is pretty clearly appending the data at https://github.com/hughbarney/BangleApps­/blob/fa07467c4236409a00526254bce6c0ad35­e5c623/apps/assistedgps/custom.html#L157­-L160 and if you look with Puck.debug=3 in the console you'll see a big blob of data is being sent.

It seems users have reported it's working, so what exactly are you basing your assumption that it's not working/sending data on??

I did observe the first fix time to be about 1 minute which is perfectly fine for what I want and I could just modify my GPS touch app to send a CAS04 first.

We went through this exact thing with Bangle.js 1 didn't we? Why does your app need to send the command? If you use the AGPS app it should have configured your GPS just fine and hopefully there won't be a need to hard-code GPS config into the app.

For GPS config we could just port the GPS Setup app that existed for Bangle.js 1

@Mark_M it may be that streaming the data over bluetooth slows things down enough that everything works ok? I guess to check we'd need to move to Serial2 and the print the responses though.

Right now, we split the file into chunks of 128 bytes (https://github.com/hughbarney/BangleApps­/blob/fa07467c4236409a00526254bce6c0ad35­e5c623/apps/assistedgps/custom.html#L157­-L160) - they're sent over serial and we actually wait for a response after the command has finished (that doesn't mean it's been sent over serial, but it does add a nice delay).

I guess it would make a lot of sense to detect the chunks of data in the ble_epo_offline.bin file and instead split the data into those blocks? That way we'd have a nice pause between transmission of each

No problem :)

The idea is eventually the Bangle.js-specific Gadgetbridge app for Android will run the App Loader website internally. It should then be able to run the AGPS upload code in the background (maybe at midnight?).

Wow, that is complex. Is it possible, may be via the GB, or another way, just to download a content from an URL?

I guess it would make a lot of sense to detect the chunks of data in the ble_epo_offline.bin file and instead split the data into those blocks? That way we'd have a nice pause between transmission of each

I believe it would work better than just relying on 128 bytes chunks. Because end of previous message and beginning of next one can be inside a chunk.
And CASIC doc states in 2.5 CASIC message exchange, that app should not send next message before it receives ACK.
Though I do not trust Zhongke anymore :), and it can be Ok to send without awaiting for ACK, I just believe it makes sense to wait for it.

Regarding a pause. I am really missing it. Tried to implement sleep() in C, but got an error

Uncaught Error: 'E.InlineC' calls should have been replaced by the Espruino tools before upload

Regarding a pause. I am really missing it.

there are promises, setTimeout (just google 'javascript sleep') or in this case you can send next message in ack/nack handler of previous message?

Tried to implement sleep() in C

To make fastest sleep ever? You can shoot yourself in the foot much easier in javascript via for or while loop, or even digitalPulse, no need for inline C to block everything.

Uncaught Error: 'E.InlineC' calls should have been replaced

this needs to run gcc behind scenes, you are probably copy pasting directly to console or directly upload file or compiler in WebIDE does not work for some reason.

The ephemerides are only valid for about 4 hours, so an upload at midnight is probably not too useful.

@Mark_M, the docs explicitly say CFG commands require waiting for an ACK, all others do not. The AGPS data only uses MSG commands. This is probably because the CFG commands modify flash settings, which are a lot slower than anything that just goes into RAM.

so an upload at midnight is probably not too useful.

some agps documents describe the procedure how to find out that gps has stale data and needs it, attached translations.

the second one has chapter "when do you need AGNSS" with enabling status NMEA message for this and " If the time stamp is valid (non-zero) and the number of valid ephemeris is large (more than 8), there is no need to download the AGNSS"

2 Attachments

• Long-term ephemeris (LTE) use document of Zhongke Microelectronics.pdf
• Zhongke Micro AGNSS Solution.pdf

there are promises, setTimeout (just google 'javascript sleep')

promises are too cumbersome (for me :)). setTimeout is not blocking current "thread". Though it is possible to issue multiple growing timeouts for each message.

or in this case you can send next message in ack/nack handler of previous message?

That is exactly what I've done. And this is the best way. Better than a "pause".

To make fastest sleep ever? You can shoot yourself in the foot much easier in javascript via for or while loop, or even digitalPulse, no need for inline C to block everything.

while loop will eat energy. Sleep supposed to halt CPU. Yes in case of single threaded it will stop everything. Question - will it stop UARTs?

this needs to run gcc behind scenes, you are probably copy pasting directly to console

yes :(. Understood.

the docs explicitly say CFG commands require waiting for an ACK, all others do not. The AGPS data only uses MSG commands. This is probably because the CFG commands modify flash settings, which are a lot slower than anything that just goes into RAM.

may be. I've just preferred to wait for ACK. One may use "a pause" or a natural slowness of BLE serial.

fanoush. This doc is about LTE. They supposed to be loaded via AID class. The .bin data we load via MSG-GPS* is probably not LTE. Though MSG-GPSEPH is ephemerides. Short term ones? Needs to check what that $PCAS06,L*67\r\n shows before and after .bin loading.

@HughB I just don't understand.

Ignore my previous statement on AGPS - I was plain wrong. I was looking for CASIC commands and checksumming. I did not realise that the download came pre-checksummed etc. The AGPS app clearly works and reduces the TTFF to 1 minute for me.

For GPS config we could just port the GPS Setup app that existed for Bangle.js 1

That would be the plan if we can get the CASIC commands to work. But not a lot of success so far by the sound of things. I've not been actively looking at it recently.

there is some success, depends which commands do you need.

Is it possible, may be via the GB, or another way, just to download a content from an URL?

Not at the moment, but in the future it will be added. IMO using the App Loader is the less complex solution though as it means a lot less duplicated code, and less stuff running on the wath slowing it down :)

@fanoush finding out when AGPS data is needed would be really neat. It would be handy to be able to flag to the user when an update would help - I wasn't aware it only lasted 4 hours - that's not ideal :)

setTimeout is not blocking current "thread"

In Espruino, there is just one thread. So if you're writing inline C code that puts the device to sleep and waits for an interrupt, lots and lots of things are going to start breaking (including handling Serial data from the GPS, which I think you care about).

You can upload Inline C from the IDE (it's just not supported via the App Loader yet - you have to include the precompiled blob). Basically you just need to do what you're doing and wait for the JS data event. If you want to go deeper you'll have to compile your own Espruino firmware, and even then you have to work within the framework that is available - which means not blocking execution unless absolutely required.

the App Loader is the less complex solution

May be App Loader is the less complex and more optimal, but it requires manual intervention.
There are not too much code to parse and push the .bin to GPS.
And it can be automated. App, after it turns on GPS checks if it needs AGPS. It can be done with using $PCAS06,L*6, or just checking if no fix in 1 minute. Or checking if a bin file is there, but it is too old. If it is, then app downloads new file and pushes it into GPS.

In Espruino, there is just one thread.

I know, I am probably too spoiled by multi-threaded environments. :)
I am completely convinced not to halt the CPU.
I am reading about Generators and Yeld/Next. It looks like a concept of "yeld" in Windows to allow main loop to process messages and then return control back to a function.