I think you're right, this could be a couple of issues and may well involve the signal logic and polarities.
In phoenix it appears that ch5 and ch6 (gyro and collective in my sim model mapping) are the only glitchy channels, and they seem to glitch simultaneously.
After calibrating phoenix to the VD5M I find the A9 trainer port (cabled) outputs are offset about +12.5% of full scale -- so at minimum stick I get 12.5% input, at mid-stick I get 62.5% input, and at high stick it clips at 100%. I'm thinking this may have something to do with edge triggered logic instead of level triggered logic; reading the back side of the pulses instead of the front for example. Maybe I can take it to work tomorrow and run it into an oscilloscope over lunch.
Separating the DX6i and VD5M really didn't help the mSR. The annoying thing there is that the silly mSR doesn't cut the motor when it knows it lost the link - it shuts off the blue LED and holds last state for all channels. It ends up beating itself against the baseboards until the eventual stall current forces a reboot and it then relinks. It almost seems like the initial link loss could be the result of some mSR brownout strategy, and perhaps the inverted edge thing again. Fortunately it looks like the mCPX implements throttle cut on link loss but I'm still not ready to try with this setup.
[edit: regardless, I think it will probably not be all that difficult for me to get to the bottom of it, and it already seems more sensible than plugging an entire receiver into SimStick]
Originally Posted by SimonChambers
Hmm. I've looked at this all afternoon and I can't replicate the problems with glitching you have - even with the same revision firmware that your receiver has.
One thing I would try is to move the receiver away from the Spektrum transmitter aerial. If it's too close, it could be being saturated on some channels as the US DSM2 sets transmit at a higher output than European models (and higher output level than what the Hitec transmits at). The receiver red LED will extinguish when it looses lock onto the transmitter. If the receiver becomes saturated, this could be what is happening.
Your revision firmware for PPM has a 22ms frame rate. However if several channels are fully deflected, the blank period (usually ~4.6ms) gets a bit short (~3.6ms), so that could confuse the transmitter/usb dongle.
I have tested the latest firmware with the PPM line connected into the back of a Futaba 8J and that works fine with no glitching. Also attached is the scope shot timings of CH1 of the PPM output of both the Aurora and Receiver. The Aurora was persuaded to output PPM out of its module connector into the Spectra module, by starting the radio up with no module plugged in (so it output PPM), then plugging the module in when its on. Not recommended to be done, but works!
Note that the two signals aren't lined up as the scope is set to trigger on CH1, but CH2 has a different PPM cycle length. CH1 (Aurora) = 23.6ms cycle, CH2 (Receiver) = 22.5ms. Hence it took several attempts to single shot both waveforms to have them close on the screen. Anyway as can be seen, both measure as the same length.
In regards to your Phoenix dongle, it could be getting confused with the PPM output levels. On Hitec, the line is low and goes high for a servo pulse. For Futaba, the line is high and goes low for a servo pulse. The Receiver outputs Futaba style. However to confuse things, I believe Hitec centre pulse is 1.5ms, while Futaba is 1.52ms. The Receiver outputs exactly what the transmitter is sending, hence 1.5ms centre. So I'm wondering if Phoenix simulator is thinking a Futaba transmitter is connected (from the inverted pulses) and so assumes that it should be 1.52ms centre?
As I can't replicate it, I can't be certain, just give possible theories.