Sending scanning data via UART

RE: Sending scanning data via UART

PKSHER — Fri, 05 Jul 2019 06:52:22 GMT

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

RE: Sending scanning data via UART

awneil — Wed, 03 Jul 2019 09:44:57 GMT

[quote userid="80472" url="~/f/nordic-q-a/49225/sending-scanning-data-via-uart/196165"]I want to send advertisement data of beacons i.e. 31 bytes to be sent to uart [/quote]

Identical question answered here:

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

RE: Sending scanning data via UART

awneil — Wed, 03 Jul 2019 09:43:36 GMT

[quote userid="72220" url="~/f/nordic-q-a/49225/sending-scanning-data-via-uart/195858"] NULL terminator to inform the receiver that the end of the string has been reached.[/quote]

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!

RE: Sending scanning data via UART

cbd — Wed, 03 Jul 2019 09:34:35 GMT

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).

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?
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.

RE: Sending scanning data via UART

PKSHER — Wed, 03 Jul 2019 08:20:45 GMT

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.

RE: Sending scanning data via UART

cbd — Tue, 02 Jul 2019 08:24:14 GMT

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)