I have a Duemilanove and ADK and I followed this and with the exception of some SDK updates, I followed it exactly.
Problem: the onboard LED doesn't blink but is always on.
Issues:
byte array is being successfully sent to the ADK from the phone, verified by monitoring serial port of arduino board
High & low signal is being properly handled in the arduino code (same verification).
the blink tutorial without the ADK blinks the on board LED properly.
So, what is wrong? Is it possible that the ADK board is always sending a HIGH signal to the on board LED and I need to use an 'external' LED for testing? A lot of the tutorials I've seen do this so could that be why?
Try to write a small blink program, just to check that everything is alright in your ADK board.
The onboard Arduino LED is on initially. It looks like it is never being turned off.
In the linked instructions, under the section How To Receive Data From The Android Device , the first line of the loop() function is:
byte msg[0];
Then to receieve data in the call to AndroidAccessory.read() the value sizeof(msg) is used to determine how many bytes to read.
However, because msg was defined to be 0 bytes long, no bytes will be read, len will be zero and the LED will not be updated.
Instead, try changing the line to:
byte msg[1];
I haven't used the shield you are using but it looks like it uses SPI for communication. SPI uses pin 13 for the serial clock signal (SCK). Given this I would expect the SCK signal may be interfering with you trying to control the LED.
I would suggest trying to wire an LED to a different digital pin such as pin 8 and update the Arduino sketch to use pin 8. This would remove the possibility of conflict.
Related
Long Description:
I have a DJI Osmo Mobile 3 gimbal with Bluetooth 5.0, which supports ActiveTrack 3.0 technology. It connects to your phone via Bluetooth and using the DJI Mimo app you can select an object and track it.
I want to implement this technique in Python using OpenCV.
As I understood, the phone calculates position of the object using computer vision and then sends the coordinates via Bluetooth to the gimbal, which then follows them. I connected to the gimbal with NRF Connect app for android and looked for its services and characteristics, and this is what I found:
Services
Some unknown information getting sent
UPD: looks like the 4 bytes after 57 on the picture mean the joystick values. Fisrt 2 are responsible for left-right tilt, the other ones indicate up-down state. Looks like all of them can be max. 256, but I don't understand, why do they need 2 bytes for each action?
First 2 Bytes:
d2, 03 (210, 3) - full right
c2, fb (194 251) - full left
Last 2 Bytes:
5a, 04 (90, 4) - full up
a6, fc (166, 252) - full down
HID Control, which doesn't return any information
The characteristic with UUID
0xFFF5
Looks like what I need, but now I need to find out, in which format the coordinates are getting sent. For this purpose I want do simulate same BLE services as on the gimbal and let the phone think it is a real one. After the connection it should send data to some of the characteristics. So now the main question.
Main question:
How to emulate BLE Services and their Characteristics using Android, RPI, ESP32 or whatever to get data being sent to those characteristics? Is there any app, library or piece of code for such purpose?
I've seen dongles like CC2045, which are designed to work on 2.4GHz frequencies and sniff BLE Traffic, but it will take for a long time for them to arrive to me. Also nRF52840 based donglas are not an option right now. So I want to implement it using things I have. Is it possible? Thanks!
I'm writing an BLE application, where need to track if peripherals device is advertising or has stop.
I followed getting peripherals without duplications this and BLE Filtering behaviour of startLeScan() and I completely agree over here.
To make it feasible I kept timer which re-scan for peripherals after certain time (3 sec). But with new device available on market(with 5.0 update), some time re-scan take bit time to find peripherals.
Any suggestion or if anyone have achieved this?
Sounds like you're interested in scanning advertisements rather than connecting to devices. This is the "observer" role in Bluetooth Low Evergy, and corresponds to the "broadcaster" role more commonly known as a Beacon. (Bluetooth Core 4.1 Vol 1 Part A Section 6.2)
Typically you enable passive scanning, looking for ADV_IND packets broadcast by beacons. These may or may not contain a UUID. Alternatively, you can active scan by transmitting SCAN_REQ to which you may receive a SCAN_RSP. Many devices use different advertising content in ADV_IND and SCAN_RSP to increase the amount of information that can be broadcast - you could, for instance, fit a UUID128 into the ADV_IND followed by the Device Name in the SCAN_RSP. (Bluetooth Core 4.1 Vol 2 Part E Section 7.8.10)
Now you need to define "go away" - are you expecting the advertisements to stop or to fade away? You will get a Receive Signal Strength Indication "RSSI" with each advertisement (Bluetooth Core 4.1 Vol 2 Part E Section 7.7.65.2) - this is how iBeacon positioning works and there's plenty of support for beacon receivers in Android.
Alternatively you wait for N seconds for an advertisement that should be transmitted every T seconds where N>2T. The downside of the timed approach is that probably not receiving a beacon isn't the same as definitely receiving a weak beacon; to be sure you need N to be large and that impacts the latency between the broadcaster being switched off or moving out of range and your app detecting it.
One more thing - watch out that Advertising stops if something connects to a Peripheral (if you really are scanning for peripherals) another good reason to monitor RSSI.
First scenario: Bonded Devices
We know that if a bond is made, then most of the commercially available devices send directed advertisements in during re-connection. In situations such as this, according to BLE 4.0 specification, you cannot scan these devices on any BLE sniffer.
Second scenario: Connectable Devices
Peripheral devices are usually in this mode when they are initially in the reset phase. The central sends a connect initiator in response to an advertisement packet. This scenario offers you a lot of flexibility since you can play around with two predominant configuration options to alter connection time. These are: slavelatency on the peripheral and conninterval on the central. Now, I don't know how much effort it's going to take get it working on the Android platform, but if you use the Bluez BLE stack and a configurable peripheral such as a TI Sensor tag, then you can play around with these values.
Third scenario: Beacon devices
Since this is what your question revolves around, according to the BLE architecture, there are no parameters to play with. In this scenario, the central is just a dumb device left at the mercy of when a peripheral chooses to send it's beaconing signal.
Reference:
http://www.amazon.com/Inside-Bluetooth-Communications-Sensing-Library/dp/1608075796/ref=pd_bxgy_14_img_z
http://www.amazon.com/Bluetooth-Low-Energy-Developers-Handbook/dp/013288836X/ref=pd_bxgy_14_img_y
Edit: I forgot, have you tried setting the advertiser to non-connectable? That way you should be able to get duplicate scan results
I am dealing with a similar issue, that is, reliably track the RSSI values of multiple advertising devices over time.
It is sad, the most reliable way i found is not nice, rather dirty and battery consuming. It seems due to the number of android devices that handle BLE differently the most reliable.
I start LE scan, as soon as i get a callback i set a flag to stop and start scan again. That way you work around that DUPLICATE_PACKET filter issue since it resets whenever you start a fresh scan.
The ScanResults i dump into a sqlite db wich i shrink and evaluate once every x seconds.
It should be easy to adapt the shrinking to your use case, i.e. removing entries that are older than X, and then query for existance of a device to find out if you received a ScanResult in the last X seconds. However dont put that X value too low, as you must take into account that you still lose alot of advertisement packets on android LE scan, compared to a BLE scan on i.e. bluez..
Edit:
I can add some information i already found for speeding up the performance on Advertisement discovery. It involves modifying and compiling the bluedroid sources and root access to the device. Easiest would be building a full android yourself, i.e. Cyanogenmod.
When a LE scan is running, the bluetooth module sends the scan sesponse via HCI to the bluedroid stack. There various checks are done until it finally gets handed to the Java onScanResult(...) which is accessed via JNI.
By comparing the log of the hci data sent from the bluetooth module (can be enabled in /etc/bluetooth/bt_stack.conf) with debug output in the bluedroid stack aswell as the Java side i noticed that alot of advertisement packets are discarded, especially in some check. i dont really understand, beside that it has something to do with the bluedroid inquiry database
From the documentation of ScanResult we see that the ScanRecord includes the advertisement data plus the scan response data. So it might be that android blocks the report until it got the scan response data/ until it is clear there is no scan response data. This i could not verify, however a possibility.
As i am only interested in rapid updates on the RSSI of those packets, i simply commented that check out. It seems that way every single packet i get from the bluetooth moduly by hci is handed through to the Java side.
In file btm_ble_gap.c in function BOOLEAN btm_ble_update_inq_result(tINQ_DB_ENT *p_i, UINT8 addr_type, UINT8 evt_type, UINT8 *p)
comment out to_report = FALSE; in the following check starting on line 2265.
/* active scan, always wait until get scan_rsp to report the result */
if ((btm_cb.ble_ctr_cb.inq_var.scan_type == BTM_BLE_SCAN_MODE_ACTI &&
(evt_type == BTM_BLE_CONNECT_EVT || evt_type == BTM_BLE_DISCOVER_EVT)))
{
BTM_TRACE_DEBUG("btm_ble_update_inq_result scan_rsp=false, to_report=false,\
scan_type_active=%d", btm_cb.ble_ctr_cb.inq_var.scan_type);
p_i->scan_rsp = FALSE;
// to_report = FALSE; // to_report is initialized as TRUE, so we basically leave it to report it anyways.
}
else
p_i->scan_rsp = TRUE;
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.
i cannot understand, when i trying to configure and connect bluetooth with my android device.
(i used bluetooth HC-05 from lc-technology and Arduino Mega 2560)
I’m trying to connect the arduino and android with bluetooth but it failed.
This is a code for arduino
char incomingByte;
int LED = 12;
void setup (){
pinMode(LED, OUTPUT);
Serial.begin(9600);
}
void loop(){
if (Serial.available()){
incomingByte = Serial.read();
if(incomingByte == '1'){
digitalWrite(LED, LOW);
}
if(incomingByte == '0'){
digitalWrite(LED, HIGH);
}
}
}
I try to send data from bluetooth device (i use Bluetooth Terminal and BlueTerm) to Bluetooth Arduino and never give a response
i've been trying to uses another pin for tx & rx on Arduino Mega 2560, but it never give a response.
Does someone have a solution on that problem ?
Thanks before for your help. I'll apreciate you for your help.
The software you provided is working.
I had exactly the same problem as you reported, with Arduino Uno and the Bluetooth module from the same maker.
After many test I came to the following conclusion: the problem is in the Bluetooth module itself cause it doesn't properly manage the tension levels of the TX pin. You don't see any response cause Arduino can not handle the tension levels from the bluetooth module.
You find more informations about my tests at the following link:
Arduino Forum
A picture of the tension levels of an HC-05 Bluetooth device Tx pin (from 3.1 down to 0 Volt)
In the next picture the tension levels of the HC-05 Bluetooth device Tx pin of the maker you and me have used (from 3.3 down to 1.7 Volt), note that the signal can't go down to 0 Volt
Check the following things:
If you are trying to light up external LED at pin 12 then it is OK.
But in case you are trying to light up the on-board LED, it is pin 13.
Check the baud rate you are using in the device to send data.
It must be same as the one used in the code.
The HC-05 can operate in a wide range of baud rate (check Google).
By default it's programmed to 9600.
If somehow yours is different, you'll have to reprogram it (again check Google to see how).
It's irrelevant to say this but 1 represents logic HIGH and 0 represents logic LOW.
Although it's up to you to program the way you want, but still it's best to follow the convention to avoid confusion.
I would like to remotely reprogram my Arduino via Android over Bluetooth SPP. The first step is to reset the ATMEGA microcontroller. This is accomplished on the Arduino by toggling the DTR line. Is there any API to control the Bluetooth SPP control lines from the Android environment?
Also it is supported by SPP in general to send or receive the control signals (DTR, DSR, RTS, CTS) I do not know any API or library for android right know, but as you just want to reset your controller...
If it is o.k. for you to change your firmware you can also create your own reset-command that can be received on your UART (over SPP).
If you receive that command you could call something like
asm("jmp 0x3800");
where you have to modify the jmp-address to point to your bootloader.
You also might want to change your interrupt vector to point to your bootloader.
Or enable your watchdog and call
while(1);
This will also automatically change the interrupt vector to the bootloader's interrupt vector and reset all SFRs. - But it is a little bit slower and the bootloader's interrupt vector must be choosen in the Fuse Bits.
I realise that this is not what you wanted, but you could always flash a new bootloader with a longer timeout and manually press the reset button before starting programming.
The new Arduino bootloader (optiboot) fits in 512B (versus the 2K of the old one) so you have extra space available to your projects; has smart boot detection, so it only enters the bootloader when the reset button is pressed; and you can extend the timeout by editing the watchdog timeout value in the source (around line 267 in optiboot.c).
// Set up watchdog to trigger after 500ms (changed to 2s!)
watchdogConfig(WATCHDOG_2S);