Streaming Video From An ESP32

The ESP32, while first thought to be little more than a way of adding wireless capabilities to other microcontrollers, has quickly replaced many of them with its ability to be programmed as its own platform rather than simply an accessory. This also paved the way for accessories of its own, such as various sensors and even a camera. This guide goes over taking the input from the camera and streaming it out over the network to multiple browsers.

On the server side of things, the ESP32 and its attached camera are set up with MQTT, a lightweight communications protocol which uses a publish/subscribe model to send information. The ESP32 is configured to publish its images only, but not subscribe to any other nodes. On the client side, the browser runs a JavaScript program which is able to gather these images and stitch them together into a video.

This can be quite a bit of data to send out over the ESP32’s compact hardware, so there are some tips and tricks for getting more out of these little devices, including using an external antenna for better Wi-Fi signal, or omitting it entirely in favor of Ethernet. As far as getting a lot out of a tiny microcontroller, though, leveraging MQTT really helps the ESP32 go a long way. These chips have come along way since they were first introduced; they’re powerful enough to act as 8-bit gaming consoles too.

Thanks to [Surfskidude] for the tip!

WiFi, PWM Backlight, And Graphics On Updated Chumby Kernel

For some, the Chumby was a peek at what could have been. That vision never died for [Doug Brown], and he has been working tirelessly on bringing mainline Linux kernel support to the customizable smart display. He has posted several updates but recently got graphics and the PWM backlight working.

Of course, we covered when [Doug] first started working on the new kernel, so it’s high time we revisited the progress. The WiFi hardware uses a Marvell 88W8686 chipset, which talks over the SDIO bus, so it’s a matter of convincing the libertas driver to talk to it. With a USB to Ethernet adapter, [Doug] could boot new kernels over NFS, so he didn’t have to walk over to swap the SD card. After dealing with an unhandled fault when trying to read the SDHCI_HOST_VERSION register, [Doug] had access points showing up in NetworkManager but could not connect. As a nasty hack, he temporarily removed the interrupts and switched to polling in the driver. While that worked, it would never get upstreamed. A critical interrupt was being dropped, and commands went out of sequence. A second, perhaps ugly hack, read a register after acknowledging an SDIO interrupt, which seemed to work. But it was still a hack, and [Doug] wanted something cleaner. In a blind stroke of luck, he found the errata online and noticed that it mentioned that an interrupt could be missed when a signal was asserted. After following the workaround with a lot of head-scratching and deep diving, he had a fully working WiFi driver.

Graphics were a more straightforward endeavor compared to WiFi. He enabled the simpledrm driver (similar to simplefb) but using Direct Rendering Manager. He had a working panel that could run Qt apps by adding the frame buffer to the device tree with the correct compatible string, registers, and data. However, there was a Vivante GC300 graphics accelerator onboard that he wanted to use. A driver for Vivante GPUs already exists in the kernel, but after enabling it, the driver detects the GC300 and then starts complaining. He discovered that older revisions of the GC300 (like the ones found in Chumbys) mapped registered at different addresses and didn’t set some bits in their idle registers. Of course, just loading a GPU driver isn’t quite enough. He modified an x11 server that supported Vivante accelerators to support the GC300.

For hacking purposes, [Doug] set the backlight GPIO high. While easy to see, perhaps not the best for a device meant to blend in. The PAX166 comes with PWM hardware, though confusingly, it has two PWM modes for pin 84. PWM1 and PWM2 share some common clock and reset bits in a decidedly undocumented way. PWM2 doesn’t work until you configure and then turn off PWM1. However, the backlight turned off once out of UBoot and into Linux. Linux re-initialized the hardware too quickly, causing the device to freak out. This was solved using the abrupt shutdown register.

It’s a journey through debugging, Linux internals, and device tree hackery. Perhaps the most incredible thing is that these changes are submitted for upstreaming to the Linux kernel, with many landing in Linux 6.2. While it’s a shame new Chumbys aren’t being made, making your own smart display has never been easier.

Impossible WiFi On An Ancient Mac Portable

The Macintosh Portable was possibly one of the coolest computing devices to be seen with back at the end of the 1980s, providing as it did a Mac in a slightly nicer version of the hefty luggable portables of the day than the PC world could offer. Inside was a mere 68000, but it ran Mac OS system 6 and looked light years ahead of any comparable PC in doing so.

Back in 1989 it wasn’t even the norm for a computer to have built-in Ethernet, and WiFi was still a gleam in the eye of some Dutch engineers, so how has [Joshua Stein] managed to get his Mac Portable on a wireless network here in 2023? The answer contains a few surprises.

When seeing a WiFi upgrade for a classic retrocomputer the usual expectation is that it’s done by emulating a modem connection to the Internet over a serial port. But this wireless network card is a bit different, it’s a real network card capable of being used for much more than just connecting to the Internet.

We have to admit to not knowing that there were SCSI Ethernet interfaces back in the day, and it’s one of these that he’s created. He’s building on a decade’s work in producing disk emulators for the SCSI bus, and he’s taken the code for a Raspberry Pi Pico version and adapted the SCSI driver part to interface with the onboard WiFi on a Pico W. Altogether it’s a beautiful piece of work, and you can color us impressed.

Thin Client Wysens Up To Become OpenWrt Router

For some of us, unused hardware lying around just calls to be used. It seems like [Miles Goodhew] heard the call, and wanted to put a Dell Wyse 3040 thin client to use — in this case as a wireless router. It seems simple enough. OpenWrt supports x64_64 targets, and the thin client has 2G of ram and 8G of flash. It should make for a very capable router.

