Hi Chris,
Per your post, I edited the thread title to reflect the change.
Hi Chris,
Per your post, I edited the thread title to reflect the change.
Thanks Bill
I forgot to mention that the reason I originally lost communication between all 3 devices was because the emonGLCD relied on getting the time from emonbase to enable posting of data from emonTx to the LCD screen. Hence, losing the emonbase disrupted communication between the other 2 devices emonTx & emonGLCD. To get around this I fitted a DS3231 RTC to the emonGLCD & changed the emonGLCD sketch to reflect this. Iâve been using the DS3231 for some years on my various devices & it keeps very good time albeit not âinternetâ time.
YVW, S!
Iâll try those sketches and see where I get to. But it might not be for a day or two.
Much appreciated Robert
Iâm afraid Iâm getting nowhere. I appear to have a failed RFM12B (it is the âblobâ type), but even when I comment that out, although it has apparently set up the Ethernet controller, it still fails at the DHCP hurdle.
DHCP status: 0
DHCP failed
Data sent: /input/post.json?apikey=123456789abcdef0123456789abcdef0&json={rf_fail:1}
Time request sent
And this is with your sketch and with a âmultinodeâ sketch that used to work. (Using the Ethercard library from GitHub - njh/EtherCard: EtherCard is an IPv4 driver for the ENC28J60 chip, compatible with Arduino IDE - the last updated file is 13 Jan 2018)
The old 2102 Ethercard library uses obsolete variable definitions, so no longer compiles with the present Arduino IDE (nor with V1.0.6)
error: 'prog_char' has not been declared
Edit: This was a false trail - see post no.51
So it looks like my nanodeRf is âdead in the waterâ unless I can find the original sketch, libraries & old IDE ? Perhaps a change to a more mordern platform like raspberry Pi (donât even suggest emonTv v 3, I tried that with ESP8266 & went round in circles & in the end gave up )
Iâm afraid that does appear to be the case. What Iâd like to do is write a âno Ethernetâ sketch for the Nanode to check whether the ethercard library is screwing up the radio, or whether my radio module itself is dead. I might be able to do that today.
The emonBase (a Raspberry Pi with RFM69Pi radio module) is the replacement for the NanodeRF, in addition it will give you your own emonCMS, so thereâs no need to send to emoncms.org (though you can do either or both).
There should be no problem with your emonTx V2 sending data to the emonBase - the radio protocol is unchanged, and the emonBase can still get the Internet time and send the time to your emonGLCD.
And of course, the data path from emonTx to GLCD is unchanged.
Thanks Robert, you answered my next question of compatability between emonTx v2 & latest emonBase. Is the emonBase ready to go âout of the boxâ? (Iâm not at all familiar with the raspberry Pi) Does it still use Arduino IDE for programming?
No. There is no energy monitoring part to the ârawâ emonBase, the RFM69Pi does use an Atmel328P processor, but it chats to the RPi via the Piâs GPIO connector. You should not need to touch the program in it at all. You operate on the RPi via the Ethernet or WiFi connection.
Look at the âKit includesâ and âDoes not includeâ to see what you need to buy.
You can either buy the SD card with emonCMS and the RPiâs operating system on it, or you could buy a ânakedâ RPi, the RFM 69Pi and a blank SD card, and download and flash the SD card yourself. As youâre not a programmer, I think I know what your choice will be.
The Pi uses a micro USB for the power, so the lead from your Nanode wonât fit, but the power supply itself is probably OK.
If you buy the pre-loaded SD card, pretty much yes. Youâll need to set up the WiFi (if you use it), and your emonCMS and/or the connection to emoncms.org, but that should be possible through your browser.
Hi
I am interested in this as I run several nanodeRF. I also have spares.
There is a lot of information here:-
http://ichilton.github.io/nanode/
Havenât looked to see if it helps.
Ian
Hi
I previously looked here & uploaded the getDHCPandDNS sketch with the same result as my nanodeRf.
Iâve decided to go with the latest emonBase & give up on the nanodeRf
Thanks to all who helped
Not that it helps you, now youâve decided to go the RPi route, but my RFM12B wasnât faulty - something (presumably) in the ethercard library had stopped it responding.
So not only does DHCP not work, it knocked over the radio as well.
What do you run EmonCMS on? You may be better off with an EmonESP as that will connect to your existing setup, or else just buy the RFM card and use it on a PiZero (keeps costs down).
Ouch! @chris_cronin tried that and gave up - couldnât get it to work (look at his âActivityâ). Youâd better take to the hillsâŚ
Arrrgggghhh. Full circle
Thereâs a hole in my bucket dear Liza, dear LizaâŚ
Could this be a sketch size issue?
It always gives a warning about size may give instability. A day or so ago out of interest I pulled out my spare nanodeRF. I tried one of my sketches with a very similar result to Chris. I changed the default node to 14 to avoid conflict. By chance I left it powered up. It was receiving no radio signal so it showed on the serial output it was posting rtfail. To my surprise looking at my inputs this morning I had a node 14 input last seen 24 hours ago!
I have another totally different issue I am working through with Trystanâs help where when I compile a sketch that he has compiled and used in the past I get a resultIng size 102% of available memory and it wonât upload. Could it be the latest Arduino/Atmel setup is producing bigger compiled results?
I am very keen to keep nanodeRF running which is why I bought spares when they ceased to be easily available. I have one unit in a location prone to loss of power. The nanode recovers without issue. I am concerned if I switch to a Pi power loss may cause issues.
I have located an archived Arduino V1.0 environment but using that on a separate PC raised other issues.
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.