Stop Bad Laws Before They Start

July 25, 2020 by Elliot Williams 88 Comments

With everything else going on this summer, you might be forgiven for not keeping abreast of new proposed regulatory frameworks, but if you’re interested in software-defined radio (SDR) or even reflashing your WiFi router, you should. Right now, there’s a proposal to essentially prevent you from flashing your own firmware/software to any product with a radio in it before the European Commission. This obviously matters to Europeans, but because manufacturers often build hardware to the strictest global requirements, it may impact everyone. What counts as radio equipment? Everything from WiFi routers to wearables, SDR dongles to shortwave radios.

The idea is to prevent rogue reconfigurable radios from talking over each other, and prevent consumers from bricking their routers and radios. Before SDR was the norm, and firmware was king, it was easy for regulators to test some hardware and make sure that it’s compliant, but now that anyone can re-flash firmware, how can they be sure that a radio is conformant? Prevent the user from running their own firmware, naturally. It’s pretty hard for Hackaday to get behind that approach.

The impact assessment sounds more like advertising copy for the proposed ruling than an honest assessment, but you should give it a read because it lets you know where the commission is coming from. Reassuring is that they mention open-source software development explicitly as a good to be preserved, but their “likely social impacts” include “increased security and safety” and they conclude that there are no negative environmental impacts. What do you do when the manufacturer no longer wants to support the device? I have plenty of gear that’s no longer supported by firmware updates that is both more secure and simply not in the landfill because of open-source firmware.

Similarly, “the increased capacity of the EU to autonomously secure its products is also likely to help the citizens to better protect their information-related rights” is from a bizarro world where you can trust Xiaomi’s home-automation firmware to not phone home, but can’t trust an open-source replacement.

Public comment is still open, and isn’t limited to European citizens. As mentioned above, it might affect you even if you’re not in the EU, so feel free to make your voice heard. You have until September, and you’ll be in some great company if you register your complaints. Indeed, reading through the public comments is quite heartening: Universities, researchers, and hackers alike have brought up reasons to steer clear of the proposed approach. We hope that the commission hears us.

There’s An Engineer In Germany I’d Like A Word With; Tale Of A Crumbling Volkswagen Lock

July 20, 2020 by Jenny List 149 Comments

In common with quite a few in the hardware hacking community, I have a fondness for older vehicles. My “modern” ride is an older vehicle by today’s standards, a Volkswagen Polo 6N made in the late 1990s. It’s by my estimation a Good Car, having transported me reliably back and forth across the UK and Europe for several years.

Last week though, it let me down. Outside the church in a neighbouring village the driver’s door lock failed, leaving me with my igniton key stuck in the door, and a mildly embarrassing phone call to my dad to bring the Torx driver required to remove the assembly and release it. I am evidently not 1337 enough, I don’t carry a full set of Torx bits with me everywhere I go. The passenger side lock has never worked properly while I’ve had the car, and this is evidently my cue to sort it all out.

Continue reading “There’s An Engineer In Germany I’d Like A Word With; Tale Of A Crumbling Volkswagen Lock” →

Surgery On The Arduino IDE Makes Bigger Serial Buffers

July 13, 2020 by Al Williams 20 Comments

It is pretty well-known that I’m not a big fan of the Arduino infrastructure. Granted, these days you have more options with the pro IDE and Platform IO, for example. But the original IDE always gives me heartburn. I realized just how much heartburn the other day when I wanted to something very simple: increase the receive buffer on an ATmega32 serial port. The solution I arrived at might help you do some other things, so even if you don’t need that exact feature, you still might find it useful to see what I did.

Following this experience I am genuinely torn. On the one hand, I despise the lackluster editor for hiding too much detail from me and providing little in the way of useful tools. On the other hand, I was impressed with how extensible it was if you can dig out the details of how it works internally.

First, you might wonder why I use the IDE. The short answer is I don’t. But when you produce things for other people to use, you almost can’t ignore it. No matter how you craft your personal environment, the minute your code hits the Internet, someone will try to use it in the IDE. A while back I’d written about the $4 Z80 computer by [Just4Fun]. I rarely have time to build things I write about, but I really wanted to try this little computer. The parts sat partially assembled for a while and then a PCB came out for it. I got the PCB and — you guessed it — it sat some more, partially assembled. But I finally found time to finish it and had CP/M booted up.

