Avatar for ColinP


Member since Jan 2016 • Last active Apr 2017
  • 1 conversations

Most recent activity

  • in Projects
    Avatar for ColinP

    The new tracker arrived today! It is a Nordic one and looks identical to the one @Gordon posted.

    It's really weird: Seeing them together shows that they are extremely similar, yet different.

    I posted some pictures showing the differences:


    The Nordic chip variant feels to be higher quality - the band is softer and more flexible and the screen is much sharper and it updates much more quickly.

    There are smaller differences - one has an oval shaped button, and the other a rectangular one. The battery clips are an almost identical design but yet made of a slightly different quality of plastic.

    The Nordic based one advertises itself as "YDY_P102" to Bluetooth and the other one seems to have decided not to advertise any more....

    What to do with it? I figure it would work strapped to a bicycle wheel as a cycle computer, or could make some kind of shoe-mounted device to communicate online by morse code - pub-quiz cheat-tastic!

  • in Projects
    Avatar for ColinP

    No need to apologise - and thanks for the link. This device uses the Nordic Bluetooth service UUID and shares an app even though it doesn't have a Nordic chip in. I find it fascinating that there appear to be a few companies making identical looking devices but with different insides, yet which share the same Android app.

  • in Projects
    Avatar for ColinP


    Aaargh! I ordered one and it is the wrong thing!

    It looks exactly the same as the one you have - same bracelet, case and charger. However the insides are different. It looks as though it has an LCD screen with a backlight rather than OLED screen and the chip inside is marked CC2541. This could be a TI chip with an 8051 processor, assuming it isn't a clone!

    It has "xianwei" and v3 written on the PCB, along with 2015.12.17 which I guess is a surprisingly recent manufacturing date. There is also a swoosh logo on the PCB which reminds me of a certain other sports manufacturer.....

    It's really interesting to do a search on alibaba.com for "smart bracelet nrf51822". There appear to be loads of identical looking products from different manufacturers. Some claim to use nrf51822, others a dialog semiconductor part, and I guess this one has a TI part. I'm not sure what it says that there are so many different companies making identical looking but different products. Now how to find the correct one on eBay...

  • in Projects
    Avatar for ColinP


    Looks very interesting! After my hacking with the Adafruit board last week I finally managed to get around to the unrelated stuff I was supposed to be working on. One ebay order later and you have managed to distract me a little bit more :-)

    What do you use with openocd to program it? I'm a bit tempted to order one of the STM32 discovery boards with STLink on it, which I think should work..it's easier to attach to that than the JLink Lite I was using previously.

  • in Porting to new Devices
    Avatar for ColinP

    Out of curiosity I flashed the Nordic sniffer software and watched the trace between my phone and Espruino using Wireshark. Outside of the datalink layer that is implemented by the project I linked to there doesn't seem to be a huge amount - the L2CAP "layer" just seems to be 2 bytes of packet saying "This is L2CAP" followed by the GAP "layer?" which is a single byte opcode of 'read','write' etc. I don't particularly fancy reimplementing it - just curious.

    I notice the devices continually send a "I have nothing to say" packet between them every few milliseconds when connected and idle. For a low energy protocol this seems like a strange choice.

    If I remember correctly, the Nordic SDK has an example of using the radio raw which I think can work with an nRF24. http://dmitry.gr/index.php?r=05.Projects­&proj=11.%20Bluetooth%20LE%20fakery is interesting too - he sends out BTLE advertisements using an nRF24 - I guess similar code would work on nrf51x.

  • in Porting to new Devices
    Avatar for ColinP

    I think you're right in that it is certainly possible to pair with a device and then reconnect to the service without advertising and I notice some Bluetooth devices have a specific "pair" button to initiate this. The Nordic UART app only seems to be able to connect to devices which advertise, so maybe it is best to keep advertising in for now if that is the sort of app that people are likely to use - at least initially until something else is written. Maybe it is a "depends on the use case" decision.

    I saw a project: https://github.com/pauloborges/blessed which looks interesting - an open source BTLE stack for nrf51822. It would be interesting to see if the softdevice could be replaced with something simpler to give extra flash and RAM, and could potentially allow the device to talk to nrf24l01 style radios as well (which I think it should be capable of doing). If I have got my head around the acronym-soup that is BTLE the GAP and GATT layers would need implementing to allow something like a UART to work. More studying required...

  • in Porting to new Devices
    Avatar for ColinP

    I thought previously about flow control being set in Linux - I tried disabling it with screen but no change. Minicom was actually worse - I found it appeared to hang quite often and I had to kill -9 it. I decided to stick with hardware flow control and screen (that I knew worked previously rather than trying to debug problems with the hardware dongle/Linux serial). I'm actually using OS X with Linux in VMWare, so I might try native OS X serial sometime.

    The schematic for the Adafruit board shows it uses P0.9 and P0.11 for serial, which is already defined in the NRF51822DK.py file . As it has the 32k RAM variant of the chip I guess it should work with no changes.

    I had a look into the advertising, and it definitely stops advertising (or at least Nordic UART 2.0 does not see it to allow reconnecting after disconnection). I noticed that running "NRF.wake()" from the terminal allowed it to be seen again and reconnect.

    I made the following change:

    diff --git a/libs/bluetooth/jswrap_bluetooth.c b/libs/bluetooth/jswrap_blue
    index 6ecd36c..b8aec46 100644
    --- a/libs/bluetooth/jswrap_bluetooth.c
    +++ b/libs/bluetooth/jswrap_bluetooth.c
    @@ -261,6 +261,7 @@ static void on_ble_evt(ble_evt_t * p_ble_evt) {
             m_conn_handle = BLE_CONN_HANDLE_INVALID;
             jsiSetConsoleDevice( DEFAULT_CONSOLE_DEVICE );
    +        jswrap_nrf_bluetooth_startAdvertise();

    I'm not 100% sure if this is correct as I don't really understand the Nordic UART states enough. I had a look around, and the Nordic code at:


    calls advertising_start() on handling BLE_GAP_EVT_DISCONNECTED...looks to be the same as my change.

  • in Porting to new Devices
    Avatar for ColinP

    I tried flashing the same hex file onto the Adafruit board. Terminal over Bluetooth now seems to work so I'll assume the fix you posted earlier has done the trick. The serial Rx and Tx lines (P0.9 and 0.11) are unconnected.

    I have to reset it after every terminal connection as it stops advertising. I had earmarked other things to do today so had better get around to them, but I'll try to have a look at that later.

  • in Porting to new Devices
    Avatar for ColinP


    Flow control (or at least the RTS (or CTS?) pin being asserted) seems to be needed before the JLink dongle serial interface will transmit anything. To begin with I only got data from the console but couldn't send it anything and couldn't find the correct incantation to turn off flow control.

    It turns out that the Bluetooth flakiness was caused as both the "nRF toolbox" and "nRF UART v2.0" apps were running on my phone. It looks as though one of them was trying to reconnect in the background. I rebooted my phone to stop any services that were running, or in case the Android BTL stack was upset, and Bluetooth seems reliable now. I have noticed that after closing a connection it stops advertising and hence I cannot reconnect. Not sure if this is intentional or not.

    I'll try the Adafruit board later to see if it now works without a serial connection.

    In the meantime, for anyone interested, my quick hacks to get it working with the Nordic PCA10000 dongle are:

    Install JLink_Linux_V492_i386 and gcc-arm-none-eabi-4_9-2015q1-20150306-li­nux.tar.bz2 and add to PATH

    Change RAM size in boards.py to run with 16k RAM, as copied from MICROBIT.py:

    diff --git a/boards/NRF51822DK.py b/boards/NRF51822DK.py
    index 0ebc85e..a7be363 100644
    --- a/boards/NRF51822DK.py
    +++ b/boards/NRF51822DK.py
    @@ -23,7 +23,7 @@ info = {
      'default_console_tx' : "D9",
      'default_console_rx' : "D11",
      'default_console_baudrate' : "9600",
    - 'variables' : 200, # How many variables are allocated for Espruino to use. RAM will be overflowed if this number is too high and code won't compile.
    + 'variables' : 145, # How many variables are allocated for Espruino to use. RAM will be overflowed if this number is too high and code won't compile.
      'binary_name' : 'espruino_%v_nrf51822.bin',
      'build' : {
       'defines' : [
    @@ -36,13 +36,13 @@ chip = {
       'part' : "NRF51822",
       'family' : "NRF51",
       'package' : "QFN48",
    -  'ram' : 32,
    +  'ram' : 16,
       'flash' : 256,

    Hack serial port config to allow HW flow control:

    diff --git a/targets/nrf5x/jshardware.c b/targets/nrf5x/jshardware.c
    index e30afc8..5ae69fa 100644
    --- a/targets/nrf5x/jshardware.c
    +++ b/targets/nrf5x/jshardware.c
    @@ -400,9 +400,9 @@ void jshUSARTSetup(IOEventFlags device, JshUSARTInfo *inf) {
       const app_uart_comm_params_t comm_params = {
    +      8, //UART_PIN_DISCONNECTED,
    +      10, //UART_PIN_DISCONNECTED,
           inf->parity!=0, // TODO: ODD or EVEN parity?

    I created a script to allow easier flashing - save as 'flash.jlink':

    device nrf51822
    speed 1000
    w4 4001e504 1
    loadfile espruino_1v84.70_nrf51822.hex

    build and flash using:

    NRF51822DK=1 RELEASE=1 make && JLinkExe flash.jlink

    and access the serial console provided by the JLink using (on Linux):

    screen /dev/ttyACM0 9600