Ethernet Gateway problem

[RJ_Make]

@meanpenugin
Yep, I thought he was using the chip. :-)

[RJ_Make]

@Dan-S.
What size cap? In testing I found I needed a pretty big cap (47uF) to get mine working with MySensor version 1.4.

[Dan S.]

Thought about this some more. I supplied power to both the radio and the Uno from the same wall wart 5v power source. But when the Uno is supplied 5v from its USB connector, the power from that connection is not regulated by the UNO. Since the radio has significant fluctuations in power output (and demand) it may cause significant ripples in its power source line--the same one which sources the UNO. Because the UNO is not regulating this power, it may have caused problems with the UNO (not the radio). Perhaps I should have capped the UNO power source also or at least should have had 2 separate power supplies, one for the UNO and one for the radio. Thought I was being clever in using one. At any rate the gateway continues to run with no problems with the radio getting power directly from the UNO's 3.3V output pin. The UNO provides enough power from this pin to power the radio with no issues.

[gregl]

Thanks everyone esp. @Anticimex for your troubleshooting on this.
I didnt realise i had an issue with my 1.4 Ethernet GW ( using the iBoard hardware) as i wasn't using it in "production" and since it was just running from my PC's USB port it was restarted each time i woke my PC.

Anyway - to bring stability to the Iboard , i just added to the original sketch the line:

SPI.setClockDivider(SPI_CLOCK_DIV2); //to assist with gateway stability.

eg:

void setup()  
{ 
 SPI.setClockDivider(SPI_CLOCK_DIV2); //to assist with gateway stability.
  // Initialize gateway at maximum PA level, channel 70 and callback for write operations 
  gw.begin(RF24_PA_LEVEL_GW, RF24_CHANNEL, RF24_DATARATE, writeEthernet);
 
  Ethernet.begin(mac, myIp);

  // give the Ethernet interface a second to initialize
    delay(1000);
  
    // start listening for clients
    server.begin();
  }

Thanks again!

[Anticimex]

@gregl You're welcome :)
Actually, I read somewhere that SPI.setClockDivider(SPI_CLOCK_DIV2) is a default setting in the device, but maybe various AVRs differ.
In any case, I found that when breadboarding, it might actually be needed to lower it to DIV4 as well.
Eventually, SPI.setClockDivider(SPI_CLOCK_DIV2) will be executed when SPI is configured in the library, but possibly some SPI calls are made without this call since you notice a difference when adding the call yourself before calling any library function.

[Dan S.]

Still having an issue with my ethernet gateway (Uno plus shield). Works flawlessly for up to 24 hours, then shuts down. When working, responds without fail to every message from my test light sensor, but then fails to respond to any message. If I take the gateway offline, then restart everything it goes through the same process--working for some length of time, then shutting down. Have tried soft spi, separate power for the radio etc., and each time I think I have found the solution till it shuts down again. Any suggestions. Thinking that it is a hardware issue given that it operates fine for hours before stopping.

[Anticimex]

Hm. Perhaps dodgy USB circuitry? (for powering the Arduino that is) assuming you do that. Have you tried alternative power supply for the Arduino as well?

[Dan S.]

@Anticimex Think I tried more than one power supply, but just to be sure will try again. Also plan on trying another uno board to eliminate that.

[Johnny B Good]

Hey Dan,

Did you got it working ?
Ik had some REALY REALY strange problems here with my MQTT gateway, who hung for the most unexplainable reasons, sometimes it worked a few hours, sometimes a few minutes, sometimes it hung when I added a new node (????) ... so no node worked at all anymore after that ...

I tried a lot of things, I wasn't sure about the power too here so I used a different power circuit with a cheap LD33V for the NRF only, but that didn't help much either :-| (zucht)

I take the project from my hobby-room table to the places it suppose to work and back for some xXx times.
It works well on the table every time, but when installed I got the weirdest problems ... well ...
I'm not sure it's a solution for you too, I can't explain how it helped me, but It's now stable for a time now ...

What did I do ? I just disabled the DEBUG'ing in MyConfig.h O_o for trying out, and it's working for me so far...
Don't ask me how or what, cause I'm not that smart, it was just a desperate try :-D
Maybe the serial was fine when connected to the PC for debugging on the table and was NOT connected when I placed it back, maybe the serial buffer was somehow messed up ... I don't know, maybe the Arduino got just a little bit more memory when debugging is disabled ... really, I can't explain it.
Let's blame it on the ozon and sun flares ... :-D

