Using an Operator Interface with the 2004 EDU RC wirelessly

[Guilherme]

...

The 2003 Edu RC receives data from 2003 Operator Interface. Then the 2003 Edu RC, witch is serial connected to the new Edu throught one cable (with the three wires like you said), sends the data to the new Edu RC.

Now... Is this correct? I guess so, 'cos it´s exactlly what we did.

The main question is: why can´t we control the servos attached in the pwm outputs located in the new Edu RC ? When we move the joystick we get no light blinking in the Operator Interface...

Thanks for your help, we´ll work harder in the assembly to try to figure it out our mistakes. Just let me know if you found any difficulties like ours, so we can share solutions.

[Andy Brockway]

Joe,

I am still a little confused on your set-up. What are you using for the modem on the 2003 EduRC? For your test, plug the servo into pwm08 and test with py_4, this is a direct link.

The setup that we are using is as follows:

2003 OI with its Radio Modem, Team Number set (ours is 716) per IFI instructions.

2003 EduRC with its interal modem (this is the black box with two sets of multiple pins and plugs into the bottom of the motherboard) and motherboard, Team number set to 716, switch set to 'program'. Do not use the full size RC radio modem. I think you are using the internal modem because you said you had no problem programming.

2004 EduRC

Cable between the 9 pin connectors of the EduRC's. Note- must be per this thread, note crossover between pins 2 and 3. Do not use a standard serial cable!

All pwm cables attached to 2004 EduRC.

Good Luck!

Andy Brockway
Team 716, The Who'sCTEKS

[Guilherme]

I got it! It´s working know.

We have no AC adapter to our OI, so the used voltage was somehow making the communication between the Internal Radio and the RS-422 Data Modem fail.

I made an Y cable to turn on both EduRC at the same time.

I made some modifications to the code, just to test. But the code available to download works perfectly!

Thanks all for your help! You´re great!

[Neal Probert]

Could we not just plug in the 2003 radio modem directly into the 2004 EDU/Full-Size RC?

Of course, we'd need to know the 2003 communications protocol to write the receiving code in C. Is this documented anywhere? Better yet, is anybody working on this?

This would be a good engineering challenge for the students.

[Dave Flowerday]

Originally Posted by Neal Probert

Could we not just plug in the 2003 radio modem directly into the 2004 EDU/Full-Size RC?

The reason we chose not to solve the problem this way is that it would be significantly more complicated for other teams to duplicate. The radio modems use RS422, so a converter would be necessary to get either an RS232 or TTL signal to hook up to the 2004 EduRC. Additionally, the radio modem requires an input that toggles it between command & data modes, which would have to be hooked up to a digital output on the Edu. Finally, the OTA (over-the-air) protocol is only partially documented for RC->OI communication and entirely undocumented for RC->OI. Also, using the old Edu provides an easy way to set the team number =) (otherwise it would probably have to just be a constant in the software).

[Dave Scheck]

Originally Posted by Neal Probert

Could we not just plug in the 2003 radio modem directly into the 2004 EDU/Full-Size RC?

We won't know until Saturday about the full-size controller, but as for the EDU...

The reasons that you can't plug the 2003 modem into a 2004 EDU are

1. It doesn't have a modem port.
You could create an external box that converted the serial signal of the modem to the inputs on the EDU. This would require a relatively simple microprocessor circuit.

2. You can't plug it into the serial port because the voltage levels are incompatible.
You could create an external box to shift the level of the modem signal, then plug into the serial port, and write some interface code to process the signal.

While both workarounds are good challenges, Dave's solution was designed to be a quick, low cost for teams that have a 2003 EDU, but do not have the resources to design the necessary interface circuitry.

I would imagine that at this stage in the game that most teams would be more interested in exploring how to write functioning C code than creating interface modules.

EDIT: Dave beat me to the punch in replying, sorry for the duplication

[Guilherme]

Don´t forget that the 2003 EDU has an internal modem, so it´s not necessary to use the any other radio.

Just build one cable, inverting ports 2 and 3 as said in this topic, and it´s all set! Just download the code, turn on the Operator Interface with the radio, and the 2003 EDU will trasmit data to the 2004 EDU. Simple serial communication, that´s all.

