Can anyone tell me what kind of pulse timing this Rutaba T6EX may have?

[Triode]

I made a tutorial on how to build a servo signal interpreter that I designed and someone emailed me saying that he built it and is having trouble. He said hes using this transmitter. For the one I used, a 3 channel traxxas, the servo signals all came back to back, when one ended the next started, so you only had to time every other channel and the others were the gaps in between. But I know some start on even timing or all pulse simultaneously. This one has some description of how it reads signals but I can't get a definitive answer about the pulse timing from them. Does anyone know? I've also suggested he hook it up to an oscilloscope and check, but I don't know that he has access to one.

 

[Sceadwian]

What you have designed will not work in his situation. The Traxxis connect is what is called the 'baseband' signal. The Futaba transmitter does not have this feature Futaba tries to be as proprietary as it possible can so they only way to figure out how their transmitter functions is to study it using a logic analyzer. Futaba only makes equipment designed to work with their own hardware and finding specs is nearly impossible because it's how they maintain their marketing edge, that and they have the glut of the market by name alone.

 

[Triode]

I wish I could change the title from to "Futaba" since no one is going to know what "Rutaba" is.

Are you sure? It seems like their servo signals would have to be the same or similar, that's what I'm trying to read, not the radio signal. But I'm guessing you know what I mean since you helped in so many of the posts where I was figuring out how to do this.

If their servo signals are different does that mean that you couldn't plug in any other companies servos? That seems odd since it's pretty standard except for vex to use PWM with 1.5ms to 2.5ms pulses starting about 20ms apart.

 

[Sceadwian]

You're dealing with proprietary hardware Triode, there are no rules or standards for this stuff, just conventions on what's been used in the past and even then there's quiet a bit of variation from maker to maker. You can read an individual servo signal but if they're synchronous you'll have to read them all at the same time. The transmitter probably doesn't use anything even close to the old methods used for transmitting servo signals, it sends a fully digital signal. The individual servo pulses should be the same, but what you describe in your first post is not individual servo pulses but the baseband signal which contains a single frame of all the servo signals one after another, it's likely that this transmitter has no equivalent signal as that is only used in older analog system's not 2.4ghz digital ones. Unless you can find someone that has some basic tools for analyzing the signal it's a little hard to suggest anything.

I would assume that the servo signals are synchronous, just because there's no reason for them not to be.

 

[Triode]

I realize that while the ones I'm dealing with are timed so that one starts when the other ends others may be synchronous or started on equal timing, but I think I could make the system work for any of those. I originally assumed my system was either synchronous or just sent the signals on some regular start time, when it didn't work as expected i discovered that it was stacked. For any mode of operation there is a way it can work, if it's synchronous just have it check 2 to 4 ports every 100us and call the time on the ones that have shut off, and if it's even spaced I can still use the one pin plan and have it just check each pulse, counting the first after the long gap as ch1. But before I can adapt it I have to know what I'm looking at.

 

[Sceadwian]

100us?
That will give you only 10 different sense positions, that's EXTREMELY course, what are you doing with the signals once received?

 

[Triode]

I realize that it will result in only 10 positions, since the full signal only varies by a total of 1ms (1.5ms to 2.5ms) but I could probably see how high that could be pushed if I were to test this. It is of course limited by the speed of the PIC. However if it can handle 100us, it would be enough for this application, which is bidirectional motor control to drive an RC skid steer vehicle. so you could have 4 or 5 speeds in forward or reverse. Of course more resolution is far preferable to make it less twitchy. I would use the capture module, which can be very exact by setting it to interrupt when the signal goes high, recording the time and setting to interrupt on fall, then recording the time again. But there are only so many capture modules. I'm not sure if they can be set to watch multiple pins for an interrupt, and if they can I don't know how.

The person sent me some o-scope shots, and they seem to be syncronous as you predicted:
**broken link removed**
**broken link removed**
**broken link removed**

for some reason channel 4 is offset. But anyway, he only wants to get 2 channels. So the CCP thing may work since the 18F1320 has two CCP modules. Or I could try and push the frequency at which it checks a bit higher and use the port checking method. It's too bad the timing is all different, I'd like to make it so that it could read any PWM servo signal, and atleast 4 of them, but that would probably require it to detect what kind of timing it was getting and then configure itself for it.

 

[Sceadwian]

Triode, explaining what those channels are hooked up to might help, our guess could be wrong and if you don't say exactly what it's confusing, as those shots don't make 100% sense.

Yes, it's synchronously generated, that's given in the scope shots. The fact that a CH4 pulse only appears in 1 of the four triggered shots does not make sense though. If CH4 is a servo output it should appear in all four captures, the 'offset' you noticed since it's only in one frame is likely a synchronization different from the first three channels, meaning that fourth channel is driving something very different from a servo.

Even if you have to lose some resolution get some deeper captures that show more than one servo pulse on each channel, especially the number 4 channel. it's VERY difficult to analyze a protocol with a shallow capture buffer, that's only 10ms of data, I'd rather see 1 second and would like to see an explanation for why the CH4 pulse only exists in one of those captured frames. This is what logic analyzers are good for =)

 

[Triode]

Apparently the one with channel 4 is the only one where channel 4 is connected and the third screen shot is with the control for channel 1 and 3 pushed up. A logic analyzer would be nice but I don't think the guy I'm helping has one, and I don't.

I also noticed channel 4 is fuzzier than the others, I wonder what that's about.

 

[Sceadwian]

The rest of the digital circuit is probably causing the noise it's so low it's irrelevant, these are logic signals.

Capture more data, show more captures with all four channels, and again you've NOT stated what these channels are connected to! NEED MORE INFORMATION. An offset fourth channel might make sense if we knew what those channels were supposed to be used for! Perhaps it's a throttle, and the offset is because they want the control surface update to occur before the throttle corrections, there's a billion possible reasons and you're providing only vague glimpses and opinions on what's going on.

 

[Triode]

I'm not in possession of the system, so I can't capture more. But he says he only wants the first 2 channels so I think it's pretty clear cut. At 8Mhz with how few operations are involved in the program I think the 18F1320 has enough speed to capture the signal at speeds upward of 20 samples per millisecond even while generating the motor control output.

What more is there really to figure out anyway? The picture says this was taken at 62hz, which means the pulses are a little less than 20ms apart (which would be 50hz) and since that's the standard I would guess it's a pretty normal signal. I'm just going to try to make a program that times the widths regardless of relative start times by monitoring them.

 

[Sceadwian]

With synchronous starting and variable ending when the end pulses are close together you'll get gitter in your measured value depending on which interrupt triggers first, it'll delay the next one enough to skew the timing somewhat. This may or may not be a problem for your application.