nRF52 UART connection with constant data stream capability

[Aashay]

Hello, I am working on a project where I have 2 nRF52832 boards with the PCA10040. I have the example developer code examples. I am using the central and peripheral code examples to talk from one UART to another on Tera Term. Although, I noticed that this code is structured so that data is piled in an array and only sent to the other UART when I press "enter" or if it reaches a maximum size (which is very large). I am only using Tera Term to test my boards and not as part of the project. I have an external source of data that works properly on its own and am trying to use these UARTs to establish wireless communication. I have cut the solder bridges SB 22-25 to isolate PO.05 - PO.08 from nRF52832 to the Interface MCU. In pins 6 and 8 on both boards, I put TXD and RXD. Essentially what I am trying to do is have data go though the TXD & RXD wires to one UART, then wirelessly transfer data to the other UART, and have TXD & RXD wires come back. This processes will not work unless the code is structured so that data can be processed (sent & received) continuously. Or at least have it to where whatever is stacked up in the buffer is sent out every interval. I have attached the part of the code for both Central and Peripheral examples that specifically deal with data in UART. I have also put a diagram of sorts to help visualize. Any help would be great. Thanks.

[Vidar Berg]

Hi, you will get higher bandwidth when you split the data into larger chunks as opposed to sending a few bytes at a time (Note: the max data size is defined by m_nus_max_data_len), so it's probably a good idea to accumulate data at a fixed interval before transmitting as you suggested. I would probably have used a longer timer interval though. The lowest connection interval allowed by BT spec. is 7.5 ms anyway. 

Aashay said:

The rest of the data gets lost

 It's not lost by the Softdevice. Data passed to ble_nus_data_send() will be transmitted if the function returns NRF_SUCCESS (i.e., the link will be terminated if a packet is not received within the supervision timeout ). I think it's likely returning NRF_ERROR_RESOURCES as it's easier to fill the Softdevice's TX buffer when you send many small notifications rather than few large notifications. The message for handle value notification illustrates this: https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.api.v6.1.1/group___b_l_e___g_a_t_t_s___h_v_n___m_s_c.html?cp=3_4_1_1_2_4_3_5 

I'd recommend using an app timer instance to control the data transfer. You can use the ble_app_hrs example to see how timers are initialized. 

[Aashay]

Hi, I looked at the ble_app_hrs example. I am still having trouble trying to incorporate a timer instance. If I could get some assistance on what to do, it would be awesome.

[Vidar Berg]

Hi,

Please try the attached example below and see if it works for you. I added a ring buffer to hold the UART data between timer events, see tx_buffer.c adjacent to main.c.

ble_app_uart_mod.zip

Note: this example requires SDK 15.3.0. Extract the folder to \nRF5_SDK_15.3.0_59ac345\examples\ble_peripheral before building the project.

[Aashay]

Hey Vidar Berg, this works really well for the peripheral example. I was trying to incorporate this into the central example since I am working with two boards, but the syntax for the 2 examples differs greatly. Is there any way you have something just like this for the central uart example.

[Vidar Berg]

Hi, yes here is the central/client version:

ble_app_uart_c_mod.zip

[Aashay]

hey Vidar Berg thanks so much for these. So i tried them out on tera term to confirm that they work and they do work correctly. so i used this configuration for the actual data i am trying to pass through the two boards. The program i am using connects and recognizes the boards, but when i try to pass data through, it gives an error saying "nullable objects must have a value". I am pretty sure that this program passes data in hex and many times it sends NULL, which is 0x00 in hex. I predict that our code isnt sending this properly. it might be not sending NULL altogether, which might be why there is an error? any recommendations on what to do or where to start? If my explanation doesn't make sense, just let me know. i can try to explain it better.

[Vidar Berg]

Hi,

It sounds like there may be a bug in the program you use, and based on the error, I guess you have access to the source code. I would suggest to debug the program and figure out where "nullable objects must have a value" gets returned.    

[Aashay]

Hey, so i was thinking of a possible way to alter the timer. I wanted to make the timer so that it is dependent on the input rather than being a continuous timer loop. As of right now, I have the interval at about 50 ticks ( 50 ms ), and it seems fine but i feel changing this would fix some of the problems I am having. If i wanted to make it to where, everytime a character/bit of data is added to the array, the timer is reset. so as long as data keeps coming in, the timer keeps resetting. When the last bit of data were to come in, there would not be another for it to reset the timer. This is where the timer could turn on and send the data array at the end of the interval and stay on until the next bit is received and resets the timer. Is this possible at all. It seems simple in terms of logic but im sure it could be troublesome in the syntax.

[Vidar Berg]

Hi, you can try to call app_timer_stop() followed by app_timer_start() in the APP_UART_DATA_READY event. This should restart the timer every time you receive a byte on the UART interface. 

[Aashay]

ok thanks so much. One more question. So using the app timer examples for both central and peripheral on teraterm, I used the send file option where I prerecorded characters on a .txt file. well both boards send the file as long as it is only 19 characters or less. if it goes above 19 characters, the uart restarts. how can i increase this size to something bigger?

[Aashay]

additional update.Vidar Berg so the 19 character limit was before i incorporated the stop and start in APP_UART_DATA_READY. After using this, the functionality i am looking for works great. but in the send file option this character limit was brought down to about 4 characters. any more and it restarts the uart. So basically without the start & stop in the uart_event_handle the limit is 19 bits and with the start & stop, the limit is roughly 4 (i didn't test exactly. I tested 4 and it works and tested 8 and doesn't work so somewhere in between). so what would be causing this? and how can we make this limit bigger so that I can send files that can be at least a few dozen characters?

[Vidar Berg]

Debug logging should be enabled in the example projects, so you can use that to determine why it resets. I guess you will probably need to use easyDMA or flow control to receive larger chunks of data reliably.