The Open Hardware Summit Badge of 2020 Is a Beauty to Behold!

This year's OHS badge is a true testament to the power of the open source methodology.

Tom Fleet
3 months ago β€’ Hardware 101 / Python on Hardware / Badges

I love to see a good hardware badge project. The quintessential conference bling, they often pack a lot of impression into that small space hanging off the end of your lanyard.

Be they purely passive, artistic FR4 tokens, simple SAO enhancements, or even fully fledged RISC-V FPGA soft-cores running Linux (here's looking at you @Hackaday!), there is a thriving badge life scene, and some stunning work is coming from it.

This year's badge for the Open Hardware Summit falls somewhere across the board. It's a beautiful synergy of powerful hardware, accessible firmware, and functional mechanical design that results in a powerful tower of processing, hanging from your neck.

Beyond the badge itself, there's been a huge amount of work put in to simplify and streamline the process of producing a batch of 300 units in time for this years summit! We'll look into that towards the end of the article, but for now, let's dive straight into the good stuff, and check out all the hard work that has gone into the OHWS badge build from the team at OSHPark.

The Tower of Power

Realized as a two-fold tower stack, the OHS badge is neatly designed to meet two use cases. The primary method of sporting the tech bling around your neck on the conference lanyard might take a back seat, with the now-virtual attendees perhaps finding more time to tinker with use case number two, and perhaps one of our other more popular hardware themes, a hacker-chic smartwatch.

As we can see in the photo above, and also on the badge case shown below, both parts sport the cut-outs and slots required to strap this CircuitPython powerhouse to your wrist and go mobile!

There are a number of subtle cut-outs in the front face of the case, hinting at some of the really fun user interaction and sensor elements that have made it into the design. Let's take a look at the hardware in detail to see what's in store for us to play with!

Hardware Deep Dive

It's fair to say that this is a powerful set of components. With the ability to run the increasingly popular CircuitPython scripting interpreter, a bevvy of hi-tech sensors, and a great big screen to draw on, the badge is reminiscent of some of the recent adafruit products, such as the CLUE.

And the similarity is more than skin deep. I'm really pleased to see a number of my favorite parts popping up, so let's take a closer look at them to see what's on board.

Rigado BMD340 (Nordic nRF52840)

Aka "The Brains" of the operation, the BMD340 from u-blox (having now acquired Rigado's BT module range) is an alternative module to the popular RAYTAQ MDBT-50Q. Both feature the powerful nRF52840 from Nordic Semiconductor, which is a Cortex-M4F CPU, clocked at up to 64MHz!

In addition to that fast processor, it also packs in powerful peripheral features, like multiple serial ports (w/ QSPI), NFC, very flexible pin mapping, USB, DMA, and a nice floating point math hardware block β€” perfect for tearing through the amount of data this board can sense, and generate.

And not to gloss over one of the main points of this part, it also contains a complete BLE / BT 5.0 radio, with all the RF matching network and antenna components taken care of by u-blox, in an SMT module form factor. BLE, conventional Bluetooth, Thread and ZigBee protocols are all supported by the nRF SoC, but that's a bit beyond the current library support (for now!).

It's a fairly standard module implementation, but let's not overlook that generous 32Mb flash, provided by the W25Q32JVZPIQ, which provides the storage required to run the CircuitPython file system, along with oodles of room for code and resources, like images, to be displayed on the on board TFT display.

Some Generous Virtual Real Estate

If I sounded a little enthusiastic for the choice of processor, well, it's because I am! I've been using them recently in a bid to understand what they are capable of, and with their powerful feature set, they are very well paired with a capable LCD that can show off their processing abilities. The team have designed in a 1.54" LCD display, interfaced quite sensibly over 4 wire, unidirectional SPI, with GPIO lines used to signal the various control lines.

Tearing Into Timings

I'm going to note the use of discrete GPIO to drive and read the display LCD_DC an LCD_TE lines respectively, rather than passing them as additional data on the SPI bus.

If you want the absolute best frame rate for your display, you want to do everything you can to up the rate of data transfer from your host MCU to the display controller.

By using hardware signaling, the host MCU can much very quickly indicate to the display controller the difference between data and control packets on the SPI bus, rather than having to encode and decode the signaling onto the serial data.

Having said that, It's also helpful to keep in mind that just blasting pixel data at a display as fast as you possible can, isn't the most "tactful" approach to fluid graphics.

Most displays work like this: Inside the display controller, there is a block of memory that stores the pixel data for the display. When you send data from your MCU to the display, this is where it ends up. This process is represented by the red arrows below, and can take place very, very quickly.

Once the data has been loaded into the display RAM, the display controller then has to read this data out, and update the actual display panel elements to match, resulting in an image. This process is shown with the green arrows.

Both of these processes take time however, and with MCU clocks, and resultant SPI clocks being as fast as they are, it's pretty easy to compute, and send over a new frame to the display controller before it has had time to update the previous frame.

This is what is happening in the 2nd and 3rd transmissions shown above. You can end up being far too quick, and overwriting the display controller memory while it is still processing the previous frame. This produces display data that is "torn" between two frames, and the visual effect is referred to as tearing.

To help keep tabs on this, the hardware incorporates the signaling feedback from the display, using the TE output, or "Tearing Effect."

Think of this as a synchronization signal, allowing you to kick back take care of other application processing, while the display does it's thing and updates the panel. When it's ready for another frame, it can let you know, and you can switch focus to blasting another image across to it over SPI. Neat!

Make the Most of Motion Sensing

The LSM9D51 is a beast of an IMU. By providing not only triaxial acceleration readings, but additionally, triaxial gyroscope and magnetometer readings, it lets you implement a full 9DoF IMU solution in code. Recall that beefy Cortex-M4+ FPU processor? Well, fusing all this data into an into AHRS variables (pitch, roll, yaw) is one of the applications it is very well suited for!

This data goes beyond a simple "flick of the wrist" recognition, and is detailed enough to design game interaction around, or even implement your own activity tracking / logging application!

Visualize VOCs with the BME680

The BME680 is a powerhouse of a sensor. It's capable of the usual atmospheric gas measurements of temperature and relative humidity (%RH), but its main feature is its ability to sense the presence of VOC (Volatile Organic Compounds) in the surrounding atmosphere. "VOC" is a popular term these days, and is often used as a catch-all phrase to group a number of organic compounds together, most of which are associated with poor air quality and/or odours.

If you ever wanted a solid reason to keep meetings short, or to at justify your stance in the ongoing "opening of the window" wars that often plague an office environment, VOC level readings are pretty good evidence for your case.

"Magic" Your Way Through Menus...

While the BME680 handles the gas measurements, there's a quartet of optical measurement packed into the APDS-9960, situated on the front face of the badge, just below the display.

While the schematic annotation sums it up quite nicely, the APDS-9960 supports recognition 6 "gestures", summarised in the table below.

As if that weren't enough, it also crams in colour sensing, proximity sensing and ambient light, all into the one tiny package.

There are countless ways for you to interact with the badge thanks to this part, though if you would rather dispense with the Jedi mind tricks, there are also 4 hardware buttons for you to tap away at.

Picky Power Paths

We've got a fairly solid set of parts taking care of routing power where it's needed;

  • An MCP73831 Li-ion charger takes care of safely managing the charging of the Lithium Ion battery. It's nice to some extra details here, such as the status indicator being bought out to GPIO, and the additon of a resistor divider (R20/R14) to allow the nRF52840 to monitor the cell voltage.
  • An AP2112K is a popular choice of 3.3V LDO, and it's a good way to power 3.3V projects, which sit nicely below the lower cutoff voltage of lithium cells.
  • Power domain priority is observed through the use of Q1, a PFET, and this technique of keeping the 3.3V and 5V domains separate, while feeding the greater of the two into the LDO is one we've seen in a recent look at the SQFMI ESP32 smartwatch.
  • One final point of note, is the use of a voltage detection IC, the S-1000 series from ABLIC. With 5% hysteresis, this is a much cleaner way of signalling the EN pin of the LDO, compared to another resistor divider network, and at 350nA current draw, its a much lower power way of doing things, that won't sit there and eat away at the lithium cell until it falls below the UVLO. Very clever!

Production Engineering

Most of us are quite capable, and even excel at building one of something. A few of us even hand assemble and test small batches of our designs for Tindie, etc.

It's probably fair to say that all of us would gawk at the idea of having to program, test and provision the user credentials for 300 conference badges, however.

What we see above is the team's answer to at least the latter part of this problem, and what I strongly suspect also helps reduce the burden of the other issues of mass production that I listed.

Powered by a Raspberry Pi, this beautifully designed mixture of T-Slot framework and 3D-printed parts enables the badges to be provisioned with specific user details, at the time of issue to conference attendees.

I hope to pour over this design at a later date, as it looks like a promising platform from which to base an ATE (Automated test equipment) system for any small scale batch manufacturing process!

The Open Hardware Methodology

It's worth pointing out that all of the software tools mentioned in this article are free-to-use, open source projects.

That's incredible.

There's the PCB designed in KiCAD, the open source EDA suite of choice for CERN.

Then there's the badge enclosure designed in FreeCAD, the open source, parametric modeling and design tool. There's also the USB bootloader and the CircuitPython binaries released by Adafruit.

This project is a true testament to what can be achieved with the open source model.

"Nanos gigantum humeris insidentes."
Tom Fleet
Related articles
Sponsored articles
Related articles