ADE7816 Energy Monitor

I have been meaning to try out the ADE7816 Single-phase 6 current channels energy monitor for a while. However time has been lacking for the last couple of years. Finally I have a working version with successful board bring-up and a semi-working Micropython driver, with an Arduino driver in the works.

PCB Design

The PCB design process for this was not easy mostly due to a footprint choice mistake on my part. I had placed the 5x5mm QFN part instead of the 6x6mm QFN part in KiCAD. This made the DRC fail everywhere in standard settings. However it ended up being a collaboration opportunity with Greg Davill who loves to practice and photograph bodging stuff. So I now have a work of art at hand instead of a non-functional board.

Practising my bodge skills

This is a QFN where the footprint on the PCB was incorrect.

Just a couple more bodge wires to add. pic.twitter.com/AmZ1CsWqC3

— Greg (@GregDavill) April 22, 2020

I am even debating whether to place the rest of the parts and possibly take away from the dead-bug awesomeness. Next time need to order parts in advance and make sure I do 1-1 prints to verify footprints before pulling the trigger on PCB's.

Energy Montor Details

Now to more about the energy monitor. This ASIC features 3 single-ended and 3 differential current inputs and a single-phase voltage input, all in very compact 40-pin 6x6mm QFN package. In fact the PCB is large on purpose to accomodate ease of use with stereo-jack type current clamps. The main usage would be in standard households where there are typically 3-4 lighting circuits, 1-2 socket circuits and dedicated Air Conditioning circuit. A single energy monitor could be built to monitor all channels using a single-ASIC and leave out fancy NILM stuff from worrying about the lights. The socket circuits could have anything plugged into them and can potentially have point-of-load monitoring instead of breaker board based monitoring. All this translates to more data being generated for IoT platforms and some sensible firmware work needs to be done to handle that.

ADE7816 Driver Development

This is still work in progress. I have done some initial exploration to find prior art. Nothing exists yet from Arduino however there is some register lists from a Javascript driver written for the now defunct Intel Edison.

Intel never quite had the maker market pinned right to market that board, it makes me sad to think of all the engineering ours sunk into a now defunct platform. Open-source software / hardware helps us salvage some of that. I also sped up the register listing by copy-pasting the ubquitous table from the ADE7816 datasheet and dropping it into a Jupyter notebook to parse all the registers, not as fancy as the Pdf parser I had built before, but much more reliable.

My @adafruit #ESP32 + Logic Analyzer test rig. Due in the background is just to keep cables tidy. The ESP32 runs micropython so that I can iterate on SPI modes quickly and use the excellent struct functions to pack/unpack bytes. https://t.co/0pQgAO1Cgl pic.twitter.com/R2imRukrpT

— Tisham Dhar (@whatnick) April 14, 2020

My driver development follwed the now tried and tested Micropython + Jupyter Notebook + Logic Analyzer path. I used an ESP32 feather as host processor with standard micropython loaded and probed the SPI bus with read-write packets for known registers until the protocol gave in and started responding with some values. The ASIC is super versatile in supported protocols - I2C Slave, SPI Master and SPI Slave modes are all viable. So developing a fully functional driver supporting all the possible modes will take a while. The initial work so far is on the SPI slave mode since all my other work in DIN rail and Featherwing formats is linked to the SPI bus, however the I2C mode can be really interesting for host-processors with fewer pins and flaky SPI support (while having solid I2C support - like the Onion).

If anyone is interested in driver development I am happy to send you a board or you can get one yourself from Oshpark, Aisler or PCBWay. Once the drivers mature I will list it for a wider audience on Tindie.

Distributed Locking from Python while running on AWS

In the day and age of eventually consistent web-scale applications the concept of locking may seem very archaic. However in some instances attempting to obtain a lock and failing to do so within a limited window can prevent dogpile effects for expensive server side operations or prevent over-write of already executing long running tasks such as ETL processes.
I have used 3-basic approaches to create distributed locks on AWS with the help of built-in services and accessed them via Python which is what I build most of my sofware in.

File locks upgraded to EFS

File based locks in UNIX file-systems are very common. They are typically created using the flock command, avalaible in Python under os-specific flock API. Also checkout the platform independent filelock. This is well and good for a VM or single application instance. For distributed locking, we will need EFS as the filesystem on which these locks are held, Linux-Kernel and NFS will use byte-range locks to help simulate locally attached file system type locks. However if the client loses connectivity the NFS lock-state cannot be determined, better run that EFS with enough replicas to ensure connectivity.
File locking this way is very useful if we are using EFS for holding large file and processing data anyway.

Redis locks upgraded to ElastiCache

Another popular pattern for holding locks in Python is using Redis. This can be upgraded in the cloud-hosted scenario to Redis-Elasticache, This pairs well with the redis-lock library.
Using redis requires a bit of setup and is subject to similar network vagaries and EFS. It makes sense when using Redis already as an in-memory cache for accelration or as a broker/results mechanism for Celery. Having data encrypted at rest and transit may require running an Stunnel Proxy.

