Data transmission using SPI interface in nRF52832

RE: Data transmission using SPI interface in nRF52832

Tai — Sat, 06 Apr 2019 19:18:44 GMT

Yeah, will do.

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

RE: Data transmission using SPI interface in nRF52832

Andy — Sat, 06 Apr 2019 19:02:30 GMT

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

RE: Data transmission using SPI interface in nRF52832

Tai — Sat, 06 Apr 2019 18:37:21 GMT

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.

RE: Data transmission using SPI interface in nRF52832

Andy — Sat, 06 Apr 2019 18:15:05 GMT

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.

RE: Data transmission using SPI interface in nRF52832

Tai — Sat, 06 Apr 2019 17:45:26 GMT

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.

RE: Data transmission using SPI interface in nRF52832

Andy — Sat, 06 Apr 2019 08:59:29 GMT

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?