newbie help - decoding radiohead ASK/OOK transmitter

[Helios W]

Hi,

I'm trying to decode a signal which i generate myself, but apparently I have no idea what i'm doing.

The signal is modulated/coded with radiohead ASK driver[1], which according to documentation does

• 36 bit training preamble consisting of 0-1 bit pairs

• 12 bit start symbol 0xb38

• 1 byte of message length byte count (4 to 30), count includes byte count and FCS bytes

• n message bytes (uincluding 4 bytes of header), maximum n is RH_ASK_MAX_MESSAGE_LEN + 4 (64)

• 2 bytes FCS, sent low byte-hi byte

Everything after the start symbol is encoded 4 to 6 bits, Therefore a byte in the message is encoded as 2x6 bit symbols, sent hi nybble, low nybble. Each symbol is sent LSBit first.

So i'm trying to decode a 16 bit payload I send.

But whatever I do, i don't get a clean binary output from rtl_433, even though gain and frequency setting should perfectly fit to only receive the desired signal.

Mostly the output is spread over several rows and parts of it missing, example:

*** signal_start = 211188, signal_end = 308222

signal_len = 97034,  pulses = 56

Iteration 1. t: 819    min: 516 (39)    max: 1122 (17)    delta 147681

Iteration 2. t: 809    min: 503 (38)    max: 1115 (18)    delta 218

Iteration 3. t: 809    min: 503 (38)    max: 1115 (18)    delta 0

Pulse coding: Short pulse length 503 - Long pulse length 1115

Short distance: 496, long distance: 996, packet distance: 1495

p_limit: 809

bitbuffer:: Number of rows: 4 

[00] {18} 00 00 00 : 00000000 00000000 00

[01] {22} f0 ab 54 : 11110000 10101011 010101

[02] {5} 68 : 01101

[03] {11} 91 00 : 10010001 000

The signal is sent with 1000 bps, so I assume "short distance" and "long distance" means the length of 0 and 1 bits?

What do "short value" and "long value" (-z -x) do?

If my calculations are correct, I should receive 108 bits including training bits. But how do I get those in a single line?

[1] http://www.airspayce.com/mikem/arduino/RadioHead/classRH__ASK.html

[Benjamin Larsson]

On 07/14/2016 01:48 PM, Helios W wrote:
> Hi,
>
> I'm trying to decode a signal which i generate myself, but apparently I
> have no idea what i'm doing.

Hi, follow the instructions listed on the main project page:

https://github.com/merbanan/rtl_433/#supporting-additional-devices-and-test-data

MvH
Benjamin Larsson

[Helios W]

oh i see.

How can I apply for push permission?

remote: Permission to merbanan/rtl_433_tests.git denied to helioshk.

Or if somebody else can upload it, documentation and samples are attached to this message.

Thanks.

[Benjamin Larsson]

On 07/14/2016 11:19 PM, Helios W wrote:
> oh i see.
> How can I apply for push permission?

You fork on github and then send a pull request, when the PR appear I
will pull the samples. Search the help on github on how to do that.


MvH
Benjamin Larsson

[Helios W]

Ok thanks for patience.

[Benjamin Larsson]

On 07/14/2016 01:48 PM, Helios W wrote:

> Hi,
>
> I'm trying to decode a signal which i generate myself, but apparently I
> have no idea what i'm doing.
>
> The signal is modulated/coded with radiohead ASK driver[1], which
> according to documentation does
>

> * 36 bit training preamble consisting of 0-1 bit pairs
>
> * 12 bit start symbol 0xb38
>
> * 1 byte of message length byte count (4 to 30), count includes

> byte count and FCS bytes
>

> * n message bytes (uincluding 4 bytes of header), maximum n is
> RH_ASK_MAX_MESSAGE_LEN + 4 (64)
>
> * 2 bytes FCS, sent low byte-hi byte

>
> Everything after the start symbol is encoded 4 to 6 bits, Therefore
> a byte in the message is encoded as 2x6 bit symbols, sent hi nybble,
> low nybble. Each symbol is sent LSBit first.

Ok, running rtl_433 -D -D -r tests/radiohead_ask/01/gfile001.data gives
the following output:

