NanodeRF and the latest jeelabs libraries

I have been resurrecting an old NanodeRF board. I made the mistake of trying to flash the board with the latest (3 years old) NanodeRF firmware and Jeelibs libraries from GitHub before I had checked that I had still got the old sources. After I had fixed a few small compilation errrors (mostly cosmetic) everything looked OK. However it refused to work, failing the to get past the ether.begin() call. The Ethercard library was looping waiting for a CLKRDY status from the enc28j60 ethernet chip. The read of the status register was always returning 0. A scope on CS pin (9) of the ethernet chip showed that it was never being pulled down to activate the chip. The culprit turned out to be the call to ether.begin, it was.

if (ether.begin(sizeof Ethernet::buffer, mymac) == 0) { //for use with NanodeRF

It needed to be.

if (ether.begin(sizeof Ethernet::buffer, mymac, 8) == 0) { //for use with NanodeRF

Is it worth me raising a pull request for this on Github?

Does anything else use this code that requires the default CS line (10) to be used?

As far as I know the NanodeRF always has the RFM12 wired to the default SPI SS pin (PB2(SS/OC1B) aka DIG10).


I can’t comment on the desirability of requesting a change, but I can offer you a March 2013 JeeLib and an Ethernet from August 2012. Those are the earliest I have, I don’t necessarily have every version since, but I do have a few.

Hi Robert,

I tried the 2012 Ethercard from
GitHub - openenergymonitor/EtherCardOct2012: October 2012 Snapshot of Ethercard library which works with OpenEnergyMonitor MultiNode emoncms posting NanodeRF sketch but that gave a mass
of compilation errors. It probably needed the companion jeelib as you suggest.

The small mod to the call to ether.begin seems to fix the problem. I think
there was only one actual compilation error with the new version, the rest
were all warnings.

The default for chip select is 8 in the 2012 library and 10 in the current
one. From memory when I last worked on the Nanode sketches back in 2012 for
my COSM version there were still stability problems that caused the Nanode
to lock up every now and then. I was hoping that the latest version would
have addressed them. But it took me ages to work that the default had
changed :-(.