Category Archives: General

Presentations and photos from the IQRF Summit 2019

Photos and presentations from the IQRF Summit 2019 in one place. Remind yourself the presentations and view all the photos.

Day 1

IQRF AllianceIoT Deployment = nightmare Not any more!
IQRF TechTowards IQRF® open standard
IQRF AllianceMaking deployment easier with new DPA features
IQRF TechIQRF Gateway
AAEON EuropeArtificial Intelligence on the Edge
LogimicOpen Edge Gateway, Abstraction layer for IQRF gateways
RehiveTechPIXLA
FM ConwayCompany introduction
OmniolyticsCommercial Poultry in South Africa, Water and Air quality monitoring & analysis
České RadiokomunikaceAddressing strategic segments, Joint-approach for Complex use-cases
VFNIoT deployment in hospital / Solution architecture
tcp / MICRORISCRadar & IQRF based car & people counters

Day 2

MyMightI measure, therefore I am. What next?
4IOTECHIQRF Interoperability
Wroclaw University of Science and TechnologyOpportunities and challenges for teaching of smart wireless technologies
Austyn InternationalCompany introduction
Findlay IrvineEarthworks Monitoring System
ProtronixInternal Air Quality sensors
HARDWARIOEASY and AFFORDABLE i4.0 pilots
VŠB-TUODevelopment of Monitoring Systems Based on IQRF Technology at the Department of Cybernetics and Biomedical Engineering
MAKERSCompany introduction

Gallery

- - -

Quick start with DPA without programming

To learn the DPA usage, development set DS-DPA-02 can be used.

Preparation

All SW, plug-ins, documentation etc. are available on the flash disk and on www.iqrf.org/support/download.

  • Prepare TR-72DATs with OS 4.03D as follows: 5 pcs as the Nodes and 1 pc as the Coordinator.
  • Prepare 4 (5) pieces of DK-EVAL-04A and 1 (2) piece(s) of CK-USB-04A.
  • Install the latest IQRF IDE.
  • Launch IQRF IDE and open Project DPA-demo.iqrfprj from IQRF Startup package. All necessary files and macros are included in the Project.

Creating Nodes

A. Plug a TR transceiver in CK-USB-04A, select the DPA-Node-STD-7xD*.iqrf file in Project window and click the Upload Plug-ins button on the Toolbar (or use the F5 key). The plug-in should be uploaded then.

B. Double-click on the configuration file DPA-config.xml in IDE Project window to open the TR Configuration window.

Make the following settings:

  • Select the desired RF channel (RF Channel A) in the OS tab. Nodes will inherit the value from the Coordinator during bonding.
  • Select the desired RX filter in the DPA tab.
    • For short range testing (within the room) select 15.
    • For operating in real conditions select 5.
  • Select the desired Access Password in the Security tab. See IQRF OS User’s guide, chapter Access encryption.

This setting must be the same in the entire network!
Do not change other parameters for now.
Save the configuration into the TR by button Upload.

C. Plug this TR into the DK-EVAL-04A kit.
Repeat steps A to C for all Nodes.

Creating the Coordinator
Use the same procedure but with the DPA-Coordinator-SPI-7xD.iqrf and DPA-config.xml files. Then leave the TR plugged in CK-USB-04A.

Warning: If you use a stronger RX filter during the development (e.g. on the table), do not forget to reduce it then in final
application (in the real environment).

Examples

A. Pop-up menu
For the simplest checking, a command to switch the red LED On / Off on selected Node can be immediately sent by clicking the left mouse button on the symbol of the given
Node in the map.
The command currently selected in the DPA Test – Data to Send window can be executed by the right mouse button click on the symbol of given Node in the map and by selecting the Send Packet from DPA Test item. NADR is set automatically according to the selected Node.

