Uno. emonTx Shield. 3Phase. RFM69. - - - Recommended firmware?

danbates · 2018-07-26T10:15:27.760Z

As above… I have an Arduino Uno with emonTxShield.

I’m looking to setup monitoring for a 3-phase installation.

I want to use the Tx’s RFM69CW radio module to emonBase.

I can get this firmware working:

github.com

emontx-shield/firmware/Shield_CT1234_Voltage at master ·...

master/firmware/Shield_CT1234_Voltage

emonTx Arduino Shield. Contribute to openenergymonitor/emontx-shield development by creating an account on GitHub.

to monitor the phases independently.

I’d like to try:

GitHub

GitHub - openenergymonitor/emontx-3phase: emonTx 'approximate' 3-phase firmware

emonTx 'approximate' 3-phase firmware. Contribute to openenergymonitor/emontx-3phase development by creating an account on GitHub.

but can’t seem to get it working for this shield… I have the latest hardware.

For clarity, it’s safe to upload to the UNO with the Shield attached?
I’ve changed #define EMONTX_V34 to #define EMONTX_SHIELD
I get no serial output and the LED flashes a few times and then is continuously ON.

When the CT is connected as shown, wire in proximity to the coil here makes a buzzing sound from inductance and messes with the ATMEGA. I wouldn’t leave it like that. Can’t recommend that one, no

183264×1836 1010 KB

danbates · 2018-07-26T17:55:11.601Z

I’ve found part of this problem was not understanding the 3 phase firmware…
I assumed having #define DEBUGGING and #define RFM69CW simultaneously would mean serial output which I was expecting… I can only get information if the I replace #define RFM69CW with #define SERIALOUT or comment out the line…
Now to figure out why changing Vcal doesn’t seem to do anything…

Robert.Wall · 2018-07-26T18:21:00.810Z

Quote:

SERIALPRINT
Turns on ‘human-friendly’ print statements for calibration and commissioning - comment
this line to exclude. You should probably comment this when the installation is working
satisfactorily. This output format is automatically turned off if either of the other serial
output formats is selected.

…

RFM69CW
Defines the mode of transmitting the output data. Permissible settings are:

