John Whittington's Blog

Tailwind - Wahoo Headwind BLE Remote with Rust

Mon, 11 Dec 2023 00:00:00 +0000

I recently purchased a Wahoo Headwind as part of my static trainer setup. The device lacks a button remote in favour of App based control. Whilst this works okay in principle, anyone that has used a static trainer knows that in the sweaty heat of the moment trying to use a App is frustrating at best!

So I decided to use the opportunity to explore using (embedded) Rust on the Nordic nRF series. Developing BLE for Nordic chips involves a reasonably complex toolchain since the BLE stack is a closed-source binary (SoftDevice) and there is a lot of supporting modules. I was intrigued to see what the experience would be like outside of the C Nordic nRF Connect SDK.

Embassy have created a SoftDevice Rust binding generator project for the nRF series that formed the foundation of my project. Using it also allowed me to learn about many parts of the Rust embedded ecosystem, such as Probe, the Embassy runtime itself and working with Rust embedded-hal(s).

Small snapshot of Wahoo App BLE logging to reverse engineer protocol

The Headwind protocol was fairly easy to reverse engineer using the Android Wahoo App with HCI BLE logging enabled and some other hacking attempts around the internet. I was able to review the action/result using WireShark. The protocol isn’t great in my opinion, using a fixed cyclic update rather than actual notify and seems to lag behind the actual state of the device at times.

I could have ignored the device state all together but I wanted to keep synchronisation so that I can seamlessly switch control between the App, front-panel and the remote. A press of the remote button will request and assert the change so that the button press will always reflect a change in the actual state of the device.

In all it was a fun project and fills the requirement. Whilst the Rust developer experience surpassed that of using the C SDK - the benefits of a modern language and package manager - it’s not as powerful as the ZephyrOS based toolchain provided by the new Nordic nRF Connect SDK. ZephyrOS is a joy to use, so I’ll take the shortcomings of C (fine with experience/working practices) for now in order to use it. Perhaps as Embassy develops, Nordic will adopt a Rust SDK but I don’t see this happening in the near future. For a simple device like this, I’ll turn to the Rust stack. For a custom fully featured BLE device, I’ll stick to the nRF SDK for now…

GitHub Project

Minnow USB-C DAM Tool

Sun, 30 Jul 2023 00:00:00 +0000

Minnow is a tool for using DAM (Debug Accessory Mode), providing an interface to SWD or JTAG and/or UART from the device. It expands upon this concept to include a USB-UART and some utility for use within test rigs. It could be considered SWD over DAM with a sprinkling of USB cereal - unlike usb-cereal it does not use the Chromebook UART mapping in favour of maintaining USB-C rotational symmetry.

Enables and interfaces USB DAM configured in image below; Full SWD or JTAG over USB-C.
Provides board designer the option of using RX+ for NRST/RXD and RX- for SWO/TXD - either single-wire trace communication (RTT) or UART.
Four configurable GPIO on FT230 for test rig control of UUT: power enable; RX pin control; reset.
TagConnect TC2030 and ARM 10-pin header to debugger.
USB pass-through or FT230 USB UART to device.
VTARGET reference from device or external.
Maintains USB-C rotational symmetry.
Alternate Mode 3.1+ can still be used in the main application with normal hosts.

That’s the intro for the README.md. I’ll expand a bit more on why I made the device here. The debugger over SWD/JTAG is a pre-requisite when developing any custom embedded hardware, and is often required for provisioning said hardware - in volumes below pre-programmed microcontrollers. When designing a PCB, there is often a trade off between ease of debugger attachment and land. I’m a fan of the TagConnect system but even that is quite big and really should be reserved for out of form, initial dev boards. Another issue is that once the device is embedded the debugger header often cannot be accessed. In practice this is generally considered a bonus (security) but it can save the day after a dodgy DFU for example.

Most devices have a USB-C interface, which supports USB 3.1+ Alternate Mode. The Alternate Mode lines provide 5 lines (2 differential pairs and 1 low-speed signal), which provide a designer up-to 10 additional IO (not used as differential and rotational asymmetry). These pins are used by USB-C interface protocols such as DisplayPort, Thunderbolt and HDMI.

The USB specification even includes one for debugging; DAM - what we are talking about here. It’s up-to the designer how to implement it, the specification only covers how to enter DAM. Since the port is normally externally accessible and already taking up board area it’s a nice solution to solve the issues mentioned in the paragraph above.

Whilst it may not be ideal for the highest security devices - exposing an external interface to debuggers - the SWD/JTAG/readback could still be disabled with fuses in production firmwares (as it should be).

Original reference modified to include option of UART.

Minnow implements DAM by defining the SWD and JTAG interface over the Alternate Mode differential pairs and VTARGET over SBUS. Since there are four SWD lines and one for VTARGET, USB-C rotational symmetry is maintained 🙏. The Minnow hardware does the job of pulling the CC lines high with the pull-ups defined in the USB specification, so when connected to a supported target SWD is exposed on the 10-pin ARM and TagConnect headers.

The neat thing is that when the target is connected to other hosts, the DAM lines are out of circuit and the Alternate Modes can be used for a custom protocol. One could have a DisplayPort display for a example, with this Minnow DAM implementation to provide DFU.

Minnow enables DAM whilst forwarding the standard USB 2.0 differential pairs to the host; SWD can be used at the same time as USB communication in DAM.

I also added the option of using the extra SWD lines (NRST and TRACE, not required for programming/debug) for UART. This means the target device can forward a UART over USB-C for provisioning rather than RTT. For this, Minnow includes a FTDI FT230X USB-UART adaptor so no additional tools are required.

The on-board FT230X’s GPIO can also be used to control power to the target device, reset the device or control something else.

There is some circuitry required on the target device to support USB DAM and the Minnow configuration (see below). Essentially the target must detect when the CC lines are both pulled up with the values specified in the USB specification. Since normal cables do not connect both CC lines, the Minnow must feature a plug to connect directly to the target.

The example board uses two op-amps configured as non-inverting amplifiers to buffer this to a logic AND, which enables a 4-channel switch to connect the debug lines to the Alternate Mode pins. It must be honoured with the corrected values as the CC lines are used for all sorts of upstream and downstream control.

You can find a quick video demo below. The design is open-source but if you’d rather purchase assembled boards or just support my work, PCBAs are on my shop and Tindie.

Minnow schematic design. Full source available on GitHub

Example DAM switching on target. Some additional circuitry is required on the target device to implement DAM as per the USB specification; it could be reduced if not concerned about meeting the specification. The additional parts are not any bigger than most other debugging headers however, with the benefit of not requiring a bespoke plug - just a USB-C.

Adding gs_usb Hardware Timestamping to Kernel Module

Sat, 07 Jan 2023 00:00:00 +0000

I recently had to check a CAN node was providing a cyclic message within a 10% threshold of the defined period. Logging the messages, it appeared that it was slipping by as much as 25% at times.

In addition to a hardware specific logger, I was debugging with a SocketCAN ‘gs_usb’ compatible tool and wanted to ensure that the host OS was not introducing any timing error.

SocketCAN candump has a flag -H to enable hardware timestamps; timestamps from the capturing device rather than the host OS stamping upon receipt (software timestamps). When the tool provides a timestamp, it should be much closer to when the transceiver actually received the message¹. Timestamps provided by the host OS may be inaccurate due to preemption by a higher priority task before the USB packet is retrieved; it’s the time it was popped from the USB queue so the period that the OS got around to this is included. More on the Linux kernel net timestamping options

My USB CAN tool of choice is and my Entree board, which uses candleLight firmware. The problem was that adding the -H flag resulted in zeros. Digging into the firmware, I saw that it does support sending timestamps as part of the gs_usb packet but that the Linux kernel module did not yet use it.

The module that required changing was gs_usb. Contributing to something like Linux is probably the most intimidating but also rewarding things to do in open-source. It’s not something that is easy to jump into and so opportunities to actually change some code are few. Additionally, whilst it is mirrored on GitHub the collaboration process is still mailing list based so it’s not just a simple case of opening a PR in a nice web GUI!

To my benefit, one of the contributors to candleLight is also a maintainer of the CAN modules and was very helpful in pointing me in the right directions. It also meant I already had someone on-board to do the final merge request. Reading the excellent documentation first also got me a long way before submitting to the mailing list. In all, the process took around four months from identifying the problem, patching then finally it being merged and release as part of Kernel 6.1. Here it is in the Linux commit log (GitHub mirror) 😏. It’s actually quite involved as the timestamp sent is a tick count from a 32 bit timer, which requires a worker to maintain a datetime relative timestamp.

