Pulse Decoding

[dhouston]

I'm going to opt to completely ignore the first transmission sequence as the start of it is a little messed up and target the second transmission sequence (I pushed the button as fast as I could, I always got 2 or more sequences).

You will always need 2 or more copies of the code as the first (and sometimes the second, third and...) will always be messed up. This is because the receiver's AGC/ATC circuitry has not yet adapted to the signal strength. How many are messed up depends on the strength of the signal. This is why I never recommend using 10101010 type sequences as a start of frame marker. In this case, Bruce uses the long silence that follows each copy of the code as a start of frame marker for the next. All you can do is test each bit and abort if the pulse or space width exceeds a maximum. I define MAX PULSE for this.

I was playing around with it before as '1's instead of '0's in pulsin but it was picking up the block of 0's not the block of 1's. (If that makes any sense)

With this particular protocol, the bit period is constant and the pulses and spaces are complementary (i.e wide pulse & narrow space and vice versa) so it really doesn't matter whether you use 1 or 0 with PulsIn.

[Freman]

Yes I've slept on it, so I'll be aiming for the long low pulse as my 'start of sequence' then working on the bits. It annoys me that I have to go to work for 8 hours before I can test this

Edit

Ok, so the long pulse is 4.6 ms long - so I should increase DEFINE PULSIN_MAX 3000 to say DEFINE PULSIN_MAX 5000 yes?

Or is that calculated the same was as the actual pulsein is calculated...

ie: DURATION / CLOCKSPEED

In which case... 3000 is just perfect

[Freman]

Well here we go, and it even works - well there's no false positives, but some times it doesn't activate, but better then it was.

' Configure the FUSE options for the compiler
@     device pic16F628A, hs_osc, wdt_off, pwrt_on, lvp_off, protect_off, bod_on, cpd_off, pwrt_off, mclr_off

' Running a 4Mhz clock
DEFINE OSC 20
DEFINE PULSIN_MAX 3000

CMCON  = 7
ALL_DIGITAL

' Setup the USART
DEFINE HSER_RCSTA 90h      ' Receive register to receiver enabled
DEFINE HSER_TXSTA 20h      ' Transmit register to transmitter enabled
DEFINE HSER_BAUD 9600      ' Set baud rate

RFIN VAR PORTB.7

INPUT RFIN

PBITS   VAR BYTE[24] ' The bits we've read
RAW     VAR WORD     ' The raw pulsin value
ADDRESS VAR WORD     ' Storage for the address
DBYTE   VAR BYTE     ' Storage for the data
LOOPDBYTE VAR BYTE
LOOPADDRESS VAR WORD
X       VAR BYTE
Y       VAR BYTE

GET_ADD:
    ADDRESS = 0 : RAW = 0 : DBYTE = 0

GET_PULSE:
    ' Look for one huge low pulse
    PULSIN RFIN, 0, RAW
    ' 2350 is about mean average
    IF RAW < 2330 OR RAW > 2370 THEN GET_PULSE

    ' Read 16 address bits and 8 data bits    
    FOR X = 0 TO 23
        PULSIN RFIN, 0, RAW
        PBITS[x] = NCD RAW
    NEXT X
    
    ADDRESS = 65535 ' Maxmimum known ID
    FOR X = 0 to 15
        IF PBITS[x] > 7 THEN ADDRESS.0[X] = 0
    NEXT X
    
    DBYTE = 255 ' Maximum known data value
    Y=0
    FOR X = 16 TO 23
        IF PBITS[X] > 7 THEN DBYTE.0[Y] = 0
        Y = Y + 1
    NEXT X

    ' If we've done a loop...
    IF ADDRESS == LOOPADDRESS AND DBYTE == LOOPDBYTE THEN
        SELECT CASE DBYTE
            CASE 3
                GOSUB subUp
            CASE 12
                GOSUB subStop
            CASE 192
                GOSUB subDown
        END SELECT
        LOOPDBYTE = 0
        LOOPADDRESS = 0
    ELSE
        ' Start a loop
        LOOPDBYTE = DBYTE
        LOOPADDRESS = ADDRESS
    ENDIF

    GOTO GET_ADD
END

subUp:
    HSEROUT ["UP",10,13]
    RETURN
    
subStop:
    HSEROUT ["STOP", 10, 13]
    RETURN

subDown:
    HSEROUT ["DOWN",10,13]
    RETURN

Any suggestible improvements? (btw, thanks for all the help so far

[skimask]

Increase your pulsin_max until it kicks out a false positive, then back up a bit.

[dhouston]

When looking for a long-0 pulse, DEFINE MAX PULSE really doesn't do anything. It's only useful when looking for a long 1-pulse.

I suggest testing each bit as received and aborting if it is shorter than the shortest normal 0-pulse. With a weak signal, noise pulses will appear during the silences (i.e.. 0-pulses), shortening the measured PulsIn value but they will just be superimposed on a 1-pulse. In some cases there may be insufficient time to do this test but I think it will work here. Take a look at...

• http://davehouston.org/rf-noise.htm

to see what I mean.

[Freman]

I'll add that check tonight dhouston.

I went with 0 instead of 1 because it gave me a much tighter average long pulse.
Almost all the long pulses were comming in qt 2355 exactly, I only added a little bit of deviation after adding the loop code.

To be honest I didn't do the math behind the short pulses, only the super massive long pulse so I will sit down and do the math to make it more accurate.

Now that the 'easy' stuff is done tho... I have to work on replicating their method for reading the input buttons as described here: http://picbasic.co.uk/forum/showthread.php?p=56697