Issues with LoPy4 connecting to a Rak2245 using their software with Chirpstack as the server backend
-
I've been using the LoPy4 only semi-successfully over the past couple of week. Using a combination of examples code from pycom and suggestions from users on the forums I am able to successfully connect to chirpstack, transmit data, and see the data within chirpstack. The trouble is that after a few successful sends I start to receive errors that never get resolved.
I am using a RAK2245 gateway with RAK's image for it. I am also using Chirpstack as the server backend.
The gateway is sitting about 20 feet away with two walls between the LoPy and it.
On the gateway side, the packet-forwarder config is based on this, https://github.com/TheThingsNetwork/gateway-conf/blob/master/US-global_conf.json and is left to default.
My current code on the LoPy4 is here.
import socket import time import binascii import pycom from network import LoRa from CayenneLPP import CayenneLPP from pysense import Pysense from LIS2HH12 import LIS2HH12 from SI7006A20 import SI7006A20 from LTR329ALS01 import LTR329ALS01 from MPL3115A2 import MPL3115A2,ALTITUDE,PRESSURE py = Pysense() mp = MPL3115A2(py,mode=ALTITUDE) # Returns height in meters. Mode may also be set to PRESSURE, returning a value in Pascals si = SI7006A20(py) lt = LTR329ALS01(py) li = LIS2HH12(py) # Disable heartbeat LED pycom.heartbeat(False) # Initialize LoRa in LORAWAN mode. lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.US915, adr=True, tx_retries=50, power_mode=LoRa.ALWAYS_ON, device_class=LoRa.CLASS_A) #lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.US915, tx_retries=50, power_mode=LoRa.ALWAYS_ON, device_class=LoRa.CLASS_A) app_eui = binascii.unhexlify('0000000000000000') app_key = binascii.unhexlify('661f82eec745983811318d3b44aa9a01') print("DevEUI: %s" % (binascii.hexlify(lora.mac()))) print("AppEUI: %s" % (binascii.hexlify(app_eui))) print("AppKey: %s" % (binascii.hexlify(app_key))) for i in range(0, 71): lora.remove_channel(i) lora.bandwidth(LoRa.BW_125KHZ) lora.add_channel(index=0, frequency=903800000, dr_min=0, dr_max=3) lora.add_channel(index=1, frequency=904000000, dr_min=0, dr_max=3) lora.add_channel(index=2, frequency=904200000, dr_min=0, dr_max=3) lora.add_channel(index=3, frequency=904400000, dr_min=0, dr_max=3) lora.add_channel(index=4, frequency=904500000, dr_min=0, dr_max=3) lora.add_channel(index=5, frequency=904700000, dr_min=0, dr_max=3) lora.add_channel(index=6, frequency=904800000, dr_min=0, dr_max=3) lora.add_channel(index=7, frequency=904900000, dr_min=0, dr_max=3) # join a network using OTAA (Over the Air Activation) lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key)) # wait until the module has joined the network while not lora.has_joined(): pycom.rgbled(0x140000) time.sleep(2.5) pycom.rgbled(0x000000) time.sleep(1.0) print('Not yet joined...') print('OTAA joined') pycom.rgbled(0x001400) # create a LoRa socket s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) # set the LoRaWAN data rate s.setsockopt(socket.SOL_LORA, socket.SO_DR, 3) s.setsockopt(socket.SOL_LORA, socket.SO_CONFIRMED, True) # set LoRaWAN to confirmed #s.bind(1) lpp = CayenneLPP() print(lpp.get_size()) while True: s.setblocking(True) pycom.rgbled(0x000014) print('\n\n** 3-Axis Accelerometer (LIS2HH12)') print('Acceleration', li.acceleration()) print('Roll', li.roll()) print('Pitch', li.pitch()) lpp.add_accelerometer(1, li.acceleration()[0], li.acceleration()[1], li.acceleration()[2]) lpp.add_gryrometer(1, li.roll(), li.pitch(), 0) """ A """ print('\n\n** Humidity and Temperature Sensor (SI7006A20)') print('Humidity', si.humidity()) print('Temperature', si.temperature()) lpp.add_relative_humidity(1, si.humidity()) lpp.add_temperature(1, si.temperature()) mpPress = MPL3115A2(py,mode=PRESSURE) print('\n\n** Barometric Pressure Sensor with Altimeter (MPL3115A2)') print('Pressure (hPa)', mpPress.pressure()/100) lpp.add_barometric_pressure(1, mpPress.pressure()/100) mpAlt = MPL3115A2(py,mode=ALTITUDE) print('Altitude', mpAlt.altitude()) print('Temperature', mpAlt.temperature()) lpp.add_gps(1, 0, 0, mpAlt.altitude()) lpp.add_temperature(2, mpAlt.temperature()) print(lpp.get_size()) print('Sending data (uplink)...') try: s.send(bytes(lpp.get_buffer())) except OSError as e: print("Error Happened:" + str(e)) s.setblocking(False) time.sleep(5) data = s.recv(64) print('Received data (downlink)', data) lpp.reset() pycom.rgbled(0x001400) time.sleep(5)With this setup, the device connects to the gateway without issue and the first few sends are received and confirmed. After a few cycles of sending new data this error will get thrown:
[Errno 11] EAGAINwhich usually happens a few cycles followed by this being thrown
[Errno 122] EMSGSIZEI am not too sure what should be changed on the packet-forwarder file within the gateway, but I have tried changing
this
"chan_Lora_std": { "desc": "Lora MAC, 500kHz, SF8, 904.6 MHz", "enable": true, "radio": 0, "if": 300000, "bandwidth": 500000, "spread_factor": 8 },to
"chan_Lora_std": { "desc": "Lora MAC, 500kHz, SF8, 904.6 MHz", "enable": true, "radio": 0, "if": 300000, "bandwidth": 125000, "spread_factor": 7 },which did not let me even connect to it.
At this point I feel like I do not know enough about this to successfully trouble shoot what is going on. The package size is 42 bytes which I thought was well within DR 3 which I thought I was defining here:
s.setsockopt(socket.SOL_LORA, socket.SO_DR, 3)The packets that arrive on chirpstack look like this:
Join Request
Join Accept
Confirmed Data Up
Then after the errors start up I begin receiving Unconfirmed Data, though it does show up on Chirpstack.
Unconfirmed Data Up
What is odd to me is that on the confirmed data transfers, the bandwidth and spreadingFactor are not what they are supposed to be, in this case they are Bandwidth = 500, spreadingFactor = 8. On the lopy I thought it would be sending at Bandwidth = 125 and spreadingFactor = 7.
I also tried setting the minimum and max allowed data rate in chirpstack to be 3 for both along with adjusting the LoPy code to not allow ADR
lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.US915, tx_retries=50, power_mode=LoRa.ALWAYS_ON, device_class=LoRa.CLASS_A)and
lora.bandwidth(LoRa.BW_125KHZ) lora.add_channel(index=0, frequency=903800000, dr_min=3, dr_max=3) lora.add_channel(index=1, frequency=904000000, dr_min=3, dr_max=3) lora.add_channel(index=2, frequency=904200000, dr_min=3, dr_max=3) lora.add_channel(index=3, frequency=904400000, dr_min=3, dr_max=3) lora.add_channel(index=4, frequency=904500000, dr_min=3, dr_max=3) lora.add_channel(index=5, frequency=904700000, dr_min=3, dr_max=3) lora.add_channel(index=6, frequency=904800000, dr_min=3, dr_max=3) lora.add_channel(index=7, frequency=904900000, dr_min=3, dr_max=3)However this does not help and the errors just keep coming.
-
@JaRay Did you manage to get this working? I have a FiPy and Chirpstack running on a Pi4 with RAK2245 same as you and I'm getting a very unreliable uplink / downlink connection similar to what you're experiencing and I suspect its due to channel configs.
Someone said that you would be seeing as few as 1/5 of the packets which is about what I'm experiencing.
Any luck?
Here I'm sending a payload from the FiPy every 30 seconds but only getting an unconfirmed uplink every 3-5 minutes or so. So I'm actually closer to only 1 in 10 messages being delivered.
Here is another chart to visualize how irregular my uplinks are. This reflects an attempt at 1 min intervals but shows that more often than not packets are not delivered. These spikes should be perfectly spaced 1 minute apart. This is between a FiPy and the gateway which are in the same room about 10 feet from each other, no barriers.
-
@sheng If your comment is about the amount of indentation:
any size is fine, as long as it is at least 1 character and consistent within the indented block. The style guide PEP8 suggest spaces, but that is not mandatory.
-
for i in range(0, 71): lora.remove_channel(i)isn't it suppose to be something like this?
for i in range(0, 71): lora.remove_channel(i)
-
HI, @JaRay
First, I'm sorry for the error...905100000, 905000000 is correct... this field is for the Frequency center.
Based on this official doc: https://lora-alliance.org/sites/default/files/2020-06/rp_2-1.0.1.pdf (section 2.5)
Concerning the channel 64, each US915 subband contains (8*channels of 125000kHz + 1 channel of 500000kHz)
BTW just realized that 64 should be 65... you're using subband 1.ouufffffff sorrySection 2.5.2
*The 915MHz ISM Band SHALL be divided into the following channel plans.488
• Upstream –64 channels numbered 0 to 63utilizing LoRa 125kHz BW varying from DR0toDR3, using coding rate 4/5,starting at 902.3 MHz and incrementing linearly 200 kHz to 914.9MHz • Upstream –8 channels numbered 64 to 71utilizing LoRa 500 kHz BW at DR4 starting at 903.0 MHz and incrementing linearly by 1.6MHzto 914.2 MHz •Downstream – 8 channels numbered 0 to 7 utilizing LoRa 500kHz BW at DR8 to DR13,starting at 923.3 MHz and incrementing linearly by 600 kHz to 927.5 MHz*So I built a spreadsheet to get a better view of it: LoraWan US915 Channel Plan 3.pdf
Regards.
-
So this is interesting and I can not figure out why it is the case.
If I setup the channels like this
for i in range(0, 71): lora.remove_channel(i) lora.add_channel(index=0, frequency=903900000, dr_min=0, dr_max=3) lora.add_channel(index=1, frequency=904100000, dr_min=0, dr_max=3) lora.add_channel(index=2, frequency=904300000, dr_min=0, dr_max=3) lora.add_channel(index=3, frequency=904500000, dr_min=0, dr_max=3) lora.add_channel(index=4, frequency=904700000, dr_min=0, dr_max=3) lora.add_channel(index=5, frequency=904900000, dr_min=0, dr_max=3) lora.add_channel(index=6, frequency=905100000, dr_min=0, dr_max=3) lora.add_channel(index=7, frequency=905300000, dr_min=0, dr_max=3) lora.add_channel(index=64,frequency=904600000, dr_min=4, dr_max=4) lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key), timeout=0) while not lora.has_joined(): time.sleep(2.5) print('Not yet joined...')The gateway will never see the the node. However, if I remove the block of code where I remove all channels and add these 9 then it will connect pretty quickly and start sending data. This does not make sense since I have the channels setup just like the gateway. You mentioned changing
"radio_1": { "enable": true, "type": "SX1257", "freq": 905000000, "rssi_offset": -166.0, "tx_enable": falseto
"radio_1": { "enable": true, "type": "SX1257", "freq": 905100000, "rssi_offset": -166.0, "tx_enable": falseI don't see why this is the case. The channels are setup like this on the gateway by default
{ "SX1301_conf": { "lorawan_public": true, "clksrc": 1, "antenna_gain": 0, "radio_0": { "enable": true, "type": "SX1257", "freq": 904300000, "rssi_offset": -166.0, "tx_enable": true, "tx_freq_min": 902000000, "tx_freq_max": 928000000 }, "radio_1": { "enable": true, "type": "SX1257", "freq": 905000000, "rssi_offset": -166.0, "tx_enable": false }, "chan_multiSF_0": { "enable": true, "radio": 0, "if": -400000 }, "chan_multiSF_1": { "enable": true, "radio": 0, "if": -200000 }, "chan_multiSF_2": { "enable": true, "radio": 0, "if": 0 }, "chan_multiSF_3": { "enable": true, "radio": 0, "if": 200000 }, "chan_multiSF_4": { "enable": true, "radio": 1, "if": -300000 }, "chan_multiSF_5": { "enable": true, "radio": 1, "if": -100000 }, "chan_multiSF_6": { "enable": true, "radio": 1, "if": 100000 }, "chan_multiSF_7": { "enable": true, "radio": 1, "if": 300000 }, "chan_Lora_std": { "enable": true, "radio": 0, "if": 300000, "bandwidth": 500000, "spread_factor": 8 }, "chan_FSK": { "enable": false, "radio": 0, "if": 300000, "bandwidth": 250000, "datarate": 100000 },I feel like with how I setup the channels on the LoPy4 this should connect. I don't get why it connects if I let every channel operate but not if I target the correct frequencies.
-
I appreciate you updating this topic with new information. Like I said I am having to refresh myself with all of the information.
As far as your point number 3 goes, how did you come up with changing the radio 1 freq to 905100000?
I just reflashed this RAK2245 gateway with the most up to date OS, so everything is setup for the default chirpstack implementation. The default gateway config shows the radio_1 frequency as 905000000, how did you come up with 905100000.
Also why are you adding "lora.add_channel(64, frequency=904600000, dr_min=4, dr_max=4)" ?
-
Hi,
-
FYI: Take a look of this table to review your frequencies setup.
https://www.baranidesign.com/faq-articles/2019/4/23/lorawan-usa-frequencies-channels-and-sub-bands-for-iot-devices -
I would say.... if you want to use subband 1, multiples changes are required on your GW side and also on your NODE side.
-
Your changes should be on the GW side, something like this
.........................
"radio_0": {
"enable": true,
"type": "SX1257",
"freq": 904300000,
"rssi_offset": -166.0,
"tx_enable": true,
"tx_freq_min": 902000000,
"tx_freq_max": 928000000
},
"radio_1": {
"enable": true,
"type": "SX1257",
"freq": 905100000,
"rssi_offset": -166.0,
"tx_enable": false -
On your NODE side:
..........................
lora.bandwidth(LoRa.BW_125KHZ)
lora.add_channel(0, frequency=903900000, dr_min=0, dr_max=3)
lora.add_channel(1, frequency=904100000, dr_min=0, dr_max=3)
lora.add_channel(2, frequency=904300000, dr_min=0, dr_max=3)
lora.add_channel(3, frequency=904500000, dr_min=0, dr_max=3)
lora.add_channel(4, frequency=904700000, dr_min=0, dr_max=3)
lora.add_channel(5, frequency=904900000, dr_min=0, dr_max=3)
lora.add_channel(6, frequency=905100000, dr_min=0, dr_max=3)
lora.add_channel(7, frequency=905300000, dr_min=0, dr_max=3)
lora.add_channel(64, frequency=904600000, dr_min=4, dr_max=4)
This is what I can see for now, if it can help.
-
-
@jcaron Hi jcaron. I made this post right before we had to shutdown for COVID, so I shelved this product for the time being. I am coming back to this, and once again trying to get things working. It is hard coming back to a project and not remembering where you left off.
I am testing out your suggestions to see what comes of it.
-
At the very least, you channel configurations do not seem to match.
If I understand your gateway's config file correctly, it is apparently configured for:
* 904 300 000 - 400 000 = 903 900 000 * 904 300 000 - 200 000 = 904 100 000 * 904 300 000 = 904 300 000 * 904 300 000 + 200 000 = 904 500 000 * 905 000 000 - 300 000 = 904 700 000 * 905 000 000 - 100 000 = 904 900 000 * 905 000 000 + 100 000 = 905 100 000 * 905 000 000 + 300 000 = 905 300 000I.e. frequencies from 903.9 to 905.3 MHz with 200 kHz steps.
You LoPy on the other hand is configured for 903.8, 904.0, 904.2, 904.4, 904.5, 904.7, 904.8 and 904.9.
So you only have 904.5, 904.7, and 904.9 in common. It should mean that at least 5 packets out of 8 will get lost. I'm not quite sure how frames are sent or received on 904.6 given the config on both sides, or how frames are sent on 904.1. The gateway may (and probably does, though it's not visible in the data here) send the list of frequencies it actually uses, so this may resolve itself. Do the screenshots actually match the configuration/sources you included?
On the LoPy, some of the settings like
lora.bandwidthare only used for raw LoRa, not LoRaWAN (they are just ignored in that case, the info comes from the DR instead). IIRC, some rules are hardcoded in the LoRaWAN stack, so it's best to match channel numbers, frequencies and data rates with the official values to avoid any mismatches.In some regions, there are limits on how much data is sent, so gateways can't just ack every single packet. Not sure what the rules are in the US region, but you may be hitting such a limit (especially with the very short interval between packets you use).
