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…
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.
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.”)
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.
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
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…
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
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.
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.
Good point. Well, imho mbed is C++ platform, has nice BLE API. For moderate complexity applications greatly simplifies code. Having compared simple BLE app, access to peripheral interfaces (SPI, I2C, GPIO) is greatly simplified when you compared similar C code from SDK.