Have you set the reset pin? From the instructions:
- Enter “GW_RESET_PIN” (no quotes) and value 11.
Looks like that one was good 
1 Like
Just an update here: I installed the poly packet forwarder using these instructions: https://github.com/ttn-zh/ic880a-gateway/tree/spi
It works perfectly once I restart the RAK831 manually. So I think there might be a bug in the resin build?
Edit: Also, with the resin image, the RAK831 never even got warm, so it was clearly not switching on. But I did observe the LEDs changing as the device was reset. I also left the system to run overnight and it did not do anything, but the ic880a-gateway system worked first try.
This one does not use the same software stack…
It is strange. A bug is always possible, but this resin setup is already running on quite a lot of gateways without trouble.
I tried a complete run through from scratch again this morning with the resin instructions, but still same result. Has anyone tested the resin build with AS923?
Aha! AU915 works fine with the resin setup, but AS923 is broken.
Ok, it’s definitely due to setting the frequency plan to AS923. If I set it to AU915 in the console and reboot the gateway, it comes up fine. Switching to AS923 gives the same error as above, and then switching back to AU915 it works again. I was running AS923 with the poly forwarder and it seemed to start fine?
@kersing are you the maintainer of this? Do you know if it has it been tested with AS923?
Frequency plan if automatically fetched from TTN.
E.g. for EU plan, it gets https://account.thethingsnetwork.org/api/v2/frequency-plans/EU_863_870
and for AS: https://account.thethingsnetwork.org/api/v2/frequency-plans/AS_923_925
This URL is provided by TTN, as well as the data.
It would be interesting to see which configuration you get with the Zurich setup and how it is different from this one…
When I look at the plans, the AS has a lbt_cfg field that e.g. EU or AU don’t have. I don’t know if it has an impact or not though…
Poly from zh repo does not support LBT (listen before talk) MP does. That may cause the forwarder not to be able initialize the radio.
With the zurich setup I used this config manually: https://github.com/TheThingsNetwork/gateway-conf/blob/master/AS2-global_conf.json
Is there some way to confirm that listen-before-talk is what is breaking MP?
You can try the following in the resin setup:
in run.py line 191 add:
if 'lbt_cfg' in sx1301_conf:
print "Removing LBT configuration"
del sx1301_conf['lbt_cfg']
and see if it works…
Hi Amedee,
Yes, that does fix it. But is LBT required for LoRaWAN compliance?
Ok I take that back. The logs look fine, but it doesn’t show up as “connected” on the ttn platform?
17.09.18 20:14:31 (+1000) main ##### 2018-09-17 10:14:31 GMT #####
17.09.18 20:14:31 (+1000) main ### [UPSTREAM] ###
17.09.18 20:14:31 (+1000) main # RF packets received by concentrator: 0
17.09.18 20:14:31 (+1000) main # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
17.09.18 20:14:31 (+1000) main # RF packets forwarded: 0 (0 bytes)
17.09.18 20:14:31 (+1000) main # PUSH_DATA datagrams sent: 0 (0 bytes)
17.09.18 20:14:31 (+1000) main # PUSH_DATA acknowledged: 0.00%
17.09.18 20:14:31 (+1000) main ### [DOWNSTREAM] ###
17.09.18 20:14:31 (+1000) main # PULL_DATA sent: 0 (0.00% acknowledged)
17.09.18 20:14:31 (+1000) main # PULL_RESP(onse) datagrams received: 0 (0 bytes)
17.09.18 20:14:31 (+1000) main # RF packets sent to concentrator: 0 (0 bytes)
17.09.18 20:14:31 (+1000) main # TX errors: 0
17.09.18 20:14:31 (+1000) main ### BEACON IS DISABLED!
17.09.18 20:14:31 (+1000) main ### [JIT] ###
17.09.18 20:14:31 (+1000) main # INFO: JIT queue contains 0 packets.
17.09.18 20:14:31 (+1000) main # INFO: JIT queue contains 0 beacons.
17.09.18 20:14:31 (+1000) main ### GPS IS DISABLED!
17.09.18 20:14:31 (+1000) main ### [PERFORMANCE] ###
17.09.18 20:14:31 (+1000) main # Upstream radio packet quality: 0.00%.
17.09.18 20:14:31 (+1000) main ### [ CONNECTIONS ] ###
17.09.18 20:14:31 (+1000) main # bridge.asia-se.thethings.network: Connected
17.09.18 20:14:31 (+1000) main # Semtech status report send.
17.09.18 20:14:31 (+1000) main ##### END #####
17.09.18 20:14:31 (+1000) main 10:14:31 INFO: [TTN] bridge.asia-se.thethings.network RTT 176
17.09.18 20:14:31 (+1000) main 10:14:31 INFO: [TTN] send status success for bridge.asia-se.thethings.network
17.09.18 20:15:01 (+1000) main
17.09.18 20:15:01 (+1000) main ##### 2018-09-17 10:15:01 GMT #####
17.09.18 20:15:01 (+1000) main ### [UPSTREAM] ###
17.09.18 20:15:01 (+1000) main # RF packets received by concentrator: 1
17.09.18 20:15:01 (+1000) main # CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
17.09.18 20:15:01 (+1000) main # RF packets forwarded: 0 (0 bytes)
17.09.18 20:15:01 (+1000) main # PUSH_DATA datagrams sent: 0 (0 bytes)
17.09.18 20:15:01 (+1000) main # PUSH_DATA acknowledged: 0.00%
17.09.18 20:15:01 (+1000) main ### [DOWNSTREAM] ###
17.09.18 20:15:01 (+1000) main # PULL_DATA sent: 0 (0.00% acknowledged)
17.09.18 20:15:01 (+1000) main # PULL_RESP(onse) datagrams received: 0 (0 bytes)
17.09.18 20:15:01 (+1000) main # RF packets sent to concentrator: 0 (0 bytes)
17.09.18 20:15:01 (+1000) main # TX errors: 0
17.09.18 20:15:01 (+1000) main ### BEACON IS DISABLED!
17.09.18 20:15:01 (+1000) main ### [JIT] ###
17.09.18 20:15:01 (+1000) main # INFO: JIT queue contains 0 packets.
17.09.18 20:15:01 (+1000) main # INFO: JIT queue contains 0 beacons.
17.09.18 20:15:01 (+1000) main ### GPS IS DISABLED!
17.09.18 20:15:01 (+1000) main ### [PERFORMANCE] ###
17.09.18 20:15:01 (+1000) main # Upstream radio packet quality: 0.00%.
17.09.18 20:15:01 (+1000) main ### [ CONNECTIONS ] ###
17.09.18 20:15:01 (+1000) main # bridge.asia-se.thethings.network: Connected
17.09.18 20:15:01 (+1000) main # Semtech status report send.
17.09.18 20:15:01 (+1000) main ##### END #####
17.09.18 20:15:01 (+1000) main 10:15:01 INFO: [TTN] bridge.asia-se.thethings.network RTT 185
17.09.18 20:15:01 (+1000) main 10:15:01 INFO: [TTN] send status success for bridge.asia-se.thethings.network
17.09.18 20:15:31 (+1000) main 10:15:31 INFO: Disabling GPS mode for concentrator’s counter…
17.09.18 20:15:31 (+1000) main 10:15:31 INFO: host/sx1301 time offset=(1537179208s:679266µs) - drift=-235µs
17.09.18 20:15:31 (+1000) main 10:15:31 INFO: Enabling GPS mode for concentrator’s counter.
17.09.18 20:15:31 (+1000) main
17.09.18 20:15:31 (+1000) main
17.09.18 20:15:31 (+1000) main ##### 2018-09-17 10:15:31 GMT #####
17.09.18 20:15:31 (+1000) main ### [UPSTREAM] ###
17.09.18 20:15:31 (+1000) main # RF packets received by concentrator: 0
17.09.18 20:15:31 (+1000) main # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
17.09.18 20:15:31 (+1000) main # RF packets forwarded: 0 (0 bytes)
17.09.18 20:15:31 (+1000) main # PUSH_DATA datagrams sent: 0 (0 bytes)
17.09.18 20:15:31 (+1000) main # PUSH_DATA acknowledged: 0.00%
17.09.18 20:15:31 (+1000) main ### [DOWNSTREAM] ###
17.09.18 20:15:31 (+1000) main # PULL_DATA sent: 0 (0.00% acknowledged)
17.09.18 20:15:31 (+1000) main # PULL_RESP(onse) datagrams received: 0 (0 bytes)
17.09.18 20:15:31 (+1000) main # RF packets sent to concentrator: 0 (0 bytes)
17.09.18 20:15:31 (+1000) main # TX errors: 0
17.09.18 20:15:31 (+1000) main ### BEACON IS DISABLED!
17.09.18 20:15:31 (+1000) main ### [JIT] ###
17.09.18 20:15:31 (+1000) main # INFO: JIT queue contains 0 packets.
17.09.18 20:15:31 (+1000) main # INFO: JIT queue contains 0 beacons.
17.09.18 20:15:31 (+1000) main ### GPS IS DISABLED!
17.09.18 20:15:31 (+1000) main ### [PERFORMANCE] ###
17.09.18 20:15:31 (+1000) main # Upstream radio packet quality: 0.00%.
17.09.18 20:15:31 (+1000) main ### [ CONNECTIONS ] ###
17.09.18 20:15:31 (+1000) main # bridge.asia-se.thethings.network: Connected
17.09.18 20:15:31 (+1000) main # Semtech status report send.
17.09.18 20:15:31 (+1000) main ##### END #####
17.09.18 20:15:31 (+1000) main 10:15:31 INFO: [TTN] bridge.asia-se.thethings.network RTT 181
17.09.18 20:15:31 (+1000) main 10:15:31 INFO: [TTN] send status success for bridge.asia-se.thethings.network
I cannot answer that – If you would use the Zurich setup it wouldn’t do LBT
Now, it would be good to understand why the concentrator doesn’t start with LBT – it is either a problem with the config file or with the mp forwarder.
This is more a question for @kersing 
It might be a transient problem of the bridge, the log looks good. I think it will appear sometime.
Does it forwards packets?
You are missing one component in the list, the concentrator and more specifically the fpga firmware level.
MP works on different hardware with lbt enabled so I don’t think it will be an issue with the software. However being in EU868 I am unable to check. (I am not about to start running lorawan hardware configured for frequencies used by mobile operators over here)
1 Like
Couldn’t you just enable LBT for EU868? Or terminate the antenna with a 50ohm load?
Depending on the hardware LBT is not supported below 915MHz. As far as I know I don’t have hardware that does support below 915MHz.
You do not seriously expect me to spend money on gateway hardware I can’t legally use over here, do you? This is a hobby that is consuming too much money and takes too much of my free time as it is… (Ask me again when I’m making money out of my work on MP forwarder, however, don’t expect it to happen soon)
2 Likes
Sorry, it wasn’t clear to me that you were just a hobbyist also. I’m not asking you to spend any money, and I apologise if it came across that way, it was not my intention. I just assumed that given you are a moderator and the person who writes this software (which is for RF packet infrastructure), you would probably have a 50 ohm terminator lying around. As far as I know, the 868 and 923 hardware is the same (at least according to the SX1301 datasheet). I was only trying to help fix what is clearly a bug somewhere (if not in mp) to benefit everyone.
I’d also be more than happy to setup my rpi device with your resin image, so that you could debug it if you wish.
I knew you would shed some light on this
I think it is as simple as that – from the RAK831 thread it seems that this concentrator does not support LBT: The hard RAK831 cafe part 1 - #213 by youngjune0594
@jeremyherbert, if you want to pursue this, you will have to talk to RAK…
2 Likes
Thank you @Amedee! Even though the issue isn’t solved, at least I know where my problem is.
It also appears that LBT is not required in AS923, according to the “LoRaWAN 1.1 Regional Parameters” document. So I will just run it without for now.