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!
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
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 😃.
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.
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.
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.
The other thing the firmware does is provide interface to the buffered IO.
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.
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.
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).
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.Code variants
The Falstad simulation realised in Verilog as a per digit synchronous reset module.
input ce;// count enable
output[13:0]count;// two digit bcd counter
always@(posedge clk orposedge reset)begin
if(count&count*count)begin// 2 & last 3
Alternatively, one module to do all digits but with 13 bits rather than 16 bits.
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.
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...
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.
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 */
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.
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.
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.
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…
Being part of a generation that doesn’t watch TV…except documentaries and films…and YouTube…as 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.
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.
Considering my next project, I wanted to make an electromechanical display using magnets. I turned to the internet for inspiration and quickly came across Flip-dot displays; solenoid driven pixels. A good starting point for what I wanted to do, I looked further.
I found a 900mm, 56×7 display on eBay from a bus salvager (who know such a thing existed!). The displays used to be common on public transport – prior to being replaced my dot matrix LEDs – to display the route number and destination. It cost me £170, which may seem expensive to some, but for 392 individually mechanically actuated pixels that are quite a feat of engineering, I thought it cheap.
Nixie Pipe is my interpretation of a modern day Nixie Tube – the cold-cathode vacuum gas-filled tubes from the 1960s.
The project came about when I decided to make a clock for my kitchen, with specific requirement for an egg timer function! I’ve always wanted to make a Nixie Tube clock but having completed a Nixie Tube project recently and one pipe failing after around 6,000 hours, I wanted to come up this something better. Something that didn’t require high voltages, special driving circuitry, could be easily interfaced and was modular, but which maintained the unique visual depth of a Nixie Tube. Continue reading Nixie Pipe – Modern Day LED Nixie Tube
A need popped up at work for a data logger for various lab tasks. Quickly looking at the market, I failed to identify a lab tool for data logging (cheap, easy but powerful setup, remote access); something for researchers and scientists. I decided a Raspberry Pi with some input buffering would be ideal for the task. This is my roll your own data logger, put together on Saturday – showing what is possible quickly and potential with more development time.