B. Macros
Click on the particular macro and PNUM, PCMD, HWPID and PDATA are automatically filled in. Then select Node Address in the NADR box (for Broadcast use address 0xFF) and click the Send button.

  • Go to the LED macros and click on macro Set LEDR on. To switch all LEDs on, fill in 0xFF in NADR and click Send button.
  • Use various macros and Node addresses to test the functionality.

C. DPA packet arranged manually
To get a better understanding of the DPA packet structure, you can also fill in the DPA packet manually. By clicking the right mouse button to the area for selecting NADR, PNUM, PCMD or HWPID, menu Predefined Addresses, Predefined Peripherals, Predefined Commands or Predefined HWPIDs is displayed. These lists allow to select items defined by the DPA specification and directly arrange the packet.

  • From menu Predefined Addresses select Broadcast or directly specify the address of given Node.
  • From menu Predefined Peripherals select the LEDR peripheral.
  • From menu Predefined Commands select the Set on command.
  • From menu Predefined HWP select the To All HWP item.
  • Click the Send button.

Test other peripherals and commands in the same way.

IQRF IDE usage

IQRF IDE environment integrates all SW tools needed for application development (and a lot of utilities for the following
control, maintenance and service). It is project oriented. Thus, a Project containing necessary definitions and files must be
specified first. Default Projects are available for immediate start. Project definition files have the .IQRFPRJ extension. See
IQRF IDE Help for details.

 

Programming and uploading procedure

Programming – a creation of a user-specific IQRF application program.

  • Editing – creation/modification of source code in C language.
  • Compilation – compiling the source program from C language to .HEX machine code.
  • Upload – uploading the code into the TR:
    • TR Configuration
    • Application code
      • Either a DPA plug-in, optionally with a Custom DPA Handler
      • Or a user-specific application.

Wireless upload (RFPGM) is also possible – see IQRF OS User’s guide, Appendix RFPGM and IQRF OS Reference guide, function RFPGM.

Other development, test and service utilities

  • Debug – allows to stop program execution and watch internal variables (break, watch and continue).
  • Terminal – utility to control serial communication.
  • Packet inspector decoding and interpreting packets logged in Terminal Log window.
  • Network management, visualization, testing, scanner, QR Code generator, …

IQRF development software

IQRF IDE
Integrated development environment by IQRF Tech to create, debug and control IQRF applications and manage the IQRF network. Required minimal IQRF IDE version depends on IQRF OS version of given TR transceiver and possibly also on the DPA version. See IQRF IDE Release notes. The best way is to always use the latest IDE version.

USB drivers
IQRF USB devices (e.g. CK-USB-04A) primarily utilize Custom class (with VID / PID by IQRF Tech when used with IQRF devices). Several IQRF USB devices (e.g. GW-USB-06) can also (optionally) use the CDC class. (CDC is not necessary for IQRF startup.)
USB drivers implemented in current IQRF devices (e.g. CK-USB-04A or GW-USB-06 with up-to-date firmware) are by the verified publisher based on the WinUSB by Microsoft.

CC5X
C compiler for the PIC microcontrollers (by B Knudsen Data). The evaluation version (included in the IQRF Startup package) is free. The compiler is not necessary when using DPA plug-ins without Custom DPA Handler creation or modification.

Text editor
For source code creation and modification, any external editor being able to save a plain ASCII text, e.g. Windows Notepad can be used. Notepad++ (a great source code editor, free by GPL License) is very recommended. Download it from www.notepad-plus-plus.org.

Quick start with the IQRF wireless technology

There are also video tutorials available on IQRF Youtube channel.

 

What do you need to start?

● TR-72DAT IQRF transceiver
● CK-USB-04A IQRF programmer and debugger
● DK-EVAL-04A Universal portable development kit for TR transceivers
● Micro USB cable

What are TR transceivers?

RF transceivers TR-72DA fits into SIM connector. They are fully programmable under IQRF OS operating system and allow to utilize the DPA approach for applications without programming. What is a Programmer?

