Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Polarity Issue on Trainer Port via H-Beat Pin? #2992

Closed
MarenB opened this issue Oct 25, 2015 · 28 comments
Closed

Polarity Issue on Trainer Port via H-Beat Pin? #2992

MarenB opened this issue Oct 25, 2015 · 28 comments

Comments

@MarenB
Copy link

MarenB commented Oct 25, 2015

Hi,

there seems to be an issue with the PPM-in using th heratbeat pin in the module bay (X9E at least).

I was using the famous DIY-headtracker for a while on my old Taranis and it worked fine. On that radio I connected it to the trainer jack, which was internally routed to heartbeat pin (at that time unused by firmware). The tracker was then plugged into the module bay.

I built another one to plug into my X9E, but this radio does not detect the correct PPM signals. it seems to trigger on the death time between two pulses. Between two PPM frames, the signal is high. The PPM pulses are also high, just the breaks are low:
http://www.rcgroups.com/forums/showatt.php?attachmentid=4959223&stc=1

Is there a chance, that this signal shape causes a false auto-detect of PPM-in polarity?

@projectkk2glider
Copy link
Member

We had a change in the algorithm that decides if incoming PPM signal is valid or not. Perhaps this is causing your problem. Is logical 1 state between frames a valid signal or not? Looks funny to me.

@projectkk2glider
Copy link
Member

Did you by any change tried the same with the plain Taranis and OpenTX 2.1.x series where the same algorithm is used. If the problem is duplicated there, then at least we can rule out any hardware problem on X9E.

@kilrah
Copy link
Member

kilrah commented Oct 25, 2015

PPM can have either polarity and it shouldn't have any influence, the Taranis will happily take both.

@projectkk2glider
Copy link
Member

True, but he polarity of pulses is in his case positive and the idle state is also positive!

@MarenB
Copy link
Author

MarenB commented Oct 25, 2015

Yes kilrah - but in my point of view, this signal shape is not consistant. It's high between the frames and high for a pulse - that let's the Taranis struggle with it, perhaps.

My old Taranis is still on 2.0.17. I need to make an adaptor harness to try the new headtracker on that one, but I am pretty sure it will work. Both headtrackers use equal hardware and firmware, only the interface to the radio is different. I also checked with an oscilloscope, the signal is as intended (as on the picture I attached above) and equal on both units.
The X9E detects a signal, "TR1" i.e. in the mixer line becomes bold, I get confirmation by haptic and the mixer output jumps to something close above 0.0%. However, it doesn't change that when I move the HT, that is what makes me believe the radio might trigger on the gap between the pulses.

Btw. when was that change made? I can't recall it 100%, but I might remember, that it worked once evene wit the X9E (a couple of weeks ago).

Oh wait - I had a false wiring on my HT supply voltage, the arduino was provided with full battery power (replaced the Arduino afterwards, of course). Is there a chance to check wether the X9E got damaged by that?

@kilrah
Copy link
Member

kilrah commented Oct 25, 2015

Yes kilrah - but in my point of view, this signal shape is not consistant. It's high between the frames and high for a pulse

No, it's high idle and low for the pulses, perfectly normal.

@MarenB
Copy link
Author

MarenB commented Oct 25, 2015

No, it's high for the pulses as well! Low are the breaks between the pulses, that I confirmed by oscilloscope.

@kilrah
Copy link
Member

kilrah commented Oct 25, 2015

Then you're not referring to the correct thing when you mean "pulses". The "pulses" are the channel separators, which all have the same length, and are low in your capture. The variable channel durations obviously have the same level as the "idle" frame separation level.

http://api.ning.com/files/KWePTtollo4*Z6ijOwVqLAtitTvNj5O*1hu7jQtEG5-w0qpo3yoV5eE1CZQX4MqV1*oNoPVPNe66wWgeSaeJDQ__/PPMframeafterPPMencoder.jpg

@projectkk2glider
Copy link
Member

@kilrah again you are right, his signal is just inverted nothing else. So do we handle inverted PPM input in 2.1?

@projectkk2glider
Copy link
Member

