Inkycal Makes Short Work Of E-Paper Dashboards

September 12, 2024 by Tom Nardi 10 Comments

The e-paper “dashboard” is something we’ve seen plenty of times here at Hackaday. Use it to show your daily schedule, the news, weather, maybe the latest posts from your favorite hardware hacking website. Any information source that doesn’t need to be updated more than every hour or so is a perfect candidate. All you’ve got to do is write the necessary code to pull down said data and turn it into a visually attractive display.

Well, that last part isn’t always so easy. There are plenty of folks who have no problem cobbling together a Raspberry Pi and one of the commercially available e-paper modules, but writing the software to turn it into a useful information center is another story entirely. Luckily, Inkycal is here to help.

This open source project uses Python to pull information from a wide variety of sources and turns it into an e-paper friendly dashboard. It works with Waveshare displays ranging from 4.2 inches all the way up to the massive 12 inch tricolor panels. While it could theoretically be deployed on any operating system running a modern version of Python, it’s primarily developed to be run under Linux and on the Raspberry Pi. All of the versions of the Pi are supported, so no need to spring for the latest and greatest model. In fact, the notoriously pokey Raspberry Pi Zero is their recommended platform thanks to its low power consumption.

With Inkycal on the Pi — they even provide a pre-configured SD card image — and the e-paper display hooked up, all you need to do is pick which sources you want to use from the web-based configuration page. Look ma, no code!

Not feeling like putting the hardware together either? Well, we might wonder how you’ve found yourself on Hackaday if that’s the case. But if you really would rather buy then build, you can get a pre-built Inkcal display right now on Tindie.

A light-dependent resistor detects cacti in the Google Chrome Offline Dinosaur game.

Jump Cacti With An LDR And A Pico

September 6, 2024 by Kristina Panos 6 Comments

By now, probably everyone is familiar with the “You’re Offline” dinosaur that stars in Google’s T. Rex game. You know — jump cacti, avoid pterodactyls. Repeat until you lose, or, we suppose, make the leaderboard. Well, what if you theoretically couldn’t lose? That’s kind of the idea behind [Bas BotBerg]’s cactus detection-and-avoidance scheme (translated from Dutch).

Like many of us, [Bas] firmly believes that repetitive tasks should be automated, and that includes the controls of the famous T. Rex. Since the cacti are always dark gray and appear along the same plane, it’s easy to register the difference between cacti and screen electronically. In order to accomplish this, [Bas] is using a light-dependent resistor and a pull-up resistor to create a resistance bridge, which is then connected to an analog input pin on a Raspberry Pi Pico.

But [Bas] didn’t do this just to cheat at Offline Dinosaur. Really! It’s for educational purposes, to get people comfortable with embedded processing, sensors, and interfaces between different devices. Check it out in brief action after the break.

Once they get familiar with these concepts, maybe introduce the ESP32 version of Offline Dinosaur.

Continue reading “Jump Cacti With An LDR And A Pico” →

The Worsening Raspberry Pi RP2350 E9 Erratum Situation

September 4, 2024 by Maya Posch 48 Comments

There’s currently a significant amount of confusion around the full extent of the GPIO hardware issue in the Raspberry Pi RP2350 microcontroller, with [Ian] over at [Dangerous Prototypes] of Bus Pirate fame mentioning that deliveries of the RP2350-based Bus Pirate 5XL and 6 have been put on hold while the issue is further being investigated. Recorded in the MCU’s datasheet as erratum RP2350-E9, it was originally reported as only being related to the use of internal pull-downs, but [Ian] has since demonstrated in the primary issue ticket on GitHub that the same soft latching behavior on GPIO pins occurs also without pull-downs enabled.

Ian from Dangerous Prototypes demonstrating the RP2350-E9 issue in a Bus Pirate prototype without pull-ups.

When we first reported on this hardware bug in the RP2350’s A2 (and likely preceding) stepping there was still a lot of confusion about what this issue meant, but so far we have seen the Bus Pirate delay and projects like [Agustín Gimenez Bernad]’s LogicAnalyzer have opted for taking the RP2350 port out back. There are also indications that the ADC and PIO peripherals are affected by this issue, with workarounds only partially able to circumvent the hardware issue.

In the case of the Bus Pirate a potential workaround is the addition of 4.7 kOhm external pull-downs, but at the cost of 0.7 mA continuous load on the GPIO when pulled high and part of that when pulled low. It’s an ugly hack, but at the very least it might save existing boards. It also shows how serious a bug this is.

Meanwhile there are lively discussions about the issue on the Raspberry Pi forums, both on the E9 erratum as well as the question of when there will be a new stepping. The official statement by Raspberry Pi is still that ‘they are investigating’. Presumably there will be a Bx stepping at some point, but for now it is clear that the RP2350’s A2 stepping is probably best avoided.

VR Headset With HDMI Input Invites A New Kind Of Cyberdeck

September 1, 2024 by Donald Papp 30 Comments

Meta’s Quest VR headset recently got the ability to accept and display video over USB-C, and it’s started some gears turning in folks’ heads. [Ian Hamilton] put together a quick concept machine consisting of a Raspberry Pi 400 that uses a VR headset as its monitor, which sure seems like the bones of a new breed of cyberdeck.

With passthrough on, one still sees the outside world.

The computer-in-a-keyboard nature of the Pi 400 means that little more than a mouse and the VR headset are needed to get a functional computing environment. Well, that and some cables and adapters.

