Seriously Slow Speed Asynchronous Serial Data Transmission

[skimask]

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

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

[SteveB]

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?


SteveB

[skimask]

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

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

[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

[skimask]

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.

[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