Connect Radio Control transmiter (Futaba/Hitec using Trainer cable) to BS2

migudono · 2013-09-05 20:07

Hi masters ...
My problem: I'm trying tro connect a RC Radio Control (using Trainer cable Futaba or Hitec) to BS2.

Using PULSIN command looks like capture some channels others looks like fixed or erratic

Any Idea to resolve this problem? (thaks for your help)

The code >>>>>>>>>>>>>>>>>>

' {$STAMP BS2e}
' {$PBASIC 2.5}
'
Ch1 PIN 8 ' TRAINER CABLE CONNECTED ALMOST DIRECTLY TO THIS PIN (RESISTENCE 2OO OHM)

cuenta VAR Byte
drive VAR Word(8) ' ( I HOPE READ 8 CHANNELS FROM THE RADIO CABLE)

begin:

DO
FOR cuenta = 0 TO 7
PULSIN Ch1 , 1 , drive(cuenta)
NEXT

FOR cuenta = 0 TO 7
DEBUG DEC drive(cuenta) , TAB
NEXT
DEBUG CR

PAUSE 100
LOOP

Duane Degn · 2013-09-05 22:27

I really doubt the BS2 is fast enough to do this. Unlike a normal servo signal, the eight channels are coming one right after another. Isn't the timing more compressed than a normal servo line?

I think the time between pulses is too short to catch them all.

I have an old program to do something like this on a Propeller. Looking at the notes inside the program, it looks like the timing is different than the normal servo pulse. My program suggests instead of pulses being between 1000us and 2000us, they're between 600us and 1600us. Does that sound right? I don't remember how much time there is between the pulses. I'm pretty sure it's much less than 20ms.

So one guess is the BS2 isn't fast enough to catch the beginning of the next pulse in the series but I'm not sure about this. One problem I do see with your program is there isn't a way for the program to tell which channel is which. I suppose if the BS2 were turned on before the transmitter, then it might be able to start out synchronized with the pulses but I suspect your debug statement will throw the program out of sync rather quickly.

I'm not sure how to remedy the problem if your program is loosing sync.

I'm inclined to think you're asking the BS2 to do more than it's capable of (though I'm not sure about this).

BTW, The Propeller is a great match for all sorts of RC and servo projects. The Prop can easily capture the input pulses from a bunch of different inputs from a RC receiver and the Propeller can drive up to 32 servos without additional components. The Propeller wouldn't have any trouble capturing the input from a trainer signal (I've done this myself).

Chris Savage · 2013-09-06 14:55

The attached code reads two R/C channels and mixes the signals to allow you to control a BOE-Bot with a R/C system. Notice the RCTIME lines are separate. Perhaps trying this will give you some insight.

Duane Degn · 2013-09-06 15:18

Chris,

I'm not sure if you're aware of how trainer cables work with RC gear. The trainer cable transmits each of the TX's channels as pulses one after another. So rather than being able to use a separate pin to receive the various channels, the order the pulses are sent designate which channel is which.

To capture a trainer signal, I think one would need to monitor the line to make sure it has been low for a set amount of time (I don't recall how long the line is idle, I'm betting a couple milliseconds). Once this idle zone has been detected, then the first high pulse can be assumed to be for the first channel. The subsequent channels could also be captured. I'm starting to think this would be possible with a BS2.

I think the code in post #1 should be pretty close to what would work. I think there needs to be a way of measuring a low pulse and comparing the low pulse to some set value before the first FOR/NEXT loop executes.

Duane Degn · 2013-09-06 15:31

I haven't tried this on a BS2 but it appears to compile.

' {$STAMP BS2e}
' {$PBASIC 2.5}
'
Ch1 PIN 8 ' TRAINER CABLE CONNECTED ALMOST DIRECTLY TO THIS PIN (RESISTENCE 2OO OHM)


cuenta VAR Byte
drive VAR Word(8) ' ( I HOPE READ 8 CHANNELS FROM THE RADIO CABLE)
MINIMUM_LOW CON 1000 ' 2 ms ? I'm not sure about this
lowPulseIn VAR Word


begin:


  DO
