Unable to see values from second emon Tx V3

Hi

I’ve been using an emon Tx V3 (Node 8) and an emonBase for about 4 years to monitor my electricity usage and PV generation and have just bought a second emon Tx V3 (Node 15) to extend what I can monitor. When I initially connected the new emon Tx I could see Node 15 but the values were reading 21845 and looking on the forum saw the topic https://community.openenergymonitor.org/t/stange-values-like-21845-from-all-sensors/12764.
I then thought the best thing to do was purchase a new SD card with the latest image on it and this is where I am getting stuck/lost/confused! When I put the new card into the emonBase I cannot connect to it (have Fing on my phone which shows the emonBase is not on line) put the old SD card back in and I can see it and connect?

Any help getting me back up and running would be most appreciated.

Having been further trawling through the information I see it says the latest emonSD image is compatible with Raspberry Pi 3, 3B+ & 4 and having checked the Pi in my emonBase it shows it is a Model 2 B, so is this why it doesn’t run with the new SD card?
If that is the case what is the best way to get my second emon Tx V3 to connect to my emonBase?

There is a note on the download page for the changes needed to run on a Pi 2. I’m about to write a new SD card for my EmonPi, which has a Pi 2 inside - though it may not happen for a few days (or weeks) yet.

SSH is disabled by default on the new image. If that’s what you were using (indirectly maybe), then there’s a note about that too.

Caveat: I’m not absolutely sure that the image will run on an emonBase (i.e. without the LCD display), but I believe it should.

Thanks Robert, I’ll have a look at that.
Is it possible to continue to run with the older SD version but be able to receive data from the latest emon Tx V3 alongside the data from my earlier emon Tx?

Yes, if you turn off “whitening” in your new emonTx.

It was introduced because the radio link can lose sync if there’s a long stream of binary zeros (or ones), which you can get with the energy values at startup or with temperature values with no sensors present - which is why they all now read “300°”.

You’ll need to edit the sketch and reload it to make the change: Make line 39 #define RF_WHITENING into a comment.

The downside may be you lose the new emonTx, or both, if the transmitter (emonTx) and receiver (emonBase) are at significantly different temperatures, for example, so that their data rate clocks are different and don’t have a changing stream of ones and zeros to maintain sync. If it hasn’t been a problem up until now, you might get away with it. There’s a reasonable amount of information about this problem in the RFM69CW data sheet.

Your “best” solution will be to get the emonBase going with the new SD card, because then you have a per node choice as to whether each sensor node uses or doesn’t use whitening.

I do have a emonBase with a Pi 2B, Rev 2.1 (I think), so it’s possible I can fire that up with the new SD image. But I probably won’t get to that for some time.

Thanks again Robert, I’ll give that a try. Also as an alternative could I just use a newer Pi 3 model in the emonbase so the latest SD image would work without modification?

1 Like

As far as I know, that should be fine.

1 Like

I have emonCMS booted and running on my emonBase (RPi B, rev 2.1)

I used Etcher to flash the card.

From the SD Download page: emonSD pre built SD card Download & Change Log · openenergymonitor/emonpi Wiki · GitHub

  • Expand data partition to fill SD card: (as at 17 Oct 19 this does not work)

Immediately after flashing the image, and before inserting the SD card into the Pi, use GParted. The data partition is the last partition on the card, and can be expanded to fill the whole card.

  • To use this image on Pi2 remove the following lines from /boot/config.txt :
arm_freq=1200
arm_freq_min=600

Only the line arm_freq=1200 in the file boot/config.txt

Both lines are in the file rootfs/opt/openenergymonitor/emonpi/stretch/config.txt

It’s not clear to me whether this overrides or is overridden by the other file. I commented out the line(s) in both files.

It’s booted and connected by Ethernet - there’s no inbuilt WiFi in the Pi and no USB WiFi dongle. I registered a user and it shows all the pages one would expect - and it appears to be updating itself. But it’s got no inputs, a very good reason being it’s a 433 MHz one and I haven’t got anything transmitting on 433 MHz at the moment. :grin:

So at first sight, all seems well.

Robert that sounds promising so I’ll give it a try once I get my head around using Etcher and GParted as I’ve never used either before and thanks again for all the help. :+1:

Etcher is as simple as put the card in the slot, tell it the download image and start it off. It does take a while (mine was a 32 GB card, the smallest Argos sell) to flash and then verify.

GParted isn’t much different - it might need telling which drive the card is, then you’ll just need to drag the top (right-hand) end of the last partition to the right, then start it off.

After that, edit the files while still in the computer.

That line is OK WRT running on a Pi 2.
If the CPU is in on demand mode, it sets the minimum CPU speed, otherwise if the force_turbo
parameter has been set to 1, this line gets ignored.

If nothing else, it’ll help the CPU to run a bit cooler when it’s idling in on demand mode.

It’s the arm_freq=1200 line that’ll make a Pi 2 choke.

All back up and running again, the new SD card that I had was faulty and wouldn’t boot. Spoke with Glyn at Open Energy Monitor and was told to send it back with the emonbase and my older emonTx and they would sort it out. Units came back and emonbase working fine with my new emonTx but still not getting info from the old one. Called them up and they sent a replacement unit out which worked right away. So many thanks to all at Open Energy Monitor.

2 Likes