The original contest proposal was to design small bluetooth low energy digital tokens, useful for prototyping board or card games.


BLE Digital Tokens 


The idea that tokens are useful as health counters, information tokens, or even just a cute updatable fridge magnet. I ended up doing an in-depth exploration of the image-sending component of these tokens. The below is a build log of how I got my computer to push simple bitmap images to my blue gecko digital "token".


Initial Setup

After receiving my devkit, I set to work trying to modify the existing examples. Having no prior experience with SiLab’s 32-bit parts, I was somewhat surprised at how much effort was required to get the toolchain set up. Just following the start guide isn’t quite enough, I also needed to work through QSG120.


One huge thing that I somehow missed was that the EFR32BG only works with the IAR toolchain. That was quite disheartening; working with EFM8 parts feels like a much more polished experience as silabs licenses the required keil compiler for you. Unfortunately, the bluetooth stack & demo does not fit in IAR’s free “kickstart” edition, so I had to register for a 30-day trial. Originally, I had planned to develop a custom small digital token board, but since I couldn’t really justify buying a $3k+ compiler, I decided to just get the proof-of-concept working.


Getting to Hello World

Ok, now that setup's done, I had one last hurdle to clear before I could sink my teeth into the project. I wish that the “getting started” page linked to the necessary documents for getting your own simple application up and running. It’s great for getting things installed, but there’s no good “hello world” tutorial included. The best guide is probably just working through the official FAE training (also mirrored a bit in AN975). Working through that got me to a simple bluetooth example that echos to serial any writes over bluetooth.


Once I got something up and running, I read the full developer guide (UG136) to see how things in the stack fit together.



Picking the Protocol:

Similar to USB, in Bluetooth there are different “profiles” that devices can advertise and implement depending on their function. For instance, there is a heart rate profile, a battery status profile, and an human interface device profile. However, there’s no simple serial communication profile, which would have made streaming image data easier. To the internets!


The community seems to have standardized on an unofficial nordic UART service specification:


<!-- UART Service -->
<service uuid="6e400001-b5a3-f393-e0a9-e50e24dcca9e" advertise="true">
    <description>UART Service</description>
    <characteristic uuid="6e400002-b5a3-f393-e0a9-e50e24dcca9e" id="tx_data">
        <properties write="true" />
        <value type="hex" length="20" />
    <characteristic uuid="6e400003-b5a3-f393-e0a9-e50e24dcca9e" id="rx_data">
        <properties read="true" notify="true" />
        <value type="hex" length="20" />

One nice thing about this unofficial standard is that vendors such as Adafruit have designed libraries and apps that specifically look for this service and allow me to easily communicate with my device. 


With newfound knowledge in hand, my plan was to package up the images on the computer and send them over-the-air to the devkit through this UART service.


Protocol Design


Sending an entire image bit-by-bit would take an unreasonable 100+ packets. In the interest of speed (and laziness), I chose to use a very simple Run-length encoding scheme. For each sent byte, the first bit encodes the color (0 for white, 1 for black), and then the next 7 bytes encodes the number of consecutive pixels of that color (0 - 127). A zero byte indicates the end of the sequence.


Typically, a characteristic value is allowed to be 20 bytes, but I was only able to write 18 byte bursts for some reason, so I decided to just run with it instead of trying to debug what was going on. The first byte in the sequence indicates the command (0x1 to clear the screen, 0x2 to draw a line), and the following bytes are the encoded image data.




Laptop Stack

The last piece of my work is hooking these devices up to the mothership control signal. To my chagrin, a javascript library is the best-supported and least-finicky BLE library. Originally I had struggled with Adafruit’s BLE Library before realizing that they donn't even use their own library in their official desktop app D:


So after resigning myself to fate and rewriting all my code in javascript, I had a fairly basic digital token proof-of-concept.


Behold, bunnies:


  • 32-bit MCUs
  • Projects
  • Wireless
  • Attaching some more code notes for the interested:


    The key to getting everything working smoothly is to first create a callback function that does whatever you want with the incoming BLE packet:



    // my_service.c
    void AttrValueChanged_my_data(uint8array *value) { if(!initialized) { gfxInit(); initialized = true; } switch(value->data[0]) { case 0x01: printf("init\r\n"); gfxClear(); break; case 0x02: printf("blit\r\n"); gfxBlit(value->data); break; }


    And then hook that function into the existing stack via the callback lists in app_cfg.c. Since we want our callback to run whenever an attribute changes, we add it to the appCfgGattServerAttributeValue array:



    // in app_cfg.c
    AppCfgGattServerAttributeValue_t appCfgGattServerAttributeValue[] = { {gattdb_tx_data, AttrValueChanged_my_data}, {0, NULL} };







  • Great share.... and a very nice project Cixlyn


    I purchased a flex Gecko kit to experiment with Thread protocol and was horrified to find that it only works with the $3k5  IAR tool set. So for the moment its just sat there gathering dust waiting for Silicon Labs to release a build that works with their own compiler - I wouldn't have bothered if it was advertised correctly !! 


    Now its a race to see who gets a low cost compiled Thread development kit that doesn't cost the earth - silicon labs or Freescale (Freescale is apparently due in September) ?!?!?!?


    Come on Silicon Labs.... either change your advertising for this product to reflect the need for the IAR compiler or pull your finger out and get the in house compiler sorted.


  • It looks like you implemented the Nordic UART Service for the Silicon Labs BLE module.  I was looking for just this example.  Is the entire project source available somewhere?  I haven't been able to piece together how you implemented it from the bits posted here.




  • It appears that @Cixelyn is no longer active member in the forum so I doubt this project is available in source code.


    Some updates:

    starting from SDK version 2.3.0, GCC toolchain is supported (Beta) and the examples in the SDK can be built with GCC without any hacking. GNU ARM toolchain 4.9.3 is available through Studio and there is no need to install or configure anything manually.


    A C-based SPP-over-BLE example is available here:



  • Dang sorry @BGM, I just saw this message when I got the notification from @JaakkoV's mention. I think I forgot to subscribe to my own forum thread.


    I currently don't actually have the full source on me at the moment.... though I did find my directory of supporting PC-side scripts which may help you. I've cleaned them up and uploaded to Github: https://github.com/Cixelyn/ble-tokens


    If you want the full MCU code, let me know, and I'll see if I can dig it up on one of my other computers.