Hi. first of all, i’m sorry if my question is too basic, but before using bluz i would appreciate if is possible to build a project in which a bluetooth device (in my case, an emotiv neuroheadset https://www.emotiv.com/epoc/) could be connected to a bluz dk in order to transfer the sampled signals to it, and pthen rocess them, in bluz or in a photon device in a gateway … thanks
There aren’t a lot of details provided on this device, but it would appear it is a BLE peripheral device. This means a DK cannot connect to it as it is also a peripheral, and peripherals can only talk to centrals.
It could be possible to use the gateway to talk to this device and then send data through a Photon, but that would require some low-level firmware changes on the gateway side. Others have attempted something similar, so you could try, but you may want to read this thread which shares some more details about it: Bluetooth sensors like sen.se
Hi @eric, thanks for your answer … could you please tell me where could i get detailed information related to the low-level firmware changes required on the gateway for this purpose?. i would realy appreciate it if it is possible for you. thanks
We don’t have detailed instructions on how to do this, you would need to jump into the source code and start playing with it. This would require changes at the Nordic SDK level, they have great support and documentation on their website: https://devzone.nordicsemi.com/questions/
You would also probably want to pick up more hardware to flash/debug code. An STLink v2 programmer would allow you to flash code directly to the flash, while a USB to Serial converter can be used for debugging. You can buy all for less then $50.
The main file you care about is here: https://github.com/bluzDK/bluzDK-firmware/blob/develop/platform/MCU/NRF51/SPARK_Firmware_Driver/src/client_handling.c as this handles all communication from the gateway to the peripherals. The connection happens here: https://github.com/bluzDK/bluzDK-firmware/blob/develop/platform/MCU/NRF51/SPARK_Firmware_Driver/src/nrf51_callbacks.c#L211
I am also going to ping @newbreedofgeek here, I know he had done some work along these lines and so perhaps he can share his experience. I would personally say this is a bigger challenge, requiring knowledge of C/C++ and embedded firmware development, at the least, along with a lot of patience as there would probably be a steep learning curve.
I’m working using the gateway to connect to various BLE Peripherals along with the DK. Unfortunately there is no detailed walkthrough on this, I’ve been pretty much learning as I go with @eric helping me when I have a major issue.
You will need to work with the Gateway firmware which is built on the Nordic SDK and examples.
A good start would be to get the required dependencies:
(as per here https://github.com/bluzDK/bluzDK-firmware/blob/develop/docs/dependencies.md#1-download-and-install-dependencies)
And building the firmware:
You can then look at the code files Eric mentioned, although I’ve found that adding new BLE Peripherals to existing Gateway logic is far from easy as you have to deal with varying types of BLE Peripheral security and pairing requirements - this is where my project is currently stuck. I’m using the Nordic Dev forums to try and work out my issues…
Hi @eric and @newbreedofgeek, thanks a lot for your answers!. they are very useful in order to know where to start and also to estimate the required effort to modify the the gateway’s firmware. best regards
Yes I managed to get my project working, but it was a long frustrating process that took a few months.
I knew which services/chars to connect to (in the peripheral I was connecting to) but the longest time spent was in working out the pairing and encryption processes.
What kind of problem did you face?
@newbreedofgeek I was trying to connect my bluz gateway to a BLE peripheral which was using encryptionc (the peripheral was a smart home BLE radiator controller). I spent some amount of time sniffing BLE packets and trying to capture the BLE handshake and decrypt the following packets. Went down a rabbit hole and eventually gave up. Would be very interested to hear how you managed to get reverse the encryption; what techniques you used, problems encountered and any advice?
@damkil it is indeed a rabbit hole so tread carefully if you are like me then it becomes an obsession to solve.
Ok, here are some tips for you to get started:
Firstly, you have to know that the bluz Gateway Shield - GWS (I’m assuming this is the Gateway you are using) is in the “central” role.
And it uses a Nordic Semiconductor nrf51 BLE chip.
The GWS is using the standard Nordic SDK to handle the BLE protocol.
Typically, a central needs to “paired and bonded” with a peripheral become any data can be shared.
You will most likely need to “pair” your devices first
There are a few ways this can happen depending on your peripheral but here some MSQ from Nordic that shows you a few ways their chips support:
The above documentation shows the flow of data and the events your firmware needs to listen to etc in various situations.
Again it is not easy to reverse engineer the BLE pairing and bonding phase unless you have some documentation but you can try.
Yes, I would be using the Bluz Gateway Shield in a central role, the plan was to replace the need for a smart phone app which is what the peripheral device works with at the minute. The smart phone app can send a command to the device such as a temperature set point. I want to have the GWS send these commands. The peripheral device appears to use the same Nordics chip (or similar) as Bluz.
I was trying to unearth the raw BLE commands the smart phone app was sending to the device by sniffing the packets, however while I could sniff the packets fine I wasn’t able to reverse the encryption. Maybe I was going down the wrong route and instead look at first trying to par the GWS to the device. Is that what you recommend? The fact that I have found somebody else who has worked on a similar project has reignited my interest. Time to head back down that rabbit hole!
Yes, you need to pair and bond first. During the pairing a short term key is exchanged, after this is successful then a long term key is stored in both devices and this is what is used to recognise a device and encrypt communication thereafter.
Of course the above is very high level and based on my dicovery.
Hopefully your peripheral does not implement some custom encryption.
Also do some research online, there are people who have reverse engineered these process for popular hardware like fitbit etc… you might find what you are looking for.
In my case, I connected to a peripharel that used “just works” pairing and bonding. Which is a simplest level.
@newbreedofgeek - great story so far and I think I’m at a very similar stage.
Would you be able to share any of your preliminary Photon code? I have my GWS up and running and want to try and get it connected to a Thunderboard Sense from Silicon Labs. Obviously there is the necessary pairing required, however the first thing I want to do is to make sure the GWS can see the Thunderboard Sense.
Any code you might have would be good. I’ve got the setup / sample code running which will obviously only return the number of Bluz DK’s out there (of which I have none).
Any help would be greatly appreciated. @eric - any worldly direction on wise one?
Most of the links to the right places are in the post above, so you can follow those to find the relevant portsions of code.
What you want to do is modify where it connects to bluz, and connect to your other device based on the scan data. Then you need to modify the characteristics/services that it listens for. I know that is easier said then done, but the code should be pretty easy to follow and uses the standard Nordic SDK, so you can probably get some help from the Nordic Devzone forums/examples as well if you need it.
@eric - great, thanks for the tips to get cracking on this.
I’ve followed the tutorial on your webpage, as to how to get the GWS started up. How would using the mentioned code above (client_handling, callbacks, etc.) be done with the Particle IDE? I’d obviously have to include all the necessary files at the top of the file…
@newbreedofgeek - do you have anything on Particle IDE that you could share easily? Have you managed to get it working enough to scan and show the results of the scan somewhere?
Unfortunately, that isn’t possible. This requires system-level changes to the firmware which means you would have to clone the repository and local compile that changes that you make. It is certainly more involved, but not something that should be too difficult.
Ok, I see. I’m no expert here (as I’ve only ever used the web IDE) so I’m going to need your help to understand the steps required to upload the necessary firmware. Local compile = easy to do? Upload by USB to Photon? Do I need to connect to the programmer connector on the GWS? What software is required to use to upload the local compilation? I am on MacOSx and so would it be Terminal?
Sorry for all the questions here, it’s not something I’m used to.
What you want to do is clone the firmware repository, then install the gcc arm toolchain from here: https://launchpad.net/gcc-arm-embedded/+milestone/4.9-2015-q3-update and make sure it is installed in your PATH
Next, go into the modules/ folder of the firmware repo and type:
make PARTICLE_DEVELOP=1 PLATFORM=bluz-gw APP=bluz_gateway
That should build the firmware. There will be two files that get generated, the both int he top-level build/target folder. The first is build/target/system-part1/platform-269-m/system-part1.bin and the second is build/target/user-part/platform-269-m/bluz_gateway.bin. If you are only changing files in the system firmware (the links above) then you only need to flash that part. To do that, the CLI is easiest, just do:
particle flash <device ID> build/target/system-part1/platform-269-m/system-part1.bin
This will trigger an OTA update, where the D7 LED will blink like crazy and the system will then reboot and come back online.
This isn’t the easiest way, and if you make a bad firmware file and flash it down, you can stop the shield from working properly. A JTAG programmer will make this easiest, then you can flash away directly without concern for breaking the shield. I would recommend the STLink v2 with an adapter from the 20-pin cable on the programer to the 10-pin header on the gateway shield. Here is an example of the adapter board, not sure if you can find one sourced locally: https://www.adafruit.com/products/2094
And then you need this cable: https://www.adafruit.com/products/1675
We then use a program called Adalink which makes it easy to program the board: https://github.com/adafruit/Adafruit_Adalink
While you can do OTA updates, it can be troublesome and can lead to the board stopping working. The programmer would mitigate all risks, so I would recommend that.
Sorry I’ve taken so long to get back to you on this.
Can you elaborate a little more on exactly how to follow your first couple steps to do the OTA update? I’m using a MacOSx and am not really sure on the terminology of “clone repository”, PATH… am I typing the make PARTICLE_DEVELOP… in terminal?
Would I need to further change any of the two top-level files or is this process more of a reset? One only hopes that after that the Gateway Shield can see the other BLE peripheral and try to connect to it.
I imagine if I’m doing all of this online then I would need to have the board powered and connected to the cloud?
I’m not sure I’m going to be buying all the debugging stuff, to pretty much only use once. I suppose the alternative to this whole thing is to buy a Raspberry Pi which I’ve seen some sample code showing interfacing over BLE. Seems like it might be easier.
Thanks for the help.
Cloning the repository means using git, which is a source code control application, to download the source locally on your own computer.
This is the repository:
On the github page there is a green button that lets you either download or copy a link for cloning. If you have git installed you can copy the link and then paste it in a terminal window. Otherwise, you should be able to download and then unzip the code.
You then need compile the firmware which is done by typing that whole command starting with ‘make’ into the terminal. You need to be in the modules/ subfolder when you run the command.