This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SPI BLE receive wrong values via UART and BLE

Hey guys,

I'm working with a Laird BL652-DVK (nrF 52832 - chip), Nordic SDK v.14.2.0 and SES (Segger Embedded Studio v.4.30). My goal is to send datas from sensor (accelerometer LIS3DH) via bluetooth to my phone. I get via spi the datas from sensor.

At first I tested the examples spim, uart and ble_app_uart separatly and all examples worked. But now I try to combine my modified example spim with unmodified example ble_app_uart and get the wrong "WHO_AM_I" values both via UART (Termite v3.4) and via BLE (to my phone, app: nRF Connect). (My modified spim code is working too.)

Via UART I get instead of 0x33 (default value for WHO_AM_I) another value. Via Bluetooth I get instead of 0x33 the value 0x3. I think there is something wrong with my code...

Here is my code:

Here are the received datas via UART:

I don't understand why I get firstly "0x24" and after it constantly "0x51"..? Because while debugging the first value is 0x24 (same like picture above) and after it constantly 0x33...

Here is the received data via BLE:

I hope, you can help me.

Best regards,

Christoph

Parents
  • I've not looked at your code yet, but points that spring to mind: 0x33 (hex) = 51 decimal = ASCII character '3'. 

    If your characteristic is defined as having a string type then nRF Connect will automatically convert it - displaying 3 for 0x33.

    … 

    Looking at your code in main() your first printf statement formats the value as hex:

    whereas your second printf formats the value as decimal:

    ...

    I can't see why your first character out is 0x24 ('$'), perhaps you can tell dynamically e.g. in debug.

    ...

    Ah shouldn't this line

    occur before you try to read the spi first time?

  • Hey cbd,

    1)

    >>> I've not looked at your code yet, but points that spring to mind: 0x33 (hex) = 51 decimal = ASCII character '3'. 

    If your characteristic is defined as having a string type then nRF Connect will automatically convert it - displaying 3 for 0x33.    <<<

    You are right, thank you. I forgot such things like ASCII and exact displaying. Also the second printf format wasn't the right, thanks for your attention!

    2)

    occur before you try to read the spi first time?

     In my modified periphal example spim I have the first printf(...WHO_AM_I...) before lis_init() and this worked... Now I tried out the 1st printf(...WHO_AM_I...) after lis_init() because of your suggestion and now I get 0x33. I don't know where is difference between spim and ble_app_uart but thank you cbd!

    3)

    I have a further question: to send datas via bluetooth to my phone/pc I need the function ble_nus_string_send() and this function send the data as string. Do you know if there are possibilities to send the datas as hex or decimal values? Or is there only the possibility for me to convert the values ​​manually (by an own function, e.g. convert 0x33 in string/ASCII "33" and give "33" to ble_nus_string_send() )?

  • You can send non-text (or ASCII) if you wish, as ultimately all data is binary anyway.

    Points to bear in mind:

    0x00 (or null) is a valid value and as it acts as a string terminator you will need to replace any string handling operators with array handling ones e.g. strlen to determine size of data to send will no longer work.

    The Nordic NUS code should support it as :

    treats the data as binary anyway.

    The NUS code may require certain terminators such as '\n' or '\r' to determine end of text - so you'll need to check that.

    nRF Connect will be expecting to handle the Nordic UART Service data as text. It probably wont handle the data correctly for display, particularly non-printable characters.

    You could use the Nordic code as is, but change the service UUID (change the nus_base_uuid ) in this section

Reply
  • You can send non-text (or ASCII) if you wish, as ultimately all data is binary anyway.

    Points to bear in mind:

    0x00 (or null) is a valid value and as it acts as a string terminator you will need to replace any string handling operators with array handling ones e.g. strlen to determine size of data to send will no longer work.

    The Nordic NUS code should support it as :

    treats the data as binary anyway.

    The NUS code may require certain terminators such as '\n' or '\r' to determine end of text - so you'll need to check that.

    nRF Connect will be expecting to handle the Nordic UART Service data as text. It probably wont handle the data correctly for display, particularly non-printable characters.

    You could use the Nordic code as is, but change the service UUID (change the nus_base_uuid ) in this section

Children
  • Thanks for your great input cbd, you know a lot! But I prefer not to change something in Nordic code so I programmed a function to convert decimal into ASCII. The code is below:

    And it works. It convert the datas from dec to hex. What do you think about my function? Any suggestions?

  • And I have another question: Is there a possibility to query the bluetooth RX buffer? Because I want to implement a send command for sending the sensor datas via ble to my phone. Before the send command it should be not allowed to send anything.

  • Could you elaborate on this? Is it the phone that should not send any thing to the nRF before the nRF has sent the sensor data?

  • Hey bjorn-spockeli,

    I want something similar to the uart example (../examples/peripheral/uart). Here we see that we close the connection when we send 'q' or 'Q' via uart. (code below)

    I want nearly the same for my modified ble_app_uart. But I don't want to send the quit command 'q' or 'Q' via UART, but via ble. When I press on my phone (nRF Connect) 's' (for start), the nRF sends the sensor data to my phone via ble. When I press 'q' the nRF should stop sending sensor data. And when I press 's' again the nRF send datas again. (pseudocode and photos below)

    start command: (app: nRF Connect on my phone)

    RX Characteristics --> Value: s

    stop command:(app: nRF Connect on my phone)

    RX Characteristics --> Value: q

    I hope I could explain clearly and precisely.

  • Hi Christoph, 

    If you have are using a modified ble_app_uart example then you're using notifications to send the sensor data to the phone. Notifications can be enabled or disabled by the central device(phone) writing to the CCCD of the characteristic on the slave device. When the CCCD is written to you will get enter the on_write handler in the NUS code. Here the is_notification_enabled flag set to true, see below. 

    This flag is checked in ble_nus_string_send, which I assume that you use to send the sensor data. 

    As you can see ble_nus_string_send will return NRF_ERROR_INVALID_STATE if is_notification_enabled is false. So you could simply set is_notification_enabled to false when you receive the stop command from nRF Connect on your phone. Alternativly, you can use a timer to trigger the sensor data transmission and use the start/stop signals to start/stop this timer that will call ble_nus_string_send in its timeout handler. 

    Best regards

    Bjørn