Getting started with the serial protocol

Discussion in 'General' started by Øyvind Nydal Dahl, Jun 6, 2015.

  1. Øyvind Nydal Dahl

    Øyvind Nydal Dahl New Member

    I am trying to receive some data from the serial protocol. Here are my experiences and questions so far:

    Checksum:
    It says "Calculated by XOR’ing all bytes, including <start>" – but it doesn't specify whether or not <stop> is included. At first I also included <stop> since it says "ALL bytes". Then I got this response: 0x7d 0x20 0x02 0x00 0x00 0x00 0x5f 0x7e

    After a while, I tried without the <stop>, then I got the right acknowledge. So I guess the above response means CRC error.

    App ID
    In the protocol documentation it says to load an application using the AppID. But it doesn't specify what the appID is. After looking further down in the document, I found a name that looked promising: XTS_ID_APP_RESP
    I got the right ack, so I assume it's correct.

    Receiving respiration data
    I am currently stuck here. I've tried the following:

    Load respiration app:
    XTS_SPC_MOD_LOADAPP + XTS_ID_APP_RESP

    Execute application:
    XTS_SPC_MOD_SETMODE + XTS_SM_NORMAL

    Now the red and green LEDs are blinking continuously, so something is happening, but no data is being sent.

    I also tried to set the detection zone before executing app, but then the module doesn't reply:
    XTS_SPC_APPCOMMAND + XTS_SPCA_SET + XTS_ID_DETECTION_ZONE + start_zone + stop_zone
    (XTS_SPCA_SET was not specified, but I was told this should be 0x10)


    Could you give an example of how to receive data through the serial protocol?
     
  2. Ole-Johan

    Ole-Johan Moderator Staff Member

    Hi Øyvind.

    I am sorry to say that the protocol documentation on this site was from a pre-released revision, so I understand that you have had some challenges.
    We have just now uploaded a new revision of the document, and I believe this answers most of your questions. Please have a look at that, hope this helps.

    Ole-Johan
     
  3. admin

    admin Administrator Staff Member

  4. Øyvind Nydal Dahl

    Øyvind Nydal Dahl New Member

    Thanks! The updated document makes the appid and crc a bit clearer.

    But I still don't see how I can get respiration data from the device. It looks like you only included what is received in the serial documentation – not what to send to start receiving data.
     
  5. Øyvind Nydal Dahl

    Øyvind Nydal Dahl New Member

    Update:
    I've also tried the XTS_SPC_MOD_SETMODE + XTS_SM_RUN from the updated specification. But still no data being received.
     
  6. Ole-Johan

    Ole-Johan Moderator Staff Member

    Use the procedure described in the datasheet "How it works", like this:
    1. Reset module (XTS_SPC_MOD_RESET, wait for system message XTS_SPRS_READY)
    2. Load application (XTS_SPC_MOD_LOADAPP)
    3. Load parameters (optional, e.g. XTS_SPC_APPCOMMAND)
    4. Run application (XTS_SPC_MOD_SETMODE + XTS_SM_RUN)

    After this series of commands, the sensor will start streaming data automatically. No other commands are needed.

    PS! Have you verified that all these commands give a correct return value?
     
  7. Øyvind Nydal Dahl

    Øyvind Nydal Dahl New Member

    So, this time I am also making sure I get the XTS_SPRS_READY before moving on. I am not loading any parameters, because when I try – I don't get any reply from the sensor. I'm guessing it's not required to set any parameters, so I will just ignore that problem for now and focus on just getting some data.

    I am pretty sure I am following the procedure you describe above, but still no luck. Can you double check that I am using the correct values? Here is the debug output from my python-script:


    oyvdahl@oyvind-XUbuntu:~/Dropbox/Utvikling/Python/XeThru$ python serial-test.py
    Opened /dev/ttyUSB0

    Reset module...
    Sending:
    0x7d
    0x22
    0x5f
    0x7e
    Receiving...
    0x7d
    0x30
    0x10
    0x0
    0x0
    0x0
    0x5d
    0x7e
    Receiving...
    0x7d
    0x30
    0x11
    0x0
    0x0
    0x0
    0x5c
    0x7e

    Load respiration app...
    Sending:
    0x7d
    0x21
    0x14
    0x23
    0xa2
    0xd6
    0x1f
    0x7e
    Receiving...
    0x7d
    0x10
    0x6d
    0x7e

    Execute app....
    Sending:
    0x7d
    0x20
    0x1
    0x5c
    0x7e
    Receiving...
    0x7d
    0x10
    0x6d
    0x7e

    Waiting for data
    Receiving...


    And at the end it just waits forever without receiving any data.
     
  8. Olav Liseth

    Olav Liseth Administrator Staff Member

    Øyvind,

    I had to implement a python example myself and got it running. The problem is your endianness in the app id, change to little endian and it will run! I reckon you should get an error message when sending a wrong app ID.
    We will update the documentation and file a bug on the return message.

    Olav
     
  9. Øyvind Nydal Dahl

    Øyvind Nydal Dahl New Member

    Thanks Olav, I changed the endianess, and now I'm getting data :)
     
  10. Øyvind Nydal Dahl

    Øyvind Nydal Dahl New Member

    Ok, so now I'm struggling with parsing the data.

    I'm using the format from the protocol documentation:
    <Start> + <XTS_SPR_APPDATA> + [XTS_ID_RESP_STATUS(i)] + [Counter(i)] + [StateCode(i)] + [StateData(i)] + [Distance(f)] + [Movement(f)] +[SignalQuality(i)] + <CRC> + <End>


    And here is one of the data packets I received:

    0x7d
    0x50
    0x26
    0xfe
    0x75
    0x23
    0x7b
    0x0
    0x0
    0x0
    0x4
    0xd7
    0x91
    0x63
    0x29
    0x0
    0x0
    0x0
    0x0
    0x0
    0x0
    0x0
    0x0
    0x0
    0x0
    0x0
    0x0
    0x0
    0x0
    0x0
    0xd0
    0x7e

    If I split this into the format above, I get:

    0x7d - START

    0x50 - <XTS_SPR_APPDATA>

    0x26 - [XTS_ID_RESP_STATUS(i)]
    0xfe
    0x75
    0x23

    0x7c - [Counter(i)]
    0x0
    0x0
    0x0

    0x4 - [StateCode(i)]
    0xd7
    0x91
    0x63

    0x2a - [StateData(i)]
    0x0
    0x0
    0x0

    0x0 - [Distance(f)]
    0x0
    0x0
    0x0

    0x0 - [Movement(f)]
    0x0
    0x0
    0x0

    0x0 - [SignalQuality(i)]
    0x0
    0x0
    0x0

    0xd4 - CRC

    0x7e - STOP


    So the first problem here is that StateCode(i) is a weird value. It should be between 0 and 6, according to the documentation. If it was one byte only, it would be 4, which would make more sense. But then I would have three unused bytes at the end...
     
  11. Olav Liseth

    Olav Liseth Administrator Staff Member

    Replicated your issue, the last byte is correct though. Will get back to you about the three other bytes.
     
  12. Ole-Johan

    Ole-Johan Moderator Staff Member

    I believe this is a type conversion bug in the FW. We changed this from being a 8-bit to a 32-bit value right around the beta release, and in the process the version currently on the module could send undefined data on the 3 remaining bytes. You should be able to get the correct response by removing the upper 3 bytes. The value is for now limited to less than 8-bit, so there is no loss of data. The next version of the FW will provide a true 32-bit value.
     
    Øyvind Nydal Dahl and admin like this.
  13. Øyvind Nydal Dahl

    Øyvind Nydal Dahl New Member

    Ok, now it's working and I'm reading respiration data! I just discarded the 3 extra bytes in state code.

    I'll upload my python code here, just in case anyone else is interested to see how I got it working.
     

    Attached Files:

  14. Marius Lind Volstad

    Marius Lind Volstad Member Staff Member

    Hi,

    I hope it's okay that I continue on this one rather than creating a new protocol thread.

    I'm getting something that might look like a malformed error response after the acknowledge response on Set Detection Zone. I have highlighted the specific portion of the log below.
    Everything seems to be working properly and the zone is being adjusted according to my expectations.
    As far as I can see from the protocol document it shouldn't be there. Have I missed something or is this a bug?

    Reset module
    Transmitting: 0x7d 0x22 0x5f 0x7e
    Received: 0x7d 0x30 0x10 0x00 0x00 0x00 0x5d 0x7e
    Received: 0x7d 0x30 0x11 0x00 0x00 0x00 0x5c 0x7e

    Load presence application
    Transmitting: 0x7d 0x21 0x12 0x89 0x28 0x00 0xef 0x7e
    Received: 0x7d 0x10 0x6d 0x7e

    Set LED control full
    Transmitting: 0x7d 0x24 0x02 0x5b 0x7e
    Received: 0x7d 0x10 0x6d 0x7e

    Set detection zone
    Transmitting: 0x7d 0x10 0x10 0x1c 0x0a 0xa1 0x96 0x00 0x00 0x00 0x3f 0x66 0x66 0xa6 0x3f 0xfa 0x7e
    Received: 0x7d 0x10 0x6d 0x7e
    Received: 0x7d 0x20 0x00 0x00 0x00 0x00 0x5d 0x7e

    Set mode
    Transmitting: 0x7d 0x20 0x01 0x5c 0x7e
    Received: 0x7d 0x10 0x6d 0x7e

    Status
    Received: 0x7d 0x50 0xbe 0x52 0x1a 0x99 0x00 0x56 0x00 0x0b 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x1f 0x7e
    Received: 0x7d 0x50 0xbe 0x52 0x1a 0x99 0x00 0x56 0x00 0x0b 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x1f 0x7e
     
  15. Ole-Johan

    Ole-Johan Moderator Staff Member

    You are correct in you assumption that the "extra" error message is a bug. The first response you get is the correct one, and that can be either an ack or an error. But the second response should not be there, ant it will always send error with errorcode 0.

    This is fixed, and will be available in the next update.
     
  16. Øyvind Nydal Dahl

    Øyvind Nydal Dahl New Member

    I couldn't find the baudrate anywhere in the documentation. But if anyone is wondering: it's 115200
     
  17. belaz

    belaz New Member

    Hi,
    Does the protocol support any flow control? It looks like CRC check is catching about 0.3% of packets for me. And it looks like it is due to missing or added bytes. Does anybody observe similar behavior?
    Thanks
     
  18. Ole-Johan

    Ole-Johan Moderator Staff Member

    Hi Belaz.
    As of now there is no flow control. We have not yet experienced any problems with the current setup. What kind of device are you using to connect to the module?

    Thanks,
    Ole-Johan