FOSDEM

7 Articles

FOSDEM Saved, With 3D Printing

February 9, 2024 by 23 Comments

If you were to consider what the most important component of a hacker event might be, the chances are you’d pick something that’s part of the program, the ambiance, or the culture. But as the organizers of FOSDEM in Brussels found out, what’s really the most important part of such an event is the toilet paper.

If you can’t keep the supplies coming, you’re in trouble, and since they only had one key for the dispensers across the whole event, they were heading for a sticky situation. But this is a hacker event, and our community is resourceful. The folks on the FreeCAD booth created a model of the key which they shared via the Ondsel collaboration tools, while those on the Prusa booth fired up their Prusa XL and ran off a set of keys to keep the event well supplied.

Perhaps for many of us, the act of running off a 3D model and printing it is such a mundane task as to be unremarkable — and indeed the speed at which they were able to do it points to it being a straightforward task for them. But the sight of a bunch of hardware hackers saving the event by doing what they do best is still one to warm the cockles of our hearts. We’re fairly certain it’s not the first time we’ve seen a bit of clandestine venue hacking save an event, but perhaps for the sake of those involved, we’d better not go into it.

Screenshot from the presentation, showing the datalogger product image next to the datalogger specs stated. The specs are suspiciously similar to those of a Raspberry Pi 3.

Reclaiming A Pi-Based Solar Datalogger

March 4, 2023 by 7 Comments

There’s quite a few devices on the market that contain a Raspberry Pi as their core, and after becoming a proud owner of a solar roof, [Paolo Bonzini] has found himself with an Entrade ENR-DTLA04DN datalogger which – let’s just say, it had some of the signs, and at FOSDEM 2023, he told us all about it. Installed under the promise of local-only logging, the datalogger gave away its nature with a Raspberry Pi logo-emblazoned power brick, a spec sheet identical to that of a Pi 3, and a MAC address belonging to the Raspberry Pi Foundation. That spec sheet also mentioned a MicroSD card – which eventually died, prompting [Paolo] to take the cover off. He dumped the faulty SD card, then replaced it – and put his own SSH keys on the device while at it.

At this point, Entrade no longer offered devices with local logging, only the option of cloud logging – free, but only for five years, clearly not an option if you like your home cloud-free; the local logging was not flawless either, and thus, the device was worth exploring. A quick peek at the filesystem netted him two large statically-compiled binaries, and strace gave him a way to snoop on RS485 communications between the datalogger and the solar roof-paired inverter. Next, he dug into the binaries, collecting information on how this device did its work. Previously, he found that the device provided an undocumented API over HTTP while connected to his network, and comparing the API’s workings to the data inside the binary netted him some good results – but not enough.

The main binary was identified to be Go code, and [Paolo] shows us a walkthrough on how to reverse-engineer such binaries in radare2, with a small collection of tricks to boot – for instance, grepping the output of strings for GitHub URLs in order to find out the libraries being used. In the end, having reverse-engineered the protocol, he fully rewrote the software, without the annoying bugs of the previous one, and integrated it into his home MQTT network powered by HomeAssistant. As a bonus, he also shows us the datalogger’s main PCB, which turned out to be a peculiar creation – not to spoil the surprise!

We imagine this research isn’t just useful for when you face a similar datalogger’s death, but is also quite handy for those who find themselves at the mercy of the pseudo-free cloud logging plan and would like to opt out. Solar tech seems to be an area where Raspberry Pi boards and proprietary interfaces aren’t uncommon, which is why we see hackers reverse-engineer solar power-related devices – for instance, check out this exploration of a solar inverter’s proprietary protocol to get data out of it, or reverse-engineering an end-of-life decommissioned but perfectly healthy solar inverter’s software to get the service menu password.

Showing balloon rising up, not too far from the ground, with one of the FOSDEM buildings and sky in the background

FOSDEM Sees Surprise Pico Balloon Event

March 4, 2023 by 23 Comments

At any vaguely-related conferences, groups of hackers sometimes come together to create an impact, and sometimes that impact is swinging something into an airspace of a neighboring country. [deadprogram] tells us that such a thing happened at FOSDEM, where a small group of hackers came together (Nitter) to assemble, program and launch a pico balloon they named TinyGlobo 1, which then flew all the way to France!

This balloon is built around a RP2040, and the firmware is written in TinyGo, a version of Go language for microcontroller use. As is fitting for a hacker group, both the hardware and software are open source. Don’t expect custom PCBs though, as it’s a thoroughly protoboarded build. But a few off-the-shelf modules will get you the same hardware that just flew a 400km route! For build experiences, there’s also a few tweets from the people involved, and a launch video, also embedded below.

This reminds us of the Supercon 2022 balloon story — darn copycats! If you’re interested in the more Earthly details of this year’s FOSDEM open source development conference, check out our recent coverage.

FOSDEM 2023: An Open-Source Conference, Literally

March 1, 2023 by 6 Comments

Every year, on the first weekend of February, a certain Brussels university campus livens up. There, you will find enthusiasts of open-source software and hardware alike, arriving from different corners of the world to meet up, talk, and listen. The reason they all meet there is the conference called FOSDEM, a long-standing open-source software conference which has been happening in Belgium since 2000. I’d like to tell you about FOSDEM because, when it comes to conferences, FOSDEM is one of a kind.

FOSDEM is organized in alignment with open-source principles, which is to say, it reminds me of an open-source project itself. The conference is volunteer-driven, with a core of staff responsible for crucial tasks – yet, everyone can and is encouraged to contribute. Just like a large open-source effort, it’s supported by university and company contributions, but there’s no admission fees for participants – for a conference, this means you don’t have to buy a ticket to attend. Last but definitely not least, what makes FOSDEM shine is the community that it creates.

