@TrystanLea Thanks very much for the update - I’ll try it out and let you know …
@TrystanLea I updated my emonhub to 115200 as above, and updated my firmware on the update page to
port etc: ttyAMA0/emnoPi/RFM69 Low Power Labs
firmware: emonPi continuous sampling firmware, lowpowerlabs, 1.1.4
However, the update log said I was downloading
`https://github.com/openenergymonitor/emonpi/releases/download/04-04-23/emonPi_CM_LPL_1_1_3.hex
and said the size was 31902 bytes.
I powered off the emonpi and restarted it.
There are now no emonPi or LPL radio inputs …
Putting emonhub back to 38400 restores the emonPi and LPL radio inputs, so I would think that I haven’t got the real 1.1.4 emonPi_CM firmware …
Ah you may need to run the emonPi update first or more specifically the admin > components> Emonscripts repository.
I may be missing something, if it listed 1.1.4 but still downloaded 1.1.3, I’m out at the moment, will check here later
I just tried updating the scripts, and then tried the firmware update listed as 1.1.4, but still got 1.1.3
I am on the master branch - not sure if that is the correct one?
Thanks
Hi @TrystanLea - have you updated the Docs? Perhaps a specific section on moving to the CM Lib might work?
Need to detail the changes to emonhub required to make this work, I’d suggest.
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?
@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 …
1 Like
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?
Ok, will do
@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.
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.
1 Like
@Robert.Wall Thanks very much for the extra information.
Trystan did say above
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.
1 Like
@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?
Only if it exceeds the available program memory, otherwise it should work just the same. The emonth LPL firmware still uses the full library
@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.
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.
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.
2 Likes
@Robert.Wall
Thanks very much for the information. Hopefully the LPL firmware uses polling too, to allow the second pulse input.
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.
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!
1 Like