Technology for wireless

Connecting devices to IoT via wireless mesh networks


  • Is there any way to bond the Node without a button press?

    Classical/legacy bonding process must somehow be initiated at the Node side. If the button cannot be used for some reason, another „event“ must be used. Because the Node is not bonded, it is not a part of the network yet and therefore no network command is usable to start bonding. One possibility is to connect to the Node in the DSM (DPA Service Mode) using the CATS tool and press the Bond button at IQRF IDE. Or you can implement you own secure peer-to-peer “Bonding command” at the Reset event in your Costom DPA Handler, etc.
  • What is the maximal number of devices in a single network?

    240 (one Coordinator and up to 239 Nodes). If more devices are requested, it is possible to use more lightweight networks rather than a huge one, which even brings significant advantages. Independent networks can run at different RF channels which brings higher throughput. Huge networks require huge maintenance and cause problems in case of failures (especially the Coordinator malfunction).
  • Is it possible to mix various TR types in a single network?

    All transceivers must use the same RF modulation. Therefore it is not possible to mix e.g. the TR-5xD and TR-7xD families. The transceiver series can be different. E.g., TR-72D and TR-76D series can be mixed. But the IQRF OS and DPA versions must be the same for all TRs in the whole network.
  • How to create a network?

    See video Network setup, IQRF DPA Framework Technical guide, chapter DPA in practice/Network and IQRF US User's guide, chapter IQMESH in practice.
  • Are asynchronous RF packets possible in IQMESH?

    Ready-to-use DPA plug-ins themselves do not support asynchronous packets (not initiated by the Coordinator). However, RF communication initiated by a (discovered) Node can be implemented in the Custom DPA handler. See example CustomDpaHandler-AsyncRequest.c.

    But there is a risk of collisions (as the communication is not managed by the Coordinator). That is why asynchronous packets are hardly recommended.
  • Are IQRF packets encrypted?

    From IQRF OS v4.00D, AES-128 encryption is implemented on TR-7xD transceivers. Networking (IQMESH only) communication is always automatically encrypted. Moreover, User encryption can be optionally added (for networking as well as non-networking communication).
  • Is it possible to use IQMESH for non-static networks?

    Although IQRF is focused especially on static networks typical for telemetry, Smart House, street lighting etc., moving nodes are also allowed. Such Nodes must have routing disabled in TR configuration. Thus, they will not be discovered (and no VRNs will be assigned to them), but if they are in a direct range of the Coordinator or any router, they will be able to communicate. See IQRF DPA Framework Technical guide, chapter Network employment.

    IQMESH allows even moving routers but Discovery must be performed after every change in routing backbone topology.
  • What is the RF packet propagation time in the IQMESH network?

    Basically, it depends on the timeslot length (packet length), number of hops (network topology, number of routing Nodes) and RF mode (STD/LP). The timeslot length is set automatically by the Coordinator according to the packet length (number of user bytes) and used RF mode (STD: 40 - 60 ms, LP: 80 - 110 ms). The total packet propagation time can be simply calculated: timeslot length x number of hops. But there are some other parameters which should be taken into account. For details see IQRF DPA Framework - Technical guide, chapter DPA Confirmation.
  • What to do when a network device failed?

    If a device is definitely broken, it should be replaced as follows:
    • If it is a non-routing Node, just a connection with this one is lost. There are two ways of replacement:
      • From the Backup: IQRF IDE supports the possibility to create a backup of all network data necessary to replace a TR with another one. This should be performed before the device fails. Backup data is stored as a file with extension IQRFBKP and can be restored in a new TR. The restored TR can be replaced piece-to-piece without any other actions needed.
      • Without the Backup: The failed device must be unbonded at the Coordinator and the replaced device must be bonded.
    • If it is a routing device, it depends on the topology (number of redundant neighboring paths). A part of the network may get inaccessible. In general, to avoid blackouts due to such local failures, the network should be designed with sufficient number of redundant paths. See routing animation. To check the results, you can perform a new Discovery and then ping potentially affected devices. But the best way is to replace the broken device (similarly as for non-routing Node). In any case, new Discovery is recommended after every change in routing structure.
    • If it is a Coordinator, the communication in the whole network is completely disabled until the device is replaced. There are two ways of replacement:
      • From the Backup: When having the Coordinator Backup performed before the device fails, the restoring is transparent piece-to-piece like for an end Node. But the Discovery should be performed thereafter.
      • Without the Backup: The whole network must be created from scratch, all end devices must be unbonded and then bonded again and the Discovery must be performed thereafter.
    See IQRF IDE Help – IQMESH Network Manager/Control/Backup.
  • When to perform Discovery?

    Discovery is an “installation” procedure by its nature. It should be performed after a new network is created or after any change in routing topology (adding, removing or replacing a routing device, changing obstacles etc.). Discovery relates to the Coordinator and routing devices only (but not the non-routing end Nodes).