Photos and presentations from the IQRF Summit 2019 in one place. Remind
Day 1
| IQRF Alliance | IoT Deployment = nightmare Not any more! |
| IQRF Tech | Towards IQRF® open standard |
| IQRF Alliance | Making deployment easier with new DPA features |
| IQRF Tech | IQRF Gateway |
| AAEON Europe | Artificial Intelligence on the Edge |
| Logimic | Open Edge Gateway, Abstraction layer for IQRF gateways |
| RehiveTech | PIXLA |
| FM Conway | Company introduction |
| Omniolytics | Commercial Poultry in South Africa, Water and Air quality monitoring & analysis |
| České Radiokomunikace | Addressing strategic segments, Joint-approach for Complex use-cases |
| VFN | IoT deployment in hospital / Solution architecture |
| tcp / MICRORISC | Radar & IQRF based car & people counters |
Day 2
| MyMight | I measure, therefore I am. What next? |
| 4IOTECH | IQRF Interoperability |
| Wroclaw University of Science and Technology | Opportunities and challenges for teaching of smart wireless technologies |
| Austyn International | Company introduction |
| Findlay Irvine | Earthworks Monitoring System |
| Protronix | Internal Air Quality sensors |
| HARDWARIO | EASY and AFFORDABLE i4.0 pilots |
| VŠB-TUO | Development of Monitoring Systems Based on IQRF Technology at the Department of Cybernetics and Biomedical Engineering |
| MAKERS | Company introduction |
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.
Creating Nodes
A. Plug a TR transceiver in CK-USB-04A, select the DPA-Node-STD-7xD*
B. Double-click on the configuration file DPA-config.xml in IDE Project window to open the TR Configuration window.
Make the following settings:
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
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.
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.
Test other peripherals and commands in the same way.
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.
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
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.
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.
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.
|
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 i 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
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;
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
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
Where: NEC, 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.
Media partners
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:
