Is this because my power to weight ratio is so much lower?
Back when I was involved with some of the higher power aspect of the hobby(J/K/L/M class) we'd go our to the desert where retrieval was a lot easier. Even out M class stuff rarely topped 1500ft.
Minimum diameter can go much, much higher but usually your flight waiver has a fixed ceiling that you don't want to exceed.
... and I also had a 400 ft limit with my permit.
Bigger stuff is fun but also hits the pocketbook a little bit more.
At first, I had some questions about why you'd use a Raspberry Pi for this, but once I realized that video was being recorded as well it made more sense. I'm quite impressed.
For increasing sample rate, it really depends on where the problem is. The Pi is recording video and managing the sensors - are these two tasks competing with each other?
Perhaps using another controller to deal with the sensors and telemetry transmission could help (if contention is actually the problem). Something like the ESP32 in the D1 Mini form factor would easily fit in the rocket. If I was doing this, I'd ignore the ESP32's onboard radios and use the LoRa module since it seems to work quite well in this application.
[0] https://johnjonesfour.com/2020/10/03/model-rocket-telemetry-...
You can program these with the Arduino IDE, so they're quite easy to use and there are tons of libraries available for interfacing with sensors, etc.
Would that really improve data capture ? How much throughput is it captured that python can't keep up (is that even the right kind of questions) ?
anecdotally, I built a telemetry system for an electric boat with very similar architecture (RPi, python script for telemetry collection, 433Mhz telemetry radio) and were pretty easily able to push on the scale of ~100 data points at 100hz. Part of that was efficiently (and manually) packing each data point into the minimum space required, pretty much just the raw data and a checksum. But from what you’re describing I definitely think you can push your system further without rewriting significantly.
Control of the bus is probably handled by kernel drivers anyway, so you're not doing much overhead with Python.
Also make sure you use hardware video encoding. I don't know if the picamera library does, but worth checking. I normally use OpenCV with the omxh264 encoder. You could also run a gstreamer pipeline in parallel with your air code.
Edit: looking at you pipeline you use the lsm303 which is I2C not SPI? So that's 400khz max. And the Bosch BMP something which isn't designed for rapid measurements - even if it's over SPI they output of the chip will be your limit there.
You mention using Adafruit libraries & working in Python. The Adafruit feather boards focus on low power situations & some include battery slots. https://www.adafruit.com/feather
Artemis seems to be Sparkfun’s new line of Feather-compatible boards. They target a pro-level audience vs Feather’s edu audience. The OpenLog Artemis looks interesting for logging telemetry. https://www.sparkfun.com/news/tags/artemis
>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 :-)
YITBOS
(For the rest of the world who's confused by this: college fraternity colors.)
I flew it yesterday with a Quectel L-80/MediaTek 3339 chipset, seems to have performed fairly well. https://forum.ausrocketry.com/viewtopic.php?f=32&t=6547
