What I've learned this month on the forum.....

RF: Manchester coding works. Very important for newbies. If you have patience, you can send large strings WITHOUT manchester coding. I also found that if you send the data INVERTED it will generally get there in better shape. Sending SYNK bits as a header is a great idea, and using the SERIN2 command with a qualifier will make life sooooooo much easier....... Here is my example:

transmittemp:
let i=0
for i = 0 to 2
portd.1=1 'switch on TX module
pause 125 ' wait a 125 mS to stabilise TX module
serout2 PORTd.0,16780,[44,44,44,44] 'sends command to temp module
pause 25 ' wait a little to organise PIC's thoughts
next i ' Next Pass
portd.1=0 ' Switch off TX
portc.3=1 ' Switch on RX
pause 25 ' 25 mS to stabalise
SERIN2 PORTc.4,16780,350,failuretemp,[wait("*"),STR temp\17] ' Get data - IF it begins with *
portc.3=0 ' Switch off RX
if temp[0] <> "*" then goto transmittemp ' If RX is not good, try again
if temp[15] <> "." then goto transmittemp ' If RX is not good, try again
HSEROUT [str temp\21,13,32,CR] ' Display the good data
clear ' Clear the array

Now, some of you experts might find this long winded, but it WORKS. If the RX doesn't receive what it wants, then it ignores the data and asks for it again from the temp module.

For those who are interested, this is part of the Temp module code, the one that reveices the command and sends the Temp afterwards....

tempsend:
portc.1=0 : ' Switch OFF RX module
portc.3=1 ' Switch ON TX module
for c =0 to 2 '
pause 50 'pause 50 mS
SEROUT2 PORTc.2,16780,[$55,$55,$55,$55,$55,"**Temperature ",dec2(temp/100),".",dec1 (Temp/10),"+"]' $55 is a SYNK bit, and the * is an indicator for the RX module.
PAUSE 25 ' Pause 25mS
next c ' next pass
portc.3=0 : goto main

Temp[0] is the first character in the Temp array AFTER the first "*" is ignored. This is a great way of checking that the data you received is actually data and not garbage (from your alarm keyfob or garage door opener), and I have put 2 checks in because there are 2 different data sets to be received, both are of different lengths.

I have had this working fine for about 4 hours, but previously without the Temp[0] checks I had it working for about 24 hours and only lost about 5% of the data I sent. Not bad eh?

What I would like are comments from all you lot out there who know this stuff better than I do. Several people on the forum have helped me out on this project with different suggestions and ideas, and general help, and now that I have learned how to do this I want to spread the knowledge to anyone who has a similar problem to what I had.



As ever, I accept no responsability for bad grammer, mispelled words or the weather.

Cheers,
Noel

Quote:

---

Originally Posted by gringobomba14

RF: Manchester coding works. Very important for newbies. If you have patience, you can send large strings WITHOUT manchester coding.

---

Yes, it works fine as long as you do actually send a few 'sync' characters to set up the data slicer in the RX AND you keep your data strings short.
However, when you start sending long data strings (greater than about 20ms or so, at least that's my experience with the modules and setup I'm using), you WILL start losing data as the data slicer gets farther and farther out of whack.

So I have limited the actual data sent, INCLUDING SYNC bits to about 20 chars long. It works perfect over short distances (10 cms) and long distances (almost 80 meters). I am happy to share my experiences with anyone who is interested, newbies and experienced peeps alike

Quote:

---

Originally Posted by gringobomba14

So I have limited the actual data sent, INCLUDING SYNC bits to about 20 chars long. It works perfect over short distances (10 cms) and long distances (almost 80 meters). I am happy to share my experiences with anyone who is interested, newbies and experienced peeps alike

---

Also (and again, this is just my happenings with the modules and set up that I'm using), for some reason, I don't know why, and quite frankly, I don't care...
If I send my data at 2400, it fails the vast majority of the time. 9600 passes about 95% and my modules are supposed to max out at 4800. 19,200 baud (WAY above spec) passes about 75% at around double the distance.
Again, don't know why, don't care, just know it works out that way.
So, you might want to play with the speed a bit, see if you can get longer distances one way or the other.

I have found that at 2400 and 4800 I get between 75 and 95 % first pass rate, as long as it's inverted. 1200 and 300 I may as well give up, and 9600 was only about 50% first pass rate. I'm now using FM modules, which I found to be much cleaner than the AM modules I bought, although I can use both with the program and get the proper data on the screen now...just takes a few seconds longer while I wait for a "good" transmission

In the cold light of day I might just "play" with the baud rates and see if increased speed = increased distance.
What modules are you using Ski??

Yes, manchester encoding works but there are simpler methods for sending short data bursts which work better.

Sync bytes are a lousy idea. See the screenshot at http://davehouston.org/rf-noise.htm (the bottom of the page) to understand why.

A single, wide pulse acts both as a start-of-frame indicator and to set the receiver's AGC and dataslicer threshold. See the screenshots at the top of the above cited page for an example.

Byte balancing sends each byte twice with the second byte a bitwise complement of the first and immediately following the first. This addresses the dataslicer threshold drift noted by skimask and gives you built in error checking - if the two bytes do not sum to $FF there's an error. Leaving a fairly long gap between data bursts allows the receiver AGC to reset. You can see its effects in the slope of the pulse in the screenshots on the above cited page.

I've provided an example in the Code Examples forum. X-10 has used the NEC protocol for its RF devices for over 30 years. Even Philips, which uses manchester encoding in all of its protocols, prefaces them with a long pulse to denote start-of-frame.

One thing you haven't learned yet is to

Code:

---

put your code
    in a form
that is more
    readable

---

That is a very interesting page Dave, and one I will be visiting again and experimenting with ASK and FSK. Just out of curiosity, ASK seems more like AM and FSK seems more like FM, but with logic 1's and 0's instead of Casey Casum and the like....would this be correct?

Code:

---

I wonder does this work

---

Quote:

---

Originally Posted by gringobomba14

In the cold light of day I might just "play" with the baud rates and see if increased speed = increased distance.
What modules are you using Ski??

---

For one, the TWS/RWS-434 modules from www.Rentron.com
Others, I've gotten from www.sparkfun.com, the 434 TX/RX pair (don't remember the model # of the top of my head)
They're practically identical. I usually add them into an order as an after thought to keep a couple extras on hand.

The one's from Spark Fun do not have an analog (i.e. linear) output. That's not much of an issue unless you want to measure the received signal strength.

The TWS/RWS (Wen Shing) are available from many dealers worldwide and have been cloned by several manufacturers.

Here's another, dirt cheap, source. [url}http://www.e-madeinchn.com/Product.htm[/url]

ASK (Amplitude Shift Keying or On Off Keying) is AM and FSK (Frequency Shift Keying) is FM. Most FSK modules cost more but you can use their Carrier Detect pin to tell when a signal is present, doing away with any need for sync bytes or start-of-frame pulses.

Range (i.e. distance) is independent of baud rate and is almost 100% a function of transmit power (severely limited by the FCC) and environment. It is, however, easy to increase range by improving the receiving antenna, adding preamplification, etc. Some receivers (e.g. the dirt cheap ones above) cannot handle a preamp, others (e.g. Wen Shing) can handle 2-3 cascaded.