@Robert.Wall and @rupert - good stories from the board! While I don’t think I’d want to go back to it, it sounds like a deep craft that’s a shame to be lost.
Rob and I have been discussing an automatic phase correction mechanism in software and there is independent phase correction for each channel so we can easily work with the lack of AA filter on the existing expander. The ideal change would be to make the front end identical, but would require a change of the header as well.
I’ve pushed the most up to date firmware to the repository (879cc9c is the commit at this point in time). Diff wise, it looks big because I’ve started using an autoformatter so essentially every line has been changed (this is a one off occurence)! If you do want to commit to the public code (rather than just making local changes), you’ll need to have clang-format installed - usually just in your normal package manager (apt, homebrew etc). It will run automatically when you make a commit, so there’s no manual intervention required
Is there anything in particular you’d like me to look at/check?
Looking at your Github page with a view to downloading this version, I noticed this:
“CT values are interpolated between the appropriate voltage samples.”
Do your really mean this? We’ve always interpolated between the voltage samples because the interpolation routine is most accurate with a pure sinusoid – and voltage is likely to be closer to this than the current. I hate to think what interpolating between samples of this current wave to generate a time-shifted exact replica would turn out like:
Here’s another. This is the “whole house” CT when the house loads and PV panels get pretty close to balanced - so not a lot of real power flowing but a fair bit of current. The inverter is dealing with the 50Hz stuff leaving the grid to deal with the harmonics.
I’ll attach the raw data associated with that in case you want to do any interpolation experiments. While the meter itself does everything at 8K samples/sec this early version could only capture the waveforms at 4K samples/sec. The latest version captures every sample for displaying, but I’ve not attempted to recapture this scenario so I’m afraid you’re stuck with 250 usec samples. balance.txt (25.4 KB)
@rupert - I’ve made a software fix to get around the reset button position, it’s a nicer solution in general (019cf09). The bootloader starts when there is a key value set at the bottom of the RAM when reset is deasserted; usually this is set by the bootloader when you first press the physical reset button. I’ve added a 4 byte offset in the linker and exported that address. Now, you can enter the bootloader by sending e over the serial/USB link and confirming. The system then resets itself, and you will magically enter the bootloader.
Hardware reset if things go completely awry is handled by the watchdog timer.
Hi all - final check in before doing a production candidate run. Changes summarised below:
Fixed incorrect connection of nRESET for the RasPi. This was connected to 3V3 on the header, so it would not have been possible to reset the microcontroller at all!
Removed the user LEDs and button. No use case in the emonPi3/Tx6 setup, and eased layout.
Replaced the 26 pin RPi header with a 40 pin header. The 26 pin is very old now (dating back to the Pi 1 days), and most volume parts are now geared toward 40 pins so are cheaper and more available.
Rerouted analog inputs to match physical pins, rather than logical pins. This makes the layout much neater, and the remapping is done in software.
Changed the expander connection to a 2x5 header (redesigned CT expander coming too). This makes all CT inputs the same, and also I’ve brought up 3V3 into the header, which gives the possibility of doing things other than “just” CT expansion.
All files are available in the repository; the current commit is 56040d2. Any feedback very welcome, as always
What would it look like with the PiZero fitted? How close to the edge are the Pi outputs (especially the HDMI)?
I’ve always felt a flaw in the emonPi was the inability to easily hook into the Pi especially for diagnostics. Being able to add a Monitor, Keyboard and Mouse would be useful.
It will be exactly the same as the Pi2 - it was designed to fit the same case. For the use you’re describing, I’d suggest a few things:
With the Pi setup for network access, you can do everything through the network connection. Raspberry Pi have made this even easier now with the Raspberry Pi Connect tool which gives you the full graphical environment through a web browser, so you don’t even need to use the command line. Or, just use normal SSH if that’s what you’re comfortable with.
If you’re just getting setup and prefer to an attached keyboard, mouse, and screen you can just directly connect the UART pins with wires. I’ve marked on the header where they are - you can see the RX and TX markings toward the right of the header. When you’re happy, attach the Pi directly as normal.
You could use the USB serial connection. If it’s something of interest, I could add a pass through for the hardware UART to the USB. That is, anything received from the UART is passed on to the USB serial.
Ah OK, yes, I was thinking this was a TX with a PiZero rather than a full Pi.
However, I can see this replacing the TX (single board for both) so, if using a PiZero (to reduce cost), perhaps there should be some thought about USB access from the Zero.
It is a shame remoting the HDMI seems to be so difficult.
I’d missed the PiConnect Tool. TBH I rarely use Pis now - everything is on VMs except for a few things using emonhub or connected to APC UPSs
Hi Brian - yes, this will also be the Tx++ as well. USB support on the Zero is annoying as it’s an OTG port so you need an adapter anyway. Same with HDMI - it’s micro-HDMI so either you need that cable, or an adapter. My suggestion would be to set it up outside the box with full acess to everything, or configure the Pi/Tx through the UART via the Pi or through the Pi/Tx’s USB port. RPi Connect is good and gives people who prefer it a graphical interface.
Incidentally, I’ve also got an ESP32 board for even cheaper WiFi access - boards are made up, but need to have a look at getting ESPHome working on it. It will just decode the JSON output from the Pi/Tx board.
Yes true, but how a dongle could be attached is something worth considering at this stage I’d suggest . A Pi (rather than a Zero) only really gives you USB and Ethernet in this configuration over the Zero, so if getting the USB to the case edge can be solved (for dongles) it gives us a device at a much better price point. The PiZero 2 has enough grunt to run emoncms generally.
There are loads of options for micro OTG to USB, but I’ve used these for simple conversions USB to microUSB OTG Converter Shim | The Pi Hut. Ideally perhaps a Micro Male to a female panel mount socket (didn’t find one though TBH).
Just feels there is a risk we are missing a trick and being too dogmatic on ‘this is the case we use’ and missing the opportunity of reducing the unit cost for little loss in functionality.
Hi Brian - yes, completely agree! The difficulty is two part:
I can make a PCB is any (2D) shape, but the range of suitable off the shelf cases is relatively small and any customisation drives up prices really quickly.
The RPi layouts are a pest - the original Pi put the connectors on 3 edges, rather than two opposing edges and almost every SBC since has followed this convention.
The Zero is actually the best in this regard ironically (all the connectors on a single edge) but it means the Zero’s connectors need to point to an edge away from the emon[Tx, Pi] connectors so you’re into custom case territory and then scrub a decent amount of the cost saving anyway. You could do a completely separate board for the Zero only, but then it’s multiplying vendor stock items and losing volume discounts, again eating into any savings.
But, I will hook up a Zero when I get the prototypes back and see if there’s anything that’s really conflicting or can be resolved. I think having a (very) cheap ESP32 WiFi driver is probably the way forward for reducing the price as far as possible.
I hooked a WEMOS Mini up and created an ESPHome Custom Component, it was OK but would end up being too slow - a proper component would do it, but that is beyond me.
90 degree adaptor might be the way to go for that, if there’s space. It could come out where the full size RPi fits, but that does preclude the use of the 12 CT header. I’m also still not entirely convinced of the long term use case - 100% for initial setup, but once it’s running, you can either access it through SSH or remote desktop. Regardless, clearly there is a use, so I will check
Here’s a sneak preview of the ESP32 adaptor (credit card for size). It goes into the RasPi header and gets 5V and the UART connection from there. Ideally I’d like to get rid of the extra USB-C connector and program it through the existing UART, but I will cross that bridge later. I’ve made a start on the ESPHome configuration as well.
Crossed wires here, I was thinking an OTG cable for the USB rather than HDMI so a dongle could be attached (MBUS etc).
Excellent - configuration or component? I have a configuration that works (sends via MQTT).
Looks good, but I do like the cheapness of the Wemos and I also think the ESP32 is overkill for what it will do. I do though accept that it might not be CE compliant!
- thanks to everybody involved.