FOSDEM’s focus is open software – yet, for hackers of the hardware world, you will find a strong hardware component to participate in, since a great number of FOSDEM visitors are either interested in hardware, or even develop hardware-related things day-to-day. It’s not just that our hardware can’t live without software, and vice-versa – here, you will meet plenty of pure software, a decent amount of pure hardware, and a lot of places where the two worlds are hard to distinguish. All in all, FOSDEM is no doubt part of hacker culture in Europe, and today, I will tell you about my experience of FOSDEM 2023. Continue reading “FOSDEM 2023: An Open-Source Conference, Literally” →

The Future Of Fritzing Is Murky At Best

February 14, 2019 by 69 Comments

Fritzing is a very nice Open Source design tool for PCBs, electrical sketches, and schematics for designers and artists to move from a prototype to real hardware. Over the years, we’ve seen fantastic projects built with Fritzing. Fritzing has been the subject of books, lectures, and educational courses, and the impact of Fritzing has been huge. Open up a book on electronics from O’Reilly, and you’ll probably see a schematic or drawing created in Fritzing.

However, and there’s always a however, Fritzing is in trouble. The project is giving every appearance of having died. You can’t register on the site, you can’t update parts, the official site lacks HTTPS, the Twitter account has been inactive for 1,200 days, there have been no blog posts for a year, and the last commit to GitHub was on March 13th. There are problems, but there is hope: [Patrick Franken], one of the developers of Fritzing and the president of the PCB firm Aisler which runs the Fritzing Fab, recently gave a talk at FOSDEM concerning the future of Fritzing. (That’s a direct FTP download, so have fun).

Continue reading “The Future Of Fritzing Is Murky At Best” →

What’s Coming In KiCad Version 5

February 10, 2018 by 89 Comments

Way back in the day, at least five years ago, if you wanted to design a printed circuit board your best option was Eagle. Now, Eagle is an Autodesk property, the licensing model has changed (although there’s still a free version, people) and the Open Source EDA suite KiCad is getting better and better. New developers are contributing to the project, and by some measures, KiCad is now the most popular tool to develop Open Source hardware.

At FOSDEM last week, [Wayne Stambaugh], project lead of KiCad laid out what features are due in the upcoming release of version 5. KiCad just keeps improving, and these new features are really killer features that will make everyone (unjustly) annoyed with Eagle’s new licensing very happy.

Although recent versions of KiCad have made improvements to the way part and footprint libraries are handled, the big upcoming change is that footprint libraries will be installed locally. The Github plugin for library management — a good idea in theory — is no longer the default. Spice simulation is also coming to KiCad. The best demo of the upcoming Spice integration is this relatively old video demonstrating how KiCad turns a schematic into graphs of voltage and current.

The biggest news, however, is the new ability to import Eagle projects. [Wayne] demoed this live on stage, importing an Eagle board and schematic of an Arduino Mega and turning it into a KiCad board and schematic in a matter of seconds. It’s not quite perfect yet, but it’s close and very, very good.

There are, of course, other fancy features that make designing schematics and PCBs easier. Eeschema is getting a better configuration dialog, improved bus and wire dragging, and improved junction handling. Pcbnew is getting rounded rectangle and complex pad shape support, direct export to STEP files, and you’ll soon be able to update the board from the schematic without updating the netlist file. Read that last feature again, slowly. It’s the best news we’ve ever heard.

Additionally, this is one of the rare times you get to hear [Wayne] speak. This means the argument over the pronunciation of KiCad is over. It’s ‘Key-CAD‘ not ‘Kai-CAD‘. You can check out the entirety of [Wayne]’s State of the KiCad talk below.

Continue reading “What’s Coming In KiCad Version 5” →

SPI On Embedded Linux

February 19, 2017 by 4 Comments

Are you already comfortable working with Serial Peripheral Interface (SPI) parts and looking for a challenge? We suspect many of you have cut your teeth on 8-bit through 32-bit microcontrollers but how much time have you spent playing with hardware interfaces on embedded Linux? Here a new quest, should you choose to accept it. [Matt Porter] spoke in detail about the Linux SPI Subsystem during his presentation at FOSDEM 2017. Why not grab an embedded Linux board and try your hand at connecting some extra hardware to one of the SPI buses?

The hardware side of this is exactly what you’d expect from any embedded SPI you’ve worked on: MOSI, MISO, a clock, and a slave select. [Matt] gives a succinct overview of SPI and reading datasheets. Our own [Elliot Williams] has done an excellent job of digging through the basics and most common gotchas if you need to get up to speed on all the SPI basics.

The fun details in the talk start at about 18:30 into the video when [Matt] jumps into the Linux side of SPI. You need a controller driver and a protocol driver. The controller driver is responsible for dealing with the pins (actual hardware) and the protocol driver handles the job of making sense of the SPI packets (messages containing any number of transfers) going in or out. In other words, the controller drive just want bits and pushes them in or out on hardware, the protocol driver makes those bits meaningful to the Linux system.

Adding SPI devices (think devices like LCDs and sensors) to your own embedded systems means telling the OS the particulars about that hardware, like max speed and SPI mode. There are three ways to handle this but the Device Tree is the preferred method for modern systems. This paves the way for the controller driver which implements an API set that the Linux SPI subsystem will use to work with your new hardware.

Protocol drivers follow the standard Linux driver model and are pretty straight forward. With these two drivers in place the new device is hooked into the OS and opens up common SPI API calls: spi_async(), spi_sync(), spi_write(), and spi_read(), and a few others.

Continue reading “SPI On Embedded Linux” →