Not receiving data - always empty
-
I'm just using the standard example code to send data to a loriot gateway (I can see that data arrive on the server) but I can't seem to get any data back.
Device: Pycom MicroPython 1.18.2.r4 [v1.8.6-849-ba178ae] on 2019-04-01; LoPy4 with ESP32
The loriot gateway has an option to queue up some data to send next time data is received, you can specify the port (I've tried lots of options, but mainly stick to 1 and 2)
I found this post where there was a bug in the code for non-standard ports, but I don't think that applies.
https://forum.pycom.io/topic/1599/lorawan-downlink-data-not-received/19I've tried using the exact same code as the example above, I've tried setting up the callback, I've also tried the normal recv as well as recvfrom with different buffer sizes.
One difference is that I specify the frequencies, could that have any effect?
from network import LoRa import socket import ubinascii import struct import pycom import time import gc gc.collect() COLOUR_RED = 0x050000 COLOUR_GREEN = 0x000500 COLOUR_BLUE = 0x000005 pycom.heartbeat(False) #pycom.rgbled(COLOUR_GREEN) lora = LoRa(mode=LoRa.LORAWAN) print('Device details: ',os.uname()) print('DEVEUI:', str(ubinascii.hexlify(lora.mac()))[1:]) # Set up KotahiNet channels lora.add_channel(0, frequency=864862500, dr_min=0, dr_max=5) lora.add_channel(1, frequency=865062500, dr_min=0, dr_max=5) lora.add_channel(2, frequency=865402500, dr_min=0, dr_max=5) lora.add_channel(3, frequency=865602500, dr_min=0, dr_max=5) lora.add_channel(4, frequency=865985000, dr_min=0, dr_max=5) lora.add_channel(5, frequency=866200000, dr_min=0, dr_max=5) lora.add_channel(6, frequency=866400000, dr_min=0, dr_max=5) lora.add_channel(7, frequency=866600000, dr_min=0, dr_max=5) # create ABP authentication params- dev_addr = struct.unpack(">l", ubinascii.unhexlify('aaaa'))[0] nwk_swkey = ubinascii.unhexlify('bbbb') app_swkey = ubinascii.unhexlify('cccc') lora.join(activation=LoRa.ABP, auth=(dev_addr, nwk_swkey, app_swkey)) s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) s.setsockopt(socket.SOL_LORA, socket.SO_DR, 0) # set data rate to zero # selecting confirmed type of messages # this causes error: File "<stdin>", line 5, in <module> OSError: [Errno 11] EAGAIN #s.setsockopt(socket.SOL_LORA, socket.SO_CONFIRMED, True) #s.setsockopt(socket.SOL_LORA, socket.SO_CONFIRMED, False) # def lora_cb(lora): # events = lora.events() # if events & LoRa.RX_PACKET_EVENT: # print('Lora packet received') # if events & LoRa.TX_PACKET_EVENT: # print('Lora packet sent') # lora.callback(trigger=(LoRa.RX_PACKET_EVENT | LoRa.TX_PACKET_EVENT), handler=lora_cb) print('Waiting a bit...') pycom.rgbled(COLOUR_BLUE) time.sleep(5.0) pycom.rgbled(COLOUR_GREEN) # make the socket blocking #s.setblocking(True) #s.bind(10) # send some data #s.send(bytes([0x02, 0x01, 0x03])) for i in range(1,11): #pycom.rgbled(COLOUR_GREEN) s.setblocking(True) s.setsockopt(socket.SOL_LORA, socket.SO_CONFIRMED, False) s.send(bytes([0x10, 0x11, 0x12])) print('Sent',i) #time.sleep(1) #pycom.rgbled(COLOUR_BLUE) #make the socket non-blocking (because if there's no data received it will block forever...) s.setblocking(False) #get any data received… #data = s.recv(32) data, port = s.recvfrom(32) #if data: # print('Received:', data, ' on port:', port) # print(lora.stats()) print('Received:', data, ' on port:', port) #pycom.rgbled(COLOUR_RED) print('Finished')One thing that's a bit weird is if I uncomment those LED colour change lines, and run it, I would expect to see it cycle between green, blue and red as it loops, but after an initial green, it just goes red, am I missing something with the loop?
Also I've had some issues with signal strength, I've found a spot upstairs where I can send data successfully, I'm assuming if I can send then I can receive?
Thanks for any help - I've been stuck on this for over a week.
-
@robert-hh ok, thanks
-
@mk I do not know much about the details. This build just includes the already existing modules for IN865 and adds in modlora.c the keywords and defaults for that region. It does NOT include changes to the LoRa software made since that version.
-
@robert-hh re-downloaded and flashed successfully with the same settings as you. There was a file size difference as well, so most likely problem was that I didn't download it properly the first time.
Is the key difference between this custom firmware and the standard, that RX2 for downlinks uses the IN865 frequency? Is there anything else?
-
@mk ah, they mentioned RX2 on their site, so for some reason I was convinced they were sending on that.
The device always listens on both, it’s up to the network to decide which one it uses.
RX1 uses the same frequency and data rate as the upload by default, but offsets can be set by the network.
You are doing an ABP join, you should switch to OTAA to get all the settings from the network. Also try sending using the lowest possible data rate (highest number) as that will dictate how the reply is sent.
Does their back-end show the channel and data rate for downlinks? Or can you log
LoRa.stats()when you receive one?
-
@mk I just flashed that file from github to my LoPy4, and it worked. I left however the setting "erase flash" and "LoRa Region Select" untouched. And I usually select a low transfer speed of 230400.
-
@mk I have to check again, if the tar file is packed the right way. Maybe that is the problem.
-
@jcaron thanks for your comments, this one got me thinking a bit more and I asked the provider for some more details:
I’m still surprised you actually received anything. The RX2 frequency and data rate is different, and is none of the channels you configured... They must have a hybrid deployment where some gateways are actually sending on the EU RX2, not the IN one?
They said:
by default we use the RX1 window, but can change to use the RX2 window on a device-specific basis, which would use the IN865 866.5500 MHz, DR2 (SF10)
I'm still pretty new to this stuff, but the LoRa Alliance regional parameters doc seems to indicated that RX1 is the default and just uses the same channel (is that the same as frequencies?) as the last uplink for the downlink. I'm only expecting to receive data after a send from the device. So does that make it clearer why I was able to receive, or am I misunderstanding something (sorry if I am!)
-
@robert-hh I tried using the latest firmware upgrade tool, selected "LoPy4-IN865-1.20.0.rc7.2.tar.gz" but got the error
The upgrade failed due to the following error:
NoneType object is not iterableHere's the options I chose on the updater:
Communication screen:
- ticked high speed transfer, erase flash file system, and force update lora region
- choose "flash from local file"
LoRa region selection: (probably didn't need to do this, I was on EU868 already)
- Country: India (same as choosing Region=EU868)
Any ideas?
-
@robert-hh thanks for this
@jcaron i will find out some more details from the provider and see what they are doing.
They think it’s strange that I had signal issues from my location as they’ve had successes more than 3x as far away, and have recommended I try a different antenna (I was just using the standard one from pycom) to one that centres on 868 or
865, I have a couple on order and will update when they arrive
-
@mk On request, I made a few builds for the IN865 region. Copies are here: https://github.com/robert-hh/Shared-Stuff
being in the EU region, I tested them only against my own gateways, a Pycom Nanogateway and a IC880a.
-
@mk that’s the whole problem of LoRaWAN... it’s mostly “you send and you pray”, especially in regions like EU868 where there are duty cycle limitations which severely limit your ability to use confirmed packets.
In regions where those limits do it exist and the network allows it, you can use confirmed packets.
I’m still surprised you actually received anything. The RX2 frequency and data rate is different, and is none of the channels you configured... They must have a hybrid deployment where some gateways are actually sending on the EU RX2, not the IN one?
-
It was a signal issue.
I took the device into the CBD along with my laptop, phone for a hotspot to get to the loriot page, ran a test there and got data back OK.
So can confirm that EU868 is fine for IN865 frequencies if you set them manually. No need for firmware changes. Also there is no IN865 region you can init the lora object with, but there's no need anyway.
So the biggest problem I see with using LoRaWAN is the real lack of any kind of feedback when signal strengths are not good enough. lora.has_joined() = True doesn't really mean anything, you can think you are sending data but there's no way to know on-device that it went anywhere. Even if it did, and you can see it on a server, it doesn't mean the device is in range to receive. It's only when you receive data that you can get some lora.stats(), so really up until that point you have to assume that you aren't in range, which could end up with duplicate data arriving to the server.
-
@jcaron OK, I'll check the docs, I don't think I've seen IN865 as a region option anywhere.
I'll also start looking into building a custom firmware
-
@mk said in Not receiving data - always empty:
@jcaron thanks for the reply.
My device is configured for EU868 but I'm setting the frequencies with the lines below to be in the 864-866 range. I assumed these frequencies would be used for sending and receiving?
Nope. Uplink and downlink channels are handled separately in LoRaWAN. There are two downlink configurations, for the RX1 and RX2 windows respectively. They have different rules, and the rules are different from one region to another.
The network you are connecting to uses RX2, which has a (different) fixed frequency in both regions.
Per the LoRaWAN spec, in the EU868 region:
The RX2 receive window uses a fixed frequency and data rate. The default parameters are 869.525 MHz / DR0 (SF12, 125 kHz)
In the IN865 region:
The RX2 receive window uses a fixed frequency and data rate. The default parameters are 866.550 MHz / DR2 (SF10, 125 kHz).
Haven't checked in a while, but as far as I remember, there's no way to change those settings other than changing the region (or building a custom firmware).
-
@jcaron thanks for the reply.
My device is configured for EU868 but I'm setting the frequencies with the lines below to be in the 864-866 range. I assumed these frequencies would be used for sending and receiving?
lora.add_channel(0, frequency=864862500, dr_min=0, dr_max=5) lora.add_channel(1, frequency=865062500, dr_min=0, dr_max=5) lora.add_channel(2, frequency=865402500, dr_min=0, dr_max=5) lora.add_channel(3, frequency=865602500, dr_min=0, dr_max=5) lora.add_channel(4, frequency=865985000, dr_min=0, dr_max=5) lora.add_channel(5, frequency=866200000, dr_min=0, dr_max=5) lora.add_channel(6, frequency=866400000, dr_min=0, dr_max=5) lora.add_channel(7, frequency=866600000, dr_min=0, dr_max=5)If IN865 is India's range, then yes, that's the way it's supposed to work. The gateway providers have successfully tested a LoPy (not sure about LoPy4 though) using EU868 and setting the frequencies.
The pycom docs say this about allowed ranges:
frequency accepts values between 863000000 and 870000000 in the 868 band, or between 902000000 and 928000000 in the 915 band.
I can see on the loriot web interface that sent packets are coming through on a range of frequencies, that all match what's been set:
BE7A0200000003BB 4/27/2019, 9:59:51 PM 866.200 SF12 BW125 4/5 12 2 101112 BE7A0200000003BB 4/27/2019, 9:59:47 PM 866.600 SF12 BW125 4/5 11 2 101112 BE7A0200000003BB 4/27/2019, 9:59:43 PM 866.400 SF12 BW125 4/5 10 2 101112 BE7A0200000003BB 4/27/2019, 9:59:39 PM 865.063 SF12 BW125 4/5 9 2 101112 BE7A0200000003BB 4/27/2019, 9:59:31 PM 865.602 SF12 BW125 4/5 7 2 101112 BE7A0200000003BB 4/27/2019, 9:59:27 PM 865.403 SF12 BW125 4/5 6 2 101112 BE7A0200000003BB 4/27/2019, 9:58:22 PM 866.400 SF12 BW125 4/5 9 10 101112 BE7A0200000003BB 4/27/2019, 9:58:17 PM 865.063 SF12 BW125 4/5 8 10 101112 BE7A0200000003BB 4/27/2019, 9:58:12 PM 865.063 SF12 BW125 4/5 7 10 101112 BE7A0200000003BB 4/27/2019, 9:58:02 PM 865.602 SF12 BW125 4/5 5 10 101112 BE7A0200000003BB 4/27/2019, 9:57:47 PM 866.600 SF12 BW125 4/5 2 10 101112 BE7A0200000003BB 4/27/2019, 9:57:42 PM 866.600 SF12 BW125 4/5 1 10 101112 BE7A0200000003BB 4/27/2019, 9:57:37 PM 865.063 SF12 BW125 4/5 0 10 101112I've set the data rate to 0 as per the gateway's instructions, loriot's datarate column shows SF12 BW125 4/5 (I'm not sure what the 4/5 is). You can see the sequence numbers go up from 0-12 and I sent some packets on port 10 at the start and some on port 2 at the end.
As I'm not getting any data back, I can't confirm anything else like signal strength from lora.stats()
To confirm if it's a signal strength issue, I'm going to take my laptop and LoPy4 in the car and drive to another part of town to where I know the signal is coming from. Obviously that's not going to be great for further dev and testing, but I should be able to at least know if that's the issue.
-
@mk RX and TX use different settings in terms of channel (frequency) and data rate, so no, it's not because you can send that you can receive. Also, a radio chain is not necessarily symmetrical, depending on the respective antenna gains and receiver sensibilities, you could have very different results.
However, the most probable issue is that your LoPy is not listening on the correct frequency for downlinks. What region is your device configured for? It it's configured for EU868, il will be listening on 869.525 MHz at RX2, while they are sending on 866.550 MHz as per IN865 (the SF is also different).
I know there have been discussions about the IN865 band several times, I don't remember if it is currently supported out of the box in current firmware or if you have to do something special. Others (@robert-hh ?) will probably be able to shine a light on that.
