Some say China is the country of 80-20, things are complete and great to 80% , the remaining 20% of polish is left hanging. The Mediatek CPU used in the Onion IoT modules suffers from a similar shortcoming. There is an working SPI bus, but it is simplex ( OUCH!!) . Simplex means only receive and transmit can take place at a time.
For interfacing the Onion Module with Energy Monitor IC's this is a huge blocker since the typical communication flow with this IC's runs as:
Write a 8 or 16 bit register address to the SPI bus
Immediately read-back a 16bit value over the SPI bus while the chip-select is held low.
The proposed remedy to this after a bit of debugging and probing with logic analyzers is to directly use the user-space SPI c-library or to fix the python-spidev library with an xfer3 method which does a special write where the clock keeps going, the first bytes are written and next bytes are read.
I have started on the path for fixing the Python library on my fork. OpenWRTbuildsystem seems happy with my efforts so far. It remains to be seen if we can communicate with the energy monitor ASIC's. Contributions are much appreciated.
Last couple of Saturdays I finally got a chance to do out-of-work activities and I decided to attend the Nairobi AI Meetups in the IBM offices in the Atrium building. It is a great venue for learning and interacting with people in the community.
The meetup can sort of be described as a book club for Stanford NLP AI/DL lectures series. I have encountered 2 possible formats so far, both of them are quite hilarious in execution.
We watch the lecture at x2 or x1.5 speed during the session and have learning and discussions around the topic. This is somewhat limiting since we cannot ask the Stanford lecturer questions. So meetup participants ask each other.
We get one or two of the meetup participant to watch lectures during the week and prepare reformatted slides from the content to present the lecture as a proxy of the Stanford lecturer. While the presenter is standing in for the original, we can ask the proxy questions and clarifications and have more interactive learning. This format is more fun, but requires more prep-work and effort from a couple of people. Increasing the pool of people doing this would be great.
The last set of lectures we watched covered Tree-RNN's and Co-referene . The tree-RNN's are particularly powerfull in capturing the semantics of prose. The meetup could really use more linguists in the mix to clarify some of the linguistic features NN's can learn, this is a multi-disciplinary field after all. I will see if we can convince people from the Nairobi University Department of Linguistics to attend, the lack of recency on their website does not give me much hope.
Riding in Adelaide especially during night can
be a hazardous activity. You have to share the road with cars and
pedestrians, staying safe from the former and keeping the latter safe.
Avoiding pedestrians requires vigilance from the cyclists, but the
attention of cars has to be drawn with bright lights. Often due to
circumstances you might need to ride in the middle of the lane or cut
across lanes to make a turn. During the day these activities are
indicated with a hand signal, I made this project to translate those to
bright lights controlled by your motion and muscle activity to obvious
signals during the night.
NOTE: This is a cross-post from Hackster.io - https://www.hackster.io/whatnick/the-red-light-beaglebone-myo-controlled-bike-lights-6c50d2
Various light options tested with data from serial port
The controller used in this project is Myo Armband - it contains a 6 DoF IMU and 8 EMG sensors for muscle activity. The controller communicates to the BeagleBone via a BlueGiga BLE dongle, this appears as /dev/ttyACM0 on debian based images. The raw data from the sensors is processed using Scikits Learn and an NN-classifier to interpret the rider motions. The turn and stop activity is then passed over to a realtime controller (either the BeagleBone's native PRU or an external microcontroller like the Teensy) to drive a WS2812B LED matrix.
Data stream from Myo controlling LED Matrix
The
BeagleBone Green is modified to add a JST connector to activate the
on-board battery charge management system to use a Lipo for poweing the
bike lights according to this how-to. See the images below for details of this modification.
The
whole system is wearable and battery powered. The LED matrix is stiched
onto a high-vis jacket, a must for any night time riding and the Myo is
placed around the fore-arm before starting the ride. Here is a video of
the lights in action linked to gestures.
Testing gestures and linked lights
The Details
Install git on BeagleBone Green and sync the date using ntpdate. Then checkout my repository.
Plug the Myo Blue Giga receiver in and check that it is recognised
lsusb
There
should be 3 usb devices. The BeagleBone Green may need to be powered
over USB instead of battery for the USB hub to power up and recognise
the module.
Install the dependencies for myo-raw.
sudo pip install -r requirments.txt
The
myo-raw can also be installed under Windows or any other desktop
environment to stream the data from the BBG and display it remotely.
Run
myo_raw_osc with the following command to stream data to remote server,
print locally and send results from EMG sensor to external LED panel
controller (in my case the Teensy, however I am also experimenting with
the PRU's)
This
will output controller codes to the Grove UART port /dev/ttyO2 to the
display driver in sync with arm motion. A bit of looking at the
experimental data and tweaking of the classifier may be needed to get it
set to you movement patterns.
That's it for the setup on the BeagleBone Green in the non-PRU mode. For the Teensy, clone the git repository as below.
Install the Teensy add-on for the Arduino IDE as described here
and upload the code to the controller. The LED matrix data pin is
connected to pin 2 of the Teensy and the BeagleBone UART is connected to
Hardware UART1. I power the LED matrix from the 3.3V output of the
Teensy rated at 100mA, this allows safely connecting the 3.3 output
signal to this particular matrix. Larger matrices may require buffer
IC's and separate power supply. The BBG 5V system pin is connected to
the VIN pin of the Teensy for power supply off the battery/USB OTB
connected to the BBG.
That is all for the set-up of this simple but very useful project.
A while ago I remember watching a youtube video from about x10 years ago talking about distributed social network platforms running on SheevaPlugs. Fast forward 10 years, we are still in walled gardens of internet behemoths like Facebook, Twitter and Google and energy monitors are running full-linux os'es in smart plugs (albeit it is mostly OpenWRT/Lede)
The idea of re-purposing Atheros/Qualcomm router IC's as general purpose linux based controllers is not new. All those pins dedicated for ethernet ports are converted into GPIO's with proper muxing.
I have been designing one myself to fit in the DIN rail using the Onion Omega 2 as the host processor. There are some road-blocks regarding the simplex SPI bus on the Mediatek CPU.
TPLink seems to have gone the same route and built a smart-plug with and Atheros CPU. Again this blog post is meant to enrich the notes I already brain dumped on twitter.
Atheros/Qualcomm powered smart plug from TPLink with metering and X2 5A relays in parallel making a switchable 10A socket. pic.twitter.com/HtYPl3GqRu
This module is designed to be a wifi controlled relay with metering, switching upto 10A according to specs. It achieves this by using x2 5A relays in parallel. The main subsystems are:
Power - Analog Devices/Linear Tech power AC-DC power IC. The footprint of this is an interesting variant of SOIC-8.
Metering - This is done by the Maxim MAX71020A IC. Every electronics manufacturer worth its salt is creating metering ASIC's these days and I am excited about opportunities in making break-out boards and comparisons. TPLink seems to have bought up all the inventory of this particular Maxim IC and Maxim has a history of discontinuing low-margin lines the like MEMS accelerometers. I will keep an eye of the Poly-phase version which seems to be still in production (MAXQ3180). Overall this does not look good for the future of this particular smart-plug.
Relays - x2 chunky 5v - 5A relays adorn the metering and CPU board. These provide the main functionality of the smart plug.
Atheros/Qualcomm processor - This is the smarts in this smart-plug. Running standard open-wrt. The Maxim IC is of course on the SPI bus and other GPIO's are driving LED's , relays etc.
Overall the lack of supply of the Maxim IC does not bode well for the future of this Smart-plug. It may find fun alternative uses as an always on linux node.
Looking at other energy-monitor designs has been a past-time of mine and I recently the chance to teardown a Neur.io energy monitor installed along with many Tesla power-walls in Australia. This one had had some feedback of high voltage over the modbus and had fried itself. Despite best intentions with TVS suppressors etc. it could not take it anymore.
In this blog post I will enrich some of the content I already posted on twitter with some more in-sights in energy monitoring and additional elements regarding current clamps.
This is the proper blogpost alluded to in the twitter thread. All the image content is already in the thread. Blogs simply allow greater structure. The meter is essentially composed of:
Current samplers with 1ohm burden resisors attached to CT's - Neur.io recently announced a flexible CT design which can make it easy to install and potentially universal in measuring AC currents via induction and DC currents via hall-effect. I dropped an multi-meter probe on the burden resistors just to check.
Voltage samplers as tiny encapsulated isolation transformers - This approach can introduce some non-linearity due to hysteresis and phase-shifts in the transformer, transformers are also bulky. Since the transformer is under no-load, phase-shifts should be minimal. The advantage is built in LV isolation. There is a bank of x3 transformers to account for x3 phases.
Energy monitor IC's - These are from Cirrus Logic (CS5467), the documentation says the IC is mainly for the Japanese market. Neur.io seems to be successfully using it in North American and Australian market.
Main processor and wifi - Unfortunately the unit I had was going back to Tesla under RMA, so I did not have chance to take of the shield and probe the processor. However I would love some assistance in poking in there and exploring the possibilities of custom firmwares.
Modbus - The meter has a modbus I/O port to communicate with other systems e.g. Inverter and Battery charge controller.
Power Systems - This is a Recom SMPS (RAC05-02SC) module keeping with my idea of keeping custom subsystems as limited as possible and reusing tested components as much as possible. I have seen a lot of energy monitors include their own power sub-systems including the Sense and WattWatchers. This increases design complexity with perhaps marginal improvements in design flexibility and BOM costs. The module outputs 3W at 5V, giving some head-room for LDO/Cap based noise filtering.
I have come to learn that DIN rails are not that popular in the North American market compared to the European and Australian market. Hence the overall brick packaging of the Sense and the Neur.io meters. Keeping the DIN form-factor requires a lot of combined mechanical and electronics design work as I have found out the hard-way. It is currently in my pipeline to create break-out boards for the CS5467 and test them out with common micro-controllers.
