Screen shot of Mongoose Wizard.

How To Build An STM32 Web Dashboard Using The Mongoose Wizard

Today from the team at Cesanta Software — the people who gave us the open-source Mongoose Web Server Library and Mongoose OS — we have an article covering how to build an STM32 web dashboard.

The article runs through setting up a development environment; creating the dashboard layout; implementing the dashboard, devices settings, and firmware update pages; building and testing the firmware; attaching UI controls to the hardware; and conclusion.

The web dashboard is all well and good, but in our opinion the killer feature remains the Over-The-Air (OTA) update facility which allows for authenticated wireless firmware updates via the web dashboard. The rest is just gravy. In the video you get to see how to use your development tools to create a firmware file suitable for OTA update.

Continue reading “How To Build An STM32 Web Dashboard Using The Mongoose Wizard”

Various hardware components laid out on a workbench.

Working On Open-Source High-Speed Ethernet Switch

Our hacker [Andrew Zonenberg] reports in on his open-source high-speed Ethernet switch. He hasn’t finished yet, but progress has been made.

If you were wondering what might be involved in a high-speed Ethernet switch implementation look no further. He’s been working on this project, on and off, since 2012. His design now includes a dizzying array of parts. [Andrew] managed to snag some XCKU5P FPGAs for cheap, paying two cents in the dollar, and having access to this fairly high-powered hardware affected the project’s direction.

Continue reading “Working On Open-Source High-Speed Ethernet Switch”

Quantum Random Number Generator Squirts Out Numbers Via MQTT

Sometimes you need random numbers — and properly random ones, at that. Hackaday Alum [Sean Boyce] whipped up a rig that serves up just that, tasty random bytes delivered fresh over MQTT.

[Sean] tells us he’s been “designing various quantum TRNGs for nearly 15 years as part of an elaborate practical joke” without further explanation. We won’t query as to why, and just examine the project itself. The main source of randomness — entropy, if you will — is a pair of transistors hooked up to create a bunch of avalanche noise that is apparently truly random, much like the zener diode method.

In any case, the noise from the transistors is then passed through a bunch of hex inverters and other supporting parts to shape the noise into a nicely random square wave. This is sampled by an ATtiny261A acting as a Von Neumann extractor, which converts the wave into individual bits of lovely random entropy. These are read by a Pi Pico W, which then assembles random bytes and pushes them out over MQTT.

Did that sound like a lot? If you’re not in the habit of building random number generators, it probably did. Nevertheless, we’ve heard from [Sean] on this topic before. Feel free to share your theories on the best random number generator designs below, or send your best builds straight to the tipsline. Randomly, of course!

Bits of GRUB syntax on pink background

Wake, Boot, Repeat: Remote OS Selection With GRUB And ESP

What do you do when you need to choose an OS at boot but aren’t physically near your machine? [Dakhnod]’s inventive solution is a mix of GRUB, Wake-on-LAN (WOL), and a lightweight ESP8266 running a simple HTTP server. In the past, [dakhnod] already enlightened us with another smart ESP hack. This one’s a clever combination of network booting and remote control that opens up possibilities beyond the usual dual-boot selector.

At its core, the hack modifies GRUB to fetch its boot configuration over HTTP. The ESP8266 (or any low-power device) serves up a config file defining which OS should launch. The trick lies in adding a custom script that tells GRUB to source an external config:

#!/usr/bin/env cat 
net_dhcp 
source (http,destination_ip_or_host:destination_port)/grub/config

Since GRUB itself makes the HTTP request, the system needs a running web server. That could be a Raspberry Pi, another machine, or the ESP itself. From there, a WOL-enabled ESP button can wake the PC and set the boot parameters remotely.

Is it secure? Well, that depends on your network. An open, unauthenticated web server dishing out GRUB configs is risky, but within a controlled LAN or a VLAN-segmented environment, it’s an intriguing option. Automation possibilities are everywhere — imagine remotely booting test rigs, toggling between OS environments for debugging, or even setting up kiosk machines that reconfigure themselves based on external triggers.

For those looking to take it further, using configfile instead of source allows for more dynamic menu entries, although it won’t persist environment variables. You could even combine it with this RasPi hack to control the uptime of the HTTP server. The balance between convenience and security is yours to strike.

