Pulse Decoding

[Freman]

G'day there.

I've still trying to replace a pic on a board. I've got a whole new approach that I'm working on.

I want to decode the pulses received from the RF receiver.

I don't have a CRO or anything useful like that, but can anyone give me any idea how I might have the pic read these pulses and store details about them in eeprom?

Or perhaps how I can read and compare these pulses to a list of knowns? (I have the specs on the transmitter, but not the receiver)

EDIT -

Ok, I've hacked myself up a cheap scope (sound card + voltage divider )

UP: http://img443.imageshack.us/my.php?i...8235605zw2.png
Stop: http://img47.imageshack.us/my.php?im...8235856ae3.png
Down: http://img47.imageshack.us/my.php?im...8000034iy4.png

So um... anyone know how I might go about reading these signals with a PIC/picbasic?

[dhouston]

Is that all there is to the code? Frequently there is a wide pulse/space pair that acts as a Start of Frame marker.

What type of transmitter? receiver? ASK vs. FSK and whether or not there is a carrier detect signal makes a huge difference in how you detect the start of a transmission.

The codes themselves are quite simple, containing 24 data bits (the last pulse is an End of Frame marker). Each bit has a fixed period (~0.67mS) and the width of the pulse determines 1 vs. 0. I would assign 1 to the wider pulses and just use PulsIn to capture them.

[Freman]

I don't honestly know what type of receiver.

This is the transmitter chip: http://pdf1.alldatasheet.com/datashe...TC/PT2264.html
it's running at around 12v and has a 1.5 mOhm resistor on it's osc.

This is what I've worked out with the scope program - Give or take

600u whole bit.

1: 450 high, 150 low
0: 150 high, 450 low

UP: 11110001001101011100000
Stop: 11110001001101001100000
Down: 11110001001101100000011

[dhouston]

That's not the transmitter. It's just the encoder chip.

Bruce Reynolds has posted code for decoding these signals. I don't recall whether it was this specific encoder or a Holtek encoder which works the same way.

There is no Start of Frame so you have to detect the long silence which occurs between codes and capture/decode the 2nd or later copy. A search here will turn up Bruce's code. Or, he's likely to jump in and point you to it.

[Bruce]

I posted a simple example for decoding a Holtek 8-bit encoder here;
http://www.picbasic.co.uk/forum/showthread.php?t=6581

The Holtek 640 encoder is similar to the one you have with 2 pulses per bit, but the Holtek
packets are 10-bit address with 8-bit data. It should at least give you a good base to start
from.

Here's a simple chopped-down version example of decoding a Holtek HT12E.

DEFINE OSC 20            ' 20MHz xtal

DEFINE PULSIN_MAX 3000  ' Set MAX wait for pulses to speed-up response time
PBIT        VAR BYTE[12]' Pulse-in values after NCD
NUMS        VAR WORD    ' RAW pulsin value
ADDRESS     VAR BYTE    ' address
DBYTE       VAR BYTE    ' data byte
X           VAR BYTE    ' GP loop counter
Y           VAR BYTE    ' GP variable
DIN         VAR PORTB.0 ' Data input direct from HT12E encoder IC

TRISB.0=1
        
GET_ADD:
    ADDRESS=0 : DBYTE=0 : NUMS=0

GET_P:
    PULSIN DIN,1,NUMS
    IF NUMS < 100 THEN GET_P  ' 
                              ' if sync pulse is less than 200uS restart.
    FOR X = 0 TO 11           ' read 12 pulses
     PULSIN DIN,1,NUMS        ' 
     PBIT[X] = NCD NUMS       ' convert high-bit-set
    NEXT X                    ' loop until done
    
    ' Get address
    ADDRESS=$FF               ' start with all 1's and find each 0
    FOR X = 0 TO 7            ' PBIT bytes 0 to 7 = address
     IF PBIT[X] >7 THEN ADDRESS.0[X] = 0 ' If NCD val > 7 it's a 0
    NEXT X
    
    ' Get data
    Y=0
    DBYTE=$0F           ' start with all 1's and find each 0
    FOR X = 8 TO 11     ' PBIT bytes 8 to 11 = encoder 4-bit data
     IF PBIT[X] >7 THEN DBYTE.0[Y]=0' DBYTE bits 0 to 3 are our data-bits
     Y=Y+1
    NEXT X
    
    ' show results
    HSEROUT ["ADD = ",IBIN8 ADDRESS," : ",IDEC ADDRESS,13,10]
    HSEROUT ["DAT = ",IBIN4 DBYTE," : ",IDEC DBYTE,13,10]
    GOTO GET_ADD
    
    END

The .JPG file attached shows a logic analyzer capture of the HT12E output.

Serial terminal result;
ADD = %10111011 : #187
DAT = %1011 : #11

This matches the address & data I had set on the HT12E encoder when the program ran.
You can change the address & data, press /TE, and watch the results on-screen.

Note: This code example is a chopped version with only a single-pass. In most
applications you will want to do 2 or 3 passes, then verify multiple address/data packets
before you change a decoders outputs. Otherwise it's prone to errors.

This version is suceptible to noise. That's why it was tested with a direct connection from
encoder to PIC input. This remains stable. The data output of an RF receiver however, is a
diferent story. You'll se a TON of noise pulses there.

The tricky part is working in the multi-pass & verify routines. That part I can't share...;o}

[Freman]

Thanks for the information Bruce.

My input signal appears to be high and fairly noisy with pulses low - I really need a real scope

If I read the code you provided correctly, it shouldn't reach GOTO GET_ADD without receiving a full pulse (or at least a full initial pulse)

Mine's running all the way through without thinking about it, even with a resistor to gnd and no actual signal.

I don't have a uart hooked up to this board at the moment so I'm just storing the values in eeprom - they're all showing up as 0's

- Edit

Oh dear, spoze if it wasn't 3 am and I'd had some coffee I would have done some thinking

1) 4 mhz clock (getting 20 mhz crystals tomorrow, ran out)
2) This is probably a one off - so at the very least I can look for 4 high pulses at the start, if not look specifically for more components of the bitstream

I'll go to bed now and resume banging head on desk tomorrow.