> Wireless code: Should display: Displays as:
> =====================================================
> ...
> 111100 0000101111100 31 95
> 111100 0100101111100 95 95

You made a small mistake, it seems. Actual value for 31 should be 0010101111100.

Coding scheme used here ensures there are no more than three zeros in a row.

Why it decodes that invalid code as 95, though, I have no idea. It can be considered as undefined behaviour in their decoding. "Garbage in - garbage out" should be sufficient explanation in that case. Bad thing they didn't detect and ignore invalid inputs, despite the possibility.

Ah, I got it. So, you've tested every possible input, and compared their output with yours, without checking for validity.

And found few invalid codes that slipped through their decoder implementation as the result.

(That, in turn, should not affect the functionality of the product, as these codes won't be transmitted in a first place.)

I think there are valid codes with more then 3 zeroes in a row, e.g. for 128...143

Indeed, the watch is working just fine. The main reason to explore in an automated way for a wider range of codes then necessary was, in fact, my desire to learn about computer vision and OpenCV.

Even after exploring more codes, I am still intrigued by how the signals are encoded. IMO it must be some algorithm simple enough to implement it into hardware, without a processor.

The receiver side might have a processor (so the watch is able to run whatever software is needed to decode), but my guess is that the chest belt transmitter doesn't have a processor, so it must be simple enough for a hardware only implementation.

My bad. There will be no more than 3 zeros in case of optimal implementation.

Still, "Should display" statement isn't quite right here. Test setup is quite nice though.

As for hardware: microcontrollers are dirt cheap nowadays. And handling the pulse sensor still requires some logic. I bet there is some generic RF-enabled one-time programmable microcontroller inside. With firmware flashed at factory. 

If you can't disassemble it to check that by yourself, look for FCC id code on the device - you will be able to find its insides at fccid.io

This is the shortest/simplest decoder (radio signal in, bpm out) that I got so far. Still written in python, but it would translate almost directly to C or assembly ...

lut4 = (38,42,50,60, 6,10,18,28, 6,10,18,28,12,20,36,56)

lut8 = (19,21,25,30,35,37,41,46, 3, 5, 9,14,38,42,50,60)

def heart_rate( code):
    pqstu = (code >> 5) & 0xf8      # top five bit 
    vw = (code >> 4) & 0x0C         # middle two
    six = code & 0x3F               # bottom six    
    DE = pqstu & 0xC0               # top two bit
    FG = pqstu & 0x38               # middle three
    if DE != 0xC0: FG <<= 1         # get st or tu
    FG &= 0x30                      # reduce to two
    if DE != 0xC0 and FG != 0x30:
        w = (vw << 1) & 0x08        # only the bottom bit
        return DE + FG + w + lut8[w:].index(six)
    return DE + FG + vw + lut4[vw:].index(six)

Loved the puzzle ... 

I must look into that, very interesting, thanks!

Did you tried this decoder with the exception codes, like the ones from this table?
https://hackaday.io/project/13142-sniff-the-wireless-data-of-a-sports-wrist-watch/log/55886-computer-scan-all-the-wireless-codes

Here is a spreadsheet with notes as cell comments. Google Sheets cell comments are always collapsed, so the comments are hard to spot. I will attach here the original Open Office file, where all the comments can be seen at once.
https://docs.google.com/spreadsheets/d/1bD1QExAo3wHoBNc9jYppoeNdXunUgC1jm-AAx7J85hA/edit?usp=sharing

Hi,

Just tried to find a pattern in the data and here is a piece of C code which translates the data to plain numbers:


========================================================================
#include <stdio.h>
#include <stdint.h>

// 13 bit data captured from pulse sensor encoded as integers
uint16_t pulse_array[] = {
1394, 1404, 1555, 1557, 1561, 1566, 1571, 1573, 1577, 1582, 1603, 1605, 1609, 1614,
1638, 1642, 1650, 1660, 1830, 1834, 1842, 1852, 1862, 1866, 1874, 1884, 1926, 1930,
1938, 1948, 1996, 2004, 2020, 2040, 2195, 2197, 2201, 2206, 2211, 2213, 2217, 2222,
2243, 2245, 2249, 2254, 2278, 2282, 2290, 2300, 2323, 2325, 2329, 2334, 2339, 2341,
2345, 2350, 2371, 2373, 2377, 2382, 2406, 2410, 2418, 2428, 2579, 2581, 2585, 2590,
2595, 2597, 2601, 2606, 2627, 2629, 2633, 2638, 2662, 2666, 2674, 2684, 2854, 2858,
2866, 2876, 2886, 2890, 2898, 2908, 2950, 2954, 2962, 2972, 3020, 3028, 3044, 3064,
4243, 4245, 4249, 4254, 4259, 4261, 4265, 4270, 4291, 4293, 4297, 4302, 4326, 4330,
4338, 4348, 4371, 4373, 4377, 4382, 4387, 4389, 4393, 4398, 4419, 4421, 4425, 4430,
4454, 4458, 4466, 4476, 4627, 4629, 4633, 4638, 4643, 4645, 4649, 4654, 4675, 4677,
4681, 4686, 4710, 4714, 4722, 4732, 4902, 4906, 4914, 4924, 4934, 4938, 4946, 4956,
4998, 5002, 5010, 5020, 5068, 5076, 5092, 5112, 6438, 6442, 6450, 6460, 6470, 6474,
6482, 6492, 6534, 6538, 6546, 6556, 6604, 6612, 6628, 6648, 6694, 6698, 6706, 6716,
6726, 6730, 6738, 6748, 6790, 6794, 6802, 6812, 6860, 6868, 6884, 6904, 7206, 7210,
7218, 7228, 7238, 7242, 7250, 7260, 7302, 7306, 7314, 7324, 7372, 7380, 7396
};

int main(void) {
    uint8_t i, qty = sizeof(pulse_array) / sizeof(pulse_array[0]);
    
    // get next value to decode
    for (i = 0; i < qty; i++) {
        uint16_t w=0, v=0;
        uint8_t a=0, a1=0, b=0, b1 = 0, gh=0, f=0, result=0, mod = 0;
        int8_t sign = 1;

        w = pulse_array[i];
        a1 = w>>10; a = a1>>1;
        b = (w & 0x0300)>>8;
        b1 = (w & 0x0200)>>9;
        v = w & 0x0FF;
        
        if (a != 3) {
            if (b == 3)    {
                v >>= 1;
            }
            gh = (a << 2) + b;
        } else {
            v >>= 1;
            gh = (a1 << 1) + b1;
        }
        
        v &= 0x07F;

        if ((v >= 19) && (v <= 25)) {
            sign = -1;
        }
        
        if ((v == 19) || (v == 46) || (v == 78)) {
            mod = 2;
        } else if ((v == 21) || (v == 25) || (v == 37) || (v == 41) || (v == 69) || (v == 73)) {
            mod = 1;
        }

        result = (gh << 4) + (v >> 3) + (sign * mod);
        
        // print decoded number of bps
        printf("%d = %d\n",w,result);
    }
}

That's great, thanks!

At the first look, I can not tell if your algorithm is similar with the one found by @killy.mxi, but I'll give it a try very soon. So far I made an emulator for the radio transmitter, in order to test new combination of bits that are not in the published encoding table.

Here is a simple test version in python3. In assembly (any micro) this would turn into just a dozen of lines of code:

#! /usr/bin/env python3
#
# Heart rate monitor decoder
#
#
from sys import argv

lut4 = (38,42,50,60, 6,10,18,28, 6,10,18,28,12,20,36,56)

lut8 = (19,21,25,30,35,37,41,46, 3, 5, 9,14,38,42,50,60)

def heart_rate( code):
    b = []
    for x in range(7):
        b.append(1 if (code & 4096) else 0)
        code = code << 1
    b.append((code>>7) & 0x3F)
    p,q,s,t,u,v,w,lut = b
    # print(p,q,s,t,u,v,w,lut)

    # find D and E
    D = p; E = q
    DE = D*2+E

    # find F and G
    if DE == 3:
        F = s; G = t
    else:
        F = t; G = u
    FG = F*2+G

    # print ('DEFG=',D, E, F, G)

    # find J and K
    if DE <3:

        if FG < 3:
            J = w
            # print('J=',J)
            JKLM = J*8 + lut8[J*8:].index(lut)
        else: # FG == 3:
            J = v; K = w; JK = 2*J + K
            # print('JK=',JK)
            JKLM = J*8 + K*4 + lut4[JK*4:].index(lut)
    else: # DE == 3
        J = v; K = w; JK = 2*J + K
        # print('JK=',JK)
        JKLM = J*8 + K*4 + lut4[JK*4:].index(lut)

    print('BPM = ', DE*64+FG*16+JKLM)

if __name__ == '__main__':
    if len(argv) < 2 :
        print('Usage: heart_rate.py code OR test.txt')
        exit()

    try:
        heart_rate(int(argv[1]))
    except:         
        with open(argv[1],'r') as f:
            for line in f.readlines():
                heart_rate(int(line))

Thanks axodus for the initial seed for thoughts.

Encoded sequence has variable lenght. There are some stuffed bits for better signal recovery. No more than 4 "0"s in a row (doesn't look like a good achievement to me, actually).

Output sequence:

* in1
* in2
* (in1 nor in2) stuffed if (in1 nand in2)
* in3
* in4
* (in3 nor in4) stuffed if (in3 nand in4)
* in5
* in6
* (in5 nor in6) stuffed if (in5 nand in6)
* in7
* in8
* (in7 xnor in8)
* (in7 nand in8)

Speaking simple, stuffing rule works like this:
* if pair of bits is 00, stuff 1;
* if 01 or 10, then stuff 0;
* if 11, don't stuff anything here.

The reason behind the last two output bits is puzzling: why doing checksum just over two last input bits?

Me figuring out the encoding:
https://docs.google.com/spreadsheets/d/18AYRKe2EpUOVvEsKSWlFoXfy9EXSNNe7LVkw8dtX75Y/pubhtml
(Initially there was conditional formatting to distinguish ones from zeroes. Now only the pairs are highlighted.)
It seems that there's small mistake in data. Values for 231 and 232 should be swapped if I'm correct.

Wow, these are very interesting findings, thank you very much!

I just tried to check again for the codes 231 and 232, but the chest strap didn't work any more.
:o(

I will try to fix it tomorrow, and let you know the result.

The chest strap is working again, and you are correct: Values for 231 and 232 should be swapped, good catch.

I will update the project with your findings.

Thanks again for cracking the encoding scheme, very well done!

While it won't answer how it was encoded, you can use brute force to decode the values from the 13 bits by using a table lookup.

Indeed, the table already extracted (the one at the end of the details section https://hackaday.io/post/43802) can be used to lookup for the decoded values, but I am still curious if this 13b/8b is a well known scheme, or a particular one used only for this product.

I tried to open the transmitter case in order to see the encoding chip, and find it's datasheet, but the case seems to be glued. I am not yet ready to open it by force because it will not be waterproof any more after this. One more reason not to open it is that there might be a dedicated chip with no part number and no available datasheet.

hey RoGeorge , thanks for the excellent write up.

 I tried to reverse engineer the encoding scheme you described in your first post with
no definite results, but thought I'd share my conclusions so far if anyone else want to give it a try.  

the i/o bits are indexed from left to right starting with 1.

looking at the correlation between the output bits  and the input bpm bits: http://imgur.com/M1Uet2e

and comparing the bits visually i got the following clues: http://imgur.com/1lEhH3f

=> bits 1,2 (left most) of the output are identical to bits 1,2 of the input.

=> bit 3  ? (correlate to input bits 3,4...)

=> bit 4 almost identical to input bit 3 apart from some values where the bits get negated.

=> bit 5 almost identical to input bit 4 apart from some (other) negated values.

=> bit 6 ? (correlate to input's bits 5...)

=> bit 7 almost identical to input bit 5, more values get negated.

etc...

not an answer yet, but a general direction i hope :)

Thank you very much for looking into this.
:o)

I never thought of a graphical representation, very good idea!

Looking at the charts, I cannot see any obvious pattern. I am starting to believe that the designer maybe just used a lookup table for encoding 8b/13b in order to achieve DC-balance or clock recovery, something similar with this 8b/10b scheme: https://en.wikipedia.org/wiki/8b/10b_encoding