Community
OpenEnergyMonitor

Community

EmonTX with 500A 50ma CT sensors NO power values


(John) #1

HI, CT Sensors seem to be working on emonPI as atleast values are registering. However, on any of my 9 emonTX’s, no power values register. If I monitor the serial on emontx I see values from CT sensors but this is not showing in emoncms on a PI. Tried all the mqtt. restarts etc. If I plug temp sensors in, those values show up fine.

From log in EMonhub

INFO MQTT Publishing: emonhub/rx/2/values 0,0,0,0,0.1,3000,3000,3000,3000,3000,3000,1,-74

From serial monitor on emontx
0.09 1.450 0.000 0.000 0.000 -0.00 -0.06 -0.06 -0.00 59.323 -0.0001 0.0000 0.0000 0.0000 300.00 Pulses=1 PLL is unlocked

Running default 3-phase sketch with freq 50 changed to 60. No ac-ac yet

Regards,


(Robert Wall) #2

If the PLL is unlocked, you cannot depend on the values from the sketch, and this

is the reason. You cannot expect a PLL to lock without a voltage reference, Neither can you expect meaningful power values.

But even so, the (useless) data should get through. The first things to look at:

  1. If you have 9 emonTx’s, do they each have an unique NodeID?
  2. Does each Node definition in emonHub match the format of the data being sent by the sketch?

(Paul) #3
INFO MQTT Publishing: emonhub/rx/2/values 0,0,0,0,0.1,3000,3000,3000,3000,3000,3000,1,-74

This payload doesn’t look correct for the current emoncms mqtt inputs, this was the old nodes module format. The emonhub log should show each value individually published to a separate topic with a common “emon” base topic and node topic eg emon/emonTx1/voltage 240.00 etc.

This is of course dependent on the value names being defined in the nodes section of emonhub.conf and the right (default) mqtt interfacer settings.


(John) #4

Hmm I think you guys are on to something in regards to the value names.

I updated the Node names to reflect what I want to call each emontx. All the Emontx’s have unique node IDs, they would show up in emonhub under node 1 thru 9. I updated emonhub config to reflect ex: Node1Isle1, Node2Isle2 etc etc. I did not however change any names or anything in the individual emontx’s. However, if temp sensors are connected, they all register proper individual values from the emontx’s. Is this possibly because the value names didnt change in emonhub and the emontx? In any case here is the emonhub config where I only added the node name changes. If I need to change node names in emontx’s, which file would that be in? Appreciate the help guys…


(John) #5
[nodes]


[[1]]
    nodename = 1_Isle1
    [[[rx]]]
       names = powerL1, powerL2, powerL3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p

[[2]]
    nodename = 2_Isle2
    [[[rx]]]
       names = powerL1, powerL2, powerL3, power4, Vrms, temp1, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p

[[3]]
    nodename = 3_Isle3
    [[[rx]]]
       names = powerL1, powerL2, powerL3, power4, Vrms, temp1, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p

[[4]]
    nodename = 4_Isle4
    [[[rx]]]
       names = powerL1, powerL2, powerL3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p

[[6]]
    nodename = 5_Isle5
    [[[rx]]]
       names = powerL1, powerL2, powerL3, power4, Vrms, temp1, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p

[[5]]
    nodename = emonpi
    [[[rx]]]
        names = power1,power2,power1pluspower2,vrms,t1,t2,t3,t4,t5,t6,pulsecount
        datacodes = h, h, h, h, h, h, h, h, h, h, L
        scales = 1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
        units = W,W,W,V,C,C,C,C,C,C,p

[[7]]
    nodename = 6_Isle6
    [[[rx]]]
       names = powerL1, powerL2, powerL3, power4, Vrms, temp1, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p

[[8]]
    nodename = 7_Isle7
    [[[rx]]]
       names = powerL1, powerL2, powerL3, power4, Vrms, temp1, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p

[[9]]
    nodename = 8_Isle8
    [[[rx]]]
       names = powerL1, powerL2, powerL3, power4, Vrms, temp1, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p

[[10]]
    nodename = 9_Isle9
    [[[rx]]]
       names = powerL1, powerL2, powerL3, power4, Vrms, temp1, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p


[[19]]
   nodename = emonth1
   [[[rx]]]
      names = temperature, external temperature, humidity, battery
      datacode = h
      scales = 0.1,0.1,0.1,0.1
      units = C,C,%,V

