So I pinched PA6 and PA7 from the CT input scan on the emonTxShield demo (they weren’t being driven anyway) and used them for OPAMP2 in follower mode. So my pinout now looks like:
Then I hooked up the signal generator to PA7 with a rail-to-rail triangle signal (Yellow trace) and also probed the output PA6 (Green trace). The datasheet says the opamps are good for 0.5 mA so I loaded up PA6 with a 6k R to GND. The Pink trace is Green minus Yellow (i…e. output - input).
The results are pretty good. Green is so identical to Yellow you can’t really see it. Pink shows about a 20mV offset between the two. I tried with the factory trimming and the user trimming but I couldn’t notice any difference to the ~20mV offset. BTW, if you do want to do a user trimming and self calibration, you can do all of that from the GUI under Configuration->OPAMP2. It’ll then generate the call to HAL_OPAMP_SelfCalibrate() for you, from within MX_OPAMP2_Init(), after it’s called HAL_OPAMP_Init().
[EDIT] - actually I see the exact same 20mV even when I connect both probes to PA6 so I think it’s just a scope measuring limitation rather than an indication of an offset out of the opamp.
Fantastic, Opamp2 on PA6/PA7 works!! I’ve got a 10uF capacitor across my 470k:470k voltage divider, with an LED on the output you can see brightness change as I switch the top resistor to 150k, great!
I neatened up my USB DFU (right) and Opamp testing (left) circuits this morning, ordered a USB mini adapter rather than having flying leads on the end of a USB socket with the risk of shorting the connections. Still same error on USB, I still need to look into the BOOT1 bit question.
Ken Boak introduced me to small energy monitoring development board with a supercap and FRAM on it a while back. I’ve done a quick calc to see if the RTC can be powered from a supercap instead of a coincell, which would be good in principal.
Typical current draw at VBAT is 0.5uA, 1uA max., according to STM guide.
I’m assuming the RTC uses the internal high speed clock and assuming the guide’s figure is based on using the internal clock.
The leakage current of this 1F cap is about 2.1uA, worked out from the discharge over time graph, 100h charge time.
“Resistance” at above site worked out as 3.3V / 0.0000031A.
614 hours or 25 days.
With a 50% drop in performance, seems usable for most contexts…
EDIT: I guess my main question on supercap vs battery is whether or not the time will be set during programming before shipping, would a short shelf life for an RTC be an issue for the OEM crew? Or does the module get time from an ESP or other internet connected MCU?
Doing a bit of a review of my local CVS respository, I noticed I had outstanding changes on the emontxshield project that related to enabling the opamp as described above. I figure that’s probably worth capturing the in the tar file series (and @pb66’s github repository) just to show how it’s done. While I was there I also included the opamp output in the ADC scan so have included that as well. The plot below is graphical representation of the DUMPING output you get if you dump that “channel”, you can see it matches the scope traces of the triangle wave above and has no trouble going rail-to-rail.
Thanks @dBC for the advice on adding the RX and TX lines to the ST-LINK connector in the PM, thought I would move the discussion here for everyone’s benefit, is there a recommended standard pin order/connector for ST-Link with rx/tx lines?
Im wondering if something like this would work, a combined UART & ST-Link 8 pin header. First 6 pins would program using one of our standard UART to USB adapters, SWDIO and SWCLK added on top to provide ST-Link option:
Trys and I are keen to develop the smaller board in parallel. 1VT and 3CT sat on top of an rPi. Something we need to cost out. I think there’s a post somewhere showing this?
Yes: STM32 Development - #280 by TrystanLea
CT and VT ADC inputs routed to allow synchronous sampling. (4 ADCs available on our chip) Expansion module 6 CTs planned should also be fine with synchronous sampling.
RJ45 connector included following combined pinout for optical sensor and temperature sensor compat.
Lots of solder jumpers placed to play with either SPI or UART data transfer between the rPi, STM32, and ESP8266 module.
DIP switches on CTs 1,2 and 3 to switch out burden resistor.
A few notes from convos with Trys:
We’re looking for an all rounder 3-phase native board with rPi mount, which doesn’t cost the earth.
Case design as custom injection molded case. Clean, simple, white, rounded corners. Screwless with a pop-off inset lid ideally.
Replacing the esp8266 based module with an esp32. Without rPi, this gives great standalone features.
USB-C will be the power-input connector.
clamp connectors to be versatile, a mix of I/O and analog. Expansion module has similar thinking around it, with provision for at least 6 more CTs, do we need extra VTs?
A few notes of my own:
USB DFU enabled chip seems possible. CubeMX auto clock config has shown it’s possible… so far not got it work. Anyone here with experience in this?
microSD and supercapacitor footprints, for local logging of large volumes of data, and maintenance of the RTC in case of power-outage.
Undecided on best way to route the wire-clamps, at the moment each triplet has 5v pwr, 5v tolerant in/ 3.3V out, and gnd. Could be nice to go for a triplets of: 5V 5V 5V. 3V3 3V3 3V3. Signal Signal Signal. Signal Signal Signal. GND GND GND.
Do you mean include the header holes to connect directly? If so, great. Unless this board is used as an EmonPi type all in one, the reduced cost of something like a D1 v a Pi is significant especially as more and more, folk will already have a Pi doing other things as well.
For the SW for a an ESP module, why not just create a custom component on EspHome?
UART flashing was not working because only specific Rx/Tx pins are to be used in boot mode.
So even though I’d connected to an Rx compatible pin, it was not a boot mode Rx pin. Easy when you know how.
DFU wise, seems the programming manual has a clear Windows direction… So I’ll load up the VM again and go through a Windows process of getting DFU working, seems to require a specific driver install.
Just came across this after I read the twitter post that you are now also using STM32. That’s great, I’m also using STM32 for all my boards. Don’t like the CubeMX stuff though, so I used mbed and I am now trying out Zephyr OS.
Good to hear.
would you mind posting a few pros and cons to cubemx vs mbed?
You see, I tried mbed, and didn’t like it. I like the idea of what they’re doing…
The cubemx code initializer is very useful…