sbts-aru VS rpi-open-firmware

My project, sbts-aru,

https://github.com/hcfman/sbts-aru

uses a GPS to synchronise the time with and then even when running completely disconnected from any network the clocks will be accurate to real time with less than 1 microsecond of error. Typically the system time hovers around 100 ns or less from the real time. And I’ve tested this by triggering interrupts on gpio’s on two devices with the same switch and printing the time.

Nice to see people able to use tech to help reduce/manage their stress/trauma in such horrific situations.

Good point about telegram. As much local control as possible is desirable. Do the text to speech interfaces work offline with the chosen devices ? If so, I’ll likely have a play.

I have a project that might be able to help with your situation. A Raspberry Pi based sound localization system. It’s very accurate. Last weekend I localized an explosion (fireworks) to within 20m from the actual location with 4 recorders. two of which were 3km from each other.

Unlike most ARUs (autonomous recording units) which are based on microcontrollers and need post processing to determine an event start time, the Pi system could be used as the basis for a real time localization system as the system times is sub microsecond accurate.

With likely a small amount of new development and co-operation with your friends you could be alerted in real time when artillery or gunfire is getting close to you. Along with a map location of where it was fired from

My license forbids government use (attaching consequences to the small developer unfriendly cyber resilience act that is stealing from small developers and giving to rich ones) but personal civilian use is just fine.

https://github.com/hcfman/sbts-aru

(PS. I agree on with the sentiments of the above authors about war. It’s sad that our governments instead of putting everything into driving to peace are spending our future climate change defence money on destruction and they are gunning for it with an insane appetite)

Nice article and lovely piece of kit that one from sparkfun. Will likely be getting one next year to further my experiments with gunshot localization, on my Pi-based sound localization platform (https://github.com/hcfman/sbts-aru). Though at the distances I'm using the phone based GNSS seems to be working quite well.

With an RTk GNSS though I could do some experiments with localizing bat calls. I've tested the Pettersson Ultrasonic microphones with my localization platform and that works fine. I suspect that the bat localization I could achieve if my co-ordinates had RTK accuracy would be pretty damned good! But I have to try it to know.

Unfortunately a Raspberry Pi is a bit ill suited for production environments. Id recommend an RTC module. Otherwise this might be helpful: https://github.com/hcfman/sbts-aru

If you install my sbts-aru project

https://github.com/hcfman/sbts-aru

It will shrink your partitions, add news and install one of these and set up a sub micro second system clock and an audio recorder suitable for sound localization with a single install command.

I recommend primo EM272 microphone capsules for use with https://github.com/hcfman/sbts-aru. They are high quality, very sensitive with high signal to noise ratio, lauded for nature recording use cases. They can be bought assembled for around 65 euros in the Netherlands. However these capsules are often found in much more expensive equipment.

My sound localizing Raspberry Pi installs a resilient base system as part of its install.

https://github.com/hcfman/sbts-aru

https://hackaday.com/2023/12/30/localizing-fireworks-launche...

With one command it for all Pi’s for both Raspbian and bookworm it:

* Shrinks the file system (Gee, how does it do that with just one disk ? ;-) )

I have a sound localization project that can help with that

https://github.com/hcfman/sbts-aru

You need to be able to hear the sound from three or more recorders. And normally localization is better within the polygon of microphones but there’s an area of better localizability extending outside of a vertex.

Interesting history!

And while we are in the subject of sound localizing may I take the liberty of introducing my new raspberry pi sound localizing audio recorder.

https://github.com/hcfman/sbts-aru

It installs with one command on all Raspberry Pi versions and synchronizes the system time to less than 1 microsecond of error with a cheap GPS.

With three of these I’ve been able to sound localize the explosions from illegal fireworks to a specific car park from more than 3km away with lots of houses in between.

When I got to the car park I could smell the sulphur from the fireworks.

This will even run on a Raspberry Pi zero running of a battery with a 6 euro neo 7m gps and a 6 euro usb mic.

Very nice tool!

So grab a spare Raspberry Pi, a GPS, a cheap USB sound card and a mic and get recording with this Pi based Acoustic Recording Unit

https://github.com/hcfman/sbts-aru

And while you are at it, install 3x or more and localize where the birds are.

Comment by the developer who attempted to create open firmware, https://github.com/christinaa/rpi-open-firmware/issues/37

> a lot of corners were cut to save time leading to what I believe is poor ARMv7+ Cortex IP integration (GIC, TrustZone, etc). So I stopped working on it. If those things were not the case (GIC working, "TZPCs" working, security working as intended, instead of NS forced to high on bridge, at least in my understanding) I would still work on it ...

ARM isn't a second class citizen on this platform, it's a third class citizen since BCM2709 (again this is an opinion) ... the features I wanted to tinker with the most are absent by design (cutting corners) and I'm not willing to resort to SW emulation of them through clever uses of the VPU.

Sure, and it's been done: https://github.com/christinaa/rpi-open-firmware - but that doesn't involve ThreadX source, just some standard reverse engineering work. ThreadX is really the least interesting part of this whole operation in terms of the Raspberry Pi.

It's very cool that ThreadX has been open sourced as it offers an additional battle tested and mature alternative to FreeRTOS for new projects, but in terms of reverse engineering or open sourcing the Raspberry Pi VideoCore blob, it's pretty much a non-event IMO.

I guess you are thinking of this issue:

https://github.com/christinaa/rpi-open-firmware/issues/37

Since then the project moved to a new maintainer (not me), who worked on it slowly but surely. They need new contributors though.

They have (https://github.com/christinaa/rpi-open-firmware). The problem is that almost nothing works (no video or even USB). The sequel to "f you, NVIDIA": f you, Broadcom.

> no clue if there's a project to reimplement that

There was! And it even booted Linux in some capacity: https://github.com/christinaa/rpi-open-firmware

> every chip is very different from one another

Eh, the usual embedded SoCs are not that different from each other — ARM GIC, ARM timer, lots of Synopsys Designware crap for SDMMC/XHCI/PCIe/etc.

For many SoCs it's totally feasible to make standards-compliant firmware, e.g. for the Rockchip RK3566 there is https://github.com/jaredmcneill/quartz64_uefi

And SoCs from the networking world (Marvell, NXP) are typically supported by upstream EDK2.

from 2018: Is this project dead? KB - No not dead but on hold, see my response · Issue #37

https://github.com/christinaa/rpi-open-firmware/issues/37