I have an stm32 microcontroller and try to connect to it in Android with a USB library. All of the things are good and can send data and receive data from stm32, but the receiving data is not complete and only receive 20 bytes from the first packet.
I do it via USB UsbEndpoint. Original packet size is 1024 bytes but receiving data are 1024 with a null value. I have read, max packet size is 64 bytes, Is that right?
PS: My main problem is in Android, because in Realterm software, data is being received completely.
Related
I am trying to write a 120 byte data through ble to raspberrypi from my android app(I increased the MTU to the required limit). But all I am able to transfer is first 20 bytes. When I tried to search on the internet, I see that android limits the size to 20 byte for ble transfers and I will have to send multiple 20 byte packets.
But why I tried to end the same data from nrfConnect android app, I see that the data is being transferred without any issue. Can you help me understand how nrfConnect is able to do it with you writing it as packets?
Through the data is getting truncated, i am getting GATT_SUCCESS response from raspberrypi
Just as info, I am able to send 52 bytes to our custom board with nrf52 chip from the same app
Looks like android takes care of writing more than 20 bytes of data.
Below are the two cases that I had:
Case 1:
Android app trying to write data to custom program running in nrf52 chip.
Size of data : 50 bytes.
After increase the BLE MTU on the chip side, the write was successful without any changes from app side.(gatt.writeCharacteristic(characteristic))
Case 2:
Android app trying to write data to ble program running in raspberrypi 3
Size of data 120 bytes.
Issue:Even after increasing the BLE MTU in raspberry pi, when trying to write the data only 20 bytes are received, with successful write response.
Solution: After using gatt.requestMtu(120) and calling the write character in onMtuChanged() callback, was able to send the entire data.
I just try to use the recieve() method of the socket.
When I send the data of a short String,as "send data",for 100
times,the recieve() function performs well.
While I send the data of a long String,as "send data to the
client,send data to the client,send data to the client,send data to
the client,send data to the client,send data to the client,send data
to the client,send data to the client",for 100 times,the recieve()
function cannot performs well.
In android project:
It just recieved about 30 packets, that is, other 70 packets are lost when I use another computer to send pakcets. But I checked the recieve buffer size, it is adequate to contain 100 packets above.
It recieves all the 100 packets when I use the localhost address to test. And I used the capturing tool named wireshark to capture the packets and the capturing tool can capture all the 100 packets everytime.
So I can eliminate the possibility of that another computer did not send all the packets.So I included that the problem exists in the emulator.
The above two cases both happened in android project,so the recieve buffer size is the same,
why in the former it will lose packets??
In java project:It recieves all the 100 packets too.
If you need all the packets then you should use TCP/IP protocol. In UDP protocol you can lose data because it is doesnot support reliable connection like Tcp/ip. UDP is designed to be faster at transferring data at the cost of unreliable connection. Based on network routing the packets you received could also arrive in different order.
Emulator TCP/IP stack's udp buffer size is smaller than the computer. So if the UDP buffer fills up, the emulator TCP/IP stack starts dropping packet. The PC TCP/IP stack pushes data at faster rate which the emulator can't handle. You can try reducing the rate at sender end to avoid filling the emulator buffer or increase the receive socket buffer size of android app to higher value by using the SO_RCVBUF socket option.
I have a question about android 4.4 Bluetooth Low Energy.
I have a BLE dongle with UART Rx pin. I can send bytes data from Rx-pin to BLE dongle, and BLE dongle will send the data to bluetooth host device by indication.
So I have a Rx characteristic value it's property is indication.
I send about 80 bytes data to Rx characteristic, but i only get 20 bytes by once callback function onCharacteristicChanged.
But I use iPad mini to indicate this characteristic value, it receives 4 packets one of 20 bytes data and it seems right.
How can I do to receive 80 bytes data like iOS in Android callback function ?
Try negotiating a bigger GATT MTU. The default is 23 bytes.
The (G)ATT protocol takes up 3 bytes for the header per Notification / Indication.
So 20 - 3 = 20 bytes left by default.
On iOS 8, the maximum MTU that iOS will allow is 158 bytes.
I'm not sure about what Android allows.
I had exactly the same problem - 20 bytes it is a limitation applied to both indications and notifications. It is defined in the Spec, however I am yet to find it.
If your characteristic is not using either indications or notifications then this constraint doesn't apply and all your data will be sent in chunks of MTU-5 see section section 3.4.6.1 of the BT4.0 spec.
The data is sent in chunks of 20 bytes each. So if you want to receive all 80 bytes, then divide the data in 20 byte chunks and send it in a loop. Refer to Android: Sending data >20 bytes by BLE for clarification.
Remember to add Thread.sleep(200) in the loop so that the characteristic is not overwritten.
I'm working on an Android Bluetooth project to send and receive data from a custom made hardware. I used Bluetooth Chat Sample in SDK as basis.
I am sending data from one device to another (LG Nexus 4). All is ok until I reach a length of 1004 bytes (it is the audio data). At that point it splits it into 2 messages of 990 and 14 bytes in most of cases. but is strange sometimes its sending 1004 without splitting (approx. 4 times in 100).
I am sending this packet of 1004 bytes, in which there is 4 bytes is my header and rest of 1000 bytes is actual data which I want to use as per command in header, now if packets are splitting as per above mentioned way than I cannot handle the flow.
So, please let me know why packets are splitting in such way and how can I stop this splitting or, if I cannot do this, than please suggest me any alternative way to do this.
Thanks.
Data sent via Bluetooth socket is abstracted as a stream. Here the transport layer is broken into packets, where packet has a maximum size of almost 1KB(1000 bytes). So you can devise a mechanism in which you can send the message length info in the header, then on receiving side you will have to make subsequent read() calls; each returning data for one packet.
I have an app that sends data over UDP.
I'm trying to find out what is the max/optimal send buffer size.
I have succeedded sending a 2k package, but bigger packets was a problem.
I tried using getSendBufferSize to see what is the send buffer size. It returned 110592 bytes.
When I try to send anything close to it, I dont get an error, but the data dosent get to the server.
How do I know what is the "allowed" send buffer size?
Thanks.
DatagramPacket is just a wrapper on a UDP based socket, so the usual UDP rules apply.
64 kilobytes is the theoretical maximum size of a complete IP datagram, but only 576 bytes are guaranteed to be routed. On any given network path, the link with the smallest Maximum Transmit Unit will determine the actual limit. (1500 bytes, less headers is the common maximum, but it is impossible to predict how many headers there will be so its safest to limit messages to around 1400 bytes.)
Reference : Java DatagramPacket (UDP) maximum send/recv buffer size
I've also encountered this error, it should be 65535 - 28 = 65507 bytes, for DatagramPacket send method's parameter "buffer" size.