The process really epitomised why I love open-source:

Was quickly able to pin point what was missing and where by looking at the code. That’s not possible with closed-source tools.
The feature wasn’t present but I wanted it and it would benefit others to add it.
Good documentation meant setting up a development environment was quick and abiding to contribution guidelines easy.
Existing experienced contributors aided but hopefully were not burdened by a new feature being developed by someone else.
It all happened asynchronously, remotely and without any meetings in four months to being included in one of the World’s most used software.

Usage and Difference Illustration

One can check the timestamping capabilities of a tool using ethtool and a candleLight will now report support for hardware RX and TX.

> ethtool --show-time-stamping can0
Time stamping parameters for can0:
Capabilities:
        hardware-transmit
        software-transmit
        hardware-receive
        software-receive
        software-system-clock
        hardware-raw-clock
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes:
        on
Hardware Receive Filter Modes:
        all

During the development and following the released 6.1 kernel with the updated module, I ran some tests to illustrate the difference between using software and hardware timestamping. Using a STM32F4 device (external oscillator with 72 MHz main clock) configured with the sole job to send a CAN message every 2 ms from the SysTick ISR, I captured on the same interface with both candump can0 -l -H (hardware) and candump -l (software). The plots and statistics are generated using a quick Python script.

Click the graphs to view live but downsampled versions (too slow and large with all datapoints).

The box plot at standard zoom is not ideal because the spread is so different between the two. It does visually highlight how much more reliable hardware timestamps are over software ones however. One can see that a software timestamp > n * 2 ms will result in the following n timestamps appearing to be ~0 ms due to the system actually popping all the packets that arrived in the n * 2 ms period and stamping them all in quick succession.

One can see there is a pronounced difference in the accuracy of the timing; the software timing makes the device appear to be unstable. I did intentionally load the system and it was running in a virtual machine so is a worse case perhaps. It is still clear that if one is doing timing specific tests, hardware timestamps are very important if not critical².

# Hardware Timestamps
Max: 2025 µs
Min: 1977 µs
Stddev: 6.8 µs
Variance: 46.6 µs
Largest percentage slip: 1.25%

# Software Timestamps
Max: 7916 µs
Min: 1 µs
Stddev: 113.1 µs
Variance: 12789.7 µs
Largest percentage slip: 295.8%

In candleLight firmware, it’s when the gs_usb packet is queued - not perfect but good enough for most use cases. The resolution is limited to 1 µs. ↩︎
On a non-real-time kernel at least - it would be interesting to test with a real-time one. They should be more stable but could not beat the accuracy of the hardware supplied ones. ↩︎

Cyme - System USB Bus and Device Listing

Sun, 01 Jan 2023 00:00:00 +0000

cyme is a Rust CLI tool I developed for listing system USB buses and devices - a modern cross-platform alternative to lsusb. Here is the README intro:

The project started as a quick replacement for the barely working lsusb script and is my yearly Rust project to keep up to date! Like most fun projects, it quickly experienced feature creep as I developed it into a cross-platform replacement for lsusb. As a developer of embedded devices, I use a USB list tool on a frequent basis and developed this to cater to what I believe are the short comings of lsusb; verbose dump is too verbose, tree doesn’t contain useful data on the whole, it barely works on non-Linux platforms and modern terminals support features that make glancing through the data easier.

It’s not perfect as it started out as a Rust refresher but I had a lot of fun developing it and hope others will find it useful and can contribute. Reading around the lsusb source code, USB-IF and general USB information was also a good knowledge builder.

The name comes from the technical term for the type of blossom on a Apple tree: cyme - it is Apple related and also looks like a USB device tree 😃🌸.

Ceramic Nixie Tube Clock

Tue, 01 Nov 2022 00:00:00 +0000

It’s been six years since my Nixie Pipe project - my interpretation of a modern day Nixie Tube. Whilst the project was successful and has merit as an Nixie Tube alternative, an element of the inspiration was perhaps shying away from the electronic design challenge of a real Nixie Tube project.

So I decided now was the time to do the fabled project of an Electronic Engineer: a Nixie Tube project. Not to say it’s the most challenging electronics in the world, more that it’s a digestible one for a side-project with some interesting analogue and digital design choices to make; Drop-in hV supply or custom design? Shift registers and MOSFETs, hV LED drivers, hV shift registers or retro Nixie drivers?

The main interest for me was the hV supply and case design - since the case is where one can make it unique. Like my Linear Clock I ended up with two designs again! One is a CNC aluminium case with a solar indicator and the other is a 3d printed ceramic case - something I’ve wanted to try for a while.

Electronics

I wanted to design the high-voltage (hV) supply into the controller - rather than pick something off the shelf - as this was one of the more interesting aspects of the project. Using the excellent report by Tony as a reference, the controller features a LT3757EMSE configured as a flyback converter. It’s essentially the application example on pg.32 but with a digital pot in the feedback loop so that the controller can adjust the output voltage as required. I thought it might to be useful to control this to overdrive the tubes if required or adjust brightness but didn’t use it in the end.

The converter is most efficient at higher than standard USB input voltages so I added a USB-PD controller. It’s nice to have the option but in practice the clock works fine at USB-2.0 5 V/500 mA - I would probably DNF this circuitry next time.

The remaining design is something tried and tested for me: SAMD21 microcontroller, DS3232 RTC, logic shifters for WS2812B LEDs and Molex connectors for the touch buttons/IO. I’m happy to report revision 0 of the controller worked without any bodge wires 😁!

JBR Nixie Tube Clock Controller Schematic

Touch Buttons

Every clock needs a way to set it, which offers another area to play! I had a basic idea of how I wanted the case to look at this point and knew I wanted touch pads not buttons. The touch input was initially provided by the MPR121 on an external board. The part is end of life however and so I’ve since developed a direct to GPIO solution using the SAMD21’s QTouch peripheral.

The touch inputs connect to aluminium (not anodised for conduction unlike the case) touch pads.

IN-12A/B Carrier Modules

With the hV supply on the controller, it didn’t leave much land for lots of through-holes to mount the IN-12 tubes directly. Modules also allow quick replacement in case of burn out so this is the route I went down. The next choice was the switching method.

I explored shift registers with transistors, shift registers with high voltage sinking etc. but none had the right number of channels to be mounted directly on a module, complicating the routing. I came across the Exixie modules a while back and actually started making some so decided to base my modules on this. I replaced the STM32F0 part for a PCA9685PW - the same control but cheaper and no programming required. For redundancy, the controller and firmware actually supports both the SPI Exixe and I2C PCA9685PW - take that chipageddon!

JBR IN-12A/B Module Schematic

My IN-12A/B Nixie Tube module. A PCA9685BS 16 channel PWD controller, 10 BF820W NPN high-voltage transistors, RGB LED and passives. It’s footprint matches the Exixe and the addressing of the PCA9685BS allows upto 62 modules, so it’s not going to be a limiter. Low stack headers mean the modules don’t add much stack compared to being soldered straight into controller. I toyed with pin sockets but opted against in favour of better clearances. My controller left to right: LT3757EMSE configured as a flyback high voltage supply (170 V) with optional digital pot for uC setpoint control. STUSB4500 USB-PD controller for > 5 V input voltage to improve flyback efficiency - will work at USB-2.0 5 V/500 mA too. SAMD21, DS3232 RTC, IO and logic shifters for WS2813B LEDs.

Cases

With the electronics done, next was the part looked at every day. I went for a fairly simple rectangle with a bit of my own spin; nice radii and smooth lines. Up top are areas for two slightly raised touch pads. On the bottom, a foot tilts the case to an angle that is nearer to one’s eyeline when on a desk.

Initially I made a resin then aluminium case because these were easy to prototype. Something about ceramic and Nixie Tubes got me going though - maybe because ceramic is often used as a hV isolator? Finding Olaf at Seremik in Switzerland, he explained how to adapt the design and we made a ceramic version.

The ceramic one is one I like most. Whilst the solar clock part of the aluminium one is cool, I actually wanted to avoid LEDs in this project. Additionally, having been into ceramics when at school it feels like coming full circle in my life of projects. I actually made it as a 70th birthday present for my mother, to go with all my school ceramic pieces!

Aluminium Solar Clock

I intended the foot to be made from wood or plastic. Waiting for parts to arrive and wanting to do more with the sun clock function in my Linear Clock, I ended up making a translucent foot. An LED strip diffuses through the foot, with the sun (LED) moving from the left to right side throughout the daylight hours - repeating with a moon hue at night. The LED palette attempts to mirror the sun’s at that coordinate position. It’s best understood watching the video or animation below.

