How to read directly from Serial1? (baby steps into CASIC) #7025

espruino-discuss2 · 2025-02-12T17:28:52Z

espruino-discuss2
Feb 12, 2025
Maintainer

Posted at 2021-12-30 by Mark_M

To work with CASIC it needs to read/write binary data into GPS chip.
We can write into Serial1. But.
When I try to read directly from it I get nothing.

Bangle.setGPSPower(0);
Bangle.removeAllListeners('GPS');
Bangle.removeAllListeners('GPS-raw');
Serial1.removeAllListeners();
Serial1.unsetup();
Serial1.setup(9600,{rx:D30,tx:D31});
Serial1.on('data',function(data){print("ser:",data);});
D29.write(1); // turn GPS on

Here some output like bunch of pieces of NMEA messages is expected.
But nothing comes in.
When I set callback on 'GPS-raw' I receive them.
But it is not what I am looking for. I need to get raw bytes from Serial1.
'GPS-raw' does some parsing into string lines. That is what I am trying to avoid.

espruino-discuss2 · 2025-02-12T17:28:54Z

espruino-discuss2
Feb 12, 2025
Maintainer Author

Posted at 2021-12-30 by HughB

I have tried exactly the same approach and nothing comes back. On Bangle1 sending CASIC commands via Serial1. write() would cause the response to come back via the GPS-raw callback but this does not happen on Bangle 2. Something we need @gfwilliams to comment on in the new year.

Posted at 2021-12-30 by HilmarSt

I'm very interested in GPS topics (see my comments in http://forum.espruino.com/conversations/370398/ ) and wondering what's meant with "CASIC"?
Can it be used to implement Assisted GPS?
Forum and internet searches doesn't provide results for "CASIC".

Posted at 2021-12-30 by Mark_M

I've google-translated this document https://m5stack.oss-cn-shenzhen.aliyuncs.com/resource/docs/datasheet/unit/Multimode_satellite_navigation_receiver_cn.pdf

There is description of both textual CAS* and binary CASIC messages and commands.

Posted at 2021-12-30 by Mark_M

@hughb, I suspect we do not get response because
a) we call requests incorrectly. In the doc there are no description how to call a query, and no examples. Same as you, I just assume a query call should have no payload. That may be wrong assumption.
also there may be "a switch" that switches from NMEA to CASIC mode.

b) the particular chip cannot not talk in CASIC mode. Just in NMEA.

Posted at 2021-12-30 by HughB

In the doc there are no description how to call a query, and no examples.

All programming datasheets are like this. As I said in one of my other comments its rather like being taught to play chess with only a list of the moves, and no example of a real game.

I just assume a query call should have no payload.

Its a correct assumption. Its actually documented. Look at CFG-PRT. There are 2 types. One for enquiry and one for setting. The inquiry version has no payload - so length is set to 0x00, 0x00 and payload is left to blank.

So far I have been trying CFG-PRT and CFG-RATE with no payload. Calculating the checksum is a bit tricky, but when the payload is zero bytes you dont need to do the loop bit of the calculation. Here's the examples of what I have been trying so far.

function prt() {
  // CFG-PRT          head       len clas   id  checksum
  //             --------- --------- ---------  -------------------
          print([0xBA,0xCE,0x00,0x00,0x06,0x00, 0x00,0x06,0x00,0x00]);
  Serial1.write([0xBA,0xCE,0x00,0x00,0x06,0x00, 0x00,0x06,0x00,0x00]);
}

I have found an example of the manufacturer sending assisted GPS data.
I will share a post on that seperately.

Posted at 2021-12-30 by HughB

I suspect we do not get response because a) we call requests incorrectly.

Sure - but the Bangle 1 GPS chip would respond with a NACK if you sent a badly constructed command. So the fact that we get no response at all means either a) the Bangle is not configured to send the commands or receive the responses (this could be a HW or SW issue) or b) the chip has to be put into some mode to respond to the requests c) the chip does not support these commands for some reason. But having found the smoking gun on the Assisted GPS data app - it looks like they are supported.

Posted at 2021-12-30 by HilmarSt

Thank you for the spec!
Just an idea: I've seen receivers that communicate with different baud rates on different channels. Do you have tried to communicate with all "well known" baud rates?

Posted at 2021-12-30 by Mark_M

