If your connected CT sensors differ from these values then the settings will need to be updated to match the CT’s that you have plugged into each channel.
If your trying the steps above and get stuck, please let me know if I can clarify anything in the steps above.
Please see the original thread if you are interested in a bit more technical detail on the issue and use of EEPROM on the emonTx4.
EmonHub is running, stopping EmonHub
Uploading emonTxV4_LPL on serial port ttyAMA0
Attempt 1...
avrdude-original: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "avrdude.conf"
User configuration file is "/root/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/ttyAMA0
Using Programmer : arduino
Overriding Baud Rate : 115200
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00
avrdude-original done. Thank you.
avrdude-original: Using autoreset DTR on GPIO Pin 7
avrdude-original: Using autoreset DTR on GPIO Pin 7
ERROR: Not in sync
Restarting EmonHub
Also the serial CT sensor calibration doesn’t work (I used the ttyAMA0 port and 115200 as baud rate).
I tried to use a direct usb connection but maybe the cable isn’t right.
P.S. Thanks for all your work and shared knowledge.
ttyAMA0 is the raspberrypi serial port and isnt actually connected to anything, it’s not possible to upload firmware and configuration over the radio unfortunately, so you do want the USB-C cable.
If the USB-C cable doesnt work in one orientation, try turning the USB-C connector around. It only works in one orientation. Once turned around, refresh the firmware page and /dev/ttyUSB0 should appear if the orientation is correct and the USB-C cable is a data cable, hopefully it will work from that point.
This might help illustrate the usb connector orientation. Some USB-C connectors have a smooth side on one side and jagged connection of the metal fold on the other. On the cables we have here, the smooth side should be facing up towards the top/front face of the emonTx4:
Good images for the docs (if you haven’t already done that )
It might be just me, but this box just doesn’t do it for me (as in stand out and make me read it) - I’m looking for that info and miss it every time
What does lcal mean? I assume llead is the phase correction at 3.2?
When I ran up my serial connection, my clamps were wrong they were back to default rather than the extra 50A and one less 20A I had setup and changed when I installed. My radio has also turned itself back on, I had turned it off with serial config as I am using a direct USB-C cable.
I also missed the box that says upgrade EmonPi first to see the new code - didn’t take too long to guess that was the required step - but then saw the same here to confirm.
emonTx V4 CM Continuous Monitoring V1.5.4
OpenEnergyMonitor.org
Loaded EEPROM config
Settings:
Band 433 MHz, Group 210, Node 17, 7 dBm
Calibration:
vCal = 807.86
assumedV = 240.00
i1Cal = 300.30
i1Lead = 3.20
i2Cal = 150.15
i2Lead = 3.20
i3Cal = 150.15
i3Lead = 3.20
i4Cal = 150.15 <<--- iCal is set by the "CT Type" box?
i4Lead = 3.20
i5Cal = 60.06
i5Lead = 3.20
i6Cal = 60.06
i6Lead = 3.20
datalog = 9.80
pulses = 1
pulse period = 100
RF off
temp_enable = 0
JSON Format Off
Reference voltage calibration: 1.0285
No temperature sensors detected, disabling temperature
AC present - Real Power calc enabled
Ah, ok it looks like “ical” value is set by the CT drop down box, is that correct? So in my case/example, selecting CT4 as 50A has changed the value on CT4 as needed.
Yes that’s correct, i4Cal is the amplitude calibration for CT4. i4Lead is the phase calibration. The value set is correct for a 50A CT sensor, great!
Because we’re now using c.t’s with a defined voltage output, I had thought that the Ical value should be scaled to read the same numeric value as the rated c.t. current, i.e. 50 for a 50 A c.t, which I thought would make more sense to most users. But as you’ve now started out with essentially the same calibration factor as for the predecessor emonTxs (i.e. the current that would give 1.00 V at the c.t. input), it looks like we’re stuck with it.
Thanks for the clear images of the cable orientation.
Now, with the correct USB-C cable orientation, the emonBase see the USB0 (Bus 001 Device 004: ID 10c4:ea60 Silicon Labs CP210x UART Bridge)
[email protected]:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 001 Device 003: ID 04e2:1411 Exar Corp. XR21B1411
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[email protected]:~ $ ls -la /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 Dec 22 08:18 /dev/ttyUSB0
Unfortunately, I have some issue with emonTx4 firmware update, again (I’m omitting many ***failed; <br /> rows by the logs).
<details><summary>LAST ENTRIES ON THE LOG FILE</summary><br />
-------------------------------------------------------------<br />
emonTxV4_LPL Firmware Upload<br />
-------------------------------------------------------------<br />
Downloading firmware from: <br />
https://github.com/openenergymonitor/emontx4/releases/download/1.5.4/EmonTxV4_LPL.hex<br />
<br />
Downloaded file: <br />
-rw-r--r-- 1 pi pi 91K Dec 19 11:53 /opt/openenergymonitor/data/firmware/emonTxV4_LPL.hex<br />
<br />
EmonHub is running, stopping EmonHub<br />
<br />
Uploading emonTxV4_LPL on serial port ttyUSB0<br />
Attempt 1...<br />
<br />
<br />
avrdude-original: Version 6.3-20171130<br />
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/<br />
Copyright (c) 2007-2014 Joerg Wunsch<br />
<br />
System wide configuration file is "avrdude.conf"<br />
User configuration file is "/root/.avrduderc"<br />
User configuration file does not exist or is not a regular file, skipping<br />
<br />
Using Port : /dev/ttyUSB0<br />
Using Programmer : arduino<br />
Overriding Baud Rate : 115200<br />
AVR Part : AVR128DB48<br />
Chip Erase delay : 0 us<br />
PAGEL : P00<br />
BS2 : P00<br />
RESET disposition : dedicated<br />
RETRY pulse : SCK<br />
serial program mode : yes<br />
parallel program mode : yes<br />
Timeout : 0<br />
StabDelay : 0<br />
CmdexeDelay : 0<br />
SyncLoops : 0<br />
ByteDelay : 0<br />
PollIndex : 0<br />
PollValue : 0x00<br />
Memory Detail :<br />
<br />
Block Poll Page Polled<br />
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack<br />
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------<br />
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00<br />
prodsig 0 0 0 0 no 125 125 0 0 0 0x00 0x00<br />
fuses 0 0 0 0 no 9 16 0 0 0 0x00 0x00<br />
fuse0 0 0 0 0 no 1 0 0 0 0 0x00 0x00<br />
fuse1 0 0 0 0 no 1 0 0 0 0 0x00 0x00<br />
fuse2 0 0 0 0 no 1 0 0 0 0 0x00 0x00<br />
fuse4 0 0 0 0 no 1 0 0 0 0 0x00 0x00<br />
fuse5 0 0 0 0 no 1 0 0 0 0 0x00 0x00<br />
fuse6 0 0 0 0 no 1 0 0 0 0 0x00 0x00<br />
fuse7 0 0 0 0 no 1 0 0 0 0 0x00 0x00<br />
fuse8 0 0 0 0 no 1 0 0 0 0 0x00 0x00<br />
lock 0 0 0 0 no 4 1 0 0 0 0x00 0x00<br />
data 0 0 0 0 no 0 0 0 0 0 0x00 0x00<br />
flash 0 0 0 0 no 131072 512 0 0 0 0x00 0x00<br />
eeprom 0 0 0 0 no 512 32 0 0 0 0x00 0x00<br />
<br />
Programmer Type : Arduino<br />
Description : Arduino<br />
Hardware Version: 3<br />
Firmware Version: 25.1<br />
Vtarget : 0.3 V<br />
Varef : 0.3 V<br />
Oscillator : 28.800 kHz<br />
SCK period : 3.3 us<br />
<br />
avrdude-original: AVR device initialized and ready to accept instructions<br />
<br />
Reading | ################################################## | 100% 0.00s<br />
<br />
avrdude-original: Device signature = 0x1e970c (probably avr128db48)<br />
avrdude-original: reading input file "/opt/openenergymonitor/data/firmware/emonTxV4_LPL.hex"<br />
avrdude-original: writing flash (33264 bytes):<br />
<br />
Writing | ##################avrdude-original: stk500_recv(): programmer is not responding<br />
# ***failed; <br />
***failed; <br />
....
....
***failed; <br />
# | 100% 16.29s<br />
<br />
avrdude-original: 33264 bytes of flash written<br />
avrdude-original: verifying flash memory against /opt/openenergymonitor/data/firmware/emonTxV4_LPL.hex:<br />
avrdude-original: load data flash data from input file /opt/openenergymonitor/data/firmware/emonTxV4_LPL.hex:<br />
avrdude-original: input file /opt/openenergymonitor/data/firmware/emonTxV4_LPL.hex contains 33264 bytes<br />
avrdude-original: reading on-chip flash data:<br />
<br />
Reading | avrdude-original: stk500_recv(): programmer is not responding<br />
avrdude-original: stk500_recv(): programmer is not responding<br />
#avr_read(): error reading address 0x0200<br />
read operation not supported for memory "flash"<br />
avrdude-original: failed to read all of flash memory, rc=-2<br />
avrdude-original: stk500_recv(): programmer is not responding<br />
<br />
avrdude-original done. Thank you.<br />
<br />
avrdude-original: Using autoreset DTR on GPIO Pin 7<br />
avrdude-original: Using autoreset DTR on GPIO Pin 7<br />
avrdude-original: Using autoreset DTR on GPIO Pin 7<br />
ERROR: Not in sync<br />
<br />
Restarting EmonHub</details><br />
Now, the emonBase is not receiving any inputs from the emonTx4.
True, I know you suggested this before. The user interface used for calibration shows the value as the CT rating. So it’s only at the lower level of serial config that it’s the same as before. One advantage is that this maintains consistency with the earlier units. Which I think is worthwhile at least at this point when the firmware is so similar in terms of serial configuration format etc. It could always be changed in future if we are changing the serial configuration format significantly…
That driver maybe conflicts with the cp210x usbserial driver (the driver used to comunicate with the emonTx4) but I’m not sure (I’ve tried to remove the xr_usb_serial_common driver, but nothing).
I will try to investigate this.
CT clamp is in port 1. The CT type was selected as 50A. Do I need to do anything with the other settings? Phase correction of 0 seems to be at odds with the rest, but is that something I set, or something measured?
Hello @tomq42 phase correction should be 3.2 like the rest. There shouldn’t be a change in radio performance, what does the data look like in the graph? Did you need compatibility radio firmware? If so you need to upload the native jeelib version of the firmware that’s a step I realise I haven’t highlighted prominently enough perhaps?
All of the temperature sensors are back plugged in to the emonTx. I have plugged them in and then powered up the emonTx. Me disturbing a connection on one of the three plugs I can believe, but doing it on all and getting nothing feels less likely.
I’ve tried them all on their own and in different combinations, but it always says “no temperature sensors detected”. I’ve tried sending it a “t0 1” to try and turn on temperature.
.
