Hobbs Time and Tach Time Flight Durations with v16.2.4

[RV8JD]

I updated my SkyView Touch from v16.0.4 to v16.2.4 and have flown four flights with v16.2.4. Since updating to v16.2.4 the Tach Time flight duration has been longer than the Hobbs Time flight duration. This is a change from my norm, where the Hobbs Time flight duration is almost always longer than the Tach Time flight duration. My taxi and flight profiles have not changed. (And I do understand the difference between the two types of times).

Before and after a flight I jot down the Hobbs and Tach time and enter those in a flight log spreadsheet that does the subtraction to yield flight duration for each.

I checked the setting for “Cruise RPM” used for Tach time calculations and it is unchanged from the 2,400 RPM number it was before the update, so the software update did not inadvertently modify this User Config setting.

Has anyone else seen something similar? It seems like I’m missing something basic.

Here is a snippet from my flight log to illustrate the difference. Again, the last 4 flights are with v16.2.4, the previous flights were with v16.0.4.

 

[swaneymj]

I might have an answer based on a problem I'm seeing since the installation of v16.2.4. I uploaded my flights to SavvyAnalysis and the Tach trace has gone WILD!! As a result, the Tach times are much higher than expected since the next flight starts on the high Tac reading from the previous flight. At least that's my theory. Here are "after" and "before" shots of my Tach and Hobbs times. Hobbs time doesn't seem to be affected.

 

[RV8JD]

Thanks for posting that info. Appreciate it!

Tomorrow I'll download my data log and see if I something similar.

 

[swaneymj]

Thanks for posting that info. Appreciate it!

Tomorrow I'll download my data log and see if I something similar.

I submitted a ticket to Dynon Tech Support. I'm glad you posted this or I'd still be searching for a different cause. If you haven't uploaded your User Logs to Savvyanalysis.com, I'd take a look. It's a great way to monitor your engine health as well as helping to trouble shoot many other issues.

 

[djones]

I will be looking into this issue when I am back in the office tomorrow 12/22
Diagnostic files may be useful here if you can grab them for me.
https://www.dynonavionics.com/data-datalogs-upload.php

 

[RV8JD]

I downloaded the data log files today. So it appears that I'm seeing the same thing "swaneymj" is. Here are some plots of Tach Time and Hobbs Time with v16.2.4 installed. Same flight, but three different zoom scales (Tach Time on top, Hobbs Time on the bottom).

I also downloaded my diagnostic file and sent it to Dynon per Don's request.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I hope Dynon gets this Tach Time issue fixed quick. Can we downgrade to v16.0.4 in the meantime?

 

[boblid]

Just experienced the same. Tach time is much higher than it should be. Hobbs appears to be accurate. Sent a diagnostic file in today. One Flight today showed .9 hrs. Hobbs and 1.2 hrs. Tach??? Second flight showed both Tach and Hobbs at .3 hrs? Third leg showed Tach 1.2 and Hobbs 1.0.

 

[djones]

I have isolated this bug. It is caused by the difference in pulse per revolution settings between one standard mag and another ignition system that is using a different pulse per revolution. I have the case written up for engineering to fix, but they won't resolve it until version 16.3 which is due out first quarter of the new year. There is a work around (although it may not be ideal), if you temporarily disconnect one of the tach inputs and run a single tach input, TACH TIME works fine. If it were me, I would fail the mag input.
The only other way to resolve it will be to go back to version 16.0.8
If you want to go back in software, contact me at support@dynonavionics.com. I will need to send some files and a link to the software to make the system load an earlier version.
Thanks for the reports and data

 

[kurtfly]

So if you have 2 P-Mags, both at 2 PPR, then you do not have this problem?

 

[swaneymj]

I assume this was caused by the updates in 16.2.4 below? Thank goodness it wasn't a safety issue. Thanks for the prompt reply and effort to identify the problem. You guys do a super job working with the customers!
Mark Swaney
Team Rocket F1 N76TR
25 years USN Flight Test F-14A,B &D
13 years Avionics Flight Test Instructor, National Test Pilot School

