Search results for:

I've modified the app:

• seconds can be set to show: 0-never, 1-when unlocked, 2-always (default)
  
• app icon shows up in menu (it was 1-bit B/W, had to make it RGB)
  
• decimal time hint set to be black digits on white background. This can overlap with bottom widgets. Sometimes widgets may draw on top of the hint. I take it as ok-ish, because next second the hint will be repainted by the app again. But if you know how to stop bottom widgets to draw please let me know.
  Also they draw in main menu mode, and leave artefacts when menu is scrolled.
  
  

https://markmal.github.io/BangleApps/#ne­rdic

I cannot reproduce the issue with hint artefact. This is the code. Vars T SW,SH
There are couple of global vars (defined as `var T=0;' for example) have simple names like T, W etc. Can it be that same vars are used by widgets or menu, or any other program? Should I make sure my global variable names are unique in entire environment?

oh, I see ...

I see. it is weird issue. Need to take a look ...
Same weird is with the icon. Should icon data be 46 x 46?

I cannot reproduce it.
hmm .... may be it is after installation, when there is no settings file yet. I'll check.

Hi andiohn,
I have top and bottom widgets. (Bottom one draws garbage in main menu. But this is issue with menu).
The application draws up and down from center. So it is kind of widget agnostic.
I'll make it bigger right to the side edges.
ALso I'll make "hide seconds" feature.

what is your watch? I have B2. Hint is fine there. No garbage.
I'll try to simulate in B1 emulator.
All sizes currently are adjusting to display resolution automatically.
I'll think on the locked update frequency. But even without this optimization my watch runs for days.

I've uploaded Nerdic binary watch to my github App Loader https://markmal.github.io/BangleApps/#ne­rdic
You can try it from there.
I need to find out how to merge it to main App Loader.

Note1: double-tap to see decimal time hint
Note2: "Try in emulator" works for the main app. But unfortunately it does not load settings.

Each advertisement is send on 3 channels with up to 10 ms between, and receiver doesn't know which one they received.

theoretically receiver should know which one they received. Because this reception will happen on a particular channel. I am not sure if that low-level info can be available from the device.
Also I read that a BLE device can be configured to advertise on particular channels only. For example, you can advertise on 37 if (second % 3) == 0, on 38 it is 1 and on 39 if it is 2. So it will cover all channels and have no inter-channel delay. I hope. The price is - overall latency of receiving time can be up to 3 sec. But this time will be more precise.

I will try the hack with SoftDevice >=6.1 with updating timestamp in scan response static buffer on the fly

this is promising approach. I think a checksum needs to be sent as well, because there can be a risk of sending partially updated buffer.

As I understand there is no much difference. GPS should receive a time from a sat and then it can keep it in its RTC. My uderstanding, the main battery is connected to AT6558 backup power supply. When you turn off GPS power AT6558 will keep time in RTC and ephemerides in memory.
But the quartz is external, not in the chip, so if it is not good enough it can drift similar way as a "main" watch quartz. In normal operation GPS always receives time from sats. So RTC is just a backup, when no reception. Because it is not that important, they may put a cheap quartz there.

GPS time can be good and precise. But yes, indoor reception can be very poor. Also it is UTC. You need to keep timezone and time savings adjustments somewhere.

additionally a delay can be figured out if there are 2 BLE devices on a computer.
One Advertiser, another Scanner. The Scanner, when it receives time can compare it with the computer time.
I may be try it with laptop internal BLE and USB dongle.

yes, we do not want to connect, just to scan for broadcasted ads with a time in data. May be in future there should be a certificate or at least a shared public key for security. So some hacker do not set all Bangles around to a wrong time. :)

Yeah, I got same idea. Even tried to write such time announcement service in Linux. But low experience with BLE and shortage of time holds me...

LOL yes, exactly, I've added that "normal time" to top, but removed for this screenshot :)

I am thinking about couple of options for the normal time hint:
a - configurable to always show on screen
b - show on some activity like swipe or tap or shake
c - show if one holds watch in "looking" position for too long, like 3-5 sec.

what do you think?

(I do not have experience with the events above, so it will be a learning curve for me)

Hi Serj, sure, it should not be a problem. I'll need to add app settings.

My Nerdic binary watch.
Currently it is experimental on Bangle2, that is why this is B/W.
For Bangle1 it will simulate red, green or blue LEDs.
Or may be red for hours, green for minutes and blue for seconds.
Or it will be too colorful? What do you think?

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.

what about those 2 middle contacts? where these are connected to?

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

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.

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.

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.

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

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.

CASIC AID-INI is probably for other data. In the .bin file there are 32 MSG-GPSEPH (0x08 0x07) messages, for each GPS satellite. Then one MSG-GPSION (0x08 0x06) and one MSG-GPSUTC (0x08 0x05). The last one I'd probably re-craft with more current time, if it will work.
All messages already have checksums pre-calculated. They are ready to be pushed to the chip.
The only my concern is, they need to be pushed one by one, after ACK for each message is received. That is how it is stated in the doc.