@HilmarSt I don't think it is possible to simultaneously communicate with multiple baud rates on same UART. I tried to switch the port to all documented baud rates, all works, though not stable above 57K.
The chip has 2 UART ports, may be CASIC is on the UART1 while NMEA is on UART0?

Posted at 2021-12-30 by Mark_M

@hughb, Bangle 1 GPS chip is swiss UBlox. Much more accurately documented. This chinese ZhongKe AT6558 is completely different beast, barely documented even in Mandarine.
What chip is your AGPS example is for? Could you share?
Also, in your example I think you moved 0x06 to 16 bits. It needs to be moved to 24. Like this

Serial1.write([0xBA,0xCE,0x00,0x00,0x06,0x00,0x06,0x00,0x00,0x00]);

example

>((0x06<<24) + (0x00<<16)).toString(16);
="6000000"

Posted at 2021-12-30 by HughB

What chip is your AGPS example is for?

The AT6558, the Bangle 2 GPS chip.

Could you share.

Done on separate post.
http://forum.espruino.com/conversations/371360/#comment16328807

Posted at 2021-12-30 by HughB

The chip has 2 UART ports, may be CASIC is on the UART1 while NMEA is on UART0?

That would explain why we get no response. Needs checking with @gfwilliams.

Posted at 2021-12-30 by Mark_M

@hughb I am looking into CFG-PRT, there is interesting item

Remark [1]: Protocol control mask
Bit describe
B0 1=Binary protocol input
B1 1=Text protocol input
B4 1=Binary protocol output
B5 1=Text protocol output

to me it looks like a way to configure the chip to work in CASIC or in NMEA, or in both. It looks like the chip is preconfigured to work in Text protocol (NMEA) only. There is CAS10 command that can do factory default to restart. That may turn on text and binary both.

Posted at 2021-12-30 by HughB

Wow - well spotted !

Posted at 2021-12-30 by Mark_M

thanks!

	aidIniMsg[2] = 0x38;		// LENGTH
	aidIniMsg[3] = 0x00;

this tells me U16 should be put as little first. Hmmm... is it this way everywhere?

and in ckSum = 0x010B0038;
0B is class and 01 is msgId. why these are switched, while 0038 is not?
weird.

Posted at 2021-12-30 by HughB

The doc say id << 24, but when its goes through the different msg types it always puts class followed by id together in every table. Its a bit confusing and easy to read the check sum as class << 24 when in fact its msg_id << 24.

It looks to me like the initial part of the chksum calc is done as:

sum = (msg_id << 24) + (msg_class << 16) ++ (len_byte1 << 8) + (len_byte0)

which matches the doc:

//The calculation of the check value can follow the following algorithm:
ckSum = (id << 24) + (class << 16) + len;
for (i = 0; i <(len / 4); i++)
{
    ckSum = ckSum + payload [i];
}

In this instance msg_id is 0x01, msg_class is 0x0B
The length is 0x0038 or 0x38 = 56 decimal bytes which is the size of the payload buffer.
As per screenshot below - the msg class and msg id are shown in that order in every part of the doc

Attachments:

aid-ini.png

Posted at 2021-12-30 by HughB

This is why I think my chksum for CFG-PRT is correct.
as msg_id = 00, class = 0x06, len = 0x0000 - together that makes 0x00 0x06 0x00 0x00

  Serial1.write([0xBA,0xCE,0x00,0x00,0x06,0x00, 0x00,0x06,0x00,0x00]);

Posted at 2021-12-30 by Mark_M

My doc v3.6 on pg 27 says:

ckSum = (class << 24) + (id << 16) + len;
for (i = 0; i <(len / 4); i++)
{
ckSum = ckSum + payload [i];
}

But the same doc v4.2 from the site says

ckSum = (id << 24) + (class << 16) + len;

confusing!

Posted at 2021-12-31 by Mark_M

So. I think the binary protocol is simply disabled for UART0 that is connected to NRF. May be there is a way to enable it by reset it to factory defaults.

But the question is - why I cannot read from Serial1 ?
Without it reading data from GPS-raw event probably does not make sense, because it may corrupt binary stream.

Posted at 2021-12-31 by HughB

I have:
V4.2.0.3 2020.01.06 Add PCAS60 statement and modify PCAS03 statement.

Posted at 2021-12-31 by @fanoush

So. I think the binary protocol is simply disabled for UART0 that is connected to NRF