What’s compelling about this is that the VR headset is much more than just a glorified monitor. In the VR environment, the external video source (in this case, the Raspberry Pi) is displayed in a window just like any other application. Pass-through can also be turned on, so that the headset’s external cameras display one’s surroundings as background. This means there’s no loss of environmental awareness while using the rig.

[Note: the following has been updated for clarity and after some hands-on testing] Video over USB-C is technically DisplayPort altmode, and both the video source and the USB-C cable have to support it. In [Ian]’s case, the Raspberry Pi 400 outputs HDMI and he uses a Shadowcast 2 capture card to accept HDMI on one end and outputs video over USB-C on the other.

Here’s how it works: the Quest has a single USB-C port on the side, and an app (somewhat oddly named “Meta Quest HDMI link”) running on the headset takes care of accepting video over USB and displaying it in a window within the headset. The video signal expected is UVC (or USB Video Class), which is what most USB webcams and other video devices output. (There’s another way to do video over USB-C which is technically DisplayPort altmode, and both the video source and the USB-C cable have to support it. That is not what’s being used here; the Quest does not support this format. Neither is it accepting HDMI directly.) In [Ian]’s case, the Raspberry Pi 400 outputs HDMI and he uses a Shadowcast 2 capture card to accept HDMI on one end and output UVC video on the other, which is then fed into the Quest over a USB-C cable.

As a concept it’s an interesting one for sure. Perhaps we’ll see decks of this nature in our next cyberdeck contest?

New 2 GB Raspberry Pi 5 Has Smaller Die And 30% Lower Idle Power Usage

August 30, 2024 by Maya Posch 16 Comments

Recently Raspberry Pi released the 2GB version of the Raspberry Pi 5 with a new BCM2712 SoC featuring the D0 stepping. As expected, [Jeff Geerling] got his mitts on one of these boards and ran it through its paces, with positive results. Well, mostly positive results — as the Geekbench test took offence to the mere 2 GB of RAM on the board and consistently ran out of memory by the multi-core Photo Filter test, as feared when we originally reported on this new SBC. Although using swap is an option, this would not have made for a very realistic SoC benchmark, ergo [Jeff] resorted to using sysbench instead.

Naturally some overclocking was also performed, to truly push the SoC to its limits. This boosted the clock speed from 2.4 GHz all the way up to 3.5 GHz with the sysbench score increasing from 4155 to 6068. At 3.6 GHz the system wouldn’t boot any more, but [Jeff] figured that delidding the SoC could enable even faster speeds. This procedure also enabled taking a look at the bare D0 stepping die, revealing it to be 32.5% smaller than the previous C1 stepping on presumably the same 16 nm process.

Although 3.5 GHz turns out to be a hard limit for now, the power usage was interesting with idle power being 0.9 watts lower (at 2.4 W) for the D0 stepping and the power and temperatures under load also looked better than the C1 stepping. Even when taking the power savings of half the RAM versus the 4 GB version into account, the D0 stepping seems significantly more optimized. The main question now is when we can expect to see it appear on the 4 and 8 GB versions of the SBC, though the answer there is likely ‘when current C1 stocks run out’.

A tricked-out kids' Jeep in black and silver.

Driven To Over-Engineer A Kids’ Car

August 29, 2024 by Kristina Panos 12 Comments

You know, it feels as though it’s getting more and more difficult to compete for Father of the Year around here. And [Jon Petter Skagmo] just laid down a new gauntlet — the incredibly overly-engineered kids car.

While the original plan was to build the entire car from scratch, [Jon] eventually opted to use an off-the-shelf car that had a dead battery.

While the original architecture was quite simple, the new hardware has just about everything a kid could want in a tricked-out ride, most of which is accessible through the really cool dashboard.

We’re talking headlights, a music player, a siren, a selfie video cam that doubles as two-way communication with the driver, and even a garage door opener that uses an MQTT connection.

Under the cute little hood is where you’ll find most of the electronics. The car’s brain is a Raspberry Pi 3B, and there’s a custom daughter board that includes GPS/GNSS. This was originally meant to geofence [Baby Girl Skagmo] in, but Dad quickly realized that kids are gonna kid and disabled it pretty soon after.

This isn’t the first high-tech rebuild of a kiddie car that we’ve seen here at Hackaday. Makes us wish we were quite a bit smaller…

Continue reading “Driven To Over-Engineer A Kids’ Car” →

Close-Up On The RP2350 HSTX Peripheral

August 20, 2024 by Jenny List 24 Comments

The new Raspberry Pi Pico 2 with its RP2350 microcontroller has only been with us for a short time, and thus its capabilities are still being tested. One of the new peripherals is HSTX, for which the description “High speed serial port” does not adequately describe how far it is from the humble UART which the name might suggest. CNX Software have taken a look at its capabilities, and it’s worth a read.

With a 150 MHz clock and 8 available pins, it’s a serial output with a combined bandwidth of 2400 Mbps, which immediately leaves all manner of potential for streamed outputs. On the RP2040 for example a DVI output was made using the PIO peripherals, while here the example code shows how to use these pins instead. We’re guessing it will be exploited for all manner of pseudo-analogue awesomeness in the manner we’re used to with the I2S peripherals on the EP32. Of course, there’s no corresponding input, but that still leaves plenty of potential.

Have a quick read of our launch coverage of the RP2350, and the Pico 2 board it’s part of.