Tips/help for transferring 1200 bytes from DK to dongle

Hello guys! I am testing the NRF52-DK along with the dongle for a IMU tracker device.
I am new to zephyr, nordic and BLE and having some troubles understanding zephyr and BLE and wanted to ask for a few pointers.
If this does not belong here then feel free to remove this post

What I'm trying to do is the following:
NRF52-DK:
Obtain samples from IMU (16bit 6axis) and fill a 1200 byte buffer (100 IMU frames)
Transfer the 1200 bytes (raw data) to the dongle via BLE in multiple blocks/transfers.
DONGLE:
Print/log the data received by the dongle to a terminal/file.
PC:
Use the data from the log file or terminal to reconstruct the IMU data and do something with it.

Questions:
1. What is the industry standard block size for this kind of transfer?
2. Can I somehow remove the prefix from the dongle output so that only the raw data is being logged? ("Attribute value written, handle: 0x12, value (0x):")
3. Is there a simple example for this kind of transfer using NCS zephyr? I have looked into the "throughput", "peripheral_uart" and "shell_bt_nus" examples but I find them being very comprehensive and hard to follow with multiple function calls within each other.
I was expecting to find a simpler example (fewer lines of code) which would be easier to dig through at this point.

NOTES:
-I have already covered the IMU reading and buffer filling at this point.
-I'm not worried about speed of transfer at this point.

Parents
  • Hi,

    1. What is the industry standard block size for this kind of transfer?

    I don´t believe there is an industry standard for this, it depends on your speicfic application.

    2. Can I somehow remove the prefix from the dongle output so that only the raw data is being logged? ("Attribute value written, handle: 0x12, value (0x):")

    Yes. If you are just transfering the data you could avoid the log APIs, and just write to UART direcly (assumign that is what you use here), and you will get just no overhead. Alternatively, if you also use logging there you can use CONFIG_LOG_MODE_MINIMAL=y.

    3. Is there a simple example for this kind of transfer using NCS zephyr? I have looked into the "throughput", "peripheral_uart" and "shell_bt_nus" examples but I find them being very comprehensive and hard to follow with multiple function calls within each other.
    I was expecting to find a simpler example (fewer lines of code) which would be easier to dig through at this point.

    The problem is the BLE is in some ways a bit complex, where you have services consisting of characeristics, and no simple standard data tunnel. I would recommend using the NUS samples (central and peripheral) though, as NUS is a simple and for that reason much used way to get a form of simple data tunnell.

Reply
  • Hi,

    1. What is the industry standard block size for this kind of transfer?

    I don´t believe there is an industry standard for this, it depends on your speicfic application.

    2. Can I somehow remove the prefix from the dongle output so that only the raw data is being logged? ("Attribute value written, handle: 0x12, value (0x):")

    Yes. If you are just transfering the data you could avoid the log APIs, and just write to UART direcly (assumign that is what you use here), and you will get just no overhead. Alternatively, if you also use logging there you can use CONFIG_LOG_MODE_MINIMAL=y.

    3. Is there a simple example for this kind of transfer using NCS zephyr? I have looked into the "throughput", "peripheral_uart" and "shell_bt_nus" examples but I find them being very comprehensive and hard to follow with multiple function calls within each other.
    I was expecting to find a simpler example (fewer lines of code) which would be easier to dig through at this point.

    The problem is the BLE is in some ways a bit complex, where you have services consisting of characeristics, and no simple standard data tunnel. I would recommend using the NUS samples (central and peripheral) though, as NUS is a simple and for that reason much used way to get a form of simple data tunnell.

Children
No Data
Related