# Bm\_serial.py + cellular only transmission
**URL:** https://bristlemouth.discourse.group/t/bm-serial-py-cellular-only-transmission/575
**Category:** Application Dev
**Created:** [June 13, 2026, 5:52pm UTC](https://bristlemouth.discourse.group/t/bm-serial-py-cellular-only-transmission/575 "2026-06-13T17:52:33Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@NickRaymomd](https://bristlemouth.discourse.group/u/NickRaymomd)
#### Post date: [June 13, 2026, 5:52pm UTC](https://bristlemouth.discourse.group/t/bm-serial-py-cellular-only-transmission/575/1 "2026-06-13T17:52:33Z")
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”
> [@Cellular only transmission rates and data length limits](https://bristlemouth.discourse.group/t/cellular-only-transmission-rates-and-data-length-limits/423/6):
>
> Hi @vsowa12 - awesome, thanks.
## 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:
```auto
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:
```auto
Spotter: v2.16.6
Bridge: bridge@v0.13.11
```
I also have a branch with the current Pi-side source code here:
```auto
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:
```auto
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:
```auto
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:
```auto
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`.
---
### Author:  [@matt001k](https://bristlemouth.discourse.group/u/matt001k)
#### Post date: [June 16, 2026, 5:44pm UTC](https://bristlemouth.discourse.group/t/bm-serial-py-cellular-only-transmission/575/2 "2026-06-16T17:44:20Z")
Hey @NickRaymomd!
To answer your questions in order:
* * *
## Q1:
There should only be two network types when transmitting data from Bristlemouth:
```c
typedef enum {
BmNetworkTypeCellularIriFallback = (1 << 0),
BmNetworkTypeCellularOnly = (1 << 1),
} BmSerialNetworkType;
```
Reference here in [`bm_core`](https://github.com/bristlemouth/bm_core/blob/b095bec4a54e67a8fcc580a28d75375fb9eacf12/integrations/spotter.h#L14-L17).
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:
```auto
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](https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://protobuf.dev/&ved=2ahUKEwjrxpuHqIqVAxXzODQIHf12IzcQFnoECCMQAQ&usg=AOvVaw3UgYpqcYHgt-BG6IXQ2g6H). 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](https://github.com/bristlemouth/bm_sbc). 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!
---
### Author:  [@zachary](https://bristlemouth.discourse.group/u/zachary)
#### Post date: [June 16, 2026, 6:27pm UTC](https://bristlemouth.discourse.group/t/bm-serial-py-cellular-only-transmission/575/3 "2026-06-16T18:27:56Z")
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](https://docs.sofarocean.com/spotter-and-smart-mooring/smart-mooring/sensor-data)