Updating an emonPi to emonPi_CM

[TrystanLea]

@rupert

I just tried updating the scripts, and then tried the firmware update listed as 1.1.4, but still got 1.1.3

I’ve fixed an issue with the firmware update tool, it will now use the remote copy of firmware_available.json which defines the firmware download URL’s without requiring the local copy of the list to be updated. Though this does require an update to EmonScripts for it to work with the new code.

Can update your EmonScripts repository @rupert via Admin > Components > EmonScripts > Update?

and then after that try updating the emonPi firmware again?

[rupert]

@TrystanLea
I did the ’ update your EmonScripts repository via Admin > Components > EmonScripts > Update’

The update log said:

- current branch: master
- local changes: no
- git fetch: Fetching origin
Already on 'master'
- git checkout: Your branch is up to date with 'origin/master'.
- git pull: Already up to date.
- database update: no changes
- component updated

The version on the Admin > Components page has changed from 1.6.12 to 1.6.13.

I did the emonPi firmware update and this time I got
`https://github.com/openenergymonitor/emonpi/releases/download/20-04-23/emonPi_CM_LPL_1_1_4.hex

I updated my emonhub config to

[[emonpi]]
        Type = EmonHubOEMInterfacer
        [[[init_settings]]]
            com_port = /dev/ttyAMA0
            com_baud = 115200
        [[[runtimesettings]]]
            pubchannels = ToEmonCMS,
            subchannels = ToRFM12,   

        group = 210
        frequency = 433
        baseid = 5                              # emonPi / emonBase nodeID
        calibration = 230V                      # (UK/EU: 230V, US: 110V)
        quiet = true                            # Disable quite mode (default enabled) to enable RF packet debugging, show packets which fail crc
        # interval =  300                         # Interval to transmit time to emonGLCD (seconds)  

The inputs are updating and appearing correctly on the input page.

However the LCD is still incorrect and displays

Data        LCD Display                feed
Power 1:         0                       0
Power 2:         0                       0
Vrms:            0                       253
Pulse          300p                      0
Temp 1:       253.24                     22.25
Temp 2:       22.25                      300

So progress …

[TrystanLea]

Great, thanks @rupert could you keep an eye on packet loss and post the results? should be listed in the inputs for the emonTx4, missed and missed_prc?

[rupert]

Ok, will do

[rupert]

@TrystanLea
Over the about the last 14 hours until now, the results for the emonTx4 (LPL format) as received on the RFM69Pi in the emonPi, are shown below.
Also included for comparison is my emonTx3 (JeeLib Classic format) which is in the same place as the emonTx4, again as received at the emonPi but using a JeeLink 433MHz (v3c) USB module.
The RFM69Pi and Jeelink hardware are very similar. Both have a RFM69CW 433Mhz RX/TX and an atmega328 CPU. The Jeelink has an extra serial to USB chip.

emonTx4 (LPL)
missed:     (at start of period -2) now -9
missed_prc: now -0.22%
rssi:       average about -63, but some spikes down to about -75

emonTx3 (JeeLib Classic)
missed_prc: now 12.4%
rssi:          about -69

I do have other units transmitting at 433MHz, so there might be some interference.
The LPL format is performing better than the JeeLib Classic format in terms of lost data.

[Robert.Wall]

I investigated LPL for/with Trystan earlier this week and we discovered that retries and failures seemed to be caused by the Pi not responding quickly. Trystan has made changes to the code around the receiver in the Pi to alleviate this. Pushing the retry count up to 8 (without those changes), I got zero failures (sending dual packets owing to having 12 input channels active) over a period of 119 hours.

I don’t know when these changes will be published, or if they were in your recent update.

[rupert]

@Robert.Wall Thanks very much for the extra information.

Trystan did say above

@TrystanLea

I’ve updated the emonPi_CM firmware available via the emoncms upload mechanism. The version is now 1.1.4 and includes improvements to the timing in the main loop. Mostly the removal of fixed delays. The result is lower packet loss and a lower number of retries required when acknowledgments are requested by the emonTx4.

so perhaps the v1.1.4 does include the changes. Also the RFM69Pi serial rate has increased from 38400 baud to 115200 baud for this version.

Getting zero failures over 119 hours is a very good result.

[rupert]

@Robert.Wall , @TrystanLea, @calypso_rae One other question about LPL …

I am in the middle of attempting to update my Mk2 PV Router to the LPL radio format, and I was just using the standard Arduino LPL library. Is there any reason that I should use the ‘cut down version’ mentioned above instead?

@TrystanLea

The latest version of the emonPi CM firmware v1.1.3, released on the 4th of April (@rupert this suggests that you are running this version) uses the cut down version of the LowPowerLabs library. I made that change immediately and updated the pre-compiled hex file when we discovered the issue.

[TrystanLea]

@rupert

Is there any reason that I should use the ‘cut down version’ mentioned above instead?

Only if it exceeds the available program memory, otherwise it should work just the same. The emonth LPL firmware still uses the full library

[rupert]

@TrystanLea Thanks for the update. So far it looks like the standard library will fit comfortably in the available program memory, so it should be ok.

[rupert]

Now that the emonPi_CM can measure two pulse counts, I have been wondering how to take advantage of this, and connect two sensors for the two inputs.

As I understand it, the pulse measurements use the interrupt inputs on the ATMega328 front end. This chip has just two interrupt inputs, IRQ0/INT0/D2 and IRQ1/INT1/D3.

IRQ1/INT1/D3 is available on pin 6 of the RJ45 connector and its use for pulse measurements is described in the emonPi Docs at
https://docs.openenergymonitor.org/emonpi/pulse_counting.html

IRQ0/INT0/D2 from the ATMega328 is connected to the IRQ pin of the RFM69CW wireless module. It can also be connected to pin 7 of the RJ45 connector as well, via JP5.

From this, is it right to say that

a) The emonPi_CM firmware does not use the RFM69CW IRQ pin, and has disabled it so that the RFM69CW does not produce any IRQs?

b) If jumper JP5 is closed then a second pulse sensor can be connected to RJ45 pin 7?

On another emonPi_CM topic, after a complete update today (except firmware), the emonPi_CM LCD is still displaying data in the wrong places …

Thanks very much in advance for any help - I appreciate everybody is busy with the new emonTx4 three phase/12 input support.

[Robert.Wall]

All I’m able to say is the emonPiCM software that I released nearly 2 years ago with the RFM69 “Native JeeLib” message format polled the RFM69CW, and did not use interrupts. It’s this that freed up the second interrupt input for pulse counting. I can’t comment about the RFM69 LPL format library as I had absolutely no involvement and only found that it was being used when it was publicly announced.

I put quite a lot of effort into that Jeelib native version, including ensuring that there was at least one sketch available for all legacy OEM monitor nodes, but as in all that time there was never a “factory” released emonPi that used it, it would be a waste of time and effort to continue to maintain it. It was with some sadness that I had to add a note to this effect on the post announcing the software.

[rupert]

@Robert.Wall
Thanks very much for the information. Hopefully the LPL firmware uses polling too, to allow the second pulse input.

[Robert.Wall]

You’ll need to study the code and connections to determine this. I have yet to find the time to do so, hence I can’t tell you. Clearly there’s no need to use interrupts, as the RFM69CW can retain one message in its buffer. Equally clearly, that message needs to be extracted as soon as possible after it’s been verified so as to allow space for the next. I think it’s up to the sketch whether reception is blocked until the message is removed and the buffer emptied, I imagine this would be the case given that the transmitter will retry if it fails to receive an acknowledgement.

[rupert]

Thanks very much for the update - I’ll have to have a look at the code.

And personally, thanks for all the work you have done on emonLibDB too Sampling 3 voltage channels, 12 current channels and doing 3 phase is no mean feat!

[TrystanLea]

@rupert

Hopefully the LPL firmware uses polling too, to allow the second pulse input.

Yes it does, the code is based directly on Robert’s original firmware, the only change is the radio format and those minor timing changes.

[rupert]

@TrystanLea
Thanks for the confirmation that the LPL uses polling. I’ll have to try a jumper on JP5 on my emonPi …

[john21042 (John Loesch)]

@rupert

emonPi_CM sends
Msg,power1,power2,power1pluspower2,vrms,t1,t2,t3,t4,t5,t6,pulse1count,pulse2count,E1,E2

Hello Rupert - Check me on this, but since the LPL format now has a message # at the beginning, don’t you need a "n, " at the beginning of the “units” line to match up with the “Msg” entry in “names”?

[rupert]

@john21042

yes - sorry I made a correction in post 9:

@rupert

It seems that the node configuration that I used is not correct, and should be -

[[5]]
    nodename = emonpi
    [[[rx]]]
       names = Msg, power1,power2,power1pluspower2,vrms,t1,t2,t3,t4,t5,t6,pulse1count,pulse2count,E1,E2
       datacodes = L, h, h, h, h, h, h, h, h, h, h, L, L, l, l
       scales = 1, 1,1,1, 0.01, 0.01,0.01,0.01,0.01,0.01,0.01, 1, 1, 1,1
       units = n,W,W,W,V,C,C,C,C,C,C,p,p,Wh,Wh

which has a ‘n’ unit for the Msg data. It also has a nodename of emonpi, so the the original emonpi feeds do not have to be renamed. I have corrected my node configuration to suit.
It would be good if this information could be put into the documentation.