[Astronouth7303]

Why not connect the PWM outs from the '03 EDU to the '04 EDU PWM ins? Basically do the same thing you already are, just remove the programming hassle. The only thing I don't know is what wires to connect (Ins are 3, outs are 4). The volatages should be safe (The hobby recievers only use up to 6v, the IFI EDU motors are expecting 5.5v to 8.6v).

[kmcclary]

Originally Posted by Astronouth7303

Why not connect the PWM outs from the '03 EDU to the '04 EDU PWM ins? Basically do the same thing you already are, just remove the programming hassle. The only thing I don't know is what wires to connect (Ins are 3, outs are 4). The volatages should be safe (The hobby recievers only use up to 6v, the IFI EDU motors are expecting 5.5v to 8.6v).

According to IFI, connecting PWM OUTs to PWM INs may cause unreliable operation, and as of now they're not guaranteeing it.

I talked to IFI tech support about this last fall. The stated reason this may be unreliable is that the CPUs implement PWM OUT with separate hardware, and PWM IN by a scanning technique. IOW, the PWM outputs don't all come out at the same time, and the PWM inputs are checked one at a time.

AFAICD, the real problem is that PWM IN is NOT an interrupt based technique. The CPU has to wait for data input, and if asked to wait too long simply assumes the line is unconnected and ignores it.

According to IFI, the asynchronous nature of this CAN make things unreliable. It WOULD be OK however, IF your order of checking things MATCHES the order in which it is SENT. Otherwise, in certain input/output pairings, you COULD end up with either "old data", or consistently missed data on specific lines due to timeouts from asking it to wait too long and the '04 CPU assumes the line is unconnected.

There's a couple of ways this can become an intermittent problem:

1) The PWM IN on the '04 EDU scans the inputs in order (R/C radio decoders send out their pulses one at a time, in order), and the '03 PWM OUT does NOT send them out in order, causing missed data in SOME pairing cases.

2) We may hit INTERMITTENT timeouts in some data cases. Bear in mind that the data is encoded by pulse WIDTH (PWM = "Pulse WIDTH Modulation"). IOW, for example in a wiring that makes a marginal timeout situation on channel 6, if channels 1-5 ALL have long data (2ms end of the 1-2ms scale), the cpu may be waiting too long for input of data on channel 6, and timeout OCCASIONALLY. I don't know if this IS the case here, but it is a known potential problem with CPU scanned techniques of R/C systems, that would need to be verified by IFI.

Now IFI said that the solution was that THEY would need to tell us how to match the firing order of the PWM OUTS with the scanning order of the PWM IN. However, they refused to state what that WAS at that time, since they'd have to VERIFY it, and they were too busy right then trying to get ready for Kickoff. They DID promise me that "when they had time" they'd review the situation and put out an app note outlining the EXACT pairings to GUARANTEE reliable operation. <Checks IFI site> I see they still don't have that in their doc, whitepaper, nor FAQ areas yet, so either they haven't Gotten a Round Tuit yet, or it simply never worked for THEM.

If IFI isn't going to document this, and you DO wish to try this technique, what we'd need to do is to figure out if such a matching is possible, or if the '03 CPU changes the PWM OUT firing order with time because of multiple pieces of asynchronous hardware driving the PWM OUTs, introducing the POSSIBILITY that things would run fine for a WHILE, yet may suddenly flake out on you LATER. (I hate those kinds of "bugs"..)

A test for you: Has anyone 'scoped the '03 PWM OUTs with a multitrace oscilloscope yet, to get a sense of the order in which they fire? If so, please comment on that.
If you decide to try this test, put the EDU on a power supply, reboot it a few times to see if the order changes, and also leave it running for a few hours (or days) to see if the order changes over time (both tests help detect two or more asynchronous pieces of hardware sending data out on different ranges of PWM OUT lines).

*IF* a consistent firing order can be determined, simply match it. I'd assume the '04 CPU most likely scans the PWM inputs in order. That's the simplest case.

