Many of us will be used to the idea of a KVM, a device that pipes keyboard, video, and mouse over the network from a remote machine to your own. But many remote machines don’t run a GUI, so there’s not always the need for a full video experience. Enter [morpheuslord] with the PicoTTY. It’s somewhere between an old-fashioned serial terminal and a KVM.

The system has two components, a Pi Pico which plugs in to the USB port of any one of a number of machines and has a wireless card, and a Pi Zero which forms the hub. The Pico acts as both a keyboard and a serial terminal, and streams both to the user via a web interface on the Zero.

We can see the use of a machine like this, but we have a few questions. Why for instance is the keyboard needed, given that the serial terminal could provide input in itself. But however it works we can see it might have a use in cases where a terminal can’t be accessed over the network directly, and we especially like it that a single USB peripheral does the job that a conventional KVM would use a bunch of cables for.

If it’s a more conventional KVM you seek, they can now be done using a microcontroller.

Anyone can string up some LED string lights in a space with mixed results. However, if you want to create a lighting environment that’s classy and stylish, it takes a little more finesse. [ipad.bendavid] has a great example of this, with a rather tidy architectural LED installation.

The electronic side of things is relatively straightforward. There’s an ESP32 running the show, commanding the colors for 928 individually-addressable WS2812 RGB LEDs. It uses the WebSocket API for real time control, integrates with Home Assistant, and even offers audio reactive lighting modes with the aid of an INMP441 I2S audio input module. A hefty 5 V, 60 A power supply ensures the LEDs are never short of juice. There was also careful attention paid to power distribution to avoid any dim spots or other issues.

Where it gets really cool, though, is the attention paid to the construction of the installation. The LED strips are installed in concentric square frames, which block light in specific areas to create a nice square pattern, with the LEDs facing the wall they’re installed on rather than projecting out to the viewer. This hides the strips themselves and eliminated the need for diffusers which can be a pain to get right.

Overall, the build is a pleasing one that plays with light and darkness and looks rather stylish in a way so many LED installs don’t. If you’re cooking up your own neat glowable projects, you know we’d love to see them on the tipsline.

We’ve all seen these sensors and modules kicking around, as part of beginner kits, strapped into prototypes and potentially even in products deployed in the field. Yet as [John Teel] rightfully points out in a recent video, most of these have no business ever being used in a real product, and might not even be suitable for prototyping.

First up is a combination of the related DHT11 and DHT22 temperature-humidity sensors. As common as these are, they’re also pretty sketchy with their proprietary one-wire protocol and at most questionable accuracy, worsened by not having a good supply chain. The replacements are plentiful: the SHT40 and SHT41, the Bosch Sensortec BME280 or BMP180, as well as TI’s HDC3020. These get you standard I2C communication and a supply chain plus a datasheet you can trust.

Second is the HC-SR04 ultrasonic distance sensor. Although fine for prototyping, it’s a 5 V module, lacks temperature compensation and other features that’d be needed outside a temperature-controlled room. Here ST’s VL53 Time-of-Flight sensors are a good alternative, containing a range of sensors of which we covered the fancier VL53L5CX previously for 3D scanning a room. Of course, you can also use reflective IR as a good cheap alternative.

Third is the HC-SR501 passive infrared (PIR) motion module. This one is also fine for PIR and motion sensing prototyping, but is too inconsistent and power-hungry for production. Instead you can get much better and much smaller PIR modules, like the Panasonic EKMC and EKMB, or the ST STHS34 IR motion and presence sensor.

Fourth takes a swing at all the MQ-series of gas sensors. These generally feature a heater that consumes a lot of power, require a long burn-in period and need calibration using a reference gas to be useful. In a safety-first environment you’d thus use a sensor from a reputable manufacturer with a datasheet and some level of calibration.

Fifth is the MPU-6050 IMU, which probably comes as a surprise to many, as it generally seems to just work well. The main issue here is something that is common for a lot of common non-sensor chips as well, like the still very common UDA1334A I2S codec that hasn’t been manufactured by NXP for ages, but is still found everywhere. If you want to design a product that can be easily manufactured, you have to pick an IMU here that is actively being manufactured by a reputable manufacturer.

You also have to actively avoid anything that’s marked as ‘Not Recommended for New Designs’ (NRND) unless you love supply surprises during production. For IMUs you end up with something like the Bosch BMI270 or TDK’s ICM-42688, albeit for more money, but with better specifications.

Sixth sensor are cadmium sulfide photoresistors (LDRs). Although this is a very simple light-dependent resistor part, they fall afoul of the EU’s RoHS regulations due to the presence of said cadmium. Fortunately they’re not that great anyway, so an ambient light sensor IC is a good alternative. Here the Vishay VEML7700, TI OPT3001 and Lite-On LTR-303 are recommended and provide far more features at a reasonable BOM cost.