To upload application codes into TRs and configure TR parameters, the CK-USB-04A kit is intended.

What is an evaluation kit?

TRs (with application functionality codes uploaded using the programmer in advance) should be hosted in portable DK-EVAL-04A kits.

Why you need a USB device?

TRs can also be hosted by CK-USB-04A connected to PC via USB. It enables to control the TR application from PC, first of all by the IQRF IDE powerful tools for communication, testing, network management and visualization. This is advantageous, especially for the network Coordinator.

 

Typical usage of kits and the first demonstration

RF link check
● Unpack two TR transceivers from the development set. Do not make any changes in SW inside.
● Plug the first TR into one DK-EVAL-04A kit and switch the power on by the jumper. Every transmitted RF packet is
indicated by a green LED flash.
● Plug the second TR into another DK-EVAL-04A kit and switch the power on by the jumper. Every transmitted RF packet
is indicated by a green LED flash.
● Moreover, transmitted packets are started to be received by the counterparts. Every received RF packet is indicated by
the red LED flash.
● Thus, a bidirectional RF link is automatically established between the kits in this way. The red LED flashing indicates the RF
connection.
● You can move the kits and check RF link with respect to the given environment.

Note: This link works plug-and-play thanks to the E09-LINK program which is uploaded in all TR transceivers in development sets delivered from the factory. It is one of the Basic examples from the Startup package and can be uploaded whenever needed later on.

 

Point-to-point

The arrangement with two DK-EVAL-04A kits see above.
The arrangement with CK-USB-04A:

See Basic examples E01-TX, E02-RX, … in IQRF Startup Package.

 

Network

The only way to implement an IQMESH network is the DPA approach. For a quick startup, it is recommended to apply the ready-to-use DPA plug-ins without Custom DPA Handlers.

 

Without programming

Higher level, running under DPA and utilizing DPA plug-ins, which are ready-to-use SW plug-ins enabling communication in Mesh networks with no need for programming. TR is not controlled by an application program but from the control system via SPI or UART by the DPA protocol. All resources of the addressed device are accessed via sending requests and receiving responses. Requested functionality is achieved without programming. However, even this approach allows user-specific adapting by optional Custom DPA Handler programmable in C language.

The DPA framework solves networking transparently. Just the addressees must be specified and then the packets are delivered automatically. This, together with the approach with no programming needed makes TRs very easy to implement. The entire network traffic is based on simple commands only specifying where and what to perform.

 

Programming in C

Lower level, running directly under IQRF OS. The functionality is given by the application program in C language.

How to implement FRC and IQRF standard

IQRF standard

1. What is FRC

Patented method how to send a command from the Coordinator to all or selected Nodes and receive answer (including data collected by individual Nodes) in outstandingly short time.

2. Format of FRC Command

 

NADR

PNUM

PCMD

HWPID

PDATA

where
               
NADR     = 0x0000               Coordinator address

               PNUM    = 0x0D                   Predefined Peripherals – FRC

               PCMD     = 0x00                    Command Send

               HWPID   = 0xFFFF

 

PDATA including these information’s:            

PDATA[0]

PDATA[1]

PDATA[2]

PDATA[3]

_PCMD [type of FRC]

[type of peripherals]

[typ of sensors]

[index]

DataOutBeforeResponseFRC[0]

DataOutBeforeResponseFRC[1]

DataOutBeforeResponseFRC[2]

 

PDATA[0]                                                                       type of FRC

0x10       2  bit                      FRC_STD_SENSORS_BIT                      responseFRCvalue.1 =        value (1 bit) 

0x90       1 byte                     FRC_STD_SENSORS_1B                       responseFRCvalue     =          value
(1 byte)

0xE0       2 bytes                   FRC_STD_SENSORS_2B                       responseFRCvalue2B =       value (2 byte)

0xF9       4 bytes                   FRC_STD_SENSORS_4B                       responseFRCvalue4B =       value (4 byte)

 