Midday the sun (LED) position is near enough middle. LED bar and tube illumination off In set settings mode the bottom bar is full magenta! The body is anodised, the buttons are not in order to isolate them from the case. Light diffuser foot. I have the intention of making a wooden foot too. Clear rear panel to show off the electronics but prevent accidental shocks. Yes I did shock myself more than once 🤦👈…

Dropbox folder with more photos

Printed Ceramic

Adapting the case for ceramic printing involved a bit of back and fourth. Unlike other 3d printing materials, the wet clay remains wet as it prints. The result is that supports aren’t an option, ruling out even minor overhangs like the radii on the case.

The front of the case is flat for this reason but I don’t think it takes much away as the imperfect, organic form of the clay adds interest. Talking of the imperfect form, the tube openings have enough tolerance for the tubes to fit and the wavy ceramic finish is not dissimilar to the blown glass tubes. It was hard to get the machined touch buttons in place however, without gaps (or only small ones)!

Unlike the machined case, which includes PCB mounts and tapped holes for the rear panel, neither were options for the ceramic case. Instead, I created a PCB carrier that is adhered to the ceramic and glued magnets to hold the rear panel.

Overall I think the outcome is great and it’s near to what I envisaged. I particularly like how the white glaze reflects the glowing tubes.

Dropbox folder with more photos

Video

Manual

Shop

Aluminium Solar Clock Ceramic Clock

Linear Clock

Wed, 16 Jun 2021 00:00:00 +0000

My latest clock project has been the longest and most challenging to complete. There have been times when I’ve been tempted to can it or thought I’d reached a dead-end but persevered. I had to keep reminding myself that I do these projects primarily for the challenge, to learn new things and to further my knowledge: if it were simple I wouldn’t have started.

Overall I’m now fairly happy with the outcome - an outcome which resulted in two designs! I’ve tried to compact the development’s interesting points into this post, which also serves as a sort of script for the video blog.

Idea and Concept

I was keen to build a mechanical clock ¹, as my previous designs have been light based. Having worked with flip-dot displays, the sound of a well orchestrated electro-mechanical system is very pleasing and this is something I wanted to achieve. It would also present the multi-domain challenges that I seek.

The solar Apple Watch face had drawn my inspiration for a while and I wanted to create a physical clock based on this. I was struggling to develop a nice way to present this however: I’d developed a sun clock based colour temperature of WS2812B LEDs but didn’t want another purely LED clock!

Ball bearings also peaked my interest and started considering how to build a clock around this, without it becoming a marble run. Again, I wanted sound but not actuation sound; only the sound of the ball rolling. How could I move balls without some form of actuation? Magnets.

Basic form sketch. The idea was two rows: one for fives of minutes and one for ones of hours. A ball in each row would move to indicate the current time using magnets. Combined with the sun clock, the shiny balls would reflect the colour temperature and make for a more interesting display.

At this point, I could design around an array of electromagnets from Aliexpress. I had recently come across PCB motors however and wanted to explore this. It would also allow for a compact and easy to assemble design. Of course, I wasn’t sure at this stage how well they would work with a gap between the PCB and attracting ball..

An ongoing idea board - it features some later developments. Shows some gauging for the clock sizing and consideration of shared channel 3-phase motor control rather than the independent h-bridge design that I ended up with.

Prototype One

So I started out designing a Coil Board and enclosure that would feature tracks above the PCB coils for each row. It would be controlled by a Controller via an umbilical connection. I opted to separate the boards for a number of reasons:

The Controller features designs I’ve tried and tested so I was confident I would not need to revise it. It had the most assembly so I could just build it once and move it to Coil Board revisions.
I was less concerned regarding EMF issues; 24 inductors next to the microcontroller didn’t seem nice!
It allows for debugging the Coil Board without the controller. Human in the loop and a power supply if required.
There simply wasn’t much space on the Coil Board. The design was already long with twelve coils and there wasn’t much space in the centre once the LEDs were added and ensuring a good ground plane.

Coil Board R0

In terms of electronics, the Coil Board was quite simple: a I2C PWM driver (PCA9685PW) per row to control each coil independently via a low-side switch (single direction) and a WS2812B LED strip in centre for sun clock and visual feedback. The challenge was in the coil design and layout.

I found Spiki a Python tool for creating KiCad spirals, which I used to create a 26 mm diameter coil with a 0.2 mm trace width. It required some fudging however to morph the output into what I could use for creating rows of coils.

Since it generated a PCB, I made this into a footprint with some vim since the KiCad editor does not allow multi-layer footprints. KiCad also does not allow vias in footprints so I ended up with a mix of footprint and layout, which I then used as a pattern using another script to create two rows of twelve coils.

The four layer PCB coil created with some scripts and vim! I had to layout the vias and tracks manually since these are not allowed in a KiCad footprint and then repeat this as a master pattern. Not before triple checking the current path is always the correct direction so as not to cancel it’s own EMF! The routing is quite tight when one factors in that JLPCB does not allow blind vias.

The full copper layout looks pretty cool!

Controller R0

Nothing too special:

STUSB4500 USB-PD controller for power supply: I’ve used this for a number of projects and it’s great. It keeps the power supply upstream but allows the controller to decide the input power - this was important as I wanted to tune the coil voltage for the maximum current the copper could take once I could measure the actual coil resistance.
SAMD21 microcontroller: My go to for Arduino compatibility. I added support for this chip to Arduino Makefile so it strikes the right balance for personal projects between being able to go low-level whilst relying on the Arduino eco-system.
Current sense for each row: For protection but I also had the idea that I may be able to detect the ball position based on the change in current due to the induced current in the ball.
DS3231 RTC: I could have used the RTC on the SAMD21 but it doesn’t have an easy to use RTC battery solution like the STM32 series. The DS3231 I’ve used in all my clocks so it was low risk.
Connected to the Coil Board via a Molex Pico-Lock system: I love these because they are small but carry high current; the 1 mm pitch/2 circuit is rated for 2.5 A! Each row has it’s own supply cable and I estimated with three coils the peak current would be 1.5 A per row.

Case R0

A render of the first design. With the PCBs fabricated in China, I perhaps got a bit ahead of myself waiting for the delivery - this would become the theme of the project!

I wanted a clean design so it’s a simple rounded rectangle - based on the PCB outline - with some indents at the front edge to indicate the positions. The tracks are profile cuts of the ball but offset slightly so the ball only contacts at the edges, in order to reduce friction and help the ball roll between pads.

When it came to printing (which I had to do in two halves due to print tray size) I opted to play with the track design. One is a smooth track and the other is wavey. The wavey idea was to create mechanical instability so that the ball would roll to the edge of the coil when the coil was switched off, allowing the next coil to pick it up. The centre thin section is for the LEDs - too thin and square in this case.

Testing

Testing started well, the coils worked! Control via the PWM controllers from the Controller also worked.

I got off to a good start: the PCB coils all worked and were controllable via the PWM controllers. PWM driving the coils wasn’t great as in combination with a magnet, they turned into a very unpleasant speaker! Even PWM frequencies above audible created noise. 100% duty solved this, which was ok as I found I had no need to module the driving.

What didn’t work was a ferrous steel ball, which I had based the design around; 20 mm carbon steel balls. The PCB magnets were too weak (generating ~1.5 mT at the PCB) to even hold a ferrous steel, let alone attract it through the casing. Not deterred, I used a neodymium magnet and this worked great. I can replace the carbon steel balls with neodymium of the same size, simple I thought…

The first hurdle with using a permanent magnet rather than ferrous steel was that it had poles and this meant single direction current control of the coil was not going to work. With the steel, I had hoped I could just shift the attracting coil down the row and the ball would roll with it. The magnet meant that it would have its poles aligned with the current coil and that the direction of the next coil needed to be the opposite. I turned to some (basic) FEM using FEMM.

FEM model of the PCB coil with balls illustrated but configured as air. One can see that the field lines from the active coil form such that the poles would be inverse on the adjacent pad. Turning on the next coil with the same polarity simply locks the ball on the other pad; the polarity must switch to attract the ball, something R0 did not allow.

More pretty colours! FEM model of the PCB coil with single neodymium ball. I’m not going to pretend I had to go much beyond the tutorial but I was pleased to find the model matched my measurements for Telsas generated by the PCB coil: ~1.5 mT on the PCB and ~1.0 mT through the case (0.6 mm).

I hoped the wavey track might counter this flaw, by causing the ball to rest between coils it would allow the next coil to pick up the ball. In practice it was not successful however. I tried a number of profiles but faced a few issues.

