Re: [Flightgear-devel] GPS - merge request
Not sure what went wrong but i get this error consistently now: Nasal runtime error: props.setValue() with non-number at /media/FG/fgdata/Nasal/props.nas, line 29 called from: __dlg:gps, line 20 called from: __dlg:gps, line 134 Segmentation fault (core dumped) On Fri, Oct 4, 2013 at 1:48 AM, Dirk Dittmann dirk.dittmann@gmail.comwrote: Am Donnerstag, 3. Oktober 2013, 21:38:52 schrieb James Turner: On 3 Oct 2013, at 17:35, Dirk Dittmann dirk.dittmann@gmail.com wrote: The improved-issue1164 is ready. https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a1238850376ea2374358fd887 : Thanks, looks good and pushed. thx Unfortunately I now need to fix the route-path code to subdivide long legs along the great-circle course, since currently the map shows a visible difference at the midpoint of legs. But, that's a bug I'm glad to have :) i dont want to force you ;-) Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
Am Mittwoch, 9. Oktober 2013, 01:37:27 schrieb syd adams: Not sure what went wrong but i get this error consistently now: Nasal runtime error: props.setValue() with non-number at /media/FG/fgdata/Nasal/props.nas, line 29 called from: __dlg:gps, line 20 called from: __dlg:gps, line 134 Segmentation fault (core dumped) i think it's intern in the Dialog line:26 dlg.getNode(scratch-index, 1).setValue(index); raise the fault. called from line:140 updateSearchResults(0, dlg.getNode(scratch-index, 1).getValue()); the line are in the runtime error are viewed from nasal so it can' see the xml head. it looks like the scratch-index is create by the getNode function and not bound to a type. In the Property Browser it shows type none. so getValue() return not a number. dlg.initNode(scratch-index,0,INT) is maybe a better interface to crate the Node. On Fri, Oct 4, 2013 at 1:48 AM, Dirk Dittmann dirk.dittmann@gmail.comwrote: Am Donnerstag, 3. Oktober 2013, 21:38:52 schrieb James Turner: On 3 Oct 2013, at 17:35, Dirk Dittmann dirk.dittmann@gmail.com wrote: The improved-issue1164 is ready. https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a123885037 6ea2374358fd887 Thanks, looks good and pushed. thx Unfortunately I now need to fix the route-path code to subdivide long legs along the great-circle course, since currently the map shows a visible difference at the midpoint of legs. But, that's a bug I'm glad to have :) i dont want to force you ;-) Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktr k ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
No , Im not sure what caused the segfault... but the error message appears every time i try to use gps navigation ( with the b1900d).Another change in behavior is the heading needle deflection is extremely sensitive now when using nav1 slaved to gps. I could be wrong , i dont have the docs in front of me , but i was sure the gps deflection range was 5 nm. Syd On Wed, Oct 9, 2013 at 4:21 AM, Dirk Dittmann dirk.dittmann@gmail.comwrote: I will search for that. allways a segfault ? fg crash ? 2013/10/9 syd adams adams@gmail.com Not sure what went wrong but i get this error consistently now: Nasal runtime error: props.setValue() with non-number at /media/FG/fgdata/Nasal/props.nas, line 29 called from: __dlg:gps, line 20 called from: __dlg:gps, line 134 Segmentation fault (core dumped) On Fri, Oct 4, 2013 at 1:48 AM, Dirk Dittmann dirk.dittmann@gmail.com wrote: Am Donnerstag, 3. Oktober 2013, 21:38:52 schrieb James Turner: On 3 Oct 2013, at 17:35, Dirk Dittmann dirk.dittmann@gmail.com wrote: The improved-issue1164 is ready. https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a1238850376ea2374358fd887 : Thanks, looks good and pushed. thx Unfortunately I now need to fix the route-path code to subdivide long legs along the great-circle course, since currently the map shows a visible difference at the midpoint of legs. But, that's a bug I'm glad to have :) i dont want to force you ;-) Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
If its any help , the error message pops up the instant the gps dialog is opened.The dialog seems to work regardless , so Im not sure what the problem is. Syd On Wed, Oct 9, 2013 at 1:20 PM, syd adams adams@gmail.com wrote: No , Im not sure what caused the segfault... but the error message appears every time i try to use gps navigation ( with the b1900d).Another change in behavior is the heading needle deflection is extremely sensitive now when using nav1 slaved to gps. I could be wrong , i dont have the docs in front of me , but i was sure the gps deflection range was 5 nm. Syd On Wed, Oct 9, 2013 at 4:21 AM, Dirk Dittmann dirk.dittmann@gmail.com wrote: I will search for that. allways a segfault ? fg crash ? 2013/10/9 syd adams adams@gmail.com Not sure what went wrong but i get this error consistently now: Nasal runtime error: props.setValue() with non-number at /media/FG/fgdata/Nasal/props.nas, line 29 called from: __dlg:gps, line 20 called from: __dlg:gps, line 134 Segmentation fault (core dumped) On Fri, Oct 4, 2013 at 1:48 AM, Dirk Dittmann dirk.dittmann@gmail.com wrote: Am Donnerstag, 3. Oktober 2013, 21:38:52 schrieb James Turner: On 3 Oct 2013, at 17:35, Dirk Dittmann dirk.dittmann@gmail.com wrote: The improved-issue1164 is ready. https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a1238850376ea2374358fd887 : Thanks, looks good and pushed. thx Unfortunately I now need to fix the route-path code to subdivide long legs along the great-circle course, since currently the map shows a visible difference at the midpoint of legs. But, that's a bug I'm glad to have :) i dont want to force you ;-) Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
Am Donnerstag, 3. Oktober 2013, 21:38:52 schrieb James Turner: On 3 Oct 2013, at 17:35, Dirk Dittmann dirk.dittmann@gmail.com wrote: The improved-issue1164 is ready. https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a1238850376ea2374358fd887: Thanks, looks good and pushed. thx Unfortunately I now need to fix the route-path code to subdivide long legs along the great-circle course, since currently the map shows a visible difference at the midpoint of legs. But, that's a bug I'm glad to have :) i dont want to force you ;-) Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
Hi James, The improved-issue1164 is ready. https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a1238850376ea2374358fd887: Dirk Am Dienstag, 1. Oktober 2013, 21:37:58 schrieb James Turner: - please make a helper function for the great-circle XTK error function, with some sane name like 'greatCircleCrossTrackError'. And please include a full URL to the aviation formulary link, for future readers of the code. (You already did this in one place I think) done - where you only want course OR distance, SGGeodesy has some convenience wrappers (I realise in most places in this patch you do want both). This is just to improve readability right now (avoids useless 'az2' declarations), but in the future we might be able to do less work if only one value is needed. done - Please squash commits, rebase -i is your friend - so all the evolution of the LegController should probably be squashed together. Similary the adding and removing of _mode_node will disappear with some squashing. done - Avoid UTF-8 degree symbols in comments, it might upset some compilers. We recently had an issue with the older GCC on Jenkins rejecting UTF-8 BOM marker. done - I would prefer arithmetic terms in conditions to *always* be parenthesised, we've had some bad bugs due to this, so: if (a (b + c)) NOT if (a b + c) - Where boolean conditional get complex, I often like to create explicit bools, so instead of: if ((some complex test) (some other complex test) ((another thing) || (still more))) I think it's more readable to do: bool answerOfTest1 = some complex text bool answerOfTest2 = some other complexTest … if (answerOfTest1 answerOftest2 …) done The compiler will get rid of the bool vars, although you might force evaluation of more terms depending on how smart you the optimiser is, but you force yourself to give each boolean expression a name, like 'isWithinOverflightDistance' or 'isWithinInterceptAngle'. As a result it becomes much easier for someone else to evaluate the conditional logic and decide if they agree with it or not. If the boolean test is used more than once, make it into a helper method - grep-ing for methods names is*() and has*() in the codebase points to many of these. In general it looks pretty good though, let me know if you're happy to make the above changes or need any help (especially if you're new to git rebase -i, it can do terrible things) Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
On 3 Oct 2013, at 17:35, Dirk Dittmann dirk.dittmann@gmail.com wrote: The improved-issue1164 is ready. https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a1238850376ea2374358fd887: Thanks, looks good and pushed. Unfortunately I now need to fix the route-path code to subdivide long legs along the great-circle course, since currently the map shows a visible difference at the midpoint of legs. But, that's a bug I'm glad to have :) Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
http://wiki.flightgear.org/Talk:Nasal_Style_Guide On Thu, Oct 3, 2013 at 9:38 PM, James Turner zakal...@mac.com wrote: On 3 Oct 2013, at 17:35, Dirk Dittmann dirk.dittmann@gmail.com wrote: The improved-issue1164 is ready. https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a1238850376ea2374358fd887: Thanks, looks good and pushed. Unfortunately I now need to fix the route-path code to subdivide long legs along the great-circle course, since currently the map shows a visible difference at the midpoint of legs. But, that's a bug I'm glad to have :) Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
On 30 Sep 2013, at 08:47, Dirk Dittmann dirk.dittmann@gmail.com wrote: branche fix-issue1164 @ my clone https://gitorious.org/fg/dirks-flightgear/source/85592ec45db2866a15197c051d97cb4014537b4b: Hi Dirk, this is looking pretty good, just some small nitpicks: - please make a helper function for the great-circle XTK error function, with some sane name like 'greatCircleCrossTrackError'. And please include a full URL to the aviation formulary link, for future readers of the code. (You already did this in one place I think) - where you only want course OR distance, SGGeodesy has some convenience wrappers (I realise in most places in this patch you do want both). This is just to improve readability right now (avoids useless 'az2' declarations), but in the future we might be able to do less work if only one value is needed. - Please squash commits, rebase -i is your friend - so all the evolution of the LegController should probably be squashed together. Similary the adding and removing of _mode_node will disappear with some squashing. - Avoid UTF-8 degree symbols in comments, it might upset some compilers. We recently had an issue with the older GCC on Jenkins rejecting UTF-8 BOM marker. - I would prefer arithmetic terms in conditions to *always* be parenthesised, we've had some bad bugs due to this, so: if (a (b + c)) NOT if (a b + c) - Where boolean conditional get complex, I often like to create explicit bools, so instead of: if ((some complex test) (some other complex test) ((another thing) || (still more))) I think it's more readable to do: bool answerOfTest1 = some complex text bool answerOfTest2 = some other complexTest … if (answerOfTest1 answerOftest2 …) The compiler will get rid of the bool vars, although you might force evaluation of more terms depending on how smart you the optimiser is, but you force yourself to give each boolean expression a name, like 'isWithinOverflightDistance' or 'isWithinInterceptAngle'. As a result it becomes much easier for someone else to evaluate the conditional logic and decide if they agree with it or not. If the boolean test is used more than once, make it into a helper method - grep-ing for methods names is*() and has*() in the codebase points to many of these. In general it looks pretty good though, let me know if you're happy to make the above changes or need any help (especially if you're new to git rebase -i, it can do terrible things) Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
Am Dienstag, 1. Oktober 2013, 21:37:58 schrieb James Turner: On 30 Sep 2013, at 08:47, Dirk Dittmann dirk.dittmann@gmail.com wrote: branche fix-issue1164 @ my clone https://gitorious.org/fg/dirks-flightgear/source/85592ec45db2866a15197c051d97cb4014537b4b: Hi Dirk, this is looking pretty good, just some small nitpicks: - please make a helper function for the great-circle XTK error function, with some sane name like 'greatCircleCrossTrackError'. And please include a full URL to the aviation formulary link, for future readers of the code. (You already did this in one place I think) - where you only want course OR distance, SGGeodesy has some convenience wrappers (I realise in most places in this patch you do want both). This is just to improve readability right now (avoids useless 'az2' declarations), but in the future we might be able to do less work if only one value is needed. - Please squash commits, rebase -i is your friend - so all the evolution of the LegController should probably be squashed together. Similary the adding and removing of _mode_node will disappear with some squashing. - Avoid UTF-8 degree symbols in comments, it might upset some compilers. We recently had an issue with the older GCC on Jenkins rejecting UTF-8 BOM marker. - I would prefer arithmetic terms in conditions to *always* be parenthesised, we've had some bad bugs due to this, so: if (a (b + c)) NOT if (a b + c) - Where boolean conditional get complex, I often like to create explicit bools, so instead of: if ((some complex test) (some other complex test) ((another thing) || (still more))) I think it's more readable to do: bool answerOfTest1 = some complex text bool answerOfTest2 = some other complexTest … if (answerOfTest1 answerOftest2 …) The compiler will get rid of the bool vars, although you might force evaluation of more terms depending on how smart you the optimiser is, but you force yourself to give each boolean expression a name, like 'isWithinOverflightDistance' or 'isWithinInterceptAngle'. As a result it becomes much easier for someone else to evaluate the conditional logic and decide if they agree with it or not. If the boolean test is used more than once, make it into a helper method - grep-ing for methods names is*() and has*() in the codebase points to many of these. In general it looks pretty good though, let me know if you're happy to make the above changes or need any help (especially if you're new to git rebase -i, it can do terrible things) I understand and will make the improvements. Thx for the hind ! I squash the commit and improve readability. Is there any code convention documentation ? Which I could read? Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
On 1 Oct 2013, at 22:34, Dirk Dittmann dirk.dittmann@gmail.com wrote: I understand and will make the improvements. Thx for the hind ! I squash the commit and improve readability. Is there any code convention documentation ? Which I could read? No, there's rules, since the codebase contains quite a mixture. We could start a wiki page, only things I really care about: m_ or _ prefix for members (_prefix is widely used but technically illegal by ISO C++, m_ is my slight preference now) fully brace conditions, even single line. This one is a pain but we've had several bugs with nested ifs-without-braces being modified and introducing logic errors. In several cases people forgot C++ is not Python: if (you do this) if (you keep do thing) if (you then do this) printf(terrible things can happen); else printf(This is not python!); :) I personally prefer lowerCamelCaseWithoutUnderscores for method and variable names, but you will find plenty of other places in the code which use all_lower_case - usually try to follow the style of the code you're working in/near. Regarding naming, longer names and fewer comments are better. Don't do: double m_vXr; /// the velocity tachyon flux better do: double m_velocityTachyonFlux; Of course only people with auto-completing editors agree with this! Shorter names are fine for locals or arguments but still aim to be descriptive. Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
On 30 Sep 2013, at 08:47, Dirk Dittmann dirk.dittmann@gmail.com wrote: Improved the Cross track error according to the great circle. http://williams.best.vwh.net/avform.htm#XTE. Great,. And make the overflight sequence configurable for the aircraft. The default is the same. /instrumentation/gps/config/over-flight-arm-angle-deg 90 /instrumentation/gps/config/over-flight-arm-distance-nm 1 /instrumentation/gps/config/over-flight-distance-nm 0 over-flight-distance-nm : - distance to waypoint - overflight - next waypoint over-flight-arm-distance-nm: - distance to waypoint over-flight-distance-nm + over-flight-arm-distance-nm - overflight arms the cone over-flight-arm-angle-deg : - the cone left/right from LEG pointing on the waypoint - when armed and the aircraft leafs the cone - next waypoint. Great, although I do wonder if anyone will ever really adjust the cone angle. Doesn't do any harm though. branche fix-issue1164 @ my clone https://gitorious.org/fg/dirks-flightgear/source/85592ec45db2866a15197c051d97cb4014537b4b: Who should I ask for merge ? Me, only query is that the above don't really seem to relate to issue 1164, which is about initial behaviour of the GPS when entering leg mode away from the active leg. Are you happy for me to pull from that branch to review, or would you rather send a patch, or make a merge request on Gitorious. All of those are fine with me, your choice. Regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
Am Montag, 30. September 2013, 09:00:19 schrieb James Turner: On 30 Sep 2013, at 08:47, Dirk Dittmann dirk.dittmann@gmail.com wrote: Improved the Cross track error according to the great circle. http://williams.best.vwh.net/avform.htm#XTE. Great,. And make the overflight sequence configurable for the aircraft. The default is the same. /instrumentation/gps/config/over-flight-arm-angle-deg 90 /instrumentation/gps/config/over-flight-arm-distance-nm 1 /instrumentation/gps/config/over-flight-distance-nm 0 over-flight-distance-nm : - distance to waypoint - overflight - next waypoint over-flight-arm-distance-nm: - distance to waypoint over-flight-distance-nm + over-flight-arm-distance-nm - overflight arms the cone over-flight-arm-angle-deg : - the cone left/right from LEG pointing on the waypoint - when armed and the aircraft leafs the cone - next waypoint. Great, although I do wonder if anyone will ever really adjust the cone angle. Doesn't do any harm though. The over flight sequence has nothing to do with the fix its a goody. Yes no harm, it was there(90°) I just bring it out to the aircraft. branche fix-issue1164 @ my clone https://gitorious.org/fg/dirks-flightgear/source/85592ec45db2866a15197c051 d97cb4014537b4b: Who should I ask for merge ? Me, only query is that the above don't really seem to relate to issue 1164, which is about initial behaviour of the GPS when entering leg mode away from the active leg. I remind the leg course was a bearing from aircraft to waypoint, calculated once at init. Now the target course is the leg. It tries to intercept(below 45°) or going direct to waypoint. Are you happy for me to pull from that branch to review, or would you rather send a patch, or make a merge request on Gitorious. All of those are fine with me, your choice. Im happy when you pull, less to me ;) Regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
It actually does solve issue 1164 (which I started). When one switches to the next waypoint, the active leg course and x-track-error relate to the leg between the previous and active waypoint of the flightplan (as it should in LEG mode). Previously the leg (-course and x-track-error) was formed between the active waypoint and the position of the aircraft at the moment of switching. The other stuff I asked Dirk to add as it makes our extra500 (GPSS) AP design a lot easier. Cheers, Eric From: zakal...@mac.com Date: Mon, 30 Sep 2013 09:00:19 +0100 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] GPS - merge request On 30 Sep 2013, at 08:47, Dirk Dittmann dirk.dittmann@gmail.com wrote:Improved the Cross track error according to the great circle. http://williams.best.vwh.net/avform.htm#XTE. Great,. And make the overflight sequence configurable for the aircraft. The default is the same./instrumentation/gps/config/over-flight-arm-angle-deg 90/instrumentation/gps/config/over-flight-arm-distance-nm 1/instrumentation/gps/config/over-flight-distance-nm 0over-flight-distance-nm : - distance to waypoint - overflight - next waypointover-flight-arm-distance-nm: - distance to waypoint over-flight-distance-nm + over-flight-arm-distance-nm- overflight arms the cone over-flight-arm-angle-deg : - the cone left/right from LEG pointing on the waypoint- when armed and the aircraft leafs the cone - next waypoint. Great, although I do wonder if anyone will ever really adjust the cone angle. Doesn't do any harm though. branche fix-issue1164 @ my clonehttps://gitorious.org/fg/dirks-flightgear/source/85592ec45db2866a15197c051d97cb4014537b4b:Who should I ask for merge ? Me, only query is that the above don't really seem to relate to issue 1164, which is about initial behaviour of the GPS when entering leg mode away from the active leg. Are you happy for me to pull from that branch to review, or would you rather send a patch, or make a merge request on Gitorious. All of those are fine with me, your choice. Regards,James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
On 30 Sep 2013, at 12:29, Eric van den Berg evan_den_b...@hotmail.com wrote: It actually does solve issue 1164 (which I started). When one switches to the next waypoint, the active leg course and x-track-error relate to the leg between the previous and active waypoint of the flightplan (as it should in LEG mode). Previously the leg (-course and x-track-error) was formed between the active waypoint and the position of the aircraft at the moment of switching. Okay, the issue then is the behaviour with GPSs which build an 'entry leg' when activating but off-route, which was the intended behaviour of the current code. I'm fine with supporting both, the question is if we really need a distinct intercept mode for leg, and indeed radial, capture in the GPS, and a config option to control how that works. The other stuff I asked Dirk to add as it makes our extra500 (GPSS) AP design a lot easier. Yes, no problem. BTW Dirk I would prefer separate commits for these areas of course. Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
On 30 Sep 2013, at 12:29, Eric van den Berg evan_den_b...@hotmail.com wrote: The other stuff I asked Dirk to add as it makes our extra500 (GPSS) AP design a lot easier. Incidentally if you (Dirk) are looking at this code, the really great thing would be to get the turn-anticipation code enabled. All the pieces are there (compute a standard rate turn based on inbound / outbound leg courses, compute time before WPT to start turning based on ground-speed), but it's always been disabled because I couldn't figure out a stable formula for CDI deviation / XTK in the turn, and especially when transitioning between turn-anticipation and normal leg modes. (So there was an ugly wobble when turn anticipation starts and ends, with the AP did not like). Any comments, or contributions to this, would be great, since a few people have ended up implementing kludges at turn-anticipation in Nasal, when this code should really do it all from C++ nicely. Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
To be honest I did not put any CDI in (yet). And it is coded in JSBSim, not Nasal (want to keep the plane flyable on my not so top-of-the-notch computer). I just turn the aircraft for a certain period of time (based on groundspeed, turn rate, ground track, nex leg course) and than switch over to the next leg. I also put some 'lead-in' time in as the AC wont be at the defined turn rate instantly. The AC then ends up very close to the leg-track, with the nose pointing in the right direction. The AP adjustment if needed is relatively subtle. Eric From: zakal...@mac.com Date: Mon, 30 Sep 2013 12:52:08 +0100 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] GPS - merge request On 30 Sep 2013, at 12:29, Eric van den Berg evan_den_b...@hotmail.com wrote:The other stuff I asked Dirk to add as it makes our extra500 (GPSS) AP design a lot easier. Incidentally if you (Dirk) are looking at this code, the really great thing would be to get the turn-anticipation code enabled. All the pieces are there (compute a standard rate turn based on inbound / outbound leg courses, compute time before WPT to start turning based on ground-speed), but it's always been disabled because I couldn't figure out a stable formula for CDI deviation / XTK in the turn, and especially when transitioning between turn-anticipation and normal leg modes. (So there was an ugly wobble when turn anticipation starts and ends, with the AP did not like). Any comments, or contributions to this, would be great, since a few people have ended up implementing kludges at turn-anticipation in Nasal, when this code should really do it all from C++ nicely. Kind regards,James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS - merge request
Am Montag, 30. September 2013, 12:52:08 schrieb James Turner: On 30 Sep 2013, at 12:29, Eric van den Berg evan_den_b...@hotmail.com wrote: The other stuff I asked Dirk to add as it makes our extra500 (GPSS) AP design a lot easier. Incidentally if you (Dirk) are looking at this code, the really great thing would be to get the turn-anticipation code enabled. All the pieces are there (compute a standard rate turn based on inbound / outbound leg courses, compute time before WPT to start turning based on ground-speed), but it's always been disabled because I couldn't figure out a stable formula for CDI deviation / XTK in the turn, and especially when transitioning between turn-anticipation and normal leg modes. (So there was an ugly wobble when turn anticipation starts and ends, with the AP did not like). my first thought is a fade in?/out XTK leg1 --fade-- XTK turn --fade-- XTK leg2 | switch next WPT Any comments, or contributions to this, would be great, since a few people have ended up implementing kludges at turn-anticipation in Nasal, when this code should really do it all from C++ nicely. Kind regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS find nearest.
Well, since this was a GPS-related thread, I decided to post this here instead of creating another thread :-) The zkv500's Turnpoint screen works properly now. However, the navigation display won't show the distance to the waypoint. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS find nearest.
Thank you pointing this, I haven't seen it. Here is the patch to correct the mistake. Thanks in advance to commit it. best regards seb Victhor Foster wrote : Well, since this was a GPS-related thread, I decided to post this here instead of creating another thread :-) The zkv500's Turnpoint screen works properly now. However, the navigation display won't show the distance to the waypoint. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Index: Aircraft/Instruments-3d/zkv500/MainScreens.nas === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/Instruments-3d/zkv500/MainScreens.nas,v retrieving revision 1.9 diff -r1.9 MainScreens.nas 223c223 dist * dist_conv[0][dist_unit], --- me.waypoint.getNode(distance-nm,1).getValue() * dist_conv[0][dist_unit], 227c227 me.waypoint.getNode(course-error-nm).getValue() * dist_conv[0][dist_unit], --- dist * dist_conv[0][dist_unit], -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS find nearest.
On 10 Dec 2009, at 21:41, Scott Hamilton wrote:
I can't seem to find it in airportinfo(), this is what debug.dump shows;
{ id: 'YMML', elevation: 131.97839, lat: -37.66986124, name:
'Melbourne Intl', has_metar: 1, lon: 144.842831907, runways: {
16: { id: 16, stopway: 60.045599, heading: 171.6, lat: -37.669491,
width: 45.1104, lon: 144.837952999, length: 3661.5624, threshold: 0 },
H2: { id: 'H2', stopway: 0, heading: 260.57999, lat:
-37.684215, width: 34.137599, lon: 144.856781, length:
34.137599, threshold: 0 },
H3: { id: 'H3', stopway: 0, heading: 206.95999, lat:
-37.664935, width: 34.137599, lon: 144.850311, length:
34.137599, threshold: 0 },
09: { id: 09, stopway: 60.045599, heading: 94.20, lat:
-37.661513, width: 45.1104, lon: 144.83517, length:
2278.98960001, threshold: 0 },
34: { id: 34, stopway: 60.045599, heading: 351.6, lat: -37.669491,
width: 45.1104, lon: 144.837952999, length: 3661.5624, threshold: 0 },
27: { id: 27, stopway: 60.045599, heading: 274.20999, lat:
-37.661513, width: 45.1104, lon: 144.83517, length:
2278.98960001, threshold: 0 },
H1: { id: 'H1', stopway: 0, heading: 260.57999, lat: -37.675007,
width: 34.137599, lon: 144.844390999, length: 34.137599,
threshold: 0 }
} }
Whoops, you are quite correct.
However, I shall now *add* that information to airportinfo :)
(One of the outcomes of the past year's navaids / airports work, is that
runways now have a reference to their associated ILS/LOC, so getting the
frequency is trivial)
James
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS find nearest.
Hi James,
thank you very much for your changes, here is the very first step of a
vor-to-vor flightplan builder. Let me improve it for more functions and
capacities.
best regards,
seb
James Turner a ecrit :
On 9 Dec 2009, at 13:47, Scott Hamilton wrote:
Something I was playing around with a few months back I thought, if only I
could find the nearest VOR/NDB/FIX/APT to
some point that I am not at but will be in the near future, unfortunately
I've forgotten what it was I was trying to do,
but I'm sure it was a good idea ;)
Yep, agreed, it's an obvious thing to support. And easy to do, as well!
Off-topic is there anyway in Nasal to find the ILS frequencies and optionally
the name, for a particular airport and runway?
Yes, the airportinfo function returns you a Nasal hash with all this and more.
Also, although it's not exposed in the current GPS GUI dialog, when you search
for an airport, the GPS scratch data contains the runways, including ILS
frequencies, headings and names. You can see them in the property browser.
James
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
var gps = props.globals.getNode(/instrumentation/gps/, 1);
var cmd = gps.getNode(command, 1);
var scratch = gps.getNode(scratch);
var flightplan = gps.getNode(flightplan, 1);
scratch.getNode(exact, 1).setBoolValue(0);
var searchType = scratch.getNode(type, 1);
var searchQuery = scratch.getNode(query, 1);
var searchMax = scratch.getNode(max-results, 1);
var flightplan_vector = [];
var copy_wp_infos = func (orig, dest) {
var nodelist = [latitude-deg, longitude-deg, name, ident,
altitude-ft, frequency-mhz]; #TODO frequency for NDB in kHz
foreach (var n; nodelist) {
var o = orig.getNode(n);
o != nil or continue;
dest[n] = o.getValue();
}
}
var build = func (from, to) {
var target_lat = from[latitude-deg] + ((to[latitude-deg] -
from[latitude-deg])/2);
var target_lon = from[longitude-deg] + ((to[longitude-deg] -
from[longitude-deg])/2);
scratch.getNode(latitude-deg).setDoubleValue(target_lat);
scratch.getNode(longitude-deg).setDoubleValue(target_lon);
searchType.setValue(vor);
searchMax.setIntValue(1);
cmd.setValue(nearest);
var wp = {};
copy_wp_infos(scratch, wp);
var wpcoords = geo.Coord.new().set_latlon(wp[latitude-deg],
wp[longitude-deg]);
var fromcoords = geo.Coord.new().set_latlon(from[latitude-deg],
from[longitude-deg]);
var tocoords = geo.Coord.new().set_latlon(to[latitude-deg],
to[longitude-deg]);
#var dist_to = wpcoords.distance_to(tocoords);
#printf(%s - %s dist_to %s, wp[ident], to[ident], dist_to);
#dist_to 18520 or return;
wpcoords.distance_to(tocoords) 18520 or return;
#var dist_from = wpcoords.distance_to(fromcoords);
#printf(%s - %s dist_from %s, from[ident], wp[ident], dist_to);
#dist_from 18520 or return;
wpcoords.distance_to(fromcoords) 18520 or return;
build(from, wp);
append(flightplan_vector, wp);
build(wp, to);
}
var new_flightplan = func {
flightplan_vector = [];
print(LFBT-LFPT);
searchType.setValue(airport);
searchQuery.setValue(lfbt);
cmd.setValue(search);
var departure = {};
copy_wp_infos(scratch, departure);
searchType.setValue(airport);
searchQuery.setValue(lfpt);
cmd.setValue(search);
var destination = {};
copy_wp_infos(scratch, destination);
print(building flightplan);
if (departure[latitude-deg] -9990.0 or destination[latitude-deg]
-9990.0) {
print(I need some yoga exercices...);
return;
}
append(flightplan_vector, departure);
build(departure, destination);
append(flightplan_vector, destination);
for (var i = 0; i size(flightplan_vector); i += 1) {
foreach (var k; keys(flightplan_vector[i])) {
var content = flightplan_vector[i][k];
var n = flightplan.getNode(wp[ ~ i ~ ]/ ~ k, 1);
if (k == name or k == ident)
n.setValue(content);
else
n.setDoubleValue(content);
}
}
print(flightplan complete);
}
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS find nearest.
On Wed, 2009-12-09 at 13:54 +, James Turner wrote:
Off-topic is there anyway in Nasal to find the ILS frequencies and
optionally the name, for a particular airport and runway?
Yes, the airportinfo function returns you a Nasal hash with all this and more.
I can't seem to find it in airportinfo(), this is what debug.dump
shows;
{ id: 'YMML', elevation: 131.97839, lat: -37.66986124, name:
'Melbourne Intl', has_metar: 1, lon: 144.842831907, runways: {
16: { id: 16, stopway: 60.045599, heading: 171.6, lat:
-37.669491, width: 45.1104, lon: 144.837952999, length: 3661.5624,
threshold: 0 },
H2: { id: 'H2', stopway: 0, heading: 260.57999, lat:
-37.684215, width: 34.137599, lon: 144.856781, length:
34.137599, threshold: 0 },
H3: { id: 'H3', stopway: 0, heading: 206.95999, lat:
-37.664935, width: 34.137599, lon: 144.850311, length:
34.137599, threshold: 0 },
09: { id: 09, stopway: 60.045599, heading: 94.20,
lat: -37.661513, width: 45.1104, lon: 144.83517, length:
2278.98960001, threshold: 0 },
34: { id: 34, stopway: 60.045599, heading: 351.6, lat:
-37.669491, width: 45.1104, lon: 144.837952999, length: 3661.5624,
threshold: 0 },
27: { id: 27, stopway: 60.045599, heading: 274.20999,
lat: -37.661513, width: 45.1104, lon: 144.83517, length:
2278.98960001, threshold: 0 },
H1: { id: 'H1', stopway: 0, heading: 260.57999, lat: -37.675007,
width: 34.137599, lon: 144.844390999, length:
34.137599, threshold: 0 }
} }
I'll try out GPS nearest scratch area next...
S.
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS find nearest.
On Wed, 2009-12-09 at 08:27 +, James Turner wrote: I second this. Something I was playing around with a few months back I thought, if only I could find the nearest VOR/NDB/FIX/APT to some point that I am not at but will be in the near future, unfortunately I've forgotten what it was I was trying to do, but I'm sure it was a good idea ;) Off-topic is there anyway in Nasal to find the ILS frequencies and optionally the name, for a particular airport and runway? S. On 9 Dec 2009, at 00:25, Sébastien MARQUE wrote: I've got an suggestion for the gps code: a command nearest-coord (or better name) which would give nearest navaid for arbitrary coordinates, given by scratch/longitude-deg and scratch/latitude-deg. It will allow to implement a simple navaid-to-navaid flight-plan in a FG session. I tried already months ago, but I can't get it to work properly. This doesn't even need a new command - I shall just update the code so that if you optionally set a valid lat/lon when executing 'nearest', it uses that position instead of the current GPS position. I will hopefully get this into CVS today. If it's useful, there's several commands that could be updated to have this behaviour. Regards, James -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS find nearest.
On 9 Dec 2009, at 13:47, Scott Hamilton wrote: Something I was playing around with a few months back I thought, if only I could find the nearest VOR/NDB/FIX/APT to some point that I am not at but will be in the near future, unfortunately I've forgotten what it was I was trying to do, but I'm sure it was a good idea ;) Yep, agreed, it's an obvious thing to support. And easy to do, as well! Off-topic is there anyway in Nasal to find the ILS frequencies and optionally the name, for a particular airport and runway? Yes, the airportinfo function returns you a Nasal hash with all this and more. Also, although it's not exposed in the current GPS GUI dialog, when you search for an airport, the GPS scratch data contains the runways, including ILS frequencies, headings and names. You can see them in the property browser. James -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS
You need to use the Route Manager dialog. The route will only activate once the aircraft is airborne. Look at the GPS dialog. If you see that the destination airport on the current leg is your departure airport, go back to the route manager, search for your destination's ICAO code, then press DTO. Hello James , Just tried the b1900d after a long while , and I have no idea how to use my own KLN90B anymore ... any pointers on how I can fix this ? In particular , I cant set the destination waypoint , though it appears with a search. Thanks. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS
On 16 Nov 2009, at 08:53, Victhor Foster wrote: You need to use the Route Manager dialog. The route will only activate once the aircraft is airborne. Uh, I hope not :) That's not the intended behaviour, and it's not what I see. Indeed, I normally activate the route before I taxi out to the active runway. Look at the GPS dialog. If you see that the destination airport on the current leg is your departure airport, go back to the route manager, search for your destination's ICAO code, then press DTO. This is a bug, the code is not detecting when you enter the departure runway reliably. As you noted, the easiest fix is to 'DTO' the first waypoint in the route after the departure airport. You don't need to search though - in the GPS dialog, hit 'active route waypt', which should select the current waypoint, use prev/next to select the desired waypt (i.e press next once) and hit 'DTO'. Regards, James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS
On 16 Nov 2009, at 07:43, syd adams wrote: Just tried the b1900d after a long while , and I have no idea how to use my own KLN90B anymore ... any pointers on how I can fix this ? In particular , I cant set the destination waypoint , though it appears with a search. I assume when you talk about setting waypoints and searching, you're referring exclusively to the in-panel KLN90 UI? I.e nothing to do with the generic GPS dialog? In which case, the quick answer is that I need to look at the XML/ Nasal code for the KLN90, and figure out what changes are required. The longer answer is, no-one has (yet) tried to model a physical device using my generic GPS code, but it need to happen (the sooner the better). Right now there is no documentation, and no easy example to follow, because this is new territory - which also means I am anxious that we create some 'good' examples of how things should be done, for other panel authors to follow. There's various requests pending to get the new route-manager/GPS working with some existing aircraft (SenecaII, 787), new aircraft (HHS's 737-300) and now yours. It's a good sign that people actually want to test the new code, so I'll take some time to understand the various panels, fix up some of the existing aircraft, and create some documentation on how things should be done. Regards, James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS
syd adams wrote: Hello James , Just tried the b1900d after a long while , and I have no idea how to use my own KLN90B anymore ... any pointers on how I can fix this ? In particular , I cant set the destination waypoint , though it appears with a search. Thanks. I had a fairly successful flight in the b1900d at the recent TransGear Airways MP event using the new GPS code/dialog, though I didn't attempt to use the Route Manager or program via the KLN90B. This is because I've yet to get totally to grips with the aircraft rather than because I didn't expect them to work. I found the integration with the autopilot pretty good, certainly better than I expected given the recently level of code change. One minor bug was that selecting a NAV ID in the GPS reset the set altitude to the NAV ID height, but didn't update that altitude select on the panel. I think this might be seen as a bug in the GPS code rather than the panel, as that's the one altitude you don't want ;) Would it be better to have the GPS simply not update the altitude set for NAV IDs (rather than airports). Also, I couldn't find a way to set the radial or heading bug within the cockpit, so had to resort to then Autopilot dialog. Was I missing something, or has that still to be implemented? -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS
On 16 Nov 2009, at 11:35, Stuart Buchanan wrote: One minor bug was that selecting a NAV ID in the GPS reset the set altitude to the NAV ID height, but didn't update that altitude select on the panel. I think this might be seen as a bug in the GPS code rather than the panel, as that's the one altitude you don't want ;) Would it be better to have the GPS simply not update the altitude set for NAV IDs (rather than airports). Absolutely. This bug (and many others related to VNAV operations) will be looked at after I commit the airways/procedure support (i.e, 'soon'), because there's some policy decisions that need to be made to ensure sensible interaction with autopilots. In particular, I'm not sure the GPS should ever be setting the autopilot target altitude, since as you noted it's often not what is desired, depending on the loaded flightplan. Also, I couldn't find a way to set the radial or heading bug within the cockpit, so had to resort to then Autopilot dialog. Was I missing something, or has that still to be implemented? I think the knob is on the centre pedestal, but that makes it hard to use (with the mouse) while looking at the cockpit displays, so I usually use the Autopilot dialog myself. James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS
Ok I'll look into it further ... need to learn how to use it before i update the KLN90B... Altitude is set from a separate instrument , not linked to the GPS in any way. As for the EFIS-84 settings , I haven't come across any good refences for the controller, so it can only be set from the dialog for now ... but that's still a work in progress as always... Cheers On 11/16/09, James Turner zakal...@mac.com wrote: On 16 Nov 2009, at 11:35, Stuart Buchanan wrote: One minor bug was that selecting a NAV ID in the GPS reset the set altitude to the NAV ID height, but didn't update that altitude select on the panel. I think this might be seen as a bug in the GPS code rather than the panel, as that's the one altitude you don't want ;) Would it be better to have the GPS simply not update the altitude set for NAV IDs (rather than airports). Absolutely. This bug (and many others related to VNAV operations) will be looked at after I commit the airways/procedure support (i.e, 'soon'), because there's some policy decisions that need to be made to ensure sensible interaction with autopilots. In particular, I'm not sure the GPS should ever be setting the autopilot target altitude, since as you noted it's often not what is desired, depending on the loaded flightplan. Also, I couldn't find a way to set the radial or heading bug within the cockpit, so had to resort to then Autopilot dialog. Was I missing something, or has that still to be implemented? I think the knob is on the centre pedestal, but that makes it hard to use (with the mouse) while looking at the cockpit displays, so I usually use the Autopilot dialog myself. James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS / route-manager landing
Hi, Also, if we have two consistent time_t, why not simply subtract one from the other, ABS it, and voila you have the time difference ? Or am I missing something regarding usage of difftime ? yes. there is no _standard_ mapping of the data type time_t to any standard C/C++ data type. i.e. time_t may be a struct (for instance for compilers which cannot handle 128 bit time_t). One should not guard time.h with an HAVE_WINDOWS_H because time.h is the correct header. See man 2 time, man difftime Cheers Olaf -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS / route-manager landing
James The this fault is fixed. Thanks. To cure the time and difftime under Windows all that is needed is to include time.h Alan _ From: Alan Teeder [mailto:ajtee...@v-twin.org.uk] Sent: 06 October 2009 17:38 To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] GPS / route-manager landing Also VC90 also does not this at line 70 of route_mgr.cxx. :- Compiling... route_mgr.cxx ..\..\..\src\Autopilot\route_mgr.cxx(70) : warning C4355: 'this' : used in base member initializer list ..\..\..\src\Autopilot\route_mgr.cxx(229) : error C3861: 'time': identifier not found ..\..\..\src\Autopilot\route_mgr.cxx(233) : error C3861: 'time': identifier not found ..\..\..\src\Autopilot\route_mgr.cxx(234) : error C3861: 'difftime': identifier not found Build log was saved at file://d:\fg\source\projects\VC90\FlightGear\Win32\Release\BuildLog.htm Alan _ From: Nicolas Quijano [mailto:nquij...@gmail.com] Sent: 06 October 2009 17:22 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] GPS / route-manager landing Hi all, this doesn't build on windows, it can't find the time symbol referenced at line 229 and 233 in route_mgr.cxx. Missing header ? Also, there is a reference to std::strncasecmp in positioned.cxx around line 820, which is also not available in windows (at least, not here). Since it's dealing with c strings, I've added locally an #ifdef WIN32 check which uses_stricmp instead in this case. Don't know how you want to deal with this, Cheers, Nic On Mon, Oct 5, 2009 at 3:59 AM, James Turner zakal...@mac.com wrote: On 5 Oct 2009, at 08:33, Dave wrote: That all sounds like good stuff. I'll try and migrate the KLN89 towards using it and depreciating the dclgps stuff - that should give it some testing. Sounds good to me. I've been going through the KLN89 manual, and there's definitely some more subtle options that will require extra features / flags (off the top of my head, resuming LEG mode from OBS mode, and the ability to DTO without recentering the d-bar). Many things should be achievable with a bit of Nasal glue, obviously I've tried to make simple building block functionality as much as I can. If you think an API or design is poor, or missing a feature, let me know and I'm happy to add it - I'd far rather get the core code sensible, than have each GPS device work around the same bug! In terms of API examples, I will be committing a new GPS dialog, which shows off most of the new features, and will also allow the GPS to be used in aircraft without real hardware, if we want that. I'm also going to create a wiki page for the GPS, to document what it can (and can't do). Regards, James -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS / route-manager landing
Hey all, I also added time.h on my side, in an #ifdef, since it's somehow already included nix side :) That said, why not simply assign 0 to the two time_t rather than a function call ? Then, it's only a matter of dealing with difftime. Don't we already have time (and timing ?) abstracted facilities though SG ? Shouldn't we first use that, or add the necessary abstracted functionality there ? Also, if we have two consistent time_t, why not simply subtract one from the other, ABS it, and voila you have the time difference ? Or am I missing something regarding usage of difftime ? Cheers, Nic On Wed, Oct 7, 2009 at 5:39 AM, James Turner zakal...@mac.com wrote: On 7 Oct 2009, at 10:32, Alan Teeder wrote: James The “this” fault is fixed. Thanks. To cure the time and difftime under Windows all that is needed is to include time.h That's what I'd hoped, thanks for confirming. I would still prefer to use something more robust than the C-library functions, so I'm investigating that, but obviously it's more important to get Windows building again. Regards, James -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS / route-manager landing
Hi all, this doesn't build on windows, it can't find the time symbol referenced at line 229 and 233 in route_mgr.cxx. Missing header ? Also, there is a reference to std::strncasecmp in positioned.cxx around line 820, which is also not available in windows (at least, not here). Since it's dealing with c strings, I've added locally an #ifdef WIN32 check which uses_stricmp instead in this case. Don't know how you want to deal with this, Cheers, Nic On Mon, Oct 5, 2009 at 3:59 AM, James Turner zakal...@mac.com wrote: On 5 Oct 2009, at 08:33, Dave wrote: That all sounds like good stuff. I'll try and migrate the KLN89 towards using it and depreciating the dclgps stuff - that should give it some testing. Sounds good to me. I've been going through the KLN89 manual, and there's definitely some more subtle options that will require extra features / flags (off the top of my head, resuming LEG mode from OBS mode, and the ability to DTO without recentering the d-bar). Many things should be achievable with a bit of Nasal glue, obviously I've tried to make simple building block functionality as much as I can. If you think an API or design is poor, or missing a feature, let me know and I'm happy to add it - I'd far rather get the core code sensible, than have each GPS device work around the same bug! In terms of API examples, I will be committing a new GPS dialog, which shows off most of the new features, and will also allow the GPS to be used in aircraft without real hardware, if we want that. I'm also going to create a wiki page for the GPS, to document what it can (and can't do). Regards, James -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS / route-manager landing
Also VC90 also does not this at line 70 of route_mgr.cxx. :- Compiling... route_mgr.cxx ..\..\..\src\Autopilot\route_mgr.cxx(70) : warning C4355: 'this' : used in base member initializer list ..\..\..\src\Autopilot\route_mgr.cxx(229) : error C3861: 'time': identifier not found ..\..\..\src\Autopilot\route_mgr.cxx(233) : error C3861: 'time': identifier not found ..\..\..\src\Autopilot\route_mgr.cxx(234) : error C3861: 'difftime': identifier not found Build log was saved at file://d:\fg\source\projects\VC90\FlightGear\Win32\Release\BuildLog.htm Alan _ From: Nicolas Quijano [mailto:nquij...@gmail.com] Sent: 06 October 2009 17:22 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] GPS / route-manager landing Hi all, this doesn't build on windows, it can't find the time symbol referenced at line 229 and 233 in route_mgr.cxx. Missing header ? Also, there is a reference to std::strncasecmp in positioned.cxx around line 820, which is also not available in windows (at least, not here). Since it's dealing with c strings, I've added locally an #ifdef WIN32 check which uses_stricmp instead in this case. Don't know how you want to deal with this, Cheers, Nic On Mon, Oct 5, 2009 at 3:59 AM, James Turner zakal...@mac.com wrote: On 5 Oct 2009, at 08:33, Dave wrote: That all sounds like good stuff. I'll try and migrate the KLN89 towards using it and depreciating the dclgps stuff - that should give it some testing. Sounds good to me. I've been going through the KLN89 manual, and there's definitely some more subtle options that will require extra features / flags (off the top of my head, resuming LEG mode from OBS mode, and the ability to DTO without recentering the d-bar). Many things should be achievable with a bit of Nasal glue, obviously I've tried to make simple building block functionality as much as I can. If you think an API or design is poor, or missing a feature, let me know and I'm happy to add it - I'd far rather get the core code sensible, than have each GPS device work around the same bug! In terms of API examples, I will be committing a new GPS dialog, which shows off most of the new features, and will also allow the GPS to be used in aircraft without real hardware, if we want that. I'm also going to create a wiki page for the GPS, to document what it can (and can't do). Regards, James -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS / route-manager landing
Thanks for the reports, I'll try to find some portable solutions to theses issues ... probably involving boost :) Regards, James On 6 Oct 2009, at 17:38, Alan Teeder wrote: Also VC90 also does not ”this” at line 70 of route_mgr.cxx. :- Compiling... route_mgr.cxx ..\..\..\src\Autopilot\route_mgr.cxx(70) : warning C4355: 'this' : used in base member initializer list ..\..\..\src\Autopilot\route_mgr.cxx(229) : error C3861: 'time': identifier not found ..\..\..\src\Autopilot\route_mgr.cxx(233) : error C3861: 'time': identifier not found ..\..\..\src\Autopilot\route_mgr.cxx(234) : error C3861: 'difftime': identifier not found Build log was saved at file://d:\fg\source\projects\VC90\FlightGear\Win32\Release\BuildLog.htm Alan From: Nicolas Quijano [mailto:nquij...@gmail.com] Sent: 06 October 2009 17:22 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] GPS / route-manager landing Hi all, this doesn't build on windows, it can't find the time symbol referenced at line 229 and 233 in route_mgr.cxx. Missing header ? Also, there is a reference to std::strncasecmp in positioned.cxx around line 820, which is also not available in windows (at least, not here). Since it's dealing with c strings, I've added locally an #ifdef WIN32 check which uses_stricmp instead in this case. Don't know how you want to deal with this, -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS / route-manager landing
James Turner wrote: Just a notification / warning - I'm planning to land my GPS / FMS / route-manager re-write tomorrow (Monday). It's not perfect (yet) but already much more usable than the previous code. I'm sure I'll regress a few things initially, but of course I'll work through any issues that people report. snip Hi James, That all sounds like good stuff. I'll try and migrate the KLN89 towards using it and depreciating the dclgps stuff - that should give it some testing. Cheers - Dave -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS / route-manager landing
On 5 Oct 2009, at 08:33, Dave wrote: That all sounds like good stuff. I'll try and migrate the KLN89 towards using it and depreciating the dclgps stuff - that should give it some testing. Sounds good to me. I've been going through the KLN89 manual, and there's definitely some more subtle options that will require extra features / flags (off the top of my head, resuming LEG mode from OBS mode, and the ability to DTO without recentering the d-bar). Many things should be achievable with a bit of Nasal glue, obviously I've tried to make simple building block functionality as much as I can. If you think an API or design is poor, or missing a feature, let me know and I'm happy to add it - I'd far rather get the core code sensible, than have each GPS device work around the same bug! In terms of API examples, I will be committing a new GPS dialog, which shows off most of the new features, and will also allow the GPS to be used in aircraft without real hardware, if we want that. I'm also going to create a wiki page for the GPS, to document what it can (and can't do). Regards, James -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gps?
On 17 Feb 2009, at 00:49, Curtis Olson wrote: At one point I think I recall that we had a variant of the C172 with a working GPS installed in the instrument panel. I don't see that any more now. Does anyone recall if we had such a thing and know where it can be found? I presume you're referring to Dave Luff's KLN89b code. This worked in the 0.9 / 1.0 era, and while no-one has actively broken it (indeed, myself and Tim Moore at least have done various pieces of work solely to keep it alive), I regard it as unmaintained and unused code. Every time I've asked here or on the forums about people using it, I get a negative response. In the medium term, my plan is to completely replace the KLN89 code with the generic GPS instrument (combined with an extended route- manager) but that's a six-month or more project, and stalled until the second week of March. So for the moment, there is no explicit reason (that I'm aware) of why the KLN89 doesn't appear in the C172, but I would expect some (hopefully minor) issues with getting it to work as originally designed. James -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gps?
James Turner wrote: On 17 Feb 2009, at 00:49, Curtis Olson wrote: At one point I think I recall that we had a variant of the C172 with a working GPS installed in the instrument panel. I don't see that any more now. Does anyone recall if we had such a thing and know where it can be found? I presume you're referring to Dave Luff's KLN89b code. This worked in the 0.9 / 1.0 era, and while no-one has actively broken it (indeed, myself and Tim Moore at least have done various pieces of work solely to keep it alive), I regard it as unmaintained and unused code. Every time I've asked here or on the forums about people using it, I get a negative response. In the medium term, my plan is to completely replace the KLN89 code with the generic GPS instrument (combined with an extended route- manager) but that's a six-month or more project, and stalled until the second week of March. So for the moment, there is no explicit reason (that I'm aware) of why the KLN89 doesn't appear in the C172, but I would expect some (hopefully minor) issues with getting it to work as originally designed. James Hi Curt, James, Yes, at one point the KLN89b worked in the 2D C172 panel, but I've heard that's it's now broken. I guess there was a kind of negative feedback loop acting there - as a result of the work I was doing on FG, I got the offer of a coding job at a GPS company, which left me without the time to now work on FG. I'm on holiday today with the kids, but they've gone to their friends and it's raining outside, so I can post emails today though. The code was a very faithful simulation of the KLN89b, based on the downloadable simulator from the manufacturer, about 3/4s finished, including the capability to do non-precision approaches, limited only by the availability of data. If a true-to-life representation of an actual aviation GPS unit is desired in FG then it would a shame to chuck it, since it's probably the best shot at getting one (all the later models are much more complex). Obviously, if no-one's bothered about having that capability, then it's a lot of code to have lying about. I definitely won't be returning to the ATC/AI code or the Taxidraw editor in any meaningful way - there's just too much stuff there and it's too open ended to ever finish, but the KLN89 is probably limited enough in scope, with a definite finish point, that I could be motivated to finish it in the evenings if it's still wanted. At the moment I can't get 3D accel working on my linux box with my GF3 and the latest kernel, so I guess I'll try a windows compile. Would I be correct in assuming that the osg branch is now the main branch, and the way to go? Cheers - Dave -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gps?
I had planned to switch the B1900D over to use that , since my nasal KLN90B is nothing more than a display of the current gps properties but waiting to see whats happening with the KLN89. Cheers -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gps?
Hi, There is a gps in CVS: $FGROOT/Aircraft/Instruments-3d/zkv500, I mean an instrument which looks like a gps for a non-pilot, not-advised user :). This instrument manages routes, looks for airports, saves waypoints (bookmarks), creates routes, give several infos about wind, etc. It uses the /position/*, /environment/* properties and properties from the hard-coded kln89. It is a 5 lines LCD display with retrolight for nigh use, the manual is included in CVS for installation and use. Indeed it is surely not a real gps as trained pilots are used to see and use in aircraft but it could be useful for people wanting to include a gps in their cockpit. I'm as aware as I can about kln89/gps changes in the code, and I will make it compliant with the new system when it will be availble. For now it works quite correctly... but, again, it is still a toy for advanced pilots. Moreover the Nasal code is a bit ugly, but it uses all my skills about :p... best regards seb syd adams a écrit : I had planned to switch the B1900D over to use that , since my nasal KLN90B is nothing more than a display of the current gps properties but waiting to see whats happening with the KLN89. Cheers -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gps?
I have a silly , non FG question what does syd adams a écrit : mean Googling didn't help , and I don't speak french Cheers :) On Tue, Feb 17, 2009 at 9:34 AM, Sébastien MARQUE seb.mar...@free.frwrote: Hi, There is a gps in CVS: $FGROOT/Aircraft/Instruments-3d/zkv500, I mean an instrument which looks like a gps for a non-pilot, not-advised user :). This instrument manages routes, looks for airports, saves waypoints (bookmarks), creates routes, give several infos about wind, etc. It uses the /position/*, /environment/* properties and properties from the hard-coded kln89. It is a 5 lines LCD display with retrolight for nigh use, the manual is included in CVS for installation and use. Indeed it is surely not a real gps as trained pilots are used to see and use in aircraft but it could be useful for people wanting to include a gps in their cockpit. I'm as aware as I can about kln89/gps changes in the code, and I will make it compliant with the new system when it will be availble. For now it works quite correctly... but, again, it is still a toy for advanced pilots. Moreover the Nasal code is a bit ugly, but it uses all my skills about :p... best regards seb syd adams a écrit : I had planned to switch the B1900D over to use that , since my nasal KLN90B is nothing more than a display of the current gps properties but waiting to see whats happening with the KLN89. Cheers -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gps?
Lol... I have a silly , non FG question what does syd adams a écrit : mean Googling didn't help , and I don't speak french Cheers :) It means: Syd Adams wrote... :-) -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gps?
On Tue, Feb 17, 2009 at 9:14 PM, syd adams adams@gmail.com wrote: I have a silly , non FG question what does syd adams a écrit : mean Googling didn't help , and I don't speak french Well, look at the header for the quote above, and try to compare with the ecrit thing :) -- Csaba/Jester who also doesn't speak french -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gps?
sorry guys for that, I forgot to withdraw the accent, btw I haven't found yet where I can change this permanently in my thunderbird config. seb Csaba Halász a ecrit (wrote): On Tue, Feb 17, 2009 at 9:14 PM, syd adams adams@gmail.com wrote: I have a silly , non FG question what does syd adams a écrit : mean Googling didn't help , and I don't speak french Well, look at the header for the quote above, and try to compare with the ecrit thing :) -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gps?
Now that you've explained what ecrit means and I'm sure everyone is pleased to find out it's nothing painful, :-) I don't think you necessarily need to worry about changing your email client. Regards, Curt. On Tue, Feb 17, 2009 at 2:47 PM, Sébastien MARQUE wrote: sorry guys for that, I forgot to withdraw the accent, btw I haven't found yet where I can change this permanently in my thunderbird config. seb Csaba Halász a ecrit (wrote): On Tue, Feb 17, 2009 at 9:14 PM, syd adams adams@gmail.com wrote: I have a silly , non FG question what does syd adams a écrit : mean Googling didn't help , and I don't speak french Well, look at the header for the quote above, and try to compare with the ecrit thing :) -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gps?
Thanks guys :) -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS/FMS/route-manager changes
On Monday 08 December 2008 21:59:53 I wrote: Can't tell whether this is related, but I just noticed a problem with the b1900d's ILS localizer. I tried a little circuit: starting off at EHAM park position B01, taxied to runway 36L, made a 90 deg right, for about a minute, then a 180 right, until I hit the northsea coast, and then made a left to heading 220, approx, following the coast. Over airport Valkenburg (EHVB), I should have intercepted the ILS localizer for EHAM runway 06 (110.55, tuned on radio 1). But this didn't happen. Glideslope was okay. Oh, never mind. I think I figured out what I did wrong. I think I left the VOR1 being slaved to the GPS instead of the NAV1 radio. I retried this pattern again, and everything worked. Cheers, Durk -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS/FMS/route-manager changes
Hi James, On Monday 08 December 2008 11:54:15 James Turner wrote: I would appreciate help on the instrument side - I know Syd has created parts of the KLN90 for the B1900, and I'll keep that working and hopefully enhance it in parallel with the KLN89B work. The two seem to share an awful lot of functionality, so some Nasal reuse is probably possible as well. I've created a wiki page to track the things I'm currently working on: Can't tell whether this is related, but I just noticed a problem with the b1900d's ILS localizer. I tried a little circuit: starting off at EHAM park position B01, taxied to runway 36L, made a 90 deg right, for about a minute, then a 180 right, until I hit the northsea coast, and then made a left to heading 220, approx, following the coast. Over airport Valkenburg (EHVB), I should have intercepted the ILS localizer for EHAM runway 06 (110.55, tuned on radio 1). But this didn't happen. Glideslope was okay. Cheers, Durk -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS update rate
* LeeE -- Monday 14 April 2008: I'm running a nasal loop at 1/(frame-rate/2), which typically works out to between 10-20 Hz, but because the gps update rate is much slower (0.45 sec if I'm interpreting the code correctly) the results aren't very smooth - the effect is that the results follow a sawtooth pattern i.e. they ramp up while the gps output is unchanged but then drop back down when the gps output is updated, and then start to ramp up again. http://autopilot.sourceforge.net/kalman.html Cheers Norman - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS update rate
On Monday 14 April 2008 18:55, Melchior FRANZ wrote: * Curtis Olson -- Monday 14 April 2008: Let's say I want to do a simple moving average ... so the new value is (let's say) 9 parts the previous filtered value + 1 part of the latest sensor reading. Doing that as a simple average though will glitch if your values are coming in around 0/360. FlightGear has an aircraft.angular_lowpass() in $FG_ROOT/Nasal/aircraft.nas. It filters sin() and cos() separately, and builds the angle from that again. Worked well in my tests. m. Ah - that sounds good. Using an exponential filter on heading produced a glitch but as it was resolved so quickly (0.45 sec) it only resulted in a small 'twitch' in flight, in most cases, but I'm sure there would be bigger problems if I was trying to follow an exact 0 deg course. LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS update rate
So summarising the current state of play - research seem to show that gps units can have update rates of 50Hz+ but cost a lot of money. In view of that it seems reasonable to make the FG gps update rate configurable - that was the main purpose of researching it - I didn't want to make it configurable if it wasn't possible to get higher rates in real life. LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS update rate
On Mon, Apr 14, 2008 at 8:38 AM, LeeE wrote: I've been doing some experimentation using the gps instrument for navigation functions but I've hit a minor problem due to the gps instrument update rate. I'm running a nasal loop at 1/(frame-rate/2), which typically works out to between 10-20 Hz, but because the gps update rate is much slower (0.45 sec if I'm interpreting the code correctly) the results aren't very smooth - the effect is that the results follow a sawtooth pattern i.e. they ramp up while the gps output is unchanged but then drop back down when the gps output is updated, and then start to ramp up again. Increasing the gps update rate to 0.1 sec in instrument_mgr helps to smooth the output because each 'tooth' is smaller, with the result that each ramp-up and drop-back is similarly reduced in size. What I was wondering though, is what is the max update rate for NAVSTAR gps receivers? I dug out my Garmin e-trex manual, because I knew that had a battery save mode that reduces the update rate but it only says that the unit will update once per second or 'continuously'. After a bit of digging around on the web I found a discussion where it was stated that The theoretical limit is down to the integration time for the receiver, typically 1-10ms but the practical limit turns out to be more down to the receiver's processing power. Does anyone else here know anything about this? Ideally, I'd like to make the gps update rate configurable - can anyone foresee any problems in doing this? I don't know specific update rates for every device, but my understanding is that a typical consumer handheld device will update every 1-2 seconds. I have a u-blox gps on my UAS and that updates at 4hz. I've seen other gps units that update at 5hz, but I've heard it's almost, but not quite 5, so you end up closer to 4hz anyway. I have seen some trimble differential units that update at 10hz, but those are starting to get really expensive. I wouldn't be surprised to find an inertially augmented system that could report approximate locations at much higher rates. My UAS flight computer computes position estimates at 10hz based on a 4hz gps + gyro accelerometer data. I could probably bump that up to a higher rate if I wanted to. So a true 0.1sec update interval is plausible, but expensive and probably not characteristic of the typical gps you would see on an aircraft. But I could be way off on that ... (?) Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS update rate
On Monday 14 April 2008 15:09, Curtis Olson wrote: On Mon, Apr 14, 2008 at 8:38 AM, LeeE wrote: I've been doing some experimentation using the gps instrument for navigation functions but I've hit a minor problem due to the gps instrument update rate. I'm running a nasal loop at 1/(frame-rate/2), which typically works out to between 10-20 Hz, but because the gps update rate is much slower (0.45 sec if I'm interpreting the code correctly) the results aren't very smooth - the effect is that the results follow a sawtooth pattern i.e. they ramp up while the gps output is unchanged but then drop back down when the gps output is updated, and then start to ramp up again. Increasing the gps update rate to 0.1 sec in instrument_mgr helps to smooth the output because each 'tooth' is smaller, with the result that each ramp-up and drop-back is similarly reduced in size. What I was wondering though, is what is the max update rate for NAVSTAR gps receivers? I dug out my Garmin e-trex manual, because I knew that had a battery save mode that reduces the update rate but it only says that the unit will update once per second or 'continuously'. After a bit of digging around on the web I found a discussion where it was stated that The theoretical limit is down to the integration time for the receiver, typically 1-10ms but the practical limit turns out to be more down to the receiver's processing power. Does anyone else here know anything about this? Ideally, I'd like to make the gps update rate configurable - can anyone foresee any problems in doing this? I don't know specific update rates for every device, but my understanding is that a typical consumer handheld device will update every 1-2 seconds. I have a u-blox gps on my UAS and that updates at 4hz. I've seen other gps units that update at 5hz, but I've heard it's almost, but not quite 5, so you end up closer to 4hz anyway. I have seen some trimble differential units that update at 10hz, but those are starting to get really expensive. I wouldn't be surprised to find an inertially augmented system that could report approximate locations at much higher rates. My UAS flight computer computes position estimates at 10hz based on a 4hz gps + gyro accelerometer data. I could probably bump that up to a higher rate if I wanted to. So a true 0.1sec update interval is plausible, but expensive and probably not characteristic of the typical gps you would see on an aircraft. But I could be way off on that ... (?) Regards, Curt. In the discussion I found (on www.dsprelated.com) one person said they'd seen 20Hz units, but they cost US$2/3K, and they knew of 50Hz units which were much more expensive. Another poster reckoned that he'd been using an automotive unit that seemed to be limited by it's 60MHz 32bit MIPS cpu and maxed out at around 10Hz. I also found an automotive racing company that did 10Hz 20Hz units - no prices but I'd guess they'd be in the several thousand US$ range too. For a pro racing car or military aircraft I'd guess a few thousand US$ is ok but it might be a bit steep for GA. Perhaps another possibility is to use a noise spike filter with a 0.45 resolution time to smooth the output between the 0.45 sec updates but this would mean that the data is always going to be 0.45 sec late. This might be less of a problem than the roughness in the output though - I'll have to play with it. LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS update rate
http://www.k300performance.co.uk/driftbox.htm may be of interest and is a little more affordable, possibly around 1000 of your US dollahs Best Regards Willie Fleming - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS update rate
On Monday 14 April 2008 15:47, LeeE wrote: On Monday 14 April 2008 15:09, Curtis Olson wrote: On Mon, Apr 14, 2008 at 8:38 AM, LeeE wrote: I've been doing some experimentation using the gps instrument for navigation functions but I've hit a minor problem due to the gps instrument update rate. I'm running a nasal loop at 1/(frame-rate/2), which typically works out to between 10-20 Hz, but because the gps update rate is much slower (0.45 sec if I'm interpreting the code correctly) the results aren't very smooth - the effect is that the results follow a sawtooth pattern i.e. they ramp up while the gps output is unchanged but then drop back down when the gps output is updated, and then start to ramp up again. Increasing the gps update rate to 0.1 sec in instrument_mgr helps to smooth the output because each 'tooth' is smaller, with the result that each ramp-up and drop-back is similarly reduced in size. What I was wondering though, is what is the max update rate for NAVSTAR gps receivers? I dug out my Garmin e-trex manual, because I knew that had a battery save mode that reduces the update rate but it only says that the unit will update once per second or 'continuously'. After a bit of digging around on the web I found a discussion where it was stated that The theoretical limit is down to the integration time for the receiver, typically 1-10ms but the practical limit turns out to be more down to the receiver's processing power. Does anyone else here know anything about this? Ideally, I'd like to make the gps update rate configurable - can anyone foresee any problems in doing this? I don't know specific update rates for every device, but my understanding is that a typical consumer handheld device will update every 1-2 seconds. I have a u-blox gps on my UAS and that updates at 4hz. I've seen other gps units that update at 5hz, but I've heard it's almost, but not quite 5, so you end up closer to 4hz anyway. I have seen some trimble differential units that update at 10hz, but those are starting to get really expensive. I wouldn't be surprised to find an inertially augmented system that could report approximate locations at much higher rates. My UAS flight computer computes position estimates at 10hz based on a 4hz gps + gyro accelerometer data. I could probably bump that up to a higher rate if I wanted to. So a true 0.1sec update interval is plausible, but expensive and probably not characteristic of the typical gps you would see on an aircraft. But I could be way off on that ... (?) Regards, Curt. In the discussion I found (on www.dsprelated.com) one person said they'd seen 20Hz units, but they cost US$2/3K, and they knew of 50Hz units which were much more expensive. Another poster reckoned that he'd been using an automotive unit that seemed to be limited by it's 60MHz 32bit MIPS cpu and maxed out at around 10Hz. I also found an automotive racing company that did 10Hz 20Hz units - no prices but I'd guess they'd be in the several thousand US$ range too. For a pro racing car or military aircraft I'd guess a few thousand US$ is ok but it might be a bit steep for GA. Perhaps another possibility is to use a noise spike filter with a 0.45 resolution time to smooth the output between the 0.45 sec updates but this would mean that the data is always going to be 0.45 sec late. This might be less of a problem than the roughness in the output though - I'll have to play with it. LeeE Oops - meant an exponential filter - seems to work ok, except for the inevitable glitch between 360/0 deg (I'm using indicated-track-true-deg) but then it resolves in 0.45 sec, which isn't too bad. The lag affected a couple of controllers but they were easily re-tuned. LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS update rate
On Mon, Apr 14, 2008 at 11:29 AM, LeeE wrote: Oops - meant an exponential filter - seems to work ok, except for the inevitable glitch between 360/0 deg (I'm using indicated-track-true-deg) but then it resolves in 0.45 sec, which isn't too bad. The lag affected a couple of controllers but they were easily re-tuned. So how do you filter/average a heading? I had to think about this on my trip at sea for one of our applications. I came up with a scheme that actually hasn't been well tested; does anyone see any holes in this? Let's say I want to do a simple moving average ... so the new value is (let's say) 9 parts the previous filtered value + 1 part of the latest sensor reading. Doing that as a simple average though will glitch if your values are coming in around 0/360. So instead I looked at the (signed) angular difference between the current filter value and the current sensor reading and normalized that to the -180 to +180 range. Then the new filter value is computed as the old filter value plus 1/10 of this difference. I think that is equivalent. But before I crash any airplanes, can anyone poke any holes in my approach? Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS update rate
* Curtis Olson -- Monday 14 April 2008: Let's say I want to do a simple moving average ... so the new value is (let's say) 9 parts the previous filtered value + 1 part of the latest sensor reading. Doing that as a simple average though will glitch if your values are coming in around 0/360. FlightGear has an aircraft.angular_lowpass() in $FG_ROOT/Nasal/aircraft.nas. It filters sin() and cos() separately, and builds the angle from that again. Worked well in my tests. m. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS update rate
* LeeE -- Monday 14 April 2008: I'm running a nasal loop at 1/(frame-rate/2), which typically works out to between 10-20 Hz, but because the gps update rate is much slower (0.45 sec if I'm interpreting the code correctly) the results aren't very smooth - the effect is that the results follow a sawtooth pattern i.e. they ramp up while the gps output is unchanged but then drop back down when the gps output is updated, and then start to ramp up again. I'd try a variable interval EWMA lowpass like aircraft.lowpass(). m. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS update rate
On Mon, 14 Apr 2008, Melchior FRANZ wrote: * Curtis Olson -- Monday 14 April 2008: Let's say I want to do a simple moving average ... FlightGear has an aircraft.angular_lowpass() in $FG_ROOT/Nasal/aircraft.nas. It filters sin() and cos() separately, and builds the angle from that again. This sounds close to what I was going to suggest - summing/averaging unit vectors. The vectors could proportional to speed if desired. In general, unit vectors are a good way of dealing with circular distributions (they work well for statistical analysis of time-of-day studies, where 2359 and 0001 need to be two minutes apart, not 1338). -- Mike Schuh - Seattle, Washington USA http://www.farmdale.com - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS update rate
On Mon, Apr 14, 2008 at 2:01 PM, Mike Schuh [EMAIL PROTECTED] wrote: On Mon, 14 Apr 2008, Melchior FRANZ wrote: * Curtis Olson -- Monday 14 April 2008: Let's say I want to do a simple moving average ... FlightGear has an aircraft.angular_lowpass() in $FG_ROOT/Nasal/aircraft.nas. It filters sin() and cos() separately, and builds the angle from that again. This sounds close to what I was going to suggest - summing/averaging unit vectors. The vectors could proportional to speed if desired. In general, unit vectors are a good way of dealing with circular distributions (they work well for statistical analysis of time-of-day studies, where 2359 and 0001 need to be two minutes apart, not 1338). -- Mike Schuh - Seattle, Washington USA http://www.farmdale.com - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel How about using a kalman filter with velocity as an input to extract a angular and angular rate signal from some noisy inclination data? I think the down side to it would be the lag, but I think it might work well in the pitch axis. Also; http://www.vboxusa.com/products.php#vb3r2g2 They have some pretty decent update rates. I've seen some demos on some really high end ones which can go at 50hz. Those boxes also come with accelerometers and they do some amount of interpolation during the time a gps signal is not present. to maintain the update rate. I thought they were pretty cool - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
