Pulse Decoding

[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