*Originally posted by gburlison *
**If you could convert the PWM outputs from the old controller to the correct voltage levels, then perhaps you would have something. **
There is some serious misinformation going around here…
I’ve personally scoped some of the signals out of the 2003 RC, AND I talked to IFI last year about interfacing other things to PWM outputs, so I have an idea of what the output driver looks like electrically.
The old (2003) RC is using 5V PWM signals. Though the driver chip is CAPABLE of higher voltages independent of the logic supply, they’ve tied the “load” power AND the “logic” power BOTH to +5V.
We’re not sure about interfacing the NEW (2004) RC to the EduBot CPU though, as they won’t guarantee ANYTHING about IT other than “It will not be compatible at ALL”…
According to IFI, the problem with a 2003 RC and 2004 EDUBot CPU combination/interface lies in the TIMING of the PWM pulses.
The EDUBOT CPU assumes that you’re connecting a standard R/C transmitter/receiver rig to it. That sends the pulses in a particular order, and the EDUBOT assumes that order when it is LOOKING for incoming pulses.
We’re just not sure of exactly WHEN the RC generates it’s PWM output signals RELATIVE TO EACH OTHER. In other words, PWM4 may NOT be generated after PWM3, and before PWM5 is sent out.
Tests at IFI have revealed that when you connect the 2003 RC to the new EDUBOT CPU, they CAN miss each other’s pulses, causing erratic operation.
They’re being coy about it, but I’m guessing that what is happening is a “beat frequency” problem between the RC’s output sequence, and the EDUBOTs scanning sequence… I’ll bet that a situation has arisen where at the time one channel of the RC is sending its PWM, the EDUBOT isn’t looking at that input AT THAT TIME. So, by the time it DOES sync up and gets a particular channel, either the Victor or Spike already has timed out and shut down, or the EDUBOT input routine has timed out, assumed that there’s no signal there, and starts sending a “127” or some such thing…
Either way, you’d get “glitchy” operation. Sometimes they catch each other and work right, and sometimes they’re “syncopated” and won’t see each other…
IFI says they WILL be coming out with an App Note shortly on their website specifying the EXACT order to connect channels between the two to help avoid this. But, THEY haven’t debugged any particular combination yet, so even THEY aren’t sure if it WILL EVER work right. Hence, the warning.
However, they HAVE said that the NEW (2004) RC will NOT be compatible at ALL with the Edubot CPU, but they refuse to say WHY.
So… If you want to get a JUMP on this, try THIS experiment: Scope out the 2003 RC’s outputs with a dual trace scope, and post here the ORDER in which it sends it’s PWM signals out. That’s the first step in tying the two devices together.
Next, determine if that order is CONSTANT. If for example we have two “banks” of PWMs generated by separate PICs in the old RC whose timing are asynchronous to each other, the order may change with time, and we’re toast.
The next step will be to INSURE there’s no voltage incompatibility due to ground currents. That can be done with simple resistor / zener combinations on the PWM cables, but we can talk about that later.
I’ll bet though, that IF the firing order is constant, and IF we connect the RC’s PWM outputs in FIRING order to PWM Input 1-8 (or 8-1) respectively, it’ll work as well as it ever will.
I don’t know if that’ll be PERFECT though, and may still be “glitchy”. It may still require a PIC (or other logic) in the middle, to buffer the PWM signals’ relative timing in some way to insure every pulse is recognized by the EduBot CPU, every time.
Now whether or not a complex interface design to sync them up is worth the effort just to save the cost of a $100 radio control rig, is an ENTIRELY different question.