PIC with RF module as remote control

[bananasiong]

Hi,
I've purchased 2 pairs of RF module recently. TLP434A and RLP434 as shown in the attachment. I want to use it as the carrier of my remote control. I'm using a single remote control to control 2 devices. Basically the function is just turning on and off 2 receivers, so I need only 4 different data.
I've referred to Nigel's tutorial 12.3, and I have some question here.
Are the INDF and FSR register working together? It seems their contents are the same. Can I use other defined constant instead of using these?
What is the usage of this: fast CRC-8 algorithm with poly x^8+x^5+x^4+1 executes in 23 cycles per update?
When I bought this RF module, the technician told me that it is good to use the module with the encoder and decoder, as shown in the attachment as well. Any encoder and decoder will work. But I don't think Nigel's and Peter JAKAB's remote control have these encoder or decoder, simply the PIC with the RF module and other application components.
Any idea?

Thanks

 

[Nigel Goodwin]

The PIC does all the coding and decoding, you can send what you want in the data packets - if it's a simple remote control you just need device ID and function - you could use the SIRC's routines from my IR tutorial just as well for remote control via radio.

INDF and FSR are for indirect addressing, consult the PIC datasheet.

 

[bananasiong]

	movlw	0xAA			;set address byte to 0xAA
	movwf	mtx_buffer
.
.
	movlw 	mtx_buffer		;0xAA = b'10101010'
	movwf 	FSR
.
.
outbu0	movf 	INDF,W			;[0xAA]-->w
	call 	update_sum
.
.
update_sum	; fast CRC-8 algorithm with poly x^8+x^5+x^4+1
		; executes in 23 cycles per update

	xorwf	sum,f
	clrw

from the transmitter code above, the content of 0xAA is XORed with the content of sum, but what's the content of 0xAA??

THanks

 

[bananasiong]

I'm not sure whether the RF module is working or not, because I've connected everything well, Vcc and Vss, when I connect the data input pin to Vcc, the digital output at the receiver is around 2V measured, when I connect the input pin to ground, the output is also 2V.
Should I test with the pulses as input signal?

Thanks

 

[Nigel Goodwin]

RF modules aren't DC coupled, so you can't just DC switch the input - feed it a 1KHz squarewave and use a scope on the receiver.

 

[bananasiong]

Yes, I can see the waveform from the receiver by a scope. But when I use a PIC to input to the transmitter, with 500 Hz (1 ms on and 1 ms off) to send 8 pulses, and there is also a PIC with the receiver to count the received pulses. It responses only when it receives 8 pulses. But it seems not working. Is there any easier way to check the communication between 2 PIC's before I do manchester coding? Do I need to pull up or down the input pin of the PIC via a resistor?

Thanks

 

[Nigel Goodwin]

Yes, I can see the waveform from the receiver by a scope. But when I use a PIC to input to the transmitter, with 500 Hz (1 ms on and 1 ms off) to send 8 pulses, and there is also a PIC with the receiver to count the received pulses. It responses only when it receives 8 pulses. But it seems not working. Is there any easier way to check the communication between 2 PIC's before I do manchester coding? Do I need to pull up or down the input pin of the PIC via a resistor?

Check the circuit my tutorial uses, you don't need a pullup - because it's AC coupled you can't input a long high level - 1mS might be too long, if the waveform out of the receiver the same as that going in the transmitter?.

 

[bananasiong]

Yes, the waveform into the transmitter and out from the receiver are the same. I've tried with 0.5ms, but it doesn't work as well.

 

[bananasiong]

My connections are okay, just according to the datasheet and I don't put any decoupling capacitor like yours. Does it cause the RF module not to work?

Thanks

 

[Nigel Goodwin]

My connections are okay, just according to the datasheet and I don't put any decoupling capacitor like yours. Does it cause the RF module not to work?

Any circuit requires decoupling capacitors to help it function properly, you should put capacitors near the power pins on any IC's, and the RF module.

