I have the following queries regarding BLE peripheral on Arduino 101 :
Is is possible to advertise any characteristic value(dynamic data) rather than the UUID in the advertising packet. If so what are the APIs for that? My goal is to get any temperature data in the adv packet instead of connecting to the peripheral.
Current Observation: I was only able to advertise service uuids and local name using the APIs setAdvertisedServiceUuid and setLocalName.
2.In the following code I was able to start and capture the advertisement in the first instance but in the letter instance the begin had a false return value. Am I doing anything wrong? The idea is to start and stop the advertisement and may be even change the advertisement data.
#include <CurieBle.h>
void setup() {
// set LED pin to output mode
pinMode(ledPin, OUTPUT);
Serial.begin(9600);
}
void loop() {
//BLE Peripheral
BLEPeripheral * blePeripheral = new BLEPeripheral;
//Set the Local Name
blePeripheral->setLocalName("MyDevice");
//Start Advertising
blePeripheral->begin();
//Run the advertisement for 20 seconds
delay(20000);
//Stop the advertisement
blePeripheral->end();
//Delete the BLE Peripheral
delete blePeripheral;
//Wait 5 seconds before starting the next adv
delay(5000);
}
A followup observation/question: Reading the _advDataInit() function in 1.0.4 CurieBLE/src/BLEPeripheral.cpp, it looks like the Curie library Advertising code supports only a Service UUID and a Local Name. It doesn't look like it supports other Advertising fields, such as BLE Service Data. Meanwhile, after a quick skim of sandeepmistry's library, it looks like that library might support more Advertising fields.
I'm interested in writing an Eddystone beacon implementation for Curie, but that protocol requires Advertising support for BLE Service Data. A Curie-based Eddystone beacon would be able to participate in Google's Physical Web project.
Supporting BLE-Standard Advertising fields would also enable more Curie BLE uses - lower-power, connectionless uses where data is provided in the Advertising packet.
Any idea when CurieBLE will support more BLE Advertising fields? ...in particular the ones necessary to support the Eddystone Beacon protocol or iBeacon protocol?
Thanks,
Brad Needham
Full Disclosure: I work at Intel, but not in the Curie group.
These pin definitions are not necessary with the 101. If you look at the heart rate monitor example there are no pin definitions needed for the 101.
These pin definitions are specific to arduino code where you have a ble break out board or some such hardware attached to an Uno or some such board, for example the Adafruit BluefruitLE board.
Thanks govkn. Really new to realm of BLE except for the HC-06 which is relatively transparent as you know. So this one is a going to be a learning curve from hell.
Me too!!! Brutal. I thought it would be as easy as using the serial library. I understand why the choice to use BLE was made as this is the standard of mobile device/iot communication, but I think it does make it quite a challenge to makers like me who are not trained engineers.
I have found that the nRF Master Control app for my android tablet is a great tool to monitor what is going on, baudot has posted a tutorial on this: https://forum.arduino.cc/index.php?topic=376495.0
I have been working with Evothings ( www.evothings.com ), and I now am able to control 4 leds and 2 servos modifying one of there example program. I can share the code if you are interested, but it is real ugly right now, nothing I am proud of, but it does the trick. I am now trying to read the "output" from a pot attached to A0 by modifying another of their examples, not working yet, but I am close
What I am actually trying to do is to get it to stream a packet of sensor data - accel, gyro, magnetometer, gps and quaternion to a PC or even the android. Looking at Mavlink to make this easier. I did find that there is a _uart service based on the review of the referenced lib and the adafruit lib. However, it would require me to go through it and remove references to the board pins to get it working so I shelved this as I have a couple of other projects going. By the way I did check that my PC does recognize the 101 Bluethooth and I can pair up automatically without going downloading the apple xcodeproj files. Oh, well.
Thanks for your help and the reference to the tutorial.
I tried to use some of the python based/python wrappers for BLE so I could get data back from the curie/101 to my desktop/laptop but to no avail. I spent many hours in frustration and didn't get very far. . . I feel your pain. My feeling is that the most mature BLE solutions are those which connect a peripheral/device/thing/edge to a mobile device, phone, tablet, etc. because this is what BLE connectivity is supposed to be all about, and therefore the desktop solutions are not all that well developed. Just my opinion. . .
I just posted a much cleaned up and commented version of the evothing things app to control leds and servos.
This is a one-way only app, the mobile writes to the servo and led characteristics to turn them off and on. I have been working on another evothings app which controls and led and read the output from a pot on A0 and have it graphing data on the mobile from the pot, however it seems like I am only getting the first or last 8 bits of a 16 bit number to graph at this point. . . When I have this up and running( and cleaned up) i will post here. However I am hoping someone will beat me to it and I can just cut-and-paste their code!
You are probably right about the maturity for desktop solutions with the Arduino 101. It just seems that there is a lot of work involved to get it up and running. Just looking at the literature and the services available it all appears to revolve around using the curie ble as a wearable. Why do I say this? I was going through some of the Nordic stuff, some of there available libraries and services and it appears these devices are a lot capable. For instance there is a uart service that might make things a lot easier for both desktop and laptop. It appears to be implemented in several other libraries but not here. So I am pretty much going to throw in the towel on BLE until things mature a little. I have several other coals in the fire :).
I am going to continue to follow the posts either way to see what progress there is and since I am stubborn I will probably continue to tinker with it.
So to be clear, my issue is not with the curie/arduino101. The BLE has worked well from the start. The examples and libraries are well written and easy to use. Using the nRf master control app, I can see the service, characteristics, etc.
However, it is working on the recieving end that has caused me trouble. It is away from the thing, edge, device that is the problem. The solutions I have looked at either do not work for me or are completly specific to a particular platform.
The one platform I have had the most luck with is evothings. It serves up javascript/html/css apps from your desktop to a phone and uses a cordova based librarie(s) to access BLE on the mobile. The javascript/html part allows you to customize to your hearts content.
I have also tried PhoneGap, and the HeartRateMonitor sketch for the 101 works with the heat rate monitor example from Don Colman's libraries:
Don't give up hope! It not the curie/101, it is all the possibilites on the other end that is the issue, hey I now have a reason to learn javascript, what the heck is a closure anyway. . .? :o
This chip and board are wicked powerful. I don't think there is a lot out there that is comparable, esp. for the price and I have a feeeling we are near the bleeding edge and there is more to come.
I haven't even looked at the real time clock stuff, but see there ae libraries on github for this!
I should be posting an example of receiving data from a pot attached to A0 shortly with evothings. This platform runs on windows, so give it a try. I had it up and running the hellow world example on mac and linux within minutes. The code I posted prior works on this platform, if you don;t have the motor board, you can just comment out that portion and attach some leds. . .
Please don't get me wrong. I rather like the Arduino 101. There are a lot of possibilities. The frustration is that is basically I like ability that SPP gives me for simple interfacing. Almost all my efforts have been through Processing. I haven't given up but just frustrated.
I was able to run a sketch that implements the UART service and it works fine when I use the nrf uart app on the droid. What I want to do is get the data into the desktop for further processing. I did find this info that you might be interested in that I posted in another thread:
I will definitely dig into you evothings and the code samples and give it a try. The only thing that is slowing me down is an upload issue to the board - that seems like it is a loader issue rather than a board issue. It works sometimes and as long as I leave the ide open I can keep going back and forth - oh well.
Anyway thanks for your patience with me and providing me with some very valuable info on getting this up and running.
