Seriously Slow Speed Asynchronous Serial Data Transmission

[SteveB]

OK, A couple of thoughts:

- Is the first PIC, on the TX side, going to vary the pulse width of the serial data, to cause the variance for the RX pic to differentiate between the High/Low on channel 4?
- If so, wouldn't that affect the frequency of the serial data, and prevent the RX pic from getting the correct data?

- Why not go with a customized serial protocol? A little more work on the software side, but may be better for this app.

just an idea, but here is something off the top of my head.

_________|---|===|===|===|===|....|===|___________
   A       B   C0  C1  C2  C3       Cn

A = Specific minimum time for a low in order to differeniante packets.
    Slave watches and when that min time is achieved, 
    it gets ready for the start bit.
B = Start bit, always high, for a specific time.
C = Data bits, one for each line out.  
    C0 is always the status of your fourth channel.

Just some musings as I'm eating my lunch.

Steve

[skimask]

- Is the first PIC, on the TX side, going to vary the pulse width of the serial data, to cause the variance for the RX pic to differentiate between the High/Low on channel 4?

Nope, no varying the pulse width on the TX.
I figure it would have to be VERY SLOW serial data because the update rate of the TX/RX RF combo is around 50hz, so therefore, the serial data rate has to be AT LEAST 1/2 of that, if not less to keep the error rate down. The PIC at the RX end would be sampling the pulse width, changing the output bit according to the pulse width. I can't change the output bit any faster than the RF will send the new pulse width, hence the name of the thread.

And since that 50hz might not always be 100% constant and might shift around somewhat, that's why I figure I have to go with, like I said, at the very most 25hz. Something probably more like 12hz would probably work just fine. There would still be a lot of edge slewing, but it might still work.
Again, I don't know how accurate that 50hz update rate actually is. Won't know until I actually try it out on an actual R/C system.

[skimask]

Here's a quick synopsis on what I got going...not exact code or hardware, but the jist of it is here.

Transmitter side...
I hacked into the Channel 5 switch, ran the wires out to a standard DIP relay for now. I also set up the transmitter so that the Channel 5 switch would run the servo to the extremes depending on switch position.
TX PIC is a 18F2620 running at 1Mhz, with 4 switches connected to Port D0-3.
Code looks something like this:

DEFINE OSC 40 'OSC defined @ 40mhz, but running 1Mhz on the internal clock, 300 baud is actually 7.5baud, good enough for what I need.
'register setup...etc...etc...
'read the Port D pins......
'invert and copy D0-D3 up to D4-D7.
'SEROUT Port D value @ 300 baud to the pin running the relay contacts connected to the switch that used to be channel 5.
'wash, lather, rinse, repeat...

Receiver side...2 PIC's...
1st - PIC12F629 running at 4Mhz, doing a continuous loop of pulsin's...
If the pulsin is less than 1.5ms, the output pin goes low, if longer than 1.5, output pin goes high. Actually, I set the code up for 1.4ms and 1.6ms for a little bit of slop in the system to cover glitches. Basically the output follows the pulse width of the input. You might call it a one-bit PWM->Analog converter.

2nd - PIC18F2620 running in the same OSC configuration as the PIC on the TX side, except this time, the word received by the SERIN gets error checked D0-D3 = ~D4-D7. If the 2 nybbles check good, the value goes out to the LEDs on PortD0-D3. If they don't check good, the value either stays the same or the port is cleared depending on a DIP switch setting I put in there.

It's slow....So very slowwwwwwwwww... Less than one byte per second, but it works. And so far it's been bulletproof, and I can easily see it being expandable to X number of sub-channels.
I'm going to try and speed up the baud rate a bit, easily done by changing the internal clock speed on both PICs. I'd be willing to bet that the fastest I'll get is with 4Mhz internal for 30 baud and that'll probably be a bit glitchy.
(And yes, I know I said 4 channel earlier, I'm using a Futaba 8UAF at the moment for testing. I'm in North Dakota and it's winter. A lot more R/C cars around here than R/C planes, and there aren't many of those either.)