AS923
-
Is there support for AS923 in the latest LoPy firmware (1.7.3.b1)?
As the data rates are defined differently how would the LoPy band plan be selected. I know you can define the channels manually and I have managed to get the OTAA join request out of the LoPy but I can't get qa successful join.
Has anyone had any success with AS923?
I'm using a multitech gateway, TTN backend and their latest packet forwarder ([v2.0.2] https://github.com/TheThingsNetwork/packet_forwarder/releases))
-
I'm registering my interest in AS923 support.
Many of the telcos in AU and NZ are implementing AS923 and will not support devices based on LoPy in its current state of affairs.
We're going to have to ditch the LoPy and go with muRata or Multitech modules unless the firmware is updated to give more control. Is this on the cards?
-
Quite possible, it looks like the LoPy isn't pick up the RX even though I can see the message being queued on the gateway at the same Freq, SF, and BW as the uplink packet. I know the data rate specifications are different on AS923 so when you define a channel on the LoPy is will only allow DR 0-4 on a 915MHz build where as AS923 has 0-7 defined as it allows a much wider range of SF.
To be honest it would actually be clearer from a developer's point of view to be able to define a channel based on SF and BW and therefore make the firmware build more flexible.
As more and more band plans are defined by the LoRa Alliance I can see the LoPy is going to need to be able to be dynamically configurable, especially for countries in NZ where multiple band plans are available. A regional/geograhpical lock just doesn't work in that situation. perhaps that is a certification nightmare. The upstream code from Semtech has been substantially re-written to support AS923 and others for LoRaWAN 1.0.2, perhaps that code needs to be ported into the LoPy?
-
Is this related to: https://forum.pycom.io/topic/884/ttn-join-accept-not-handled-properly/18 ???