@MarenB do you get voice announcement when the PPM signal is detected? Do you also get trainer lost announcement? (you nedd files "trainko.wav" and "trainok.wav" in SOUNDS/en/SYSTEM folder)

@MarenB
Copy link
Author

MarenB commented Oct 25, 2015

I get a haptic alarm in both cases. Will try using voice file.

Thanks guys, have a couple of items to test now. Hopefully I did not fry the input by overvoltage. Should be possible to confirm or deny this by testing S.Bus-Traininer-in.

Will return after I got more data.

@projectkk2glider
Copy link
Member

Hopefully I did not fry the input by overvoltage

Hardly, the input is protected by the reversed diode so it only triggers on low voltage.

@projectkk2glider
Copy link
Member

If you get many trainer OK and trainer KO messages, then the new PPM validity algorithm is causing this.

@LapinFou
Copy link
Contributor

Maybe it is not the same issue, but I played with a X8R plugged in the JR bay ("Master/SBUS Module" mode) in order to achieve a wireless trainer link. When I switched from one model to another on the master radio, I got many trainer OK and trainer KO messages. After a power off/on cycle on the master radio, it came back to normal.
The same behavior happened when I switched from one model to another on the student radio (both models use the same RX ID, since the X8R is inside the master JR radio bay).

@projectkk2glider projectkk2glider added this to the OpenTX 2.1.X milestone Oct 31, 2015
@MarenB
Copy link
Author

MarenB commented Nov 1, 2015

Hi there,

finally managed to test with "TrainerOK" and "TrainerKO" sounds and indeed, that's what I hear. But just once any time I plug/unplug the headtracker, not multiple times.
Next test will be with this HT via an adaptor cable to my old Taranis D.

@LapinFou
Copy link
Contributor

LapinFou commented Nov 2, 2015

When I described my problem, I thought it was correlated to me problem. In fact a new ticket #2999 has been opened. So, please don't take in account my comment below.

@MarenB
Copy link
Author

MarenB commented Nov 7, 2015

Gents,

thanks a lot for your comments on my issue. Finally, OpenTX 2.1.5 solved the problem :)

@MarenB MarenB closed this as completed Nov 7, 2015
@theailer
Copy link

theailer commented May 6, 2016

I'm on OpenTX 2.1.8 and I have this issue with the same headtracker.

@projectkk2glider
Copy link
Member

I am not sure why @MarenB closed this issue, we haven't done anything in code. Perhaps he can explain how he made it work.

@theailer what are your symptoms, do you get "TrainerOK" and "TrainerKO" sounds? Did it work in previous OpenTX versions? Does it work with any other hardware? Please provide as much information as possible.

@theailer
Copy link

theailer commented May 7, 2016

@projectkk2glider
Sorry for my brief comment.
It worked fine on my fly sky th9x with smartieparts board and er9x software. I'll check for the trainerKO and OK sounds this evening. I had it on mute when i tested yesterday and there were haptic feedback and I could also see on the channel display that the input halted.

@theailer
Copy link

theailer commented May 7, 2016

I could try and flash 2.0.x if that would help debugging.

@kilrah
Copy link
Member

kilrah commented May 8, 2016

The feature doesn't exist in 2.0, so no it wouldn't help...

@theailer
Copy link

theailer commented May 8, 2016

Ok, I get the trainer recovered and trainer lost messages intermittently when moving my headtracker. Not all the time though but pretty much. It still works perfectly on my er9x th9x radio but not on the taranis plus.

@kilrah
Copy link
Member

kilrah commented May 8, 2016

Can you confirm which port you're feeding the headtracker data to?

@theailer
Copy link

theailer commented May 8, 2016

When looking at the back of the radio its the left one. The other with the smaller bezel is for headphones?

@kilrah
Copy link
Member

kilrah commented May 8, 2016

Yes. But this issue is about using pin 2 in the module bay, not the trainer port...

@theailer
Copy link

theailer commented May 8, 2016

Aha, sorry.

@theailer
Copy link

theailer commented May 8, 2016

Sorry for messing it up.
Anyways, tried the headtracker again on my old flysky th9x and it does the same thing there. So it was the headtracker all along.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants