Real-time data acquisition up to 30 sensors - is it possible with nRF?

[Kris__]

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!

[haakonsh]

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.

[Kris__]

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?

[haakonsh]

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. 

[Kris__]

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.

[haakonsh]

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.