Of all the horrors visited upon a warrior, being captured by the enemy might count as the worst. With death in combat, the suffering is over, but with internment in a POW camp, untold agonies may await. Tales of torture, starvation, enslavement and indoctrination attend the history of every nation’s prison camps to some degree, even in the recent past with the supposedly civilizing influence of the Hague and Geneva Conventions.
But even the most humanely treated POWs universally suffer from one thing: lack of information. To not know how the war is progressing in your absence is a form of torture in itself, and POWs do whatever they can to get information. Starting in World War II, imprisoned soldiers and sailors familiar with the new field of electronics began using whatever materials they could scrounge and the abundance of time available to them to hack together solutions to the fundamental question, “How goes the war?” This is the story of the life-saving radios some POWs managed to hack together under seemingly impossible conditions.
Benchmarks often get criticized for their inability to perfectly model the real-world situations that we’d like them to. So take what follows in the limited scope that it’s intended, and don’t read too much into it. [Joonas Pihlajamaa]’s experiments with toggling a hardware pin as fast as possible on different single-board computers can still show us something.
The take-home result won’t surprise anyone who’s worked with a single-board computer: the higher-level interfaces are simply slow compared to direct memory-mapped GPIO access. But really slow. We’re talking around 5 kHz from Python or any of the file-based interfaces to the pins versus 3 MHz for direct access. Worse, as you’d expect when a non-realtime operating system is in the middle, there are glitches on the order of ten milliseconds with all the file-based methods.
This test only tells us so much, though, and it’s not really taking advantage of the BeagleBone Black’s ace in the hole, the PRUs — onboard hardware processors that bring real-time IO capabilities to the system. We’d like to see a re-write of the code to take advantage of libpruio, for instance. A 20 MHz square wave is a piece of cake with the PRUs.
Of course, it’s not interacting, which is probably in the spirit of the benchmark as written. But if raw hardware speed on a BeagleBone is the goal, it’s likely that the PRUs are going to feature prominently in the solution.
Smart Energy GB are the organisation campaigning for the roll-out of smart energy meters in the UK. Publicizing smart meters and making traditional electricity and gas meters look obsolete is part of their mission, and towards the end of last year they came up with a novel idea. “Requiem for Meters”, is a piece of orchestral music performed on instruments made from old gas and electricity meters, and recorded by the Royal Philharmonic Orchestra at the famous Abbey Road Studios in London.
The old meters serve as much as artworks in some of the instruments as they do a function. As far as we can see for example the gas meter violins are electric instruments rather than acoustic, the meter serving only as the physical body of the instrument rather than as an acoustic cavity in the way the body of a traditional violin does. The wind instruments seem to incorporate the cavity of a gas meter in their construction though and the percussive instruments are very much dependent on the properties of the meters themselves, though we’ll leave it to the reader to decide whether the resulting sound is one you’d want regularly on your hi-fi.
The video below the break shows some of the background to the piece, though sadly not as much instrument building detail as we’d like.