An AWS only Method - DynamoDB

A while ago AWS published an article for creating and holding locks on DynamoDB using a Java lock client. This client creates the lock and holds it live using heart-beats while the relevant code section executes. Since then it has been ported to Python and I am maintaining my own fork.
It works well and helps scale-out singleton processes run as Lambdas to multiple lambdas in a serverless fashion, with a given lambda quickly skipping over a task another lambda is holding a lock on. I have also used it on EC2 based stuff where I was already using DynamoDB for other purposes. This is possibly the easiest and cheapest method for achieving distributed locking. Locally testing this technique is also quite easy using local-dynamodb in a docker container.
Feel free to ping me other distributed locking solutions that work well on AWS and I will try them out.

Testing the OrangeCrab r0.1

After hassling Greg Davill for a while on twitter and admiring his OrangeCrab hardware I managed to catch up with him in person in Adelaide. I have been away in Nairobi till October last year, then I spent a brief few days in Adelaide before coming over to Canberra to take up a position in Geoscience Australia. The new gig is much less time commitment than the start-up world and hopefully will allow more time for blogging and board bring-ups like this one.

I caught up with Greg at a Japanese restaurant in Rundle mall and was treated to his now trademark led cube and led icosahedron. They are insanely detailed pieces of work and deserve staring at. However I am most grateful for the care package he left me, an OrangeCrab v0.1. This is an ECP5 board in feather form factor with an ADC built in to respect the Analog In pins on the feather. My aim for this board is to host some energy monitoring code on the FPGA with a fast 4mbps or so ADC and perform power/energy calculation on some parts of LUT's/DSP and have a softcpu push data out.

Greg also left me a home-made FTDI based board to use a JTAG programmer. The whole setup requires 3 USB cables:

•  To plugin and power the FPGA board (eventually it should be alos programmable via this port) 
• To attach a USB-Serial converter and watch the console when the gateware comes up 
• To program the board over JTAG using an FTDI chip

Getting firmware compiled these days is getting easier, but Greg had done his initial testing with Lattice Diamond. I managed to installed it in WSL and promptly ran into a tonne of issues. The weirdest being close coupling to bash, Ubuntu actually uses dash as its default shell. You can get a Diamond licence and help support integration of diamond in litex-buildenv.

