LoRaWAN downlink data not received

[bmarkus]

Added event callback. TX_PACKET_EVENT received but no any RX_PACKET_EVENT generated.

[jmarcelino]

@bmarkus

RX_PACKET_EVENT works on TTN

def rxcb(arg):
   print("RX callback received\n")

lora.callback(LoRa.RX_PACKET_EVENT, rxcb)
>>> s.send(bytes([42,42])) #nothing queued on TTN
2
>>> s.send(bytes([42,42])) # now queued a downlink
2
>>> RX callback received

If it's not working for you then there's clearly some difference between TTN and those servers you're using, but without full details - including entire protocol sequence of events - I can't help further.

I have a private server running LoRa Server https://www.loraserver.io - actually a great free server that has been making huge progress, we might even drop our private TTN server for it. I will try it against that later today or tomorrow.

[bmarkus]

@jmarcelino

Don't worry. I trust in both Kerlink SPN and the LORIOT server, they are working fine with all other devices I have around. Also I can see detailed logs and GW traffic to know what is happening. There can be an issue with my test code but it looks ok. What is remaining is a bug in the LoPy fw as the radio itself works fine in raw LoRa mode.

It would be interesting to downgrade LoPy to an older fw and retest. I upgraded from 1.5....... so it must be possible boot to this old release.

[jmarcelino]

@bmarkus
What FPort are you setting in your donwnlinks?

The LoPy seems to ignore anything other than FPort 1 and 2 for downlinks, if you use something else no data is returned and RX_PACKET_EVENT is not triggered.

s.bind() makes no difference, it only sets the uplink port.

[jmarcelino]

I have confirmed through the source code, the LoPy only accepts downlinks to port 1 and 2. Anything else is discarded.

Github issue: https://github.com/pycom/pycom-micropython-sigfox/issues/46

Thanks for raising this @bmarkus it certainly will help many others - but it would have a bit quicker to pinpoint if you described the issue in more detail ;-) especially the use of a non-default port.

[bmarkus]

@jmarcelino said in LoRaWAN downlink data not received:

I have confirmed through the source code, the LoPy only accepts downlinks to port 1 and 2. Anything else is discarded.

NOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

In fact it works on port 1 and 2, data received and callback event is generated. Why other ports are dropped? Do developers know LoRaWAN specification? How quality assurance works if still after long time of product launch basic functionality doesn't work?

It took days of my time testing the module hoping it is close to production quality but it is far away yet.

@jmarcelino
Thanks for your help in debugging!

Béla

[bmarkus]

@jmarcelino said in LoRaWAN downlink data not received:

Thanks for raising this @bmarkus it certainly will help many others - but it would have a bit quicker to pinpoint if you described the issue in more detail ;-) especially the use of a non-default port.

In LoRaWAN there are no such thing as default port.

[bmarkus]

@jmarcelino said in LoRaWAN downlink data not received:

Github issue: https://github.com/pycom/pycom-micropython-sigfox/issues/46

I'm not familiar with the GitHub structure, but is this sigfox section the right place for a LoRaWAN issue?

[jmarcelino]

@bmarkus said in LoRaWAN downlink data not received:

Why other ports are dropped?

I believe the reason is because all LoRaMac-node code examples do this. Then again they are only sample applications not to be taken verbatim.

It's however interesting that this passed LoRaWAN certification - which from what I can see now is satisfied as long as downlinks to port 0 and 224 work.

I'm not familiar with the GitHub structure, but is this sigfox section the right place for a LoRaWAN issue?

Yes, that is the main repository for all protocols, -sigfox title was added because the original repo didn't include the sigfox stack.

[dbrgn]

@jmarcelino said in LoRaWAN downlink data not received:

Yes, that is the main repository for all protocols, -sigfox title was added because the original repo didn't include the sigfox stack.

...which was a pretty confusing move, since they could just have created a new branch.

[daniel]

@bmarkus thanks for reporting this. Fixing it now...