The breadboard pictured in that link is replaced by your emonTx Shield
The second point in that section describes calibration. The rest of this post assumes you’ve read and understand that.
What @danbates was saying is that if you calibrate your EmonTx Shield using power from an FTDI connector so that it outputs correct voltage/current/power readings, and then choose a different method of powering it when you put it into use, the calibration you have already done will no longer be valid.
You need to calibrate it using the power supply you will end up installing with it.
Aye that’s it I was about to say getting things up and running is where you’re at, to forget what I’ve said for now and come back to this calibration point if needed, but Greebo puts it better, calibrate using the power supply you’re going to end up using it with.
Note that the Arduino+shield are running at 5v, whilst the Huzzah is 5v powered it is running at 3.3v so you will need some level adjustments for the serial lines (or at least the Arduino Tx to Huzzah Rx line at the very least). A simple voltage divider might do the trick, look at the shield schematics to see how this is already done for the rfm module as that too is 3.3v and not 5v safe.
@danbates & @Greebo
I think you both should look at emonLib and study in particular what happens when the line
#define emonTxV3
is not present in the sketch (as it won’t be for an emonTx Shield).
EmonLib was created for use with the battery-powered emonTx V2, which does not have a power supply regulator, and therefore the supply voltage, hence the analogue reference, was expected to and did change over the life of the batteries. However, by measuring the (known) internal reference against the (unknown) external reference, the value of that can be deduced.
#define emonTxV3 was created because, in my opinion, there was some confusion over the meaning of “accuracy”, that is, no distinction was made between the uncertainty in the initial value and changes in the value due to external influences, of the internal band-gap reference inside the Atmel 328P.
Sure does, it can be safely connected to the ftdi to pick up the data over serial.
You’ll need a big battery if you’re powering an arduino and WiFi module for long term use. You’ll also need a way to guanatee a stable supply voltage from a battery for accurate measurements as the battery voltage drops.
Gotcha, thanks.
Good to know.
I thought V2 and V3 were about the Tx hardware versions and pinout. Not defining #define emonTxV3 makes emonlib use the internal band gap reference.
Good spot, Sorry it took so long to respond I hadn’t had time to review since you posted. I could recall from past discussions that the Huzzah was not 5v safe despite being 5v powered. looking at the datasheet, you are right the 2 uart and one reset pins do apparently have level-shifting (I do not recall seeing that before nor it coming up in previous discussions), but it is worth noting that it doesn’t apply across the whole device, the other gpio pins are 3.3v only. I do not know if that info was always there, but I do think that is useful info that should be noted on the sales page since the shop sells the 5v shields, although it must say specifically “only the uart and reset pins have level shifting” to avoid confusion (or smoke).
I was about to say getting things up and running is where you’re at, to forget what I’ve said for now and come back to this calibration point if needed, but Greebo puts it better, calibrate using the power supply you’re going to end up using it with.