I was about to give up then Greg got it working with the opensource toolchain and [NextPNR-ECP5. I had by then setup litex-buildenv to support the orangecrab. So getting some gateware on was relatively easy. Then I got stuck on RAM timing bug in Litex till a few hours ago when I tested out some new gateware.

Also Checkout out Greg's foboot fork and help make programming over the USB possible and reduce 1 USB cable. More work on this including getting MicroWatt running coming soon.

Around Kenya in 4 days and a year ( part 2)

The New Year adventure continued past the sad mercury laden mines of Migori to the Tanzania border , Isebania in particular. We met up with professor Sangai Mohochi and had a brief gander into Tanzania ( Serere) for a beer. Later we had some Orokore Beer made from millet, we sat around a car tyre sipping still fermenting beer from straws.

We took our leave from the professor and had a long drive out to Rusinga island. A beautiful place without much of the tourist trappings lakeside places have. The Suba culture is being revived with festivals. We woke up early and did a trip around Rusinga Island and visited Tom Mboya's Mausoleum. One of my high school's illustrious alumni. 

After another long day of driving and some fiddling with charging phones directly from a car battery ( another story on how many engineers does it take to charge a phone), we ended up in Naiberi River Campsite. It is more like a glamping spot and ideal for a quiet New Year's celebration around a fire in the main hall.

A late lunch/early dinner at Rift Valley Lodge Golf Club. We went for a post dinner walk on the greens and ran into herds of zebras and antelopes. No wonder this golf club is classed as one of the best in the Africa. All the excitement was followed by an uneventful drive back to Nairobi.

We arrived tired but energized the beauty and possibilities in Kenya. The roads need to be built, electricity needs to be channeled to houses, there is a lot to do. We look forward to hanging around and getting it done. Eric is heading back to his PhD at Harvard, Gichini will be doing something about the weather prediction and I have helped put Lori Systems on a solid technical footing and change the Logistics landscape.

Open-source Sustainability (The tale of 2 package managers)

Last weekend I had the priviledge to attend the 10th PyconAU and listen to some amazing speakers. I went with my I will write markdown on the fly and make a blog-post at the end of the day mindset. Even though I did write a lot of markdown on the fly, I haven't gathered the courage to push these unedited notes into a public post. Excellent examples of live-blogging from conferences here.
What did happen was that the niggling doubts I had around how open-source works in the real world outside of just the code crystallized. This was as a result of 2 very good talks , one about how the PyPi project works and another around Open-source sustainability beyond money.

For the last year I have been writing and reviewing a lot of React Frontend, Python backend (Flask/Django) and Notebooks code. Both frameworks are super easy to buy batteries for where the included ones are running out of juice. Simply via pip install and npm install you can climb onto the shoulders of giants who are library maintainers and the life-blood of lean start-ups everywhere. However the maintainer burnout is a thing and start-ups when building their stack should be highly cognizant of this. Package repository burnout is also a thing. In my time in the software industry I have seen Maven repositories disappear. More recently NPM go through an identity crisis and the left-pad incident.

The PyPi talk gave me great background on a tool I use every single-hour without too much thought. It takes some dedicated volunteers to keep the dream alive. Who according to Dustin Ingram are :

• Unemployed and bored and poor (but super talented) 
• Paid for by their employer (thanks employers who support FOSS) 
• Not getting enough sleep (or in my case time with the family)

Vicky's talk covers another aspect. Developers and maintainers need more than money to keep going, they need back-up. The community need insurance against the bus-factor and burn-out. I have been guilty of this myself, putting a few dollars behind features I would like to see in BountySource instead of diving in. This has become more so as I have progressed in my career and become increasingly time-poor. Talking about this would anyone at VSCode like to claim the few dollars we put here ?

I love the longevity and discipline of project warehouse and will find some time to contribute to it. I also look forward to a similar alternative to npm, rather than a caching proxy with community behind it.

Sunbeam Coffee Maker Teardown

The bad Kenyan grid has struck again. There is very little built in surge protection in the system, so all appliances plugged to the wall end up with in-house surge protectors. This time the victim was my beloved coffee machine which had served us well for more than a year.

So I decided to take it home and spend some quality time with Pascal tearing it down. He is always curious about stuff and what is inside, so the Coffee machine is a complex beast capable of keeping him and myself occupied for hours on end. First we took of the top and looked at the heater and the electromechanical assembly controlling the hot-water head and frother was exposed. Also was exposed the heating tank with dual heating elements and a thermistor (I am assuming a thermistor rather than a thermocouple).

When we took the back plate off we found the main controller board. There is to obvious transformer in the set-up so I assume to whole power supply is cap-drop. There is a giant heat-sink attached to a 3-pin device which I assume is a triac or SCR for controlling the heating elements.

The bottom-left corner has a water pump with its own switching mechanism driven by relatively thin signal-wires from the main board.

There are some more interesting details on the main processor board including thick high current traces driven by the silicon switch with exposed copper and extra solder on top to increase thickness and provide a lower current path.

The main CPU is TQFP packaged micro-controller which is covered by the conformal coating the entire PCB is covered in. A macro image on twitter helped establish the lineage of the processor. It is a chinese 8051 variant with the datasheet here. Any help in translating it will be highly appreciated. But most of the schematic is legible.

Next up will be powering on the processor with a suitable 3.3v supply and examining the analog and digital buses. As well as powering on the whole thing to see why it turns of immediately on start. If the machine is unfixable I am planning to scavenge the thermistors, heating elements etc. to build a reflow mechanism.

All the water circulation mechanism is really interesting as well and can possibly be shoe-horned into a water cooler for a 3D printing system.

Nairobi 2nd OSHW meetup

After a many month hiatus we finally put together the 2nd Nairobi Open-source hardware meetup. This time we were at the Tav Irish Pub near Nairobi Garage on Waiyaki way. The pub was chosen due to proximility to Nairobi garage and possible use of that venue. As it turned out none of us were memebers paying the $60 per-month fee so we ended up co-opting the pub in Chicago 3H fashion.

PCB Lineup

I had collected PCB's over the last few month from Aisler, OSHPark and PCBWay all shipped to Kenya from Germany, US and China respectively. So we lined up to try various soldering techniques on 0603 Jellybeans and some 20pin TSSOP IC's.

Soldering Demo

The techniques we we tried were the tack, finish and reflow one using the iron and an experimental one with paste and dry-iron I had picked up recently. I didn't have a temperature profile controller for the dry-iron method. So we were just going to wing it by the eye.

Part Placement

We pasted up the boards using screwdrivers and tweezers. Started the reflow till the parts settled. Then simply turned off the iron. I am sourcing a K-Type thermocouple and SSR from KTechnics to get a better handle on this for next time. However the dry-iron does reach sufficient temperature for leaded solder reflow.

Dry iron reflow

By the end of the session we had assembled x2 CS5464 Breakouts. Next step from here will be suitable MicroPython and Arduino drivers to ensure these things actually work. We had a lot of fun over the meetup and I hope to continue having these sessions. Next time one of the participants has promised to bring his Weighbridge Automation and IoT set-up.

Scavenging a Coffee Machine

Following the meetup I have been hunting for accessories to make the dry-iron reflow less of a fire hazard and more controllable. (Un)fortunately the coffee machine at work has been fried by the spikes prevalent in the grid in Kenya (especially during the rainy season), so I have a spare K-type thermocouple I can work into the build. I have also co-opted a tissue holder we had on our dining table to stabilize the inverted iron during reflow.

Stand of opportunity

Onwards to the next Meetup.