Has anyone used the NTN (Non-Terrestrial Networks) feature on the nRF9151? I’d love to hear about your experience or any challenges you’ve encountered.
iMX RT1011 Nano Kit can run CircuitPython which allows you to access hardware-specific functionality and peripherals in the popular Python programming language. With CircuitPython, there are no upfront desktop downloads needed. Once you get your board set up, open any text editor, and start editing code. It's that simple.
The Zephyr Project is a Linux Foundation hosted Collaboration Project. It’s an open-source collaborative effort uniting developers and users in building a best-in-class small, scalable real⁃time operating system (RTOS) optimized for resource-constrained devices, across multiple architectures.
No it is not, IMO. These devices are only ever usefull if you have unencrypted connections, with peripherals with static addresses. Add either random addresses or encryption and you won't have any success while debugging. So this tools are not usefull for 99% of peripherals you see around.
These cheap tools can only operate on 1 frequency at a time. BLE Advertisments are done one 3 channels (37,38,39), you have to listen to all of them to get the init of the connection. With this cheap devices you have 66% you miss some parts of this and thus fail to follow the connection and encryption on the remaining 36 channel (BLE does dynamic channel hopping, the channel list is exchanged within the connection).
Plus with only 1 channel, it will sooner or later fail to follow the connection and this is usually just before you could repro the issue at hand.
Believe me if you want to do anything serious you have to invest some money. Up to BLE 4.2 i would suggest https://fte.com/products/bpalowenergy.aspx which comes around 1000€. There is so no follow up for 5.0 (which more and more devices have now) so I have no suggestion there (unless you want to invest 10.000+++)
Very much depends on what you're trying to do... In my case I wanted to examine the raw traffic between two devices that I had written software for and had full control over. I found it worked just fine as the debug version of the code doesn't implement any of the ble security features. Also had no issues using the dongle to examine ble 5.x traffic.
Yes thats true, but even if I have access to the device firmware, which I usually do, so I can build an unecrpyted version and this usually leads to the problem not being reproducible or showing differently...
Anyway I want to reproduce the problem as close to production fw as possible. So via our time/effort calculation, spending some money on a multichannel sniffer was surely worth it.
Great note, didn't think of this limitation when using the dongle previously.
One question though, doesn't the sender transmit advertisements sequentially on all of the broadcast channels? So at least for BLE advertisements, they should all appear on the advertisement channel you're listening on - even if that's just one of them?
This is true, but the connection request only comes on one channel.
The sniffer can be set up to follow an advertiser though, which makes it jump to the next channel in the sequence as soon as the time window for sending a connection request after the advertisment is gone. It picks up connection requests virtually every time in this mode.
Both this and encrypted communication interpretation works a lot better than the commenter above you claims. They've either not tried this sniffer, and are only making claims based on assumptions, or they haven't learned how to use it properly.
It's definitely not as good as commercial sniffer hardware, but it's perfectly fine 90% of the time, and the price is two to three orders of magnitude lower.
nRF52840 MDK USB Dongle is a small, low-cost USB Dongle that supports Bluetooth 5.4, Bluetooth mesh, Thread, Zigbee, 802.15.4, ANT and 2.4 GHz proprietary protocols. It's shipped with the UF2 Bootloader, supports Bluetooth LE/802.15.4 packet sniffer with Wireshark, and has PCBA and w/Case options to meet various scenarios.
nRF52840 Connect Kit is an open-source prototyping kit designed for connected projects. It is built using the nRF52840 SoC, which has protocol support for Bluetooth LE, Bluetooth mesh, Thread, Zigbee, 802.15.4, ANT and 2.4 GHz proprietary stacks. It provides Arm TrustZone® CryptoCell cryptographic unit as well as numerous peripherals such as USB 2.0, NFC-A, GPIO, UART, SPI, TWI, PDM, I2S, QSPI, PWM, ADC, QDEC to support a wide range of applications.
Particle uses (used?) thread for its local mesh network stuff. When I worked there, one complaint that was commonly fielded was it’s presence on the already crowded ISM band (2.4ghz) and that it has a very limited range.
Zigbee suffers from some of this but the protocol is much lighter and payloads smaller, which means the MCU can spend more CPU time and energy decoding messages. If we can get a chip that combines cellular with Bluetooth and LoRa, that would be a killer IoT platform.
I miss Particle's mesh support. It worked great for me in my tiny environment. I tried to get a thread border router running using zephyr on a xenon with the ethernet featherwing, but couldn't get it working.
The Ethernet featherwing was tricky to get working in isolation, I can’t remmeber exactly what is was, but I recall there being some workaround in their Device OS firmware that is (or at least at the time was) open source.
The mesh network stuff was cool but suffered from a strange internal product decisions that made it useless for most applications.
First off, it was not created with a specific customer in mind. Most customers using IoT platforms want cellular connectivity, to allow for zero-setup on the customer or installer-side, and the ability to push OTA firmware updates. Mesh also used a Thread which was not super useful at the time. The vision was that you would be able to have a local network with one or more redundant gateways that ingress and egress of data through a few links.
This created another problem: monetization. In the gen 2 era of Particle where most customers with significant spend connected via cell network, Particle were able to charge a high margin rate and get considerable revenue as a result of their mvno business. This promise of a mesh network, where you could potentially reduce the number of internet connected devices to 10% of your original allocation, required rethinking of pricing as to capitalize on the devices that were connected to the mesh network but not acting as a gateway. What they did next destroyed any chance at widespread adoption. They created the most convoluted pricing systems where they were directly charging fees for a mesh connected device to be connected at all, as well as per network. Particle, whose OTA product famously worked extremely well coupled with a generous free tier (for device management) and that was easy to understand, decided to go generally available with a crippled mesh product, no customers for it, and extremely hard-to-understand pricing. Developers originally flocked to them because they could be certain of the service and features of each tier and that it just worked very well, but they destroyed trust with developers who were the genesis of most of their inbound leads.
What they should have done was to launch the products with a mesh communication library and charged for the gateways, using one pricing model if it was a stand-alone device and an upgraded one that would allow it to route mesh traffic through the internet. Oh, they also should have fucking gone with LoRa just like everyone was asking because 2.4Ghz at its tiny power is just outside of range of anything actually useful for the customers who actually wanted mesh networks
There is space another mesh product that is sanely designed and priced reasonably. I can’t see it coming from Particle, however. If anyone wants to start this, hit me up - my contact info is in my profile.
Has anyone used the NTN (Non-Terrestrial Networks) feature on the nRF9151? I’d love to hear about your experience or any challenges you’ve encountered.