Open Bdanilko opened 6 years ago
What channels are predefined merely by using
lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.EU868)
?
When a region is set, then all of the default channels are set for that region. Looking at the spec, that should be:
New frequencies are added via the JoinAccept CFList or the NewChannelReq MAC command.
But the first three channels should always be there, as the two methods for adding channels can't change or remove the 3 defaults.
I haven't used EU868 yet, so this is all theoretical!
I agree, however this is clearly not working as when I used 868 I had no problems getting signals through to a LoRa gateway 7 km away but now I have specified AU915 nothing is getting through to me TTN gateway sitting 4 meters away.
Hi Simon,
Did you mean - region=LoRa.AU915 in your original post here? I commented on your thread in the pycom forums this morning that could be useful about the AU915 frequency plan.
There are some issues that make AU915 more difficult to get going. But with the latest firmware it is possible -- check the forum post. I'm running on AU915 as we speak.
Regards, Brian
Yes my line of code should have read
lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.AU915)
I just checked and my FiPy sent 874 messages, my TTN gateway actually received 11 of these when located 4 meters away. using 916.8, 917.0, 917.2, 917.6 and 917.8. Packet at gateway reads
{
"gw_id": "kohimarama",
"payload": "QFgsACYAagMCFSKsEoMHd88XLdmetZZZKYvv8xgUX8kiB4r6TrXNf+7kkB8fYn4OmhtWPuBm9PR8nthN5w==",
"f_cnt": 874,
"lora": {
"spreading_factor": 12,
"bandwidth": 125,
"air_time": 2793472000
},
"coding_rate": "4/5",
"timestamp": "2018-06-06T00:14:51.183Z",
"rssi": -92,
"snr": 9,
"dev_addr": "26002C58",
"frequency": 917000000
}
So some are now getting thru. An RSSI of -92 over that short range seems low.
Also what did you mean when you wrote "There are some issues that make AU915 more difficult to get going. But with the latest firmware it is possible -- check the forum post"?
Do you have a code snippet of the python you used successfully to set up the connection to LoraWAN at 915 MHz? Also what version of firmware are you using from Pycom?
Thanks Simon
Hi Simon, There is a bug in the 1.17. firmwares for AU915. It's described in the forum post I was referring to: https://forum.pycom.io/topic/3339/setting-region-on-fipy-doesnt-seem-to-work/2
That said, 1.17.x or 1.18.0 firmwares all can work, if the REMOVING of extra channels is done instead of trying to add them.
My code is in different classes so it's not easy to paste out of context (and is my client's) but the deletion of the frequencies should make things work. Use the 1.18.0 firmware, delete the frequencies not supported by the gateway and use a DR less then 5 (when setting up the socket). Then you should see your success rates jump!
Good luck, Brian
Thanks Brian, embarrassingly that was my own thread, just at work so didn't have time to look at it. I will try this as soon as I get home
Hey Guys, have you worked out code for AU? I'm dying to get this working. My latest post on the topic: https://forum.pycom.io/topic/3374/ttn-via-nano-gateway-in-au915-region-fails-on-otaa/5 Thanks, Chris.
I've been trying to get the patch accepted to fix this but have been having trouble getting past the contributor license agreement. I'll work with Bettina on that who I think is on holiday. But, you can work around it by just removing all of the channels that aren't supported by the gateway. Adding of channels 64 and up is broken, but they are already there by default. So just have to remove the un-supported channels. See the end of this thread: https://forum.pycom.io/topic/3339/setting-region-on-fipy-doesnt-seem-to-work
Hi @Bdanilko 👋
Did you manage to sort out the agreement? If not, I'm happy to help you with it, just let me know 😉
Hi @sdaniel55,
Thanks -- the issue with the CLA has been fixed (it referenced an old URL). I now have this fix in a pull request #183 waiting to be merged. It has been waiting a long time (almost 2 months), but you guys seem to be pretty busy. I'm sure it'll be merged as the problem is still outstanding.
Hi friend, new here. I sign in here to solve a question i have. I buy a Helium Hnt hotspot miner (Nebra) us915, but my country (argentina) Is au915! Works anyway, don't works, i can setup to make it works? I Will tanks any help
Hi, Please contact Helium or Nebra with your issue. This is the open-source repository for the Pycom-Micropython firmware which has no relation to the Helium network nor Nebra specifically.
System I'm using: (sysname='LoPy4', nodename='LoPy4', release='1.17.3.b1', version='ae3a294-dirty on 2018-05-01', machine='LoPy4 with ESP32', lorawan='1.0.2', sigfox='1.0.1') I've done a new version of the firmware to test my 'fix' -- but the issue was definitely in the original 1.17.3.b1 firmware.
When adding a single 500kHz channel for the AU915 (id 64-71), it is not added:
self.lora.add_channel(65, frequency=917500000, dr_min=6, dr_max=6)
The issue seems to be that the function: RegionAU915ChannelManualAdd( ChannelAddParams_t* channelAdd ) enforces that the dr_min has to be 0 for ALL channels. But for the AU915 and US915 channel id's 64-71, the dr_min is not meant to be zero (for AU915 it is DR6 and US915 it is DR4).
This results in the channel silently being discarded on the add_channel() call, so not being available for transmission.