For most of us the abbreviation “CRT” brings to mind a monitor or TV. But at its core it’s about the special vacuum tube that makes the images appear.

Regardless of whether it’s just a simple monochrome CRT in an oscilloscope or a full RGB CRT, the basic steps to make it work in a device remain the same. In a recent video by [Void Electronics] these steps are worked through, including the biasing at the end that is necessary to get a stable image.

A big part of installing a CRT and driving it is knowing how to read its datasheet. Much like other vacuum tube types, there are heaters, control grids and a range of voltages to get right and keep happy. Even then you can still have a situation where you must troubleshoot problems, which is also touched upon in the video. All of this is demonstrated using an RFT B6S1 CRT as the subject, including how to build your own bias circuit.

Despite calling it an “obsolete skill”, there is still a lot of demand for CRTs in vintage lab equipment, arcade restorations and far more obscure fields that still have new CRTs produced for them. Not to mention that even today CRTs have characteristics that make them competitive with flat-screen technologies.

The Bernoulli disk was a wild piece of 1980s hardware. Take a big floppy. Spin the platter at 1500 RPM just a micron or so from a read head. The airflow around that rapidly-spinning disk actually stabilizes the disk that close to the read-head via the Bernoulli effect, hence the name. Once upon a time, everybody wanted a Bernoulli Box to put under their Macintosh 512, but [Will It Work?] wanted to see how well these old drives held up to the 21st century… by using it to load games onto a WiiU. 

It’s not as crazy at is it seems. The WiiU is happy to read and write anything that looks like a USB mass storage device. The Bernoulli Box is of course pre-USB– even the later model 5 1/4″ drive [Will] is using from 1987. That means it uses SCSI, the USB of the 1980s. He’s got a 90 MB disk, though IOmega did make disks of higher capacity in that format, all the way up to 230 MB. Yes, the same iOmega of Zip-drive fame and infamy— but don’t worry, the peculiar pneumatic nature of the Bernoulli disks makes them immune to the click of death.

You might think it’s going to take a great deal of hacking and homebrew to get the WiiU talking to a SCSI drive from the 80s, but as we said in the introduction, Nintendo made this thing respect USB conventions, so all that’s needed is an SCSI-to-USB cable. Well, plus a passive SCSI 1 to SCSI 2 adapter to get the USB adapter to fit. Daisy-chaining adapters isn’t the most advanced hack, but the point isn’t how hard it was to pull off– it’s that we’re amazed it worked at all.

It doesn’t seem like the drive slows down the WiiU nearly as much as we’d expect, but then it’s not a console known for fast load times. The other suprizing detail is how much space the WiiU’s formatting sucked up, knocking the 90 MB disk down to only 68 MB– combine that with the WiiU’s firmware wanting to pad space for save files, and not much fits. Thus we don’t expect this odd tower of power to take off like the original did– still, if you had one of these back in the day, it might be a nice nostalgia hit to hear the drive whirring away.

If you think a disk drive is something Nintendo would never imagine for their consoles, think again! The Japanese version of the NES had the Famicon disk drive, which turns out to be essential if you want to run UNIX on that system.

With the advent of affordable 2.5 Gbit, 5 Gbit, and 10 Gbit consumer networking gear, more and more people are taking advantage of these higher networking speeds, with [This Does Not Compute] having used 10 Gbit SFP+ modules over regular Cat-5e copper to connect to a NAS in the next room. Only problem was that after a while these SFP+ modules began to start dropping frames. On taking a closer look at these modules, he found that they were running pretty hot: 40°C while idle. A teardown of one of these modules showed severe discoloration due to heat.

Inside these 10Gbit modules is the Marvell-branded Alaska X 88X3310/40P PHY, which despite the ‘low-power’ claims have a metal heatsink glued onto the actual IC and thermally coupled to the module’s metal enclosure. The other side of the PCB was quite discolored, further indicating how hot these modules run in operation. Some digging revealed that this can go up to around 2.5 watts.

Perhaps the most fascinating part of this teardown is the discovery of an 8051-based MCU that’s responsible for telling the switch the module is put into that it is a 30-meter multi-mode fiber module, presumably for compatibility purposes. It’s definitely an interesting feature of these FS-branded SFP+ modules.

