Thanks a lot Dave, that was very useful. I ordered 5 modules for 8 dollars each to begin testing.
Thanks a lot Dave, that was very useful. I ordered 5 modules for 8 dollars each to begin testing.
The routines Dave posted are a good place to start, and he has a lot more interesting tutorials on his site. Definitely worth a visit.
But, you can definitely send/receive serial data without using encoder/decoder ICs. If you do, you'll want to packetize your data, and probably use a preamble, synch byte, redundant data, and maybe even a checksum.
I use these with serout2/serin2 all the time, and it works exceptionally well, but you do have to learn to deal with noise, and data errors.
You can also develope your own protocol using pulsin at the receiver, and simply taking the transmit pin high/low for specific periods to transmit.
It's pretty easy once you've had time to experiment with different methods. Which one works best normally depends on the application. The more critical the data, the more work it is to send/receive it reliably.
We carried stock of 315MHz, 418MHz and 434MHz TWS/RWS for several years. We had a hard time keeping the 434MHz versions in stock. The 315MHz and 418MHz versions sat there forever. That's the only reason we dropped them.
The NEC protocol sends each byte a second time, in bit-wise complement form, so it has built-in error detection and is very reliable. It's best with sort messages although X-10, Panasonic and others use it or very similar variants with up to 48 bits in each message. Hitachi uses a variant with >100 bit messages.
If you need lots of data, Crestron stuffs a lot into very short messages (10 bit periods with 5 possible states for each) using a combination of pulse width and space width encoding. It can also include forward error correction but it requires some sophisticated math skills (the kind that makes my head hurt) for that.
Bruce's site is full of good stuff, too.
Bookmarks