Category Archives: General

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     = 0x0000               Coordinator address

               PNUM    = 0x0D                   Predefined Peripherals – FRC

               PCMD     = 0x00                    Command Send

               HWPID   = 0xFFFF


PDATA including these information’s:            





_PCMD [type of FRC]

[type of peripherals]

[typ of sensors]






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


bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

bit index

sensor index


                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:


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;



         case STD_SENSOR_TYPE_EXTRA_LOW_VOLTAGE:                                 // 0x04

             if ( sensorIndex > 1 )                                                                                                                     

                 goto DpaHandleReturnFALSE;

              W = 1 + sensorIndex;



         case STD_SENSOR_TYPE_TEMPERATURE:                                            // 0x01

              if ( sensorIndex > 1 )                                                                                                      

                   goto DpaHandleReturnFALSE;

              W = 2 + sensorIndex;



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



                                                                                                         //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





                 case 0:                      

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





                      case 0:                                                                                                                                                                  

                         responseFRCvalue.1 = binary_data.0;



                      case 1:

                         responseFRCvalue.1 = binary_data.1;



                      case 2:

                         responseFRCvalue.1 = binary_data.2;





                case 1:

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

                responseFRCvalue.1 = 0;



                case 2:

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

                responseFRCvalue.1 = 0;





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

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



                    goto DpaHandleReturnFALSE;


                 case 0:                      

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



                 case 1:

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



                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





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

               switch ( sensorIndex )                                                                                                    



                    goto DpaHandleReturnFALSE;                


                 case 0:                      

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



                case 1:

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



                 case 2:

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








4. FRC commands from example

For BinaryData7:


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:


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:


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

- - -

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, where you enter the discount code:




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.


  • 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.


  • 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



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 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 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.

IQRF Alliance at IoT Solutions World Congress 2018

The IQRF Alliance attended the IOTSWC18 event in Barcelona together with Monolitic with a success among visitors. Presenting members‘ devices and solutions.

The IoT Solutions World Congress is an event full of decision makers, top speakers, and business professionals. The event is dedicated to joining IoT providers with industry in order to help agree on business partnerships.

This year was the fourth IOTSWC and it was visited by more than 16,000 people, 300 exhibitors, and 316 top level speakers on a venue of 32,000 m2 large.

The IQRF Alliance had a joint booth with Monolitic, M2M communication, and semiconductor company, and presented members’ devices and solutions using live demo boards with end devices, gateways and also data visualization in various clouds.

Next IOTSWC is on October 29-31 2019.

- - -

Let‘s learn how to ventilate properly to maintain a low level of CO2 in schools and kindergartens

RehiveTech, a spin-off of the Brno Technical University and member of the IQRF Alliance, installed its smart indoor air quality monitoring system in several schools and kindergartens in Brno, and the results were very interesting.

At the beginning of the project, an analysis of the environment has shown that CO2 levels in rooms are gradually increasing, a phenomenon that is common in every room inhabited by people and not ventilated properly. Unfortunately, higher levels of this gas cause drowsiness, headache, and a lack of concentration. In their own interest, people should watch the level of CO2 that should not exceed the 1500 ppm hygienic limit set by a decree.

The deployed system consisted of a CO2 sensor (A) that provided data via the IoT system (B) to the central application where the data was evaluated. The control commands were regularly sent back, influencing the color of the light, which was in the form of a likable cloud (C) present in a class. The light signalized how healthy the environment was by changing colors. Children and staff have instructions on how to behave in any color state. They learned how to maintain the CO2 level low by only proper ventilation.

Three months later, the experimental shutdown of the signaling light followed, and the measurements surprisingly showed that the local staff had learned to control their indoor air themselves and that no unacceptably high levels of CO2 were measured.

The system can also recommend or not to open windows based on a weather forecast or ambient air data.

RehiveTech, a member of IQRF Alliance, develops this system for offices where within a single AuroraHub system it is possible not only to measure the air quality but also to solve the security of rooms, attendance, and mandatory staff breaks, e.g. with smart bracelets including the necessary documentation. More at


- - -

Presentations from the IQRF Meetup

The IQRF Meetup is over but the IQRF Alliance is working on other events for its members. Meanwhile you can go through all the presentations from the Meetup.

IQRF Meetup opening, ecosystem, IQRF Alliance news – Šimon Chudoba, IQRF Alliance

Where are we going to? – Vladimír Šulc, IQRF Tech

OS + DPA release details – Hynek Syrovátka, IQRF Alliance

IQRF Gateway Daemon – Rostislav Špinar, IQRF Tech