And before you tell us that it’s just another computer, and that installing OpenWrt on a miniature x86 machine isn’t a hack, note that there were some speedbumps along the way. First off, the motherboard has integrated storage, with the not-very-useful ThinLinux installed, and the system BIOS locked down to prevent reinstall. There is a BIOS clear button on the system’s diminutive motherboard. With the BIOS lock out of the way, a real Linux system can be installed on the small 8 GB mmcblk device.

The next issue the the CPU. It’s an Intel Atom x5 z-series. OpenWrt won’t actually boot on that oddball, not-quite- processor, so [Miles] opted to install Fedora and test via virtualization instead. If that statement makes you do a double-take, you’re not alone. The initial explanation sounded like the mobile-centric processor was missing instructions to make OpenWrt run, but virtualization doesn’t add any instructions for a guest to use. It turns out, the problem is a missing serial port that OpenWrt uses as a debugging output by default.

After a custom OpenWrt compile, the device comes up just as you’d expect, and while it would be underpowered as a desktop, OpenWrt runs happily shuffling bits from Ethernet to wireless adapter at respectable speeds. As [Miles] points out, there’s nothing ground-breaking here, but it’s nice to have the details on re-using these machines compiled in one place. And if you too love the idea of putting OpenWrt in places where nobody intended, we’ve got you covered.

Home Network Organization Gets Out Of Hand

[SpookyGhost] has a big home network, and has taken cable management and server organization to the extreme. He has written about individual components before, but this blog post brings it all together and reviews the entire system. The networking gear is installed in a closet and mounted in a 25U tall 19-inch rack. From top to bottom, here is a brief list of the gear:

Full View of Network Equipment Rack
  • Keystone patch panels
  • pfSense Firewall / Router
  • Two Cisco Ethernet switches
  • Redundant internet connections
  • Shelf of numerous servers
  • RAID-Z2, 12 each 8 TB SCSI, media storage
  • NAS RAID, 6 ea 4 TB SAS, 2 ea 800 GB SSD
  • Video Management System, 48 TB storage
  • UPS and power distribution units

Most of the Ethernet uses 10GBASE-T and Cat6 cabling and connectors, with some interconnects use fiber optical cable and LC connectors. Unsurprisingly, as this setup grew and grew, [spooky] had to pipe in air-conditioning to the closet.

This is a serious installation, but there are plenty of good ideas for folks with less ambitious networking goals and/or requirements. We liked the swappable Keystone jacks in the patch panels, and the cable pass-through panel with a dense curtain of rubber fringe to keep things looking tidy. If you have any ideas to share on network equipment and cable management, let us know in the comments.

GrblHAL CNC Controller Based On RP2040 Pico

[Phil Barrett] designed a new CNC controller breakout board called the PicoCNC which uses the Raspberry Pi Pico RP2040 module and grblHAL. It packs a bunch of features typical of these controllers, and if you use the Pico W, you get WiFi connectivity along with USB. And if you don’t want connectivity, you can execute G-code directly from a micro SD card. The board is available in kit form, and schematics are posted on the GitHub repository above. Some of the features include four axes of motion, spindle control, limit switches, relay drivers, expansion headers, and opto-isolation.

This isn’t [Phil]’s first controller board. He also designed the grblHAL-based Teensy CNC controller breakout board, a step up from the usual Arduino-based modules at the time and boasting Ethernet support as well. According to the grblHAL site, nine different processors are now supported. There are well over a dozen CNC controller breakout boards listed as well. And don’t forget [bdring]’s 6-Pack grbl-ESP32 controller, a modular breakout board we covered a few years back. So pick your favorite board or roll your own and get moving.

PCjr WebServer Hits 2500 Hours Uptime

When [Mike] fired up his PCjr webserver back in March, he probably wasn’t expecting it to go viral. 2640 hours later, here we are! Not only has his machine run continuously for over 110 days, it also is surviving a global hug of death. All of this is thanks to some very special software.

We see lots of old machines here on Hackaday. We also see lots of minimal web servers. But we don’t see many that can run for thousands of hours, offering up to 8 simultaneous connections. Curious if jr is still up? Check brutmanlabs.org. The whole website is hosted on the 40-year-old machine. If you want to be a bit more kind, here’s a direct link to the text-only status page. While many of those hours were idle, currently lots of folks are hitting that little V20 CPU, so please give it a few seconds to respond.

The PCjr has a few upgrades — the aforementioned V20 CPU upgrade, a jrIDE sidecar, and a memory upgrade to 736 kB to name a few.  Ethernet connectivity is via a Xircom parallel port adapter – which is circa 1993.  The operating system is IBM PC DOS 5.02. One thing to note is that all these upgrades were possible back in the mid-1980’s when the PCjr was still current.  [Mike] could run the system with an MFM hard drive, an ISA ethernet card (via an adapter), and use the original CRT monitor. Older DOS versions would work too — though partition sizes would be limited. The “modern” conveniences are just to keep from wearing out vintage hardware which is quickly becoming rare.

The real glue that holds this all together is [Mike’s] own software: mTCP. mTCP is a full set of tools for running internet applications on systems running MS-DOS or a compatible OS. We’ve seen quite a few mTCP projects over the years.  [Mike] has worked tirelessly testing the software, ensuring that it is stable and reliable.

Software is never perfect though – one thing [Mike] didn’t implement is a log roller. Since he has logging turned on, the PCjr was slowly filling up its hard drive. Once the drive was full, mTCP would perform an orderly shutdown — but the uptime will be reset.  [Mike] was able to go in and switch off logging with  DOS’s DEBUG command. A live patch is not the way one would normally update software – but the fact that he was able to do it shows how deep [Mike’s] knowledge of the software goes.

[Mike] has even provided a live stream recording of the little PCjr handling requests from all over the globe.

Continue reading “PCjr WebServer Hits 2500 Hours Uptime”