Hi, do you have technical details for that? I don't really see any.
>There must be a buffer that holds a certain amount of camera footage before saving it to disk. Because the battery disconnected in-flight, no flight video saved. I'd like to figure out how to write video data more frequently in case the battery issue happens again.
Disk or SD card?
I'm seeing RSSI. What signal are you measuring the strength of? Given that you talked about problems losing footage and buffering, I suppose you are not transmitting in near real-time but instead save to disk and get the data afterwards? Given that you have a link, why not send the video stream to your ground station directly?
I worked with Raspberry PI to acquire data from fitness trackers with Bluetooth Low Energy (BLE), then transmit using 4G dongles. We serialized the data into protobufs and used Kafka in the backend. We also used the setup for other things.
>The software performed well, but I'd still like to increase the data capture rate. There are Adafruit libraries for the components I'm using in C++, so I'm considering rewriting air.py in C++, but I'd really love it if someone talked me out of that.
I don't think you have to re-write anything in C++. I'm pretty sure the bottleneck is not the language.
For the video issue, I need to do some homework and figure out what the issue is. It's just speculation at this point. Yes, I am saving the Pi's microSD card.
Telemetry transmission and reception is done by an Adafruit RFM95W, and I'm using this library to interface with it: https://github.com/adafruit/Adafruit_CircuitPython_RFM9x. It handles data just as Python byte arrays, and I only transmit data from the senors (in real time) but not video. I use that library to determine RSSI as well.
Thanks for the note on the language idea. Like I said in the post, I want to be talked out of that :-)
>There must be a buffer that holds a certain amount of camera footage before saving it to disk. Because the battery disconnected in-flight, no flight video saved. I'd like to figure out how to write video data more frequently in case the battery issue happens again.
Disk or SD card?
I'm seeing RSSI. What signal are you measuring the strength of? Given that you talked about problems losing footage and buffering, I suppose you are not transmitting in near real-time but instead save to disk and get the data afterwards? Given that you have a link, why not send the video stream to your ground station directly?
I worked with Raspberry PI to acquire data from fitness trackers with Bluetooth Low Energy (BLE), then transmit using 4G dongles. We serialized the data into protobufs and used Kafka in the backend. We also used the setup for other things.
>The software performed well, but I'd still like to increase the data capture rate. There are Adafruit libraries for the components I'm using in C++, so I'm considering rewriting air.py in C++, but I'd really love it if someone talked me out of that.
I don't think you have to re-write anything in C++. I'm pretty sure the bottleneck is not the language.