These old modules were replaced with Wiitek-branded modules that are supposed to use only up to around 1.5 watts in operation courtesy of a newer chipset, in the hope that these wouldn’t fry themselves. At idle these do however still run at 30 °C. As noted in the comments, it might be a good idea to have active airflow over high-speed networking gear like this, as they generally can get pretty hot and sometimes crispy.

The final solution for the video’s networking problem was to just run single-mode fiber to the room and use appropriate SFP+ modules for that, also because these run noticeably cooler. If you still have room in your cable ducts, that would seem to be the optimal solution.

Few things are more satisfying during a Summer night than hearing the crackle and pop of another mosquito hurling itself against a bug zapper and knowing that it won’t be trying to suck your blood any more. The only problem with those bug zappers, whether the mounted or hand-held type is that you cannot get every single attacking mosquito. Unless you were to put the bug zapper on yourself, of course. This is basically what [Dani Cruster] of the aptly named ‘DiWHY’ channel decided would be the right course of action.

The video is apparently dubbed over from the original Russian – with the team claimed to be based in Moldova – which probably explains a lot of the reasoning behind this engineering. At the core of the whole-body bug zapper is galvanized mesh, with a big question being how close you can get it to the body before said body gets zapped too. With about a millimeter of clearance between both layers of mesh required at 1 kV, this was another design consideration.

Ultimately the guts of stun guns were used, which output around 10 kV and thus require a 1 cm gap between the mesh layers. PVC plates were used to create the structural elements of the walking bug zapper suit, using a heatgun to form it into a body-appropriate shape. That’s when human testing started, to try and not make it zap the wearer.

The final suit of bug zapping armor uses six stun gun modules, each powered by a 3 V power source created from two 1.5 V alkaline cells that are good for an hour of zapping. One issue found during a human trial run was that the zip ties used turned out to actually cause arcing, which had to be addressed first before heading to the mosquito-infested woods. In the video these are said to be near Tarkov in what appears to be the national park in Russia’s Tver Oblast and clearly a prime mosquito breeding ground.

During the real-life test run many mosquitoes and apparently even some ticks find their electrifying demise, before for some reason they seem to clear out after an hour or so. Overall it seems to work well, even if it’s not that ergonomic and things get spicy when it starts to rain.

Although the basic principle of radio direction finding is easy to understand (measure the phase difference between different antennas, then calculate the angle of arrival from this difference), the radio hardware to actually implement this has historically been hard for hackers to access. The QuadRF project aims to change this by building a phase-coherent four-channel SDR which makes direction mapping easy (GitHub repository).

The QuadRF uses two boards: one to receive and pre-process radio waves, and a Raspberry Pi 5 for additional processing. The RF board has four patch antennas, each capable of either transmitting or receiving in the 4.9 GHz to 6.0 GHz range, with switchable right- or left-hand polarization. For on-device processing, it uses a Lattice ECP5 FPGA, which uses two MIPI cables to connect to the camera and display interfaces on the Raspberry Pi. These form a very high-speed data exchange, and after further processing, the Pi can pass data on over Ethernet or Wi-Fi. Individual QuadRF boards can connect together in a lattice grid to form larger phased arrays.

The QuadRF’s software shows off its real strength: it’s compatible with standard programs like GNU Radio, but it also hosts a few of its own programs. The most striking of these is an “RF camera” which scans its entire frequency range at 30 fps, tracking the direction of detected signals and visualizing them on a spatial plot. When overlaid on a camera feed, this plot lets one easily see the radio signals emitted from electronics; as an example, the creators tracked a drone in flight, even distinguishing the two radio transmitters on the drone.

This isn’t the first multi-antenna SDR we’ve seen, though this is the first that could transmit. It’s important to be careful, though: some applications of this kind of hardware run afoul of arms regulations.

Thanks to [Swake] for the tip!

Some municipalities implement bike counters on cycling routes in order to monitor traffic. [nullpxl] recently investigated how these counters work, and explored methods that can be used to trick the counter into thinking a bike passed over it.

