Design Review: LattePanda Mu NAS Carrier

It is a good day for design review! Today’s board is the MuBook, a Lattepanda Mu SoM (System-on-Module) carrier from [LtBrain], optimized for a NAS with 4 SATA and 2 NVMe ports. It is cheap to manufacture and put together, the changes are non-extensive but do make the board easier to assemble, and, it results in a decent footprint x86 NAS board you can even order assembled at somewhere like JLCPCB.

This board is based on the Lite Carrier KiCad project that the LattePanda team open-sourced to promote their Mu boards. I enjoy seeing people start their project from a known-working open-source design – they can save themselves lots of work, avoid reinventing the wheel and whole categories of mistakes, and they can learn a bunch of design techniques/tips through osmosis, too. This is a large part of why I argue everyone should open-source their projects to the highest extent possible, and why I try my best to open-source all the PCBs I design.

Let’s get into it! The board’s on GitHub as linked, already containing the latest changes.

Git’ting Better

I found the very first review item when downloading the repo onto my computer. It took a surprising amount of time, which led me to believe the repo contains a fair bit of binary files – something quite counterproductive to keep in Git. My first guess was that the repo had no .gitignore for KiCad, and indeed – it had the backups/ directory with a heap of hefty .zips, as well as a fair bit of stuff like gerbers and footprint/symbol cache files. I checked in with [LtBrain] that these won’t be an issue to delete, and then added a .gitignore from the Blepis project.

Continue reading “Design Review: LattePanda Mu NAS Carrier”

Smartphone Hackability, Or, A Pocket Computer That Isn’t

Smartphones boggle my mind a whole lot – they’re pocket computers, with heaps of power to spare, and yet they feel like the furthest from it. As far as personal computers go, smartphones are surprisingly user-hostile.

In the last year’s time, even my YouTube recommendations are full of people, mostly millennials, talking about technology these days being uninspiring. In many of those videos, people will talk about phones and the ecosystems that they create, and even if they mostly talk about the symptoms rather than root causes, the overall mood is pretty clear – tech got bland, even the kinds of pocket tech you’d consider marvellous in abstract. It goes deeper than cell phones all looking alike, though. They all behave alike, to our detriment.

A thought-provoking exercise is to try to compare smartphone development timelines to those of home PCs, and see just in which ways the timelines diverged, which forces acted upon which aspect of the tech at what points, and how that impacted the alienation people feel when interacting with either of these devices long-term. You’ll see some major trends – lack of standardization through proprietary technology calling the shots, stifling of innovation both knowingly and unknowingly, and finance-first development as opposed to long-term investments.

Let’s start with a fun aspect, and that is hackability. It’s not perceived to be a significant driver of change, but I do believe it to be severely decreasing chances of regular people tinkering with their phones to any amount of success. In other words, if you can’t hack it in small ways, you can’t really make it yours.

Continue reading “Smartphone Hackability, Or, A Pocket Computer That Isn’t”

Hacker Tactic: ESD Diodes

A hacker’s view on ESD protection can tell you a lot about them. I’ve seen a good few categories of hackers neglecting ESD protection – there’s the yet-inexperienced ones, ones with a devil-may-care attitude, or simply those of us lucky to live in a reasonably humid climate. But until we’re able to control the global weather, your best bet is to befriend some ESD diodes before you get stuck having to replace a microcontroller board firmly soldered into your PCB with help of 40 through-hole pin headers.

Humans are pretty good at generating electric shocks, and oftentimes, you’ll shock your hardware without even feeling the shock yourself. Your GPIOs will feel it, though, and it can propagate beyond just the input/output pins inside your chip. ESD events can be a cause of “weird malfunctions”, sudden hardware latchups, chips dying out of nowhere mid-work – nothing to wish for.

Worry not, though. Want to build hardware that survives? Take a look at ESD diodes, where and how to add them, where to avoid them, and the parameters you want to keep in mind. Oh and, I’ll also talk about all the fancy ways you can mis-use ESD diodes, for good and bad alike!

Continue reading “Hacker Tactic: ESD Diodes”

ZPUI Could Be Your Tiny Embedded GUI

One of the most frustrating things to me is looking at a freshly-flashed and just powered up single board computer. My goal with them is always getting to a shell – installing packages, driving GPIOs, testing my proof of concept code, adjusting the device tree to load peripheral drivers. Before I can do any of that, I need shell access, and getting there can be a real hassle.

