Trick Your (1970) Pickup Truck

[Dave] wanted an old pickup, and he found a GMC Sierra Grande truck vintage 1970. While it had an unusual amount of options, there weren’t that many high-tech options over 50 years ago. The five-year-long restoration work was impressive, as you can see in the video below, but we were really interested in the electronics part. As [Dave] mentions, the truck was made when the Saturn V was taking people to the moon, but after his modifications, the truck has a lot more computing power than the famous rocket.

He was concerned that the taillights were not up to modern standards and that it would be too easy for someone using their cell phone to plow into the rear of the truck. So he broke out an ESP32 and some LEDs and made an attractive brake light that would have been a high-tech marvel in 1970.

Continue reading “Trick Your (1970) Pickup Truck”

Dodge, The Weird Tripod Robot

[hannu_hell] created Dodge as a “novel design of tripod.” It’s a small robotic device quite unlike anything else we’ve seen of late. It’s intended to be a self-mobile camera platform that can move itself around to capture footage as needed.

Dodge is essentially a two-legged robot with a large flat “foot” in the center. When stationary, it rests on this flat foot. When it needs to move, it can raise this center foot and rest on its two outside legs. If Dodge needs to move, it can crab back and forth in a line with these two legs. If it wants to turn, it can return to resting on its center foot, and pivot about its central axis. It can thus rotate itself and use its two outer legs to move further as needed.

Dodge does all this while carrying an ESP32 Cam module. The idea is that it’s a small mobile tripod platform with a live camera feed. It reminds us of various small monitoring robots from cartoons and anime.

Ultimately, it’s an interesting take on robot locomotion. Rather than walking with two legs or four legs and dynamic stability, it takes full advantage of static stability instead.

We’ve seen some wild roboticized camera rigs over the years. Video after the break.

Continue reading “Dodge, The Weird Tripod Robot”

PCB Design Review: ESP32-S3 Round LCD Board

For our next installment, I have a lovely and daring PCB submitted by one of our readers, [Vas]. This is an ESP32-S3 board that also has an onboard round TFT display, very similar to the one we used on the Vectorscope badge. The badge is self-sufficient – it has an ESP32, it has a display, a programming connector, two different QWIIC ports you could surely use as GPIOs – what’s not to love?

This is a two-layer board, and I have to admit that I seriously enjoy such designs. Managing to put a whole lot of things into two layers is quite cool in my book, and I have great fun doing so whenever I get the opportunity. There’s nothing wrong with taking up more layers than needed – in fact, if you’re concerned about emitted/received noise or you have high-speed interfaces, four-layer is the way to go. But making complex boards with two layers is a nice challenge, and, it does tend to make these boards cheaper to manufacture as a very nice bonus.

Let’s improve upon it, and support [Vas]’s design. From what I can see looking at this board, we can help [Vas] a lot with ease of assembly, perhaps even help save a hefty amount of money if they go for third-party PCBA instead of sitting down with a stencil – which you could do with this board pretty easily, since all of the components on it, save for the display, are the ones you’d expect JLCPCB to stock.

Continue reading “PCB Design Review: ESP32-S3 Round LCD Board”

Dev Board Watch Takes Path Of Least Resistance

Building your own watch or clock is kind of a maker’s rite of passage. Once upon a time, if you went with a wrist watch, you’d typically work on producing your own compact PCB with everything crammed into a typical watch form factor, maybe relying on a simple binary output for compactness and simplicity. Times have changed, however, and [Arnov]’s design is altogether different in its construction.

The build relies on a XIAO ESP32-C3 microcontroller board as the brains of the operation. It’s paired with the XIAO expansion board. It’s designed as a carrier for the ESP32-C3, giving it a bunch of IO that’s accessible over readily-accessible connectors. It also features a display, a real-time clock, and a battery — pretty much the three main things you’d need to add to an ESP32 to turn it into a watch.

Thus, with the electronics pretty much done, it was simply up to [Arnov] to turn the device into a watch. He achieved this by screwing the frame and strap of an old Casio watch to a 3D printed carrier for the XIAO expansion board. With that done, it was simply a matter of writing the code to show the time from the RTC on the display. There’s no connectivity features, no smart stuff going on — just the time and date for your perusal.

Some might decry the project for simply slapping a watch band on a devboard. Or, you could look at how this indicates just how fast and easy development can be these days. Once upon a time, you could spend weeks trying to find a cheap display and then further weeks trying to get it working with your microcontroller. Now you can spend $20, get the parts in a few days, and get your project blasting along minutes later.

