Hello Bristlemouth team,
I am currently attempting to view data that I sent over the Spotter API but am not seeing anything. We are trying to send a Base64 buffer using the spotter_tx_data line shown in guide 5. When running the code and looking at the Bristlemouth console, we see the message saying that is has successfully transmitted data to the Spotter: show in the picture below.
After putting that API token into the Bristlemouth UI website and putting in our Spotter ID (SPOT-31430C), we were expecting to see the data we transmitted but do not.
Are there any steps we are missing or could do resolve this issue?
Hey there. I might be able to help you. Let’s walk through the API data retreival part of Guide 5 to see where you’re getting stuck…
I’d start by determining whether or not you are expecting GPS signal (this would be open to the sky, no obstructions, or maybe if you’re lucky near some very large windows on a few sides).
You will see the data on the sensor-data API endpoint if you do have GPS.
I’d also make sure your API token is working correctly. Are you able to grab data from Spotter normally as per the API docs?
You can also check the logs on the SD card, xxxx_MS.log to see if the message is transmitting successfully as intended ( I think your output shows that it is based on the way you wrote the help text, great job…but it’s nice to validate that the Spotter actually sent the message ).
Hey, thanks for the response.
With your help, we were actually able to resolve the issue! The issue was with our buffer being too large for the spotter. We found this out by looking at the xxxx_MS.log on the SD card. After reducing the size of that we now see the data on the Bristlemouth UI.
While we are successfully able to see data on our dashboard, we are working on optimization to send the most amount of data at once.
Currently we are using a payload buffer. We check to see if there is a new line of data available from UART and then read it into the payload buffer. strcmp(payload_buffer, fileStart) checks if the received line matches the fileStart marker, which indicates the start of a file-saving process.
If the data matches fileStart, the variable saving_file is set to 1, indicating that the following data should be treated as part of the file. When the content of payload_buffer matches fileStart, the system enters “file-saving mode” (saving_file = 1), indicating that subsequent lines of data received are part of the file. With that, we use spotter_tx_data to send the data through cellular so we can see it on the dashboard.
The questions we had was if we can use the SD card as a middle man in sending our data. Instead of going straight from the bristlemouth to cellular, is there a way we can have cellular listen for data from the SD card instead of getting it straight from our buffer? Is there a way the Spotter can read the SD card and send it through cellular automatically? How does the Spotter transmit its own data automatically? That way we can send a lot more bytes at once. We currently have 128 bytes sending at once so if we can use the SD card, it would make things much faster.
Another question we had, not really related to the issue above but still an issue: the 5Volt on our board is not working. Where do we go for a RMA request?
I am following up to see if the Bristlemouth team has any recommendations on what we can do to optimize our data. We have been tinkering with the parameters a little bit but we are just wondering if there is any other solution.
Right now there’s no way to use the SD card as an intermediate stage before sending to cellular. It sounds like a great feature, but would require lots of work on the Spotter firmware.
Luckily this is a community about open standards, and you or anyone could make a Bristlemouth telemetry module that functions differently.
I can imagine a more medium-term (instead of long-term) feature that I can put in the backlog and discuss with our product team — adding the ability to read files from Spotter’s SD card from a Bristlemouth module. Right now we can only write, which was necessary for logging.
Regarding how to optimize throughput, I have 2 suggestions.
The max payload size for spotter_tx_data is 311 bytes. Make the messages exactly that size (or as close as you reasonably can) to reduce overhead.
If the data coming in over UART is ASCII text, you have lots to gain from compression! You could roll your own bitpacking or use an existing embedded compression library.
Rolling your own bitpacking might be as simple as using 7-bits per character instead of 8 (since ASCII codes are only 0-127), which would get you 355 characters in a telemetry message instead of 311. You could also get more complicated and crafty with this depending on the particular content you need to send.
In a quick search for embedded compression libraries, I find these results, and I’m sure there are plenty more:
You may simply need to enable it in code as mentioned in this topic, for example in your setup function:
bristlefin.enableVbus();
bristlefin.enable5V();
// Wait for Vbus to stabilize before enabling Vout
vTaskDelay(pdMS_TO_TICKS(5));
bristlefin.enableVout();
If it turns out to be something else, please start that discussion as a new topic on the forum with a longer description of how you’re testing and what you observe.