[[20]]
   nodename = emonth2
   [[[rx]]]
      names = temperature, external temperature, humidity, battery
      datacode = h
      scales = 0.1,0.1,0.1,0.1
      units = C,C,%,V

[[21]]
   nodename = emonth3
   [[[rx]]]
      names = temperature, external temperature, humidity, battery
      datacode = h
      scales = 0.1,0.1,0.1,0.1
      units = C,C,%,V

[[22]]
   nodename = emonth4
   [[[rx]]]
      names = temperature, external temperature, humidity, battery
      datacode = h
      scales = 0.1,0.1,0.1,0.1
      units = C,C,%,V

[[23]]
    nodename = emonth5
    [[[rx]]]
       names = temperature, external temperature, humidity, battery, pulsecount
       datacodes = h,h,h,h,L
       scales = 0.1,0.1,0.1,0.1,1
       units = C,C,%,V,p

[[24]]
    nodename = emonth6
    [[[rx]]]
       names = temperature, external temperature, humidity, battery, pulsecount
       datacodes = h,h,h,h,L
       scales = 0.1,0.1,0.1,0.1,1
       units = C,C,%,V,p

[[25]]
    nodename = emonth7
    [[[rx]]]
       names = temperature, external temperature, humidity, battery, pulsecount
       datacodes = h,h,h,h,L
       scales = 0.1,0.1,0.1,0.1,1
       units = C,C,%,V,p

[[26]]
    nodename = emonth8
    [[[rx]]]
       names = temperature, external temperature, humidity, battery, pulsecount
       datacodes = h,h,h,h,L
       scales = 0.1,0.1,0.1,0.1,1
       units = C,C,%,V,p

(John) #6

emonhub log

2019-01-07 20:38:41,855 DEBUG    MQTT       Publishing: emon/emonpi/vrms 0
2019-01-07 20:38:41,857 DEBUG    MQTT       Publishing: emon/emonpi/t1 0
2019-01-07 20:38:41,859 DEBUG    MQTT       Publishing: emon/emonpi/t2 0
2019-01-07 20:38:41,860 DEBUG    MQTT       Publishing: emon/emonpi/t3 0
2019-01-07 20:38:41,862 DEBUG    MQTT       Publishing: emon/emonpi/t4 0
2019-01-07 20:38:41,864 DEBUG    MQTT       Publishing: emon/emonpi/t5 0
2019-01-07 20:38:41,866 DEBUG    MQTT       Publishing: emon/emonpi/t6 0
2019-01-07 20:38:41,867 DEBUG    MQTT       Publishing: emon/emonpi/pulsecount 0
2019-01-07 20:38:41,869 INFO     MQTT       Publishing: emonhub/rx/5/values 0,0,0,0,0,0,0,0,0,0,0
2019-01-07 20:38:43,442 DEBUG    RFM2Pi     188 NEW FRAME : OK 1 0 0 0 0 0 0 0 0 12 0 114 9 48 117 48 117 48 117 48 117 48 117 1 0 0 0 (-60)
2019-01-07 20:38:43,446 DEBUG    RFM2Pi     188 Timestamp : 1546893523.44
2019-01-07 20:38:43,447 DEBUG    RFM2Pi     188 From Node : 1
2019-01-07 20:38:43,447 DEBUG    RFM2Pi     188    Values : [0, 0, 0, 0, 0.12, 241.8, 3000, 3000, 3000, 3000, 3000, 1]
2019-01-07 20:38:43,448 DEBUG    RFM2Pi     188      RSSI : -60
2019-01-07 20:38:43,449 DEBUG    RFM2Pi     188 Sent to channel(start)' : ToEmonCMS
2019-01-07 20:38:43,449 DEBUG    RFM2Pi     188 Sent to channel(end)' : ToEmonCMS
2019-01-07 20:38:43,535 DEBUG    MQTT       Publishing: emon/1_Isle1/1 0
2019-01-07 20:38:43,537 DEBUG    MQTT       Publishing: emon/1_Isle1/2 0
2019-01-07 20:38:43,539 DEBUG    MQTT       Publishing: emon/1_Isle1/3 0
2019-01-07 20:38:43,541 DEBUG    MQTT       Publishing: emon/1_Isle1/4 0
2019-01-07 20:38:43,543 DEBUG    MQTT       Publishing: emon/1_Isle1/Vrms 0.12
2019-01-07 20:38:43,545 DEBUG    MQTT       Publishing: emon/1_Isle1/temp1 241.8
2019-01-07 20:38:43,547 DEBUG    MQTT       Publishing: emon/1_Isle1/temp2 3000
2019-01-07 20:38:43,549 DEBUG    MQTT       Publishing: emon/1_Isle1/temp3 3000
2019-01-07 20:38:43,550 DEBUG    MQTT       Publishing: emon/1_Isle1/temp4 3000
2019-01-07 20:38:43,553 DEBUG    MQTT       Publishing: emon/1_Isle1/temp5 3000
2019-01-07 20:38:43,555 DEBUG    MQTT       Publishing: emon/1_Isle1/temp6 3000
2019-01-07 20:38:43,557 DEBUG    MQTT       Publishing: emon/1_Isle1/pulse 1
2019-01-07 20:38:43,559 DEBUG    MQTT       Publishing: emon/1_Isle1/rssi -60
2019-01-07 20:38:43,561 INFO     MQTT       Publishing: emonhub/rx/1/values 0,0,0,0,0.12,241.8,3000,3000,3000,3000,3000,1,-60

