RF and PIC basic

[turkbey]

Hello dear friends.
I want to make a new project but, have some unknown.
I have a transmitter module 433,92 Mhz rf module and PT2262 encoder I send any data and adress word. than I want to use rf receiwer modules 433,92 and PIC16F628 for decoding.
So how can I read from PT2262 IC's datas whith PIC16F628
Thanks for all

[mackrackit]

If you use an ENCODER you will need a DECODER. (normally)

[turkbey]

yes it is true ..and I know. but I dont want to use any decoder Ic. because my project is working with PIC16F628 . so I want to write decoder code in my PIC16F628.
thanks.

[mackrackit]

I do not remember exactly, but I think dhouston or Bruce had a way to do this. Might have been for a Holtec Encoder though.

Found it.
http://www.picbasic.co.uk/forum/showthread.php?t=6581&highlight=decoder

[dhouston]

The datasheet for the PT2262 doesn't provide any description of the communication protocol so, for starters, you will need to capture a few (different) codes and analyze them. This page shows how. http://davehouston.net/learn.htm

[dhouston]

I found another datasheet that does describe the protocol used by this chip. While the specifics for a "1", "0", and "F" differ from Holtek, the overall approach is very similar to the HT640. A bit period depends on the encoder oscillator frequency (set by an external resistor) you still need to capture some codes to determine the bit period. And there are some encoder pins that can be used either in the address or in the data so you'll need to determine that, also. Then you should be able to adapt Bruce's HT640 code to work with the PT2260.
http://www.spelektroniikka.fi/kuvat/PT2260.pdf
http://www.picbasic.co.uk/forum/showthread.php?t=6581&highlight=holtek

[Megahertz]

