Yes; it’s a shame the nanodeRF is no longer functional because of library issues (£70 the poorer). Must back up current libraries to prevent future library changes/updates causing ths same problem with my current functioning devices emonTx, emonBasePi & emonGLCD)
I have more or less a complete set, but the problem was the IDE changed as well, and I didn’t have an old version of that.
I’ve got IDE 1.04 & 1.06 if you’re interested.
I’ll try these with my nanodeRF
I think you need an earlier version than those. I’d tried a 1.0.6, and there were far too many errors to chase down.
And to make matters worse, most intelligent IDEs allow you to specify a library exactly. Arduino doesn’t, it appears to grab whatever it can find. I guess that arises from a misguided attempt to dumb it down, and they took it too far.
But unless you’re keen to recommission the Nanode, is it worth putting much effort into this?
Edit: This was a false trail - see post no.51
Not really
If you do any nanodeRF experiments let me know the results please. I use 2 that are working and have 2 spares which are dead without firmware.
I might have found the problem: The reported value for “SS” has changed to Pin 10.
I decided to abandon the OEM sketch and try the demo ones. I picked “testDHCP.ino” because I’d established that the ENC28J60 was not responding to readOp(byte op, byte address) in enc28j60.cpp
Here’s setup()
void setup () {
Serial.begin(57600);
Serial.println(F("\n[testDHCP]"));
Serial.print("MAC: ");
for (byte i = 0; i < 6; ++i) {
Serial.print(mymac[i], HEX);
if (i < 5)
Serial.print(':');
}
Serial.println();
// Change 'SS' to your Slave Select pin, if you arn't using the default pin
if (ether.begin(sizeof Ethernet::buffer, mymac, SS) == 0)
Serial.println(F("Failed to access Ethernet controller"));
Serial.println(F("Setting up DHCP"));
if (!ether.dhcpSetup())
Serial.println(F("DHCP failed"));
ether.printIp("My IP: ", ether.myip);
ether.printIp("Netmask: ", ether.netmask);
ether.printIp("GW IP: ", ether.gwip);
ether.printIp("DNS IP: ", ether.dnsip);
}
True to form, all I got was
[testDHCP]
MAC: 74:69:69:2D:30:31
I checked my old circuit diagram and /CS is shown as DIG8, so I inserted two lines just above “Change ‘SS’ to your Slave Select pin, if you arn’t using the default pin”, i.e., before the call to ether.begin(...)
byte SS = 8;
Serial.print("SS=");Serial.println(SS);
and here’s what I get:
[testDHCP]
MAC: 74:69:69:2D:30:31
SS=8
Setting up DHCP
My IP: 192.168.1.67
Netmask: 255.255.255.0
GW IP: 192.168.1.254
DNS IP: 192.168.1.254
I cannot find where SS is defined anywhere in the EtherCard library, so my theory is JeeLib or another library has ‘poached’ it and set it as a Global variable.
Perhaps one of you can check that defining SS = 8 works on your set-up?
(The third parameter into ether.begin(sizeof Ethernet::buffer, mymac, SS) is optional, so if only two are given, just add it as the above example.)
Here is a working “kit” for the NanodeRF _multinode sketch. It works with the current (as of 10 Mar 2019) Ethercard library (file dates 25 Aug 2018 & 13 Jan 2019) and JeeLib (all files dated 10 June 2018) but I’ve included the essential parts of those too.
I’ve included the above change, in a rather neater fashion, changed the text strings to remain in flash memory, so freeing up a valuable couple of hundred bytes, and got rid of some compiler warnings.
NanodeRF.zip (108.9 KB)
Many thanks Robert, your efforts really appreciated.
Regards
Ian
1 Like
Thanks Robert nanodeRF working & receiving time updates from the server but emonGLCD clock not updating; I’ll have to check whether any mods made to emonGLCD sketch to accomodate emonBasePi.
The only way I could get the sketch to upload was to hold down the reset button until ‘uploading’ appeared at the bottom of the sketch window & only then release the reset button (something I always have to do on my mega2560 with shield fitted)
Also, green led flashes briefly & red led turns OFF briefly but at all other times red led is ON. In the original sketch ‘red led ON is BAD!!’
I just added the sketch filename into void setup() but on running the sketch it prints the filename approx every 16 seconds so it looks as though WDT is resetting & the green led flashes indicating setup has finishednanodeRF output.txt (236 Bytes)nanodeRF output.txt (407 Bytes)
The NanodeRF is set as NodeID = 30, so if you want the time from this instead of the emonPi, you’ll need to change something: you could get the time in the GLCD from either (by putting an ‘or’ into the logic); or if you’re only ever going to have either the Nanode or the emonBase on at any one time, you could change the Nanode to be node 5.
I don’t know why that should be any different - the sketch has nothing to do with the upload process.
It only did that for me when it was receiving data every second. When I slowed the emonTx down to every 10 seconds, it behaved perfectly.
Something must be slowing - or stopping - the main loop because the watchdog is reset every time round. Coupled with the red LED problem, I’d look first at DNS. It didn’t misbehave for me, and I can’t see an obvious reason, so I’m struggling.
You should be seeing something like this, when it’s receiving from a sensor node:
[webClient RW]
DHCP status: 1
IP: 192.168.1.69
GW: 192.168.1.254
DNS: 8.8.8.8
DNS status: 1
SRV: 80.243.190.58
Data sent: /input/post.json?apikey=deadbeeffeedfadedeadbeeffeedfade&json={rf_fail:1}
OK received
Time request sent
Time: t19,40,47
Data sent: /input/post.json?apikey=deadbeeffeedfadedeadbeeffeedfade&node=9&csv=3,0,2,28,822,28022,4,0,0,0,30000
OK received
Data sent: /input/post.json?apikey=deadbeeffeedfadedeadbeeffeedfade&node=9&csv=4,0,7,34,1940,28026,4,0,0,0,30000
OK received
Data sent: /input/post.json?apikey=deadbeeffeedfadedeadbeeffeedfade&node=9&csv=5,0,12,38,3019,28023,4,0,0,0,30000
OK received
Data sent: /input/post.json?apikey=deadbeeffeedfadedeadbeeffeedfade&node=9&csv=6,0,13,39,3424,27995,4,0,0,0,30000
OK receivedchanged #define MYNODE 30 to #define MYNODE 5
My serial output gets only as far as:
…
OK received
Time request sent
Time: t20,53,26
its obviously failing at the void loop() lines:
// Display error states on status LED
if (ethernet_error==1 || rf_error==1 || ethernet_requests > 0)
{
digitalWrite(redLED,LOW); //turn red LED ON
but I can’t work out why
ps my emonTx transmits every 7s
And emoncms.org will only accept data once every 10 s. I’d try changing that to 10 s. You won’t gain anything, my understanding is it will actually be recording every other reading, but how it stores the data depends on how you’ve set up the feed.
As I said, mine couldn’t handle data every second. I’m not a networking expert, so I’m struggling here.
Your original sketch (my_nanodeRF_22-2-2019.ino) handles the data in a markedly different way to the multinode: yours interprets the data and then reassembles it and sends it, whereas the multinode “forwards” it in the same format as it was received, leaving emonCMS to interpret it.
If your old sketch worked for you, why not just transplant the tiny bit I added to get it to initialise the Ethernet module?
If you remember my old nanodeRF stopped working altogether; ethernet & Rf. Your sketch gets the ethernet side working OK it’s the Rf that appears to be the problem (I assume between emonTx & nanodeRf).
I’ll try your suggestion of increasing the Rf interval on the emonTx to 10s & see if that helps
Tried updating my emonTx as suggested but I’ve got a new problem; the sketch won’t upload, returning the error ‘avr dude: stk500_getsync() …’.
Tried all the usual stuff, FTDI, cable, drivers; even changed the Atmega 328 & tried on a different computer but the problem remains.
Very strange as I last updated emonTx in Feb with no problems & I haven’t changed anything I’m aware of to cause this problem.
I was using an emonTx V2 to generate the test data. 
So there’s nothing about the current Arduino IDE (I’m using the Ubuntu 1.8.7 version) that’s likely to cause that. Whenever I’ve had that, it’s invariably been a broken core in the cable - once the USB but most times the decidedly dodgy 6-way ribbon cable that I use between the programmer and whatever - it seems a lot safer (mechanically) than plugging the programmer directly into the emonTx/Nanode.
Given the age of your V2, have a good look for dry joints in the FTDI area.
I’ve tried different FTDI/USB devices with different cables so it appears to be the emonTx so I’ll check for dry joints as you suggest
Turns out to be the FTDI/USB; the only one that will upload sketches is the Wicked Device Nanode so now I’ll try your suggestion of increasing the Rf interval on the emonTx to 10s & see if that helps
That’s what I have - it used to be the stocked “shop” one. The present ‘shop’ one looks to be almost the same, but there are detail differences: the silk screen is different: apart from “OpenEnergyMonitor” replacing “Wicked Devices Nanode”, some component designations have moved and it’s a different font, but the component layout does not appear to have changed.