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.
Now, this is a very interesting initiative! We have many in-house boards with NRF51/52 conencted to RFM95 - @petekmet if you are interested we can supply a board to you if you can use the puse Nordic SDK and not the mBED UI for this development (maco@blava.net) - do you already have any code avail?
Did you look at the Adafruit Lora Feather? Nice and small, full LoraWAN stack available, has reasonably low sleep current but you can tweek the hardware a bit to get even lower.
I have both the M0 and the 32U4 versions working with the Dutch Lora network, and I quite like this platform for simple applications.