(Paul) #7

Of your 8 emonTx’s, only 2 (nodeids 1 and 4) have the same count of names and values. It seems nodes 2,3,6,7,8,9 are all missing names for temp sensors 2 thru 6, OR they have too many datacodes if the sketches only output 1 temperature reading.

If you look at emonhub.log it should be clear what is happening.

Is the Mqtt interfaces set up ok?

Are there any messages telling you the datacodes do not fit the data received?

Are there any “publishing to” messages?

If you show us some emonhub.log it might help. posted whilst i was writing.


(John) #8

OK even if I rename for example the temp field name in emonhub, the values still come in so im thinking filed name changes have no bearing on data coming in or not


(John) #9

Keep in mind that not all 9 emontx’s have been turned on. At the moment, only one is on and connected to the EmonPi. Im not aware of Matt interfaces


(John) #10

yes each emontx will only have one temp sensor attached. Once I get things going, I will remove the extra temp values for a cleaner read.


(John) #11

most recent emonhub with RFm2Pi info

2019-01-07 20:51:33,974 DEBUG    RFM2Pi     device settings updated: E i5 g210 @ 433 MHz q0 USA 0
2019-01-07 20:51:34,078 DEBUG    RFM2Pi     device settings updated: E i5 g210 @ 433 MHz q0 USA 0
2019-01-07 20:51:34,187 DEBUG    RFM2Pi     3 NEW FRAME : OK 1 0 0 0 0 0 0 0 0 13 0 127 9 48 117 48 117 48 117 48 117 48 117 1 0 0 0 (-60)
2019-01-07 20:51:34,191 DEBUG    RFM2Pi     3 Timestamp : 1546894294.19
2019-01-07 20:51:34,192 DEBUG    RFM2Pi     3 From Node : 1
2019-01-07 20:51:34,192 DEBUG    RFM2Pi     3    Values : [0, 0, 0, 0, 0.13, 243.10000000000002, 3000, 3000, 3000, 3000, 3000, 1]
2019-01-07 20:51:34,193 DEBUG    RFM2Pi     3      RSSI : -60
2019-01-07 20:51:34,194 DEBUG    RFM2Pi     3 Sent to channel(start)' : ToEmonCMS
2019-01-07 20:51:34,194 DEBUG    RFM2Pi     3 Sent to channel(end)' : ToEmonCMS
2019-01-07 20:51:34,380 DEBUG    MQTT       Publishing: emon/1_Isle1/powerL1 0
2019-01-07 20:51:34,382 DEBUG    MQTT       Publishing: emon/1_Isle1/powerL2 0
2019-01-07 20:51:34,383 DEBUG    MQTT       Publishing: emon/1_Isle1/powerL3 0
2019-01-07 20:51:34,385 DEBUG    MQTT       Publishing: emon/1_Isle1/powerL4 0
2019-01-07 20:51:34,386 DEBUG    MQTT       Publishing: emon/1_Isle1/Vrms 0.13
2019-01-07 20:51:34,388 DEBUG    MQTT       Publishing: emon/1_Isle1/temp1 243.1
2019-01-07 20:51:34,390 DEBUG    MQTT       Publishing: emon/1_Isle1/temp2 3000
2019-01-07 20:51:34,391 DEBUG    MQTT       Publishing: emon/1_Isle1/temp3 3000
2019-01-07 20:51:34,393 DEBUG    MQTT       Publishing: emon/1_Isle1/temp4 3000
2019-01-07 20:51:34,394 DEBUG    MQTT       Publishing: emon/1_Isle1/temp5 3000
2019-01-07 20:51:34,396 DEBUG    MQTT       Publishing: emon/1_Isle1/temp6 3000
2019-01-07 20:51:34,398 DEBUG    MQTT       Publishing: emon/1_Isle1/pulse 1
2019-01-07 20:51:34,399 DEBUG    MQTT       Publishing: emon/1_Isle1/rssi -60
2019-01-07 20:51:34,401 INFO     MQTT       Publishing: emonhub/rx/1/values 0,0,0,0,0.13,243.1,3000,3000,3000,3000,3000,1,-60

