I am trying to control an LED via RN4871 BLE from microchip (http://ww1.microchip.com/downloads/en/DeviceDoc/50002466B.pdf) and I would like to provide brief pulses (below 10ms).
For this purpose I installed gattlib package for C from https://github.com/labapart/gattlib
First on my RN4871 side I define a characteristic with Write property (Write value of characteristic with acknowledgment from client to server) and using the read_write.c example from the library works just fine.
However, since I want to have a fast communication to provide short pulses of LED then I have to use write without response function. On my BLE device side, I create only one characteristic with the property of "Write without response" and associate the digital out with the UUID handle.
PS,59c88760536411e7b114b2f933d5fe66
PC,59c889e0536411e7b114b2f933d5fe66,06,01
and for the script:
#PW_ON
SHW,0072,18
#CONN
|O,08,%0072
Now when I use the example from the library (nordic_UART) to have write without response, it fails. I removed the parts for notify and rx. I am only using the tx uuid.
My question is more on the basic level, am I following the right direction for configuring my BLE device for write without response? Should I add additional characteristics (like notify)? Or the problem is how I am managing the gattlib package examples?
Related
I am trying to read ECG real-time data from a movesense sensor by using another generic BT-LE module.
GATT characteristics can be used for Heart Rate (read or notify) or other predefined services : we simply send a raw command to an endpoint, for example a 0x0100 (START_NOTIFY) on the corresponding UUID for a heart rate notification streaming.
The problem is that with a micro controller and a BT LE module we can not use any of the C, Java, React... libraries since all of the underlying code is not open source ( the movesense device-lib and community-lib do define how to use and program the services, but we can not discover what to send on one of the 2 other services that are defined, the UART service or the Unknown Service, which are probably used by the movesense library to send all of the URL requests).
As a footnote, we access our generic BT-LE module with AT UART commands to communicate to the movesense platform.
Thanks for any help or guidance,
FS
Have you looked https://bitbucket.org/suunto/movesense-device-lib/src/master/samples/ble_std_services/CustomBleController.cpp
void CustomBleController::OnUartData(uint8_t * p_data, uint16_t length)
for receiving and
send_ble_nus_data(buffer, BUFFER_LENGTH);
to send using NUS (Nordic UART service).
It is possible to do your own GATT service on Movesense sensor (since v. 1.6.0) using the CustomGATTService module. Please look into latest movesense-device-lib and the sample "custom_gattsvc_app" (and with 2.0, the "gatt_sensordata_app")
Full Disclaimer: I work for the Movesense team
We are looking at using the Telit BlueMod+SR chip in a hardware idea we are working on. Towards that I've been trying to build a Bluetooth Low Energy (BLE) server simulation using the Telit BlueEva+SR evaluation board driven over USB by a Python script.
The two relevant manuals appear to be:
BlueMod+SR AT Command Reference
Terminal I/O Profile Client Implementation Guide (though I'm implementing the server)
(N.B. these are available here but are behind a register/login.)
I'm stuck on something basic: how to send or receive data. I understand that this is done by setting the value of a Generic Attribute Profile (GATT) service's characteristic. The BlueMod+SR already has the GATT service characteristics that I need (a UART data TX characteristic and a UART data RX characteristic) on its Terminal I/O Service. The UUID's of the characteristics I need are given in the Terminal I/O Profile Client Implementation Guide but I cannot see how to read from nor write to them. The AT Command Reference has a section on GATT Server commands but the only one listed, +LEATTRIB, is for defining the attributes for a service (and the ones I need are already defined).
What are the commands I need to read and write the values for the characteristics UART Data TX, UART Data RX, UART Credits TX, and UART Credits RX?
It turns out that I did not need to use the credit mechanism, that's handled for me. So to write to the TX characteristic I can either connect to BLE and just write the data, or use the multiplexing and write the data to channel 0x01 (Terminal I/O). Reading the RX characteristic si similarly just reading the serial connection.
I tried looking everywhere to understand how BLE pairing works but unable to find answers. Lets say I have a small device, like a raspberry pi with a BLE dongle. What I'd like to do is to allow BLE pairing and then subsequent communication with a BLE peripheral (such as a BLE temperature sensor) using software only.
My aim is to try and see if I can control the pairing and then getting the temperature, without touching the sensor at all, so that in future, I can just remotely log into the raspberry pi, turn on bluetooth, obtain the temperature reading and then afterwards turn it off again. And in future if I need to obtain the reading again, I'll repeat the process.
So:
Can this "simple" scenario be achieved using some software based control?
If not, then which parts require manual input and then which don't?
The BLE sensor should not be in advertisement mode or broadcasting the information. It should only send the data to paired devices.
Any and all answers appreciated! :-)
Most Bluetooth low energy devices do not require pairing at all so check first that your sensors do have this requirement. If they do then you need to determine which specific pairing procedure is required. Bluetooth defines various ways to authenticate during pairing and these generally relate to the I/O capabilities of the two devices and are called Association Models. In some cases, pairing "just works" (the name of the simplest association model) and no user interaction is required. In others, say if one device has a keyboard but the other has a display and no keyboard, the second device will display a random 6 digit number and the user must key that number into the first device. All of this is defined in the Bluetooth Core specification.
In your case the pairing procedure will be defined for your sesnors in the manufacturer documentation so check there first. Not that you should only have to do this once per device, not every time you want to read the sensor.
Accessing sensor data remotely needs a gateway which I guess is what your Pi will do. The Bluetooth SIG defined a set of RESTFul HTTP APIs for exactly this purpose. See https://www.bluetooth.com/develop-with-bluetooth/white-papers
The SIG also provides a gateway developer resource for Raspberry Pi which you can download including source code which is written in node.js. See https://www.bluetooth.com/develop-with-bluetooth/developer-resources-tools
Good luck
Being somewhat of a newbie I was wondering if there is a way to hard-code something on a peripheral that would only allow a single unique central/master to connect.....?
i.e. / eg
I have the ‘simple chat’ Arduino app on a RedBearLab Blend-Micro (which is for all intensive purposes the same as a Arduino Uno with a BLE shield) and I only want one single / unique phone to BE ABLE TO connect with it and therefore work with it.
My understanding is that the GAP handles security features during a BLE connection.
Therefore, is there some way to ‘code’ the peripheral device in / below one of the following includes:
spi.h ?
boards.h ?
EEPROM.h ?
RBL_nRF8001.h (or similar) ?
Other?
Didn't quite get an answer from Restricting the BLE peripheral device to connect to only one Master
OR
Am I stuck with EVERYTHING connecting but coding the peripheral in some other way in a GATT profile (I think) to ONLY do something with a predefined unique central/master (how/where to code?).
Many thanks for thoughts in advance
Being somewhat of a newbie I was wondering if there is a way to hard-code something on a peripheral that would only allow a single unique central/master to connect.....?
Theres the "Advertising Filter Policy" as specified in the Bluetooth Core V4.0 specification. Its a Byte in the Advertising Parameters as specified in Section 7.8.5 LE Set Advertising Parameters Command.
For example the value 0x02 reads Allow Scan Request from Any, Allow Connect Request from White List Only.
Then theres section 7.8.16 LE Add Device To White List Command.
That said, if your device confirms to the Bluetooth 4.0 specification, it should support these HCI commands. However there might be functions that simplify these procedures, wrapping those HCI commands for easier use. Check the Documentation of your device for such methods.
Good Luck!
I was asked to answer this question via email. It's been almost a year since I quit working on BLE. So I only answer this question based on my memories.
Basically #dominik has it right.
If the device is freshly new, it should advertise normally (without setting the whitelist only bit), then any central device could connect and bond. Once it is bonded, you should save this bonded flag and the bonded master's bd_addr to EEPROM. If the next time the master is lost, you will advertise with that white-list-only flag set. If a new central tries to connect, you could verify if its address is the same as your master.
I don't have the BLE spec at hand and I kind of forgot a lot about BLE already. Probably the spec says somewhere that if a central sees a peripheral device is broadcasting with white-list-only flag set, it wouldn't try to connect if it doesn't recognize that peripheral device. This saves both some effort.
But a master could always initiate a connection to your peripheral device regardless the white-list-only flag. So checking if the connecting central device's address is the same as your previously bonded master is the last resort.
[Update]
I used CSR1010 chips. I remembered that the BLE stack actually allows me to insert a list of bd_addr to the white-list data structure maintained by the stack. Then, with the white-list-only flag set, the lower-level stack layer will help you filter devices that are not in that white-list without your knowing.
However, you can always filter bd_addrs from your application code.
I am trying to write a Labview program that takes input from a thermal sensor on serial port RS - 232, applies some basic transformation to it, and displays it on a screen.
I'm wondering if it is possible to somehow simulate the sensor in labview, or by using some external simulator application so I can test my program before I'm given access to the actual hardware.
Is this possible?
I have Labview 2011.
The quickest way to test your VI's logic would be to make a CSV file of example data, and temporarily replace the section that reads from the sensor with a section that reads data values from the CSV file at the same rate.
It's probably not worth trying to emulate the serial port input at a lower level as Labview is generally very reliable at getting data from hardware into your VI - it's up to you then what you do with it!
You could have another program simulate the sensor and write to a different COM port. Then you could connect these COM ports with a null modem cable.
In order to do so, you'll have to work out how your sensor works and feed data in na appropriate format into that 2nd COM port. These data will end up being received by the 1st COM port and eventually by your application-to-be-developed.
If you encapsulate all of your communications code in a subVI or set of subVI's, separate from the code that does the transformation and display part, you can easily substitute test code and test data for the real sensor data. You could write a subVI that generates the test data and replace it with the real sensor comms subVI later, or you could use a case structure in the subVI to choose between communicating with the real sensor and just outputting test data (which, as Moray suggests, you could read in from a file so that you can easily change it).
I would suggest that you write separate subVIs for opening communications to the sensor, getting a data point from it, and closing the comms port when you are finished (though you can probably just use the serial or VISA close function for that). Chain these VIs together using the comms port (aka VISA session) and error wires. The 'open' VI could take an input that specifies whether real/simulated data is to be used and store that choice in a global variable (or a functional global VI) which the 'get data' VI checks each time it is called.
glglgl's suggestion of sending the simulated data from another serial port is also good; all you need to do here is use the serial send and receive functions in some sort of loop to do the same thing as the real sensor would, in terms of receiving commands and sending an output back. This has the advantage that you don't need to make any changes to your main program which should work exactly the same whether it's connected to the real sensor or the simulation program. However, problems with serial comms in the real world often result from instruments or devices that don't do exactly what their specifications claim they do, so just because your program works perfectly with your simulation doesn't guarantee it'll work perfectly with the real sensor if the real sensor does something you didn't expect :-)
Though the other answers offered some really great ideas, I've found an easier way to simulate sensor input that would be convenient for beginners.
Create virtual serial ports on your computer by using a Virtual port simulator. http://www.eltima.com/products/vspdxp/
Get a Modbus simulator. http://www.plcsimulator.org/
Download Labview Modbus Library. http://zone.ni.com/devzone/cda/epd/p/id/4756
Open the Labview Modbus library and run 'MB Serial Master Example.vi'
Now it should be possible to read/write values into the simulator using the example program.
The Block Diagram of example program can be analyzed to find out how data is being transferred behind the scenes on Modbus protocol.