If the firing order is NOT consistent (changes with time), the ABSOLUTE worst case scenario I can think of is it will take a piece of hardware to capture all PWMs regardless of order sent, and either "regenerate" them in an order that the '04 CPU is happy with, or simply sends the data in via the serial port to the '04 EDU. (IOW, another PIC in between them...) I hope it won't come down to that, though...

But, is this even worth the time? Short of reverse engineering the interface and firmware (IFI won't release schematics nor internal code), if IFI won't even guarantee consistent operation, I'm not sure this is a smart way to interface them. You could have a robot that goes out of control on occasion.

Didn't someone get a '03 EDU / '04 EDU combination running RELIABLY last fall with a serial technique? I thought someone tied the two serial ports together and ran a small program in the '03 that shoved the data out the serial port to the '04 EDU serial port, but I never saw the code posted for it. If so, let's stop wasting time with this whole PWM OUT/IN interface technique.

Can someone simply please point us to the wiring AND the code required on both CPUs to go serial?

Thanks!

- Keith

[seanwitte]

Originally Posted by kmcclary

According to IFI, connecting PWM OUTs to PWM INs may cause unreliable operation, and as of now they're not guaranteeing it.

I talked to IFI tech support about this last fall. The stated reason this may be unreliable is that the CPUs implement PWM OUT with separate hardware, and PWM IN by a scanning technique. IOW, the PWM outputs don't all come out at the same time, and the PWM inputs are checked one at a time.

AFAICD, the real problem is that PWM IN is NOT an interrupt based technique. The CPU has to wait for data input, and if asked to wait too long simply assumes the line is unconnected and ignores it.

According to IFI, the asynchronous nature of this CAN make things unreliable. It WOULD be OK however, IF your order of checking things MATCHES the order in which it is SENT. Otherwise, in certain input/output pairings, you COULD end up with either "old data", or consistently missed data on specific lines due to timeouts from asking it to wait too long and the '04 CPU assumes the line is unconnected.

There's a couple of ways this can become an intermittent problem:

1) The PWM IN on the '04 EDU scans the inputs in order (R/C radio decoders send out their pulses one at a time, in order), and the '03 PWM OUT does NOT send them out in order, causing missed data in SOME pairing cases.

2) We may hit INTERMITTENT timeouts in some data cases. Bear in mind that the data is encoded by pulse WIDTH (PWM = "Pulse WIDTH Modulation"). IOW, for example in a wiring that makes a marginal timeout situation on channel 6, if channels 1-5 ALL have long data (2ms end of the 1-2ms scale), the cpu may be waiting too long for input of data on channel 6, and timeout OCCASIONALLY. I don't know if this IS the case here, but it is a known potential problem with CPU scanned techniques of R/C systems, that would need to be verified by IFI.

Now IFI said that the solution was that THEY would need to tell us how to match the firing order of the PWM OUTS with the scanning order of the PWM IN. However, they refused to state what that WAS at that time, since they'd have to VERIFY it, and they were too busy right then trying to get ready for Kickoff. They DID promise me that "when they had time" they'd review the situation and put out an app note outlining the EXACT pairings to GUARANTEE reliable operation. <Checks IFI site> I see they still don't have that in their doc, whitepaper, nor FAQ areas yet, so either they haven't Gotten a Round Tuit yet, or it simply never worked for THEM.

If IFI isn't going to document this, and you DO wish to try this technique, what we'd need to do is to figure out if such a matching is possible, or if the '03 CPU changes the PWM OUT firing order with time because of multiple pieces of asynchronous hardware driving the PWM OUTs, introducing the POSSIBILITY that things would run fine for a WHILE, yet may suddenly flake out on you LATER. (I hate those kinds of "bugs"..)

A test for you: Has anyone 'scoped the '03 PWM OUTs with a multitrace oscilloscope yet, to get a sense of the order in which they fire? If so, please comment on that.
If you decide to try this test, put the EDU on a power supply, reboot it a few times to see if the order changes, and also leave it running for a few hours (or days) to see if the order changes over time (both tests help detect two or more asynchronous pieces of hardware sending data out on different ranges of PWM OUT lines).

*IF* a consistent firing order can be determined, simply match it. I'd assume the '04 CPU most likely scans the PWM inputs in order. That's the simplest case.