(Paul) #12

That’s new info. So we are looking for just one emontx and that is there in your emonhub.log, are you saying that still isn’t showing in emoncms?

No, nor I. That was supposed to be Mqtt but auto spell correction had other odeas, now corrected.


(John) #13

Correct, for the moment only looking for that one emontx. As per log, Mqt tseems to be reporting info like correct temp info from emontx but power values are 0. If I serial into the emontx and monitor it, I see values for the CT Sensors


(Paul) #14

I’m not sure I will work like that. You must have the correct datacodes for the data being sent. if you say there are values that sum up to a cetain size and a packet arrives of a different size, it will discard the packet. so you need to get that right up front. If I recall correctly, the datacode arrays are included in the sketch headers so you only need to copy it over unless you edit the sketches payload.

In your example I don’t think the temp of 243.1 degs C is accurate, that sounds more like a voltage?

Start with defining the nodes correctly, emonhub is supposed to discard data that doesn’t “fit” and looking at incorrectly labelled data will aways cause confusion.


(Paul) #15

This line

2019-01-07 20:51:34,187 DEBUG    RFM2Pi     3 NEW FRAME : OK 1 0 0 0 0 0 0 0 0 13 0 127 9 48 117 48 117 48 117 48 117 48 117 1 0 0 0 (-60)

is the raw data, the first value after the “OK” is the node, the following 8 zero’s are the 8 bytes that make up the 4 16bit “power?” values. As you can see the data arriving via the serial connection is all zero’s so the issue is in the sketch or the way it is connected/configured. (or there is another node 1 transmitting locally)


(John) #16

The line you quoted came from the emonhub log.

ALso thx for the reference to the datacode arrays in the sketch. I found those values and copy pasted to the emonhub config. Now decimal for temps is correct but still not getting values for power… hhmm


(John) #17

For serial input, emonHub requires “datacode = 0” in place of “datacodes = …” as above.
Line from sketch…

What does for serial input mean?


(Paul) #18

If you were connecting the emonTx running that sketch, directly to the gpio (instead of the emonpi addon or rfm2pi) or via a usb-serial adapter, then the data is passed as “normal” human readable values and no decoding is required (ie zero decoding), it has nothing to do with the airbourne RFM payloads that are all “byte values” and require decoding.


(John) #19

got it.!


(John) #20

Ohh well, still no go :frowning:

Here is a copy of my sketch for 3 phase 240v per phase plus neutral. Very little changed from defaults

