Hi Geoff
*Equipment*
What equipment are you using? a KC-10 with a 'probe and drogue'?
*The Prize*
>> I will offer a VIRTUAL bottle of good Bordeaux rouge to the first pilot
who maintains drogue contact for say a minute
Good luck.
Am I correct in thinking that a sudden movement of a foot or more will
cause the probe to miss the drogue?
And a sudden movement forwards or backwards of, say, ten feet may cause a
disconnect?
If so, consider:
At the equator a degree of latitude or longitude is about 69 miles.
Therefore one foot equals 0.00000274483 degrees.
I note that http://crossfeed.fgx.ch/data supplies latitude and longitude of
six decimal places - in other words down to a precision of one foot
increments.
This kind of appears to be OK. but there are other factors to consider.
For example perhaps the numbers are bogus.
The explanation is hiddden in this complex article:
http://en.wikipedia.org/wiki/Floating_point
What it's saying is that if, in determining positions, heading, speed or
delts and if there is a sin, tan or square root used in the calculation,
then you are hosed if there is a 32-bit or longint anywhere in the code.
Intermediate products wreak havoc on accuracy. Playing with big numbers and
little numbers at the same time produces odd results.
[Harking back to the conversation a couple of weeks ago between you and
Peter on 32-bit vs 64-bit: My vote is for 128-bit.]
I could go on and on. 220 knots is over 371 feet per second. At a 10 Hz
interval the planes have moved over thirty feet.
In order to calculate an accurate delta then you need to eight or nine
digits of degree precision
*The easy answer: Cheat*
It would be far easier if you could lock your deltas to those of the probe.
If the probe moves an arbitrary distance forward then your position would
be its position plus X.
Is there some 'over the shoulder view' set of numbers that you could use to
lock your plane's deltas to the movement of the other plane? If so that
would be great. Of course, trying to refuel two planes at the same time
might make the ride a bit jerky for your passengers.
*10 Hz*
I laugh when I see such a number. Do you really expect something as silly
as a computer to be that reliable?
In my highly asynchronous animation world we have no use for setTimeout,
fixed intervals or whatever. Their behavior causes logjams and fails. The
current device/trick/whatever is a called Request Animation Frame.
See
https://developer.mozilla.org/en-US/docs/DOM/window.requestAnimationFrame
http://paulirish.com/2011/requestanimationframe-for-smart-animating/
http://updates.html5rocks.com/2012/05/requestAnimationFrame-API-now-with-sub-millisecond-precision
Yes, I know this is all browser-based stuff but could work just as well in
an executable - and how about the thought of running FG on a laptop for
hours without draining the battery?
*Why UDP?*
I have asked several times but nobody answers: Why does FG still use UDP
when there are so many easier more modern alternatives - ranging from a
RESTful system to RTC?
**
I'd love to see some logs of two planes trying to refuel. My guess is that
from a global point of view they are touching, but when it gets down to
inches - the two planes are all over the place. - lost in a rounding-error
space.
In any case, good luck with giving out the Bordeaux!
Theo
On Wed, Apr 17, 2013 at 4:13 PM, Geoff McLane <ubu...@geoffair.info> wrote:
> NOTAM:
>
> To flyers who fly 'probe' enabled aircraft in Europe... or
> even if NOT...
>
> I will be flying the 'victor' refueling tanker for the next
> few days from KFPY, south 180 track, then turn around at the
> southern mountains, north on 360, at 12,000 feet – FL120
> STD QNA – and am interested in 'hot' flyers who want to try
> air-to-air REFUELING (AAR) in suitably equiped aircraft,
> well ANY aircraft...
>
> The tanker will maintain, under autopilot, 220 knots (KTAS),
> at the said 12,000 feet, either 180 or 360, under the callsign
> GA006.
>
> The flights will commence about noon, or before, UTC, and
> close about 20:00 UTC.
>
> The track can be followed using http://test.fgx.ch, or other mp
> map URLS. Click on 'GA006' to localize...
>
> Reason:
>
> (a) I have tried with several aircraft over the last few days, and
> learned that this is QUITE difficult, but I hope NOT impossible!
>
> (b) The present suggested pps (Hz) is 10 when you set up –multiplay=,
> but FG 2.11 has fill-in extrapolation code when fgfs packets
> do not arrive in time, so maybe this is too high. This is the basic
> question...
>
> So the idea is to reduce this IFF this fill-in code helps, ie does its
> job...
>
> The theoretic idea is that with this code we can reduce the
> bandwidth used by 10 Hz to perhaps 2-4 Hz, but this needs
> to be FULLY tested, and confirmed...
>
> Now I have tried this over several day, in several aircraft –
> A-10, f-14b, a4 and failed, FAILED to touch the trailing
> drogues... it is TOUGH... autopilots help you get to the 'zone'
> but it needs manual flying to get to the RIGHT PLACE...
>
> If you are using a joystick maybe you need to even adjust
> the dead spot and the 'sensitivity' of the inputs... lots of
> learning, understanding and doing fgdata xml changes...
>
> And I have had a few pilots joining in ad hoc, but so far
> no one has actually contacted with the trailing outer wing
> drogues... The 'victor' can refuel 2 aircraft at a time... and I
> would LOVE to see/capture that...
>
> One, french I think, got so frustrated at his attempts, began firing
> missiles at the tanker. Thankfully, he MISSED, but was CLOSE ;=))
>
> Also if you alert me to your attempt to refuel from my tanker, via
> mp chat, email, fgcom, … AND I am on board at the time -:
>
> (a) I will offer a VIRTUAL bottle of good Bordeau rouge to the first
> pilot who maintains drogue contact for say a minute, or more ;=))
>
> (b) I will take some screen shots and post them.
>
> Be warned, during a screen shots (F3), fgfs stops sending mp
> packets for up to a second or so, and in the close fgfs the fill-in
> (extrapolation) code is activated, with some interesting, and
> sometimes quite alarming effects...
>
> Also I have heard others mention that the live metar update can
> also cause mp packet delays. The tanker will be flying under the
> 'Fair weather' scenario to avoid this. Maybe you should choose this
> as well...
>
> I really seek help from other pilots to analyse this multiplayer
> bandwidth situation. We have chosen 10 Hz, but WHY?
> Can less than 10 Hz be used with no adverse effect? That is
> the BIG question...
>
> Simply, what really is the optimum packets-per-second (pps) rate?
> Maybe it changes depending on circumstances...
>
> We know the lower the Hz the lower the bandwidth used by
> FGMS servers... but can the extrapolation code fill-in for
> the missing packets?
>
> Is 10 Hz good? Should it be higher, or lower depending on
> circumstance.. Lots to learn...
>
> Of course I am sure there are OTHER ideas...
>
> Hope you can help, and have some FUN at the same time;=)).
>
> Look forward to seeing you on my rear view... and I will
> take some pics...
>
> Regards,
> Geoff.
>
> CC: to users list...
> BCC: to others...
>
> --
> You received this message because you are subscribed to the Google Groups
> "fgx-project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fgx-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Flightgear-users mailing list
Flightgear-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-users
