emonTx v2 not passing data to nanodeRF

Suddenly after 7 years my data was not being posted to emocms.org.
The green LED of the emonTx flashes every 10s as is usual.
The nanodeRF (emonbase) used to show a flashing red LED when all was working but now the red LED doesn’t flash & the green LED is permanently ON indicating that the void setup() hasn’t finished.
The serial output I get is:

Failed to access Ethernet controller

Looking at the sketch even with the above ‘Failed to access Ethernet controller’ the setup should complete & the green LED should turn OFF (notice the comment “Nanode RF LED indictor setup - green flashing means good - red on for a long time means bad!
High means off since NanodeRF tri-state buffer inverts signal”.

I’ve changed the RFM12 on both the emonTx & the nanodeRF but problem remains

Keep it simple as I’m not a coder

You don’t mention which sketch you’re using, I’m looking at NanodeRF_multinode.ino and “Failed to access Ethernet controller” is printed when the Ethernet controller, the ENC28J60, doesn’t return the correct response - it should be the version number - to being initialised.

Assuming you’ve checked (or substituted) the power supply, and because it appears that the Atmel 328P is working, I think it means that the ENC28J60 has failed. I can’t be absolutely certain - if a DIL Atmel 328P is available, it might be worth swapping it and reloading the sketch just in case it is the processor.

Looks like there’s no shortage of 328 DIPs available. A Google search turns up quite a few sources.
e.g. SparkFun, Mouser, Digikey as well as the manufacturer themselves, Microchip.

UK sources include Farnell, RS and Hobbytronics

The sketch I’m running is NanodeRF_Power_RTCrelay_GLCDtemp

Just placed an order for an ENC28J60; I’ll keep you posted on the outcome

Tried a new Atmel 328P & the problem is still there so it’s looking like the ENC28J60 is the likely culprit

Another issue has arisen with my emonTx v2 regarding sketch outputs.
I lost my original sketch from 7 years ago so downloaded emonTx_CT123_Voltage & added print statments to output ct1, ct2 & Vrms. I’m running on the bench & only using ct1 which seems to give a reasonable reading measuring the power supplied to a tower PC but there’s something wrong with Vrms showing a reading of approx 27,400V! My actual AC voltage is 248V.
Suggestions please

The voltage*100 (ie centivolts) is passed due to the exclusive use of 16bit signed ints (<32768 ie 327.68V) with RFM transmissions at that time. 274 V still seems a bit high, you should check vcal and make sure your AC adapter output, input voltage divider resister values and vcal all tally, or alternatively just set vcal to existing_vcal*(actual_voltage/reported_voltage) as rough calibration.

The V2 & V3 use different voltage divider ratios, so calibration coefficients for the V3 don’t apply to the V2. The starting value is on the calibration page in ‘Learn’. (Check which a.c. adapter you have.)

Fitted new ENC68J60 but problem remains so ordered replacement CD74HCT125E just in case.

Update on this post. I fitted new CD74HCT125E & replaced both 1702 voltage regulators but problem remains. I’ve checked board for dry solder joints but all looks ok.
The only items I haven’t replaced are the discreet components like resistors, capacitors & crystals.
I’m begonning to think it’s more software than hardware. Any suggestions where to go from here?

Update on this post. I fitted new CD74HCT125E & replaced both 1702 voltage regulators but problem remains. I’ve checked board for dry solder joints but all looks ok.
The only items I haven’t replaced are the discreet components like resistors, capacitors and crystals.
I’m beginning to think it’s more software than hardware.

Now I’m getting:
DHCP status: 0
DHCP failed
Data sent: /api/post.json?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&json={rf_fail:1}
Time request sent

& the red led is permanently on.
Any suggestions where to go from here?

Looking through old archives I came across a post of mine from 27/10/2014 when a similar problem of emoncms.org stopped updating. That was caused by a change made by Trystan to the server. Could something similar be casuing my current posting issue? (emoncms.org stopped updating on 1/2/2019)

You have not mentioned changing anything in software, and that is why my thoughts turned immediately to hardware. I don’t quite see how it can be software - unless something has updated itself and you’re not aware of that.

But to confirm that - have you still got the sources for the sketches? Have you reloaded them?

The NanodeRF is 7 years old, there are 4 electrolytic capacitors in it, but only 3 are on the schematic, the 4th is optional. If anything is going to fail, it’s likely to be one of those. But unless it’s been in a very warm place, I think it’s a long shot.

Have there been any changes that might be relevant?

I’ve tried umpteen sketches from way back that worked back then but the problem remains.
I did notice that in all old sketches there was a line:

char website[] PROGMEM = “emoncms.org”;

that failed to compile unless changed to:

const char website[] PROGMEM = “emoncms.org”;

Could a library change be the cause of my problem?
I’m now back to: [webclient] & a solid green led

My nanodeRf has 2 electrolytic capacitors plus the option pin2 to pin 6 I added but also has 13 other small value capacitors (1 either side of the 2 crystals = 4 plus 9 others). I’ll try changing these if you think it’s possible one or more could be faulty.

There have been changes to the Arduino IDE - PROGMEM is one of them.

But surely it failed while it was running the software that was compiled 7 years ago? Or have you recompiled with new libraries in between?

I wouldn't change components at random without some justification. The fact that the processor is running rules out a lot of things. If you have access to a 'scope, the first thing I'd do is check the supply rails. If one of the smoothing capacitors had lost capacitance, that could cause untold problems. The disc ceramics are not top of my list.


I use several nanodeRF. I haven’t access to my code at the moment as I am at home. But I seem to remember the format changed to /input/… from /api/… some years ago. Possibly the sketches have not been changed. I reported it at the time but that must be in the old forum. A search there might confirm details.


I haven’t made any related changes recently to emoncms.org so I dont think it is that. The api/post endpoint also maps through to the newer input/post so that wont be the cause. I notice its unable to get DHCP in the log above, have you tried restarting your home router, perhaps its not giving it a connection?

changed both electrolytic capacitors; no change!
Changed DNS server from Google (8,8,8,8) tp (virginmedia) - problem still the same

Reset router but problem still there. I also tried running sketch getDHCPandDNS - 2011-07-05 [email protected] with the same error:
Failed to access Ethernet controller
DHCP failed
My IP:
DNS failed

The LAN port activity LED flashes as expected if a connection was made

Could someone check the sketch I’m using as this problem is looking more software related

decode_reply.ino (1.2 KB)
dhcp_dns.ino (2.1 KB)
my_nanodeRF_22-2-2019.ino (12.8 KB)

I should mention that the post title is no longer accurate as my emonTx is talking to my emonGLCD it’s only the nanodRf (emonbase) that’s still the problem

Robert, when the failure initially occured on 2/2/2019 all 3 devices failed to talk to one another (emonTx, nanode Rf and emonGLCD). Back in 2014? when I last uploaded the sketches I wasn’t uploading a filename with the sketch for identification purposes (something which I do now) so I don’t know which sketches were last uploaded. I’ve gone back & used date stamps of the various sketches used in the past but there are a lot of them because of frequent changes but I also can’t be sure I still have the last uploaded sketches. During the troubleshooting stage I uploaded assorted sketches to the 3 devices & managed to get 2 of them working (emonTx & emonGLCD now talking to each other).

Are there any original sketches & libraries dating from around 2014 for the nanodeRf? (I’m suspicious that the problem may be library related) especially when I found I had to change the following in all earlier nanodeRf sketches I tried, which had originally compiled OK, as detailed below:

char website[] PROGMEM = “emoncms.org”;

failed to compile unless const was added prefixed to ‘char website’

const char website[] PROGMEM = “emoncms.org”;