How to implement downlink messages

[dbrgn]

Thanks for your answers, @jmarcelino and @jcaron :)

@dbrgn what happens if instead of listening for events you actually try to receive data on the socket right after sending?

Good idea. Does not seem to work though :(

Sending packet 3...
Try to receive on port 150...
Timeout
A LoRa event occured: Lora packet sent
Sending packet 4...
Try to receive on port 150...
Timeout
A LoRa event occured: Lora packet sent

This is the code I used:

# Initialize incoming socket
s_in = usocket.socket(usocket.AF_LORA, usocket.SOCK_RAW)
s_in.setblocking(False)
s_in.settimeout(1)
s_in.bind(150)

# Main loop
counter = 0
while True:
    print('Sending packet %d...' % counter)
    s_out.send(bytes([counter]))
    counter += 1
    print('Try to receive on port 150...')
    try:
        received = s_in.recv(64)
        print('Received: %r' % received)
    except:
        print('Timeout')
    utime.sleep_ms(10000)

I feel your original post is spreading into too many topics

You might be right. On the other hand, a single known-to-be-working example by Pycom could probably cover all those areas :)

I see from your code your appear to be using a single channel gateway?

No, it's an iC880A board with the poly packet forwarder that a lot of other people run in production. Joining via OTAA works, so it's definitely capable of doing downlinks.

Can you post a screenshot of the TTN "Gateway Traffic" page for your gateway, showing the frequencies and transmission times?

Great idea. Here's the screenshot of four uplinks and one downlink:

I also tried to send a confirmed downlink. According to the gateway stats it was only sent down once, but I can't see any flag whether it was confirmed or not by the LoPy. Not sure how TTN handles the displaying of confirmed downlinks.

[dbrgn]

Also, here's an excerpt from the gateway logs, after sending two downlinks:

Jul 28 20:54:15 ttn-gw-test ttn-gateway[2881]: ### [DOWNSTREAM] ###
Jul 28 20:54:15 ttn-gw-test ttn-gateway[2881]: # PULL_DATA sent: 3 (100.00% acknowledged)
Jul 28 20:54:15 ttn-gw-test ttn-gateway[2881]: # PULL_RESP(onse) datagrams received: 2 (346 bytes)
Jul 28 20:54:15 ttn-gw-test ttn-gateway[2881]: # RF packets sent to concentrator: 2 (28 bytes)
Jul 28 20:54:15 ttn-gw-test ttn-gateway[2881]: # TX errors: 0

I'm not sure I read this correctly, but I think that means that 2 downlink packets were sent over the air from the gateway to the node.

[jmarcelino]

@dbrgn
OK since you're using ABP how are you handling the frame counters? Resetting them through the TTN console?

I see in your example your uplink counter seems to have started back from 1 when the first downlink counter there is 7.

TTN's console display of confirmed downlinks is a bit buggy AFAIK so you might not see it in the browser.

[dbrgn]

@jmarcelino said in How to implement downlink messages:

OK since you're using ABP how are you handling the frame counters? Resetting them through the TTN console?

I use relaxed frame counters for development.

I see in your example your uplink counter seems to have started back from 1 when the first downlink counter there is 7.

I think that makes sense, since the uplink frame counters are managed by the device (and reset when the device resets) while the downlinks are managed by the server, where the counter can be stored properly.

To make sure that nothing is wrong with the configuration, I deleted and re-created the device in the TTN backend. Then I re-did the same example script with OTAA instead of ABP. Joining worked (so downlink transmission seems to work fine in principle). But the downlinks did not arrive.

Maybe I'll get the possibility to test with a different network in the next days (not sure if I have coverage). But I haven't heard of downlink issues with TTN so far.

[jmarcelino]

@dbrgn said in How to implement downlink messages:

I use relaxed frame counters for development.

Ok I asked because "relaxed frame counters" means TTN disregards uplink counters when authenticating incoming messages but it doesn't mean the LoPy will disregard frame counters on downlinks: TTN's counter must always be higher than what the LoPy expects (up to a "max frame counter gap" ...). But yes that is happening and not the problem in this case.

@dbrgn said in How to implement downlink messages:

Maybe I'll get the possibility to test with a different network in the next days (not sure if I have coverage). But I haven't heard of downlink issues with TTN so far.

Downlinks in general should work. What I meant is there are reported issues with the display of confirmed downlinks on TTN's console.

All my LoPy are tied up at the moment so I can't test this, but what happens if you do uplinks and downlinks using the same port number instead of different as you're doing? It may be that you really only have one LoRa socket for the whole system so the uplink and downlink port numbers must match.

[jcaron]

@dbrgn Just to be sure, you are aware of the 10 downlink messages per day limitation on TTN? Note that this includes confirmed uplink ACKs. Basically downlinks are unusable on LoRaWAN, at least in the ETSI region.

Not quite sure how this would appear in logs though.

[dbrgn]

@jcaron said in How to implement downlink messages:

@dbrgn Just to be sure, you are aware of the 10 downlink messages per day limitation on TTN? Note that this includes confirmed uplink ACKs. Basically downlinks are unusable on LoRaWAN, at least in the ETSI region.

Yes, but I think so far that's just a soft limit. I won't do that many downlinks in production, but I think it's fair if I occasionally go over the limit while testing as long as I don't exceed the 1% duty cycle, especially since both gateways in my area are provided by me :)

@jmarcelino said in How to implement downlink messages:

but what happens if you do uplinks and downlinks using the same port number instead of different as you're doing?

I think I tried that too, without better results.

It may be that you really only have one LoRa socket for the whole system so the uplink and downlink port numbers must match.

If that would the case, the LoRaWAN stack would be pretty useless :) But I don't think it's the case. At least sending on different ports works properly.

[jmarcelino]

@dbrgn
I came across this one today and found there is a problem in the current implementation, only downlinks to ports 1 and 2 are being accepted.

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

May explain your problems.

[Brick]

@jmarcelino Thanks. I was trying to get downlink messages for about a week now without success.
Changing port to 1 helped.

[dbrgn]

@jmarcelino wow, thanks a lot for that find. explains the headaches I've been having :)