nRf51422 data rates

[Paul]

Hi, I'm having the purpose to use nRF51422 /ANT to connect a relatively data hungry ANT device. The nRf51422 specs expose three programmatically available data rates : 250 kbps, 1Mbps, 2 Mbps. I'm unable to find more details in the doc (either soft device 310 or product reference manual) Could you tell me where I can find details concerning the data rates options Regards

[mnhs]

Those data rates are AFAIK maximum theoretical 2.4 Ghz radio transmit speed. You can send the raw data that fast. But all the sync preambles, addresses and identification, payload itself, CRC etc. are included. The process of building those packets also requires some MCU time.

Thus, the maximum data rate is significantly reduced by this. Please correct me if I am wrong, but as far as I can remember, the maximum payload data rate both for BLE and ANT is somewhere around 60kbps. You can send your payload that fast. Those protocols are intented to be used for ultra-low-power low data rate applications. If you need 250kbps or even 2Mbps payload throughput, I think you will have to choose another solution, not based on ANT/BLE.

ANT was primarily designed to ultra low datarates, the standard datarate is 8 bytes every approx. 250 milliseconds. There is a story that Dynastream designed this protocol for Nike as they needed a device which could transmit for a year or two from a single CR2032 coin cell. Due to this requirement, the radio (~10mA) has to be active only 0.1% of the time. It is also extremely easy to implement. As you rise the data rate, you will soon start to lose that ultra-low-power advantage. At the 60kbps datarate, in terms of power consumption, I suppose you will be close to standard Bluetooth 2 link.

[Asbjørn]

The ANT protocol use 1 Mbps on air data rate. So if you are using ANT you don't have an option in changing the on air data rate. The 250 kbps and 2 Mbps are available for proprietary radio communication.

[Paul]

Thanks for the answer, it helps me a lot because i'm a newbie in the ANT world. My understanding, so far, of the ANT bandwidth management is that the max payload of 60kbps is for one channel. My project is :

• to wire various sensors to a nRF51422
• to send the data from this nRF51422 to an another nRF51422 using various ANT channels (and therefore having a (channnelnumber x 60kbps) payload. Do you think it is feasible ?

[mnhs]

I don't think so. The radio and stack is fully busy during burst transmit.

I would recommend to look at the data you are sending. There is a great chance you can compress them to reduce the data rate. Now I am developing a project which runs an OLED display and I have a lot of images to be stored in the MCU. Simple RLE compression and I am able to get to 30-40% of the original "raw-BMP" size.

Could you please specify what kind of sensors are you using? In most cases, the measured values do not change that much so you don't need to send them 10x a second but only when the value changes. Or you can take an inspiration from video codecs. You will send the absolute value once and then you will send just the increments.

An example: Temperature sensor, 0 - 500°C - you need minimum of 9 bits to send the absolute value. You transmit the data 10 times a second. [run out of characters ...]

[mnhs]

[continuing the previous comment]

You transmit the data 10 times a second. For a "classic" way of transmission, you need 90 bits each second. Now you will assume that the physical limitation of the temperature sensor is that the temperature can't change more than 1°C/100 miliseconds. So, you will send only the increments - two bits (you need to implement three states -1; 0; 1). You reduced the data rate to 20 bits/second - cool, isn't it?

Yes, but there are some problems. For example - you will lose a packet. You can't reconstruct the data anymore. OK, you will send the absolute value once a second. Voila - 9 bits + 10*2 bits = 29 bits => about 33% data rate of the "normal" way.

This example is very simplified, it does not include any packet structure etc. Just for illustration of how the data compression can work. The robust implementation itself is much harder.