Seriously Slow Speed Asynchronous Serial Data Transmission

Just like the title says (and I wish you all could hear me say that since I got a mouthfull of braces about 6 months ago, and now I've got a bit of a lateral lisp with all this metal in my mouth, yep, 38 y/o, figure about 25 years behind the power curve here, only another 18 months to go with this stuff crammed in there...) :D

So, I was thinking over the weekend...
Me and the guy next door are building this 'ground moving, mechanical menace of a robot looking thing', controlled by a 4 channel ground R/C car transmitter/receiver. We want to add a bunch of stuff to it, but obviously, we're out of channels. We only need 2 proportional channels, so that leaves the other 2 free (which are on/off anyways).
And that's where I got to thinking...

I take the 4th channel switch, unwire it and tack it into a PIC output.
The PIC has a bank of switches wired into it, and depending on the position of those switches, it'll send out data out to that 4th channel wire, basically switching the line high and/or low as needed to send slow speed serial data.

At the other end, I have a PIC connected to channel 4 on the RX.
I use the PULSIN command to tell me if the channel is > or < 1.5ms, thereby differentiating high from low sent at the TX end, and I set an output pin according to the pulse width.
Now, since the RX's frame rate is only ~50hz, I can't send data very fast, figure maybe 25bps at the very most. That's all the first PIC does, is to set the output pin, doesn't do any decoding, no nothing.

So...I write code for a 2nd PIC tied to the first one to handle the 'expanded channel' outputs. I use DEFINE OSC 40 in the code, and use 244 as my SERIN2/SEROUT2 mode number...but, instead of running the PIC at 40Mhz, I run at 4Mhz (even though it's defined as 40Mhz), thereby my baud rate ends up being 24.3bps, a little under 2 1/2 characters per second. Plenty fast to turn lights on/off, move smaller actuators, etc. without having to worry about precision.

Solid theory? Decent theory? Not gonna happen no matter what I try?
Any thoughts...

Skimask... KISS it...

Just use the TX and TX pics at either end. Run full speed with a descent baud rate. Include periodic data bytes or "commands" in the data stream the indicate when the line should be High/Low. RX pic reads data, catches the command bytes and changes the line as needed.

Or just use one pic with the line in and then line out. Won't that work?

:D
SteveB

Quote:

---

Originally Posted by SteveB

Skimask... KISS it...
..........
Or just use one pic with the line in and then line out. Won't that work?
:D
SteveB

---

I suppose mainly because the RF-TX and RF-RX are already done with an R/C car radio, and it's done well...with the commericial stuff anyways.
I can't do it nearly that well, and certainly not at the price of a commericially available unit.

Unless I missed what you were trying to say :) Entirely possible...it is monday ya know...

Now that I reread what you wrote I see I may have misunderstood. Is the link between you two original pics was RF?

Line 4----PIC----RF-TXch4 -> RF-RXch4-----PIC----Line 4

If so, I'll just go back to lurking and we will all chock it up as Monday!!!

SteveB

Quote:

---

Originally Posted by SteveB

Now that I reread what you wrote I see I may have misunderstood. Is the link between you two original pics was RF?
Line 4----PIC----RF-TXch4 -> RF-RXch4-----PIC----Line 4
If so, I'll just go back to lurking and we will all chock it up as Monday!!!
SteveB

---

It's all good...

Ya, pretty much what you've got up there...

Many switches/knobs/dials -> PIC -> SSSASSDT -> RF-TX-Ch4-Sw........>>>>>>>>

>>>>>>>>........RF-RX-Ch4 output -> PIC -> Relays/MOSFETs/ETC -> Lights, solenoids, etc.

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.

Code:

---

_________|---|===|===|===|===|....|===|___________
  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

Quote:

---

Originally Posted by SteveB

- 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.

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.)