GoBLE Remote Control – WICED Bluetooth Implementation


I will be teaching a video training workshop for Mouser on October 24. In the class I am going to show a bunch of Bluetooth things running on PSoC6 with WICED.  Given that Bluetooth has two sides of a connection I wanted something that people could download from the iOS App Store to interact with my PSoC6/4343W design that looked like a remote control.  And, I found a program called GoBLE which was developed by a company called DF Robot to control their robots.  Here is a screenshot from my iPhone where you can see that it has four buttons on the right, a joystick on the left and two buttons in the middle.

I watched their youtube video, and it seems great… but how does it work?  And how do I make a WICED Bluetooth project to work with it?

GoBLE Documentation

So, how does the App work to send button/joystick commands?  Well, if you press the little “i” in the App, it will take you to this screen.  You can see that it sends a variable length packet of data that tells you which buttons are being pressed and where the joystick location is in x & y.  OK… but that doesn’t really tell you what to do on the Bluetooth Peripheral side.

If you look around on the internet you will find on GitHub a place where they tell you what the BLE Services/Characteristics need to look like: (sort of).

What they appear to have meant is that the SerialPortId and Command Id Characteristic need to have the GATT properties Read, WriteWithoutResponse, Write and Notify properties and that you need the Client Characteristic Configuration Descriptor for both Characteristics.  In the WICED application (that I will show you in the next section) that I build to test the remote control, they do not appear to use the CCCD or Read properties.  In addition they only use the Serial Port Id characteristic.  In fact if you do not include that Characteristic, it will still work.  The bottom line is that you database should look like this (in WICED).

The good news is they do service discovery and didn’t depend on a hardcoded handle.

WICED 20719 Implementation

Start by using the Bluetooth Designer to make a new project for the 20719-B1, which I will run on a CYW920719Q40EVB_01.

Click on the add Service button.

Add a Service Name as GoBLE, and then type in the UUID for the service, 0000dfb0-0000-1000-8000-00805f9b34fb.  Notice that you need to do UUIDs as little endian.

The next step is to add a characteristic.

Name the Characteristic SerialPortId and setup the UUID  0000dfb1-0000-1000-8000-00805f9b34fb (once again little endian)

Now you need to configure the Characteristic properties to match the specification.

After all that is done, press the generate code button to build the project.  Now you will need to edit a little bit of code.  Start by enabling the PUART.

The iPhone App recognizes you as a peripheral by seeing the Service UUID advertised.  Unfortunately whoever wrote the advertising packet parser assumed that the Service UUID was first (which it doesn’t have to be).  If you notice I added the name of the device to the advertising packet… but while I was trying to figure that out I put a #if 1 / #endif around that part of the packet.  (notice that on line 178 I modified it the number of packet elements to be 3.

When the App writes to the 20719 you will get a callback in the function “goble_server_callback”.  To figure it out I print out the raw data, as well as the parsed version.

In the file wiced_bt_cfg.c modify the advertising duration to “0” which means never timeout.

Now that is all done I can program the development kit.  The phone immediately recognizes the kit.  And, when I press the buttons you can see that they are printed out.  You can see that I pressed two buttons at a time to start, then I moved the slider around.

OK.  All good.