Anyone see errors with PPM and VBAR?

[Greg Alderman]

Nice report! Next time I see you...the beer is on me! Although I also have been wanting an 18mz...I really love the Jeti and all of its awesome features...so this is good news. I may have to wait a little longer to decide if the Jeti goes and the 18MZ comes...

I will go ahead and repair the 770 and give it another go...although, the R6L needs to go back to Danny as the crash took off 1 of the Antenna about 1/2 way. But, I may just carefully take the insulation off the required amount to expose the end and use in a small Heli. I remember being old that this was acceptable to do as just the small exposed end is the actual antenna portion.

Looking forward to the UDI update even more so now...

[F1 Rocket]

I've forwarded this to the guys at Jeti and will let everyone know their comments when I hear back from them. In the mean time it would be great if this info could be a sticky.

[Seasick78]

I've been running 100hz with ppm positive and 20ms with failsafe "on" ever since 100hz has been available with these radios. The only issues I ever had were motor cutouts (everything else was fine) which were as a result of a now corrected FBL system bug. Have had zero issues since then, with several R7's, R5's, and R6's... All set the same (100hz, 20ms, PPM positive, failsafe on with -100 for throttle and neutral settings for flat pitch in failsafe etc.). FBL - BD3SX...

Very interesting thread!

[cbdane]

Originally Posted by rchelijc

Cbdane, great work and confirms my suspicions, lengthy explanation several posts back.

Basically with Failsafe OFf, the Rx discards the signal received from the Tx, after constructing the PPM for output. With failsafe ON, it must not discard it because if that's the last signal from the Tx then it needs to maintain that as a constant to vbar, or whatever your failsafe settings are.

This "chucking away" is obviously not syncing well with 50hz where it will happen very often where the gap between pulses is longer than expected by vbar. Cannot happen with 100hz

I partially agree but I think the problem isn't the "gap longer than expected by vbar" but the fact that the pulse packets run together in the Jeti PPM output. Notice that, in the vbar, we don't specify the number of channels in the PPM stream; I believe that vbar looks for a quiescent gap to determine the end of a packet and therefore how many channels are being transmitted. When this gap occasionally (and randomly) collapses, then the vbar tries to interpret this interval as the next channel (9, for example) and finds that it is well out of the 1-2ms tolerance and reports an error. Just my theory and some thoughts.

One way to further illuminate this would be to test your theory by looking for additional packets in the stream with failsafe pulse data from the transmitter. I think this is unlikely but I'll try to fit it in tonight.

[flymustangs]

Hey Brent, what model scope is that? I think I need a new toy.

[cbdane]

Originally Posted by flymustangs

Hey Brent, what model scope is that? I think I need a new toy.

It's an old (12-13 years) Tektronix 60MHz, 2 channel (Model 1002, I believe) that I use for my home business (electronic design and embedded control programming). It works great but the newest version has a USB port on the front which allows you to directly download screen shots and digital curves. I'd definitely recommend it if you're looking for a general purpose scope.

Added in edit: It looks like the current version is the TBS1062.

[mkovalcson]

FYI, If you are looking for a "toy". There was a sale on these back in November and I picked one up for $222. Dirt cheap for a 25MHz scope. Now it is NOT a tektronix, but it works pretty well. Looks like they are up to $350 right now. I'm not sure what the deal is but mine seems to work well enough for what it is and has software to grab screen shots etc..

http://www.amazon.com/PDS5022T-Porta...words=PDS5022T

[flymustangs]

Thanks! Something like this would have been very useful when I reversed engineered the Xicoy V10 data protocol. My old analog scope was basically useless. Luckily, there were other tools out there. I wound up buying Xicoy's device anyway since it had a couple of features mine did not and the price was good.

[Kiba]

Brent,

I think the Vbar and RX failsafes can coexist without a problem provided you set the RX failsafe channel outputs to "drive to position" and not "hold."

If you have the RX failsafes set to "hold" then the heli will just keep doing whatever it was doing in the event of a TX to RX link failure... certainly not safe and if your FBL controller has an event log you won't be left any clues as to the cause of the failure.

