I have started working with Nordic android SDK. And I have managed to make my sensors-devices subscribe and publish to group I have them assigned to. Problem is that my messages that I should receive in meshMessages doesn't contain enough data. From my device-sensor I have data sent in packed like code bellow.
{
uint32_t srcMac4;
uint8_t remoteTypeID;
uint8_t opCode;
uint8_t statusData[16];
} generic_onoff_status_msg_pkt_t;
I can read data in my meshMessages when I cast them to GenericOnOfStatus. Problem is that I'm receiving only 6 bytes and I should see more like 12 in one message.
How can I make my app receive more byte data in GenericOnOfStatus messages?
I have used Nordic app as guideline for me how to implement code so far. https://github.com/NordicSemiconductor/Android-nRF-Mesh-Library
I have found solution. Problem is with Nordic SDK. They have problem's with their library at the moment. When we try to set unicast address in filter (White or Black listing) somehow it doesn't recognize it as unicast address and that makes app crash. Workaround at this moment until they have it patched is to switch to dev branch of library.
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 a newbie in this forum and I'm not very familiar with app development in general, however I am in the situation in which I have to develop an app to acquire ANT data from 3 nodes. I am basing myself on a previously developed app for Windows in C++ (.exe extension).
I am using a Samsung Galaxy A51 as a mobile phone and my Android Studio API is 29.0.
I am starting with the case of a single node and have implemented the following steps in my app:
bindService() and it returns that it is true;
getChannelProvider() and it returns a name of the channel;
acquireChannel(), with a setup of a default Public network;
assignChannel() to the type of a Shared Bidirectional Master;
open() the channel;
setPeriod() to the user period I chose (1092, corresponding to 30 Hz which is what I want to achieve in order to look for each of my 3 units with a frequency of 10 Hz);
setBroadcastData() with a payload that I need to call one of my units.
At this point, I expect to have sent my broadcast data and I am waiting for an "answer" from my unit. How do I read the message? I am finding many functions that want an AntMessageParcel type as input but I don't know where to get that Parcel from. Also, I am not sure that the logical order of the app is correct or if I need additional steps in between my code.
I thank you for your help.
Have a nice day!
I'm trying to reproduce an ATT packet being sent to a Bluetooth LE device already connected to a phone.
Is this even possible?
I've figured out how the packet should look like, I'm just not able to wrap my head around GATT and how it translates to ATT in this specific case.
The wireshark dump looks like this:
localhost () remote () ATT 26 Sent Handle Value Notification, Handle: 0x0035 (Unknown)
Bluetooth Attribute Protocol
Opcode: Handle Value Notification (0x1b)
0... .... = Authentication Signature: False
.0.. .... = Command: False
..01 1011 = Method: Handle Value Notification (0x1b)
Handle: 0x0035 (Unknown)
Value: 0a0b313233343536373839303132
I've already figured out that the actual application payload here starts after the handle 0x0035, with 0x0a 0x0b being some custom control characters and everything afterwards a number (123456789012), exactly as I expected it to be.
How do I translate the "handle" to the GATT protocol? Is this done in Android GATT via UUIDs? If I loop over all services on that device a get a bunch of services, loads of characteristics, descriptors and I'm lost.
Oh, what I forgot to mention: None of the services and characteristics I get seem to be related to the handle 0x0035.
Is "getInstanceId" supposed to return the handle that will be used? Writing to writable characteristics on that device lead to Wireshark showing the handle value corresponding to the getInstanceId.
first thing you have to know is that in Android you can't use the Handles direktly as a developer. You have to deal with the UUIDs. in Wireshark when you have a look at the ATT Protocoll you should be able to see the UUID of the service and the characteristic when opening the Handle drop down. With this Information you should be able to detect the UUids you need.
https://developer.android.com/guide/topics/connectivity/bluetooth-le shows you how to send a value to a notification. In general you can use Constants for example to ebanle notifications. I guess if your server requires specific bytes you should be able to send them the same way.
Well, after inspecting logs and docs a little more I came to the conclusion that the remote device (which should provide serivces) here is actually using a server on the local host and this is a value notification sent from the host to the remote.
Issues with Android-2-Arduino communication made it clear to me I have no clue which parts of the chain are (directly) affected by the baud rate. Could you please confirm/correct following assumptions?
The 'baud rate' value is not related to anything on the Android side. Therefore it is not a bug when an Android USB/Serial library only sends the baud rate value (9600, 125000, etc.) to the other side via controlTransfer, not storing it anywhere, not setting it somehow to the Android device itself.
When calling usbConn.controlTransfer with 'baud rate' parameter on Android, this command is NOT redundant to me calling Serial.init(baudRate) in the Arduino code. Both these calls are intended for different HW/parts. Both of those parts reside on Arduino. (Both, obviously, must be called with identical value.)
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.