If you’ve done an altogether more ornate watch build of your own, we’d love to see that, too. Show us on the tipsline!

Custom Library Rescues Good LoRa Hardware From Bad Firmware

The range of hardware that comes on some dev boards these days is truly staggering. Those little LoRa boards are a prime example — ESP32 with WiFi and Bluetooth, a transceiver that covers a big chunk of the UHF band, and niceties like OLED displays and plenty of GPIO. But the firmware and docs? Well, if you can’t say something nice, don’t say anything at all. Or better yet, just roll your own.

Of course that doesn’t hold true for all the LoRa dev boards on the market, but [Rop] certainly found it to be the case for the Heltec HTIT-WB32LA. This board has all the bells and whistles and would be perfect for LoraWAN and Meshtastic applications, but it needed a little help getting it over the line. [Rop]’s contribution to this end is pretty comprehensive and is based on his fork of the RadioLib library, which incorporates a library that greatly reduces wear on the ESP32’s flash memory. In addition to full radio support, the library supports all the hardware on the board from the pushbutton to the display, power management and battery charging, and of course the blinkenlights.

[Jop] includes quite a few example applications, from the bare minimum needed to get the board spun up to a full-blown spectrum analyzer. It’s a nice piece of work, and a great give-back to the LoRa community. And if you want to put one of these modules to work, you’re certainly in the right place. We’ve got everything from LoRaWAN networks to the magic of Meshtastic, so take your pick and get hacking.

A graph from the article, showing dead zones and error bars for the ESP32 ADC

RP2040, ESP32, And An Atmega Have An ADC-Off

[Simon Monk] got frustrated with bad ADC performance when tinkering with an ESP32 board, and decided to put three of the nowadays-iconic boards to the test – a classic ESP32 devboard, a Pi Pico with an RP2040, and an Arduino Uno R3 with an ATmega328P. To do that, he took a bench PSU, added a filter circuit to it, went through the entire ADC range for each board, took a large number of samples at different points and plotted the results. The plots show us both linearity and precision, as well as ADC dead zones, and the results are quite surprising.

The ESP32 doesn’t only have the most limited ADC with maximum 1V input, it also produces the worst results out of all three, with large error bars and sizeable dead zones at both ends. The Pi Pico, despite being colloquially known for its subpar ADC, produces better results than the ESP32. However, both of them are dwarfed by the ATMega328P’s performance. If you need a dedicated ADC, it might just be a good idea to put an ATMega328P on your board.

The example code is provided, and we are wondering whether there are methodology errors. For instance, the ATMega328P code is written in Arduino-supplied C++, but ESP32 and RP2040 in particular used MicroPython, which does more than just running the code, and MicroPython for ESP32 in particular creates a WiFi access point – something known to induce noise into ADC readings. Nevertheless, this is a fun comparison, and we like when hackers do microcontroller standoffs like that – for instance, check out this review from 2017 which pits a dozen microcontrollers of the time against each other!

A breadboard showing a tiny ESP32 board and two HMC5883L sensors connected to it on different pins

Avoid I2C Address Conflicts On ESP32 By Pin Muxing

Using hardware I2C on an ESP32? Do you need to connect multiple I2C devices with the same address? Normally, you wouldn’t be able to do that without extra parts, but on the ESP32, [BastelBaus] has found a nice hack — just connect your devices to different pins and slightly abuse the ESP32 GPIO muxing, no extra hardware required!

Initially, they tried separating SDA and SCL completely, and after a bit of tinkering, that’s worked out wonders! For this method, [BastelBaus] provides example Arduino code you could easily integrate into your project, and shows logic analyzer captures that demonstrate there’s barely any overhead. Later, they’ve also found out that you could multiplex only one of the pins, specifically, SDA, having the SCL line be common! As far as we see, this could also work out with split SCL, but do let us know if that doesn’t sound right.

Typically, such a problem is solved with an I2C multiplexer, and we’ve highlighted projects with them before. However, this simple method could also work on chips like the RP2040 or even the Raspberry Pi 4 — just a bit more limited, since the GPIO muxing for I2C has less available ports! Also, if you’re not using a chip with such a comfortable GPIO mux and you must use devices with overlapping addresses, check out the comment section under our I2C ecosystem article – there’s a fair few other methods you can use. And, if this method ever malfunctions for you, there’s a bunch of very straightforward ways you could debug your bus!