SparkFun Forums

[norlin]

I set up my KLP circuit as described in the KLP walkthrough. I have a PIC uC sending out a constant string "Test" and have the receiver end connected to a MAX232 chip which connects to a PC running hyperterminal.

If I connect the TX line of the uC directly to the MAX232 I get the "Test" string over and over (with a 0.5s delay between each transmission of the string "Test").
Now I put the RF modules in between. I'm not sure what capacitors to add if any, so I put some between ground and Vcc as is my usual practice. When I hit "reset" on my uC, I get one clear "Test" string output on hyperterminal followed by a lot of garbage. When I hit reset again I get the "Test" string once followed by garbage again, I have the devices about 5ft apart, will try seperating them further tonight (not enough room in my office to spread them out further lol). Below is a sample output, you can see where I hit reset over and over to get a bunch of "Test" strings in a row, that's how it should look w/o me pressing reset.

Any clues how to make this better? I made a helical antenna for the transmitting end out of 22AWG wire, 15 turns with about 3mm diameter which seemed to help (I wasn't even getting a single "Test" transmission w/o it, just garbage).



TestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTes
tTestTestTestTestTestTestTestTestTest(óúÄúú³úvúú%Äú ^ úÄúãúp³úðð ÄúúúÄ
œMúðúðúã{> œãÄòV7ãú%ú{Qð ³ úœ³ðúTest#MQMQVestHTestTe
stððœúððúúððúððúúðúúúúúúúðúúúúúúúðð³ |*^³úðBTVestUestTestT
estTestœDã 9úijœ
úúø óG  G8óÄ´ú9@ð´œ@ú@Äq³púðÄNú`ÄÄð`@ú`Ä
ð@@³ú@œúN³±Äú ð`@ÄúÃÄ`bt``Ä ±úbtpÄNÄ` úl úbt ú``úP ú`úP ú`úú
``tP ú bt @@tø±@@± ±@AH`@@@`ú !±@
@Ä@` úD@@A@t ` ±@± H(@@A@@@@ @
±@@@P@A@@@ú !@D

[norlin]

Adding a similar antenna to the receiving end got rid of the garbage I was seeing (unless the transmitter and receiver were too close together). Now at home I placed the modules further apart and am getting the "Test" string over and over properly, yay! However, I do get errors fairly frequently as posted below. Best way for eliminating these? An encoder/decoder IC? Also, guessing I just need capacitors near the modules going between VCC and ground, is there others that would be useful? Something on the RX or TX pins?

TestTestTestTestTestTestTestTestTestüÀÀÀÏæ@estestestestestTe
stTestPestPest@estPestestestestestestTestTestTestTestestestdstestestestTestTestT
estPestPestest`stestÀþøÆ estestTestTestTestPest@estestestdstø üestestestTestTest
Pest@estestestestestestTestTestTestTestTestest@estestdstestTestTestTestTestTest
est@estestestdstestTestTestTestTestPestPestestdstdstT`stTestTestTestTestTest@est
@est@estest`stTestTestTestÀ

[riden]

Balancing the data (one way is to send a character followed by its complement) instead of sending the same string over and over will help. Know that you can expect an occasional error under the best circumstances. That is why people implement error detecting or correcting code.

[reklipz]

I don't believe these modules are meant to be a replacement for a wire (ie, make a wired serial interface wireless). You're going to need some sort of intermediate interface between your data source/sink (for lack of a better term) and the transmitter / receiver.

One of the problems has to do with the way the ASK modules work, in that sending too many ones in a row will eventually drain the cap/inductor/energy storage on the transmitter and it is no longer able to transmit that signal.
(this is probably way oversimplified, but it's enough to get the point across)

As riden said, you'll need to look into some sort of DC balancing scheme.

Manchester is fairly simple to implement, but cuts effective transmission rates in half.

8/10 encoding encodes 8 bits into 10 bits and is used in SATA and PCIE interfaces, but is a bit harder to implement.

There are many threads here that deal with this issue. Also, I'm not sure of your application, so if any / all of this is unnecessary for your app, sorry for the confusion.

Good luck!

[saipan59]

Occasional bad data can't really be avoided, since you likely have neighbors using devices on the same frequency (garage door openers, for example).

Pete

[norlin]

yeah, occassional bad data will be fine for my project, was just using a test string but data won't be like that. If I get 60%+ good data I'd be happy with it, as it is it looks like I'm getting 85%+

[Philba]

Most communications systems presume the existence of noise (i.e. transmission errors). You should use or create a protocol that allows you to verify the transmission. I have used a simple packet based scheme that uses a check sum to verify the packet. With short packets, it works well. I put a byte count, payload and checksum in the packet. bad check sum and I toss the packet. payload is usually just a few bytes. If you are using tranceivers (rx and tx on both ends), you can use an acknowledgment scheme (like tcp/ip) or you can just design your app to tolerate lost packets.

Larger packets could use CRC and there are lots of error correction schemes but simple has it's virtues.

[norlin]

when transmitting from my PIC, I'm not sure how I'd put any checksum programming on the PC receiving side where I'm using hyperterminal, and when receiving data with the PIC, once again not sure how to transmit checksummed data from the PC unless I write my own application to replace hyperterm? Though for PIC to PIC communication this of course would be easy for me.

[saipan59]

I'm not sure how I'd put any checksum programming on the PC receiving side where I'm using hyperterminal, and when receiving data with the PIC, once again not sure how to transmit checksummed data from the PC unless I write my own application to replace hyperterm?

Can you tell us what is the goal?
If the received data is to be viewed by a Human via Hyperterm, and you don't want the occasional errors to be displayed, then you need something between the rcvr and Hyperterm to verify the checksum on each packet, and then do something when the checksum is bad.

I gather that you already have a PIC at each end of the link? Or only at the xmtr end? Please explain your complete (desired) configuration.

Pete

[Philba]

yes, pete is correct. Simply put, you can't use RF as a cable replacemet with out something to handle the inevitable errors. You could write some PC software that understands your protocol. It's not that hard. I believe there are open source terminal programs out there you could adapt.

[norlin]

Basically have a PIC on both ends, the receiving end only responds to 5 characters that is receives, so if it received anything else it just ignores it as garbage which is why I'm not so bothered if it has a high error rate. If the garbage it receives happens to be one of the characters it responds to, it doesn't matter to much either as it only results in about 0.5s of activity before it waits for another valid character.