A while back I set up a gateway using a Raspberry Pi 2, an ic880a and a USB WiFi dongle. The gateway was working and packets from my node were being received and shown on the console.
However, I then deleted the gateway and registered it again with another account in order to teach members of a computing club how to do it. However, I can no longer get it to work again. I have reflashed the OS and set it up again, but it still shows ‘not connected’ in the console and doesn’t forward any traffic.
If I run the command sudo tcpdump | grep 'network' I can see that it is sending data to router.eu.thethings.network and bridge.eu.thethings.network regularly, so I don’t think it’s an issue with the gateway itself.
It uses a legacy packet forwarder, so its ID is ‘eui-b827…’ I realise now that when you delete a gateway you cannot re-use its ID. Does that mean that it cannot register again on TTN?
Sorry for my confusion, I’m still new to the Things Network.
Thank you.
EDIT:
When i use sudo journalctl --unit=ttn-gateway to check the logs I see many lines marked ‘INFO’ before these lines:
ERROR: Version of calibration software not expected, actual:0 expected:2
ERROR: [main] failed to start the concentrator
ttn-gateway.service: Main process exited, code=exited, status=1/FAILURE
ttn-gateway.service: Unit entered failed state.
ttn-gateway.service: Failed with result ‘exit-code’.
ttn-gateway.service: Service hold-off time over, scheduling restart.
This suggests that there is something wrong with the gateway after all. Instead of running continuously as I thought it was, it is starting, sending the packets I saw in tcpdump, failing, scheduling another start later on and stopping over and over again.
I had also same problem. But I sorted this problem out after reset sx1301.
So I think you have better to check your Raspberry Pi reset pin what it is work well.
I’m pretty sure that the pin connections are correct because I’m using a backplane. However, I have been getting under-voltage warnings so I’ll try a better power supply. Once I find one, do I just need to run the installation script again or do I need to reflash the OS and start anew?
Also make sure you are correctly controlling the reset, ie that software is driving the GPIO it is actually connected to.
Once I find one, do I just need to run the installation script again or do I need to reflash the OS and start anew?
It’s unclear you’d need to do anything software wise once the hardware is working again.
If there is a gateway ID issue, that is not really locked into the hardware, it may come from the PI’s MAC address but there are other options for getting one and putting it in the packet forwarder config files.
I’ve tried setting it all up again with a better power supply but I’m still having the same problem and exactly the same problem is appearing in the logs, with actual:0 expected:2.
How can I check if the reset it being correctly controlled?
Check that a wire is connected to the appropriate concentrator pin and identify the pi GPIO that it is connected to. Make sure this is the value used by the reset script.
Put a scope probe or even a multimeter on that signal while running the reset script / starting the packet forwarder and see that it goes high and then back low again.
There are also a variety of basic spi tests in a typical build of gateway software which you can run instead of packet forwarder to conduct lower level tests, for example
I’ve looked at the ic880a reset pin with a multimeter like you said. It’s normally at 3.15v, but periodically it goes down to 1.6v for a moment. I assume that it goes down to 0v but my multimeter just doesn’t have a fast enough refresh rate to see it.
I’ve also tried to use the same Raspberry Pi and backplane with a different ic880a and set it up again. I get exactly the same problem, so I think it’s a faulty connection somewhere on the backplane. I’ll try to test it with the multimeter when I get time.
Find the resets script and increase the “sleep” and you should have plenty of time to see the state change. I would have though the typical 1 second was enough.
Also run the SPI tests in the lora hal directory rather than the packet forwarder.
It’s vaguely possible an insufficient power supply might start to show up at the point where the concentrator starts running and more or less doubles the system power consumption, as it consumes about as much as a pi does.
There seemed to be a solder bridge on the backplane between the Raspberry Pi pin GPIO25 (which is connected to the ic880a’s RST pin) and pin GPIO8. I cleaned it up and the gateway showed ‘connected’ on the console but was forwarding no packets. I rebooted it and I was back where I has begun, with the actual:0 expected:2 message in the logs. The gateway did not connect again.
I disabled the packet forwarder and ran the util_spi_stress script. It says this: INFO: Starting LoRa concentrator SPI stress-test number 1 Cycle 0 > error during 1th iteration: write 0x67, read 0x00 Repeat read of target register: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 x000 0x00 0x00 0x00 0x00 0x00 0x00 0x00
I connected the Raspberry Pi and ic880a with jumper cables instead of the backplane and sure enough it started working perfectly. It was a connection issue all along like you said. I assume the backplane has been damaged somehow, so I’ll find another way to connect them.