Data transmission using SPI interface in nRF52832

[Tai]

Hello everyone!

I have been working on getting data from ADS1299 ( ExG bio-signal sensing). I successfully got data from this IC using STM32F407VG (Cortex M4) and transmitted the data to PC via serial communication. I intend to use nRF52832 so that the data can be wirelessly transmitted. My question here is:

1) The ADS1299 chip is a 24-bit ADC chip with 8 channels. I want to collect the data from all 8 channels which means each data frame would has at least 24 bytes long (24*8), not to mention status bytes (3 bytes) and other bytes added for monitoring data integrity. In short, each data frame would has 30 bytes long. As far as I know, a package data is only up to 20 bytes for BLE protocol, thus do you have any suggestion in my application?

2) I suppose it is doable to send 30-byte package each time. To send the data to mobile app, I still need to partition them into 8-bit data each and use NUS service to send. As I make a quick calculation, it requires at least a baudrate of 150000 byte/second if sampling rate is 500 Hz. Will the nRF52832 be able to transmit data to mobile app with this baudrate?

P/s: SPI interface I am using is 4-wire interface.

Thank you! 

[Andy]

I'm working on a project where I get ECG samples from an ADS1292, but I get only 500 samples from just one channel.

1) My approach to this problem was to put all the data in a ring buffer. I'm using the nrf_queue library to buffer the samples, and I start sending the data over notifications once I have buffered 500 samples (once a second basically). At this point I start sending notfications as fast as possible. There are loads of threads on how to achieve this by queueing as many notifications as possible and then reacting on BLE_GATTS_EVT_HVN_TX_COMPLETE events.

Your current approach won't ever work. You won't be able to send notifications each time you get a sample from the sensor, even if you lower the connection interval to the minimum (7.5 ms). You need to increase the ATT MTU size and make use of the data length extension feature to achieve this. Take a look at the throughput example if you need some pointers.

2) How did you come up with that number? You need to send (3 bytes/channel * 8 channels * 500 samples/second) = 12000 bytes/s, which is totally achievable. You might run into problems with iPhones though: in my experience they force the connection interval to 30 ms, but this is something that you need to test.

If you run into problems, start optimizing your data frames: do you really need to sample all 8 channels?

[Tai]

Thanks a lot Andy!

For question (2), sorry for my mistake. It should be 150000 bits/second. I came up with this number as I intend to use NUS BLE service which resembles the UART communication (every serial data frame including a start bit and a stop bit is about 10 bits), thus it would be (30 bytes for 8 channels * 10 bits * 500 samples/second = 1500000 bits/second).

Yes. I try to have a system with high throughput. Since my system is for bio-signal recording in animals, I may think whether mobile app is a good platform to send the data or using PC for this system.

[Andy]

You don’t need start/stop bits. Where did you get that from?

Anyway, may I ask about the product you’re developing? I’m working on a similar project, also targeted to animals. I’m curious. 

[Tai]

What a coincidence! 

I try to develop a system for our Lab research about heart regeneration ability of Zebrafish.

Just a quick search about UART, each package theoretically contains both data bits and start/stop bits (http://www.circuitbasics.com/basics-uart-communication/). Actually, I added two these bits so that I can calculate an estimated baudrate supposed to require for my application.   

[Andy]

The service is called UART but it’s not UART. You need to check the structure of a BLE packet. 

[Tai]

Yeah, will do.

Thanks for your reply, Andy. How about your project? I'm also curious about it. Btw, here is my email ([email protected]). It would be great if we can have further discussion.