Hello,
I’m currently playing a little bit around with the iC880A conecntrator and a Raspberry Pi B+ which I bought as a se by IMST.
Since I already have some devices and another gateway I wanted to try the util_pkt_logger which works fine for frames send by the end-device (which is an arduino with an RFM9x connected), but it seems like I don’t get downstream messages or Join Accept messages from the gateway to the end-device.
Does anyone know, why this happens? Is there something which needs to be configured to get this done?
Kind regards
Seems like:
lgw_reg_w(LGW_MODEM_INVERT_IQ,0);
lgw_reg_w(LGW_ONLY_CRC_EN,0);
helps (like writen in https://github.com/Lora-net/lora_gateway/issues/29 )… but then I only have the messages from the Gateway. Is there no way to get both?
Seems like using lgw_reg_w is possible on runtime. Therefore I could proceed with starting having both values set to 1 in order to get the Join Request from the device, and if this request is received switch to lgw_reg_w values set to zero to get the Join Accept.
Hello @lora_rub,
I also have these kind of gateway. Do you have Problems when you want to reconnecd it to the TTN-Webside? The statuts is always not conneced.
1 Like
The IQ inversion setting is not the only possibly key difference between uplink and downlink transmissions. Depending on what regional bandplan you are operating in, it may not really be possible to use one gateway to snoop on another in the general case - it seems like it might work in EU868, but it will not work in US915 where downlink transmissions use a different set of a frequencies and more critically, use a 500 KHz bandwidth rather than the 125 KHz used by most uplinks.
Gateways built around the SX1301/SX1308 chip have a receiver architecture which can monitor 8 125 KHz channel frequencies, but only one 500 KHz one.
So in a bandplan with 8x 500 KHz downlink channels, you would need to not only need to modify the gateway configuration to listen on the downlink channels, you would actually need an SX1301 concentrator card for each monitored 500 KHz channel.
Generally speaking, software monitoring of the target gateway, either on the gateway itself or on the server controlling it is preferable to over-the-air monitoring.
There is one possible strategy, in that if you see an uplink you could write software to make the radio jump to the frequency and settings where any resulting downlink would appear. And you don’t even need a gateway class radio to catch the downlink, since the spreading factor can also be deterministically predicated - downlinks are after all intended to be received by a node’s node class radio. But for this to work, you do need to have a situation where your monitoring rig can “hear” both the node’s uplink and the target gateway’s downlink.
1 Like
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.