One was the increased material/air gap degrading the holding field strength and also struggling to get the ball stable when held. Another was that the track biasing had to be symmetrical (in order to work both directions) but this meant the ball would not always roll to the correct coil. It’s possible with more effort one could find a track profile but I opted for a different path.

I could not find a track profile that solved R0’s design flaws. This track had small peaks but also narrowing to make the ball less stable at the coils so that it would carry momentum between coils. The problem was biasing the roll in the correct direction, whilst maintaining bidirectional control.

Pondering over other mechanical advantages: inclining the track depending on direction, moving the magnet…all felt like over-complexity and dilution of the idea - I wanted the ball to roll with no apparent assistance.

Another attempt at salvaging the design was using iron core electromagnets. I found the perfect size for the design. Whilst this did hold a carbon steel ball, the air gap was still too large to attract the ball from another coil. At this point I was learning the hard way about reluctance and the magnetic field drop off in air!

Prototype Two

Prototype One showed the concept had potential but also flaws so I set out on a second design. The primary updates were to the Coil Board, the Controller could remain at R0 - the split paying dividends.

The Coil Board needed polarity control of the coils.
Current sense didn’t really work for position detection; current induced was negligible compared to coil current. I needed a better positioning method.
I had realised how important reluctance is and that the coil should be as close to ball as possible.
I had measured the coil resistance to be ~20 Ω. Based on the fabricated copper thickness peak 450 mA @ 9 V was about the limit before burn out. I say peak because the coil quickly warms up and thus its resistance increases, reducing the current.

Coil Board R1

The obvious way to get direction control of the coils was to ditch the PWM controller and MOSETS and to use a motor controller IC with internal H-bridges. The design decision here was what controller to use.

3-phase with three channels? I could wire the coils like a stepper motor rolled out flat and get away with just two controllers. The current demand would be high however as four coils would be on when just one is working, or eight in order to move (~7.4 A!). It might also corner me in the software control flexibility.

I decided against this 3-phase, mostly because the current demand would eliminate USB-C and the clock would require a massive PSU. There was the option of not sharing channels, but going down this track I opted to use a simple dual H-bridge IC: the DRV8833. I’d used it in a couple of other projects so knew how it worked, plus I liked that it features over-current limiting, clipping current control and fault indication. I would add hall effect sensors at each coil as a magnet position sensor - since I was now using magnetic balls not steel, this was an option.

Testing the DRV8833 control of coils with first board before redesign. I wanted to ensure that the DRV8833 didn’t fault, since the coil could be considered a short-circuit.

The next step was how to independently control each DRV8833. I would have six DRV8833 per row (one per two coils), each with five inputs and one output. A shift register came to my mind first, but would not provide read-back of fault or the hall sensors so I would require another chip just for this. Since the speed or timing of the coil switching was not important, I went for the MCP23017 GPIO expander: three per row, each controlling and reading the state of four coils via the DRV8833 and hall sensors.

Whilst the Coil Board was having quite the overhaul, the nice thing about using the GPIO expander was that it could be controlled over I2C and so the PicoLock cable to the Controller reminded the same. The firmware became a bit more complex, due to addressing the six MCP23017 in order to shift along the coil row but I created an abstraction layer that made this transparent as my first task.

Development and Testing

The assembled R1 Coil Board with DRV8833 H-bridge control via MCP23017 GPIO expanders and hall sensors below each coil is quite pleasing, even if I do say so myself - and only one bodge wire! It’s four layer so there is some hidden complexity below the solder mask.

The updated boards arrived, I assembled and to my joy the system worked! I had polarity control and sensing of all the coils via the Controller. With the wind in my sails, I set out developing the firmware. My approach to the firmware was to create a coil control abstraction, which a magnets state machine interfaces with.

The magnets state machine on a basic level, takes a seek position and moves the magnet to this location. It also constantly tracks the state of the magnet, ensuring that it is always where it should be, if it is missing or if the system is faulting.

Movement is achieved by enabling the next coil in the direction of the seek position, with the opposite polarity of the current coil. The current coil is disabled and the ball movement is detected by the hall sensors. The movement event causes the state change, this allows the system to detect when the magnet is stuck and act accordingly. Once moved, the brake state enables coils either side of the position to help stop the magnet.

Demo of magnets state machine with LED debugging enabled. Green: hall sensor active; Blue: coil enabled with north polarity; Red: coil enabled with south polarity.

Another state machine linear-time, controls the clock state and sets the magnets FSM based on the time. It also controls a configuration state, which allows one to set the time and other run-time parameters.

Separate to all this is the solar clock I designed that sets the hour position LED colour temperature based on the solar cycle:

night -> dawn -> sunrise -> day -> sunset > dusk -> night

Solar cycle showing the sunrise using a blended sky colour palette, emulating each phase of the day. See the demo reel for a clearer view.

It does this completely offline, based on a set longitude and latitude using the sunset lib - pretty neat! I created the FastLED colour temperature palettes using sky palettes kindly provided here that are mapped to each day phase, mixed as they intersect.

Balls…

You may have noticed that the above video shows only one magnet…I’m embarrassed to say, I became so focused developing this that I developed the whole thing with only one magnet. I started with one row during bring up and just didn’t think to try the other row since it was just a mirror of the first. I also have the excuse that my original design was without permanent magnets so interaction between rows was not an issue.

If you haven’t worked it out, the magnetic field of the neodymium magnets is magnitudes (100x) larger than the PCB coil. The air gap between the rows is not enough to prevent 15 mm neodymium magnets interacting with each other 🤦. In hindsight, this is obvious and I may appear an idiot but I guess it’s an example of a design in flux (pun intended!) and becoming too focused on the development once one gets a sniff of success!

Above was a low point in the project for sure. I took a break, unsure how it could be salvaged. I considered how I could change the magnetic properties of the ball:

Heating the ball in the oven I had read can permanently reduce magnetism of neodymium - not for me or at not enough to make a difference.
Hitting the balls I also read can affect a permanent magnet due to change in the crystal alignments. No joy.
Making a carrier ball with smaller neodymium magnets at the pole positions. It didn’t really roll well.
Permanent magnets not made from neodymium or at least not 100% neodymium to reduce the magnetic field for the same volume. I found one can get sintered ferrite magnets that can be tuned to the required field strength. These are nice because they have a mirrored finish unlike a 100% ferrite magnet and are not quite as brittle. They are expensive however!

The carrier ball and sintered magnets did offer a solution. The problem, was the trade off when selecting ball size. A large ball has more inertia and so is harder to control and move - it does offer a larger field strength however, so is more attracted to the coil. I wanted a large ball (15-20 mm) as this was the intended design. Small balls made the clock harder to read from a distance and make a more pingy sound.

I now have a lot of magnetic balls. Exploring the different trade offs between ball diameter, inertia and magnetic field strength. I’ve included the 3d printed carrier balls in this photo too.

The ball size also has an impact on the control system/PCB geometry, as the circumference/2 should be a close factor of the coil pitch in order to roll into the next coil with the correct polarity.

After a lot of testing, the only ball I could get to work reliably on the current design was a 5 mm neodymium. It didn’t look bad but the small balls just felt like too much of a compromise. True to current tech trends, I decided I’d keep it at that but call it ‘Linear Clock Mini’ or something and work on a re-design.

Demo reel of the Mini design. Whilst the small balls dilute the design somewhat, I still think it has a place in a small room or on a desk.

Prototype Three

Not fully satisfied with the Linear Clock Mini. I explored some options for a clock with the original large balls I had designed for.

Sledge

One idea that seemed feasible and would maintain the same exterior was to sandwich a magnet between the case and PCB. The magnet would move along an inner track - driven by the PCB coils - and pull a carbon steel ball above. It would be a multiplier for the PCB coil of sorts.

Sandwiching a flat magnet between the ball track and PCB was something I tested. Here a small magnet is shown to move with a steel ball magnetically attached - the case would sit between the two.

In practice, whilst it did sort of work, the ball would scrape along the track rather than roll. In addition, friction of the magnet in the sandwich and due to the clamping force to the ball meant it wasn’t all that smooth. I also suspected I would encounter issues with magnet size and proximity to the parallel sledge again, due to the size magnet I would require.

Split

Creating a larger air gap between the rows was the other feasible idea I had and decided to go with. It was guaranteed to work, the challenge was finding the minimum air gap and maintaining a nice design.

I turned back to my FEM model and back it up with real-world testing to find the minimum air gap such that the PCB coils would overcome the interaction between the two magnets. By stepping the design and moving the gap into the diagonal, the effect on overall width was reduced slightly. The step also creates a better area for the position indicators, LED and easier viewing of both balls when reading at eye level so wasn’t a complete compromise.

