Bm_serial.py + cellular only transmission

Application Dev
1

Hi Sofar/Bristlemouth team,

Starting a new thread because this is related to the earlier cellular-only payload-length discussion, but the question is now more about queue behavior, API visibility, and whether my serial approach is correct.

Reference thread: “Cellular only transmission rates and data length limits”

Background

I’m using a Raspberry Pi connected over UART to a Bristlemouth mote/serial bridge inside a potted camera module. The Pi is running Python code that publishes Bristlemouth serial packets to:

spotter/transmit-data

I’m using this to send image chunks from the Pi through the mote/Bridge to the Spotter.

I do not currently have the original mote firmware source file, but the mote reports:

bm info 2f58e75e9f6554b5
Successfully sent info request
Neighbor information:
Node ID: 2f58e75e9f6554b5
VID: 0000 PID: 0000
Serial number 0123456789abcdef
GIT SHA: 31F3BEB7
Version: 0.13.3
HW Version: 0
VersionStr: serial_bridge@ENG-v0.13.3-1-g31f3beb7+ec5dc832
Device Name: 203538484d305010004a0045

Current Spotter/Bridge firmware:

Spotter: v2.16.6
Bridge: bridge@v0.13.11

I also have a branch with the current Pi-side source code here:

https://github.com/nickraymond/bm_rpi_camera_module/blob/cellular-only-test/field_units/bmcam002/BM_Devel_Pi/bm_serial.py

What I’m testing

In my Python bm_serial.py, the spotter/transmit-data payload includes a one-byte network selector before the payload data.

When I send with network type byte 0x01, the Ebox logs show:

MS_Q_LEGACY
Submitted spotter/transmit-data message to sat/cell queue

With 0x01, I also see the orange SIGNAL LED blink, and this appears to match the previously working behavior.

When I send with network type byte 0x02, the Ebox logs show:

MS_Q_CELLULAR_ONLY
Submitted spotter/transmit-data message to cell-only queue

Using 0x02, I can successfully queue both 300-byte payloads and larger ~990-byte payloads. With Bridge v0.13.11, the larger payloads are accepted and I no longer see the “message too large” error.

However, with 0x02 / MS_Q_CELLULAR_ONLY, I do not see the orange SIGNAL LED blink, and I am not yet seeing the resulting payloads through my existing API tooling.

Questions

  1. Is setting the spotter/transmit-data network type byte to 0x02 the correct Bristlemouth serial equivalent of calling:
spotter_tx_data(data, data_len, BmNetworkTypeCellularOnly);

from mote firmware?

  1. Should payloads submitted to MS_Q_CELLULAR_ONLY appear in /api/sensor-data as binary_hex_encoded Smart Mooring records, the same way 0x01 / MS_Q_LEGACY payloads do?

  2. If MS_Q_CELLULAR_ONLY payloads do not appear in /api/sensor-data, what API endpoint should I use to retrieve them?

  3. Is the orange SIGNAL LED expected to blink for MS_Q_CELLULAR_ONLY transmissions, or is that LED behavior specific to the legacy/sat-cell queue path?

  4. If the Notecard buffer percentage increases while using MS_Q_CELLULAR_ONLY, what commands or configuration should I check to confirm that those queued messages are actually syncing to the Sofar backend?

  5. Given that my potted module is using old serial_bridge@ENG-v0.13.3 mote firmware, do I need to update the mote firmware to use the recommended BmNetworkTypeCellularOnly path correctly, or is the Python-side spotter/transmit-data network byte approach expected to be supported?

Thanks — I’m trying to determine whether the issue is:

  • my Python serial implementation,

  • old mote/serial bridge firmware,

  • expected LED behavior,

  • Notecard flushing/configuration,

  • or API visibility for MS_Q_CELLULAR_ONLY.

1 Like
2

Hey @NickRaymomd!

To answer your questions in order:

Q1:

There should only be two network types when transmitting data from Bristlemouth:

typedef enum {
  BmNetworkTypeCellularIriFallback = (1 << 0),
  BmNetworkTypeCellularOnly = (1 << 1),
} BmSerialNetworkType;

Reference here in bm_core.

So when you are sending network type 0, you should be limited to the smaller iridium payload byte limit, but sending to type 1 you should have access to the larger ~1000 bytes. Type 2 does not exist and is probably why you have not been seeing data actually transmitted.

Q2 and Q3:

All messages will appear in the api/raw-messages endpoint, an example curl command to request data from this endpoint is:

curl "https://api.sofarocean.com/api/raw-messages?spotterId=SPOT-31082C&startDate=2026-05-28T20:00:00Z&endDate=2026-05-29T23:40:00Z" -H "token: $SOFAR_API_TOKEN" | jq

These messages will be prepended with a header (the first byte in the payload) which are:

  • DE (Legacy messages)
  • EA (Cell only messages)

The EA messages are encoded using protobufs. Give me some time and I will get you a python script that can decode these messages!

Q4:

The orange signal LED will only blink when the Spotter is sending data over cellular, it does not matter which MS_Q is sending date. If you are not seeing the signal LED that would mean:

  • The system is in iridium fallback (cell messages have failed for long enough of a time the system is sending over iridium)
  • Data is not actually being sent

It seems like the second reason is more likely. Again you should be sending Bristlemouth data to type 1 for your use case.

Q5:

If you invoke post in the Spotter’s terminal, and the errors for cellularSignalErrorState and cellularErrorState say OK, then the data is properly being sent to Sofar’s backend.
If you provide you Spotter ID I can also validate for you!

Q6

I do not thiunk it NEEDS to be update to the latest as v0.13.3 is still compatible with the current (and your installed) Spotter firmware.

Let me know if you have any other questions Nick!

P.S.

Something cool the team has been working on that would interest you - native Bristlemouth running on a Raspberry Pi. It is set up to communicate over UART to a mote, but act exactly like another Bristlemouth node on the network, so eliminating the need for the bm_serial.py file. The repository is setup to potentially work with 10BASE-T1L which would eliminate the UART bridging completely and make the Pi completely native!

1 Like
3

Also, the sensor-data API endpoint now shows all the data from dev kits and is much easier to use and understand than the raw-messages endpoint. This has been true for a long time now, but maybe word hasn’t spread widely enough.

The Sofar API docs got a revamp and polishing in the last couple months too. Here’s the documentation for the sensor-data endpoint: (GET) Sensor Data | Sofar API

1 Like