Pulse data: 58 pulses
[ 0] Pulse: 512, Gap: 489, Period: 1001
[ 1] Pulse: 511, Gap: 490, Period: 1001
[ 2] Pulse: 510, Gap: 490, Period: 1000
[ 3] Pulse: 512, Gap: 488, Period: 1000
[ 4] Pulse: 511, Gap: 490, Period: 1001
[ 5] Pulse: 511, Gap: 489, Period: 1000
[ 6] Pulse: 511, Gap: 490, Period: 1001
[ 7] Pulse: 510, Gap: 490, Period: 1000
[ 8] Pulse: 510, Gap: 489, Period: 999
[ 9] Pulse: 512, Gap: 489, Period: 1001
[ 10] Pulse: 511, Gap: 489, Period: 1000
[ 11] Pulse: 511, Gap: 489, Period: 1000
[ 12] Pulse: 512, Gap: 489, Period: 1001
[ 13] Pulse: 512, Gap: 488, Period: 1000
[ 14] Pulse: 511, Gap: 489, Period: 1000
[ 15] Pulse: 512, Gap: 490, Period: 1002
[ 16] Pulse: 510, Gap: 490, Period: 1000
[ 17] Pulse: 511, Gap: 1489, Period: 2000
[ 18] Pulse: 1511, Gap: 990, Period: 2501
[ 19] Pulse: 1012, Gap: 489, Period: 1501
[ 20] Pulse: 1011, Gap: 489, Period: 1500
[ 21] Pulse: 1011, Gap: 989, Period: 2000
[ 22] Pulse: 511, Gap: 490, Period: 1001
[ 23] Pulse: 511, Gap: 991, Period: 1502
[ 24] Pulse: 509, Gap: 990, Period: 1499
[ 25] Pulse: 511, Gap: 489, Period: 1000
[ 26] Pulse: 1011, Gap: 989, Period: 2000
[ 27] Pulse: 512, Gap: 489, Period: 1001
[ 28] Pulse: 1011, Gap: 990, Period: 2001
[ 29] Pulse: 511, Gap: 489, Period: 1000
[ 30] Pulse: 1010, Gap: 991, Period: 2001
[ 31] Pulse: 510, Gap: 490, Period: 1000
[ 32] Pulse: 1510, Gap: 491, Period: 2001
[ 33] Pulse: 1010, Gap: 990, Period: 2000
[ 34] Pulse: 510, Gap: 491, Period: 1001
[ 35] Pulse: 1011, Gap: 989, Period: 2000
[ 36] Pulse: 511, Gap: 491, Period: 1002
[ 37] Pulse: 1009, Gap: 991, Period: 2000
[ 38] Pulse: 511, Gap: 489, Period: 1000
[ 39] Pulse: 1011, Gap: 989, Period: 2000
[ 40] Pulse: 510, Gap: 492, Period: 1002
[ 41] Pulse: 1010, Gap: 989, Period: 1999
[ 42] Pulse: 510, Gap: 491, Period: 1001
[ 43] Pulse: 1010, Gap: 990, Period: 2000
[ 44] Pulse: 511, Gap: 490, Period: 1001
[ 45] Pulse: 1011, Gap: 989, Period: 2000
[ 46] Pulse: 510, Gap: 492, Period: 1002
[ 47] Pulse: 1009, Gap: 991, Period: 2000
[ 48] Pulse: 510, Gap: 491, Period: 1001
[ 49] Pulse: 509, Gap: 491, Period: 1000
[ 50] Pulse: 510, Gap: 490, Period: 1000
[ 51] Pulse: 510, Gap: 490, Period: 1000
[ 52] Pulse: 510, Gap: 992, Period: 1502
[ 53] Pulse: 508, Gap: 491, Period: 999
[ 54] Pulse: 511, Gap: 489, Period: 1000
[ 55] Pulse: 510, Gap: 490, Period: 1000
[ 56] Pulse: 1011, Gap: 991, Period: 2002
[ 57] Pulse: 1010, Gap: 15111, Period: 16121


The data looks really good, so the demodulator is working well. Now we
just need to figure out the bit representation. We have pulse lengths of
500, 1000 and 1500. Gap lengths with the same 3 values. My guess is that
a pulse of 500 is a 0 and a gap of 500 is a 1. This matches the pulse
code modulation. Using this config:

.modulation = OOK_PULSE_PCM_RZ,
.short_limit = 510*4,
.long_limit = 510*4,
.reset_limit = 8000*4,


gives the following output:

pulse_demod_pcm(): Template decoder
bitbuffer:: Number of rows: 1
[00] {169} aa aa aa aa a3 9b 65 25 96 59 76 59 65 96 35 65 93 52 ce 40
00 00

And aa aa aa aa a looks like the 36 training bits mentioned. So I think
that these are the proper bits. So use those values and go from there.
When you have something that works somewhat send it for review through a PR.

MvH
Benjamin Larsson

[Helios W]

Sorry i shifted by one bit in the earlier message, this should be correct.

