Not satisfied with RN2483 (bulky, taking 50uA sleeping) I am thinking about writing lightweight LoRaWAN stack (class A1/A2) for nordic bluetooth radios and SX1276/RFM95. Initialy I started playing with LMIC for mbed but found it incompatible with each other mainly because how they do “cooperative” multitasking in main control loops - both softdevice (BLE) and lmic have own loops. Moreover, AES software implementation is too heavy for nRF51 RAM wasting embeded AES hardware on chip. With nRF5x and SX1276 we can easily get below 10uA, depending on BLE broadcasting interval.
Anyway, if it is worth the effort, would it be interesting for others to have both radios driven by single SoC and programmed with mbed?
Thanks,
Peter
Have you looked into the Laird RM1XX module?
It’s certified LoRa + Bluetooth.
I am planning to try the same thing. Waiting for my Nordic BLE board to arrive.
Are you using a github repository?
Great module but comes without software. I mean their weird Basic can not be considered a software for anything beyond one-off weekend project.
GitHub most likely. I am just doing feasibility study now, but so far everything looks good. Small obstacle about AES decryption will have to be in software since nordics chip can just encrypt in hw. Right now, I am running on my custom hardware, but for development anything from BLE nano to nordics DK will do. 
I think that’s no problem! In LoRaWan only the AES encryption algorighm is necessary on a node. If I remember correctly, the network encrypts messages by applying AES decryption to it. Decryption on a node can then be done by applying AES encryption to the message…
I don’t agree 
Well, as a class A1 node it is uplink only (encrypts), but in order to attempt be compliant there are MAC messages which are downlink and if content of the mac message is in payload, we need to decrypt to interpret it correctly. AES decrypt is a bit different operation although it is “inverted” to encrypt. You won’t get decrypted message if you run encrypt on already encrypted message. But anyway, we can get away with software decrypt.
When the network sends a message to a node it actually decrypts the plaintext using the secret key before sending the message!
Because encrypt(decrypt(plaintext,key),key) == plaintext for AES this works.
There is no need for AES decrypt on a node for any LoRaWan message. The node uses encrypt for all messages that it sends, and uses encrypt to decipher all incoming messages…
2 Likes
You are right, just checked 
Decrypt on plaintext results in encrypted string which can be “decrypted” with encrypt operation. Clever use of symmetric cipher property. This way it is possible to leverage simple hardware encryption engines in SoC. Great point, thanks ! 
The alternative is to use nRF loop to control lmic and get rid of LMIC ‘runtime os’. The runtime functions are limited enough to be easily adapted to other environments.
I wasn’t successfull to release softdevice mbed waitForEvent() method on time on lmic events, looks like they do not use tickers/timeouts to schedule jobs. As a result rx windows get missed.
I guess not, but just in case it helps, in another topic, @matthijs suggested:
LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);</pre>
This tells LMIC to make the receive windows bigger, in case your clock is 1% faster or slower.
(And as for encrypting: see the specifications: “The network server uses an AES decrypt operation in ECB mode to encrypt the join-accept message so that the end-device can use an AES encrypt operation to decrypt the message. This way an end-device only has to implement AES encrypt but not AES decrypt.”)
About AES, that’s absolutely true. Now I have answer why they implemented only one-way AES encoding hardware on chip.
Why do you want to use a single SoC to Control two radios? Only lower BOM cost?
Our LoRaWAN module (STM32 cortex M3 + SX1272) consumes 1.6uA in sleep, and will wake-up on interrupts or alarm timer. Just combine your BLE SoC with an ultra-low power LoRa module and you have the Most reliable, low power solution.
1 Like
The RM186 module which is almost exactly what’s being proposed here (nRF51 running Semtech/Stackforce LoRaWAN stack + SX1276) does:
standby mode (automatic): 4.2uA
deep sleep (no RAM retention and requires reset but can wake from GPIO pin change): 750 nA
this is using smartBASIC (which I understand it’s not to everyone’s liking, but works fine for me)
1 Like
Because we can! Seriously, your module looks very nice. If it is below US$25 in small qty, and possible to program in C/C++, has LoRaWAN stack and supported by mbed then please, take my money
1 Like
semtech/stackforce LoRaWAN stack in C is supported. Why would you want to have mbed support? Can you add your own board/module to the mbed eco-system? Last time I checked I didn’t see how to add it…
Yes you can join mbed as a partner:
If you need more direct contacts please msg me.
What STM32 is there? Many are already supported by mbed.