Verifying the FEM modelled air gap required for a 15 mm sintered ferrite ball, before committing to the design.

Coil Board R2

The R2 schematic matched R1 since it worked - the change was purely mechanical. I created a split and cut lines in order to detach the rows from each other. One might wonder why I didn’t just create symmetrical PCBs for each row. I opted for a single board with cut so that I could use the board in a wide flat design if I desired; I could keep a single connector to the Controller without changing that design; to minimise changes in the layout/tracking at this stage.

There were very few hardware issues in the design process. There was one gotcha in the split that did require some hardware debugging: the cut disconnected the top layer ground plane, resulting in the DRV8833s working at low power (5 V/3 A) but not the intended 9 V/3 A. A good lesson that a bad ground return can allow something to work but not work well.

Stepped Case

Overview of the Max model. I think I made the most of the forced geometry and it did not become too cumbersome. The track features tees to aid keeping the ball in position.

Prototype Three demanded a completely new enclosure design. Nothing too complex though: again based on the PCB outline to minimise size but with a slope based on the calculated minimum air gap + fudge factor between the rows. I made full use of the slope to make the position indicators clearer with an LED light diffuser between them.

The ferrite balls have a dark gray appearance so for this design, I requested a gray anodising to the aluminium machined base to match.

It Works!

I placed the order for the printed top and machined base then crossed my fingers. When they arrived, I was dreading the test but thankfully, it worked! The big balls were controllable through the full clock cycle. The firmware for both designs is the same, apart from some different timing values for the motion due to the different ball inertia.

There is minor interaction between the rows on both the Mini and the Max design - more so on the Mini in fact. With the motion sensing however, the controller can overcome this. It flips the parallel row to ensure the poles are opposing one another and will re-attempt a move if stuck - this can be seen in the demo videos. Running at accelerated speed for the demos, this is more apparent as the coils and balls warm up and the control is less effective. I think the repeated movement is almost part of the charm.

I’m pleased with both designs. The rolling noise is different but pleasing on both; a fast swipe on the Mini and a grand roll on the Max due to the increased inertia. Each fits a different space.

Demo reel of the split and stepped Max design. The increased air gap allows the clock to work with 15 mm balls, which was my original design intent.

The Max design involves some soldered connections unlike the Mini. I would probably change the interconnects if I were to revise this, so that both boards connect directly to the Controller.

Final Design Gallery

Mini

Max

mechanical in the non-static sense rather than internal cogs and gears. ↩︎

Same Same but Different

Thu, 06 May 2021 00:00:00 +0000

I’ve migrated this blog from Wordpress to Jekyll. Wordpress worked but since I write everything in Markdown before posting it, Jekyll fits into my workflow better. Wordpress become overkill and slow or my needs; it’s not really designed for power users and I didn’t use most the features. In addition, Wordpress required plug-ins like Jetpack in order to prevent an overwhelming amount of SPAM and I didn’t like having an external analytics tool harvesting data ¹. I’m a proponent of just not having tracking cookies rather than cookie banners that everyone hates - it’s an easy and intended solution.

On a similar note, I opted not to include or support comments in the migration. Whilst I have enjoyed the discussion and feedback I’ve had with readers over the years, it’s hard to find a good privacy focused comment host. It is a shame to loose this as the public comments often keep posts up to date or add things I may have missed but unless I find a nice and easy to implement static comments system, it’s email only for now.

The blog is almost ten years old now! Going back through the archives, there is some embarrassing stuff and it’s certainly not representative of my current skill set but I opted to keep them, as a record of my progression as an engineer if nothing else.

I hope to continue updating this blog with personal projects for at least another ten years. I already have a couple of projects in my backlog I’m excited to write about and the Markdown -> blog post should lower the barrier to this.

Wordpress to Jekyll Migration

There are a number of posts around for this so I won’t go too deep. It was not quite as simple as running a plugin however!

Install the Wordpress to Jekyll exporter plugin.
Find out this doesn’t work on the production site and so export the SQL database and spin up a Docker wordpress container:

services:
    wordpress:
      image: wordpress
      restart: always
      ports:
        - 80:80
        - 443:443
      environment:
        WORDPRESS_DB_HOST: db
        # I changed these to match the hosted database (in 'db' service too) but not sure it's required since the wp_config is created for the service
        WORDPRESS_DB_USER: db_user
        WORDPRESS_DB_PASSWORD: db_password
        WORDPRESS_DB_NAME: db_name
      volumes:
        - ./wp-content/themes/my-theme:/var/www/html/wp-content/themes/my-theme # mapping our custom theme to the container
        - ./wp-content/plugins:/var/www/html/wp-content/plugins # map our plugins to the container
        - ./wp-content/uploads:/var/www/html/wp-content/uploads # map our uploads to the container

    db:
      image: mysql:5.7
      restart: always
      environment:
        MYSQL_DATABASE: db_name
        MYSQL_USER: db_user
        MYSQL_PASSWORD: db_password
        MYSQL_RANDOM_ROOT_PASSWORD: '1'
      volumes:
        # put the exported .sql database in ./docker/ and it will be imported
        - ./docker:/docker-entrypoint-initdb.d

Realise the local site attemps to re-direct http -> https when using ‘/wp-admin’ so:

docker exec -it engineer_db_1 bash
mysql --user=root --password=ROOT_PASSWORD # where the password is the root password displayed when the serice is started
use db_name
SELECT * from wp_options WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_options SET option_value = 'http://localhost' WHERE option_name = 'home' OR option_name = 'siteurl';

Fix all the exported Markdown post asset links and inline html using a mix of vim macros and fd . _posts/ --type f -e md --exec sed ...; the exporter does not do this…

I didn’t have the time nor inclination to dig into exactly what, but if it’s free… ↩︎

Entrée USB-C CAN Bus Interface with USB-PD

Tue, 16 Mar 2021 00:00:00 +0000

Entrée - like a Canapé but tastier…yes the logo is, and name was, Canapé but I didn’t want to face a Trademark dispute over an acute e for a hobby project…

The Entrée is a USB-C CAN interface. It is a variant of the open source candleLight platform and its many spawns. Not only does it add USB-C, it brings new features and CAN/USB controlled USB-PD for powering devices under test.

This post is a copy and paste of the README.md - the repository one should be used as the source of truth. I thought I’d share it here for the record, as it is both a useful and interesting project.

Features

Compatiable with:
- gs_usb firmware candleLight_fw; Linux mainline native support.
- slcan cantact; Linux CAN over USART/CDC.
USB-C connection for use with modern hardware.
USB-PD negotiation for powering devices rather than using USB communication interface. Up-to 20 V/1 A can be requested and supplied to a device.
Switched control of 120 Ω termination resistor.
Switched control of DFU mode and TagConnect 6-pin ISP for use as a development tool.
USB-PD profile and device setup using switched internal CAN IDs.
USART test points for SLCAN without USB.
Two signal connector choices.
Small form factor: 55 x 18.5 mm.
Silkscreen art 🎨!
Web-DFU firmware update/selector tool.

Purchase

Usage

Hardware Connection

The primary CAN connection is a Molex Picoblade 53261-0471.

The connector was selected because they are commonly used on Drones and so Picoblade to 0.1” header cables can also be easily obtained:

1 Bit Sqaured Black Magic 0.1” female cable.

Alternatively, one can obtain pre-crimped female cable assemblies 15134-0402 or female 4-pin housing 51021-04 for custom cabling.

A secondary unfitted JST SM04B (otherwise known as Qwiic/STEMMA) footprint is available on the bottom of the board if one wishes to use those commonly available cables instead. JST pre-crimped part is A04SR04SR30K152A.

Wiring Example

Below is a wiring example showing the Entrée Picoblade and JST pinout. A Black Magic 0.1” female header cable is connected to the Picoblade and standard STEMMA QT connected to the secondary JST header. Note both cable colouring is non-standard due to optimal board layout.

Software

A Vagrant virtual machine environment is provided in the ./linux-vm folder for those on non-Linux hosts or who want a pre-configured environment. Install Vagrant and VirtualBox and then setup the machine from within the ./linux-vm folder with the vagrant up command.

Linux SocketCAN

Entrée comes with candleLight firmware which is intended for use with a Linux host. Most Linux distributions include the gs_usb driver and can kernel modules by default so getting started is very easy.

Create CAN network interface [ref]

sudo ip link set can0 type can bitrate BIT_RATE # where BIT_RATE is the CAN bus speed in b/s
sudo ip link set up can0