If you want to know (it wasn't my problem here) how I powered my MQTT, just let me know and I make a Fritz diagram...
And maybe can a more geek then me explain this with this fresh look on the problem.

-= GreetingZzz and may the sensors be with you =-

[hek]

Enabling DEBUG increases program space. Could be just enough to tip things over.

[ntruchsess]

DEBUG also enables use of Serial which causes the 3.3V Voltage to drop a bit by causing power-consumption of the USB-chip (not relevant when using external power-regulator for the nRF24L01).

[Dan S.]

@Johnny-B-Good I'm pretty sure my problems are power supply/radio related as others have suggested. It doesn't seem to lose connection via the Ethernet with Vera. Its the radio connection to the sensor that eventually fails.
Am now testing with the UNO directly supplied by a 9v power supply which says that it is regulated. Was using 5Vusb input before. We'll see how it goes. I do have a cap on the radio, but if this fails new power supply fails I'll look at other alternatives to help the radio operation be more reliable.
I did have debug turned off when uploaded the Ethernet sketch.

[Dan S.]

Looking for some debug help here. Have tried different boards, separate power supply, soft spi, etc. Ethernet controller words for a period from a few hours to up to a day, but eventually stops communicating with test light sensor. The controller still communicates fine with Vera since I receive no error messages on reload or when include button is pressed. But when I serial monitor the sensor it says failed for every message it sends to the controller. The sensor shows an ok for every message up to the failure point and then ir shows fail for every message thereafter. If I unplug the gateway and plug it back in it starts to work--for a while.

[Anticimex]

Do you get anything using netcat?
Assuming you use linux:

   nc <ip of gateway> <port>

It essentially allows you to monitor what the GW sends on ehternet exactly like a serial line. That is, you can expect it to print a message there if you press the inclusion button.

[Dan S.]

@Anticimex Don't use linux but am certainly willing to learn. I do need some way to monitor what is happening with regard to the gateway. It looks like that is what you are proposing.

[Anticimex]

@Dan-S. You can use PuTTY if you like as well.
My proposal is that you establish if it is the GW that stops sending data on Ethernet or the controller that stops receiving it.
Example:
You run your GW until you think it has died (controller stops reacting to sensor input).
Then you connect using your monitor (PuTTY or NC). If you get anything there then you can determine if your GW receives sensordata or not. And you can also determine if GW is alive (if you have a inclusion button). When pressed, it should show in that monitor.

What workaround are you currently using for your ethernet module? SOFT SPI or SW patched management of SPI_EN?
SW patched management of SPI_EN works with this module but not this module.
If you use any variant of W5100 you need some workaround due to the W5100 hogging MISO. Supposedly there are shields that mitigates this flaw in HW (using inverter on CS signal to handle SPI_EN) but I have none of those so I cannot confirm which ones.

The SPI problem can potentially hide (luck and timing play a role here) for a while, and that could be what you experience.
Other factors I have noticed when I debugged my module was that DEBUG flag can have an effect (I am again guessing timing) so if you have that enabled, try disabeling it). Also, the HW SPI bus speed could be too high (if you have "dirty" wires) and that can be worh a try to lower as well (see here).

[hek]

@Anticimex said:

What workaround are you currently using for your ethernet module? SOFT SPI or SW patched management of SPI_EN?
SW patched management of SPI_EN works with this module but not this module.

@Anticimex

What do you say about just have one ethernet sketch always running SOFTSPI for radio. This should be working on all variants of W5100 ethernet moduls/shields?

[Anticimex]

@hek I think it should be a sufficient solution. Personally I am going to stick with my own patch though because I am going to need every byte program memory available. But generally speaking SOFT_SPI should satisfy most ethernet gw users.

[Hausner]

Dan S.
Not to hijack your tread, but I've had similar problems. First the "check wires" thing, next dropping out at random times.

I started with this R3 and this shield which is a ENC28J60, but couldn't get it to work properly.

Then I bought this shield , plugged it in, and uploaded the Ethernet GW without mods, except IP of cause, and it has worked ever since.

[Dan S.]

@Hausner My board looks like the one you got to work. I am back up and running with soft spi and separate power supply for the radio. Will see how long it works. Had stopped running soft spi since it seemed to work without it, but Anticlimax says the SPI problem can hide, so I put the soft spi back in. Wish mine was plug and play like yours. I have a genuine Arduino UNO and W5100 shield, but the knockoff version of each that I have acted the same way. Anticlimax: I do believe its a radio problem since I get the OK at the end of the sensor message line on the serial monitor even if the gateway is not connected to the controller but when it stops it says fail at the end of the sensor line, which to me means either the gateway radio is not receiving and/or sending when it fails.