Hey guys I have found a few answers to my questions but I am currently stuck.
I have a PIC16F688 using UART connected to a TLP434. I know this is working properly at 2400 baud because i hooked the PIC upto to a MAX232 to RS232 to Hyperterminal and the data was dead on. This is one way transmission. Whenever an event is triggered on the PIC 3 unique characters are transmitted.
The digital output of the RLP434 gives me junk. But the junk is consistent with what I transmit. For example if i transmit 100 ‘p’ i get a 100 ‘w’. Looking at the digital output on the oscilloscope it seems to switch some of the high bits to low bits. The high bits seem to be on less then low bits.
So I read on here to hook a voltage comparator upto to the analog output of the RLP434. This works well but the spacing between high and low bits are assymmetric. The low bits are significantly longer than high bits. Are their any simple fixes?
the assymetric nature of the RLP/TLP is inherent in the transmitter design - it takes longer to turn on the transmitter than turn it off. This is a limiting factor for the max datarate. I compensated for that by making my '0’s shorter than my '1’s. However, that’s not an option for you unless you bit bang the async - not hard to do but it’s more work. I think piclist has lots of bit bang code to look at.
Philba:
the assymetric nature of the RLP/TLP is inherent in the transmitter design - it takes longer to turn on the transmitter than turn it off. This is a limiting factor for the max datarate.
Not only that, the receiver’s AGC has to adjust itself. In fact, I think this is the main limiting factor as it takes more time for the receiver to wake-up than the transmitter to ramp-up. My RF telemetry application works well because the 1 to 0 ratio of the transmitted data is within limits so the TX/AGC delay isn’t a factor. Bit-banging the data would give you a lot of control to balance out the ratios, however I’m able to use the hardware UART since my data stream doesn’t have a lot of repeating data.
jet9133:
Any suggestions would be most appreicated.
In your message you said that you are sending a string of 100 of the same character. Have you tried a message string that has a mix of characters (i.e. “-HELLO, SparkFun world-” or some such)? If you get better results with that message but your actual data would be very repetitive (i.e. 00 00 00 FF FF FF), you might want to explore ways of evening out the 1:0 ratio.
I had a strange, yet interesting idea pop into my head this afternoon. Say the data you’re sending has a lot of redundacy (i.e. you are sending the status of 16 switches by sending 16 ‘0’ or ‘1’ bytes). You could employ a simply Exclusive OR routine where you XOR your data against a small array of bytes (i.e. AA 55 AA 55). That way even if your data is all 0’s or 1’s the transmitted data stream will have a better 1 bit to 0 bit distribution.
In your message you said that you are sending a string of 100 of the same character. Have you tried a message string that has a mix of characters (i.e. “-HELLO, SparkFun world-” or some such)? If you get better results with that message but your actual data would be very repetitive (i.e. 00 00 00 FF FF FF), you might want to explore ways of evening out the 1:0 ratio.
I had a strange, yet interesting idea pop into my head this afternoon. Say the data you’re sending has a lot of redundacy (i.e. you are sending the status of 16 switches by sending 16 ‘0’ or ‘1’ bytes). You could employ a simply Exclusive OR routine where you XOR your data against a small array of bytes (i.e. AA 55 AA 55). That way even if your data is all 0’s or 1’s the transmitted data stream will have a better 1 bit to 0 bit distribution.
Just FYI, this general concept is called "disparity", and is used in high-speed serial buses such as Fibre Channel and PCI-Express.
One nifty thing you could do in SW is to encode all your data the way PCIe does (for example), and you will be guaranteed to have “neutral disparity” at all times. It also helps the receiving end see when there has been some bit errors, because the disparity may go bad.