RFM69CW	Hope RFM69CW radio module
SERIALOUT	Wired serial connection via the FTDI port (suitable for direct connection to the emonBase or emonPi (see https://github.com/openenergymonitor/emonTxFirmware/ blob/master/emonTxV3/noRF/ emonTxV3_DirectSerial/emonTxV3_DirectSerial.ino )
EMONESP	ESP8266 WiFi module (see https://github.com/openenergymonitor/EmonESP)

If neither radio nor serial connection is required, do not define anything - in which case, the serial output will be ‘human readable’ for information and debugging only. NOTE: The sketch will hang if the wrong radio module is specified, or if one is specified and not fitted.

Robert.Wall · 2018-07-26T18:48:02.767Z

Quote:

EEPROM Memory
The internal EEPROM memory can be used to retain some of the system settings and
calibration constants. When the settings have been saved to EEPROM memory, those
values are read at each power-up thereafter and override the values in sketch. You can
however choose to restore the default values and erase the EEPROM settings. How to
store, change and revert the settings is explained later.

danbates · 2018-07-27T03:00:19.173Z

It’s a useful program but takes a while to set up I’m finding!

To enter configuration mode at start-up, using the serial monitor part of the Arduino IDE, enter “+++” followed by the [Enter] key when prompted. You must respond within 10 seconds. If you do nothing, the start-up procedure continues normally after the timeout has expired.
You will then see a short menu:

. typing ‘+++’ and enter doesn’t seem to do anything for me. It’s a problem as the printed RF settings are

OpenEnergyMonitor.org
emonTx Shield CT1234 Voltage 3 Phase PLL example - Firmware version 1.00
Loaded EEPROM config
Calibration:
vCal = 241.20
i1Cal = nan
i1Lead = nan
i2Cal = nan
i2Lead = nan
i3Cal = nan
i3Lead = nan
i4Cal = nan
i4Lead = nan
Network: 72
Node: 195 Freq: 433MHz
POST…wait 10s
‘+++’ then [Enter] for config mode

and changing the sketch values (int nodeID = 6; int networkGroup = 210;) doesn’t do anything either. Any clues? I’m using Arduino IDE 1.8.5

. Changing vCal in the sketch doesn’t seem to do anything. Typing ‘r’ after ‘+++’ and enter doesn’t seem to change anything.

. Do I have to manually enter every iCal value through serial?

. It’s not clear having defined DEBUGGING or SERIALPRINT what extra information is outputted. A header would be useful labelling each column of serial output… What do these mean? Real and Apparent power especially… which ones are they?

36814×83 14.3 KB

. I have no CT4 connected, is there an advantage to connecting CT4 for lower power circuits? It’s not clear to me if the program is spending time sampling CT4 when it’s not connected.

danbates · 2018-07-27T04:12:36.670Z

Not sure if this is related:
#define RFM69CW
doesn’t allow any serial output at all.

EDIT: working after correcting jumper settings on Shield.

danbates · 2018-07-27T04:25:00.646Z

Unfortunately mine hangs at
void sendResults()
It’ll be a pin assignment, jumper or physical soldering issue…

18968×525 74.8 KB

danbates · 2018-07-27T05:18:09.591Z

The main thing was to correct my jumper settings.

I changed the pin assignment in the sketch to match the shield guide.
IRQ should be 2 for UNO, 3 for Leonardo. Uno’s most common I think.

EmonTx_Shield_SMT_RFM69CW.jpg800×505 156 KB

// EmonTx Shield Pin references
#define VOLTSPIN 0
#define CT1PIN 1
#define CT2PIN 2
#define CT3PIN 3
#define CT4PIN 4
#define LEDPIN 9
#define RFMSELPIN 5   // See Wiki
#define RFMIRQPIN 2   // See Wiki //changed!
#define SDOPIN 12
#define W1PIN 4       // 1-Wire pin for temperature

could do something like
#define EMONTX_SHIELD_ARDUINO_L // for TxShield: comment out for Uno, in for Leonardo

then

// EmonTx Shield Pin references
#define VOLTSPIN 0
#define CT1PIN 1
#define CT2PIN 2
#define CT3PIN 3
#define CT4PIN 4
#define LEDPIN 9
#define RFMSELPIN 5   // See Wiki
#ifdef EMONTX_SHIELD_ARDUINO_L
#define RFMIRQPIN 3   // See Wiki
#else
#define RFMIRQPIN 2   // See Wiki
#endif
#define SDOPIN 12
#define W1PIN 4       // 1-Wire pin for temperature

danbates · 2018-07-27T05:28:49.459Z

Excellent, working now
many thanks.

Robert.Wall · 2018-07-27T08:37:54.839Z

The sketch was specifically written for @Simsala, he seems very happy with it and it was he who submitted it to Github.

danbates:

#define RFM69CW
doesn’t allow any serial output at all.

That is not true. I think you should read the documentation.

Relating to some other comments above, you are of course free to change whatever you wish, but if you make a change, you must do whatever tests you feel necessary to assure yourself that it works and performs to your satisfaction.

danbates · 2018-07-27T09:25:21.585Z

Of course.
It was a RFM jumper setting on my shield, causing a hang and stopping serial output…
It works great. It’s interesting to think about whether a sketch like this should have settings that ‘work out the box’… or whether a user should HAVE TO go through a calibration and settings routine to get an output.
I don’t disagree with the method, however given that all other OEM software works out the box I had an expectation this would do the same, and of course, assumptions are the mother of…

It could be clearer that the calibration process and various settings are MANDATORY, in that sense, it’s an excellent learning resource. This could be clearer in the introduction. That is all.

The +++ command still didn’t work for me. I had to write the RFM settings in config.ino. If I find a reason I’ll post a solution.

Many thanks.

Simsala · 2018-07-28T10:18:48.438Z

Yes, I’m very happy with the firmware, it’s a great improvement over the previous three-phase firmware. Thanks again to @Robert.Wall .

The firmware is configured to work out-of-the-box for the current emontx version without software adaptations. For other configurations an adjustment has to be made, of course. The code for other versions is also already available, all you need to do is select the #define at the very beginning of the source code: emontx-3phase/src.ino at dbb950d8e0baf2bf1885c5f012ea01973fbb4b92 · openenergymonitor/emontx-3phase · GitHub

If I understand it correctly, the problems resulted from the combination of the emontx shield with the Arduino Leonardo? Here of course the difficulty arises to support all possible hardware combinations. But pull requests are always welcome.

Individual calibration is not really necessary as long as the UK transformer is used for the voltage reference. For the EU transformer the calibration factors are not correct, this still has to be improved.

Which program do you use to access the serial port to enter the configuration menu? With Platformio it works without problems for me, if the Arduino software is used the field to the left of the baud rate (line endings) must be set to Both NL & CR.

danbates · 2018-07-28T18:05:38.512Z

That was the problem yes, except mine’s an Uno.
… NL & CR works! +++ now lists available commands and all is beautifully intuitive
Wonderful work.

So the program checks for data in eeprom, and if nothing is found default values are used defined in the sketch… Hence out of the box functionality with emonTx?.. With my uno/TxShield the eeprom values were ‘nan’ but their use was attempted regardless, meaning I had to write to the eeprom to get any usable values transmitted. No big deal.
I think this may specific to the Uno, I’ve got the official R3 with no change to the EEPROM before adding this sketch. I don’t know.

I have a second official uno, blank also, which I could test with now I’m more familiar with the setup.

Robert.Wall · 2018-07-28T18:16:39.412Z

You clearly had a value that was not 0xFF in the first byte of the EEPROM, i.e. it had been used previously and not erased. You can erase the EEPROM (or the part that the sketch uses) with a documented command issued via the monitor.

The sketch uses exactly the same protocol as the emonTx (i.e. none) for determining if the EEPROM is in use, and it uses the first few bytes in exactly the same way for the same variables.

danbates · 2018-07-28T18:27:46.896Z

This is the output from a brand new Arduino Uno R3 with Tx Shield, fresh install of the 3phase firmware version1.0, from master, no changes except making the line #define EMONTX_SHIELD.

26983×493 39.1 KB

As you know, simply entering config mode ‘+++’ and pressing ‘r’ (with NL & CR set next to Baud rate in Arduino IDE) will make use of the sketch default values and provide basic functionality.
I wouldn’t define this as ‘out of the box’ functionality. Particularly with the incorrect iCal values defaulted for the TxShield.

That is all

Robert.Wall · 2018-07-28T19:29:38.012Z

That still means that the first byte of the EEPROM was not 0xFF, and indeed we know that because the first byte is the Node ID, for which the value 195 is reported (0xC3). And it would appear that the higher bytes were indeed 0xFF, which I understand is the default “never used” value for all erasable memory, as the calibration constants are all stored as float, and a float or double with all bits set is NAN.

The “protocol” used by the emonTx has no mechanism to determine the integrity of the values in the EEPROM.

I could very easily have included a “signature” to determine whether the EEPROM values belonged to this sketch, and a checksum to verify the content. However, I felt that compatibility with the emonTx was important enough to override that.

danbates · 2018-07-28T20:01:00.207Z

I was thinking the same… I was trying to think of a suitable term, signature is precise. A signature would be a solution.
A signature could be added to the end of the EEPROM, or located somewhere far enough away to not make conflict with potential additions…