CLI

Install can-utils using one’s package manager and then various command line tools are available.

cansend can0 999#DEADBEEF   # Send a frame to 0x999 with payload 0xdeadbeef
candump can0                # Show all traffic received by can0
canbusload can0 500000      # Calculate bus loading percentage on can0
cansniffer can0             # Display top-style view of can traffic
cangen can0 -D 11223344DEADBEEF -L 8    # Generate fixed-data CAN messages

See the can-utils README for more.

Cangaroo GUI

The Cangaroo GUI can be compiled for Linux hosts. See Cangaroo.

Windows

To use the default candleLight firmware on Windows, one can use Cangaroo: Pre-compiled Win32 binary.

Alternatively, to use SocketCAN one can use the pre-configured virtual machine explained at the start of the Software section.

Python

The python-can module supports SocketCAN (candleLight), slcan and PCAN devices so options for all hosts are covered - see the configuration page.

Paired with the cantools module, one has access to powerful CLI tools and scripting for CAN bus operations including use with database definition files.

Both modules are pre-installed in the Vagrant virtual machine.

DIP Switches

The 4 bit DIP switch sets unique runtime settings when in the ‘ON’ position; for normal usage as a CAN bus probe these would be ‘OFF’.

Switch	Decimal	Set Action
1	1	Force bootloader for DFU.
2	2	Enable Entrée internal configuration CAN IDs.
3	4	Enable VBUS -> VBS always not just when USB-PD profile valid.
4	8	Enable 120 ohm CAN_H/CAN_L termination resistor

NOTE both DFU and ‘Enable VBUS’ will require power cycling the device for the change to be reflected.

USB Power Delivery (USB-PD)

The on-board USB-C controller (STUSB4500) is configured for 5 V / 1A power delivery by default (PDO 2). One can configure the controller using the below CAN bus commands when using the candleLight_fw fork and with the internal CAN IDs switch set. Please refer to the candleLight_fw Entrée fork README for usage.

Firmware

candleLight_fw Entrée fork - [BIN DOWNLOAD]: Default firmware shipping with Entrée. Works with Linux SocketCAN and the Cangaroo GUI. Includes support for configuration of the on-board STUSB4500 USB-C controller and DFU without setting DIP switch.
cantact_slcan: slcand is a USART CAN daemon for Linux, which emulates a CAN network socket over USART. The pre-cursor of the candleLight_fw and gs_usb driver, it offers no real advantage since it is still over USB as a CDC. I’ve found it to drop frames at common bus rates and so do not recommend it. USART pins are exposed however if one wishes to play with slcan over physical USART. A virtual network interface can be created: sudo slcand -o -s8 -t hw -S 3000000 /dev/ttyS0 and then used like a SocketCAN interface.

Update

Web Updater

Use the Web-DFU tool provided here: https://www.jbrengineering.co.uk/web-dfu/

Manual CLI

Enable the DFU DIP switch and then issue the following command with dfu-util:

sudo dfu-util -d 0483:df11 -c 1 -i 0 -a 0 -s 0x08000000 -D $FIRMWARE_FILE.bin

Where $FIRMWARE_FILE.bin is the firmware file to be updated. Binaires are stored in the ‘./bin’ folder of this repository, so to flash:

sudo dfu-util -d 0483:df11 -c 1 -i 0 -a 0 -s 0x08000000 -D ./bin/entree_fw.bin # candleLight_fw

Credits

The open source CAN community is large and this project adds to that in the true spirit of open source. The canable devices (of which I have many!) started me on my journey into CAN hardware and software development. Entrée fixes areas I felt could be improved upon and brought up-to date.

Please find links below to projects that have supported the development of the open source CAN ecosystem.

Should get you started down the rabbit hole!

Game of Life on a Flip-Dot Display

Tue, 28 Apr 2020 11:41:59 +0000

With the passing of John Conway, I decided to add ‘Game of Life’ to a Flip-Dot project I’m working on, in honour of his work.

I show a couple of random starts, a start from text ‘Hello!’ and a start with some known forms.

Physical display is an Alfa-Zeta XY5 28×14. I’m building it into a much larger display (252×56) so I develop with a curses based simulator most of the time. I show Game of Life running in this at the end, the larger area allows for some known persistent patterns at start.

Uses Python PIL based driver: https://github.com/tuna-f1sh/flipdot
With custom async display manager, Game of Life functions: https://gist.github.com/tuna-f1sh/9e6ff4552f75de3705cae6d3c044b1cc

Pi-Hole and Smokeping using Same lighttpd Service

Mon, 09 Dec 2019 17:10:03 +0000

I was having random – or not so random – internet dropouts on a 4G WiFi router. I wanted to ascertain when they occur and if it’s internal wireless or WAN to troubleshoot. smokeping is an old but useful tool to capture this as it sits in the background constantly pinging pre-defined servers.

Since I had a Pi-Hole on the network, this seemed the best tool. Getting the web-portal up and running requires some tinkering however to run as part of the existing Pi-Hole lighttpd web server.

Turns out the correlation is with trains and rush hour! I live near a train station and as a train comes to the station at peak times, the contention ratio on the 4G mast must go through the roof and my internet crawls…Either that or the electric train lines are EMC bandits!

Warning: Steps below worked on PiHole 4.0 and were captured post-process for my own documentation; it is not a concrete guide and some system knowledge is probably required

Install Smokeping

sudo apt install smokeping

Smokeping Setup With Pihole Lighttpd

# enable cgi
sudo ln -s /usr/share/smokeping/www /var/www/html/smokeping
sudo cp /var/www/html/smokeping/smokeping.fcgi.dist /var/www/html/smokeping/smokeping.fcgi
echo 'exec /usr/lib/cgi-bin/smokeping.cgi /etc/smokeping/config' >> /var/www/html/smokeping/smokeping.fcgi

Setup Fast cgi /etc/lighttpd/conf-available/10-fastcgi.conf

fastcgi.server += (
  "smokeping.fcgi" => ((
    "socket"   => "/var/run/lighttpd/fcgi.socket",
    "bin-path" => "/usr/share/smokeping/www/smokeping.fcgi"
  ))
)

sudo lighttpd-enable-mod fastcgi
sudo /etc/init.d/lighttpd force-reload

Check Route

http://localhost/smokeping/smokeping.fcgi

Redirect Smokeping Route to Fast cgi File

In /etc/lighttpd/lighttpd.conf

$HTTP["url"] =~ "^/smokeping/" {
         url.redirect  = ("^/smokeping/?$" => "/smokeping/smokeping.fcgi")}

Now one can simply navigate to pihole.local/smokeping

Whitterm-220 2.0

Sun, 30 Jun 2019 15:54:08 +0000

Having used my clever serial terminal – the WT-220 – for a few years now, I’d identified improvements I wanted to make. I was never that pleased with the cobbled together electronics (based on what I had laying around and ability at the time) and with PCB fabrication accessible to hobbyists now thanks to China, I decided the main win would be a Raspberry Pi Hat.

The rear panel wiring made opening the thing up a dread, so this was the main item I wanted to fix. Thinking about how to simplify the connection between the Hat and the RPi, I came around to the idea of ditching the acrylic rear panel entirely in favour of PCB mount upright connectors – the PCB would be electronically and mechanically part of the design.

As with all good hobby projects, I got quite carried away with adding bells and whistles but the rear panel functionality and resulting WT-220 has been greatly improved overall. It was a nice slow burner project to fill time gaps moving to Switzerland at the start of the year. I enjoy these sorts of projects, cementing knowledge I’ve developed in professional work and exploring ideas one doesn’t always have time for.

WT-220 Rear Panel IO Hat

The hole is for a panel mount USB.

The (hand) populated rear panel.

40-pin IDC cable to Raspberry Pi is a much nicer solution than before.

Features

USB-C input for USB-PD high current (3 A) supply to RPi. LEDs indicate detected current profile from UFP. I2C lines made available to SAMD for playing with USB-C device modes.
MAX3232 RS232 transceiver provides RS232 level interface to RPi UART and SAMD UART.
SAMD21 microcontroller provides boot button control of RPi over I2C and buffered IO (2 0-10 V inputs, 2 OC outputs, 2 24 V inputs and 1 0-5 V output). Can be programmed over USB-C CDC-serial device or ISP.
Control of RPi power supply from SAMD. Off by default allows safe start up, only when power input suitable/ready.
DIP switch control of device UART connections (SAMD, RPi, RS232).
Board replaces laser cut acrylic back piece from original design – it is both electronically and mechanically integrated.
Lots of status LEDs 😃.