A great many of these devices are built using inductive loop sensors. This involves passing a current through a loop of wire embedded in the ground. When a conductive item such as the metal wheel of a bike passes through the electric field, eddy currents are generated in the item, creating their own magnetic field which reacts with the loop’s field itself. This creates a change in inductance which can be measured, and thus used to log the number of times a conductive item has passed over the sensor. By looking at the signature of the inductance change, a system can be tuned to detect specific objects—for example, two bicycle wheels passing over a sensor will create a signal that varies over time in a characteristic way.

[nullpxl] first tried to recreate a “bike” signal for the inductive loop by running over the area holding two metal pans. This wasn’t close enough, so a new idea was needed. Experiments with a scrap bike then indicated that there was a speed gate involved, and that wheeling one wheel over the sensor and back again could trick the sensor into thinking a bike had passed by. Eventually, [nullpxl] distilled all this learning down to create “the BIKE BASKET.” It’s simply a bag with a bike wheel in it, and swinging it over the sensor twice makes the counter tick up.

Is there any money in tricking the average municipal bike counter in your local city? We doubt it, unless Big Bike is getting increasingly filthy in its lobbying efforts. In any case, we love to see weird sensor hacks around these parts.

We’ve been talking a bunch of home automation on the Podcast lately, and this week, in the Mailbag segment, a reader asked us about our setups. Neither Kristina nor I are poster children for the home automation movement: she has absolutely no smart anything because she didn’t want her data up in “the cloud”, and I have an entirely local system that’s really nothing more than a bunch of ad-hoc scripts that talk to an MQTT broker, everything fully DIY but held together with metaphorical duct tape. Neither of us are doing it right, but we’re doing it wrong in interestingly different ways.

Kristina thought, probably because of the range of commercial devices out there that tie you into using their remote data storage services, that giving up control of her data was necessary to use it. And it might be, if you insist that setting up the system be as easy as possible. But the tradeoff for this ease is a drastic reduction in simplicity. You shouldn’t need a remote server in some foreign country to turn your lights on and off. Adding “the cloud” into the mix brings a lot of complexity, mostly in the form of servers that have to be paid for somehow by whatever company is providing the service. It needs to be secure. You might even have to create accounts, remember passwords, and manage that whole deal. Sure, that’s easy enough, but it’s a lot of moving parts, and you can’t blame her for rejecting that complexity.

My system is hosted on a now-ancient OrangePi in the corner, and the network in question is an old WiFi router that it sits on. Nothing needs to leave my four walls, but actually some of it does – I bridge some of the MQTT topics out to an external server for my own amusement. There is no protocol, and no real “system” frankly. Each device in the network has its own topic, and I’m responsible for knowing what it means. The thermometer in the basement has an ESP8266 that transmits on the home/basement/temperature topic, and it puts out its temperature in degrees Celsius. It was the simplest system I could think of, but I have to write whatever software I want to log, display, or act on the data. Of course, that’s simple if you can write some four-liner scripts on the OrangePi broker, but it’s not easy enough that my wife wants to hack on it.

So if the full-buy-in commercial systems are easy but overly complex, and my DIY network is transparently simple but requires a level of hands-on that isn’t easy for “normies”, is there a middle ground? I know half of you are already screaming Home Assistant or Domoticz, and you’re also thinking of which client device libraries you like the most for all your DIY applications: ESPHome vs Tasmota, for instance. And you’re all right!

We are living the in the golden age of the home automation projects. Open-source software and firmware, combined with an abundance of online tutorials and worked examples, have made huge strides toward bridging the gap between simplicity and ease of use. You can set up a hub for everything on a single-board computer, upload the software of your choice, and you don’t need the complexity or loss-of-support liability of a cloud provider. At the same time, setup is easy enough if you’re willing to roll up your sleeves a little bit, and when it’s not, chances are good that someone else has already figured it out for you. These days, interoperability with popular commercial products is shockingly easy to boot.

I need to spend some time and rationalize my system: given the state of the art, it’s simply too simple, and taking a step into an open-source solution would make it easier to use for the rest of the family, without overly complexifying things, adding sketchy dependencies, or losing our data sovereignty. I haven’t finished exploring my options yet, but from what I can see, the community has converged on some goldilocks setups: not too simple or too easy, but rather just right. Thanks, y’all!