Sounds good, my vote for rssi value should be in dBm.

Many thanks for your effort.

Originally Posted by SimonChambers

Hi Bingo,

The RSSI output is PWM based. It is an averaged value of RSSI over the last complete received channel hop sequence. Invalid packets or corrupt will reduce the RSSI value.

I couldn't find any form of standard whatsoever, so I came up with the following formula:
PWM duty cycle = ([RSSI_dBm] + 128) * 2

The PWM is 8bit - so generated internally from 0 to 255.

IIRC, the RSSI dBm signal strength in the receiver is between -120dBm (minimum received signal) and -10dBm (receiver saturation). Above -10dBm the receiver becomes saturated and is unable to process packets (so signal loss). However the only way I can get these park flier receivers to saturate is by putting the receiver antenna right next to the transmitter antenna, in the same polarisation plane - not recommended to be done btw, as you could damage the receiver RF front end.

If all packets are lost for 2 complete channel hopping frames, RSSI will drop to zero - i.e. Failsafe/no signal mode. By default the receiver will stop outputting PPM on the loss of 2 complete channel hopping frames, unless if the failsafe is set, then the receiver PPM will output the failsafe positions. Each channel hopping frame = 21 channels. So 2 complete channel hopping frames = ~1 second.

Anyone who has a better RSSI algorithm, let me know and I can change it to it! One possible problem is that the dBm scale is logarithmic - so at low signal levels, the RSSI will vary by not a lot.

I've got some interesting stuff going on behind the scenes , unfortunately I am restricted due to commercial reasons from saying exactly what I am doing.

I really can't say more than that (I'm sticking my neck out by saying what I have here already), as I don't want to risk damaging all the work that has gone on. Rest assured, if everything is eventually successful, it should be good and hopefully people will be happy!

Cheers,

Si.

Si, can you confirm you received my paypal payment?
Thanks,
Jimmy

Originally Posted by Rescuejim

Si, can you confirm you received my paypal payment?
Thanks,
Jimmy

Hi Jimmy,

Yup payment received and posted today!

Cheers,
Si.

Thanks Si, I'm looking forward to not having to use my DM8 mod to fly my little foamies on my A9.

I use in smaller balsa kit builds, like the Dumas Waco YMF and other Trittle designs: they don't have "bulky" antennae!

Originally Posted by SimonChambers

I've got some interesting stuff going on behind the scenes , unfortunately I am restricted due to commercial reasons from saying exactly what I am doing.

I really can't say more than that (I'm sticking my neck out by saying what I have here already), as I don't want to risk damaging all the work that has gone on. Rest assured, if everything is eventually successful, it should be good and hopefully people will be happy!

Cheers,

Si.

Are you about to become a FrSky engineer who specilizes in Hitec clones? I know I know - you can't answer. I'll leave this here for posterity as 'my guess'...

Im still voting for a 9 chan hitec compatible rx!

+1

I spent an hour slapping this together and having some fun with preliminary tests. I was able to fly my Blade mSR and Phoenix Flight Sim models using an untethered A9.

Overall it was pretty cool but it was glitchy enough that I won't try it on my mCPX just yet. The mSR was losing the link periodically and Phoenix was glitching collective on my heli models; I could see the red LED flicker once in a while as well. Controller had to be recalibrated under Phoenix as the pulse lengths were quite far out from the direct wired PPM that my A9 is providing.

I should also mention that I was powering the receiver with an old ultra-micro (E-Flite 1S120/15C) pack and the PPM line from the board was hard wired to the TRS connector -- no level converters, buffers, pullups, or current limit resistors were used.

Thanks for the amusement Si, it's nice to have odd projects like this to tinker.

[update: NiMH receiver pack didn't cure the glitching]

My latest order just arrived.

Si, what are those pins for (the strip thingy)?

Thanks, again.

Originally Posted by Dirt-Torpedo

I spent an hour slapping this together and having some fun with preliminary tests. I was able to fly my Blade mSR and Phoenix Flight Sim models using an untethered A9.

Overall it was pretty cool but it was glitchy enough that I won't try it on my mCPX just yet. The mSR was losing the link periodically and Phoenix was glitching collective on my heli models; I could see the red LED flicker once in a while as well. Controller had to be recalibrated under Phoenix as the pulse lengths were quite far out from the direct wired PPM that my A9 is providing.

I should also mention that I was powering the receiver with an old ultra-micro (E-Flite 1S120/15C) pack and the PPM line from the board was hard wired to the TRS connector -- no level converters, buffers, pullups, or current limit resistors were used.

Thanks for the amusement Si, it's nice to have odd projects like this to tinker.

[update: NiMH receiver pack didn't cure the glitching]

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.

Cheers,
Si.

Originally Posted by JohnathanSwift

My latest order just arrived.

Si, what are those pins for (the strip thingy)?

Thanks, again.

Awesome. For some reason, your parcel took longer than some other's that went to the US and a couple of days longer than last time it got to you.

Those pins are a bunch of crimp connectors for the included servo connector housings if you want to make your own leads. Kinda redundant, as I supply the 5 micro connectors leads that are pre-made anyway. However as FrSky now included them with their receivers (well they did in the last batch of receivers I bought from HK), I sent them along with them still included. Maybe they might be useful for spares if one of the leads/connectors becomes damaged?

Cheers,
Si.

Thanks, Si-no doubt living on the Left Coast contributed to the delay.

I've now got 50 or so flights on the WACO, and performance has been flawless!

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.

Cheers,
Si.

Si,

Attached is some evidence for a runt pulse from the VD5M that doesn't show up in wired "pupil mode" PPM transmissions from the A9. The scope was triggering on falling edges, and the closed box with 3V amplitude could only occur with a glitch. It was very intermittent (just like the mSR & phoenix cyclic issue) and only seemed to occur when I was stick banging. Possible logic race on interrupt handling? Perhaps only occurring if RF frames are lost?

The other two attachments show clean frames with 506us pulses from the VD5M and 405us pulses from the A9. It seems like the "calibration mismatch" is likely a result of phoenix measuring servo inputs as the difference between the period and the pulse.

Seems to all make sense to me now.

Cheers.