Archived Forum

For what it's worth, I'm having HUGE problems with the (old) nanodeRF and Ethernet. It seems to be centred around DNS, though it can be accessing the controller or DHCP; but as I'm no networking expert I'm struggling.

I've modified getDHCPandDNS.ino (out of the EtherCard library examples) to allow the port to be re-initialised under software control, and here are some stats:

Requests: 509
Success:  463
Reinits: 20
Failed to init: 3

'Request' is an attempt to submit data. 'Failed to init' is any fault that meant it didn't get as far as getting an IP address to send the data to.  If it fails 3 times in a row to get a response from the emoncms.org server, it re-initialises ('Reinits') the port.

And enlarging the buffer from 700 to 1000 bytes

byte Ethernet::buffer[1000]; 

seems to have helped.

========================

As for your watchdog timeout, the maximum that the watchdog can be set for is 8 s. If you don't reset it within that period, it will time out and cause a restart. Unless there's reset missing somewhere, I'd suggest you need a longer timeout, but I don't know if it's possible to do that.

There's a list of the timeout constants here.

Many thanks for the reply.

I left it on logging the serial to file. About 5pm it started to work correctly. The reset was because I was not getting a response from the emoncms.org server. I did not not know that earlier as it is the first time I have used a nanodeRF. For the record and in case any one else has a similar problem the serial output is like this when all is well:-

Termite log, started at Sun Nov 11 11:06:40 2012
**********************************************************

[webClient]
DHCP status: 0
DHCP failed
Data sent: /api/post.json?apikey=24a5c91daceb457805e259b1ae6cbc46&json={rf_fail:1}
Time request sent
DHCP status: 1
IP:  192.168.1.13
GW:  192.168.1.1
DNS: 8.8.8.8
DNS status: 1
SRV: 213.138.101.177
Data sent: /api/post.json?apikey=24a5c91daceb457805e259b1ae6cbc46&node=18&csv=2100,3086
OK received
Data sent: /api/post.json?apikey=24a5c91daceb457805e259b1ae6cbc46&node=18&csv=2112,3086
OK received
Time request sent
Time: t11,08,44
Data sent: /api/post.json?apikey=24a5c91daceb457805e259b1ae6cbc46&node=20&csv=0,0
OK received
Data sent: /api/post.json?apikey=24a5c91daceb457805e259b1ae6cbc46&node=18&csv=2112,3086
OK received
Data sent: /api/post.json?apikey=24a5c91daceb457805e259b1ae6cbc46&node=20&csv=0,0
OK received

And so on.

I guess my problem may have been caused by the server.

Regards

Ian

I think either you're lucky, or I'm not! 

My analysis is:
The Ethernet functions can hang just about anywhere. Some of them have their own timeouts, that are much greater than the 8 s watchdog, hence the watchdog must be disabled to allow these to complete (or time out). DHCP depends on getting a reply from your router, in my case it either replies immediately or not at all. DNS depends on getting a reply from the DNS server, and that can take many seconds. Both these functions seem to have the own internal timeouts. But the function called to initialise the Ethernet, ether.begin( ), can hang indefinitely, therefore you need the watchdog enabled before that is called, and then disabled after to allow the DHCP and DNS functions ether.dhcpSetup( ) and dnsLookup( ) to return, and then enabled again to catch any hang-ups elsewhere.

The standard sketch indeed re-initialises if the server fails to respond after 10 tries. (This is done is a rather obscure way in line 219

if (ethernet_requests > 10) delay(10000); // Reset the nanode 
      if more than 10 request attempts have been tried without a reply

   with a delay of 10s, which causes the watchdog to fire that in turn resets the processor).

I'm hoping that the version that I'm working on will intelligently allow the Ethernet initialisation to complete and still be robust enough to allow unsupervised operation.

And having found out a bit more about the watchdog timer, 8 s is the maximum that it is possible to set.

Robert,  You've probably tried this, but have you tried changing the dns server ip address in the dhcp_dns script?

Thanks for the input.

Yes, with the NanodeRF_multinode.ino sketch, I've tried Google (8.8.8.8) and my ISP's. At present, I'm playing with the getDHCPandDNS.ino sketch from the EtherCard Library examples, using the EtherCard library default of (8.8.8.8). I'm collecting stats to see just where the problems seem to lie. I sense there's a memory allocation/buffer overflow/timing problem somewhere, but I could well be wrong.

Over a period of exactly 8 hours yesterday, attempting every 5 s to post 3 integer values of test data to emoncms.org, this is what I recorded:                  

(Since writing the 16:04 post above, I've established the DNS timeout is close to 50 s - there's a 30 s timeout I can see in the library, I've yet to understand where the additional 15 or more seconds comes from).