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

Sending scanning data via UART

Hey guys. I am making a firmware using nrf52840 dongle which scans nearby bluetooth devices. I do not want to connect to any device, just send scanning data to another device via UART.

Below is the code where I am getting scanning data on console

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{

switch (p_ble_evt->header.evt_id)
{
 case BLE_GAP_EVT_ADV_REPORT:
 {
      NRF_LOG_RAW_HEXDUMP_INFO (m_scan.scan_buffer.p_data, m_scan.scan_buffer.len);
      NRF_LOG_RAW_INFO ("----------------------------------\r\n");
}

 default:
 break;
}

}

I changed nrf logging tx pin and connect to my other device and got the same result, but it gives me ascii format such as I want 4C in hex but it is giving me 4C in ascii, so now I want to use uart and send hex data, but same as I am getting in ascii.

My other code is below, but it is not giving me the right result. I want advertisement data to be sent to other device via uart and I will decode the data on that side to get only ble beacons and extract MAC address from the advertised data. I hope you guys understand me.

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{

ble_gap_evt_t const * p_gap_evt = &p_ble_evt->evt.gap_evt;
uint8_t uuid[30];
uint8_array_t adv_data;

switch (p_ble_evt->header.evt_id)
{
case BLE_GAP_EVT_ADV_REPORT:
{
for (int i=0;i<100;i++)
{
  app_uart_put(p_gap_evt->params.adv_report.data.p_data);
}

}
}


}

Your suggestion will be appreciated.

Regards,

Parents
  • Hi,

    You're getting ASCII values back as that is what you're converting the binary data to.

    All of the NRF_LOG functions convert the binary data to ASCII, NRF_LOG_RAW_HEXDUMP_INFO converts the binary data to an ASCII representation of the binary data.

    If you want to send binary data then you can do so, but you'll need to put your own protocol in place as most UART examples send only ASCII data as it's easier - by sending ASCII strings you're using the NULL terminator to inform the receiver that the end of the string has been reached.

    For your purposes sending data in the following format would be a start:

    • data length (number of bytes)
    • data (all bytes from data array)

    Using this all data would need to be treated as binary, unless you add another field to indicate whether the data is binary or ASCII. You may wish to add a short sequence of known bytes to indicate the start of a message e.g. 0xA5A5, you may also place something similar at the end of every message e.g. 5A5A. At the receiving end you would read those fields back and handle them accordingly e.g. is this the start of a message; does the data length match the length stated in the length field etc.

    In this case you'd build up your data string in a buffer array and send that.

    For example the data copied into the array would be in the order:

    • data length (copy of m_scan.scan_buffer.len value)
    • data (copy of all bytes in buffer pointed to by m_scan.scan_buffer.p_data)
  • But my point is how to get the data. For example the below code

    switch (p_ble_evt->header.evt_id)
    {
      case BLE_GAP_EVT_ADV_REPORT:
      {
        app_uart_put(p_gap_evt->params.adv_report.rssi);
      }
    }

    It sends RSSI values of nearby devices to uart, I want to send advertisement data of beacons i.e. 31 bytes to be sent to uart just like these RSSi values.

Reply Children
  • Hi PKSHER,
    I know what you're after, but I'm not going to write your code for you.
    I explained why, in your first code snippet, you were seeing a hexadecimal formatted ASCII representation of your binary data.
    Your first code snippet implied that you knew how to access the advertising data, in any case you'll find your it located at p_gap_evt->params.adv_report.data.p_data
    and of length p_gap_evt->params.adv_report.data.len
    Note: not all devices will advertise the same amount of data.
    In sending data over the UART you'll need to allow for the fact that the BLE advertising events (with data) and the UART transmission are not synchronous, hence my mention of a temporary buffer into which you'll need to copy your data and the UART code can draw your data from.

    I guess from your mention of app_uart_put that your using one of the NRF libraries, which is all well and good, but let me ask you these two questions too think over (I don't want a reply to them).
    1. If at the receiving end of your UART line you receive a block of data, say 78 bytes, how do you know where an advertising record begins and ends, or indeed if it contains any part records?
    2. If you decide to send RSSI data and advertising data over the UART, how does your receiving device determine which byte of data relates to the RSSI value?
    This is why I was guiding you towards some form of messaging structure, maybe with start and end termination sequences and data length indicators.
    Your first code snippet seemed to imply that you know of the need of a temporary buffer by using
    m_scan.scan_buffer.p_data and m_scan.scan_buffer.len .

    Your second code snippet with its for loop seems to imply that you know how to write a block of data to the UART a byte at a time (although it should be limited to the length of the data in your buffer as it may be more than or less than 100 bytes) e.g.
    for( int i=0; i< m_scan.scan_buffer.len; i++)
    {
        app_uart_put(m_scan.scan_buffer.p_data++);
    }
    The NRF UART library will indeed temporarily buffer data for you, but you'll still need to package it so that you can understand how to handle it at the other end.
  • NULL terminator to inform the receiver that the end of the string has been reached.

    No, that's not (quite) true.

    The NUL terminator tells the 'C' library functions that they have reached the end of the string.

    The NUL terminator is not sent to the receiver!

  • I want to send advertisement data of beacons i.e. 31 bytes to be sent to uart

    Identical question answered here:

    https://devzone.nordicsemi.com/f/nordic-q-a/49289/reading-raw-adv-packet

  • Ok i will look at it and get back to you. Thanks.

Related