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

Posted on
Page
of 2
/ 2
Next
  • 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.

  • 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 @Gordon to comment on in the new year.

  • 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".

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

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

  • @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.

  • 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.

  • 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.

  • 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?

  • @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?

  • @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"
    
  • 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

  • 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 @Gordon.

  • @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.

  • Wow - well spotted !

  • 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.

  • 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


    1 Attachment

    • aid-ini.png
  • 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]);
    
  • 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!

  • 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.

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

  • 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.

  • @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?

  • I've found something interesting in https://github.com/espruino/Espruino/blo­b/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.

  • 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.

  • 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.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

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

Posted by Avatar for Mark_M @Mark_M

Actions