I am assuming the OP wanted a failsafe scheme so that he could revert to manual control if the PIC failed. Reversion to manual control should occur in three cases: 1: The PIC realizes that it is in trouble. 2: The PIC program fails (watchdog timeout?) 3: The user explicitly wants to take control. I would implement this by using an external N x 2 multiplexer to select the N channel signals from the receiver and those from the PIC. The select input on the mux would be driven by a circuit that would select the receiver input if: 1: A certain receiver channel's period is greater than 1.5 milliseconds. This is how the user explicitly takes control. or 2: An external watchdog timer that is refreshed by the PIC times out. This handles cases 1 and 2 above. This scheme does not rely on the sanity of the PIC in any way to ensure manual remote control. Bob Ammerman RAm Systems ----- Original Message ----- From: "Pete Stapley" To: Sent: Tuesday, April 29, 2003 12:11 PM Subject: Re: [PIC]: PIC/RC RECEIVER > To make sure I understand this correctly, you would use a pin on port > A let say for each servo input from the receiver. When the PIC control is > off you just write each of these servo inputs to the appropriate pin on > port B which then control the servos. When PIC control is on the PIC does > whatever processing it needs to do and you write these signals out on the > appropriate pin on port B out to the servos. Am I understanding this > correctly? From what I know about RC the receiver sends out a signal using > PWM to the servos to control them, so let's say you have an extra channel > that you are going to use to turn PIC control on and off. What would be the > best way to do this? Connect this extra channel to the PIC and make > decisions based on the PWM signal whether PIC control should be on or off? > Or would you design something (maybe there is already something out there > that does this) to convert this PWM signal to 0v or 5v which would be easy > to decide whether PIC control should be on or off? > > At 09:34 AM 4/29/2003, you wrote: > >I've been having the same ideas... > >Although, I haven't gotten around to it yet as I still need to build > >something I can control :-) > > > >It wouldn't be too hard if you have a spare channel to route to the PIC. > >Then you simply route all signals through the pic and it could relay then > >when PIC-control is off and override them when control is on. (This is what > >I'll be doing.) > >With a simple setup it could be as simple as reading port A, then writing to > >B in the OFF state, and doing it's own work in the ON state. A simple 4 MHz > >oscillator would give you 500000 transfers a second, more than enough to > >keep your control perfectly smooth. > > > >You will need some code to handle the on/off transitions... Especially if > >your receiver module donesn't have a on/off signal for one of the channels. > >This shouldn't ba any problem though. > > > >Sounds like a plan? > > > >Oh, and if anyone has a cheap but good glider I'd be very glad as building > >one seems like a lot of work to justify me playing with a PIC :-) > > > > KreAture > > > > > >----- Original Message ----- > >From: "stanton54" > >To: > >Sent: Tuesday, April 29, 2003 4:40 PM > >Subject: Re: [PIC]: PIC/RC RECEIVER > > > > > > > (tag fixed, missing colon) > > > > > > Controlling the servos is fairly easy. A single timer can control up > > > to 10 servos. Each servo gets 2 ms for a 1-2 ms pulse (1 ms = all the > > > way one direction, 1.5 ms = center, 2 ms = the other endpoint); the > > > whole thing repeats at 50 Hz = every 20 ms. > > > > > > As others have suggested relays will be the easiest way to switch > > > between PIC and manual control. You could use a servo to push a small > > > switch or button to trigger all of them. > > > > > > The alternative requires decoding the data from the receiver, which > > > could take a lot of work if you need to look at too many channels. > > > If you're brave enough to dig around inside your receiver you can > > > get the data from all of the channels through a single pin, which > > > simplifies things. You will still however have a problem if the PIC > > > crashes/gets confused/etc. > > > > > > Joe Smith wrote: > > > > > > > > I am looking to interface a PIC to some servos in a RC model. What I am > > > > looking to do is be able to have the PIC control some of the servos but > >I > > > > also want to be able to use the transmitter in case my code does not > >work > > > > exactly as I had intended. Are there any resources where someone has > >done > > > > this before or where I can get some ideas? > > > > > > > > Thanks > > > > > > > > _________________________________________________________________ > > > > The new MSN 8: smart spam protection and 2 months FREE* > > > > http://join.msn.com/?page=features/junkmail > > > > > > > > -- > > > > http://www.piclist.com hint: The list server can filter out subtopics > > > > (like ads or off topics) for you. See http://www.piclist.com/#topics > > > > > > -- > > > http://www.piclist.com hint: The PICList is archived three different > > > ways. See http://www.piclist.com/#archives for details. > > > > > > >-- > >http://www.piclist.com hint: The PICList is archived three different > >ways. See http://www.piclist.com/#archives for details. > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.