Yep, your scenario works and it's completely possible and plausible.
Messages are extremely small and efficient OTA (highly optimized and compressed).
The API is JSON and messages are your own unconstrained JSON object, but they're transmitted as compressed binary. (You can also have a binary payload 'attachment' to a JSON message if you so choose.)
Although everything works fine if the messages are individually in the KB's, that's not the design center because of how we manage memory on our (STM32L4R5) MCU.
Things work most efficiently when the app uses lots of small messages. We buffer them in flash, and power-on the modem at user-settable intervals (or conditions) for upload.
The 500MB - is that per month - or once for the lifetime of the 10-year cell-"contract" of the card? (if once, how refill once depleted?)
THANK YOU FOR DOING THIS!.
(Also, while at Lockheed, our division was one of the early adopters of Groove. Sadly, we had factions who loved it and wanted to use it and factions who didnt want to change their workflows. -- As the head of IT, I liked it, although it had some quirks... it was too bad we didnt "find our groove" with Groove at the time. But the vision behind it was dope.)
I'm having a hard time finding out the physical dimensions of the cards. Can't see anything in the data sheet about that?
I'd like to know how small a configuration with a Notecard + carrier can be?
For sewing into a kids backpack I think it looks like it will be small enough, but in my mind, putting a tracker inside a shoe would be much better. A backpack is easily forgotten or lost somewhere, but shoes tend to stay with the person. However, to put it in a shoe it'd have to be pretty small.
Long time no chat! Haven’t talked to you since a couple years after Microsoft acquired Groove.
This is really cool, but I don’t see any information on costs if you go over the 500mb of cellular data. Probably missed it, but I did click around a lot trying.
A heads-up: I have been told flash wear can be a problem for such a use case if you always start writing records from the same address after transmitting the buffer. :)
Messages are extremely small and efficient OTA (highly optimized and compressed).
The API is JSON and messages are your own unconstrained JSON object, but they're transmitted as compressed binary. (You can also have a binary payload 'attachment' to a JSON message if you so choose.)
Although everything works fine if the messages are individually in the KB's, that's not the design center because of how we manage memory on our (STM32L4R5) MCU.
Things work most efficiently when the app uses lots of small messages. We buffer them in flash, and power-on the modem at user-settable intervals (or conditions) for upload.