PDATA[1]  =  DataOutBeforeResponseFRC[0]               type of peripheral

0x5E                                       PNUM_STD_SENSORS

 

PDATA[2]  =  DataOutBeforeResponseFRC[1]               typ of sensor, f.e.:

0x01       2 bytes                   STD_SENSOR_TYPE_TEMPERATURE                               FRC standard:  1byte, 2byte

0x04       2 bytes                   STD_SENSOR_TYPE_EXTRA_LOW_VOLTAGE                 FRC standard:  2byte

0x81       1 byte                     STD_SENSOR_TYPE_BINARYDATA7                                FRC standard:  2-bits-1byte

 

PDATA[3]  =  DataOutBeforeResponseFRC[2]               index

PDATA [3]

bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

bit index

sensor index

where

                bit index                – is a index of bit, which asking by FRC, used in 2-bit FRC

                sensor index         – is a index of sensor if I have few sensors of the same type, f.e. 3x temperature

More info:  https://www.iqrfalliance.org/techdoc_files/IQRF-StandardSensor_V015.pdf

 

3. Example: Implemented FRC and IQRF standard for types of sensors

uns16       temperature;

uns16       e_low_voltage;

uns8         binary_data;

                                                                                                //random values for test

temperature= 0x0640;                                                        // 100 °C

e_low_voltage=0x3039;                                                       // 0x3039 = 12345d = 12345mV = 12,345 V

binary_data=5;                                                                     // 00000101  position 0 = log.1, position 1 = log.0, position 2 = log.1,

 

case DpaEvent_FrcValue:

                                                                                                                                      //first part   process the FRC request