The only problem was there were not many good options for transferring data back and forth to the PC. It looked like the best bet was to do Intel hex files and transfer them copy and paste across the terminal. I wanted better, and that sent me down a Saturday morning rabbit hole. What I ended up with is a way to make your own menus in the Arduino IDE to set compiler options based on the target hardware for the project. It’s a trick worth knowing as it will come in handy beyond this single problem.

Continue reading “Surgery On The Arduino IDE Makes Bigger Serial Buffers” →

Why Are Digital Cameras Still Boring?

July 1, 2020 by Jenny List 102 Comments

In the matter of technological advancement, we are as a species, mostly insatiable. The latest toy, the fastest silicon, the largest storage, the list goes on. Take digital cameras as an example, what was your first one? Mine was a Casio QV200 in about 1997, I still have it somewhere though I can’t immediately lay my hands on it, and it could hold a what was for its time a whopping 64 VGA-resolution pictures in its 4Mb of onboard memory.

The QV200 showing off its VGA photography capabilities. It’s March 1998, and this is a brand-new PlayStation that I’m about to install a mod chip inside.

It’s a shock to realise that nearly a quarter century has passed since then, and its fixed-focus 640×480 camera module with a UV-sensitive CMOS sensor that gave everything a slight blue tint would not even grace the cheapest of feature phones in 2020. Every aspect of a digital camera has improved beyond measure since the first models in the 1980s and early 1990s that started to resemble what we’d know today as a standalone digital camera, they have near-limitless storage, excellent lenses, huge and faithfully-reproducing sensors, and broadcast-quality video capability.

But how playful have camera manufacturers been with the form factor? We see reporters in sci-fi movies toting cameras that look nothing like their film-based ancestors. What do our real-life digital cameras have on offer as far as creative body design goes?

Continue reading “Why Are Digital Cameras Still Boring?” →

USB-C Is Taking Over… When, Exactly?

June 23, 2020 by Zoe Skyforest 182 Comments

USB is one of the most beloved computer interfaces of all time. Developed in the mid-1990s, it undertook a slow but steady march to the top. Offering an interface with good speeds and a compact connector, it became the standard for hooking up interface devices, storage, and even became the de-facto way to talk old-school serial, too.

In late 2014, the USB Implementers Forum finalised the standard for the USB-C plug. Its first major application was on smartphones like the Nexus 5X, and it has come to dominate the smartphone market, at least if you leave aside the iPhone. However, it’s yet to truly send USB-A packing, especially on the desktop. What gives? Continue reading “USB-C Is Taking Over… When, Exactly?” →

Seeing Code: The Widescreen Rant

June 20, 2020 by Elliot Williams 114 Comments

A couple of weeks ago, Linus Torvalds laid down the law, in a particularly Linusesque sort of way. In a software community where tabs vs. spaces can start religious wars, saying that 80-character-wide code was obsolete was, to some, utter heresy. For more background on how we got here, read [Sven Gregori]’s history piece on Hackaday, and you’ll learn that sliced bread and the 80-character IBM punch card both made their debut in July, 1928. But I digress.

When I look at a codebase, I like to see its structure, and I’m not alone. That’s one of the reasons for the Linux Kernel style guide’s ridiculously wide 8-character tabs. Combined with a trend for variable names becoming more and more descriptive, which I take to be a good thing, and monitors’ aspect ratios growing seemingly without end, which I don’t, the 80-column width seems like a relic from the long-gone era of the VT-220.

In Linus’ missive, we learn that he runs terminals at 100 x 50, and frequently drags them out to a screen-filling 142 x 76. (Amateur! I write this to you now on 187 x 48.) When you’re running this wide, it doesn’t make any sense to line-wrap argument lists, even if you’re using Hungarian notation.

And yet, change is painful. I’ve had to re-format code to meet 73-column restrictions for a book, only to discover that my inline comments were too verbose. Removing even an artificial restriction like the 80-column limit will have real effects. I write longer paragraphs, for instance, on a wider screen.

I see a few good things to come out of this, though. If single thoughts can be expressed on single lines, it makes the shape of the code better reflect its function. Getting rid of pointless wrapping takes up less vertical space, which is at a premium on today’s cinematic monitors. And if it makes inline comments better (I know, another holy war!) or facilitates better variable naming, it will have been worth it.

But any way you slice it, we’re no longer typing on the old 80-character Hazeltine. It’s high time for our coding style and practice to catch up.