Archived Forum

If you got your adapter from the shop, there should be no need to change anything. Otherwise, if you bought an adapter locally, you will probably need to change the voltage calibration, but that will be because the ratio of mains voltage to output voltage of the adapter will be different, not because the mains voltage itself is different.

If you are using the 100 A YHDC ct, you should not need to change the current calibration. The phase calibration should be close provided you are using the YHDC ct and your ac adapter has a similar phase error to ours.

Thanks Robert.

I know that by using a AC-AC adapter, emonTx would automatically detects it is a AC power source and it would adjust the voltage to 120V as in US that's what we have. But I was thinking just to use a battery to power emonTx V3, therefore I'd like to double check to see if I need to upload a new Sketch because I checked the code for the default emonTx V3 on github and it had a hard coded Votage of 240V as it is for the UK. (I know that it is better to use a AC-AC power adapter as it would be more accurate anyway, but I don't have to place near by the switch box in my house to plug AC-AC adapter)

Ah, I see what you're saying. If you're on battery power, then you are assuming a voltage and yes, you do need to change that number in the sketch to your normal voltage, and that multiplied by the measured current gives you apparent power (volt-amperes), not real power (watts).

To edit and upload the sketch, you will need to install the Arduino IDE and you'll need a programmer too.

Ahhh I too have the same issue.... and i am using the provided ac to ac adapter here in the US. when i monitor the data from the Arduino i get

monTx V3 Discrete Sampling V1.3
OpenEnergyMonitor.org
Performing power-on tests.....please wait 10s
CT 1 Calibration: 90.90
CT 2 Calibration: 90.90
CT 3 Calibration: 90.90
CT 4 Calibration: 16.60
RMS Voltage on AC-AC Adapter input is: ~247V
AC-AC adapter detected - Real Power measurements enabled
assuming powering from AC-AC adapter (jumper closed)
Vcal: 138.40
Phase Shift: 1.70
CT 1 detected
Unable to detect DS18B20 temperature sensor
RFM12B Initiated:
Node: 10 Freq: 433Mhz Network: 210
23 12785
44 12766
28 12813
40 12785
33 12787
46 12831
36 12779
33 12814
22 12788
43 12789
37 12789
41 12826

So what is your issue? You think you are using an AC adapter and that indeed appears to be the case. The voltage it is measuring is varying between 127.66 V and 128.31 V - if that is not correct, what is the actual voltage you have? - and the power is reading between 22 and 46 W, so essentially there's no significant load. In your case, there's no need to change the constant "230 V" that's used for apparent power calculations as it seems to be getting the true voltage from the adapter, but if it's not reading the true voltage, then it's the voltage calibration constant 'Vcal' (line 62)  that you need to change.

Thanks for your reply.... I seemed to have solved to issue by adjusting the vcal to 138.4. However I have now developed a new issue... The Emon tx V3 is no longer connecting to the Pi with the RFM12B. 

When the Pi boot the led on the RFM12b flashes once then once more after boot.... then nothing.... sigh

Please note the data i displayed in my previous post above is with the adjustments made to the Vcal.  

OK, so you don't have an issue with calibration. You changed the calibration constant according to the calibration instructions. Big deal. What was the point in misleading everybody by saying you have an issue?

Do you really mean you now have a problem with the RF, or are you using "issue" to mean something different to the normal meaning?

Assuming this time you do mean you have a problem, you need to check everything associated with the RFM12B. My guess is you changed something else as well as the calibration. What frequency is the RFM12B in your emonTx?

I double check both the frequency on the Sketch :

#define RF_freq RF12_433MHZ                                              // Frequency of RF12B module can be RF12_433MHZ, RF12_868MHZ or RF12_915MHZ. You should use the one matching the module you have.
const int nodeID = 10;                                                // emonTx RFM12B node ID
const int networkGroup = 210; 
typedef struct { int power1, power2, power3, power4, Vrms, temp; } PayloadTX;     // create structure - a neat way of packaging data for RF comms
  PayloadTX emontx

and

The the frequency on the Pi config file

####################

# Gateway settings #
####################
[gateway]
# loglevel must be one of DEBUG, INFO, WARNING, ERROR, and CRITICAL
# see here : http://docs.python.org/2/library/logging.html
loglevel = DEBUG

#############
# Listeners #
#############
[listeners]

# This listener manages the RFM2Pi module
[[RFM2Pi]]
    type = OemGatewayRFM2PiListener
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
    [[[runtime_settings]]]
        sgroup = 210
        frequency = 4        baseid = 15
        sendtimeinterval = 300

# This listener gets data from a socket
[[Socket]]
    type = OemGatewaySocketListener
    [[[init_settings]]]
        port_nb = 50011
    [[[runtime_settings]]]

###########
# Buffers #
###########
[buffers]

# The two following buffers instantiate the same class,
# that formats the data for an emoncms instance.
# One sends the data to a local instance, the other one
# to a distant one.
# If active is set to False, the buffer neither records nor sends any data,
# but it holds unsent data until active becomes True.
[[emoncms_local]]
    type = OemGatewayEmoncmsBuffer
    [[[init_settings]]]
    [[[runtime_settings]]]
        domain = localhost
        apikey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        protocol = http://
        active = False
        path = /emoncms

[[emoncms_remote]]
    type = OemGatewayEmoncmsBuffer
    [[[init_settings]]]
    [[[runtime_settings]]]
        domain = emoncms.org
        apikey = d0c3447c13714526a549800e45f2f583
        protocol = http://
        active = True
        path =

Again I apologize for the error 

First, I have deleted 7 very similar posts to your response above. When you post, please look carefully to see how the site responds. You should have seen a message stating that your comment was held in the queue awaiting approval. This is a mechanism to hamper spammers. Your post clearly is not spam, but the automatic system was unsure.

When I asked if you checked the frequency, I meant the actual frequency to which the RFM12B module is tuned. It should be marked on the emonTx, but if not, look at the pictures here. Am I right to think it has worked once? If so, I assume it is 433 MHz.  Why is the frequency in the Pi configuration file "4" and not "433"?

The OEM Gateway settings file is formatted in lines as that is how the settings are read, pythons ConfigObj may be misinterpreting the line 

frequency = 4        baseid = 15

although "4" is actually correct for specifying 433MHz in OEMG, that may not be what is actually being read, "baseid = 15" should be on a new line. https://github.com/Jerome-github/oem_gateway/blob/master/oemgateway.conf.dist#L35-L36, But since the RFM2Pi retains its settings, this doesn't explain how or why the setting could be incorrect, corrupt or forgotten (or where the new line went), only that it may not be able to correct the setting if that was the case.

Try putting the new line back in to see if it makes a difference.

Paul

Here I am again... i seemed to have solved the communication issue by using a completely different ready to go image for the Pi since is dated August 13  and located https://github.com/emoncms/emoncms/blob/bufferedwrite/docs/setup.md i said aha... it should work and it did. Yea for me.

Now with that said new issue has arisen.

When i use the tail -f /var/log/emonhub/emonhub.log command i get WARNING 153 RX data length: 12 is not valid for datacodes (See attached)

 So i reviewed the output of the TX (see attached) and the conf file of the pi (see attached)... both look good. I even did a sudo service emonhub restart

 where am I going wrong?

Regards

The log entries that you see state the error as being

"RX data length: 12 is not valid for datacodes ['l', 'h', 'h', 'h', 'h', 'l', 'l', 'l', 'l']

This message indicates a problem with the received data's length and specifically 12 is not valid for the string of datacodes representing the data's structure, 5 x longs (l) and 4 x ints (h) requires 28 byte values (5x4 + 4x2) so the recieved sstring of 12 values will not allow the process to continue as it cannot map the data types.

In emonhub.conf you have added 

[[10]]

datacodes = l, h, h, h, h, l, l, l, l,

This defines node 10 as needing 28 byte values, I'm entirely sure if that was intentional or not, I cannot see it in the guide you followed.

The serial monitor screen from your arduino IDE shows the default "emonTx V3 Discrete Sampling V1.3" sketch installed on the emonTx which transmits a packet consisting of 6 ints (6x2 = 12) which is why you are getting 12 not 28 values.

If you attempted to install a different sketch to the emonTx that appears to have failed and you should investigate that, or if you intend to use the default sketch you can just remove the node 10 datacodes from emonhub.conf and it will work using the default settings (which is why the guide doesn't tell you to edit the nodes section).

See  http://openenergymonitor.org/emon/node/5289 for more info on datacodes.

Paul

Yep seems like i got it working.  So for my friends in the US here is what i did

used sd image located here https://github.com/emoncms/emoncms/blob/bufferedwrite/docs/setup.md and did the mods in the images attached thanks robert and pb66 for your help..... 

Now i am off to configure emoncms @  http://emoncms.org/yourenergycube

Question for yourenergycude

Why did you use 110V in your calculation of the Vcal?

my line voltage is 120V, and the rated voltage on the provided AC-AC adapter is 120V also.  What am i missing?

Thanks

M

It's quite possible that you're missing nothing. The point about Vcal is it relates the line voltage to the number that comes out of the rms average calculation. As long as you use a consistent set of numbers, it should be correct. It is:

voltage constant = alternating mains voltage ÷ alternating voltage at ADC input pin

For us here in the UK using the adapter from the shop which is rated for 230 V input, 9 V output and has 20% regulation, the numbers are:

voltage constant = 230 × 11 ÷ (9 × 1.20) = 234.26

The components of that, which might cause confusion - but which are explained in Building Blocks - are:

11              - the inverse of the ratio of the resistive voltage divider
(9 × 1.20) - the actual ac adapter output at 230 V

So if you know your adapter gives you 9.72 V with a line voltage of 118.5 V, you'd use those numbers:

voltage constant = 118.5 × 11 ÷ 9.72 = 134.105

but if you have the same mains voltage (118.5 V) but your adapter says it is 120 V in, 9 V out with 25% regulation, you'd either use:

voltage constant = 120 × 11 ÷ (9 × 1.25) = 117.333

or measure the actual values!

Just to confirm - you mean measure the voltage provided from the AC-AC adapter (around 9v) and measure the line voltage directly (which I get 118-120 depending on how the wind blows!)

Real Line voltage * 11 / Output of AC-AC Adapter = VCal?

Indeed - except I've just looked at the thread title and you're using the emonTx V3, and the resistive divider in that is 120 kΩ and 10 kΩ, so the ratio there is 13, not 11.

(Building Blocks was written before the emonTx V3!)

OK my volt meter shows exactly 120Vac on the phase I connect the AC-AC adapter to

The AC-AC adapter shows an output of 11.84Vac

Vcal=120V * 13 / 11.84 = 131.76

After using this Vcal Input 5 on the EmonTx V3 is showing around 121 - which is pretty close.

Am i missing anything or do you think i'm good to go?

You could tweak Vcal to make the EmonTx read exactly the same as your voltmeter. It's for you to decide whether you think that is close enough. What some users have done in the past is compare the energy recorded over a long period against the supplier's meter, and adjusted the calibration to make the numbers agree. I think better than 1% is a probably as close as you'll get.