I'm afraid but this is beyond my capabilities for now.

I converted the hex to bin;

010101010101010101010101010101010101 36 training bit

0001 1100 11011 start symbol 0xb38

Everything after here is coded 4b6b yet this is too complex for me. Here's the function to decode in radiohead:

// Convert a 6 bit encoded symbol into its 4 bit decoded equivalent

uint8_t INTERRUPT_ATTR RH_ASK::symbol_6to4(uint8_t symbol)

{

    uint8_t i;

    uint8_t count;

    

    // Linear search :-( Could have a 64 byte reverse lookup table?

    // There is a little speedup here courtesy Ralph Doncaster:

    // The shortcut works because bit 5 of the symbol is 1 for the last 8

    // symbols, and it is 0 for the first 8.

    // So we only have to search half the table

    for (i = (symbol>>2) & 8, count=8; count-- ; i++)

        if (symbol == symbols[i]) return i;

    return 0; // Not found

}

101100 101001 message length

001011 001011 header (to, from, id, flags)

001011 001011

101100 101100

101100 101100

101100 011010 payload (16 bit int, in this case)

101100 101100

100110 101001 crc

011001 110010

[Helios W]

d'oh shifted again one bit in/after start symbol. but i think you see what i mean.

[Benjamin Larsson]

On 07/15/2016 01:51 PM, Helios W wrote:
> Sorry i shifted by one bit in the earlier message, this should be correct.
>
> I'm afraid but this is beyond my capabilities for now.

Start googling and begin hacking. At least create a decoder that can
verify the preamble and the start symbol.

When you have that I might be able to help out with the rest.

MvH
Benjamin Larsson

[Helios W]

I will try, but I have another project first.

The cheap receivers matching those cheap transmitters aren't very good, sometimes they have problems even at 40dB SNR. I think rtl_433 may perform better.

Though the bad performence, about 40m range is possible at 500bps, so probably higher range or higher speed may be possible with rtl_433.

[Benjamin Larsson]

>
> Everything after here is coded 4b6b yet this is too complex for me.
> Here's the function to decode in radiohead:
> |
> // Convert a 6 bit encoded symbol into its 4 bit decoded equivalent
> uint8_t INTERRUPT_ATTR RH_ASK::symbol_6to4(uint8_t symbol)
> {
> uint8_t i;
> uint8_t count;
> // Linear search :-( Could have a 64 byte reverse lookup table?
> // There is a little speedup here courtesy Ralph Doncaster:
> // The shortcut works because bit 5 of the symbol is 1 for the last 8
> // symbols, and it is 0 for the first 8.
> // So we only have to search half the table
> for (i = (symbol>>2) & 8, count=8; count-- ; i++)
> if (symbol == symbols[i]) return i;
>
> return 0; // Not found
> }

Ok, the 4to6 coding is used to get transitions in the signal. This helps
clock recovery. If you do not ensure bit transitions you might get a
signal with only zeros. And in that case you might loose sync when
decoding. Anyway when you encode 4to6 you take 4 bits and then use a
lookup table that has some magical property with regards to bit
transitions. To decode you just do the reverse. So how do we get these
tables. Well you already provided the code for it. Just input [0,63] to
the function and record the output.


table_6to4[64];

for (i=0 ; i< 64 ; i++)
table_6to4[i] = symbol_6to4(i);

Now to get the 4 bit value just do a index lookup in the table_6to4[] table.

MvH
Benjamin Larsson

[Benjamin Larsson]

You can use -l 0 for maybe better performance.

MvH
Benjamin Larsson

[Emmanuel Navarro]

Hi,

I just push a branch with a RadioHead ASK device.

It's here: https://github.com/enavarro222/rtl_433/tree/ASK

I can create a PR... however I think it may be "out of the scope" of rtl_433. This is a "generic" decoder for some "home made" devices (based on RadioHead ASK) and not a decoder for a specific device... What do you think about that ? The only practical problem I see about the bitrate (RH_ASK_SPEED) which is defined by a constant in rtl_433 but may vary from one RadioHead ASK device to an other.

Also I took some code from RradioHead src (for CRC, and 4to6 decoding...) but both project are GPL so I guess there is no issue with that. Maybe references can be more visible.

+

Emmanuel N.

--
You received this message because you are subscribed to the Google Groups "rtl_433" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtl_433+unsubscribe@googlegroups.com.
To post to this group, send an email to rtl...@googlegroups.com.
Visit this group at https://groups.google.com/group/rtl_433.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/57891E2F.1030802%40ludd.ltu.se.

For more options, visit https://groups.google.com/d/optout.