if ( DataOutBeforeResponseFRC[0] == PNUM_STD_SENSORS )                         //Check PDATA[1], if 0x5

        {

         uns8 sensorIndex = DataOutBeforeResponseFRC[2] & 0x1f;                   //save sensor index from PDATA[3]

         uns8 bitIndex = DataOutBeforeResponseFRC[2] & 0xe0;                         // save bit index from PDATA[3]

         bitIndex = bitIndex >> 5;                                                                                 // rotate 5x right

                                 

        switch ( DataOutBeforeResponseFRC[1]                                                      // Check PDATA[2], type of sensor
)                                              

           {

            default:                                                                                                         //DPA handler return false

               goto DpaHandleReturnFALSE;

 

          case 0x00:                                                                                                     //if  0x00 => type of sensor isn’t defined

               goto _KeepSensorIndex;                                                                       //save sensor index 

                                               

          case STD_SENSOR_TYPE_BINARYDATA7:                                                // 0x81

              if ( sensorIndex > 1 )                                                                              // only one sensor of this type

                   goto DpaHandleReturnFALSE;

               W = 0 + sensorIndex;

              break;

 

         case STD_SENSOR_TYPE_EXTRA_LOW_VOLTAGE:                                 // 0x04

             if ( sensorIndex > 1 )                                                                                                                     

                 goto DpaHandleReturnFALSE;

              W = 1 + sensorIndex;

           break;

 

         case STD_SENSOR_TYPE_TEMPERATURE:                                            // 0x01

              if ( sensorIndex > 1 )                                                                                                      

                   goto DpaHandleReturnFALSE;

              W = 2 + sensorIndex;

           break;

          }

       sensorIndex = W;                                                                    // new sensor index, depends on type and quantity  of sensors

       _KeepSensorIndex:        

 

                                                                                                         //second part – send the FRC answer

        switch ( _PCMD)                                                                                //Check  PDATA[0], type of FRC

            {

            default:                                                                                          //if empty => DPA handler returns false           

               goto DpaHandleReturnFALSE;                                                       

 

            case FRC_STD_SENSORS_BIT:                                                           //2-bit FRC, FRCommand 0x10

               switch ( sensorIndex )                                                                     //send answer based on index of sensor

                {

                 default:

                    gotoDpaHandleReturnFALSE;

 

                 case 0:                      

                 switch ( bitIndex)                                                                      // send answer based on index of bit position

                     {

                      default:

                         gotoDpaHandleReturnFALSE;                

 

                      case 0:                                                                                                                                                                  

                         responseFRCvalue.1 = binary_data.0;

                         break;

 

                      case 1:

                         responseFRCvalue.1 = binary_data.1;

                         break;

 

                      case 2:

                         responseFRCvalue.1 = binary_data.2;

                         break;

                  }

                     break;

               

                case 1:

                responseFRCvalue.0 = 1;                                                            // 2- bit FRC Extra_Low_Voltage not implemented

                responseFRCvalue.1 = 0;

                   break;                      

                                                                 

                case 2:

                responseFRCvalue.0 = 1;                                                            // 2- bit Temperature not implemented

                responseFRCvalue.1 = 0;

                    break;     

             }

           break;

        

         case FRC_STD_SENSORS_1B:                                                              //1- byte FRC, FRCommand 0x90

               switch ( sensorIndex )                                                                     //send answer based on index of sensor

                {

                 default:

                    goto DpaHandleReturnFALSE;

 

                 case 0:                      

                    responseFRCvalue = binary_data;                                         // return 1- byte FRC BinaryData7

                    break;

 

                 case 1:

                responseFRCvalue = 0x01;                                                         // 1- byte FRC Extra_Low_Voltage not implemented

                    break;

 

                case 2:

                                                                                                                         // Convert to the “F = ( T + 22 ) * 2 ” from 1/16 resolution

                uns16_temp = temperature + 4;                                                // Note: do rounding when /8

                responseFRCvalue = (uns8)( _temp /8 ) + 44;                           // return 1- byte FRC Temperature

                break;

                }

              break;

                                               

          case FRC_STD_SENSORS_2B:                                                                     // 2- byte FRC, FRCommand 0xE0

               switch ( sensorIndex )                                                                                                    

                {

                 default:

                    goto DpaHandleReturnFALSE;                

 

                 case 0:                      

                    responseFRCvalue2B = 0x0001;                                                       // 2- byte FRC BinaryData7 not implemented

                    break;

 

                case 1:

                 responseFRCvalue2B = e_low_voltage ^ 0x8000;                             // return 2- byte FRC Extra_Low_Voltage

                    break;

 

                 case 2:

                    responseFRCvalue2B = temperature ^ 0x8000;                            // return 2- byte FRC Temperature

                    break;

                }

              break;

            }

        }

      break;

 

4. FRC commands from example

For BinaryData7:

NADR      PNUM     PCMD     HWPID   PDATA

00.00      0D           00           FF.FF       10.5E.81.00                           return 2-bit FRC, value of bit #0

00.00      0D           00           FF.FF       10.5E.81.20                           return 2-bit FRC, value of bit #1

00.00      0D           00           FF.FF       10.5E.81.40                           return 2-bit FRC, value of bit #2

00.00      0D           00           FF.FF       90.5E.81.00                           return 1-byte FRC

00.00      0D           00           FF.FF       E0.5E.81.00                           return 2-bytes FRC  (not implemented)

 

For Extra_Low_Voltage:

NADR      PNUM     PCMD     HWPID   PDATA

00.00      0D           00           FF.FF       10.5E.04.00                           return 2-bit FRC (not implemented)

00.00      0D           00           FF.FF       90.5E.04.00                           return 1-byte FRC (not implemented)

00.00      0D           00           FF.FF       E0.5E.04.00                           return 2-byte FRC

 

For Temperature:

NADR      PNUM     PCMD     HWPID   PDATA

00.00      0D           00           FF.FF       10.5E.01.00                           return 2-bit FRC (not implemented)

00.00      0D           00           FF.FF       90.5E.01.00                           return 1-byte FRC 

00.00      0D           00           FF.FF       E0.5E.01.00                           return 2-byte FRC

