Weāve spent years battling against use of SCPFās on TTN and trying to educate folk and now this looks to formalise option - even if āexperimentalā!
And worst still drives excess use (as no longer spread over random channel selection) of one of the key mandatory channelsā¦
I seriously suggest the future starts now for this feature. @johan is TTI seriously considering to allow non compliant hardware to hog one of the 3 join channels defined in the standard? What is the response of the Lora Alliance on this proposal? If TTI want to implement something for non compliant hardware then at least use a less critical frequency for this purpose please, pretty pleaseā¦
My gateways are busy being spammed with join requests from unknown devices as is, no need to clutter those three frequencies even more. (SF12 requests, some just seconds apart on multiple gateways tens of kilometers apart)
But if it can be abused then efforts elsewhere inside TTI to provide a better onboarding experience for new developers will be potentially hamstrung when we have to revisit the whole āyour device is working to 8 channels, your gateway only listens on oneā explanation.
As some of us are exploring low cost concentrator cards combined with PF & BS code for the ESP32, a super low cost gateway that is relatively DIYāable could be on the horizon in the near future. But the incentive to do that RnD will be entirely destroyed if SCPF come back in to existence.
If not @johan, maybe @adrianmares could fill us all in on what this is for?
I understand your concerns very well. I had the same.
This is an experiment together with some key ecosystem players in the ecosystem. We will only commit to support this long term if we are convinced that this grows the LoRaWAN addressable market. It should never eat into the existing market or present itself as an cheap alternative to 8 channel multi-SF gateways.
We expect that only 30% of LoRa connected devices are using LoRaWAN. For each connected device, my guess is that thereās one ādisconnectedā device, i.e. the LoRa transceiver is in there but it is not used for anything.
With that in mind, thereās a potential of 85% LoRa devices that can either be turned into an end device or, if thereās another backhaul, a gateway, with a simple software update.
Also, a SX1302 or SX1303 based design is cost, power and space prohibitive to embed in most products and requires a non negligible driver in the host MCU.
The way I envision this going forward, is that this becomes standardized or recommended through the LoRa Alliance. It should only use SF5 or SF6 to ensure very short time-on-air and minimize chance of collisions. Also, Iām strongly advocating for adding a secondary channel that is used for data transmission (like 869.525) and that 868.1 is only used for device activation.
Ah, OK, make use of unused resources, good for the planet and perpetuates the most important rule for standardisation. Hopefully the LNS will enforce the channel & DR rates to prevent a huge proliferation of devices that flood just one channel. Or perhaps have the data channel any one of the eight and hopefully the installer will distribute the channel use on deployment.
This is what I do with point to point with channels for āhelloā, scheduled uplinks (co-ordinated via devices RTC) and āhelpā - lost contact with āgatewayā - the Dragino OLG02 makes for a nice platform for this - two radios - one of which can be a LoRaWAN device so is effectively a LoRa to LoRaWAN relay - or just have one radio for housekeeping and one for receiving uplinks. RadioLib is taking this further as it is super easy to save a session, swap in to LoRa only mode and then back to LW.
If you care to share more of the details, we can prototype / test.
May-be a stupid question, but why not use a frequency like 867.1 instead of one of the LoRaWAN ācoreā frequencies? That way transmissions on SF7-SF12 wonāt interfere with regular LoRaWAN join requests. Or will the other parties ensure only SF5 and SF6 can be used so there wonāt be any issues? (Of course once this feature is available people with older chipset will want to use it as well and I see SF7-SF12 appearing on the horizon already)
Yes, that would be the idea, and that is the need for the secondary channel. 868.1 MHz would be just to capture the join-request and send the join-accept with a CFList containing the actual data frequency. With a MAC command, 868.1 MHz would then be disabled.
The reason is that this needs to work with LoRaWAN end devices. Activation will take a while for the end device to randomly hit the right frequency for the join-request with the right data rate, but from then on the Network Server will disable the other channels and a static ADR profile ensures that the end device uses one data rate. Non-LoRaWAN compliancy is the main downside of Relay: it needs the end device that is behind a Relay to be aware of Relay and use RX3.
When using SF5 and SF6 for the data channel, there will need to be an update for the end device. However, it looks like SF5 and SF6 will become part of the LoRaWAN Regional Parameters for EU868 and other regions, so steering devices connected through a two channel gateway to SF5 and SF6 will still be compliant.
And indeed, if there is an 8 channel gateway in sight, MAC commands will enable all 8 channels and ADR.
Speaking for a friend, because Iād not do that sort of source code, but there was some good results with using CAD on the SCPF firmware - some reduction in sensitivity but may allow for the Faux-Gateway to listen on more than one DR for the join.
TR007 is pretty clear on join retries but I suspect that only LoRaMAC-node and successors do that properly apart from the few of us that add it on to the other stacks that are around. I suspect that a very clear very large set of caveats will need to be in the docs for those that hope this will lead to some automatic cost reduction.
With the join on one channel and then the response switches the device to another channel a two channel gateway will need two radios - if thereās just one with some switching back & forth thatās going to increase the join time for devices quite considerably. This then makes the recycling of unused / redundant radios somewhat moot, so will there be a new sort of gateway on offer?
I suspect that the spec is very much work in progress, as before, would be happy to participate, there are plenty of use cases where there are only a handful of devices needed making the use of a full gateway somewhat overkill.
That would only make economic sense if no (or almost no) maintenance effort is involved. Given current component cost gateways are the equivalent of two or three hours of a European workers cost (not saying that person takes that amount home)
Given the issues that will be popping up due to reduced channel availability with regular LoRaWAN end devices I seriously doubt this will be economically viable.
it somehow relates to relay devices.
. Hopefully the LNS will enforce the channel & DR rates to prevent a huge proliferation of devices that flood just one channel. Or perhaps have the data channel any one of the eight and hopefully the installer will distribute the channel use on deployment.