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.
Just wondering have you tried the Multitech xDot? Seems to meet all your criteria.
STM32L151CB-A
The 152 is supported in mbed, 151 is Almost the same. So, Technically it is possible, but someone has to do it.
Another option is using I-CUBE-LRWAN. They use the semtech/stackforce LoRaWAN stack.
http://www.st.com/en/embedded-software/i-cube-lrwan.html
Technically yes, but the price is over US$50.
1 Like
I don’t see open source access for the LoRaWAN stack on the mDot. Don’t know if People are interested in this, but having Control allowed us to build a Class C device that can switch to Class A when needed.
It’s actually just $16.30
http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=64707
and last quote I got from the local distributor
5 x MTXDOT-EU1-A00-1 868 MHz LoRa Module UFL/TRC £ 17.50ea
Let’s keep this thread nrf5x-specific and move other platforms suggestion to separate thread. Moderator may suggest existing thread if any.
I was trying to understand the motivation for using mbed instead of Nordic’s much more up-to-date GCC toolchain, especially when it’s looking like the components would be quite tied to the nrf51 platform.