Visit us at Smart Home Expo 2019

Meet us at Smart Home Expo 2019 where Šimon Chudoba is going to have a seminar on how to use the IQRF wireless technology, what is the IQRF Alliance and new features in IQRF OS 4.03D.

Smart Home is UK’s ultimate event for the evolution of automated home tech for modern day & independent living. The event will have 150 seminars by the sector’s leading visionaries, 200 world-class suppliers and interactive features.

Since the innovations are all around us in various areas of life, it is no surprise that these innovations are getting also to the area of living. Home automation and smart homes are closer than you think.

The IQRF Alliance is partnering up to the show and our CEO Šimon Chudoba will be speaking at the event!

 

When: 26th – 27th March 2019 – set a note to your calendar

WhereNEC, Birmingham, UK

- - -

 

Smart Home is really the “home” of the innovations changing the face of modern day living, taking place on the 26th & 27th March 2019 at Birmingham’s NEC.

To register for your FREE ticket and catch Šimon Chudoba’s seminar visit www.smarthometechlive.co.uk.

- - -

List of speakers

Smart Home Expo 2019 website

 

Media partners

   

IQRF development tools with 50% discount in November

Regarding the release of the new OS, the IQRF Tech offers a significant discount on basic development tools – 50%!

For discount go to IQRF.shop, where you enter the discount code:

 

IQRFNOV50

 

Discount can be applied only during November 2018!

 

Discount applies to:

 

Evaluate the unique mesh approach and all advanced
features of the IQRF® technology

- - -

- - -

- - -

Easy deployment of IQRF® with IQRF OS 4.03D

The new IQRF OS 4.03D brings many improvements to help you work with the IQRF®. These include, in particular, Smart Connect and Autonetwork V2.

Smart Connect

This is a new method of adding the Node to the IQRF network.

Properties

  • The node does not need to be within the range of the Coordinator but must be within the range of the Node that is already bonded to the network.
  • No action is required on the bonded Node side (for example, pressing a button).
  • The bonded Node needs to have neither a working channel nor an Access Password of that network set in its configuration.
  • Smart Connect is based on system communication encrypted with IBK (Individual Bonding Key). This is the unique and permanent code stored in each TR module during production.
  • For the Coordinator to add the Node to the network, it must know its IBK and MID(Module ID).

Smart Connect is implemented in DPA as the new Coordinator periphery command. HWP of a Node supports pushbutton bonding as well as Smart Connect.

In the unbonded state (the red LED flashes on the Node), the Node is in LP reception (low power consumption) and expects the system’s Smart Connect packet. If the button is pressed, Node sends the bonding/pre-bonding requests. If the button is not pressed, the Node will go to sleep after about 5 hours. This long period offers time-space for installing Nodes and running the Smart Connect process. This time change is possible in Custom DPA Handler (event BondingButton). Alternatively, sleeping can be entirely disabled by using the Stay awake when not bonded configuration parameter.

- - -

 

Testing the Smart Connect process

You can start the Smart Connect process by the Smart Connect DPA command sent to the coordinator on the Coordinator periphery. The key input parameters are the IBKand MID of the bonded Node, and the required logical address. Both IBK and MID can be detected by application or in IQRF IDE – TR Module Information (Ctrl + M).

Smart Connect command can be tested, like any DPA command, in IQRF IDE via a terminal or more user-friendly via IQMESH Network Manager.

 

Smart Connect in practice

The input parameters (IBK, MID) can be passed to the Smart Connect process using the so-called IQRF Smart Connect Code. This is an alphanumeric string where the IBKMID, and HWPID (Hardware Profile ID) of the device are encoded. This code can be generated using the IQRF Code Tool in the IQRF IDE or by a custom application based on available documentation and can be passed in various ways, e.g. using NFC, QR code, etc. The IQRF Code Tool also can also be used to generate QR code.

 

In practice, Smart Connect can look like this

  • In IQRF IDE, a QR code for each TR module (Node) is created and stuck to the device containing this TR module.
  • You place the device in the final place and read its QR code by a mobile application(such as IQRF Network Manager for Android).
  • The mobile application is linked to the IQRF Repository and therefore it can find and display information about the device (type, manufacturer, drivers …) accordingly to HWPID.
  • The mobile app will connect via API to the gateway based on the IQRF Gateway Daemon and launches Smart Connect.

IQRF Gateway Daemon v2

IQRF Network Manager for Android

- - -

What about the working channel?

From IQRF OS version 4.03D, all types of bonding (Local – e.g. with button, Smart Connect, Autonetwork V2) are running on service channels. Therefore, the bonded Node does not need to have the same working channel pre-configured as the network Coordinator. When installing a network, it is enough to set up a suitable (undisturbed) channel in the Coordinator, and all bonded Nodes will “inherit” this channel and store it automatically in the configuration during the bonding process.

The exception is Remote Bonding – a “pre-bonding” part. Existing Nodes provide pre-bonding in the network, the process takes place in the background, on the working channel of the network, and the Node which should be pre-bonded must have this working channel preconfigured in the configuration.

A user does not need to know the service channel numbers, they are listed in the IQRF OS User’s Guide – a channels map.

 

What about Access Password?

In the case of Smart Connect bonding, the Access Password of the bonded Node does not need to be the same as of Coordinator. The IBK of the Node is used for encryption and authorization.

Other bonding methods (Local – e.g. with a button, Remote, Autonetwork V2) require using the same Access Password.

Access Password is still used for authorization in DPA Service Mode (DSM) and to encrypt/decrypt network backups during the Backup/Restore process for smooth Coordinator/Node replacement in the network (if needed).

 

Autonetwork v2

This is a new version of an automatic network creation using services deployed directly in the operating system.

Properties

  • No Custom DPA Handler is required in the Node.
  • In the Coordinator, the Custom DPA Handler required for Autonetwork functionality is uploaded (CustomDpaHandler-Coordinator-AutoNetworkV2-Embedded.c)
  • Nodes do not need to have the same working channel as the Coordinator. The channel is “inherited” and automatically saved to the configuration during the Autonetwork process.
  • The nodes to be added to the network must have the same Access Password as the Coordinator.

Network creation goes in waves. In each wave, the following steps are made:

  • Prebonding (assigning of a temporary address 0xFE),
  • Authorization (assignment of a logical address),
  • Checking the Nodes (non-communicating Nodes are unbonded from the Coordinator),
  • Discovery (detection of a network topology).

In the first wave, Nodes in the direct RF reach of the Coordinator are added to the network. In the next waves, also existing Nodes in the network are involved in the network creation. If no new Node is added during the set number of waves (default value is 2), the Autonetwork process is terminated.

You can start the Autonetwork process with a DPA command sent to the Coordinator, the command is available, for example, in macros (name – Autonetwork embedded – Start).

 

IQRF OS v4.03D User’s Guide

Release notes

Downloads

 

Autonetwork V2 – process schema

- - -

IQRF case studies, products and details

Are you interested in the IQRF technology and would you like to test it or buy some devices?

Visit the IQRF Alliance website at www.iqrfalliance.org where you can find case studies from various companies that used the IQRF wireless technology in their projects or devices and services on a Marketplace with all its technical details.

The IQRF Alliance is an international community of companies, schools and innovation centers that are using the IQRF wireless technology in their IoT projects, smart building, and smart city areas. The main goal of the IQRF Alliance is to help its members with promotion and sales leading to increasing the market share. Because together we are stronger!

You can also visit the IQRF Shop at iqrf.shop where you can buy many IQRF devices from various manufacturers in one place. There are also discounts up to 70 EUR for IQRF Alliance members.

Also follow us on social networks – Facebook, Twitter and LinkedIn.