i'm trying to receive advertising data without connect to ble sensor, i used onScanResult function. I logcat the result and then i get:
ScanResult{mDevice=A4:34:F1:3A:AF:XX, mScanRecord=ScanRecord
[mAdvertiseFlags=6, mServiceUuids=null, mManufacturerSpecificData={},
mServiceData={}, mTxPowerLevel=-2147483648, mDeviceName=XXXX],
mRssi=-67, mTimestampNanos=1445086508079000}
the mDevice and mDeviceName and mRssi is correct, then i try to get the mScanRecord, it in byte array format, i try to convert it to hex representation: then i have this result
02010606094D734F6E65000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000
the first problem that the data change just for first time and then stay like this, and the data that i received is not like the original data that i tested in RPI using python script , this is the result of scanning in RPI
a4:34:f1:3a:af:ab,54540400201818000e00000000000000,-74
a4:34:f1:3a:af:ab,5252040313061f015500050000020001,-84
thank you for helping me
The first thing I noticed is 6E in your packet says that ADV packet has 110 bytes of payload data, which is not technically possible or it does not make sense. That is assuming when 0201 is your header (2 bytes) and 0606094D734F is the device address (6 bytes) is correct. You can double check it by scanning your packet using another scanner like your raspberry pi.
See this answer for how;
https://stackoverflow.com/a/22569917/1505341
Something is wrong with the received packet structure there. I'd also check it with a BLE scanner app on android or even on iOS as well just to be sure. Nordic had a good one as far as I can remember. Not sure what's the best app out there these days for scanning raw BLE packets.
Related
I'm developing an app for a custom peice of bluetooth hardware.
The spec for the device has a number of commands which can be sent to the device, via a specific Bluetooth Characteristic.
we are currently using this version of Flutter Blue; flutter_blue:^0.7.2
So far we have it discovering the device, connecting, and discovering the correct services and characteristics.
We also have it sending commands and receving the expected responses.
This works by listing on the correct chartacteristic like so;
await notify.setNotifyValue(true);
notify.value.listen((event) {
_handleEvent(event);
});
and then sending the commnads like so;
await recv.write(command, withoutResponse: true);
(where the command is a List representing the payload bytes).
The problem comes in where a response includes more than one packet.
In this case the inital packet is received but the following expected packets do not arrive.
On ios it's working slightly better in that the inital packet is 4 times the size of the Android response and includes the expected data, BUT if the data is too big it's not included.
I've attempted to modify the MTU but this dosen't seem to have any effect on the issue.
Any help would be greatly appeciated.
In this case the issue was totally releated to the MTU setting.
I was under the impression that if you requested to set it too high it would automatically go to it's highest possible value. But looks like that is not the case.
If you are seeing a similar issue try setting the MTU to 251
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.
We are facing one issue when reading characteristics from remote BLE device.
This issue happen in Android OS 5.0 and above.
Points are below to generate issue :
Make one peripheral device with one service and one characteristics.
Characteristics will have only read permission. Now set the value of this characteristics with more than 20 characters i.e. 20 bytes.
Now let peripheral device broadcast itself with one service and one characteristics.
Now launch any BLE scanner app from market and connect with this peripheral device.
Once successfully connected with peripheral device just try to read characteristics.
In this case it will not show any data and when debugging the app it show that it returns null data.
The above same case not working in the Android OS 5.0 and above.
Same case working in android 4.4.
So there is something change in Android OS 5.0 and above that internally disable readblob() request that can read data having more that 20 characters.
This can be simply achievable by splitting your data into 20 byte packets and implementing a short delay (i.e. using sleep()) between sending each packet.
You can use BluetoothGatt.requestMtu(). See the Official document of BluetoothGatt.requestMtu
Request an MTU size used for a given connection.
When performing a write request operation (write without response), the data
sent is truncated to the MTU size. This function may be used to request a larger MTU size to be able to send more data at once.
A onMtuChanged(BluetoothGatt, int, int) callback will indicate whether this operation was successful.
Requires BLUETOOTH permission.
If you want send more 20 bytes, you should define array byte[] include how many packet you want.
There is an example Android: Sending data >20 bytes by BLE
Also there is another example How to send more than 20 bytes data over ble in android?
Is there someone using blob request (long read) from an android device?
We work with a CC2540 from TI, connected to a android 4.4.
We try to read a long characteristic value (size more than 23 bytes). In the android API for BLE, we have not seen a readBlob or readLong method.
We expect that the Android BLE Stack do the job for us, by reading a characteristic presentation format (same way has notification), but it doesn't works.
We have no idea how to send Blob Request through Android.
Let me make this clear that Android has only one method to read the value of a characteristic, readCharacteristic(characteristic). You can use this method to get the value of a characteristic of any length. Android takes care of forming a ReadBlob request; it's all in the back end. You'd have to change the code of your CC2540 though, to make it work with ReadBlob request. Once you make all the required changes at your CC2540 end, on calling readCharacteristic() from Android, you'll get the entire value of the characteristic which you can access in the onCharacteristicRead() callback.
You canĀ“t, BLE characteristic values are limited at 20 bytes. So if you want to send or receive more than 20 bytes, you have to split it into 20 byte chunks. See this topic on the issue.
I am working on a group project where we are sending serial data over Bluetooth from Arduino to Android. We are all fairly new at both Arduino and Android.
Hardware used include Arduino Uno R3 and HC-05 bluetooth module.
I am sending dummy data for a 3 axis accelerometer packet and successfully read the packet data from Android.
However, we have this blob of data (about 50+ bytes usually and has ranged up to 512 bytes) that always gets sent to the app in the beginning. Its a randomly sized chunk of bytes, which we can't interpret because it doesn't seem to match the packet format we set up for our data. We managed to avoid looking at this byte chunk by checking to see if the packet size is small enough. But this adds a lot of overhead (4 - 5 seconds), so we'd like to figure out what this blob of data is. So, does the HC-05 send some proprietary Bluetooth related data first or is there some thing wrong with my script that's causing the unexpected data to be sent?
This is the Arduino code.
#include <SoftwareSerial.h>
SoftwareSerial bluetooth(10,11);
void setup(){
bluetooth.begin(9600);
}
void loop() {
int x = random(360);
int y = random(360);
int z = random(360);
formAccelerometerPacket(x, y, z);
delay(5000); // wait 5 sec
}
void formAccelerometerPacket(int xVal, int yVal, int zVal) {
printSensorVal('A', xVal);
printSensorVal(':', yVal);
printSensorVal(':', zVal);
}
void printSensorVal(char flag, int sensorVal) {
bluetooth.print(flag);
bluetooth.print(sensorVal);
}
I've looked at it with a Bluetooth terminal app but nothing looks wrong from there. Its LogCat from the app that shows this content received from the app, but I can't interpret it as I said earlier, which is what I need to solve.
I've tried to look at other SO questions but none others could help me.
I don't have the code for the Android app as it is with another teammate, but I know that they followed the BluetoothChat example closely.
The only thought I had was that since Arduino loops the data, if the app starts after the Arduino starts, it might start reading some data part way from what was going on in the serial port before. But it doesn't explain the size difference in the blob of bytes.
Edit on 08/21/2014 at 10:33AM PST
Here is a screenshot of the LogCat. What we did was ran the Android app first and then I started the Arduino to make sure the board didn't have old data. Looking at this makes me think it might be a pairing issue as some one suggested. I am working on trying that fix.
Try Bluetooth SPP on Google Play, then connect to the HC-05. Check the output and then once you get clean data reset the arduino and see what happens. That's how I usually go about checking the output from my HC-05. And no there is nothing sent by the HC-05 when it starts up. I couldn't comment so had to post an answer, sorry.
I am not sure that is your case but may be it's usefull. When you send a data from HC-05(FC-114) to a Slave(HC-06) the first byte(or the first three/four) is sent immediatly and the rest with a delay of 5/10ms. I don't know why, but i see it using oscilloscope. If well managed, you can fix the problem when receive the packet of byte waiting for a while, otherwise, you can get crazy for understand what is happening.