tryAgain:
    GOSUB checkLow
    IF lowPulseIn < MINIMUM_LOW THEN GOTO tryAgain


    FOR cuenta = 0 TO 7
      PULSIN Ch1 , 1 , drive(cuenta)
    NEXT


    FOR cuenta = 0 TO 7
      DEBUG DEC drive(cuenta) , TAB
    NEXT
    DEBUG CR


    PAUSE 100
  LOOP


checkLow:
  PULSIN Ch1, 0, lowPulseIn
  return

It's pretty much the same as the original code but with a pulsin checking for a long low time. I don't know if I have the constant "MINIMUM_LOW" set to a correct value. I'm also not sure of the "IF THEN GOTO" syntax.

Is a pulsein of 1000 2ms with a BS2e? I assumed it was so keep that in mind.

migudono · 2013-09-06 16:01

Thaks for your advice

I must comment about the spead of BS2 to read the signal....When I change the code from

PULSIN Ch1 , 1 , drive(cuenta) to PULSIN Ch1 , 0 , drive(cuenta) ...the value readed is the same for all channel ...I can supose the readed value is separation between channels ...but it's only a supposition
another strange thing ....the code look like don't need sincronization....but read some channel in consistent way

Well, thaks for your help

migudono · 2013-09-06 16:15

Thaks Chris.
In fact, the code attached to your post was the base to begin my own code, but your code have 2 input pin, one for each channel,
The trainner cable I thing he needs only one pin , the signal have all channels

Thank for your help

Duane Degn · 2013-09-06 16:15

migudono wrote: »

When I change the code from

PULSIN Ch1 , 1 , drive(cuenta) to PULSIN Ch1 , 0 , drive(cuenta) ...the value readed is the same for all channel ...I can supose the readed value is separation between channels ..

I think you're probably right about the channel separations all being the same. What if you tried increasing the number of channels read to 9 or 10? I'd be interested to see if one of the separations is longer than the others. This would be a temporary change just to learn more about the signal.

Duane Degn · 2013-09-07 10:15

Thinking about this a bit more, I see a problem with the code in post #5. One a long low pulse has been detected, the overhead of setting up the FOR/NEXT loop and will likely cause the first high pulse detected in the loop to be measured shorter than it actually is.

Does the "PULSIN pin, 1, variable" statement wait for a low to high transition? I bet it does. In which case the first high pulse will be entirely missed by the code in post #5.

I still think there's a way to do this with a BS2 but I don't think the code I posted will work.

Chris Savage · 2013-09-09 08:13

Duane Degn wrote: »

Chris, I'm not sure if you're aware of how trainer cables work with RC gear. The trainer cable transmits each of the TX's channels as pulses one after another. So rather than being able to use a separate pin to receive the various channels, the order the pulses are sent designate which channel is which.

You're right, I assumed it was coming from a receiver where you could pick each channel.

migudono · 2013-09-09 11:27

thanks you all for your contribution to resolve my problem

Here it's attached an image with the signal "format", captured from and Homepage of RC hobbyst (ufff so bad english...LOL)

Mike Green · 2013-09-09 12:02

Based on the diagram in post #11, I really doubt if you can make this work with a BS2. It's too slow. I suspect you could do it with some external logic to decode the separate servo pulses. It's possible you could do it with one of the faster Stamps like the BS2px, but I'm not sure. You could certainly do it with a Propeller.

Duane Degn · 2013-09-09 12:26

I'm pretty sure the trainer signal is inverted from the graph is post #11.

The short separation pulses reported in post #6 are likely 400us (based on my own experience trying to read a trainer signal a few years ago).

If in the inverted signal, the blank time is high, then instead of reading six pulses, seven pulses could be read. The seven pulses could then be checked to see which is the blank time and the remaining pulses could be assigned their appropriate channels based on their relationship with the blank time.

You'll miss frames during the sort algorithm and you'll also lose frame during the debug statement. My (wild) guess is that maybe one in four frames could be captured this way. If you could do away with the debug, then maybe one in two frames could be captured (another wild guess).

migudono · 2013-09-09 19:59

Duane Degn wrote: »

You'll miss frames during the sort algorithm and you'll also lose frame during the debug statement. My (wild) guess is that maybe one in four frames could be captured this way. If you could do away with the debug, then maybe one in two frames could be captured (another wild guess).

Yes ...I considered this point, because the read stage is inside from the first For-Next loop without slow step, and the output (Debug) stage is inside the second for-next loop. Obviously ....when the problem will be resolved, the output stage will be replaced