I'd guess it is not, maybe bangle firmware does not pass unknown data to you and just discards it. You could maybe verify it by reconfiguring Serial1 to use different harmless pins and try to setup Serial2 (second nrf52840 uart) to use GPS pins, then hopefully bangle firmware will not interfere when using Serial2. BTW I did not try, this is just a guess.

Posted at 2021-12-31 by Mark_M

@fanoush
but why I cannot read from Serial1 at all?

I cannot find that C code for Bangle that is responsible for getting GPS data. Could you help me?

Posted at 2022-01-01 by HilmarSt

I've found something interesting in https://github.com/espruino/Espruino/blob/master/libs/banglejs/jswrap_bangle.c

ifdef BANGLEJS_Q3
...
define GPS_UART EV_SERIAL1
...
/*JSON{
  "type" : "EV_SERIAL1",
  "generate" : "jswrap_banglejs_gps_character",
  "#if" : "defined(BANGLEJS_F18) || defined(DTNO1_F5)  || defined(BANGLEJS_Q3)"
}*/
bool jswrap_banglejs_gps_character(char ch) {
...

Maybe that's what you are looking for.

Posted at 2022-01-02 by Mark_M

Thanks HilmarSt. But this looks like it is for UBlox. BangleJS2 has AT6558.
Is it same code used for both watches?
If so it will skip CASIC.

Posted at 2022-01-02 by HilmarSt

It's defined for
defined(BANGLEJS_F18) || defined(DTNO1_F5) || defined(BANGLEJS_Q3)
I don't know if one of these is AT6558 - but it seems so:
A search for "AT6558" in the contents of https://github.com/espruino/Espruino does not deliver any result.

Posted at 2022-01-02 by @fanoush

Is it same code used for both watches?

github has quite nice search, you can go to https://github.com/espruino/Espruino and it topleft corner enter e.g. ublox or casic or nmea and click 'in this repository'

As for using Serial2 - instead of finding random pins for Serial1 it could also work to configure just rx or tx, so do Serial1.setup with just tx: and then setup Serial2 with just rx: and hook into Serial2 'data' event to get replies and still write to Serial1

Posted at 2022-01-02 by HilmarSt

Both, the github search and the search in Espruino-master.zip returns no results for AT6558.

For "casic" or "uranus" it finds only one result:
'GPS' : {
'device' : 'Casic URANUS',
'pin_en' : 'D29', # IO expander P0
'pin_rx' : 'D30',
'pin_tx' : 'D31'

May be
BANGLEJS_F18 is Bangle.js
BANGLEJS_Q3 is Bangle.js 2
DTNO1_F5 is ?

Posted at 2022-01-02 by @fanoush

Yes, there is no code that would handle CASIC binary protocol for AT6558, only NMEA is used so far for bangle2 and also ublox protocol for v1. And almost everything for banglejs watches is in libs/banglejs (and some js stuff in libs/js/banglejs). F5 was something like version 0.

Posted at 2022-01-02 by HughB

Yes, there is no code that would handle CASIC binary protocol for AT6558, only NMEA is used so
far for bangle2 and also ublox protocol for v1

Do you mean there is no specific code for either in the firmware. For B1 we send UBLOX commands via serial1.write() via a javascript app called gpssetup:

https://github.com/espruino/BangleApps/blob/master/apps/gpssetup/gpssetup.js

For Bangle 2 we should be able to do the same approach for but different bits and bytes as per the CASIC protocol. The quest we have is how to setup the AT6558 so that it accepts both CAS and CASIC instructions.

The problem we have at the moment is that the chip appears to be told not to listen or respond to CASIC instructions and the only way to comfigure it to respond is to send a CASIC instriction.

As for using Serial2 - instead of finding random pins for Serial1 it could also work to configure just >rx or tx, so do Serial1.setup with just tx: and then setup Serial2 with just rx: and hook into Serial2 >'data' event to get replies and still write to Serial1

This sounds promising. I would not have a lot of confidence in how to code that; but if someone can get the Bangle 2 AT6558 to respond to CASIC instructions (over Serial1,write(), or Serial2.write()) I'm reasonably confident I could figure out how to put the AT6558 into a power saving mode and reduce its battery drain and build a Bangle 2 version of gpssetup.

Posted at 2022-01-02 by Mark_M

My understanding BANGLEJS_Q3 means Bangle JS2. And Q3 watch has AT6558 chip for GPS.

But, main question was - is jswrap_banglejs_gps_character(char ch) function assigned to Serial1 input for all time? Can it be unassigned by Serial1.removeAllListeners(); ?
For Q3 that C code should be adjusted to CASIC not UBX.

Posted at 2022-01-02 by HughB

For Q3 that C code should be adjusted to CASIC not UBX.

What C code are you referring to ? The C code just sets up the pipes. What flows through the pipes (UBX or CASIC) is sent via javascript in function calls to Serial1.write(...)- isn't it ?

Posted at 2022-01-02 by Mark_M

I am not saying about GPS chip input, I am about output, what GPS chip sends to Serial1 and how it is processed.
The code is in bool jswrap_banglejs_gps_character(char ch) in https://github.com/espruino/Espruino/blob/master/libs/banglejs/jswrap_bangle.c
it checks for a protocol, if it is NMEA or UBX it copyes data into ubloxMsg. Otherwise it just skips the data.
The way it check if it is UBX is in line 3690

    } else if (ch == 0xB5) {
      inComingUbloxProtocol = UBLOX_PROTOCOL_UBX;

That 0xB5 is specific to UBX, for CASIC it should be two bytes 0xBA 0xCE.
It also checks for consistency of NMEA at 3707-3719. I do not think it will pass whatever "unknown" binary data as NMEA. It will just skip it.

Posted at 2022-01-02 by HughB

Got it ! Bingo - thats the bug. The firmware assumes the Bangle 2 GPS talks UBLOX and throws the responses away if not. There should be a more generic way of doing this in the future.

Thats why we get no apparent response when we send CASIC commands.
We need @gfwilliams to do a firmware update.

If you agree I will log an issue and reference this thread.
Its the firmware thats causing the responses to be chucked away !

Posted at 2022-01-02 by Mark_M

I agree.
But also I am still puzzled where is the code that assigns jswrap_banglejs_gps_character(char ch) function to Serial1 input forever? And why it cannot be unassigned by Serial1.removeAllListeners(); ?

Posted at 2022-01-02 by @fanoush

But also I am still puzzled where is the code that assigns jswrap_banglejs_gps_character(char ch) function to Serial1 input forever?

interesting, it is the type specifier EV_SERIAL1
https://github.com/espruino/Espruino/blob/c09de7bc3a206760f16fd9482c2152dd73a9f605/libs/banglejs/jswrap_bangle.c#L3662
as per this
https://github.com/espruino/Espruino/blob/62a456e99abd49805599c03602cffa5afeaa1138/scripts/common.py#L63
so looks like returning always true from that method makes the character handled so it is not passed further.

The way it is done is quite complicated, here the jswOnCharEvent method is generated from such EV_XXX JSON comments https://github.com/espruino/Espruino/blob/47d22f82e1c5b325f62bdccafb324553dcff7655/scripts/build_jswrapper.py#L689
and here it is called https://github.com/espruino/Espruino/blob/86eba79a209f32a885e08ad34f688d406b04a8be/src/jsdevices.c#L419

Posted at 2022-01-02 by @fanoush

Its the firmware thats causing the responses to be chucked away !

That's why I was suggesting switching GPS output to Serial2 as a quick workaround to test CASIC commands.

something like this should work once gps is enabled

Serial1.setup(9600,{tx:D31});
Serial2.setup(9600,{rx:D30});

then the data will arrive to Serial2 instead where you can handle it yourself

Posted at 2022-01-03 by Mark_M

@fanoush. Great! This redirection to Serial2 works!
I am going to try some CASIC now.
Yes! After CASIC call GPS spits out some binary output. Most likely NACK.

D29.write(1); // turn GPS on
// pause
Serial2.write(0xBA,0xCE,0x00,0x00,0x06,0x00,0x00,0x06,0x00,0x00);
//short pause
D29.write(0);
=undefined
ser: ºÎ���
�

Posted at 2022-01-03 by Mark_M

First success! CASIC response received and parsed.

var h1=0,h2=0, l1=0,l2=0,
    cs1=0,cs2=0,cs3=0,cs4=0,
    protocolType="Unknown",
    casicPos=-1, payloadPos=0,
    inCasicMessage=false, casicIsCompleted=false;
var casicMsg={};

function parseCASIC(data){
  for(var i=0;i<data.length;i++){
    c=data.charCodeAt(i);
    //print("i:",i,"c:",c, "casicPos:",casicPos,"payloadPos:",payloadPos);
    if(c==0xBA && casicPos<0){
      h1=c;
      protocolType="CASIC";
      inCasicMessage=true;
      casicIsCompleted=false;
      casicPos=0; payloadPos=0;
      h2=0; l1=0; l2=0; cs1=0;cs2=0;cs3=0;cs4=0;
      casicMsg={};
    }
    else if(!inCasicMessage) return;
    else if(c==0xCE && casicPos==0){
      h2=c;
      casicPos++;
      casicMsg.hdr = (h1<<8) + h2;
    }
    else if(inCasicMessage && casicPos==1){
      l1=c;
      casicPos++;
    }
    else if(inCasicMessage && casicPos==2){
      l2=c;
      casicPos++;
      casicMsg.len = (l2<<8) + l1;
    }
    else if(inCasicMessage && casicPos==3){
      casicMsg.class = c;
      casicPos++;
    }
    else if(inCasicMessage && casicPos==4){
      casicMsg.msgId = c;
      casicMsg.payload=[];
      payloadPos=0;
      casicPos++;
    }
    else if(inCasicMessage && casicPos>4 && payloadPos<casicMsg.len){
      casicMsg.payload.push(c);
      payloadPos++;
      casicPos++;
    }
    else if(inCasicMessage && casicPos==casicMsg.len+5){
      cs1 = c;
      casicPos++;
    }
    else if(inCasicMessage && casicPos==casicMsg.len+6){
      cs2 = c;
      casicPos++;
    }
    else if(inCasicMessage && casicPos==casicMsg.len+7){
      cs3 = c;
      casicPos++;
    }
    else if(inCasicMessage && casicPos==casicMsg.len+8){
      cs4 = c;
      casicMsg.checkSum = (cs1<<24)+(cs2<<16)+(cs3<<8)+cs4;
      inCasicMessage = false;
      casicIsCompleted = true;
      casicPos = -1;
      protocolType="Unknown";
      print(casicMsg);
    }
  }//for
}

D29.write(0);
Serial2.removeAllListeners();
Serial2.setup(9600,{rx:D30,tx:D31});
Serial2.on('data', function(data){parseCASIC(data);});
D29.write(1);

some pause

//CFG-PRT query
Serial2.write([0xBA,0xCE, 0x00,0x00, 0x06,0x00, 0x00,0x00,0x06,0x00]);
=undefined
{ "hdr": 47822, "len": 8, "class": 6, "msgId": 0,
  "payload": [ 1, 7, 192, 8, 0, 194, 1, 0 ],
  "checkSum": 164218632 }
{ "hdr": 47822, "len": 8, "class": 6, "msgId": 0,
  "payload": [ 0, 119, 192, 8, 128, 37, 0, 0 ],
  "checkSum": -2002991608 }
{ "hdr": 47822, "len": 4, "class": 5, "msgId": 1,
  "payload": [ 6, 0, 0, 0 ],
  "checkSum": 167773441 }
>

Posted at 2022-01-03 by @fanoush

oh, the Serial2.setup silently steals pins from Serial1, I was expecting it to throw some error instead but this is even easier

Posted at 2022-01-03 by HughB

@Mark_M - brilliant ! I can see you had a late night. Many thanks for sharing. Just about to give it a go. I got bogged down in trying to shut the NMEA output up and failed miserably, so didn't make much progress.

I have logged the firmware issue at:
https://github.com/espruino/BangleApps/issues/1200

Posted at 2022-01-03 by Mark_M

to shut NMEA output you can use CAS06 with 0 for all types.
I have created module AT6558 that can do it conveniently.
I need to merge it. You can get from my github https://github.com/markmal/BangleApps/tree/master/modules

now I am starting working to make some functions. I will try to change mode to Car (CFG-NAVX). I tried GPS during driving, it is very slow, I can drive for like 30 sec at 40kph, but it still shows 18. Stubborn.
I do not know is it because of its poor reception (no or too small antenna) or because it is configured for pedestrians :)

Posted at 2022-01-03 by HughB

to shut NMEA output you can use CAS06 with 0 for all types.

I got CAS06 as product information. I think its CAS03 to set the outputs

None of these attempts worked for me.

// try and slow the output down 
function cas02() {
  // example $PCAS02,1000*2E  - 1 second in milliseconds
  sendCommand("CAS02,5000");  // does not work
}

// try and stop the NMEA output
function stp() {
  //example:  $PCAS03,1,1,1,1,1,1,1,1,0,0,,,1,1,,,,1*33
  // attempt no output - did not work
  //sendCommand("CAS03,0,0,0,0,0,0,0,0,0,0,,,0,0,,,,0");
  // attempt every 100, does not work
  sendCommand("CAS03,100,100,100,100,100,100,100,100,100,100,,,100,100,,,,100");
}

I can see gnss.setSentencesAll("0"); in your code, so assume that works for you.

 gnss.setSystems(1,0,0);
  gnss.setSentencesAll("0");
  gnss.setSentences({RMC:"1"});
  gnss.setUpdateRate(500);

Not to worry, I'm more interested in the CASIC controls to get the NAV frequency down to once every 2 minutes.

I'm working on trying to get a checksum function to work.
I will test it from the output of your parse_casic code.

Posted at 2022-01-03 by HughB

here's my variation of your code. Attempted to print out the checksum in Hex as it makes it
easier to manually check. I'm concerned about the negative checksum - this should not happen.

//cs1=0,cs2=0,cs3=0,cs4=0,

var h1=0,h2=0, l1=0,l2=0,
    protocolType="Unknown",
    casicPos=-1, payloadPos=0,
    inCasicMessage=false, casicIsCompleted=false;

var cs1 = new Uint32Array(1);
var cs2 = new Uint32Array(1);
var cs3 = new Uint32Array(1);
var cs4 = new Uint32Array(1);

cs1[0] = 0;
cs2[0] = 0;
cs3[0] = 0;
cs4[0] = 0;

var casicMsg={};

function parseCASIC(data){
  for(var i=0;i<data.length;i++){
    c=data.charCodeAt(i);
    //print("i:",i,"c:",c, "casicPos:",casicPos,"payloadPos:",payloadPos);
    if(c==0xBA && casicPos<0){
      h1=c;
      protocolType="CASIC";
      inCasicMessage=true;
      casicIsCompleted=false;
      casicPos=0; payloadPos=0;
      h2=0; l1=0; l2=0; cs1[0]=0;cs2[0]=0;cs3[0]=0;cs4[0]=0;
      casicMsg={};
    }
    else if(!inCasicMessage) return;
    // header byte 2
    else if(c==0xCE && casicPos==0){
      h2=c;
      casicPos++;
      casicMsg.hdr = (h1<<8) + h2;
      casicMsg.hdr = '0x' + (casicMsg.hdr).toString(16).toUpperCase();
    }
    // length byte1
    else if(inCasicMessage && casicPos==1){
      l1=c;
      casicPos++;
    }
    // length byte2
    else if(inCasicMessage && casicPos==2){
      l2=c;
      casicPos++;
      casicMsg.len = (l2<<8) + l1;
      //casicMsg.len = '0x' + casicMsg.len.toString(16).toUpperCase();
    }
    // class 
    else if(inCasicMessage && casicPos==3){
      casicMsg.class = c;
      casicPos++;
    }
    // msg id
    else if(inCasicMessage && casicPos==4){
      casicMsg.msgId = c;
      casicMsg.payload=[];
      payloadPos=0;
      casicPos++;
    }
    // accumulate payload
    else if(inCasicMessage && casicPos>4 && payloadPos<casicMsg.len){
      casicMsg.payload.push(c);
      payloadPos++;
      casicPos++;
    }
    // checksum bytes cs1, cs2, cs3, cs4
    else if(inCasicMessage && casicPos==casicMsg.len+5){
      cs1[0] = c;
      casicPos++;
    }
    else if(inCasicMessage && casicPos==casicMsg.len+6){
      cs2[0] = c;
      casicPos++;
    }
    else if(inCasicMessage && casicPos==casicMsg.len+7){
      cs3[0] = c;
      casicPos++;
    }
    else if(inCasicMessage && casicPos==casicMsg.len+8){
      cs4[0] = c;
      casicMsg.checkSum = ((cs1[0]<<24)+(cs2[0]<<16)+(cs3[0]<<8)+cs4[0]);
      casicMsg.checkSum16 = '0x' + casicMsg.checkSum.toString(16).toUpperCase();
      inCasicMessage = false;
      casicIsCompleted = true;
      casicPos = -1;
      protocolType="Unknown";
      print(casicMsg);
    }
  }//for
}

function setup() {
  print("setup()");
  D29.write(0);
  Serial2.removeAllListeners();
  Serial2.setup(9600,{rx:D30,tx:D31});
  Serial2.on('data', function(data){parseCASIC(data);});
}

function pon() {
  print("power on");
  setup();
  D29.write(1);
}


function pof() {
  print("power off");
  D29.write(0);
}

function prt() {
  Serial2.write([0xBA,0xCE, 0x00,0x00, 0x06,0x00, 0x00,0x00,0x06,0x00]);
}

Here's the output

>prt();
=undefined
{
  "hdr": "0xBACE",
  "len": 8, "class": 6, "msgId": 0,
  "payload": [ 1, 7, 192, 8, 0, 194, 1, 0 ],
  "checkSum": 164218632,
  "checkSum16": "0x9C9C708"
 }
{
  "hdr": "0xBACE",
  "len": 8, "class": 6, "msgId": 0,
  "payload": [ 0, 119, 192, 8, 128, 37, 0, 0 ],
  "checkSum": -2002991608,
  "checkSum16": "0x-776339F8"
 }
{
  "hdr": "0xBACE",
  "len": 4, "class": 5, "msgId": 1,
  "payload": [ 6, 0, 0, 0 ],
  "checkSum": 167773441,
  "checkSum16": "0xA000501"
 }
>pof();
power off
=undefined

Posted at 2022-01-03 by @fanoush

I'm concerned about the negative checksum - this should not happen.

https://stackoverflow.com/questions/1908492/unsigned-integer-in-javascript

Posted at 2022-01-03 by HughB

The only JavaScript operator that works using unsigned 32-bit integers is >>>. You can exploit this >to convert a signed-integer-in-Number you've been working on with the other bitwise operators >to an unsigned-integer-in-Number:

sounds like need todo >>> 0 at the end of the checksum calculation in parseCasic.

Posted at 2022-01-03 by @fanoush

or store it to Uint32 array element instead of reading from it (which does nothing helpful)

Posted at 2022-01-05 by Mark_M

@hughb

Not to worry, I'm more interested in the CASIC controls to get the NAV frequency down to once every 2 minutes.

I doubt it is possible.
I've made code that can set intervals 1000, 500, 200,100,50(yes, 20Hz!). But for other values it returns NACK.

function ckSum(len,cls,mid, pldDV){
  var cs = (mid<<24)|(cls<<16)|len;
  for(var i=6; i<pldDV.buffer.length; i+=4){
    print(i, pldDV.getUint32(i, true));
    cs += pldDV.getUint32(i, true);
  }
  print(cs.toString(16));
  return cs;
}
const UD='undefined';
function sendCfgRate(cfg){
  const cls=0x06, mid=0x04;
  var len = (typeof(cfg.interval)!=UD)?4:0;
  var msg = new ArrayBuffer(6+len+4);
  var dv = new DataView(msg);
  dv.setUint8(0,0xBA); dv.setUint8(1,0xCE);
  dv.setUint16(2, len, true);
  dv.setUint8(4,cls); dv.setUint8(5,mid);

  if(typeof(cfg.interval)!=UD){dv.setUint16(6+0,cfg.interval,true);}
  cs = ckSum(len,cls,mid,dv);
  dv.setUint32(6+len,cs, true);
  print(msg);
  Serial2.write(msg);
}

sendCfgRate({interval:10000})
6 10000
10 0
4062714
new Uint8Array([186, 206, 4, 0, 6, 4, 16, 39, 0, 0, 20, 39, 6, 4]).buffer
=undefined
{ "hdr": 47822, "len": 4,
  "payload": new Uint8Array([6, 4, 0, 0]).buffer,
  "payloadBytes": new Uint8Array([6, 4, 0, 0]),
  "class": 5, "msgId": 0, "checkSum": 168035584,
  "name": "ACK-NACK"
 }
>

Posted at 2024-10-11 by @gfwilliams

Resuming this conversation on https://forum.espruino.com/conversations/400068/

I have some nice reliable comms now without the Serial2 hack

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Espruino JavaScript

How to read directly from Serial1? (baby steps into CASIC) #7025

{{title}}

Replies: 1 comment

{{title}}

Select a reply

Espruino JavaScript

How to read directly from Serial1? (baby steps into CASIC) #7025

espruino-discuss2 Feb 12, 2025 Maintainer

Replies: 1 comment

espruino-discuss2 Feb 12, 2025 Maintainer Author

espruino-discuss2
Feb 12, 2025
Maintainer

espruino-discuss2
Feb 12, 2025
Maintainer Author