If you search "custom profile" there are several threads here where folks
have uploaded basic projects moving data.
Just define the custom service as you need it. In your code, set the attribute value for your custom attribute when the buffer got filled (and handle notifications). If the other side of your connection has enabled the notifications, it gets the data. Otherwise it must read the data explicitely.
Note that BLE is not designed to transmit a continuous data stream, bute just attributes that don't change that often.
You can use the project at http://www.cypress.com/?rID=107617&cache=0 as a reference to create Custom profile and use it to send the data.
I do have a question. As the measurement is Heart rate data, why don't you use the Standard BLE HRS service? This way, you will not need a custom App to make sense of data over Custom Service. Standard services are understood universally.
Thank you for your supports!
ROIT, I want not measure the heart rate, I would like measure the electrical signal of heart to then transmit the data stream and plot the signal in my cell phone! Attached the graphic.
I have been reading about the time that it take transmit a packet from the sender [about 7.5ms(interval connection time minimum) + 1.25ms(time for next connection interval)] to the receiver and the payload size for each packet transmited (about 30 bytes) from link layer.
Could I send data stream of 30 bytes each 10 ms, trying to graph the ECG signal in real time in the receiver?
I'll read all the advice that sent me and I'll try to make my custom profile!
ECG_graphic.png 94.4 K
30 bytes per 10 ms is possible. You can set the appropriate connection interval (10 ms) by sending a connection parameter update request to the connected Client device. Also, set the custom characteristic data size and MTU size as 30 bytes.
How many bytes / graph frame. Seems like you are hovering around
the flicker frame rate human eye can see. Maybe best approach is
to buffer an entire frame before presenting on display, even then that
will be close to observable flicker updatre rate.
If heart rates quite low then a smooth painting in time the data only
You really need to use the notificatzion mechanism of BLE. That way the PSoC4 can push updates, and there is no problem with the phone maybe requesting data to early in the 10ms cycle. You can also try larger package sizes so you don't need to transmit so often.
I think the largest payload for a single packet is 20bytes, so it might be a good idea to transmit multiples of that.
On the display side, it should be OK to update only the portion of the signal that gets updates data. That way no flickering should occur (since th other parts are never redrawn)
One approach is to keep a buffer of the signal, say a buffer of amplitudes vs time.
Then when new data comes compare each element of the data with buffer, if data
changed update that element in buffer and change that portion of display. If no
change NOP. That will produce the cleanest display appearance of all approaches.