Ethernet gateway troubleshooting advice

  • Hi guys,

    I've had a Vera for about a year but I'm new to the Arduino/MySensors platform. I've spent a-couple of days researching and troubleshooting my ethernet gateway but unfortunately it's still not working for me so I'm hoping you guys might be able to give me a helping hand. I'm using the Arduino Nano, the NRF24L01 board, and the W5100 ethernet adapter. Here's what I've done:

    Using the ethernet gateway instructions here:

    I began to hook everything up. The first thing I noticed was my W5100 adapter's VCC pin is labeled +5V, however the instructions say to power the ethernet adapter with 3.3v. Also, the pins on my W5100 adapter are labeled slightly differently. So I used my best judgement and wired it up as follows:


    I also added a 4.7uf capacitor between 3V3 and GND. I plugged in the Nano, changed the IP address in the ethernet gateway sketch to match my network, and uploaded the sketch.

    Unfortunately it looked like something wasn't right. I couldn't ping the gateway. The PWR led on the W5100 lit up and the FDX led was flashing, nothing else was lit up. I also noticed I was getting "0;0;3;0;9;check wires" in the serial console. I checked the voltage between the capacitor pins and I was only getting 3.0V so I figured the W5100 wasn't getting enough power. Since the W5100 board was labeled +5V I hooked it up to the +5V pin on the Nano and immediately most of the lights lit up and I was getting some flashing on the RX pin so it looked like at this point it was almost working. Checked the voltage between the capacitor and I was now getting 3.3V so it appears the W5100 is too power hungry to be powered off the 3V3 pin. Still couldn't ping it though, and I was still getting the "0;0;3;0;9;check wires" message in the console.

    I decided to try and tackle the NRF24L01 issue and come back to the W5100 later. According to what I've read, the "check wires" message is related to the NRF24L01 so I triple checked my wires and even tried a different NRF24L01 but unfortunately it still was not working for me.

    So this is where I'm at now. The ethernet module looks like it's working but I cannot ping it. The ip address is a valid unused address on my network so that shouldn't be the issue. I read that adjusting the value of RF24_PA_LEVEL in MyConfig.h might help so I set this to RF24_PA_MIN but I'm still getting the "0;0;3;0;9;check wires" message.

    My current wiring is as follows:


    I'm curious if maybe I've mis-interpreted a connection somewhere, especially since the W5100 labels are different than what's in the documentation. Any help or guidance would be greatly appreciated. I'm really excited to see this work. πŸ™‚


  • Admin

    I've also struggled getting W5100 module to work together with the RF24 module. There seems to be different variants out there and on a some of them the ethernet is hogging the SPI.

    Have had a long discussion with @Anticimex about the issue and the creator of the RF24 fork we're using. A couple of days ago @TMRh20 created a patch able to use SoftSPI. So basically you hook up the radio to other pins than the hardware SPI used by the Ethernet module.

    Please read our discussion here:


    I've been having similar problems when attaching a touch display to my AtMega2650 which have been occupying my night shift the last few days. Please let me know how SoftSPI is working out for you.

    I'll have to make more tests myself when I get the current work out of my hands.

    henrikekblad created this issue in TMRh20/RF24

    closed SoftSPI #24

  • Contest Winner

    I have also noticed that the W5100 module seem to trash the SPI bus for other devices.
    I have started to break down my design totally, and I'm "rebooting" from a serial GW.
    Status currently is that I have gotten my serial GW to be able to receive RF data using software SPI but it does not seem to be able to ACK the messages properly. I suspect it is a bug in the RF24 work TMRh20 has made recently, but I am not sure.
    "Offline" discussion with @hek seem to suggest that the ACK problem is not at all related to what SPI solution is used, but more the RF24 code in general.

  • Just a quick update, I disconnected the NRF24L01 from the Nano so I only have the W5100 ethernet module connected. I downloaded a sample HTTP client sketch and uploaded it to the Nano. This works perfectly, I can ping the Nano and hit the HTTP server so this at least proves my W5100 module works fine and I have it connected correctly.


    I disconnected the W5100 module, re-connected the NRF24L01, and re-uploaded the gateway sketch. I then started getting a "0;0;3;0;14;Gateway startup complete" message in the console. So it appears having the W5100 ethernet module connected is not allowing enough power to initialize the NRF24L01, at least on my particular Nano. Supposedly this combination works for others, even without the capacitor. Anyway, I've read that using a larger capacitor (47uf - 100uf) can help so that's my next step...

  • Contest Winner

    Yes that works for me as well. But it is not a power issue. I have wired independent power supplies for both RF and W5100 and I still cannot get them to coexist on the same SPI bus.
    Others on the web have also confirmed that W5100 is a SPI bus hog, so if you use it, it has to be the sole SPI user on that particular SPI bus (the HW SPI bus if using the ethernet library from the Arduino IDE).
    This is due to the fact that the W5100 always drivers MISO as described in this document under "Multiple SPI Slave Usage".
    Unfortunately, I have not been able to solve this using the recommendation (de-asserting/asserting SCS). I am not sure if it is due to how the W5100 module is wired (I have not found a schematic to confirm the SPI_EN signal actually goes to SCS and I do not fully trust my eyesight). Or if it is I who made a mistake in my SW patch, but even if I just use the serial GW sketch and drive SPI_EN low, the W5100 kills the RF module by just being on the bus and powered. I confirmed the state of SPI_EN with a logic analyzer as well. But perhaps you could give that a shot as well just so that we can rule out that option as a SW workaround to the problem.

  • Hmm, well that's somewhat discouraging. Surely someone has a combination of the two that work together or there wouldn't be instructions on building an Ethernet Gateway using a W5100 on the MySensors site right? πŸ˜‰ Or I would hope not anyway.

    Are you using a genuine Arduino board or a clone? Maybe we should take a poll to see who has working configurations and exactly what they're using and where they got their components from. Just a thought...

  • Contest Winner

    I'm on a clone. I have not heard of anybody that have managed to run the W5100 module with RF reliably actually. And googling W5100 and SPI is...discouraging as well...there are all sorts of HW patches and workarounds circling. But I agree, we should try to boil down to the gritty details on this matter. My current status is that I can get the "Gateway startup complete." message with my W5100 and RF module connected (using soft SPI) but then the W5100 does not respond to ping. But running a webserver sketch on the same HW wireing works just fine, so is is a MySensor/Sketch issue, possibly relating to W5100 lib vs RF lib.
    Also, running a serial gateway sketch on the same HW works (with issues on ACKs but that is believed to be caused by yet-to-be-identified changes in the RF lib).
    I need to stabilize my hw a bit more, and then I will try to use my logic analyzer and try to get a grip on this.

  • Gotcha.. Thanks Anticimex, keep us posted on what you find out with the logic analyzer, that will be very interesting for sure.

  • Contest Winner

    Sure. I will try to get some time to look into it tomorrow evening. What I really would like though is a debugger. But I guess prints have to do.

  • @Anticimex said:

    I'm on a clone. I have not heard of anybody that have managed to run the W5100 module with RF reliably actually.

    Am using a Jaycar EtherTen ( with RF fine. Its based on the ATmega328P.

    Couldnt get a mega working with the ethernet shield, couldnt get the mega working with ethernet module, nor a mini or micro clone.

    Am wondering if there's more to it than the context of SPI hogger but will happily take any fix. I'd rather be using the mega as the extra memory will allow me to evolve my gateway somewhat.

  • Contest Winner

    Alright, my findings so far:
    I have had some success in getting my ethernet GW to work. I had to make some minor changes to the sketch.
    Most importantly, I had to bring in the SOFTSPI support in the RF24 lib (how to do this is described here.
    I also had to disable the debug feature (in MyConfig.h).
    And I had to move gw.begin in setup() to be done after the delay(1000).
    Now I have a ethernet GW executing which is self-powered from my Vera (using USB) and running with a PA enhanced RF module on maximum PA level.

    I will now move on to picking up where I originally left off; checking if it is possible to manipulate SPI_EN signal in the sketch to allow RF module to share bus with W5100 which would be ideal. It should be easier to confirm this now, when I have a known good setup.

  • Hero Member


    There would seem to be a number of solutions to the issue of the W5100 not releasing the MISO line when the slave is deselected and thus being incompatible with other SPI devices.

    1. Use SoftSPI for one (or more) of the devices
    2. Use the USART SPI master mode for one device
    3. Use a host with more than 1 SPI interface
    4. Modify a shield or module to allow SPI_EN to be controlled by another uC pin & change libs to use it
    5. Use a shield or module designed to drive SPI_EN as the inverse of NSS (slave select)
    6. Modify a shield or module to do so

    The SoftSPI (for nRF) seems to work for some people. For the low-bandwidth usage of MySensors that may be adequate.

    The Wiz811 and Wiz812 modules appear to be in category 5, as are a few shields. The Wiz810 breaks out SPI_EN so it could be controlled by another uC pin.

    I haven't seen nRF or W5100 libs modified to use the USART in SPI mode but it should be possible (one would need to NOT use the hardware serial port for debugging or program loading while using it for SPI of course).

    I do not know if the W5200 or W5500 chips have the same problem.

    Note: since the W5100 does not tristate the MISO line when deselected but SPI_EN is still high, that means it's output will be fighting with whatever other slave is trying to drive MISO. Sometimes the other device may win, sufficiently. Thus the possibility of using both W5100 and nRF without any of the compensations -sometimes working for some people. Not good practice and not reliable!

  • Contest Winner

    I am going for option 4. I tried it once and failed, but I have since made a small change to the sketch which allowed me to use the W5100 using softSPI (changing order of some calls during setup()).
    Once I have confirmed if this will be possible without totally tearing up the libs I'll post it here.
    Someone else is of course welcome to investigate alternative options but my options are limited. I really would like to make it work with what I have, which rules out option 3 and 5-6. I prefer option 1 before option 2 as 1 is more flexible.

    Option 4 actually needs little to no hw modification. The MySensors building description does not mention it but W5100 does have SPI_EN on a pin, and this pin should also be connected to the host (I have connected it to D4).
    So with that small adjustment to the build instructions, and some appropriate changes to the sketch and possible the libraries, <should> get the ethernet GW back on track.

  • Admin

    @Zeph said:

    I haven't seen nRF or W5100 libs modified to use the USART in SPI mode

    @TMRh20Projects actually also incorporated the option to use USART as SPI in the latest commit (see defines in RF24_config). But you'll lose the debug-print possibility when using this option.

  • Contest Winner

    My "option 4" attempt is progressing well.
    True-to-the-topic a good troubleshooting advice is to lower the speed of the SPI bus. When working on a breadboard, and having multiple devices on the SPI bus, the capacitive load starts to affect the clock and data lines.




    lowers the clock speed and provides a more reliable signalling (confirmed with logic analyzer).
    I do not think the change is needed on "sharp" boards, but it seem indeed to help when having a bread-board that resembles something from greek mythology πŸ™‚

  • Contest Winner

    My fix for W5100 is now available on the development branch.

  • Hero Member


    I do not know if the W5200 or W5500 chips have the same problem.

    Checked the W5500 datasheet and read:

    TCHZ - SCSn High to Output Hi-Z - 2.1 ns

    So it looks like the W5500 does not have this problem.

    since the W5100 does not tristate the MISO line when deselected but SPI_EN is still high

    If this is true then even using SPI_EN instead or in combination with /SCS does not really enable using another SPI slave in combination with the W5100 ...

  • Contest Winner

    @daulagari said:

    So it looks like the W5500 does not have this problem.

    since the W5100 does not tristate the MISO line when deselected but SPI_EN is still high

    If this is true then even using SPI_EN instead or in combination with /SCS does not really enable using another SPI slave in combination with the W5100 ...

    Yes it does, since driving SPI_EN low makes W5100 release MISO.
    SPI_EN is not a signal to be used "instead of" SCS. It is a completly independent signal that enables or disables the use of the SPI bus on the W5100. SCS is used "in" the SPI bus for selecting W5100 as sender/receiver.

    So a solution to the problem is to make sure SPI_EN is driven low, every time another SPI slave is being used.

  • Hero Member

    Some designs fix this issue for the W5100 by driving SPI_EN from SCS via an inverter - I've seen circuits with a nand gate and with a FET and resistor. I believe the WizNet folks suggested that option. It could also be handled with a modified library by driving SPI_EN from another uC pin and disabling SPI_EN (low) whenever driving SCS high.(say if you were using a WIZ810 which has both W5100 pins exposed). Most shield tie SPI_EN to Vcc tho, so you'd have to cut a trace to fix them.

  • Anticimex, thanks, your fix works. I am using uno R3 with Wiznet5100 shield. I am able to control relays and receive sensors data. I can also ping ethernet gateway.
    There seems to be just a minor glitch. though. When I connect uno via usb cable to computer to monitor serial messages I never get "0;0;4;11;Arduino startup complete" message.

    Has this been removed? It doesn't seem to affect functionality anyway.





Looks like your connection to MySensors Forum was lost, please wait while we try to reconnect.