USB-C

The original WT-220 with DC jack input going to buck-converter for 5 V wasn’t ideal. It was always frustrating attempting to find the right jack, the jack coming loose or if using Micro B USB, finding an adaptor to supply the > 2.5 A required by a RPi 3 B+ & screen – the worse thing was that if the supply was flaker, it might power up then brown out during use.

I had been wanting to implement a USB-C board in order to understand the interface, so this became the project. The great thing about USB-C is that the upstream device can provide information on the power available to the downstream device. By configuring the CC lines, one can set or detect what current is available and act on this. I opted to use a controller – the TUSB320 – to handle this, with LED indication of current mode detected.

Using the GPIO mode of the TUSB320 and LEDs, one can visually show the USB-C current mode. Here both LEDs indicate full 5 V/3 A. This could be read over I2C and the boot button restricted if power to low.

With the SAMD controlling the power supply to the Pi via a MOSFET swtich and I2C connection to the TUSB320, one can prevent boot up of the Pi until a suitable upstream supply is detected. For something like the WT-220, the LED indication is enough as I’m the only one using it. For a user consumer product however, this is great as it removes the ability to plug in any old phone charger and then the device appearing to not work properly.

Turns out I wasn’t the only one thinking down this path. Since developing this board and in the process of writing this post, the Raspberry Pi 4 has been released with a USB-C port replacing the Micro B. I’m not sure if the new Pi uses current mode detection to prevent start up like suggested above but it would be logical.

Firmware

The SAMD firmware is pretty simple. As said, it controls the power to the Pi and then an I2C communication between the SAMD and Pi allows LED boot status and shutdown/power off control. See below for a basic (messy) state diagram.

Raspberry Pi maintains I2C link with uC once booted and acts on shutdown request from button press. The LED flashing routines were the most complex part of the firmware development!

The other thing the firmware does is provide interface to the buffered IO.

Raspberry Pi

I opted for Raspbian Lite rather than Arch for this updated build. The support for ARM 64 bit is better and the Lite variant still means I could install only what I wanted.

For the install, I used I3WM since it’s a keyboard based terminal. I then compiled and installed cool-retro-term for the CRT look.

