I miss this style of quirky magazine layouts. The web has made everything follow the same 12 column grid template with just one or two sans-serif fonts.
Not sold, but shared internally across multiple clients with no functional opt out: Once Democratic party digital firms like NGPVAN and ActBlue get your email, be prepared to get multiple emails per day from candidates across the country you've never heard of (much less could even vote for) constantly sending you garbage emails. The unsubscribe buttons do nothing.
I'm curious if there's a site tracking new software for vintage platforms such as ssheven which is a modern SSH client for Mac OS 7/8/9. For the occasional retrocomputing enthusiast, it'd be great to have a dedicated resource tracking all the great new work the community is producing. (And a way to also collaborate/give back via open source.)
That's a great idea! And thanks for the tip on ssheven, I have an OS 9 machine I've gotten networked but having a devil of a time getting any network client software onto it without a lot of floppy hoop-jumping, and scp would be real handy.
History repeats itself. Check out the story of the Molly Maguires, a somewhat vigilante labor group in PA's coal region, who were infiltrated by an undercover Pinkerton in the late 1800s: https://en.wikipedia.org/wiki/Molly_Maguires#In_the_United_S... I'm from the region of PA where this all happened, and it's a well-known story among locals.
Good idea! I'd want to do some research and simulations to figure out how much of an altitude hit I'd take with the added weight of an additional controller.
This[0] is the ESP32 module that I keep on hand. The seller doesn't list any information that would help with your simulations, but the photos can give you a rough idea of the physical size. Other than a bare ESP32 module[1] I don't think I've seen a physically smaller ESP32 board.
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.
I've used TinyPICO Esp32 modules. They're even smaller than D1 Minis! They lack the metal cover, though I don't quite know what that's for (mumble EMI?).
Looks like the pocketbeagle has two 'programmable real-time units' PRUs @200MHz which could be used to run the sensors while the main CPU handles video+I/O. Could be a good option for 'multithreading' without having to insert another module. (caution: I've kept to the rpi for weird little side projects, so haven't actually tried this. Double super big caution: Never add hardware before profiling your current system to figure out where the bottleneck is... it might just be a matter of changing your 'main loop' a bit.)
I'm still somewhat annoyed that didn't lead to a complete blackballing of Swarm. A <$1M fine for a VC-funded space start-up actually doesn't seem that large, and I bet they probably saved a bunch of money by not following the proper procedures anyway, which lowers the actual impact of that fine anyway. It sets a bad precedent for other New Space companies that might be looking for a shortcut.
I'm not totally certain. I could do a quick C++ POC to see if that improves throughput a bit, but I've got doubts. My other thought is that the SPI interface only can go up to a certain speed. If anyone has deeper knowledge of that protocol I'd love to hear their thoughts.
You should try doing some profiling on each part of your system and find where the bottlenecks are.
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.
Yeah, this is the source code: https://github.com/URSolarSplash/Telemetry-Server. The version uploaded there is transmitting at ~4hz but we cranked it up to a much faster transmit loop when necessary. A few interesting files:
In classic "college engineering project" fashion, the project is rather disorganized and very specialized to the technology we used on our boat at the time. Our telemetry server had an in-memory cache of latest data points which were relayed over serial with all the telemetry nodes. We used the telemetry system to carry throttle and all other control signals for the boat. We replicated all the data points to a secondary server running on a shore computer, so we had two separate sources of data logs.
I will note that since building that system, my philosophy has changed several times -- Today, I would likely not roll our own telemetry protocol, instead using something like https://msgpack.org/index.html or going all-in and using ROS on a larger project.
If you're interested in chatting more, feel free to send me an email (my username @ gmail). It's always great to see others go through the same experimental process with telemetry and data collection systems! (Also, check out bps.space on youtube, who has done a lot with telemetry on model rockets.)
I would have thought that the max SPI speed on the Pi is probably faster than your peripherals can deal with. Your bigger problem is system interrupts which might cause discontinuous capture. The speed is derived from the core clock which can go to well over 100MHz.
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.
Donkeycar might give you some ideas... it logs still images with a RaspberryPi camera module. The frames can be stitched into video afterward (though maybe lower frame rate/resolution than what you want). If it crashes, logged frames are on disk.
