I’m in the process of getting a KLPA link running and, if I understand some of the other posts, it isn’t always easy – so I thought I’d see what the fourm might have to say.
I have the devices hooked up and running, but with sporadic results. I found that they need bypass capacitors on the power lines – .047 ufd worked for me.
Strong Signals:
I think that there is a problem with strong signals overloading the receiver. My performance is poorest with the RX and TX in close proximity. If I spread them apart (five feet with 6 inch quarter wave antennas) things get better, but still touchy. The serial output looks good on the scope, but suspect that some early bits of the signal burst are getting clobbered when the signal is strong. Since I want to use the devices in both near and far applications, this appears to be a troublesome problem. Has anybody else experienced this?
What should be done with the second data pin on the receiver? There seem to be several thoughts on this and I’m not sure which one is optimum. Some seem to say to leave it open – others say to ground it. In looking at it on a scope, it seems to duplicate the other pin so I am reluctant to ground it. Some say it is an analog output for test purposes – I seem to see only a digital signal, but that may be due to the strong signals.
When it is working, I am seeing good nose rejection using a simple ASCII character preamble to qualify the rest of the ascii transmission. Hopefully that and a checksum will allow a reasonably reliable system. Otherwise I guess manchester coding will be the next step.
Boost C (unsolicited product plug)
I am using Source Boost C to program the PIC and couldn’t be happier with it. It’s inexpensive (even free), reliable and comes with a nice IDE. Support is also very good via their forum that is monitored by the developers who frequently step in and get folks out of trouble.
It does appear that the KPLA receiver has difficulty with strong signals. Below is a scope photo showing how well the receiver duplicates the output of the transmitter for a very strong signal and, below that, for a more normal (but not weak by any means) signal. Note the significant shortening of the bits under strong signal conditions.
These photos also confirm that the signal out of the transmitter is on-off keying with no sophisticated protocol – but then what can you expect for such a reasonable price.
The signal shown was 1200 baud. The bit shortening would, of course, be really devastating for a 4.8 kB bit stream.
I usually shy away from running straight serial over those links - I personally prefer something more like manchester encoding. Takes more software to recover clock/data - but its a more reliable encoding.
I’ve experience this overdriving situation before as well. I assume that it can be compensated for by writing a software serial driver instead of relying on the hardware UART module to handle the I/O… although I’ve never done it because I’ve never needed to use the modules when closer than 4 feet or so.
Also, these modules and most others like it, will not work very well / if at all when sending more than a few bytes without some sort of DC balancing. The driving circuit just cannot recharge fast enough when transferring at anything but relatively slow speeds.
Manchester encoding is by far the easiest methods, and there are a few posts about it here on the forums. 8B/10B is also another popular encoding scheme, but is harder to implement. While the most common form of manchester encoding results in half the speed, 8B/10B encodes 8 bits into 10 bits and thus only a 20% speed degredation.
In addition to the encoding scheme, for longer “data” transmissions, CRC is pretty much a must have. The encoding scheme keeps the hardware running, and the error checking keeps the software running.
Thanks for the input on Manchester. I have actually been having pretty good luck with the KLP now that I understand it a little better.
Here are some of my thoughts.
Bit distortion at close range seems to be something that has to be lived with so I keep the units about five feet apart – it even works with quarter wave antennas on each unit
I was trying to recover data bursts with the transmitter turned off between bursts. The trouble I was having seems more related to the internal UART syncing up than with the bit stream. I suspect that the UART is a little discombobulated after listening to all of the noise with no signal present. Once things sync up everything is fine. So now I fill the dead air time with filler characters. My system just listens to the filler and doesn’t start to grab the data burst until is sees a couple of “start of message characters”. Then it reads data until it sees end of message characters. In that mode I have been able to walk away for 500 feet (open space) with no errors. I suspect I could just append a short preamble of synch characters to my data bursts and do the same thing. Looking at the data stream out of the receiver shows that the first characters of the burst are OK, so it’s apparently just the UART settling down that was giving me trouble. I have seen the same problems with the units hard wired together – at least on start up of the system.
I did a test to see if long strings of ones or zeros might be screwing up the data and couldn’t get things to fail. I sent alternating space (ASCII 00100000) and ?(ASCII 00111111) and didn’t see the receiver (or UART) having any trouble reproducing the data stream.
Here’s a photo of the data stream between the receiver output and the UART input pin. It shows a $ followed by alternating ? and space. Nothing looks out of the ordinary…
I wonder if the KLPs haven’t been getting a bad wrap because somebody might have used AC coupling between the receiver output and UART input. This could cause a dc level shift (drift) that would start making trouble with long strings of 1’s. In AC coupled video amps of yesteryear they had what was called a dc restoration circuit to keep the black (?) reference from drifting. I suspect that they do it differently these days.
Hopefully all of this will be helpful to the next guy who tries to tame the KLP devices…
Also, one thing I forgot to mention; when using a UART module, the UART has to know when to begin the “packet,” and because the receiver outputs noise constantly, it’s almost guaranteed not to be synced correctly. One common way to get around this is to send alternating 0’s and 1’s as the beginning of a transmission. This helps the “slicer” in the receiver module line up the edges and makes things easier to deal with on the UART. On a PIC, you’ll have to clear the misalign error bit in order to receive more “packets,” but this will eliminate the need for constant transmission between data bursts.
I do have to add that I got the 500 foot range using a 1200 baud rate, so I wasn’t working the receiver too very hard. And it was from a second story window overlooking a soccer field behind our house. I suspect it would be less at the maximum KLP usable rate of 4.8 kB. I’ll be trying that and reporting in the next few days.
I was seeing close to that distance using manchester coding at around 10Kb (so effectively 5K). I was also seeing about 100ft going through 4 lathe and plaster walls. I use a manchester-illegal preamble to sync up and it has good reliability. I also use packets with checksum and am seeing about 2% loss.
The Spec for the KLP — which is so full of typicals as to be almost useless — shows the RX having a max rate of 8K and the TX as having a max rate of 10K — which in itself is an interesting spec for a supposedly matched RX/TX pair.
Be prepared to spend some time taming those new units. It seems as if everybody has initial problems, but eventually it all works out.
Just remember:
Bypass the Power pins
Be aware that, even without antennas, the units act screwy if too close together.
If you are using a UART (and who isn’t) be aware that it may take a couple of characters for the UART to settle down (sync) after listening to the receiver noise. I send a couple of dummy characters prior to the message.
The second receive data pin seems to be a duplicate of the first and can be left hanging – don’t ground it.
It seems as if the TX/RX pair are happiest with a non-inverted serial signal. My PIC 16F877 TTL serial output is inverted and I had better luck after installing an inverter on both ends (RX & TX). Your milage might vary…
Regarding the 2nd rcvr output pin: There seem to be multiple variants of the modules. On the ones I have, those 2 pins are tied together (you can see the etch on one side of the module).
Other (earlier?) versions had an ‘analog’ output, which should allow you to do stuff like adding your own circuitry to the slicer, etc.
Regarding the too-much-signal issue: You could get fancy and add some circuitry to change the antenna configuration on-the-fly. In particular, add an option to disconnect your existing antenna. Then send each packet twice - once without the antenna, then again with the antenna.