The rest of the image is fairly standard, bar a few services I created and config scripts (all can be found in repo:

boot: Runs shell script that displays boot ascii logo.
i2c: Runs python I2C script (wt220-i2c.py) that configures case LEDs to act on RX/TX and then maintains link with I2C link with SAMD. Polls shutdown request state and acts on request by issuing system shutdown.
poweroff: Runs on shutdown.target and issues the final I2C shutdown command so that SAMD disables RPi 5 V.

Wooden Bits Binary Clock FPGA Port

Sun, 23 Dec 2018 12:45:27 +0000

In attempt to get started with FPGAs and Verilog, I decided to port Wooden Bits to a Lattice IceStick – selected because of the Open-Source IceStorm toolchain. Counters and flip-flops are the first thing one learns when starting with FPGA design, so the project lends itself naturally. I learnt things FPGAs are good at and things they are not so good at – best done on a microcontroller. As the project was educational, there were many learnings along the way and invariably still to be learnt; it is not intended as a best use of FPGAs or implementation.

The most enlightening part of the learning and what finally kicked me to do the project, was the PicoSOC project and in particular, Matt Venn’s addition of a WS2812 peripheral to the PicoSOC. The idea of rolling one’s own peripheral for driving external hardware into a SoC or only adding the required ones is new ground for me. The concept also really helps to cement what is actually going on when accessing registers during development of embedded software.

Binary Clock Counter Design

A binary clock is essentially a frequency divider, which can be formed using D-Type Flip-Flops, each data line clocking the next. In order to reset the 4 bit counter at 9 (or the other digits for time), a modulo 9 counter is created by using an AND gate driving reset with bits 1 & 3 (as it clocks 10). This is assuming the D-Type is asynchronous (will reset on reset edge). If it were synchronous, the AND gate must be connected to bits 0 & 3 (9), such that the reset will be clocked as it would be counting 10. The difference becomes quite important in Verilog, particularly when driving the next digit modules with the reset signal.

24 hour ninary coded decimal (BDC) clock design. LSB/digit on left. A binary clock is first a frequency divider, which can be created by changing Flip-Flops together. A modulo counter is created by using a logic gate driving reset of synchronous D-Type Flip-Flops. The time is 00:03:38 in this screenshot.

It’s good to start with a logic diagram of what one is trying to achieve so I drew one up in Falstad (import this file). To implement this, I designed a counter module for each digit that is asynchronous (reset on reset edge), so that the reset line can directly feed the next digit module. Initially, my approach was synchronous (read reset on clk edge) but this meant having to have a ‘carry’ output on reset to clock the other digits at the correct time (otherwise they would clock one digit a head of the desired value).

Test bench timing diagram for synchronous reset digit module. The reset wire turns the counter into a modulo BCD module. Since the design is synchronous, the reset signal cannot be seen – unlike the asynchronous plot below, where it lasts for one clock cycle. The wire will instantaneously (in theory but not in physics…) reset one digit (causing it to clear) whilst driving the next, since it is hardware logic. This is one of the key differences between microcontroller variables and FGPA design.

The asynchronous Flip-Flop design results in the proceeding digit being one clock out of phase. I did originally remedy this by including a _modulo_ output bit, that asserted as the reset signal was clocked. It is the equivalent of adding an additional Flip-Flop to latch the reset in the simulation as a clock source for the next module.

Interestingly, one could use a single counter register rather than individual modules. I developed an alternative based on this idea, using bit logic to clear/increment bit addresses. The advantage is that it only uses 13 bits rather than 16 bits. Other than this, the modular system synthesis should resolve down to the same thing (something that looks like the Falstad simulation), since the reset inputs driving each module are just wire bit logic as in the massive if, else. I think having modules for each digit helps with readability and helped with learning the module aspect of Verilog.

module counter(
  input clk,
  input rst,
  output [BITS-1:0] digit);

  parameter BITS = 4;

  reg [BITS-1:0] digit = 0;

  always @ (posedge clk or posedge rst) begin
    if (rst)
      digit <= 0;
    else
      digit <= digit + 1;
  end

endmodule

/* seconds (4 and 3 bits but leave all) */
wire [3:0] ds0;
wire rst_ds0 = ((ds0[1] & ds0[3]) || reset); // 10
counter s0(clock_clk, rst_ds0, ds0);
wire [3:0] ds1;
wire rst_ds1 = ((ds1[1] & ds1[2]) || reset); // 6(0) minutes
counter s1(rst_ds0, rst_ds1, ds1);

/* minutes (4 and 3 bits but leave all) */
wire [3:0] dm0;
wire rst_dm0 = ((dm0[1] & dm0[3]) || reset); // 10
counter m0(rst_ds1, rst_dm0, dm0);
wire [3:0] dm1;
wire rst_dm1 = ((dm1[1] & dm1[2]) || reset); // 6(0) minutes
counter m1(rst_dm0, rst_dm1,  dm1);

/* hours (4 and 2 bits but leave all) */
wire [3:0] dh0;
wire rst_dh0 = ((dh0[1] & dh0[3]) || rst_dh1 || reset); // 10 or tens of hour reset
counter h0(rst_dm1, rst_dh0, dh0);
wire [3:0] dh1;
wire rst_dh1 = ((dh1[1] & dh0[2]) || reset); // 2(0) & 4 hours
counter h1(rst_dh0, rst_dh1, dh1);

The Falstad simulation realised in Verilog as a per digit synchronous reset module.

module binary_clock(clk, reset, ce, count);
   input clk, reset;
   input ce;  // count enable 
   output [13:0] count; // two digit bcd counter

   reg [13:0] count;
   wire [3:0] d0 = count[3:0];
   wire [2:0] d1 = count[6:4];
   wire [3:0] d2 = count[10:7];
   wire [1:0] d3 = count[12:11];

   always @(posedge clk or posedge reset) begin
      if (reset) begin
         count <= 0;
      end else begin
        if (ce) begin
           if (count[3] & count[0]) begin // 9
              count[3:0] <= 0;
              if (count[6] & count[4]) begin // 5
                count[6:4] <= 0;
                if (count[10] & count[7]) begin // 9
                  count[10:7] <= 0;
                  if (count[12] & count[8] * count[7]) begin // 2 & last 3
                    count[12:11] = 0;
                  end else begin
                    count[12:11] <= count[12:11] + 1;
                  end
                end else begin
                  count[10:7] <= count[10:7] + 1;
                end
              end else begin
                count[6:4] <= count[6:4] + 1;
              end
           end else begin
              count[3:0] <= count[3:0] + 1;
           end
         end
      end
   end
endmodule

Alternatively, one module to do all digits but with 13 bits rather than 16 bits.

Binary clock timing diagram over almost 24 hours. The LED matrix wire contains the bits arranged to match how the clock display is wired. They are not in digit order but the half frequency of each bit is quite visible.

For development, the clock input to the first Flip-Flop is taken from a divided down master clock (12 MHz) to form a 1 Hz clock. For actual deployment on the bench, I added an additional clock input pin for driving from an external 1 Hz clock generator such as can be found on RTCs.

Wooden Bits FPGA Port Button

WS2812 LED Matrix

My original design uses sixteen one-wire WS2812 LEDs chained through the laser-cut wood to form an addressable LED matrix. WS2812 LEDs simplify wiring and hardware complexity over standard LEDs, at the cost of CPU cycles: The one-wire interface sends 24 bit colour data for each LED by modulating the period of high/low in a serial data stream. Each LED takes the first 24 bits,then sends forwards the rest of the data to the next in line. Since microcontrollers don’t have a peripheral specifically designed to do this, it is normally done using Timers and match/overflow interrupt routines.

An FPGA can make light work of this however and my real interest peaked with the idea that one can make a WS2812 peripheral with no processor overhead.

// map bits to matrix in snakes and ladder formation...
assign led_matrix = {
    dh1[3], dh0[3], dm1[3], dm0[3],
    dm0[2], dm1[2], dh0[2], dh1[2],
    dh1[1], dh0[1], dm1[1], dm0[1],
    dm0[0], dm1[0], dh0[0], dh1[0]};

for (i=0; i<NUM_LEDS; i=i+1) begin
    led_rgb_data[24 * i +: 24] <= (led_matrix[i] | rainbow) ? display_rgb : 24'h00_00_00;
end

The binary clock face only needs to set LEDs on or off. I created a fork of Matt Venn’s WS2812 module that can access the LED colour register directly so that the code then does a mask operation using the digit registers on each update of the digits (1 Hz in standard operation). The main real overhead driving the LEDs is the size of the colour register that is 24 * N bits, where N is the number of LEDs. The FPGA must latch this data, as it can change at different clock edges. I experimented with various different modifications to the code, each with it’s merits but settled on the direct setting of the RGB register for this project.

Clock Features

Set Button

The set button was easy to port: I added an input to the top module connected to an IO pin and a button with hardware pull-up and debounce – hardware is a key point here, I did both on the uC previously. If the button is pressed, the clock source to the first counter flip-flop changes to one that is running at 1000 Hz (using a counter based divider) and the display colour changes red. Releasing the button returns the clock to the normal state. This allows a user to quickly advance the clock to the correct time.

/* binary clock source is either clk_1 (external 1 Hz) or clk_2 (1 kHz) if button is pressed */
wire clock_clk = CLK_1HZ ^ (clk_2 && ~BTN);

Whilst it was an easy port, the user interaction is much less refined compared to the software version. My software design features a delay before advancing at accelerated time so one can button press through minutes when near the correct time, or hold the button to advance quickly. It will also wait in set mode for a few seconds on release before setting the new time. Additionally, the set button can be used to set the main display colour.

Wooden Bits FPGA Port Button

These advanced interaction would all be possible on the FPGA but the design would become somewhat messy and it would need to be carefully implemented as to avoid FPGA bad practices (there are some big pitfalls I have found!). My take away was that these kind of user interaction features are better done in software – there is minimal overhead compared to driving the LEDs and it is very quick to implement.

Rainbow Colour Cycle

My original clock also fills the display with a rainbow colour routine at midday and midnight. Implementing this on the IceStick became quite challenging as I quickly overran the 1280 LUTs (basically combinational logic). I think this was due to setting a RGB colour for each LED in the colour register, where as before it was just an option between two colours based on whether a bit was high or low. Without the rainbow effect, the sythesis was a simple logic mask but with the addition of full 24 bit colour at run time, it would require much more complicated logic. In addition, the routine works using a pseudo colour wheel that also adds complexity to the logic synthesis, due to three < switches.

task colour_wheel; begin
  if (wheel < 85) begin
    red <= (255 - wheel * 3);
    green <= 0;
    blue <= wheel * 3;
  end else if (wheel < 170)  begin
    red <= 0;
    green <= (wheel - 85) * 3;
    blue <= (255 - (wheel - 85) * 3);
  end else begin
    red <= (wheel - 170) * 3;
    green <= (255 - (wheel - 170)* 3);
    blue <= 0;
  end
end endtask

Encountering these sorts of problems are useful when learning a new topic.Whilst the base project itself is quite simple, adding in these sorts of features brings up challenges that require further reading. I just managed to squeeze the rainbow effect, after finding areas of optimisation in logic statements and transparent latches.

Discussion

The project grew well beyond the scope of simply getting a binary clock working on the IceStick – I achieved that in less than an hour. What took time was refining how the digit module worked and really understanding how to mirror the simulation; digging into the WS2812 module to add masking and direct colour register set; developing a test bench and methods for capturing specific parts of a design and finally, the user interactions and bonus features.

My take home is that an FPGA is ideal for creating a low-level driver but what one then does with that driver is generally better achieved in software. A binary counter is just as easy and low resource to implement in C and the advantage then is that the button control and advanced features that make the clock unique is much quicker, safer and flexible to incorporate. That code can then directly interface with something like the WS2812 via a FPGA peripheral in this example.

I’m looking forward to trying other high data rate experiments with FPGAs such as LED matrix and HDMI driving, watch this space…

GitHub Project

Samsung Frame TV Oak Tripod Stand

Sun, 23 Sep 2018 08:40:29 +0000

Being part of a generation that doesn’t watch TV…except documentaries and films…and YouTube…ah well, might as well watch it on a big screen. Got a TV, a Samsung Frame – designed to look like a picture frame.

It can mount flush to a wall or be mounted on an easel inspired stand, which Samsung sell separately for £500. I decided to have a go at making one myself.

The design is simple but required some thought and trigonometry, in order to get the TV mounted on the VESA mount just at the right position to rest on the joining platform. Photos speak for themselves.

I planned to get the design CNC cut as I didn’t trust my carpentry skills. Finding someone who could cut planned Oak was difficult however (due to the work holding) and I decided plywood wouldn’t cut the mustard. Instead, I laser-cut templates of the DXF exports and traced them with them jigsaw. It turned out OK; only minor fettling and wood filler involved.

Scribbles and sketches to calculate the trigamontry before CAD sketches.

CAD render

I first created a 1/25 scale model after CAD to get an idea of stability and design proportions

My model of the TV was critical in getting the stand to fit together first time and to validate my trigonometry

The front legs butt into a recess, with glue and a hidden screw for added confidence (the screw wouldn’t be required if my carpentry was better!). The rear is a slotted friction fit.

The VESA mount is just plywood and is not pretty…

The oak appears to blend into the rear of the TV. Getting the VESA mount just at the right height so that the TV rests on the joint required some maths…

The finished article!

Is Bristol Choking – Air Pollution Web App

Sun, 04 Feb 2018 10:16:57 +0000

UPDATE: I have not renewed the domains for this so it’s now down

I had some of my Nixie Pipe displays showing air pollution data collected by the council, using a Python web scraper at an art trail and people seemed very interested and unaware of the data. I considered how good it would be to have live displays at the air monitoring sites for people to see, but decided a web app was more feasible as a weekend project and less risky!

Is Bristol Choking? is the result. You may wonder what I mean by choking: I’ve classed an area as choking if the current 15 minute average NO2 value is greater than the annual mean legal limit set by the EU of 40 µg/m³ and as stated in the WHO guidelines. Check the website during rush hours and weekend daytime and most are choking. Have a read of the choking and about sections for more.

I used it as a means to learn Python Flask and Python web app tech in general and hope it is clearer and easier to understand than the council site. There is an about section that should add some context to the numbers, which I feel the council site was lacking.

I enjoyed the process of creating the app and learnt quite a lot. Initially, I was scraping the data in the same function call as the main landing page route, which created a short delay with no feedback for the user; it appeared as if the page was taking a while to load. Instead, I ended up using WebSockets with Flask to asynconously scrape the data from the Bristol Air Quality site so that Flask could render the template index.html with a scraping loading animation, then populate the fields via json passed from Flask to a Javascript socket event.

GitHub repository

Honock – Hexagon Honey Clock

Sat, 25 Nov 2017 11:57:58 +0000