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

Sending large data from smart phone

Hi,

I need to send large data(about 200KB) from android phone to my custom board.

Connected like this :

Android Phone ->(BLE) -> nRF51822 ->(UART) -> Custom board.

And I'm using ble_app_uart(SDK 12.3.0).

I read other posts but most about sending data from BLE module.

Now I just send data with no flow control or something and I have some problem.

My app is based on UART app in nRF Toolbox.

On Android app, I just read data(hex file) and send.

I want check if it's okay to send data. If okay, send data. If not, wait until okay and send data.

I need some guidence or references.

Thanks for reading my question!

Parents
  • Well simply define some ACK mechanism on application layer which will tell to the phone that it can continue. Yes, it will lower the throughput but you will hardly solve it without wasting one or two connection intervals for this procedure. When I was pushing new FW (100-200kB of data) over the link from the phone I simply sacrificed certain amount of RAM on nRF5x side (you usually have 1kB left, usually more) so mobile pushed all the data there and then waited for Notification (because nRF5x side was GATT Server) with specific code which was saying to continue with another chunk. Indeed this store and forward architecture has some drawbacks and limitations but it should solve your problem easily. If your throughput is limited by the wired UART on emebedded side you shouldn't care that you are adding some overhead on radio transfer...

    This ACK mechanism will typically mean that messages over NUS (at least in one direction) cannot start directly with data but there needs to be some header byte. Then you can just release your wild imagination and e.g. reserve just one escape sequence character like 0xFF or 0x80 or whatever so if it comes first it means that next byte is some special code and not NUS unstructured data which should be sent to upper layer directly (and if next byte is the same then you just cut one of them and send it to upper layer anyway - by this trick you can still transfer any information, just with small probability of being one special character on first position you might loose one byte in the transfer with this overhead, I find it pretty elegant and easy to parse on receiver's side).

Reply
  • Well simply define some ACK mechanism on application layer which will tell to the phone that it can continue. Yes, it will lower the throughput but you will hardly solve it without wasting one or two connection intervals for this procedure. When I was pushing new FW (100-200kB of data) over the link from the phone I simply sacrificed certain amount of RAM on nRF5x side (you usually have 1kB left, usually more) so mobile pushed all the data there and then waited for Notification (because nRF5x side was GATT Server) with specific code which was saying to continue with another chunk. Indeed this store and forward architecture has some drawbacks and limitations but it should solve your problem easily. If your throughput is limited by the wired UART on emebedded side you shouldn't care that you are adding some overhead on radio transfer...

    This ACK mechanism will typically mean that messages over NUS (at least in one direction) cannot start directly with data but there needs to be some header byte. Then you can just release your wild imagination and e.g. reserve just one escape sequence character like 0xFF or 0x80 or whatever so if it comes first it means that next byte is some special code and not NUS unstructured data which should be sent to upper layer directly (and if next byte is the same then you just cut one of them and send it to upper layer anyway - by this trick you can still transfer any information, just with small probability of being one special character on first position you might loose one byte in the transfer with this overhead, I find it pretty elegant and easy to parse on receiver's side).

Children
Related