A Network Status Panel The Way It Should Be

Sometimes a project forms itself around a component rather than an idea, and thus it was that [Maximilien] found himself building a data rate monitor for the connection between two data centers. Some MD0657C2-R LED dot matrix displays for not a lot needed a project.

The displays are mounted in groups of four on small PCBs, driven by a MAX6952, which are then controlled by a Pi Pico. There are several display panels in the project, each of which is a pained and laser-etched acrylic sheet with a pair of the LED boards mounted behind it. These in turn go on the front of a wooden enclosure, with a set of LED ring lights behind to illuminate the etched parts of the panels. Each display panel has its own Pico, daisy chained together and driven by a Pico W that supplies network connectivity.

As you might expect, this isn’t the first status panel we’ve brought you over the years.

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.