emonTx v2 not passing data to nanodeRF

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! highfive

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 :slight_smile:)

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. :smile:

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

1 Like

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

1 Like

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.

1 Like

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…

1 Like

Arrrgggghhh. Full circle :laughing:

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.