Glider events run outdoors in full sunlight, so the system uses big bright LED matrix displays to show its timing information. The system, built around the STM32 Discovery platform, uses several of the microcontroller boards to drive several displays as well as the main controller which handles timing. It also packs in an audio system for issuing instructions to competitors. It can also display pilot names as well as instructions such as when competitors should land at the end of a heat.
It’s that time of year in both hemispheres — time to get outside and play before it gets unbearably hot (or cold). No matter what your game, don’t keep score in your head or with piles of rocks — make yourself a portable, fold-able scoreboard like [LordGuilly] did and be on the bleeding edge of display technology. It’s really more roll-able than fold-able, which is awesome because you get to unfurl it like a boss.
All you need is a place to hang it up and you’re good to go. This thing runs on a beefy 10,000 mAH USB power bank, and [LordGuilly] says that it’s easy to read even on really sunny days. As you may have guessed, those are WS2812 strips and they are set into rectangular PVC bars. The bars are set equidistant from each other in a frame made from modified version of cable tracks — plastic chain links for cable management.
Good looks aside, we especially like that there are two controller options here. If you want to assign a dedicated scorekeeper, there’s a handled version that uses an STM32 blue pill and is wired to the display. But if you’re short on people, use the ESP8266 version and update the score with the accompanying app. Check out the demo after the break so you can see it in action.
In a flooded mesh network every node repeats every message it receives. This has the theoretical advantage of making the network self-healing if a single node stops working, but often just means that the nodes will interfere with each other. Thanks to some characteristics of LoRa, [Dan] is using several tricks to get around this packet collision problem. LoRa network can make use of the “capture effect”, which allows a receiver to differentiate between two packets if the power level difference is large enough. This is further improved by adding forward error correction and slightly changing the frequency and timing of the LoRa chirps. QMesh also implements TDMA (Time Division Multiple Access) by splitting transmission into time slots, and only transmitting every third slot. This means it is operating on a 33% duty cycle, which is much higher than the 0.1%-10% allowed on license-free ISM-bands, which legally limits it to the ham bands.
On the hardware side, [Dan] has been using the STM32 NUCLEO-144 development boards with F4/L4/F7/H7 microcontrollers and a custom shield with a 1 W LoRa module and OLED screen. While [Dan] wants to eventually build handheld radios, he plans to first develop small FM repeaters that encode voice as codec2 and use QMesh as a backhaul. QMesh is still under development, but we would love to see the results of some long-range testing, and we are excited to see how it matures.
If your interested in a more basic LoRa-based human-to-human messaging system, take a look at Meshtastic. It’s been going very rapidly over the past year. To learn more about LoRa and other digital modulation schemes, check out the crash course we did with an SDR a while back.
It’s easy to get caught up in a build and forget that the final version usually needs some sort of enclosure, especially things with sensitive electronics in them. The [Director of Legal Evil] at the LVL1 Louisville Hackerspace notes as much in his recent radio build. It seems as though the case was indeed an afterthought, but rather than throwing it in a nondescript black project enclosure it was decided to turn the idea of a project enclosure itself inside-out.
The radio build is based on an SI4732 radio receiver which is a fairly common radio module and is easily adaptable. It needs a microcontroller to run though, so a Maple STM32 platform was chosen to do all of the heavy lifting. The build includes a screen, some custom analog controls, and a small class D audio amplifier, but this is the point it begins to earn its name: the Chaos Radio. While playing around with the project design in CAD, a normal design seemed too bland so one was chosen which makes the radio look like the parts are exploding outward from what would have been a more traditional-style enclosure.
While the project includes a functioning radio receiver, we have to complement the creator for the interesting display style for this particular set of hardware. It can get boring designing the same project enclosures time after time, so anything to shake things up is often welcomed especially when it puts all of the radio components on display like this. In fact, it’s reminiscent of some of [Dmitry]’s projects, an artist known for deconstructing various common household appliances like this CD Player.
Deciding to go for a full digital design for the circuitry, the peripheral is based off of a MEMS microphone and an STM32 microcontroller doing the heavy lifting between it and a USB connection. [Andy] notes that MEMS microphones are very delicate and you have to design the PCB around the hole where the sound enters, which is why he went with a breakout board which has the component already soldered onto it.
As for the MCU, he reasons that since this is a off-one project which won’t be produced in large numbers, the 180 MHz ARM core shouldn’t be seen as overkill, since it also gives him more than plenty of headroom to do signal processing to make the sound clearer before sending it through to a computer by the USB audio device descriptor.
Once the components are chosen and the board designed, [Andy] goes into detail explaining the firmware he wrote for the STM32 to translate the PCM samples from the microphone’s I²S interface into a format better suited for the computer. He also describes how it then processes the audio, applying a graphic equalizer to reduce noise and then ST’s own Smart Volume Control filter, which works more like a compressor than a simple amplitude multiplication.
Finally, all files for the project, including board gerbers and the STM32 firmware are available at the bottom of his post, and to boot, a video demonstrating the project which you can check here after the break. [Andy]’s choice of microcontroller for this project is no surprise to us, given he’s already made his own development board for the STM32 G0 series. But if this digital microphone project is a bit too modern for you, why not try your hand at building a ribbon microphone instead?
The release of the Raspberry Pi Foundation’s Raspberry Pi Pico board with RP2040 microcontroller has made big waves these past months in the maker community. Many have demonstrated how especially the two Programmable I/O (PIO) state machine peripherals can be used to create DVI video generators and other digital peripherals.
Alongside this excitement, it raises the question of whether any of this will cause any major upheaval for those of us using STM32, SAM and other Cortex-M based MCUs. Would the RP2040 perhaps be a valid option for some of our projects? With the RP2040 being a dual Cortex-M0+ processor MCU, it seems only fair to put it toe to toe with the offerings from one of the current heavyweights in the 32-bit ARM MCU space: ST Microelectronics.
Traditionally, 3D printer control boards have used simplistic 8-bit microcontrollers to command the stepper drivers and ultimately move the machine where it needs to go. Newer boards have switched over to 32-bit microcontrollers, but they’re still relatively limited computationally. Because of this, a Raspberry Pi running OctoPrint is usually used to provide more complex features such as remote management and live video.
Looking to combine these different devices into a single all-in-one board, [pkElectronics] developed the Sigmoid S7P. With an STM32 microcontroller, TMC2209 stepper drivers, a Raspberry Pi Compute Module 4, and plenty of room for expansion, it promises to be a drop-in upgrade for essentially any 3D printer running on an open source firmware that could be ported over.
According to [pkElectronics], the idea for the Sigmoid had been floating around for several years, but never got off the ground due to the difficulties in dealing with the SO-DIMM interface used by previous iterations of the Compute Module. But with the switch to smaller and denser connector for the CM4, the board finally started to take shape.