"New: Support for twin-engine configurations on a single display page. New widget styles are available that display both engines' information on a single gauge.
Note for existing twin-engine customers: These updated twin-engine monitoring capabilities superscede the legacy capabilities. In software versions before 16.2, each EMS module was tied to a single display, requiring two displays to monitor both engines. In version 16.2 and later, each display page (100%/50%/20%/bottom bar) are configured to display gauges from both engines. Additionally, all displays' pages will be identical. In other words, the display of both engines should be configured on each page layout, and those pages are universal across screen. The ability to display only one engine per dislplay is not supported in 16.2 and beyond. However, legacy twin-engine settings will continue to work as-is until changes are made to EMS settings. Contact Dynon technical support for additional details.
New:Dual/split needle engine gauge widgets for twin-engine configurations."

 

[RV8JD]

Don,

Thanks for the quick diagnosis and interim fix before the Holidays. Appreciate it!

 

[jakej]

So if you have 2 P-Mags, both at 2 PPR, then you do not have this problem?

Kurt, That's correct -Ive just got my Glasair, with dual P-Mags, going again after 11 months due Superior (not so) crank AD, I have 30 hrs without ant tach/hobbs times issues.

Jake
Glasair IIS FT 2700hrs & still going strong

 

[djones]

The one thing all of these reports had in common were different pulse per revolution settings in the tach calibration settings.
I could not make it happen if both are the same ie: two magnetos, two Pmags, what ever. SkyView uses the highest RPM reading of the two inputs and it looks like it was changing back and forth with the normal noise and fluctuations. Watching debug data, I could watch the tach time jump up by .5 or so and back down, just by switching back and forth between tach inputs. I was using a 2 channel signal generator which made that easy.
It just isn't handling the math correctly during that back and forth.(I am not a software guy, so ....)

 

[cbretana]

I have 16.2.4 and two P-Mags and am not seeing this issue.

 

[lancair360]

I have 16.2.4 and two P-Mags and am not seeing this issue.

It’s mentioned above but with two P-mags you won’t see this behavior. Same pulses per revolution so there’s no glitch. Only with two separate/different inputs like a mag and a p-mag for example.

 

[RV8JD]

So to follow up on my previous posts: I elected to downgrade from v16.2.4 to v16.0.8. Don sent me an email with instructions, a couple of files, and a link to download v16.0.8. Yesterday I was able to downgrade to v16.0.8, but my EMS widgets were gone, replaced by a solid black area instead. The Network showed that the EMS was in a "Ready" status, and I could bring up the fuel computer with no problem, but no widgets.

A call to Dynon Support was returned quickly by Don himself while I was at the airplane, and he postulated that due to the significant changes to the EMS going to v16.2.4, I should reload my previous USER CONFIG file. He also warned me that doing that would zero out the Hobbs Time and Tach Time (but I had already written those numbers down).

So today I loaded the USER CONFIG file and the EMS widgets were back and looking normal. The Hobbs Time and Tach Time were set to 0.0, but I entered the correct values on the EMS Config page. I flew the airplane and everything is back to normal, including the Tach Time calculation.

When v16.3 comes out, I think I'll let some other folks fly it first! But to be fair, in all the Dynon software updates I've done, this is the first one that caused me a problem.

Thanks again to Don for his help on the phone while I was at the airplane yesterday.

 

[GlennB]

So to follow up on my previous posts: I elected to downgrade from v16.2.4 to v16.0.8. Don sent me an email with instructions, a couple of files, and a link to download v16.0.8. Yesterday I was able to downgrade to v16.0.8, but my EMS widgets were gone, replaced by a solid black area instead. The Network showed that the EMS was in a "Ready" status, and I could bring up the fuel computer with no problem, but no widgets.