"Drive to Position" failsafe condition however is useful; in the event of a TX to RX link loss I have the RX channel failsafes are set to the following:

Aileron / Elevator / Yaw / Collective: go to position "neutral"
Tail gain: "hold last position"
Throttle: go to position "-120%" (throttle cut)

Since I'm running HC3SX, I also have a failsafe on the head gain channel which is "go to position" +100% which activates maximum self leveling. Thus, if my helis ever experience a TX to RX link failure the throttle will cut, any control inputs will be set to neutral, and the heli will rapidly self-level.

Of course, you want to set your FBL controller failsafes as well such that in the event you have an RX to FBL controller link failure (RX failure, PPM cable failure, etc) the FBL controller will know to cut the throttle.

The Jeti RX failsafe conditions can be set to "hold last position," "go to position," and "no output." My thought is "go to position" makes the most sense from a safety perspective. However, "no output" makes sense as well especially on an FBL controller with logging as "no output" would create an invalid PPM stream and leave you a clue in the FBL event log as to what actually caused the failure; once the FBL controller detects no valid outputs from the RX it will go to the set failsafe conditions and if the FBL controller has an event log it should log this condition.

This is of course a separate issue than the poor PPM packet formation at 50hz / failsafe off but I think proper RX failsafe setting should be mentioned as well.

I wonder if this PPM framing issue was present even in early firmwares when it was only 50hz (in early firmwares there was no 100hz option.) Being a very early adopter of the Jeti stuff I initially set all my receivers up with PPM but also with "drive to position" failsafes set-- so if the 50 hz / RX failsafe off PPM framing errors were present back in December of 2012 with the initial firmware versions I would never have encountered it.

[Clay333]

I can confirm Cdbanes theory about the failsafes playing a role in the problem even further. There are 2 helis of mine that have Vbar that I have encountered no problems with, my X5 and X4II. The X5 has about 75 flights on it and the X4ii has about 30. Neither of them have had any problems. The X5, has express software so I can't see the logs, but the X4ii has Pro and the logs are clean. The one thing that these helis have in common that is not common with the others is that I never turned the failsafes off in the receivers. So they were running with stock failsafes in PPM positive (8ch,20ms), but were still running at 50hz since that is a universal setting, not something that is changed per model. I am truly astounded by Cdbanes work. It took him less than a few hours to find a major bug in the firmware that everyone has been running for nearly a year and yet everyone else (including Jeti) has missed it!

[F1 Rocket]

We had a conversation with Jeti today. They advise that everyone run the TX at 100Hz. There is no reason to use the 50 Hz setting.

[Greg Alderman]

Thanks Danny! Did they give any other insight on the issues some of us seeing? Or "just use 100hz"? I am going to go ahead and rebuild the 770 one more time...I am hoping for the best! :-)

[rchelijc]

Originally Posted by cbdane

I partially agree but I think the problem isn't the "gap longer than expected by vbar" but the fact that the pulse packets run together in the Jeti PPM output. Notice that, in the vbar, we don't specify the number of channels in the PPM stream; I believe that vbar looks for a quiescent gap to determine the end of a packet and therefore how many channels are being transmitted. When this gap occasionally (and randomly) collapses, then the vbar tries to interpret this interval as the next channel (9, for example) and finds that it is well out of the 1-2ms tolerance and reports an error. Just my theory and some thoughts.

One way to further illuminate this would be to test your theory by looking for additional packets in the stream with failsafe pulse data from the transmitter. I think this is unlikely but I'll try to fit it in tonight.

I thought so initially, but I've scoped out a Jeti Rx PPM output, and can confirm that what Danny said is correct: that the Rx automatically adjusts the length of the PPM signal to an appropriate length to accommodate the frame gap, hence preventing a lot of the gap collapse issues faced by other Rx'es when you specify a fixed length and they strictly enforce it.

I'm assuming that all Jeti Rx'es PPM out work like that, but I have not tested all of them.

So my only conclusion comes from the "Failsafe Off" clue - notice that you don't get errors on FS "ON".

So working backwards, "ON" requires the Rx storing last known good signal, and repeating it if necessary for Rx-driven failsafe to work.

