Message length limits when sending cell/iridium from the mote

Application Dev
1

Hey! We’ve had some solid progress recently and have been able to initiate data transmission to the API from the Dev Board app! I modified the example from Dev kit guide 5, and now we are automatically forwarding any data we get from our uart (rpi) payload to the API backend. It’s working pretty fast too- roughly 45 seconds per transmission I think, and the messages come in order even when we send them at like 0.5Hz.

Howeverrr… from my testing the longest message we can send is 48 bytes - anything longer and the entire dev board crashes. I was referencing this thread where you say:

This is not my experience so far :confused: Here is how we are sending it in our dev board app, just like guide 5 with a modification to recast the char buffer to uint8.

    uint16_t read_len =
        PLUART::readLine(payload_buffer, sizeof(payload_buffer));
    /*
       a lot of other stuff here
    */
    // Copy uart data into a raw bytes buffer and send
    uint8_t tx_data[read_len] = {};
    memcpy(tx_data, reinterpret_cast<uint8_t *>(&payload_buffer), read_len);
    if(spotter_tx_data(tx_data, sizeof(tx_data), BM_NETWORK_TYPE_CELLULAR_IRI_FALLBACK)){
      printf("%llut - %s | Successfully sent Spotter transmit data request\n", uptimeGetMs(), rtcTimeBuffer);
    }
    else {
      printf("%llut - %s | ERR Failed to send Spotter transmit data request!\n", uptimeGetMs(), rtcTimeBuffer);
    }

And when it lands in the backend, heres an example of what that looks like:

    {
      "latitude": 34.4145333,
      "longitude": -119.8480833,
      "timestamp": "2024-04-29T05:32:02.000Z",
      "sensorPosition": null,
      "bristlemouth_node_id": "0x29f5069863a2a349",
      "units": "hex",
      "value": "3c5478783e74657374313238",
      "unit_type": "binary",
      "data_type_name": "binary_hex_encoded"
    },

It’s the exact same format as when we send it from the spotter console. Any thoughts? Can we access the whole buffer?

2

Hey there! Congrats sending things along successfully!

If you look just below the quoted post I corrected that figure slightly — Spotter adds a 29-byte header, so the max you can send in one transmission is 311 bytes.

I would not expect the data transmission to cause a crash, so I’m guessing the crashes happen around the same time as an attempted large transmission but for a different reason. If you can share more info like:

  • What’s the physical setup? Just dev kit with serial to the rpi with a power supply? Is the Spotter connected?
  • What are all the versions of firmware on all the devices?
  • More code? You could point us to a public code repo or a gist or pastebin if it’s too big to be easily readable in the forum.
  • How do you know that longer transmissions are correlated with the crash? Maybe you have logs from the RPi? Share log snippets?

Happy to help given more info. Psyched about the progress! :raised_hands:

3

The spotter and dev board are connected to each other and both on. Spotter is running on battery and dev board is powered by the wall wart. The raspberry pi is connected to the dev board by TX, RX and GND, and is powered separately.

The spotter is running spotter_bm-dbg v2.9.0. We are running a custom app firmware on the dev board and the full user_code is here.

To test this I’ve just been running this from the rpi. I started with a short message, hit send and checked the dev board console for the “Successfully sent Spotter transmit data request\n” output, and then increment the length until it crashes. Based on that, maximum length is 48.

import serial

# Define the serial port and parameters
ser = serial.Serial('/dev/ttyS0', baudrate=9600, timeout=1)

try:
    # Open the serial port
    if not ser.is_open:
        ser.open()

    data = "short test qwertyuiopaskl3vb444nm,.currlength 49\n"
    ser.write(data.encode())
    print(data)
    print(len(data))

finally:
    ser.close()

If a message fails and crashes the dev board, there’s no acknowledgement of that in the spotter console. If message queues successfully, I get a (spotter console) output like this:

2024-05-06T19:19:03.078Z [MS] [INFO] Added message(id: 18 len: 73) to queue MS_Q_LEGACY: (1)!
Message: DE 66 39 2D 28 B3 FF 9C 02 11 29 13 09 7D DF 1B 0D 8E 8A 8D 24 A7 D4 1A 63 16 5F 2B F0 73 68 6F 72 74 20 74 65 73 74 20 71 77 65 72 74 79 75 69 6F 6B 6C 76 62 34 34 34 6E 6D 2C 2E 63 75 72 72 6C 65 6E 67 74 68 20 34 38 
2024-05-06T19:19:03.082Z [BM_TX] [INFO] Submitted spotter/transmit-data message to sat/cell queue, Len: 45
2024-05-06T19:19:03.082Z [BM_TX] [DEBUG] Message:
 73 68 6f 72 74 20 74 65
 73 74 20 71 77 65 72 74
 79 75 69 6f 6b 6c 76 62
 34 34 34 6e 6d 2c 2e 63
 75 72 72 6c 65 6e 67 74
 68 20 34 38

So it looks like its adding 73-45 bytes to it? But that doesn’t add up to 311 bytes…
A question for my understanding - what is MS_Q_LEGACY?
Also, I don’t know if this is relevant, but I am also seeing random messages like this pop up in the spotter console:

2024-05-06T19:19:58.320Z [MS] [INFO] Added message(id: 9 len: 6135) to queue MS_Q_CELLULAR_ONLY: (1)!
Message: 08 01 12 F2 2F 0A //followed by a huge block of hex data

What does this mean? Is cellular a thing now?

Sorry for the scattered post - im probably missing some relevant information. Let me know what you’re thinking!

4

Thanks for all of that — very helpful. I notice line 34:

#define RPI_BUFFER_SIZE 48

Have you been changing that variable as you’ve run your sending tests on the RPi?

It looks like the while loop at line 135 will be infinitely stuck after you read the first 48 bytes, requiring a reset to become responsive.

Does that help?

5

Whattt why is that there who wrote that?!? :disguised_face: (it was me)
Thanks - that nailed it. We are so close!

1 Like