That is correct. There are simply too many factors that influence the range and, of course, the modulation techniques are also part of this. It does make a difference whether I use QPSK or the more stable BPSK modulation, for example. But then I have limitations in terms of speed. In addition, things like the utilisation of the radio channels also play a role. We have only extensively tested the range of IEEE 802.15.4 modules and it was very difficult to find suitable test routes. And the question will always arise as to the area of application in which the radio modules are used. City, country, sea, buildings, high data rate, low data rate. There are simply too many factors to make generalised statements about range. Ultimately, users also utilise technologies that they can easily implement and that are available. BLE and especially BLE Mesh are also used, although these are usually not the best technologies. The tests we did with IEEE 802.15.4 devices fit the theory I discussed, but these are only small samples. The theory is good and useful for an initial estimation of range, but in a specific application the only option is usually to test. Nordic Semiconductor has an amplifier module for the nrf52840 and has also achieved ranges of over 1km with BLE. I have not yet been able to check this and I would also be interested to know whether the same range can be achieved with Thread or ZigBee using the same module, which is also capable of IEEE 802.15.4. In practice, however, the range will be mostly much shorter and, of course, the power consumption will be correspondingly higher.

You are welcome. Thank you for your positive feedback.

You are welcome. No, the book does not go into detail about the SMP. However, CBC-MAC and CTR are explained in more detail in the chapter about IEEE 802.15.4.

Yes, it can sometimes be a bit frustrating, especially if something has been changed in the basic settings during updates. What error is occurring? Perhaps someone can help.

You are welcome. Book is already available: WSN and IoT: Basics, protocols and applications a.co/d/iHExiPG

@wsniot We need more detail how to use zephyr

Hey, did you find a solution to your Problem? I'm currently trying to communicate with the DWM1000 via the DWM1001-dev board

You can use the function sprintf for example to generate a Json-String: static uint8_t buf[20]; static int buf_length; static int counter=0; while (1) { k_msleep(1000); buf_length= sprintf(buf, "{\"Counter: %d ", counter\"}); counter++; }

Not really. You could try to solder a bigger switch to reset on the downer side and GND. Or using a J-Link programmer, but also not more comfortable. Or you are just using another dongle like from Nordic or MDK instead with the ner52840. MDK support also uf2 Bootloader as i remember.

Thanks for the nice feedback. Yes, should be no problem. The access to the I2C-bus is not exclusive. At the end the driver uses the same instruction like writing it manually with the Zephyr functions.

You are probably missing something. The stick is an IEEE 802.15.4 sniffer. If you have set the correct channel, you will also receive ZigBee packets since IEEE 802.15.4 are the two downer layer from ZigBee. Is your ZigBee network encrypted? Have you set the network key in Wireshark? At least you should see the IEEE 802.15.4 part from the ZigBee-pakets