Broad questions around cellular data sending/receiving

Dev Kit Support
1

Hi, I got a dev kit last week and I’m working through maybe a slightly unconventional use-case. It’s a great product and the docs are quite nice!

I basically just want to use the smart mooring as a thin data pipeline. I’ll connect over serial (or i2c if I figure out how) from my own microcontroller. And then just send bytes and expect to get them from your web API.

A few questions have arisen I haven’t been able to answer in the docs:

  1. Is the spotter mooring code available anywhere? It would be nice to have for interpreting error logs. OK if not.

  2. If I send data with BM_NETWORK_TYPE_CELLULAR_IRI_FALLBACK I can get it from your server. But if I send BM_NETWORK_TYPE_CELLULAR_ONLY, I just see messages like the below, and nothing makes it to the sensor-data API.

2024-01-08T17:42:38.324Z [BM_TX] [DEBUG] Message:
64 61 74 61 3a 20 74 65
73 74 20 74 69 6d 65 3a
20 32 30 32 34 2d 30 31
2d 30 38 54 31 37 3a 34
32 3a 33 38 2e 31 30 35

2024-01-08T17:42:38.371Z [MS] [DEBUG] Notecard is 17.000000 pct full.
2024-01-08T17:42:38.371Z [MS] [INFO] Sending Cellular message to Notecard.
2024-01-08T17:42:38.371Z [MS] [INFO] Queuing message 259 20004510

I do have a green light for SIGNAL on my spotter. And I tried typing note enable which says it was enabled successfully. Additionally I see a log for Cellular SignalErrorState changed from CONNECTING to OK. I’m not sure how to tell if my messages sent with iridium fallback are being sent over iridium, to determine if this is a code bug.

  1. Your devkit docs say Note: Messages sent if the Spotter has not established a GPS fix will not appear at the regular sensor-data API endpoint, as data that comes in without a valid timestamp and coordinates is filtered from this API endpoint. However it’s not clear to me what format the raw-messages API is actually in… there’s a message field but it’s not decodable as hex utf16 the way your sensor-data.
2

Hi @chris — Welcome! :wave:

You are not the first to notice that the cellular-only queue doesn’t show up in the API. It’s not a bug in your code; it’s a feature we haven’t finished building. :sweat_smile: Check out this thread for more info: Spotter_tx_data possible bug - #4 by zachary

Spotter is a complex product with multiple MCUs. The main Spotter firmware repo is closed source. Let us know if there are logs you’d like to understand better. You may find our SD Card Data Guide helpful. You can get there by going to the Sofar website → clicking support → click the button under “Spotter Documentation & Onboarding” and scroll down to the heading “Onboard SD Card Data”.

The bm_protocol github repo contains the open source firmware for one of the MCUs inside the bouy, the Bristlemouth Bridge. You may find that some logs you’re investigating come from the Bridge, so it’s often worth searching the bm_protocol code.

The “cellular with Iridium fallback” queue does send over cellular if the device has a cell signal. If the Spotter is going to send data from this queue over Iridium you should see in the logs at some point:

Falling back to Iridium modem

As well as

Entering Transmit Iridium State, powering down notecard

Hope that helps!

3

Extremely helpful answers, thanks!

Another thing I noticed is that if I send a message with 500 characters I get the response

2024-01-09T20:21:44.773Z [MS] [ERROR] Message size is too large!
2024-01-09T20:21:44.773Z [BM_TX] [ERROR] Unable to submit message to sat/cell queue

Is this expected? And what exactly is the limit, so I can work to avoid it?

4

You’re very welcome!

Yes, that “too large” error is expected. The message size must be less than or equal to 340 bytes, which is the limit set by Iridium for Mobile Originated (MO) Short Burst Data (SBD) messages.

5

Perfect. That reminds me of another question - are there specific data rate limits for iridium and cellular?

6

Not that I know of. Throughput mostly depends on signal strength. We try to abstract this from you so you just queue up the messages, and we’ll get them sent eventually. However, if you fill up the queue faster than messages can be sent, then beyond a certain point messages will get dropped. Your mileage will vary as far as the precise max throughput.

If you learn more through experimentation, please share!

7

Also, since this queue can end up sending over Iridium — please :warning: be careful not to send too much data that way — a monthly Iridium bill can easily run into the thousands of dollars. :moneybag:

8

The message size must be less than or equal to 340 bytes

I suspect that this limit also includes the data spotter includes by default. Is it possible to say how much data I can actually put in the “messages” field myself, if so? Also makes me wonder if it’s possible to send messages without the spotter location and other metadata on every packet.

I also wonder if I should design my protocol to try to burst many packets, once a day, vs streaming data every 5 minutes. To save battery life perhaps?

9

Actually when using spotter_tx_data you control the whole 340-byte buffer. Spotter does not add anything. Spotter sends other messages periodically that contain things like diagnostic data and locations.

Regarding brief daily burst vs trickle all the time, I’d recommend not worrying about it at this stage. It’s probably best to make sure you can iterate and learn quickly. Those kinds of optimizations can easily come later.

10

Is there no way to access the cell connection directly? i.e. is there any way to send multi Megabyte files over the cell connection?

11

Hi Peter,

First, a correction to my message above. I was wrong when I said “Spotter does not add anything.” It adds a 29-byte header with location and diagnostic info, so the max user payload is 311 bytes. See More info on "growing set of abstract parsing tools" - #8 by zachary

And then to answer your question, no, there is no way to directly access the cellular connection. The closest you can come from a dev kit is by using spotter_tx_data.

12

I’m currently planning to write my own transaction manager for sending packets larger than 311 bytes. Is that a planned feature on your end at some point? Seems like it might be broadly useful.

1 Like
13

Great idea! Thanks for offering! I’d love to see that open source so anyone could use it. We have some bespoke code on spotter and the Sofar backend to manage very specific cases of this, but nope, no general solution is on our roadmap.

14

And as a reminder about the original post in this topic from a month ago — something that is in our 2024 plan is to fully enable the cellular-only queue, which will be a better way to send large payloads and won’t have such a low limit on message size.

15

Another question while I have you. How are cellular/iridium costs managed for the devkits? Sounds like I have a 3 month free trial, but after that where can I see costs and pay for them?

16

And a follow up to that - this morning I accidentally misconfigured my bristlemouth to send data every 5 seconds instead of minutes and ran it for an hour sending on cellular. My bad!

But not it seems like my system has been rate-limited or disabled? I don’t see any data from anything I send now, even for simple txdata calls that always worked.

17

NVM - I think it was just failing to get a GPS connection

18

Hey Chris,

  1. The 3 months of Iridium credits come with a 1 year use by date
  2. The system also comes with a complimentary 1 year of cellular data
  3. You can check the status of your credits and buy more credits by logging into your spotter dashboard and checking your system settings - click here to learn more
  4. Later this year we will releasing more flexible data subscriptions so stay tuned!