If the firing order is NOT consistent (changes with time), the ABSOLUTE worst case scenario I can think of is it will take a piece of hardware to capture all PWMs regardless of order sent, and either "regenerate" them in an order that the '04 CPU is happy with, or simply sends the data in via the serial port to the '04 EDU. (IOW, another PIC in between them...) I hope it won't come down to that, though...

But, is this even worth the time? Short of reverse engineering the interface and firmware (IFI won't release schematics nor internal code), if IFI won't even guarantee consistent operation, I'm not sure this is a smart way to interface them. You could have a robot that goes out of control on occasion.

Didn't someone get a '03 EDU / '04 EDU combination running RELIABLY last fall with a serial technique? I thought someone tied the two serial ports together and ran a small program in the '03 that shoved the data out the serial port to the '04 EDU serial port, but I never saw the code posted for it. If so, let's stop wasting time with this whole PWM OUT/IN interface technique.

Can someone simply please point us to the wiring AND the code required on both CPUs to go serial?

Thanks!

- Keith

Dave Flowerday published the code and interface in the first post of this thread.

[kmcclary]

Originally Posted by seanwitte

Dave Flowerday published the code and interface in the first post of this thread.

Ah, thanks Sean! I didn't spot the code link when I read it last fall. (Duh... 4 months back, but same thread no less.) I'll need to try it.

Now *I* am confused... If Dave's serial method is working, why oh why are people still attempting PWM interfacing??? That's messy, more wiring, special connectors, prone to noise, AND may have timing problems.

As long as the data rate is decent (and the CPU overhead to service it is low), serial is a much more reliable method, AND less wiring is required.

Is there some drawback to Dave's way that I'm not seeing that's prompted more experimentation?

- Keith

[Astronouth7303]

Originally Posted by kmcclary

Ah, thanks Sean! I didn't spot the code link when I read it last fall. (Duh... 4 months back, but same thread no less.) I'll need to try it.

Now *I* am confused... If Dave's serial method is working, why oh why are people still attempting PWM interfacing??? That's messy, more wiring, special connectors, prone to noise, AND may have timing problems.

As long as the data rate is decent (and the CPU overhead to service it is low), serial is a much more reliable method, AND less wiring is required.

Is there some drawback to Dave's way that I'm not seeing that's prompted more experimentation?

- Keith

Simple: Dave's method requires special coding (as he says: there is easy way to read what's coming in from the port), not to say we can't get used to it. If the PWMs can be connected correctly, we can bypass that.

Is the fourth wire (orange) related to timing? or is it another power source?

[kmcclary]

Originally Posted by Jamie (Astronouth7303)

Is the fourth wire (orange) related to timing? or is it another power source?

It's another a battery power lead.

Black = Ground
Red = +Battery (not required for Victors)
Yellow = PWM Control (1-2 ms positive going PWM signal)
Orange = +Battery

See page 8 of the the "2004 EDU Robot Controller Reference Guide" for a pictorial of the pinout.

I simply assume the orange lead is most likely a higher current capacity "Raw Motor Power" lead for the servo (vs a low current "Logic Power" wire or PCB trace that may or may not be regulated), but I haven't broken any seals nor set up any voltage and current inline tests yet to confirm that.

- Keith

[Astronouth7303]

Thank you!

[Dave Flowerday]

Originally Posted by Astronouth7303

Simple: Dave's method requires special coding (as he says: there is easy way to read what's coming in from the port), not to say we can't get used to it. If the PWMs can be connected correctly, we can bypass that.

Well, now that we know what the real code looks like, it should be easy to redo my code so that it's transparent to the rest of your code. At the time though I didn't know what the real code was going to look like. Unfortunately, I don't have time to do this right now, but maybe someone else could. Basically, I'd just override the Getdata() function that goes and grabs the data from the '03 EDU and returns it in the same struct as the real 04 controller uses. It shouldn't be hard to do this so that the same code will work on either the EDU or the real controller.

Also, the advantage of using this serial method is that you can get the OI digital switches, enabled/disabled bit, etc. as well. If you just use the PWMs, you'd either have to settle for no buttons from the OI or you'd have to make software changes to send the button values over a PWM.