Any ideas (Bruce's code for HT640) if this will work if HT640 is used with other RF modules, like the normal el chipo style?
I will give it a go to decode PT2262 soon.

[Ioannis]

I tried to decode a UM3750/MM53200/HT12 type encoder with this either as subroutine or as Interrupt Driven Routine:



GET_CODE:
PULSIN DIN,0,NUMS
IF NUMS > 8200 and NUMS<12000 then 'Detect Header
goto get_pulses
else
RETURN
endif
get_pulses:
FOR X = 0 TO 11 ' read 12 pulses
PULSIN DIN,1,NUMS '
if NUMS>220 then
if NUMS<300 then
code.0[x]=1
endif
endif

if NUMS>450 then
if NUMS<560 then
code.0[x]=0
endif
endif
if NUMS=0 then
loops=0:code=0:flag=0
RETURN ' temp=0:
endif
next x
if loops<3 then
if prev_code=code then
loops=loops+1
else
prev_code=code
loops=0
endif
endif
return


But I got a delay in decoding. It just gets one every 4 transmissions. So for a 4 times check of equall transmitted codes, it takes more than 250ms to give a valid. With the Logic Digital Analyser it is confirmed that it takes 1st transmission, then 4th etc.

The numbers in NUM are PIC and OSC clock dependant.

If anyone can spot why, please reply.

Ioannis

[mackrackit]

What var size is NUM?

[Ioannis]

Word sized.

It does work but gets one every 4th. Very strange...

I have not here the Logic. In the afternoon I will post a shot of the pulses to make it more clear.

The posted routine was tested also as part of Darrels DT-INTs on a fast 16F1827 chip at 32MHz clock.

Ioannis

[Jerson]

Ioannis, not sure what you mean by gets one every 4th. The way I understand your statement is that you get a valid pulse once in 4 transmissions. If that is correct, the code which does that is the loops part. if loops < 3 then ..... When it finds a code 'repeated' 4 times, it transfers to the Prev_code. Is that what you're looking for??

[Ioannis]

Hi Jerson. No, it is not that the case. It just gets the first train of pulses but not the second one after the header of 11ms. It waits for a reason that I do not understand and gets the 4th train again. I try to get a shot from the Logic screen and post it next.

Here is the picture:

5726

The first channel shows the data received from the Rx module.

The second shows every time the routine detects the header like this:



PULSIN DIN,0,NUMS
IF NUMS > 8200 and NUMS<12000 then
toggle portb.4
goto get_pulses
else
RETURN
'goto get_p
endif


That delay is constant and not random. So it must be either a shortage ofthe lanquage or my mistake (possibly).

Ioannis

[Agent36]

I know this is an old thread, I am trying to decode a PT2262 encoder using a PIC could do with someone looking at my code to see where I am going wrong. The code is modified from Bruce's Holtec decoding routine.
I can read the buttons pressed using the code below, but it only works if I hold the Tx a few inches from the Rx. I think there is a timing problem.
I have measured the waveforms at the output of the encoder and they are;
120uS for a logic 0 and 400uS for a logic 1 with a duty cycle of 500uS. Each pulse train is spaced at 4mS, each button press is repeated 4 times. See the data sheet posted in dhoustons link above.
I am using the bit24 (sync) as the reference bit as its the only constant in the pulse train.

Thanks Nick



@ __config _INTRC_OSC_NOCLKOUT & _WDT_ON & _PWRTE_OFF & _MCLRE_OFF & _BOD_OFF & _CP_ON & _CPD_ON

OSCCON = %01110000 ' Internal 8MHz osc
ANSEL = %00000000
CMCON0 = 7
Define OSC 8 ' Define oscilator speed
DEFINE DEBUG_REG GPIO
DEFINE DEBUG_BIT 0 'GPIO.0
DEFINE DEBUG_MODE 0 'Inverted
DEFINE DEBUG_BAUD 9600 'Baud rate to LCD
define DEBUG_PACING 1000
DEFINE PULSIN_MAX 3000 ' Set MAX wait period
INCLUDE "modedefs.bas"


GPIO=0 ' All outputs = 0 on boot
GPIO=%00100000 ' GPIO.5 = in, rest outputs.

PBIT VAR BYTE[24]' Pulse-in results of high-going address/data/ synch
NUMS VAR WORD ' Pulsin result of low-going synch period
ADDRESS VAR Byte ' Holds decoded 8-bit address
ADDRESS2 VAR Byte ' 2nd address storage for verification pass
ADDRESS3 VAR BYTE ' 3rd address storage for verification pass
DBYTE VAR BYTE ' Holds decoded 8-bit data byte
DBYTE2 VAR BYTE ' 2nd data byte storage for verification pass
DBYTE3 VAR BYTE ' 3rd data byte storage for verification pass
X VAR BYTE ' GP loop counter/array index pointer
Y VAR BYTE ' Address & Data bit index pointer
Z var byte ' Used to display button press
LOOPS VAR BYTE ' Loop counter for address & data match
P_MAX VAR BYTE ' Wide pulse (indicates GND)
P_MIN VAR BYTE ' Narrow pulse (indicates Vcc)

DIN VAR GPIO.5 ' Data input pin from RF receiver
LED VAR GPIO.2 ' Visual cue
High LED
pause 2000
Debug $FE,1,"Power UP" 'Output received data to the world
pause 500
Debug $FE,1,"Waiting for" 'Output received data to the world
Debug $FE,$C0,"Button press"

Begin: ' Clear vars on power up & start over.
ADDRESS=0 : ADDRESS2=0 : ADDRESS3=0 : DBYTE=0 : DBYTE2=0 : DBYTE3=0 : LOOPS=0

GET_P:
'PULSIN DIN,0,NUMS ' Get low going synch period pulse.
'IF NUMS = 0 THEN ' If NUMS=0, no synch pulse within defined period.
' Loops=0 ' Clear "1st pass" address & data loop counter.
' GOTO GET_P ' Keep looking.
' ENDIF

' Normally the synch pulse is between 11-16mS, so we'll reject any synch pulse < 10mS
' to allow for variations in timing & transmitter voltages.
'IF NUMS < 1000 THEN GET_P ' 1000 X 10uS = 10mS (PULSIN = 10uS resolution at 4MHz)

FOR X = 0 TO 24 ' 25 bits in total for pt2262
PULSIN DIN,1,NUMS '

IF NUMS < 20 THEN GET_P 'USED TO REJECT NOISE

PBIT[X] = NCD NUMS ' 25 bits total. 1 synch, 16 address, 8 data
NEXT X ' Note that the PT2262 uses two pulses form each bit.

' Now load P_MAX & P_MIN for sort loops below to sort out
' address/data bit logic states.
P_MAX = PBIT[0] ' Not used yet
P_MIN = PBIT[24] ' "narrow" synch bit

' Decode 8-bit address
ADDRESS = $FF ' Start with all 1's & find each zero bit
Y=0 ' Zero address bit index pointer

' PBIT[0] + PBIT[1]=1st address bit. PBIT[14] + PBIT[15]=last
FOR X = 0 to 15 STEP 2 ' Increment x 2 each pass
IF (PBIT[X] = P_MIN) AND (PBIT[X+1] = P_MIN) THEN
ADDRESS.0[Y]=0
ENDIF
Y=Y+1 ' Increment address bit index pointer
NEXT X

' Decode 8-bit data byte (decode button press)
DBYTE = $FF ' Start with all 1's & find each zero bit
Y=0 ' Zero data bit index pointer

' PBIT[16] + PBIT[17]=1st data bit. PBIT[22] + PBIT[23]=last
FOR X = 16 TO 23 STEP 2 ' Increment x 2 each pass
IF PBIT[X] AND PBIT[X+1] = P_MIN THEN DBYTE.0[Y]=0
Y=Y+1 ' Increment data bit index pointer
NEXT X

' On 1st pass, load 1st address & data into verify registers,
' then return for 2nd pass at pulsin. We'll make address &
' data match twice before moving on.

Loops = Loops + 1 ' Increment loop counter
'if LOOPS = 1 THEN GET_P
IF Loops = 1 THEN ' 2nd pass through?
Address2 = Address ' Yes. Load 1st address into match register
DBYTE2 = DBYTE ' Load 1st data into match register
GOTO GET_P ' Get 2nd readings for comparison with 1st two
ENDIF

' 2nd pass, so verify address & data bytes.
' If they match, show button press
CONTINUE:
IF (DBYTE = DBYTE2) AND (ADDRESS = ADDRESS2) THEN ' Show only if both data bytes equal


if DBYTE2 = %11110001 THEN Z = "B"

if DBYTE2 = %11111000 THEN Z = "A"

if DBYTE2 = %11110010 THEN Z = "D"

if DBYTE2 = %11110100 THEN Z = "C"

Debug $FE,1,"Add=",$14,#address2 'Output received data to the world
Debug $FE,$C0,"Button=",$14,z
ENDIF


GOTO Begin ' Start over.

END

[koraydin]

Hi Agent36,
Have you had a chance to get an answer to your issue mentioned in your last message?. I am going to start a project to decode PT2260. So I wanted to be sure that the code works without an issue. You mentioned that code works if the distance is so close (a few inches).
Best regards
Koray