A call to Dynon Support was returned quickly by Don himself while I was at the airplane, and he postulated that due to the significant changes to the EMS going to v16.2.4, I should reload my previous USER CONFIG file. He also warned me that doing that would zero out the Hobbs Time and Tach Time (but I had already written those numbers down).

So today I loaded the USER CONFIG file and the EMS widgets were back and looking normal. The Hobbs Time and Tach Time were set to 0.0, but I entered the correct values on the EMS Config page. I flew the airplane and everything is back to normal, including the Tach Time calculation.

When v16.3 comes out, I think I'll let some other folks fly it first! But to be fair, in all the Dynon software updates I've done, this is the first one that caused me a problem.

Thanks again to Don for his help on the phone while I was at the airplane yesterday.

I had a similar saga, also with plenty of help from Don. Loading USER CONFIG didn't work. But there is a fix!

On the USB stick used for the firmware upgrade, Skyview thoughtfully creates a folder called “settings_archive”. In there you will find a file with a .dfg extension and a file name relating to the time of the upgrade. Mine was about 160kB in size, and contained every custom sensor and widget setting, along with calibrations for fuel gauges etc. It‘s a text file, so you can peer inside to see that it's what you need.

Skyview can only see files in the root folder of the drive, so the file must be copied to there. Then, use “load file” to push it to the display. (I’d also renamed it “restorethis.dfg” to be sure of seeing the correct one in the list.) Hey presto, all the settings that existed prior to the 16.2.4 upgrade were restored to match the reversion to 16.0.8. The whole process took about 30 seconds, and my blood pressure was similarly restored to normal…

 

[RV8JD]

I had a similar saga, also with plenty of help from Don. Loading USER CONFIG didn't work. But there is a fix!

On the USB stick used for the firmware upgrade, Skyview thoughtfully creates a folder called “settings_archive”. In there you will find a file with a .dfg extension and a file name relating to the time of the upgrade. Mine was about 160kB in size, and contained every custom sensor and widget setting, along with calibrations for fuel gauges etc. It‘s a text file, so you can peer inside to see that it's what you need.

Skyview can only see files in the root folder of the drive, so the file must be copied to there. Then, use “load file” to push it to the display. (I’d also renamed it “restorethis.dfg” to be sure of seeing the correct one in the list.) Hey presto, all the settings that existed prior to the 16.2.4 upgrade were restored to match the reversion to 16.0.8. The whole process took about 30 seconds, and my blood pressure was similarly restored to normal…

I think we are talking about the same file. The USER CONFIG file I mentioned is the .dfg file, as shown by the example file name below. I did put it in the root folder on the USB drive.

"2021-12-14-NXXXX-SNYYYY-16.0.4.8437-SW_UPGRADE-USER_CONFIG.dfg"

Every time I do a SW update, I copy the “settings_archive” folder from the USB drive to my Mac as a backup. The “settings_archive” folder also includes the SENSOR_CONFIG.sfg file.

"2021-12-14-NXXXX-SNYYYY-16.0.4.8437-SW_UPGRADE-SENSOR_CONFIG.sfg"

If the USER_CONFIG.dfg and the SENSOR_CONFIG.sfg files are downloaded apart from a software upgrade, the filename is similar, but the "SW_UPGRADE" is not in the filename.

 

[GlennB]

I think we are talking about the same file. The USER CONFIG file I mentioned is the .dfg file, as shown by the example file name below. I did put it in the root folder on the USB drive.

You‘re probably right. I’d done a manual export of settings, which didn’t help when I reloaded it, so I was stuck for a while. I wasn’t expecting to find anything in a folder, as Skyview can’t read them from there, so I’d never explored it before.

 

[RV6-KPTW]

Hi Don - I have this issue (1 mag, 1 pmag) when you say “fail” one of the inputs, am I just doing a phyzical disconnect of one of the rpm inputs (probably the pmag…)? Or is this a configuration fix?

Thanks,