/*  Energy monitor for 3-phase 3-wire or 4-wire installation

    Based on a single phase energy diverter by Martin Roberts 2/12/12, which itself was
    based on emonTx hardware from OpenEnergyMonitor http://openenergymonitor.org/emon/
    this version implements a phase-locked loop to synchronise to the mains supply and
    supports a single Dallas DS18B20 temperature sensor.
    
    Temp fault codes: 300 deg = Sensor has never been detected since power-up/reset. 
                      302 deg = Sensor returned an out-of-range value. 
                      304 deg = Faulty sensor, sensor broken or disconnected.
                      85  deg   although in range, might indicate a wiring fault.

    Three-phase energy monitor
    V 1.0   10/12/17 The original extensively modified with diverter code removed
                     and extended for 3-phase operation. 
    V 1.1   20/02/18 Sleep (sleep_mode()) removed from rfm_sleep() in rfm.ino
    V 1.2   12/03/18 Temperature fault codes were
                      300 deg = Faulty sensor, sensor broken or disconnected.
                      301 deg = Sensor has never been detected since power-up/reset. 
                      302 deg = Sensor returned an out-of-range value. 
    V 1.3   25/09/18 Declaration of showString() added - omission thereof caused 
                      compiler error in Arduino IDE V1.8.7
    V 1.4   22/10/18 Added 3-wire options & switch for 4-wire / 3-wire operation, 
                      free choice of phase for all four c.t's. 
                      
    
                     
    History (single Phase energy diverter):
    2/12/12  first published version
    3/12/12  diverted power calculation & transmission added
    4/12/12  manual power input added for testing
    10/12/12 high & low energy thresholds added to reduce flicker
    12/10/13 PB added 3rd CT channel to determine diverted power
    09/09/14 EmonTx v3 option added by PB ( http://openenergymonitor.org/emon/node/5714 )


    emonhub.conf node decoder settings for this sketch:

    [[11]]
        nodename = emonTx_three_phase
        firmware = three_phase
        hardware = emonTx V3.2/V3.4/Shield
    [[[rx]]]
        names = power1, power2, power3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulsecount
        datacodes = h, h, h, h, h, h, h, h, h, h, h, L
        scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
        units =W,W,W,W,V,C,C,C,C,C,C,p
    
    IMPORTANT NOTE:
    When used in the 3-wire configuration with one line conductor being treated as the 'neutral', the
    individual powers recorded for the other two line conductors are meaningless, only the TOTAL power
    of the line conductors has a physical meaning. Therefore, 'power1' is the COMBINED power of inputs 1 & 2
    and all the values for input 2 alone are set to zero.
    Note also: Only one temperature sensor may be connected. All remaining temperatures will read "300.00"

    For serial input, emonHub requires "datacode = 0" in place of "datacodes = ...." as above.
    
*/
const int version = 14;                          // The firmware version 1.4

#define EMONTX_V34                               // Sets the I/O pin allocation. 
                                                 // use EMONTX_V2 or EMONTX_V32 or EMONTX_V34 or EMONTX_SHIELD as appropriate
                                                 // NOTE: You must still set the correct calibration coefficients

//--------------------------------------------------------------------------------------------------
// #define DEBUGGING                             // enable this line to include debugging print statements
                                                 //  This is turned off when SERIALOUT or EMONESP (see below) is defined.

#define SERIALPRINT                              // include 'human-friendly' print statement for commissioning - comment this line to exclude.

// Pulse counting settings
#define USEPULSECOUNT                            // include the ability to count pulses. Comment this line if pulse counting is not required.
#define PULSEINT 1                               // Interrupt no. for pulse counting: EmonTx V2 = 0, EmonTx V3 = 1, EmonTx Shield - see Wiki
#define PULSEPIN 3                               // Interrupt input pin: EmonTx V2 = 2, EmonTx V3 = 3, EmonTx Shield - see Wiki
#define PULSEMINPERIOD 110                       // minimum period between pulses (ms) - default pulse output meters = 100ms
                                                 //   Set to 0 for electronic sensor with solid-state output.
                                                 
// RFM settings                                  // THIS SKETCH WILL NOT WORK WITH THE RFM12B radio.
#define RFM69CW                                  // The type of Radio Module, or none.
                                                 // Can be RFM69CW 
                                                 //   or SERIALOUT if a wired serial connection is used 
                                                 //   or EMONESP if an ESP WiFi module is used
                                                 //     (see http://openenergymonitor.org/emonnode/3872) 
                                                 //   or don't define anything if neither radio nor serial connection is required - in which case 
                                                 //      the IDE serial monitor output will be for information and debugging only.
                                                 // The sketch will hang if the wrong radio module is specified, or if one is specified and not fitted.
                                                 // For all serial output, the maximum is 9600 baud. The emonESP module must be set to suit.
                                                 
#undef RF12_433MHZ
#undef RF12_868MHZ
#undef RF12_915MHZ                               // Should not be present, but can cause problems if they are.

#define RF12_433MHZ                              // Frequency of RFM module can be 
                                                 //    RF12_433MHZ, RF12_868MHZ or RF12_915MHZ. 
                                                 //  You should use the one matching the module you have.
                                                 //  (Note: this is different from the normal OEM definition.)