Time after time, I’ve struggled trying to get to a shell on an SBC. For best results, you’d want to get yourself a keyboard, monitor, and an Ethernet cable. Don’t have those, or there’s no space to place them? Maybe a UART connection will work for you – unless it’s broken or misconfigured. Check your pinouts twice. Sure, nowadays you can put WiFi credentials into a text file in /boot/ – but good luck figuring out the IP address, or debugging any mistakes you might make formatting the file. Nowadays, Pi 4 and 5 expose a USB gadget connection on the USB-C port, and that helps… unless you’re already powering the Pi from that port. There’s really no shortage of failure modes here.

If you put a Pi on your network and it goes offline, you generally just don’t know what happened unless you reboot it, which can make debugging into a living hell. I’ve dealt with single-board computers mounted above fiberglass lifted ceilings, fleets of Pi boards at workshops I organized, pocket-carried Pi boards, and at some point, I got tired of it all. A hacker-aimed computer is meant to be accessible, not painful.

Continue reading “ZPUI Could Be Your Tiny Embedded GUI”

Attack Of The Beepy Clones

In the Blackberry-keyboard-based project lineage story last week, I covered how a series of open-source projects turned into Beepy, a cool Linux PDA with a lively community. To me, it’s yet another demonstration of power that open-source holds, and more importantly, it shows how even a small pet project of yours could cause big moves in the hardware world, provided you publish it – just ask [JoeN], [WoodWorkeR] and [arturo182].

The journey didn’t end there. For all its benefits, Beepy had some flaws to take care of, some board-killing flaws, even. The 5 V boost regulator was never intended for 4.7 V input it gets when charger is connected, and would occasionally cook itself. A charging current resistor was undersized, leading people to either bodge resistors onto their Beepy boards, or have their battery charge for 30 hours until full. A power path diode was undersized, too, and has burned out on more than a few devices. Also, Beepy’s feature package left things to be desired.

Beepy never made it beyond v1. If I had to guess, partially because of BB Q20 keyboard sourcing troubles, but also definitely some sort of loss of interest. Which is a shame, as the plans v1.5 of the hardware were pretty exciting. In the meantime, other players decided to take up the mantle – here’s a tale of three projects.

Continue reading “Attack Of The Beepy Clones”

The Blackberry Keyboard: How An Open-Source Ecosystem Sprouts

What could happen when you open-source a hardware project?

No, seriously. I hold a fair few radical opinions – one is that projects should be open-source to the highest extent possible. I’ve seen this make miracles happen, make hackerdom stronger, and nourish our communities. I think we should be publishing all the projects, even if incomplete, as much as your opsec allows. I would make ritual sacrifices if they resulted in more KiCad projects getting published, and some days I even believe that gently bullying people into open-sourcing their projects can be justified. My ideal universe is one where companies are unable to restrict schematics from people getting their hardware, no human should ever hold an electronics black box, by force if necessary.

Why such a strong bias? I’ve seen this world change for the better with each open-source project, and worse with closed-source ones, it’s pretty simple for me. Trust me here – let me tell you a story of how a couple reverse-engineering efforts and a series of open-source PCBs have grown a tree of an ecosystem.

A Chain Of Blackberry Hackers

Continue reading “The Blackberry Keyboard: How An Open-Source Ecosystem Sprouts”

Interposer Helps GPS Receiver Overcome Its Age

We return to [Tom Verbeure] hacking on Symmetricom GPS receivers. This time, the problem’s more complicated, but the solution remains the same – hardware hacking. If you recall, the previous frontier was active antenna voltage compatibility – now, it’s rollover. See, the GPS receiver chip has its internal rollover date set to 18th of September 2022. We’ve passed this date a while back, but the receiver’s firmware isn’t new enough to know how to handle this. What to do? Build an interposer, of course.

You can bring the module up to date by sending some extra init commands to the GPS chipset during bootup, and, firmware hacking just wasn’t the route. An RP2040 board, a custom PCB, a few semi-bespoke connectors, and a few zero-ohm resistors was all it took to make this work. From there, a MITM firmware wakes up, sends the extra commands during power-on, and passes all the other traffic right through – the system suspects nothing.

Everything is open-source, as we could expect. The problem’s been solved, and, as a bonus, this implant gives a workaround path for any future bugs we might encounter as far as GPS chipset-to-receiver comms are concerned. Now, the revived S200 serves [Tom] in his hacking journeys, and we’re reminded that interposers remain a viable way to work around firmware bugs. Also, if the firmware (or the CPU) is way too old to work with, an interposer is a great first step to removing it out of the equation completely.