From what I understand the LoRaWAN stack is still limited to a handful of functions: init, join, send and RX. This is to me a critically limiting, from my experience in LoRaWAN you either have very deep control of your stack or you going to have a very bad time when deploying hundreds of devices onto public networks. The idealised world where everything meets the spec doesn’t exist and even the specs itself falls over quite quickly - just have devices start moving between networks and using ADR…
Can’t see any way to push TX power beyond 14dBm for example (yes I am aware of legal restrictions) or change the default frequencies. For example I wouldn’t know how to CE certify this module without the ability to transmit at fixed frequencies.
Is is possible to not use your binary closed source stack running on the CM0 and talk to the LoRa chip directly? Are you able to list the internal connections between the PSoC6, SX1261 - maybe TCXO?
Is is possible to not use your binary closed source stack running on the CM0 and talk to the LoRa chip directly? Are you able to list the internal connections between the PSoC6, SX1261 - maybe TCXO?
Yes, with version A of our module, you can use our LoRaWAN functions and make communication to the Semtech LoRa Chip, but it can not be LoRa Alliance certified from our side.
In addition, with the “blank” version, you can make your own LoRa/LoRaWAN communication.
There are multiple versions of our Onethinx Core LoRaWAN® module (detailed list in datasheet on page 5). The versions are as follows:
S - Standard Secure version(secure certified stack, secure boot)
P - PSA Certified version (PSA certification, secure certified stack, secure boot)
A - “Configurable” LoRaWAN stack (stack is locked down and Onethinx LoRaWAN functions can be used, but M4 can access the Semtech SX1261 radio chip, not LoRa Alliance certified, secure boot)
blank - Open (stack-less) version. Both core come open and configurable, without the stack programmed. User can make their own communication.
The Onethinx Core LoRaWAN® module comes CE certificied. Due to legal restrictions, the TX power can not go beyond 14 dBm.
We are working on a set of additional API commands to enhance flexibility for the user, for example Sleep, Hibernate, Flashwrites, Testmode and so on.
We like to learn from you how you propose a viable certification setup, for example: would you need to be able to set a constant carrier on the frequency of choice or would you prefer an automatic ‘testing algorithm’ on certain frequencies with certain LoRa packets.
We worked on randomized back-off time-spectrum algorithm. This means we optimized the join frequency / datarate / interval scheme from an initially maximum allowed transmit requests gradually decreased to a transmit dutycyle of 0.01% after 11 hours. While the LoRaWAN specification defines 3 retransmission back-off boundaries, the OTX-18 devices will follow a gradual decreasing dutycycle slope in order to mainain optimal time-spectrum utilization.
A few screenshots of our simulations (this is a total timeframe of 36 hours):
