LoRaWAN downlink data not received

[bmarkus]

LoRaWAN downlink data not received, lora.recv() returns empty buffer always. LoPy hardware is OK, in LoRa mode reception works fine.

It is 1.7.8.b1

[jmarcelino]

I'm on 1.7.8b1 and I can receive downlinks from TTN successfully.

TTN console:

Gateway:

{
  "gw_id": "stephenson-rising",
  "payload": "YHEpASYAAQAB2cCUW40uAjI=",
  "f_cnt": 1,
  "lora": {
    "spreading_factor": 7,
    "bandwidth": 125,
    "air_time": 51456000
  },
  "coding_rate": "4/5",
  "timestamp": "2017-08-02T08:26:48.313Z",
  "dev_addr": "26012971",
  "frequency": 867100000
}

On LoPy:

Sent 1 bytes
Data received: b'acec0ffe'

Maybe you can share more details of your configuration?

[bmarkus]

It is my code. Uplink works as expected. On the LoRaWAN network side I see that queued downlink message sent when uplink received (it is Class A device). However recv() return always b''

Network server is LORIOT, and there are two gateways in range, a Raspberry Pi with RisingHF SPI board and a Kerlink V2 iBTS. This arrangement works fine with other devices.

[jmarcelino]

@bmarkus
Why do you sleep 10 seconds between sending and receiving?

I simply do

    count = s.send(bytes([i % 256]))
    print('Sent %s bytes' % count)
    
    s.setblocking(False)
    data = s.recv(64)
    print("Data received: " + str(binascii.hexlify(data)))

If this doesn't help can you post some sort of log showing packets send/received by LoRiot, particularly times and frequencies?

[bmarkus]

@jmarcelino said in LoRaWAN downlink data not received:

@bmarkus
Why do you sleep 10 seconds between sending and receiving?

In the last days I tested various codes, including different timings or no delay at all. It doesn't matter, result is the same.

I will continue with OTAA test and add event callback.

[jmarcelino]

@bmarkus
I connected my gateway to Loriot but then found out the the free tier , community edition, doesn't allow downlinks so I'm afraid I I can't test this further.

[bmarkus]

I checked Network Server log and GW operation. Downlink messages are sent to the air correctly.

[bmarkus]

Tested with a Kerlink SPN Network Server, result is the same. It is definitely not a server side issue.

[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...