Seventh sensor and #1 on the list is the ACS712 current sensor. Specifically the mains-targeting breakout boards that are being sold everywhere. Here it’s not the IC that’s the problem, it’s that here – as also seen with various common relay boards – there has been no consideration given to basic mains power safety, such as creepage distance and general separation. The lesson here is that if you integrate mains power in your device, you do not skimp on safety with a sketchy module.

There’s a new contender in the prosumer UV printer world up on Kickstarter, the HeyGears G1. This one’s particularly interesting as they’re explicitly marketing it as being able to produce full-color 3D prints along with the “print-on-anything” functionality we’ve come to expect from a UV flatbed printer.

You get two choices of bed, with the larger being 420 mm x 320 mm x 130 mm. Hardly the largest build volume we’ve seen around here. You can fill that with up to 6 KG of UV ink/resin from its Epson-brand head in glorious full color and layers as small as 10 um. The ink isn’t super cheap — the CMYK kit looks to MRSP at 189 USD — but you aren’t locked in to expensive cartridges at least. HayGears sells ink in bottles, and you’re free to grab any other brand’s bottles if you want to risk it.

The Kickstarter is ongoing, and it will be some time before backers get their printers. But we can report that the early review copies, like the one [Steve Makes Everything] got for the video embedded below, seem to live up to the manufacturer’s claims, which is promising indeed. Certainly the idea of SLA quality without the mess is very appealing to many — though the super-early-bird price of two grand on Kickstarter and the doubtless higher MRSP may temper some of that interest.

If you’re curious about this UV printer business and why a maker might want one that doesn’t do 3D, our own [Tom Nardi] went hands-on with the EufyMake E1 last year.

While we’ve largely settled on analog sticks and digital buttons for controlling video games, there’s all sorts of projects to create truly esoteric controllers that allow playing games in unique ways. This one from [sukolupo] lets you use data from standard bike trainers to get your virtual character moving.

Called Deck de France, it maps the data coming from one of the supported bike trainers to a virtual controller which can then be “plugged in” to a gaming console of choice, in this case a Steam Deck mounted to the trainer’s handlebars. Although a bike trainer doesn’t have the same number of inputs as a modern gaming controller, it does have enough to play games like Rocket League. As you might expect, it’s also perfect for biking titles such as the Tour de France series.

As far as unique controllers for video games go, this one is surely up in the rankings with a real trombone or a controller purpose-built for riding virtual horses. It’s also a great way for those who are getting a bit bored of riding their trainers to breathe some new life into their exercise routine. We’ve also seen some open-source alternatives for modern bike trainer software as well, which is another great way to get excited about exercise equipment too.

Stewy is a very interesting robot, with some slightly odd kinematics. Its head is a Stewart platform, which is a common-enough 6-DOF actuated plate normally used with a fixed base. By connecting legs to the same servos running the Stewart platform, [JD] turned it into an adorable hexapod walker. The walker had a problem, though: it can’t feel its feet, and [JD] thinks that would make it much more mobile on uneven surfaces. So he got some resistors to turn the cheap servos in its legs into force-sensing actuators.

Well, almost. He’s not actually putting strain gauges or anything like that into the legs; he’s just measuring the voltage drop across a resistor in series with the servos. Since the motors draw more current the more torque they’re putting out, he has a very quick and easy way to sense the current and thus the torque using good old Ohm’s law and an analog input on the microcontroller driving the robot. It’s a simple hack, but the data he’s getting is surprisingly good for how much work it is to add to a robot, as you can see in the video — at least once he slowed down the servos a touch.

Perhaps this isn’t a ground-breaking innovation, but [JD] does a very good idea explaining it. Of course if you want to use resistors to sense force directly, force-sensitive resistors are a thing that we’ve seen in everything from Twister-mat MIDI controllers to self-leveling 3D printers.

Stream decks are very useful when you’re live on camera and you need to hit some complicated macro at a glance. However, there is sometimes a perception that commercial options are a touch expensive for what they are, an attitude which has spawned many DIY builds. [Fady Faheem] has developed just such a device of his own.

Named Stream32, the build is intended to be simple to understand and adapt to one’s own individual workflow. Putting one together is as easy as buying a display, hooking it up to an ESP32, flashing the firmware, and then adding pages of shortcuts as desired. [Fady] has designed the firmware to be flexible with regards to screen choice — currently, it can be set up for a 4″ Waveshare LCD or a nice roomy 10.1″ display from Elecrow. Since it’s open source, adapting to a wider range of displays is a potential exercise for the builder.

The great thing about custom stream decks is you have all the freedom in the world to customize them to your own specific setup. Play with the code, the functionality, the visual layout—all to suit your own needs. If you’re working on your own custom hardware, be sure to tell us on the tipsline.