If you’ve got your own wild GRUB customisation, let’s hear it!

Networking History Lessons

Do they teach networking history classes yet? Or is it still too soon?

I was reading [Al]’s first installment of the Forgotten Internet series, on UUCP. The short summary is that it was a system for sending files across computers that were connected, intermittently, by point-to-point phone lines. Each computer knew the phone numbers of a few others, but none of them had anything like a global routing map, and IP addresses were still in the future. Still, it enabled file transfer and even limited remote access across the globe. And while some files contained computer programs, others files contained more human messages, which makes UUCP also a precursor to e-mail.

What struck me is how intuitively many of this system’s natural conditions and limitations lead to the way we network today. From phone numbers came the need for IP addresses. And from the annoyance of having know how the computers were connected, and to use the bang notation to route a message from one computer to another through intermediaries, would come our modern routing protocols, simply because computer nerds like to automate hassles wherever possible.

But back to networking history. I guess I learned my networking on the mean streets, by running my own Linux system, and web servers, and mail servers. I knew enough networking to get by, but that mostly focused on the current-day application, and my beard is not quite grey enough to have been around for the UUCP era. So I’m only realizing now that knowing how the system evolved over time helps a lot in understanding why it is the way it is, and thus how it functions. I had a bit of a “eureka” moment reading about UUCP.

In physics or any other science, you learn not just the status quo in the field, but also how it developed over the centuries. It’s important to know something about the theory of the aether to know what special relativity was up against, for instance, or the various historical models of the atom, to see how they inform modern chemistry and physics. But these are old sciences with a lot of obsolete theories. Is computer science old enough that they teach networking history? They should!

It’s IP, Over TOSLINK!

At the recent 38C3 conference in Germany, someone gave a talk about sending TOSLINK digital audio over fiber optic networks rather than the very low-end short distance fibre you’ll find behind your CD player. This gave [Manawyrm] some ideas, so of course the IP-over TOSLINK network was born.

TOSLINK is in effect I2S digital audio as light, so it carries two 44.1 kilosamples per second 16-bit data streams over a synchronous serial connection. At 1544 Kbps, this is coincidentally about the same as a T1 leased line. The synchronous serial link of a TOSLINK connection is close enough to the High-Level Data Link Control, or HDLC, protocol used in some networking applications, and as luck would have it she had some experience in using PPP over HDLC. She could configure her software from that to use a pair of cheap USB sound cards with TOSLINK ports, and achieve a surprisingly respectable 1.47 Mbit/s.

We like this hack, though we can see it’s not entirely useful and we think few applications will be found for it. But she did it because it was there, and that’s the essence of this game. Now all that needs to happen is for someone to use it in conjunction with the original TOSLINK-over network fiber, for a network-over-TOSLINK-over-network abomination.

38C3: It’s TOSLINK, Over Long Distance Fibre

If you’ve owned a CD player or other piece of consumer digital audio gear manufactured since the 1980s, the chances are it has a TOSLINK port on the back. This is a fairly simple interface that sends I2S S/PDIF digital audio data down a short length of optical fibre, and it’s designed to run between something like a CD player and an external DAC. It’s ancient technology in optical fibre terms, with a lowish data rate and plastic fibre, but consider for a minute whether it could be adapted for modern ultra-high-speed conenctions. It’s what [Ben Cartwright-Cox] has done, and he delivered a talk about it at the recent 38C3 event in Germany.

if you’ve cast you eye over any fibre networking equipment recently, you’ll be familiar with SFP ports. These are a standard for plug-in fibre terminators, and they can be had in a wide variety of configurations for different speeds, topographies, and wavelengths. They’re often surprisingly simple inside, so he wondered if he could use them to carry TOSLINK instead of a more conventional network. And it worked, with the simple expedient of driving an SFP module with an LVDS driver to make a differential signal. There follows a series of experiments calling in favours from friends with data centre space in various locations around London, finally ending up with a 140 km round trip for CD-quality audio.

It’s an interesting experiment, but perhaps the most value here is in what it reveals to us about the way optical networking systems work. Most of us don’t spend our days in data centres, so that’s an interesting technology to learn about. The video of the talk itself is below the break.

Continue reading “38C3: It’s TOSLINK, Over Long Distance Fibre”