Possibly. When I compile @chris_cronin’s sketch, I get:
Sketch uses 14638 bytes (45%) of program storage space. Maximum is 32256 bytes.
Global variables use 1792 bytes (87%) of dynamic memory, leaving 256 bytes for local variables. Maximum is 2048 bytes.
I can’t see very heavy use of the stack, though I know JeeLib does nest functions quite deeply.
But as Chris has decided to go the RPi route, I’m not sure whether it’s worth spending too much time on this.
I just realised it is dynamic memory that is the reported problem not sketch size.
Sketch uses 15214 bytes (47%) of program storage space. Maximum is 32256 bytes.
Global variables use 1790 bytes (87%) of dynamic memory, leaving 258 bytes for local variables. Maximum is 2048 bytes.
Low memory available, stability problems may occur.
My interest in this is that I still use nanodeRF and even have spares but they will be of no use if I cannot get them running.
I did try reducing the array sizes to free up memory - it still failed to initialise the RFM with 700+ bytes free, so I think that might be one of several problems.
Thanks for trying. Would you share the sketch with reduced array. I don’t have any problems initialising the RFM. My sketch seems to work OK but the posted data never gets through. I am guessing there may be library differences. I hardly dare update libraries in case it causes further problems.
Very wise - or if you do, zip up the ones you have first. Everybody got caught out by that before, hence the EtherCardOct2012 in Github.
I was using the Multinode sketch, all I did was change byte Ethernet::buffer[700]; down to 200 elements.
But I am using the new (current) ethercard library.
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
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