RX / TX duo

[skimask]

I was doing some reading awhile back on these various modules using On/Off keying, FSK/ASK, whatever. I can see the modules working fine when only sending small data packets that only end up lasting a few milliseconds (with a good preamble of course). But, from what I've read, it seems that the data slicer will lose it's mind after that especially if the data has a lot of repeating 0's or 1's.
Correct or wrong?
JDG

[Bruce]

Long periods of 0's will cause problems.

Short bursts of information like preamble,synch,address,data,checksum etc
work just fine. The payload is delivered just after everything is stable and in
synch. Even a few bytes of data with large numbers of 0's works, but you
wouldn't want to stuff 50 words in there made up of all 0's.

If you're transmitting long streams of serial data that can vary from all 0's
to all 1's, then you might want to look into using manchester.

Here's one example of how a simple remote control encoder works.
http://www.linxtechnologies.com/docu...datastruct.pdf

[mbw123]

Bruce,
I didn't read your first post carefully enough. In your receiver code you had the SERIN line say:

SERIN2 D_IN,BAUD,[WAIT(Synch),ADD_IN1,DAT_IN1,ADD_IN2...]

What does the WAIT(Synch) line do?

I appreciate your answering, as this is probably a stupid question.

Thanks!!

-Mike

[Bruce]

It WAITs for the Synch byte. Look in your PBP manual under SERIN2 for the
WAIT modifier. This forces the SERIN2 line to wait until this specific byte
arrives before receiving the rest of the serial packet.

[mbw123]

Sorry about the late post, and thanks for the help guys! Now I am thinking about the possibility of using the PIC16F628A instead of the 16f84. Will I be able to use the same code and schematics (I think that the PIC16F628A has an internal oscillator; will that mean I can eliminate the external oscillator?)? Thanks for the help!!

-Mike

[mister_e]

you can use the same schematic and probably the same code. But look at the the 16F628 Specs... it have an internal USART. More reliable than a software solution and produce a tighter code. HSERIN, HSEROUT that's it.

About skipping the external OSC... it could work good or not. Usually for serial comm i prefer to use a crystal for a better stability upon the temperature variation. The internal OSC is still a RC circuit... But try it before at slow baudrate and it could work great.