#define RFPWR 0x99                               // Transmitter power: 0x80 = -18 dBm (min) - 0x9F = +13 dBm (max)
                                                 //    0x99 - RFM12B equivalent
                                                 //    A 5 V supply is required for the emonTx V3.4 versions prior to V3.4.4 if power is set 
                                                 //    significantly above the minimum.

int nodeID = 11;                                 //  node ID for this emonTx. Or nodeID-1 if DIP switch 1 is ON.
int networkGroup = 210;                          //  wireless network group
                                                 //  - needs to be same as emonBase and emonGLCD. OEM default is 210



//--------------------------------------------------------------------------------------------------

//--------------------------------------------------------------------------------------------------
// constants which must be set individually for each system


double vCal = 268.97;     // calculated value is 240:11.6 for UK transformer x 13:1 for resistor divider = 268.97
                          //   for the EU adapter use 260.00, for the USA adapter use 130.00
#define VCAL_EU 260.0     // can use DIP switch 2 to set this as the starting value.                     
double i1Cal = 90.91;     // calculated value is 100A:0.05A for transformer / 22 Ohms for resistor = 90.91, or 60.6 for emonTx Shield
double i2Cal = 90.91;     // calculated value is 100A:0.05A for transformer / 22 Ohms for resistor = 90.91, or 60.6 for emonTx Shield
double i3Cal = 90.91;     // calculated value is 100A:0.05A for transformer / 22 Ohms for resistor = 90.91, or 60.6 for emonTx Shield
double i4Cal = 16.67;     // calculated value is 100A:0.05A for transformer / 120 Ohms for resistor

double i1Lead = 2.00;     // degrees by which the v.t. phase error leads the c.t.1 phase error
double i2Lead = 2.00;     // degrees by which the v.t. phase error leads the c.t.2 phase error
double i3Lead = 2.00;     // degrees by which the v.t. phase error leads the c.t.3 phase error
double i4Lead = 0.20;     // degrees by which the v.t. phase error leads the c.t.4 phase error

#define WIRES 4-WIRE      // either 4-WIRE (default, measure voltage L1 - N) or 3-WIRE (no neutral, measure voltage L1 - L2)

#define CT1Phase PHASE1   // either PHASE1, PHASE2 or PHASE3 to attach c.t.1 to a phase. This c.t. MUST be used.
#define CT2Phase PHASE2   // similarly to attach c.t.2 to a phase. This c.t. MUST be used.
#define CT3Phase PHASE3   // similarly to attach c.t.3 to a phase. This c.t. MUST be used, do not comment this line.
#define CT4Phase PHASE1   // similarly to attach c.t.4 to a phase or comment this line if c.t.4 is not used 
                          //   (See also NUMSAMPLES below)
#define LEDISLOCK         // comment this out for LED pulsed during transmission
                          //  otherwise LED shows loop is locked, and occults to show transmission, but that is not easily visible
//--------------------------------------------------------------------------------------------------

//--------------------------------------------------------------------------------------------------
// other system constants
#define SUPPLY_VOLTS 3.3  // used here because it's more accurate than the internal band-gap reference. Use 5.0 for Arduino / emonTx Shield
#define SUPPLY_FREQUENCY 60
#define NUMSAMPLES 33     // number of times to sample each 50/60Hz cycle - for a 4-wire system, this must be a multiple of 3;
                          //   for a 3-wire system, it must be a multiple of 6
                          // Permissible maximum values (serial only) 50 Hz, 3 c.t: 45         60 Hz, 3 c.t: 36
                          //                                          50 Hz, 4 c.t: 36         60 Hz, 4 c.t: 33
#define ADC_BITS 10       // ADC Resolution
#define ADC_RATE 64       // Time between successive ADC conversions in microseconds
#define LOOPTIME 5000     // time of outer loop in milliseconds, also time between data transmissions

#define PLLTIMERRANGE 100 // PLL timer range limit ~ +/-0.5Hz
#define PLLLOCKRANGE 40   // allowable ADC range to enter locked state
#define PLLUNLOCKRANGE 80 // allowable ADC range to remain locked
#define PLLLOCKCOUNT 100  // number of cycles to determine if PLL is locked

//--------------------------------------------------------------------------------------------------
//
//   Users should not need to change anything below here
//
//
//--------------------------------------------------------------------------------------------------

FYI - Plugging in 2 CT Sensors into EmonPi I get power values.! This is just not working with emonTX…

[edited for readability, please use 3 backticks ``` on the lines before and after code to get it to display correctly, pb]