Hello!
I have 18-bit sensors with SPI and I2C, which I intend to use in a wireless array.
I need to choose equipment and topology (star, scanning mode?), enabling data acquisition from max. 30 sensors and sending to a selected mobile device (tablet) via USB with the shortest possible delay (10 ... 20 ms).
For example: is nRF24LE1 and nRF24LU1 sufficient to solve the problem?
Thanks for any suggestions!
30 wireless links with a maximum latency of 20ms is going to be difficult with a 1/2mbps radio. You will have to design your own radio protocol.
You will most likely require 2 receivers with the nRF24 series, depending on whether you need automatic retransmissions or not. With room for one retransmission per packet you will require ~700µs per data transfer per device, at 1mbps. For 30 devices that's ~700µs * 30 = 21ms, just for the wireless transfer. If you use 2mbps you can cut that down a bit, but there is a fair bit of overhead in switching radio states. With 2mbps and no retransmissions, you can get maybe ~300µs x 30 = ~9ms of radio time to deliver one a set of data from each device.
The nRF24 series is not suited for new products, the radio is 15 years old and we have no real support for that device.
I'd much rather recommend the nRF52833 as it is our most cost-optimized device with a USB and a modern 2mbps radio. The time it takes to switch states in the 52 is much lower than the nRF24, it has far greater range, lower current consumption, better ease of use, and actual support.
For the radio protocol, I propose that you have the "receiver" send out a beacon packet and have the sensor "transmitters" synchronize their transmissions to this packet so that they do not collide on-air (TDMA), for each set of data. You will also have to decide whether to implement frequency hopping or not, and how many retransmissions you require.
Thank you for your answer.
By design, the sensor array will be battery powered (low power consumption) and will operate over a very short distance (several meters). It will also be light and small. First I was thinking about the nRF24LE solution with power limitation to -18dBm (power management). If I understood correctly - the new nRF52 would in this case replace only the outdated nrF24LU, while cheap nRF24LE could remain, working directly with sensors via SPI (sensors nodes)? Thanks!
A unique address for each device is not a problem unless you use ESB, who only supports 8 slaves per master.
If you want more slaves per master you will need to create your own radio protocol based on the receiver/transmitter examples.
If you look at my original reply you'll see that it is possible, but again, it will take you a fair bit of time to create such a protocol.
So the next question is: what is the difficulty in creating such a protocol and why is it so time consuming? It is not just a matter of duplicating the instructions for each addressed sensor (nodes)? What dependencies (synchronization) do I need to consider?
the sensors should all run the same program.
The problem is that you need to make sure that only one sensor transmits at any given time, otherwise any on-going transmission will fail due to the RF interference of another transmitter. One way to synchronize 30 slaves is to divide the available on-air time into blocks of 30, one for each slave, and send a timing beacon from the master at the start of each set of 30 blocks. You will then have to find a way to assign each sensor to a block. You can, for instance, give each a unique number from 0 to 29 and use that number to represent what on-air time block it is allowed to transmit in with respect to the synchronization beacon.
You will also have to consider if you need re-transmissions of lost packets or not, as that will complicate your protocol.
It is time-consuming because you will have to create the implementation yourself, we do not have any radio protocols that support your needs. ESB can have one master per 8 slave, as the closest option.
Thanks!
The sensor is 18-bit, but 3-axis (X, Y, Z) and additionally equipped with 8-bit temperature measurement. My guess is that in this situation the total estimated time needed only for wireless data transfer is therefore more than 3 times longer and is about 3ms for a single module (apart from measurement time of the sensor itself specified in the catalog card as ~1...3ms depending on the selected mode (low power drive / low noise drive)). In connection with the above, I am afraid whether the nRF project will be implemented at all.
The actual on-air time of your data is easy to calculate, at 2mbps the on-air time of a sensor's data will be:
(1/2*10^6)seconds/bit * (3*18 + 8)bits = 0.6µs/bit * 62bits = 31µs.
Most of the radio time is occupied by changing radio states and packet overhead like a preamble, address, opt headers, opt CRC. You must also set aside extra time for the receiver before and after a transmitted packet to allow to compensate for clock drift between the two radios.
I've given you a rough estimate of the on-air times of complete radio packets in my first reply.
The actual on-air time of your data is easy to calculate, at 2mbps the on-air time of a sensor's data will be:
(1/2*10^6)seconds/bit * (3*18 + 8)bits = 0.6µs/bit * 62bits = 31µs.
Most of the radio time is occupied by changing radio states and packet overhead like a preamble, address, opt headers, opt CRC. You must also set aside extra time for the receiver before and after a transmitted packet to allow to compensate for clock drift between the two radios.
I've given you a rough estimate of the on-air times of complete radio packets in my first reply.