IBM Cloud – special package and services for IQRF Alliance members – Petra WinklerováVojtěch Novák

Monitoring of industrial processes with IQRF – Jozsef Kopják, IQ Home

IoT platform and gateway introduction – Peter Vereš, Makers

IQRF Mobile App – Radek Hollein, Master Internet

AuroraHub & Pixla – Pavol Korček, RehiveTech – (live)

Company presentation – Marek Žanta, 4IOTECH


Also, you can view the photos from the IQRF Meetup in Mikulov here.



4IOTECH (Member) – more

ALIS Tech (Member) – more

AT&T Global Network Services Czech – more

AUSTYN International (Member) – more

České radiokomunikace – more

CITIQ (Member) – more

DATmoLUX (Member) – more

Dazzle Light Europe (Member) – more

DEGA CZ – more

Expense Reduction Analysts – more

GC System (Member) – more

GreyCortex (Member) – more

HARDWARIO (Member) – more

IBM (Member) – more

IQ Home (Member) – more

IQRF Tech (Member) – more

JOT – more

JoTio Tech (Member) – more

Logimic (Member) – more

LPRS (Member) – more

MAKERS (Member) – more

Master Internet (Member) – more

NETIO (Member) – more

Omniolytics – more

OnSite Power – more

RehiveTech (Member) – more

Review Display Systems – more

SECTRON – more

TCP (Member) – more

T-MAPY – more

T-Mobile CZ – more

Total Structures – more

UniPi technology (Member) – more

University of West Bohemia in Pilsen (Member) – more

VSB – Technical University of Ostrava (Member) – more

ZAT – more



Contacts of all registered guests are in the internal news in Member zone where only IQRF Alliance members have access to or contact for the list.


- - -

IQRF Meetup with over 90 IoT professionals

More than 90 IoT professionals came to the IQRF Meetup in South Moravian region.

The IQRF Meetup became very popular among the members of the IQRF Alliance during the years. This time the meetup was attended by more than 90 representatives not only from companies that are members of the Alliance but also from companies that for example heard about the IQRF wireless technology for the first time but are interested in it.

The event was held in Hotel Volarik in town Mikulov, South Moravian Region (CZ) and started with two blocks of presentations where the IQRF team introduced new features (Smart Connect, IQRF Network Manager mobile app, IQRF Daemon 2, etc.), devices (GWs, etc.) and also vision where should the IQRF technology be heading. The second block was dedicated for representatives from various companies all over the Europe who had time to introduce their company, what they do, what they can offer to others and what they need from the community.

Based on the experiences from previous years, we know that it is all about networking. The best networking is of course done while eating and drinking something tasty, so the whole group moved to the nearby wine cellar. Attendees enjoyed the wine degustation and started to discuss possible cooperation with companies they didn’t even know a few hours ago.

- - -

IQRF Meetup is coming

The IQRF Meetup is coming, set a note in your calendar!

The IQRF Alliance invites you to another IQRF Meetup which will be held on October 4th, 2018 – now in South Moravia.

Attendants will be able to enjoy an informal conference on professional premises and then move to a wine cellar for a good networking dinner.


WhereHotel Volarik, Mikulov, Czech Republic

When: October 4th, 2018



- - -



12:00 – 13:00 Registration
13:00 – 15:00 1st round of presentations
15:00 – 15:30 Coffee break
15:30 – 17:00 2nd round of presentations
17:00 – 18:00 Break
18:00 – 18:30 Walk through the town to a wine cellar
18:30 Networking in the wine cellar


The IQRF Meetup will start with a Registration from 12:00 in Hotel Volarik, Mikulov, Czech Republic.

After the Registration, there will be two rounds of presentations – representatives will have an opportunity to briefly introduce their company and what they do. IQRF Tech and other IQRF Alliance members will introduce the release of new features, products, and services: Smart Connect, IQRF Gateway Daemon 2, simple and low-cost IQRF gateway, mobile app, IoT platform, connectivity to Big Clown makers kit, and much more.

Thanks to the experience we know that people get to know each other best during networking, so we will take a short walk from Hotel Volarik through the historic center of the town to the wine cellar Šimák. Guests will find there a pleasant sitting with a wine degustation and a good dinner in the form of pork ribs and chicken wings. Furthermore, we will try out the very first IQRF music jam so bring any musical instrument you can play to join the “IQRF band”.

- - -


- - -



We recommend Hotel Volarik for the accommodation, where the whole IQRF team will stay as well. The accommodation is registered by the guests themselves. Please book your room at or call +420 777 003 692.

- - -


Media partners