Thank you.
Now i have recived the Parallax RF modules and write this test programs
Transmitter PIC16F628A whit Internal RC OSC at 4 MHz
Reciver PIC16F872 with 20 MHz OSCCode:<html> <head></head> <body><!--StartFragment--><pre><code><font color="#008000"><i> </i></font>CMCON = <font color="#808080">7 </font><font color="#008000"><i>'Alla I/O Digitala </i></font>LEDPin <font color="#000080">VAR </font>PORTB.<font color="#808080">0 </font>TransmitterPIN <font color="#000080">VAR </font>PORTB.<font color="#808080">4 </font><font color="#000080">INCLUDE </font><font color="#FF0000">"modedefs.bas" </font>Counter <font color="#000080">VAR BYTE </font>Synk <font color="#000080">VAR BYTE </font>Synk = <font color="#808080">$55 </font><font color="#000080">DEFINE </font>CHAR_PACING <font color="#808080">1000 </font>Counter = <font color="#808080">0 </font>Main: <font color="#000080">HIGH </font>LEDPin <font color="#000080">PAUSE </font><font color="#808080">100 </font><font color="#000080">LOW </font>LEDPin <font color="#000080">PAUSE </font><font color="#808080">100 </font><font color="#000080">SEROUT </font>TransmitterPIN,T1200,[Synk,Synk,Synk,Synk,Synk,Synk,<font color="#808080">9</font>,Counter] <font color="#000080">HIGH </font>LEDPin <font color="#000080">PAUSE </font><font color="#808080">100 </font><font color="#000080">LOW </font>LEDPin <font color="#000080">PAUSE </font><font color="#808080">100 </font>Counter = Counter + <font color="#808080">1 </font><font color="#000080">PAUSE </font><font color="#808080">600 </font><font color="#000080">GOTO </font>Main <font color="#000080">END </font></code></pre><!--EndFragment--></body> </html>
It´s working very well whit in the rance of 50 - 60 meters whit the transmitter indoors and the reciver outdoors, but when i take the reciver also indoors in a house 50 - 60 meters away from the transmitter the counter on the reciver display starts to show wrong numbers sometimes but it´s still counting... but whit the reciver outdoors it does not miss a single number whit in 50 - 60 meters.Code:<html> <head></head> <body><!--StartFragment--><pre><code><font color="#008000"><i> </i></font><font color="#000080">DEFINE </font>OSC <font color="#808080">20 </font><font color="#000080">DEFINE </font>LCD_COMMANDUS <font color="#808080">3000 </font><font color="#008000"><i>'Set command delay time in us </i></font><font color="#000080">DEFINE </font>LCD_DATAUS <font color="#808080">200 </font><font color="#008000"><i>'Set data delay time in us </i></font><font color="#000080">INCLUDE </font><font color="#FF0000">"modedefs.bas" </font>Counter <font color="#000080">VAR WORD </font>ReciverPIN <font color="#000080">VAR </font>PORTC.<font color="#808080">0 </font>ADCON1 = <font color="#808080">7 </font><font color="#008000"><i>' Alla digitala </i></font><font color="#000080">PAUSE </font><font color="#808080">500 </font>Main: <font color="#000080">SERIN </font>ReciverPIN,T1200,[<font color="#808080">9</font>],Counter <font color="#000080">GOSUB </font>LCD <font color="#000080">GOTO </font>Main LCD: <font color="#000080">LCDOUT </font><font color="#808080">$FE</font>,<font color="#808080">1 </font><font color="#000080">LCDOUT </font><font color="#808080">$FE</font>,<font color="#808080">$80</font>,#Counter <font color="#000080">PAUSE </font><font color="#808080">500 </font><font color="#000080">RETURN END </font></code></pre><!--EndFragment--></body> </html>
Any idé how i can to improve my code?
I´going to do some more tests to tomorrow, it´s soon time to sleep here in sweden...
RF is tricky, no matter what you do. Just too many variables for the average joe to account for, circuit layout, power stability, sunspot cycle, and so on and so on...
My experiences: (which are far outweighted by a number of people on these forums when it comes to RF)
-Try changing the number of sync bytes in the transmitter...6 sync's is a good start. Try 2, try 10, try anything, see what happens.
-Try changing the baud rate. I had a TX434 from Rentron. The datasheets say it's only good for 4800bps. I got it to work very reliably at 9,600 and fairly decent up to 19,200, but it didn't like 2400bps. Try 2400, try 9600, try 4800...
-Change the PACING length. You have it set at 1000, a decent number. But...maybe the RF module wants less. If you have 1ms between each character, that also means that you have 1ms between each sync character, which may be screwing up your sync'ing, which may mean that the data slicer isn't being balanced completely. Try leaving out the PACING altogether, sending your sync bytes as fast as possible, then manually PACING your sent bytes with a slight pause in between each character.
Get a better antenna at the receiver. You can build a very simple but very good one from plans on my web page.Any solid copper insulated wire will work (the bigger the wire diameter, the better) or you can even use copper tubing if you can insulate it, and you can cheat by using 75-ohm coax for the phasing line. If you still need more range, then add a wideband preamp between the receiving antenna and receiver - it's the Ten-Tec 1001.Ignore the picture - it's the wrong one.
And try without pacing.
When i disconnect the power from the transmitter the reciver display still shows numbers, but does not count from 0 to 255, it´s shows 1, 244, 34, 55, 23, 99, 138, 232, 233 and so on.... where does this numbers come from?
Sounds like random noise. There is RF every where.
I think the internal "slicing" capacitor is wondering around giving false data.
If this is the case, depending on what you are going to use this for the solution can pretty easy.
If you are sending commands for a remote control the easy way is to have something like
If you are sending data like what you are now, you may need to set up a way to verify the data. Some sort of encoding / checksums...Code:SERIN ReciverPIN,T1200,[9],Counter IF Counter = ??? THEN XYZ ELSE QRS
The Linx web site has some info on this and dhoustion has a protocal on his web site.
Dave
Always wear safety glasses while programming.
I'm not familiar with the Parallax modules, but if they use the Linx LR series, then this receiver will output random noise even if the transmitter is powered down.
Look at the examples on dhoustons' website, and others he has posted here. He knows what he's doing.
You might also try a search here. I have posted several code examples for RF communications that are very simple to implement, and work quite well with PBP & noisy receivers.
It's just not that simple to get a reliable wireless connection up & going, and it's for sure not going to be anywhere near as simple as a 'wired connection', but there are enough threads here 'with code examples' that cover this if you look hard enough.
Like Bruce, I'm unfamiliar with the modules you chose. From your description it seems like they are superregenerative receivers. Seefor an explanation of the noisy output. It can be caused by environmental factors or come from internal noise sources (e.g. resistors).
Using SerIn with this type of receiver creates two problems. One is that SerIn samples the data at the mid-point of the bit period. If the output is high at that time, you get a 1 bit and, if low, you get a 0 bit. Random noise can give you either state. The other problem is that you need to set the receiver AGC and ATC (Automatic Gain Control & Automatic Threshold Control) and you need to signal the receiver that some data is on the way. The sync bytes recommended by several people who post here are intended to serve those purposes. EDIT: If you look at the bottom picture at the above referenced link, you can see how a signal very much like the sync bytes only gradually emerges from the noise. There is a better way but it depends on the type of data that you wish to transmit.
I would only use SerOut/SerIn if I wanted to send text or lengthy data packets. And these receivers are not the best choice for either. FSK gets away from noise and the receiver has a CD (Carrier Detect) output that tells you when data is coming. FSK modules cost more than ASK but not as much as the ones you've chosen.
For short data packets, I prefer ASK and the NEC protocol illustrated in this threadThe long lead-in pulse sets AGC & ATC and signals that a data packet follows. Since the output is only monitored after seeing the long lead-in, random noise is much less of an issue. Instead of sampling at mid-bit, the receive routine measures the length of the spaces between pulses so it's less likely to be fooled by noise or its absence at mid-bit. (It's even better to measure between rising edges but that requires interrupts.) And each byte is sent twice in bitwise complementary form so error detection is built-in.
What is the nature of the data that you want to transmit?
Last edited by dhouston; - 15th February 2008 at 13:35. Reason: Added italicized sentence re sync bytes & noise
Bookmarks