Another thing ....I understood, from the signal diagram, that the duration of complete pulse (6 channels + sinc) is arround 20 mili Sec...and reading the manual I undertood that de minimal resolution from PIN command it's in micro sec, so... how is possible basic stamp don't be able or slow to capture correctly the wide pulses? (but maybe some channel really could be losted)

Mike Green · 2013-09-10 06:56

Duane's suggestion is correct (post # 13). You may be able to do seven PULSIN statements, one after another, then process the data to find the long sync pulse. It will probably take 40ms or more to do this processing, so you'll miss maybe two sets of pulses. See here for a discussion of BS2 execution times. Notice that a simple IF / THEN statement takes around 400us and a GOTO takes around 150us. This adds up quickly.

migudono · 2013-09-10 22:33

well maybe this is the end of the road...

but a last issue

this example obtained from the code editor, read correctly the number 1 channel ... without sinc loop, without make an explicit reffers to number one channel or without IF statement for wait a sinc value

when I did write the logic code to expand the reading to more channels, don't read more channels, only repeted the first

' {$STAMP BS2}
' {$PBASIC 2.5}

Pulse PIN 7 ' pulse input pin

#SELECT $STAMP
#CASE BS2, BS2E, BS2PE
Scale CON $200 ' 2.0 us per unit
#CASE BS2SX, BS2P, BS2PX
Scale CON $0CC ' 0.8 us per unit
#ENDSELECT

time VAR Word

Main:
PULSIN Pulse, 1, time ' measure positive pulse
IF (time > 0) THEN ' if not 0
DEBUG HOME,
DEC time, " units ", CLREOL ' display raw input
time = time */ Scale ' adjust for Stamp
DEBUG CR,
DEC time, " us " ' display microseconds
ELSE
DEBUG CLS, "Out of Range" ' else error message
ENDIF
PAUSE 200
GOTO Main
END

Duane Degn · 2013-09-12 14:06

Here's a trace of the output from the trainer port on my Spektrum DX7.

attachment.php?attachmentid=103869&d=1379019468

There are seven channels on the DX7 but there are eight pulses plus the sync pulse being sent on the trainer line. I think the last pulse is a calibration aid but I'm not sure. I do know the final pulse does get transmitted.

The original trace had a negative voltage. I inverted the oscilloscope connections since I figured the BS2 would prefer not to have negative voltage attached to the pins.

I attempted to capture the pulses with a BS2 but it didn't work All the pulse length were reported as zero. I don't think the BS2 was able to read the low voltage level. The pulses were barely over one volt.

I am curious if your radio also sends an extra pulse so instead of sampling seven pulses try eight to see if you can capture the long sync pulse.

migudono · 2013-09-12 21:16

Duane Degn wrote: »

I attempted to capture the pulses with a BS2 but it didn't work All the pulse length were reported as zero. I don't think the BS2 was able to read the low voltage level. The pulses were barely over one volt.

Thanks for your interest

I did read the cable voltage from a Futaba radio and Hitec and was around 5V or more. The information about the Futaba cable I have, it's only that was I attached some post days ago.

Furthermore, I can comment that, I have a USB cable for connect Radio to PC, for a simulator game. The USB connector have an IC labeled em78m612damj , and I will attach the datasheet link if someone can understand how is read (readed?) the cable signal. It powered from the PC.

http://pdf1.alldatasheet.com/datasheet-pdf/view/113351/EMC/EM78M612DAM.html

zlantz · 2014-01-04 14:06

Any luck on reading the Trainer signal? I too am working on a project that I would like to be able to just plug into the controller instead of the receiver's individual servo pins.

Looks like its going to be the receiver method until someone cracks the trainer cable.

Chris Savage · 2014-01-06 08:17

Duane Degn wrote: »

I attempted to capture the pulses with a BS2 but it didn't work All the pulse length were reported as zero. I don't think the BS2 was able to read the low voltage level. The pulses were barely over one volt.

I am curious if your radio also sends an extra pulse so instead of sampling seven pulses try eight to see if you can capture the long sync pulse.

You would need at least 1.4V to read a high on the BS2 input.

Connect Radio Control transmiter (Futaba/Hitec using Trainer cable) to BS2

Comments