It 'may' work fine without it?, and perhaps has something on the substrate?, but it's good practice to add decouplers!.

 

[bananasiong]

Yes I have decoupling capacitor for the PIC, but not the RF module. I'll try it soon.
And, is it okay if I test it on a breadboard? I think it should be fine since the modulation is done on the RF module itself.

 

[Nigel Goodwin]

Yes I have decoupling capacitor for the PIC, but not the RF module. I'll try it soon.
And, is it okay if I test it on a breadboard? I think it should be fine since the modulation is done on the RF module itself.

The module manufacturers say not even to use stripboard! - never mind breadboard (notice my tutorials have the unused strips removed).

 

[bananasiong]

My program seems to be very long. According to the datasheet, PIC16F877A has 8K memory, in hex, it is 0x2000. As long as the hex file size is less than 0x2000, my program will work well? Even branch from the very begging line to the very last line has no problem?

Thanks

 

[Nigel Goodwin]

The PIC 16F series consist of a number of 2K pages, if you goto or gosub to a different page you have to set it accordingly. As long as you stay in the first 2K of memory this isn't a concern - are you sure your program is anywhere near 2K, 2K is a LOT of assembler!.

 

[eblc1388]

As long as the hex file size is less than 0x2000, my program will work well?

A hex file is an ASCII representation of the binary codes using hexadecimal characters, along with address, data type and row check sum included.

Therefore you cannot just look at the HEX file size to determine the actual binary code size. You need to load the hex file into any PIC programming software and then you can examine/view the actual length of your program.

As a rough guess, the HEX file size will be 2.5x or more the actual size of the binary codes.

 

[bananasiong]

Yup, I'm not referring to the file size, I look at the address of the last line after loading the hex file. I convert it to decimal and found that my program is only more than a quarter of 2k

I've tested the RF module and it works. It didn't work previously because I didn't modify well the Manchester routine. I'm using only a transmitter to switch an LED at one receiver, press a button to turn it on, the same button to turn it off.
But sometimes it can be turned on and off nicely, sometime just stay on and sometimes just stay off. Sometimes I can see it blinking when I long press the button, that's fine.
I've checked everything, decoupling capacitor, connection, etc. How to make it to be more efficient?
BTW, I noticed that there's a op-code "bnz", I can't find this from the datasheet, does it mean "branch if not zero"?

Thanks

 

[bananasiong]

I'm using PIC12F629 for the receiver and PIC16F877A for transmitter. Since 629 provides 4Mhz internal RC oscillator, I planned to use it without a crystal, to reduce cost. I'm using a 4 MHz crystal for the transmitter.
After testing, I found that the receiver works better with crystal; with the internal oscillator, the LED is turned on/off almost only once in ten times pressing the button.
Even with crystal, it is not working very well. Is there any way to improve it? Can I send the signal for 2 times? Then I'll put a delay routine to the receiver after switching the LED, so that it doesn't on and off at the same time.

 

[Nigel Goodwin]

Are you using Manchester routines?, the internal oscillator should be perfectly fine - if changing to a crystal helps?, you're doing something seriously wrong somewhere!.

 

[bananasiong]

Yes, I use the same Manchester routine as yours. It works better if I change it to crystal. I'm still troubleshooting, I know that the internal RC oscillator is good, I'm going to use it as well.

 

[bananasiong]

I'm not sure, but I suspect this: interrupt. My interrupt happens every 4 ms, and around 17 us taken to execute the instructions in the interrupt vector. Maybe when the encoded signal is being transmitted halfway, interrupt happens and delay for around 17 us? If I transmit the signal 2 times continuously would work? Or should I put the Manchester routine in the interrupt vector so that nothing can stop the transmission?
I'm not sure whether the internal RC oscillator is working or not, because I tested it and it didn't work very well, then I used crystal and did some modification, but never try the internal RC oscillator after that.