Today's Message Index:
----------------------
1. 02:38 AM - Short Discharge Time (Jan de Jong)
2. 06:07 AM - Short Discharge Time (R. curtis)
3. 12:00 PM - Re: Short Discharge Time (Jan de Jong)
4. 03:04 PM - External Flight Plans - Dynon Skyview/Garmin 696 (Matt Dralle)
5. 04:31 PM - Re: (Case 117320) VP-200 Compatibility with Dynon Skyview 5.1 EMS Data (Matt Dralle)
Message 1
| INDEX | Back to Main INDEX |
| NEXT | Skip to NEXT Message |
| LIST | Reply to LIST Regarding this Message |
| SENDER | Reply to SENDER Regarding this Message |
|
| Subject: | Short Discharge Time |
Batteries!
With batteries there are 2 properties of interest:
1. the energy content measured in Wh, or Ah x voltage at some standard
rate of discharge.
2. the efficiency of release of the energy (some power rating)
The first measure is fairly well established, although the "standard"
discharge rate is often very low or not even mentioned, but the second
is not. Manufacturers may give a power rating in W, but they do not
mention how much power is lost internally in heat and what temperature
increase for the battery they had to consider still within bounds to
attain the given power rating.
Manufacturers may also give an internal resistance but it may be at a
useless 1 kHz. In any case it must be related to capacity and voltage to
decide whether the number is relatively high or low.
Mr. Davide Andrea introduces the "Short Discharge Time" (a calculated
time in seconds to completely discharge a battery if shorted) as a
figure of merit for battery efficiency. It does not depend on size,
voltage and composition of a battery.
I found the following interesting:
http://liionbms.com/php/wp_short_discharge_time.php
Jan de Jong
Message 2
| INDEX | Back to Main INDEX |
| PREVIOUS | Skip to PREVIOUS Message |
| NEXT | Skip to NEXT Message |
| LIST | Reply to LIST Regarding this Message |
| SENDER | Reply to SENDER Regarding this Message |
|
| Subject: | Short Discharge Time |
> Batteries!
> With batteries there are 2 properties of interest:
> 1. the energy content measured in Wh, or Ah x voltage at some standard
> rate of discharge.
> 2. the efficiency of release of the energy (some power rating)
May I add a third property of interest?
3. Batteries that self ignite for some unknown reason should never
be used in an aircraft, even
if they meet or exceed all of another batteries specs!
Roger
--
Do you have a slow PC? Try a Free scan http://www.spamfighter.com/SLOW-PCfighter?cid=sigen
Message 3
| INDEX | Back to Main INDEX |
| PREVIOUS | Skip to PREVIOUS Message |
| NEXT | Skip to NEXT Message |
| LIST | Reply to LIST Regarding this Message |
| SENDER | Reply to SENDER Regarding this Message |
|
| Subject: | Re: Short Discharge Time |
I might have said: there are two functional properties of interest - and
a host of non-functional ones - of which not conflagrating ranks pretty
high indeed.
Jan de Jong
On 2/3/2013 3:06 PM, R. curtis wrote:
> <mrspudandcompany@verizon.net>
>
>> Batteries!
>> With batteries there are 2 properties of interest:
>> 1. the energy content measured in Wh, or Ah x voltage at some
>> standard rate of discharge.
>> 2. the efficiency of release of the energy (some power rating)
>
> May I add a third property of interest?
> 3. Batteries that self ignite for some unknown reason should
> never be used in an aircraft, even
> if they meet or exceed all of another batteries specs!
>
> Roger
>
Message 4
| INDEX | Back to Main INDEX |
| PREVIOUS | Skip to PREVIOUS Message |
| NEXT | Skip to NEXT Message |
| LIST | Reply to LIST Regarding this Message |
| SENDER | Reply to SENDER Regarding this Message |
|
| Subject: | External Flight Plans - Dynon Skyview/Garmin 696 |
Dear Listers,
Below is a dialog that I'm currently having with Dynon technical support regarding
the support for External Flight Plans on the Dynon Skyview. I have a Garmin
696 connected serially to the Dynon and use it for primary GPS positional data.
I would like to also have it transfer the current flight plan data as its
a LOT easier to look up remote airports, etc. on the Garmin696. But, for some
reason, the flight plan data doesn't seem to propagate to the Skyview; I can
only assume because the Dynon is ignoring the GPRMB NMEA0182 data fields.
In contrast, I have a King Skymap IIIc connected to the GRT HXs in the RV-8 (for
testing) and I am able to easily get external flight plan data from the Skymap
to the GRT HX over the serial line (see screen shots)
Finally, with the new ADSB receiver on the Skyview, I'm no longer getting Traffic
data on the Garmin 696. With just the Mode S transponder, I get traffic targets
when I'm in traffic areas so the TIS data link (Skyvew->Garmin696) seems
to be working. But as soon as I enable the ADSB receiver, I no longer get the
traffic on the Garmin 696 even though the ADSB traffic is showing up on the
Skyview Map and PDF displays.
Below are some composite screen shots I made for Dynon with embedded comments and
documentation to describe what I'm seeing. I thought I'd share with the rest
of the group in case someone maybe had some feedback or thoughts.
-
Matt Dralle
RV-8 #82880 N998RV "Ruby Vixen"
http://www.mattsrv8.com - Matt's Complete RV-8 Construction Log
http://www.mattsrv8.com/Mishap - Landing Mishap Rebuild Log
http://www.youtube.com/MattsRV8 - Matt's RV-8 HDTV YouTube Channel
Status: 172+ Hours TTSN - Rebuilding Fuselage After Landing Mishap...
RV-6 #20916 N360EM "The Flyer"
http://www.mattsrv6.com - Matt's RV-6 Revitalization Log
Status: 120+ Hours Since Purchase - Upgrades Complete; Now In Full Flyer Mode
At 10:36 AM 2/1/2013 Friday, you wrote:
>Matt,
>
>Please do send some screen shots. We will fly a flight plan from the Garmin. Do
you see the CDI on the HSI?
>
>I can make sense out of this with a picture.
>
>Mike H
>
>Dynon Avionics Technical Support
>support@dynonavionics.com
>Phone: 425-402-0433 - 07:00-17:00 Pacific weekdays
>---
>
>-----Original Message-----
>From: "Matt Dralle" <dralle@matronics.com>
>Date: Fri, 01 Feb 2013 10:01:39 -0800
>To: "Dynon Technical Support" <support@dynonavionics.com>
>Cc: "dralle@matronics.com" <dralle@matronics.com>, "michael Woolson" <mrwoolson@prodigy.net>
>Subject: Re: (Case 117228) Garmin GPS696 Input to Skyview
>
>>Hi Mike,
>>
>>That's not what I'm talking about. What I mean is when I go into the Garmin
and enter in a flight plan. For example, KLVK to KEDU to KMRY. These destinations
are being transmitted by the Garmin over the NMEA 0183 serial output but
the Skyview isn't using them. I have to go into the Skyview and reenter the
destinations.
>>
>>In contrast, on my Garmin to GRT HX installation, if I have a flight plan entered
into the Garmin, that information is picked up and used by the GRT HX. If
I don't have a flight plan on the Garmin, then the GRT HX uses whatever I enter
in on the GRT HX. I can sent you some screen shots if you want.
>>
>>Matt
>>
>>At 09:26 AM 2/1/2013 Friday, you wrote:
>>
Hi Mike,
Please see that attached two images. The first describes what I'm seeing on the
Dynon/Garmin696 and the second shows what I'm getting on the GRT HX/SkymapIIIc.
The third shot is of my Dynon and Garmin 696 configuration.
Note that with the Dynon, there's no external flight plan data utiliation.
Note on the GRT, there is full external flight plan data utilization. I've included
the NMEA0183 data strings that include the flight plan data.
Also note, the lack of ADSB traffic on the Garmin 696 when the ADSB is enabled.
With the ADSB DISABLED, the Mode S traffic appears.
Emacs!
Emacs!
Emacs!
Message 5
| INDEX | Back to Main INDEX |
| PREVIOUS | Skip to PREVIOUS Message |
| NEXT | Skip to NEXT Message |
| LIST | Reply to LIST Regarding this Message |
| SENDER | Reply to SENDER Regarding this Message |
|
| Subject: | Re: (Case 117320) VP-200 Compatibility with Dynon Skyview |
5.1 EMS Data
(I sent the message below to Dynon this afternoon. FYI -Matt)
Dear Dynon Support,
I was forwarded the text immediately below regarding the new Skyview Version 5.1
issue and EMS data stream compatibility with Vertical Power VP-200
I think that Dynon is kind of missing the point here. Dynon has, for all intents
and purposes, developed a "standard" for this EMS data format. Whether arbitrary
3rd parties use it and/or communicate that use to Dynon is also beside
the point. Dynon has committed to a certain format and as such cannot change
it without incurring some serious, potentially negative and/or life threatening
ramifications in the field. The designers of TCP/IP didn't just randomly decide
to change the order and meaning byte values in the standard. A standard
is a standard. When its done and released, *its done*. Version 1.0 cannot be
updated.
Adding a "version string" to the data stream doesn't work either as the devices
listening to version 1.0 don't know the version string is there and are equally
as broken.
The only option is to version each new format and allow the user to select between
the various version. Or, depending on the flexibility of the protocol, ADD
new data strings to the format. But the original data strings *cannot* be changed.
For example, in NMEA0183, $GPGGAxxx, $GPRMCxxx etc. allow for a progression
of new formats to be added. But the format of $GPGGAxxx always has to
remain the same.
I work at a Government research laboratory in Livermore where I engineer and write
embedded firmware for remote security terminals that are used throughout the
Department of Energy sites. Part of that responsibility is to design, implement,
and utilize serial protocols for communicating between various devices
over both RS485 and Ethernet. If I were to make a change to our protocol like
Dynon has done in the upgrade between 5.0 and 5.1, I would be fired. Plain and
simple. Even IF everyone that is using the protocol happens to be notified
of the change, there is still the issue of incrementally upgrading all of the
end devices.
I guess my point here is that Dynon needs to take their various "proprietary" serial
protocols a whole lot more seriously. I believe this is now at least the
*third* time that a protocol change has adversely impacted the user community.
That is *not* acceptable. I would have probably been fired after the first
indiscretion, if not strongly reprimanded. The second and third times would
just not have happened.
For protocol versioning control, Dynon needs to either add additional named strings
to their protocol or they need to simply start versioning each change AND
including support for all versions in their products. For example, the user
should be able to select between EMS Version 1 or EMS Version 2 or EMS Version
3 from the configuration menu. The format of EMS Version 1 or any previous versions
can never change; period.
And finally, given Dynon's lackadaisical attitude toward their protocol specifications,
I find it almost impossible to believe that a simple downgrade from Version
5.1 to 5.0 is, by default, disallowed? Why aren't the same Draconian version
control practices imposed on the customers, applied to their software developers
as well?
Matt Dralle
RV-8/RV-6/RV-4
>Forwarded Email (Originally from Dynon Support)
>
> We updated the serial stream because we had some important customers that asked
for specific elements to be added to the stream. We knew this was a possibility
since day one, and even put a version number in the serial stream so an
application can tell that the stream has been changed. We would always prefer
to not change the format, but at some point you need to balance the needs of a
variety of customers, and we had a clear business case to support customers asking
for new features in the serial stream.
>
>One of the issues here is that the VP-200 is not a product we "support." While
we have official support for the VP-X,
>Vertical Power used our serial stream for the VP-200 on their own accord without
any input from us. This is fine and in fact the whole reason that we created
a documented serial stream, but this means we didn't even really know they were
using it so it's hard for us to realize that we were going to break anything.
Compatibility is something that we test every release for products we support,
but isn't something that we can promise for arbitrary 3rd party devices
that few of our customers use.
>
>We only moved a few parameters around in the new serial stream, so it's unfortunate
that it will take them months to fix this as it's likely just a few constants
in their code to make it work again.
>
>It is possible to revert to 5.0 without much hassle. Contact support via email
or phone and we can send you instructions.
At 03:48 PM 2/1/2013 Friday, Dynon Technical Support wrote:
>Matt:
>
>Another customer told us today that Vertical Power recommended not updating to
v5.1 because of changes Dynon made to the streaming data format.
>
>We advise talking to Vertical Power first.
>
>Thanks,
>
>Steve
>
>Dynon Avionics Technical Support
>support@dynonavionics.com
>Phone: 425-402-0433 - 07:00-17:00 Pacific weekdays
>
>-----Original Message-----
>From: "Matt Dralle" <dralle@matronics.com>
>Date: Fri, 01 Feb 2013 15:26:51 -0800
>To: "support@dynonavionics.com" <support@dynonavionics.com>
>Cc: "support@verticalpower.com" <support@verticalpower.com>
>Subject: VP-200 Compatibility with Dynon Skyview 5.1 EMS Data
>
>>With the release of Skyview 5.1, it seems there might be an issue with the new
EMS data format from the Skyview and compatibility with the Vertical Power VP-200
EMS input.
>>
>>I haven't upgraded my Skyview from 5.0 to 5.1 but I was planning to on Saturday.
Any thoughts?
>>
>>Here's the thread from the RV10-List Forum (towards the bottom):
>>
>>http://forums.matronics.com/viewtopic.php?p=393418#393418
>>
>>Thanks for your help,
>>
>>Matt Dralle
>>
Matt G Dralle | Matronics | 581 Jeannie Way | Livermore | CA | 94550
925-606-1001 V | 925-606-6281 F | dralle@matronics.com Email
http://www.matronics.com/ WWW | Featuring Products For Aircraft
Other Matronics Email List Services
These Email List Services are sponsored solely by Matronics and through the generous Contributions of its members.
-- Please support this service by making your Contribution today! --
|