The simplest way to implement is to keep repeating the PPM to vbar based last known signal, if no new valid signal has arrived. And only construct a new PPM if at least one channel has changed - this would be efficient use of time.

However, "OFF" removes this requirement to store, and it could have been easily implemented as 'don't store' by Jeti.

So if you could set your Tx to 20Hz, that's 50ms! Without the Rx buffering the last signal, it'll have to wait 30ms or more, doing nothing.

And that doing nothing probably kicks off vbar's thresholds, a bit like this:
- single line error...
- single line error...
- single line error...
- Failsafe activated..

Or something like that

[Seasick78]

Did the scope indicate a difference between auto vs. say, 20ms?

[cbdane]

Originally Posted by Seasick78

Did the scope indicate a difference between auto vs. say, 20ms?

No, the pattern in the PPM data stream was completely unaffected by the setting in the receiver. I looked at 10ms, 20ms, and Auto. They were all identical except for when using 50Hz in the transmitter and "failsafe off" at which point the output became very erratic.

[Seasick78]

Thank you.

[rchelijc]

Originally Posted by Seasick78

Did the scope indicate a difference between auto vs. say, 20ms?

Yes, when I set it to minimum (can't remember the value, it was months ago), and I set all channels to low or high (depending) so that PPM out for each channel is around 1.1ms, you can visually see the signal pulse shorten way under 20ms, for 8 channels. Basically, it looks like it almost behaves like a variable length signal, with the frame gap at the end of each pulse maintained at a constant, like 4ms or something.

This previous analysis is what led me to the conclusion, that vbar may not tolerate gaps, or frame gaps, beyond a certain length before complaining.

And I would think so, because the brains behind vbar seems to like data, and it'll report errors in certain sequences, eg. Leading up to failsafe activation, so that guys like MrMel / Ulrich can diagnose problems just from the log file.

[rchelijc]

Originally Posted by cbdane

No, the pattern in the PPM data stream was completely unaffected by the setting in the receiver. I looked at 10ms, 20ms, and Auto. They were all identical except for when using 50Hz in the transmitter and "failsafe off" at which point the output became very erratic.

Cbdane, set it at 10ms... You should be able to set your sticks and switches (maybe reverse some channels) to minimum and get a really short pulse, around the 13ms mark... While still on the scoping, now put all channels to max... You should be getting a 20ms or so pulse now. In fact you should see the pulse length expanding as you are doing it.

[bikerlee]

I stumbled into this thread after having the exact same problem as Clay here… https://www.helifreak.com/showthread.php?t=595498.

A couple of months ago I had the Logo 600 lose connection and crash, I thought it was related to a loose connection at the receiver so used some shoe goo on it. To complicate things the iKon would only boot first time around 50% of the time so swapped it over for the one on my Logo400SE, which also now only boots around 50% of the time so was leaning towards that as the culprit.

Two weeks ago the 600 locked out three times, the first time just after take off and landed in the snow so luckily no damage. Had some charged packs so hovered them out but it locked out another two times, each time the Jeti DS-16 showed a signal loss and the iKon flashing red so figured it’s got to be related to the receiver now.

The receiver antenna (R5 receiver) on both the 400 and 600 run parallel to the boom and down 90 deg. towards the skids. The 400 is not grounded but the 600 is, although I have not checked the resistance in a while.

I have an R3 on the Diabolo with the antennas on a Y tray and not had a problem with it.

All the receivers are set to fail safe and drive to neutral position. I was stoked to read that changing to 100hz should help only to find I am already at 100hz…really hope the UDI fixes this.

[mkovalcson]

Originally Posted by cbdane

No, the pattern in the PPM data stream was completely unaffected by the setting in the receiver. I looked at 10ms, 20ms, and Auto. They were all identical except for when using 50Hz in the transmitter and "failsafe off" at which point the output became very erratic.

There must be some handshake that happens with an intelligent FBL controller.

However when I configured my Jeti receiver to talk to the Real Fight Dongle the PPM setting mattered. At 19-20ms it seemed to work, but 18ms and below it had issues.

I've found some of my receivers connected to my SK-720 set to 17ms despite the fact I thought I had them all set to 20ms but they had no problems.