Re: [Flightgear-devel] Default 3d clouds in Local Weather
... and yet another issue: On a first long-range test yesterday, I observed that the cloud base of my convective layer was continuously rising. At takeoff the clouds were exactly as specified, later still plausible given terrain, but by the time the cloudbase had reached my curise altitude of 20.000 ft, I was reasonably certain that this had nothing to do with realistic terrain interaction and must be a bug. Convective cloud altitude determination is quite a complex procedure, and I spent 30 minutes to go through all of it. In the end, I verified that the raw list of alt-ft property values passed to fgcommand(add-cloud, p); is what it should be (in the 8000 ft range) by printing the whole set of 500 values to the console and that /environment/clouds/layer[0]/elevation-ft is set to zero (so that I can compute the absolute altitude of clouds in my routines) while clouds are drawn at 20.000 ft (I have a screenshot of that if needed). My only remaining theory is that /environment/clouds/layer[0]/elevation-ft describes a layer in Cartesian geometry which is attached to the sphere at my startup point. As I fly long distances, the spherical Earth curves away below the flat, uncurved layer, and thus there is an ever-increasing mismatch between zero altitude in (lat,lon,alt) coordinates on the sphere and zero altitude on the layer. This would at least be consistent with what I'm seeing. If so, there probably needs to be a routine which matches Cartesian and spherical geometry periodically... if not, I simply don't know what is wrong. * Thorsten -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
On Tue, 16 Aug 2011, Derrick Washington wrote: One last thing is there a way to ensure that FG is sending out its outputs in floating point format, because I'm not sure it is, I have the generic file setup for binary mode, but I'm not convinced that FG is transmitting data as floats, I think it might actually be transmitting data as integers or something else. I make this observation because the data I did get cause an action in my algorithm which didn't make sense. The auto pilot switched to flight mode while still on the ground, it wasn't susposed to do that until it reached 1800 feet, so thats why I'am assuming that the output it received from FG as the altitude couldn't have been in floating point format it must have been an integer or maybe a double, or something but whatever it was it wasn't a float. The good way to verify if the transmission of float values work is to print the value in your receiver and compare that to the value of the property you transmit in FG. Btw. if your generic protocol is set to use network byte order (endianness MSB) you have to take that into account when unpacking the float value. I looked at the perferences file in the FG directory, and I changed all the double types to float, should that do it? I loaded it under the configuration option in the advanced options menu, but when I started FG back up and hit the / key and looked at the outputs the values still said double. No, don't do that. It should have no influence on this issue. The sender code converts the property value to float before encoding it. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New aircraft: SF-25
Hi guys, Thanks for this. Gary, I gave your yasim xml a spin. (sorry, long mail ahead) I don't have enough experience with the plane yet to comment on everything. The real thing seems to behave a bit better on takeoff when there is no crosswind -- haven't done a crosswind takeoff or landing yet, so I can't comment on that. One problem with the model is that the support wheels shouldn't both touch the ground, they should allow the plane to tilt maybe 10-15 degrees in either direction. They also bend and flex when slammed hard, for shock absorbtion. The airbrakes are definitely not efficient enough. My school sets down that we must always land the Falke with the engine stopped (they had people breaking the plane with powered landings early on, so they forbade it). Therefore we do a very 'glider-style' landing, pretty steep descent at around 60 knots with the spoilers extended all the way, levelling out just above the runway with the spoilers still out. You just release it back a little so you don't accidentally brake and nose over :) More on that later. This way you touch down at around 35-40 knots, but you must continue to hold the spoilers out, otherwise you might get airborne again above 30 (depending on weight which influences stall speed). See some pics of a landing here: http://www.avatarzenekar.hu/files/P1020616.JPG http://www.avatarzenekar.hu/files/P1020617.JPG http://www.avatarzenekar.hu/files/P1020618.JPG So the speedbrakes must be effective enough to be able to do this :) Regarding the speedbrake/brake link and flight controls... The Falke has a fixed prop and no mixture lever. I've read somewhere that the Limbach engine is actually an adopted VW engine, maybe that's why. Apart from the throttle, all you've got is a carb heat lever and on the C model and later, a cowl flap that helps regulate engine temperature (the B has a fixed cover that you install in the winter only). On landing, the spoiler is your primary glidescope control. I have a Saitek Aviator which has a split throttle -- I map one half to the spoiler and that works great. The problem with the config I submitted is that the brakes start working at around 50% travel. Like you said, this is not correct. Please read on for a somewhat long-winded explanation on how it's used in practice: The Falke's fuselage is welded metal tubing covered with canvas. The actual spoilers are spring-loaded and a fair bit of force is required to pull them out (if you'd let go of the lever, they would slam back down quite violently). There are two spoiler levers in the cockpit -- one on the left, and one between the two seats. When you open the spoilers all the way, the left lever hits one if the fuselage tubes (a vertical one). You've got to pull that lever inward slightly to be able to pull it further back and engage the brakes. Only the C version and newer have a parking brake -- which is actually a small, loose lever dangling on the same fuselage tube that can be used to jam the spoiler in the fully open position. This is the best pic I could find that shows this: http://www.alte-ems.de/flugzeuge/sf25c/sf25c_cockpit1.jpg.JPG The spoiler lever handles are blue, the fuselage tubing and the rest of the spoiler lever is grey. If you look carefully on the left of the pic below the placard you can see a little black knob -- that's the parking brake lever. I'll try to remember to take close ups next time I'll go flying. It's all very crude and simple but actually quite clever and efficient way to ensure that you don't land with the wheel locked. But it seems that it still happens sometimes: http://wap.airliners.net/photo/0003212/L/ :) I wish I had the skills to do these animations, but probably the best I can come up with would be a bit of nasal code to link the spoilers and the brakes. I can see that if we made it work like it does in the real thing, that might confuse and piss off FG users, who might expect that the parking brake, brake and spoiler work independently. Personally I'd prefer if they were linked the following way: 1. If you hit the brakes (b key or toe brake pedals, etc), the spoilers would open all the way. This would do for a handy shortcut for full spoilers. 2. If you set the spoiler controls to 80%, the spoilers should be fully open and you should start applying the brake instead (this would be needed for joystick control). 3. If you set the parking brake, that should apply full brake and full spoilers. This should either override any joystick controls, or it's also OK by me if you can't set the parking brake unless you have either set full spoilers or full brakes. 4. Parking brake should be released by using any of the brake or spoiler controls. What do you think? Is this doable? Does this require nasal coding? Cheers, Vik On 08/16/2011 02:25 AM, Gary Neely wrote: Vik, Based on Maik's CG information and a little nosing around for performance information
Re: [Flightgear-devel] New aircraft: SF-25
On Tue, 16 Aug 2011, Viktor Radnai wrote: http://www.avatarzenekar.hu/files/P1020617.JPG http://www.avatarzenekar.hu/files/P1020618.JPG Am I the only one that noticed that someone has been mowing a lawn with that prop? :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
Also with sending/receiving UDP packets, you need to use different ports for the sending and receiving channels. On Tue, Aug 16, 2011 at 2:28 AM, Anders Gidenstam anders-...@gidenstam.orgwrote: On Tue, 16 Aug 2011, Derrick Washington wrote: One last thing is there a way to ensure that FG is sending out its outputs in floating point format, because I'm not sure it is, I have the generic file setup for binary mode, but I'm not convinced that FG is transmitting data as floats, I think it might actually be transmitting data as integers or something else. I make this observation because the data I did get cause an action in my algorithm which didn't make sense. The auto pilot switched to flight mode while still on the ground, it wasn't susposed to do that until it reached 1800 feet, so thats why I'am assuming that the output it received from FG as the altitude couldn't have been in floating point format it must have been an integer or maybe a double, or something but whatever it was it wasn't a float. The good way to verify if the transmission of float values work is to print the value in your receiver and compare that to the value of the property you transmit in FG. Btw. if your generic protocol is set to use network byte order (endianness MSB) you have to take that into account when unpacking the float value. I looked at the perferences file in the FG directory, and I changed all the double types to float, should that do it? I loaded it under the configuration option in the advanced options menu, but when I started FG back up and hit the / key and looked at the outputs the values still said double. No, don't do that. It should have no influence on this issue. The sender code converts the property value to float before encoding it. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New aircraft: SF-25
Haha, that was me taxiing her out for takeoff for the first time! Part of the normal taxiway was cordoned off for some kind of car tuning show (you can see that on the left) and we had to go through slightly longer grass, with some weeds sticking out. That's the great thing about a grass airfield, after a point, the planes will take care of the lawnmowing :D On 08/16/2011 02:29 PM, Gene Buckle wrote: On Tue, 16 Aug 2011, Viktor Radnai wrote: http://www.avatarzenekar.hu/files/P1020617.JPG http://www.avatarzenekar.hu/files/P1020618.JPG Am I the only one that noticed that someone has been mowing a lawn with that prop? :) g. -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
Btw. if your generic protocol is set to use network byte order (endianness MSB) you have to take that into account when unpacking the float value. Huh? Are you saying that if I am using --generic=socket that FG sendings out the data MSB first? Is there a discription on this anywhere so I can read up on any other gotcha's? So if the protocol is set to --generic=serial then how are the values read out? On Tue, Aug 16, 2011 at 3:28 AM, Anders Gidenstam anders-...@gidenstam.orgwrote: On Tue, 16 Aug 2011, Derrick Washington wrote: One last thing is there a way to ensure that FG is sending out its outputs in floating point format, because I'm not sure it is, I have the generic file setup for binary mode, but I'm not convinced that FG is transmitting data as floats, I think it might actually be transmitting data as integers or something else. I make this observation because the data I did get cause an action in my algorithm which didn't make sense. The auto pilot switched to flight mode while still on the ground, it wasn't susposed to do that until it reached 1800 feet, so thats why I'am assuming that the output it received from FG as the altitude couldn't have been in floating point format it must have been an integer or maybe a double, or something but whatever it was it wasn't a float. The good way to verify if the transmission of float values work is to print the value in your receiver and compare that to the value of the property you transmit in FG. Btw. if your generic protocol is set to use network byte order (endianness MSB) you have to take that into account when unpacking the float value. I looked at the perferences file in the FG directory, and I changed all the double types to float, should that do it? I loaded it under the configuration option in the advanced options menu, but when I started FG back up and hit the / key and looked at the outputs the values still said double. No, don't do that. It should have no influence on this issue. The sender code converts the property value to float before encoding it. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
Hi Curt I tried the two different port thing and the single port option, I don't think FG will receive data from a socket if it is not the server, it seems it has to open up the connection and port when receiving data. On Tue, Aug 16, 2011 at 8:37 AM, Curtis Olson curtol...@gmail.com wrote: Also with sending/receiving UDP packets, you need to use different ports for the sending and receiving channels. On Tue, Aug 16, 2011 at 2:28 AM, Anders Gidenstam anders-...@gidenstam.org wrote: On Tue, 16 Aug 2011, Derrick Washington wrote: One last thing is there a way to ensure that FG is sending out its outputs in floating point format, because I'm not sure it is, I have the generic file setup for binary mode, but I'm not convinced that FG is transmitting data as floats, I think it might actually be transmitting data as integers or something else. I make this observation because the data I did get cause an action in my algorithm which didn't make sense. The auto pilot switched to flight mode while still on the ground, it wasn't susposed to do that until it reached 1800 feet, so thats why I'am assuming that the output it received from FG as the altitude couldn't have been in floating point format it must have been an integer or maybe a double, or something but whatever it was it wasn't a float. The good way to verify if the transmission of float values work is to print the value in your receiver and compare that to the value of the property you transmit in FG. Btw. if your generic protocol is set to use network byte order (endianness MSB) you have to take that into account when unpacking the float value. I looked at the perferences file in the FG directory, and I changed all the double types to float, should that do it? I loaded it under the configuration option in the advanced options menu, but when I started FG back up and hit the / key and looked at the outputs the values still said double. No, don't do that. It should have no influence on this issue. The sender code converts the property value to float before encoding it. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
On Tue, 16 Aug 2011, Derrick Washington wrote: Btw. if your generic protocol is set to use network byte order (endianness MSB) you have to take that into account when unpacking the float value. Huh? Are you saying that if I am using --generic=socket that FG sendings out the data MSB first? Is there a discription on this anywhere so I can read up on any other gotcha's? So if the protocol is set to --generic=serial then how are the values read out? I'm saying that if your generic protocol file specifies binary_modetrue/binary_mode byte_ordernetwork/byte_order your receiver (or sender) code also have to use that encoding convention. The encoding used by the generic protocol is independent of the output channel you choose (file, TCP socket, UDP socket, serial port or whatever). If you are unsure about what encoding FG uses for binary data src/Network/generic.cxx is the place to find out. It is pretty much standard for the basic types as far as I know, though. Network order is MSB first (as is host order if your system is big endian but that is not so common these days). If you use host order and both your systems have the same endianness (and you only care about your use case) you don't have to worry about this. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
OK so I have to specify wether or not FG should be using host or network byte order. OK, I don't have the source code I just downloaded the executable, so I'll have to figure out some way of checking it. OK then once I specify this I have to somehow check to see exactly what that order box is using MSB first, or LSB first. BTW in my generic protocol file I didn't not have this specified at all, I wasn't aware that I had to do that, maybe I over looked something, but I haven't seen this before. The battle continues, thanks for your input. On Tue, Aug 16, 2011 at 10:22 AM, Anders Gidenstam anders-...@gidenstam.org wrote: On Tue, 16 Aug 2011, Derrick Washington wrote: Btw. if your generic protocol is set to use network byte order (endianness MSB) you have to take that into account when unpacking the float value. Huh? Are you saying that if I am using --generic=socket that FG sendings out the data MSB first? Is there a discription on this anywhere so I can read up on any other gotcha's? So if the protocol is set to --generic=serial then how are the values read out? I'm saying that if your generic protocol file specifies binary_modetrue/binary_mode byte_ordernetwork/byte_order your receiver (or sender) code also have to use that encoding convention. The encoding used by the generic protocol is independent of the output channel you choose (file, TCP socket, UDP socket, serial port or whatever). If you are unsure about what encoding FG uses for binary data src/Network/generic.cxx is the place to find out. It is pretty much standard for the basic types as far as I know, though. Network order is MSB first (as is host order if your system is big endian but that is not so common these days). If you use host order and both your systems have the same endianness (and you only care about your use case) you don't have to worry about this. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Two strange issues
Two things which might be worth mentioning (both with recent GIT, pulled and compiled ~ a week ago) 1) One of my rendering performance benchmark tests is to use the ufo transport it, using the location dialog, exactly 30.000 ft over the starting position (then increase FOV to 120 deg and create weather and observe framerate). With recent GIT, this leads to an error message from the route manager, and in about 1 of 10 cases to a segmentation fault - hasn't happen before when I did benchmark testing, I can't definitely say since when this is the case. 2) I have the Corse custom scenery http://helijah.free.fr/flightgear/scenes.html#Corse installed under my FG 2.0.0 FGData. With my GIT version, I don't actually have any scenery under FGData but instead use the commandline option --fg-scenery=/usr/share/FlightGear-2.0.0/Scenery/ That works fine everywhere else I can see, *except* for Corse (LFKJ for instance) where I see none of the objects which should be there (works fine with 2.0.0). First obvious thing - the scenery requires models installed under /Models/Region-Corse/ - so I copied that folder into my GIT FGData (and it is readable). Still no objects. What am I missing? * Thorsten -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
On Tue, 16 Aug 2011, Derrick Washington wrote:
OK so I have to specify wether or not FG should be using host or network
byte order. OK, I don't have the source code I just downloaded the
executable, so I'll have to figure out some way of checking it. OK then
once I specify this I have to somehow check to see exactly what that
order box is using MSB first, or LSB first.
BTW in my generic protocol file I didn't not have this specified at all, I
wasn't aware that I had to do that, maybe I over looked something, but I
haven't seen this before. The battle continues, thanks for your input.
If you don't specify byte order, host order will be used. Anything x86 is
very likely to use LSB order (a PC certainly is).
If you post how your code decode the value we might be able to spot the
problem. Have you verified that your code does not receive the
expected value?
Your earlier code, with my correction, should receive float values in
network order (if reading the rs232_uart1 variable really gives you the
next byte from the serial port each time - I would have expected some sort
of handshaking or waiting between the bytes?):
for ( int i = 0; i = 3; i++ )
{ dummy_var = (dummy_var 8) | rs232_uart1; }
return *(float *)dummy_var;
Cheers,
Anders
--
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/
--
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] D-EEQA, the FlightGear C172
On Tue, 16 Aug 2011, Torsten Dreyer wrote: Hi, just for the fun of it - here are 55 pictures of the Cessna's transportation from the tiny airfield of Wahlstedt (EDHW) to my home. http://www.c172fg.de/ That's just awesome. Thanks for the pics! :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
Anders
I have included the following line in my generic xml file
output
binary_modetrue/binary_mode
byte_ordernetwork/byte_order
My C++ code looks like this now.
float gps_vdummy, gps_xdummy, gps_ydummy, gps_zdummy;
if ( (quik_silva_status_reg 0x1000) != 0 ) { //CHECK TO SEE IF
SIMULATOR DATA IS AVAIABLE
gps_vdummy = rs232_uart1_fp;
gps_zdummy = rs232_uart1_fp;
gps_xdummy = rs232_uart1_fp;
gps_ydummy = rs232_uart1_fp;
etc ...
My hardware is returning a 32bit floating point word, in hardware what is
happening is my UART is taking in the bytes one at a time of course and
shifting the into a 32bit register a byte at a time, and returning that
32bit value. S if FG is sending the data MSB(most significant byte
first), then I should be getting the correct value, right?
On Tue, Aug 16, 2011 at 1:37 PM, Anders Gidenstam
anders-...@gidenstam.orgwrote:
On Tue, 16 Aug 2011, Derrick Washington wrote:
OK so I have to specify wether or not FG should be using host or network
byte order. OK, I don't have the source code I just downloaded the
executable, so I'll have to figure out some way of checking it. OK then
once I specify this I have to somehow check to see exactly what that
order box is using MSB first, or LSB first.
BTW in my generic protocol file I didn't not have this specified at all,
I
wasn't aware that I had to do that, maybe I over looked something, but I
haven't seen this before. The battle continues, thanks for your input.
If you don't specify byte order, host order will be used. Anything x86 is
very likely to use LSB order (a PC certainly is).
If you post how your code decode the value we might be able to spot the
problem. Have you verified that your code does not receive the
expected value?
Your earlier code, with my correction, should receive float values in
network order (if reading the rs232_uart1 variable really gives you the
next byte from the serial port each time - I would have expected some sort
of handshaking or waiting between the bytes?):
for ( int i = 0; i = 3; i++ )
{ dummy_var = (dummy_var 8) | rs232_uart1; }
return *(float *)dummy_var;
Cheers,
Anders
--
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/
--
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
?xml version=1.0?
PropertyList
generic
output
binary_modetrue/binary_mode
byte_ordernetwork/byte_order
!-- GPS output of course to allow the plane to actually fly to it's destination, and for some angle calculations --
chunk
nameSpeed/name
node/velocities/airspeed-kt/node
/chunk
chunk
nameAltitude /name
node/position/altitude-ft/node
/chunk
chunk
nameLatitude-deg /name
node/position/latitude-deg/node
/chunk
chunk
nameLongitude-deg (rad)/name
node/position/longitude-deg/node
/chunk
!-- Orientation angular rate outputs to allow my HiL to calculate the orientation angles --
chunk
namePitch rate (deg per sec)/name
node/orientation/pitch-rate-degps/node
/chunk
chunk
nameRoll rate (deg per sec)/name
node/orientation/roll-rate-degps/node
/chunk
chunk
nameYaw Rate (deg per sec )/name
node/orientation/yaw-rate-degps/node
/chunk
!-- Accelerometer magnitude outputs to allow my HiL to calculate the orientation angles --
chunk
nameAccelerometer X (ft per sec)/name
node/accelerations/x-accel-fps_sec/node
/chunk
chunk
nameAccelerometer Y (ft per sec)/name
node/accelerations/y-accel-fps_sec/node
/chunk
chunk
nameAccelerometer Z (ft per sec)/name
node/accelerations/z-accel-fps_sec/node
/chunk
!-- Orientation Angles output for comparason with calculated angles done by my HiL
chunk
nameRoll Angle (deg)/name
node/orientation/roll-deg/node
/chunk
chunk
namePitch Angle (deg)/name
node/orientation/pitch-deg/node
/chunk
chunk
nameYaw Rate (deg)/name
node/orientation/yaw-deg/node
/chunk
--
/output
/generic
/PropertyList--
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and
Re: [Flightgear-devel] [OT] D-EEQA, the FlightGear C172
snip transportation from the tiny airfield of Wahlstedt (EDHW) to my home. snip That looks like it was fun, but will it fit in the basement grin! jj http://kingmont.com -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
Here is my command line set up.
D:\Program Files\FlightGear\bin\Win32\fgfs.exe
--fg-root=D:\Program Files\FlightGear\data
--fg-scenery=D:\Program Files\FlightGear\data\Scenery;D:\Program
Files\FlightGear\scenery;D:\Program Files\FlightGear\terrasync
--airport=CA70
--aircraft=f-14b
--control=joystick
--disable-random-objects
--prop:/sim/rendering/random-vegetation=false
--disable-ai-models
--bpp=32
--generic=serial,out,5,COM3,115200,FlightGear_GPO
--generic=serial,in,5,COM6,115200,FlightGear_GPI
Another very odd thing I've noticed is the FG will not even began to run
unless my board starts transmitting data, it will just sit there and spin
its wheels until the board starts transmitting data. Not sure why that is
happening but no matter what it will sometimes start transmitting and
receiving and then it will just freeze, by the way I'm now running on new
computer with XP not vista just rule out vista. I'm sending and receiving
on two different COM ports and still FG is not cooperating. One or two
things here, either FG simply can not transmit and receive data at the same
time period, or I have some fundamental setup wrong, I'm thinking its the
latter. And yes I'm still getting the wrong values when it actually does
send data in.
2011/8/16 Derrick Washington ddwas...@gmail.com
Anders
I have included the following line in my generic xml file
output
binary_modetrue/binary_mode
byte_ordernetwork/byte_order
My C++ code looks like this now.
float gps_vdummy, gps_xdummy, gps_ydummy, gps_zdummy;
if ( (quik_silva_status_reg 0x1000) != 0 ) { //CHECK TO SEE IF
SIMULATOR DATA IS AVAIABLE
gps_vdummy = rs232_uart1_fp;
gps_zdummy = rs232_uart1_fp;
gps_xdummy = rs232_uart1_fp;
gps_ydummy = rs232_uart1_fp;
etc ...
My hardware is returning a 32bit floating point word, in hardware what is
happening is my UART is taking in the bytes one at a time of course and
shifting the into a 32bit register a byte at a time, and returning that
32bit value. S if FG is sending the data MSB(most significant byte
first), then I should be getting the correct value, right?
On Tue, Aug 16, 2011 at 1:37 PM, Anders Gidenstam
anders-...@gidenstam.org wrote:
On Tue, 16 Aug 2011, Derrick Washington wrote:
OK so I have to specify wether or not FG should be using host or network
byte order. OK, I don't have the source code I just downloaded the
executable, so I'll have to figure out some way of checking it. OK then
once I specify this I have to somehow check to see exactly what that
order box is using MSB first, or LSB first.
BTW in my generic protocol file I didn't not have this specified at all,
I
wasn't aware that I had to do that, maybe I over looked something, but I
haven't seen this before. The battle continues, thanks for your input.
If you don't specify byte order, host order will be used. Anything x86 is
very likely to use LSB order (a PC certainly is).
If you post how your code decode the value we might be able to spot the
problem. Have you verified that your code does not receive the
expected value?
Your earlier code, with my correction, should receive float values in
network order (if reading the rs232_uart1 variable really gives you the
next byte from the serial port each time - I would have expected some sort
of handshaking or waiting between the bytes?):
for ( int i = 0; i = 3; i++ )
{ dummy_var = (dummy_var 8) | rs232_uart1; }
return *(float *)dummy_var;
Cheers,
Anders
--
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/
--
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
OK
So now what I am doing is taking input altitude value (gps_zdummy)
converting it to a integer and sending it to a seven segment display I have
on my board and the values are all over the place sometimes , but most
of the time just skipping around to wild numbers. This tells me that
whatever value I'm getting from FG is either simply incorrect or I'm reading
it in in the wrong order, and I tried switching the network option to host
in the xml file, same result. I'll tell my hardware to store the bytes LSB
first and see what happens. BTW FG is reporting an altitude value of
20.~~~double
On Tue, Aug 16, 2011 at 2:25 PM, Derrick Washington ddwas...@gmail.comwrote:
Here is my command line set up.
D:\Program Files\FlightGear\bin\Win32\fgfs.exe
--fg-root=D:\Program Files\FlightGear\data
--fg-scenery=D:\Program Files\FlightGear\data\Scenery;D:\Program
Files\FlightGear\scenery;D:\Program Files\FlightGear\terrasync
--airport=CA70
--aircraft=f-14b
--control=joystick
--disable-random-objects
--prop:/sim/rendering/random-vegetation=false
--disable-ai-models
--bpp=32
--generic=serial,out,5,COM3,115200,FlightGear_GPO
--generic=serial,in,5,COM6,115200,FlightGear_GPI
Another very odd thing I've noticed is the FG will not even began to run
unless my board starts transmitting data, it will just sit there and spin
its wheels until the board starts transmitting data. Not sure why that is
happening but no matter what it will sometimes start transmitting and
receiving and then it will just freeze, by the way I'm now running on new
computer with XP not vista just rule out vista. I'm sending and receiving
on two different COM ports and still FG is not cooperating. One or two
things here, either FG simply can not transmit and receive data at the same
time period, or I have some fundamental setup wrong, I'm thinking its the
latter. And yes I'm still getting the wrong values when it actually does
send data in.
2011/8/16 Derrick Washington ddwas...@gmail.com
Anders
I have included the following line in my generic xml file
output
binary_modetrue/binary_mode
byte_ordernetwork/byte_order
My C++ code looks like this now.
float gps_vdummy, gps_xdummy, gps_ydummy, gps_zdummy;
if ( (quik_silva_status_reg 0x1000) != 0 ) { //CHECK TO SEE IF
SIMULATOR DATA IS AVAIABLE
gps_vdummy = rs232_uart1_fp;
gps_zdummy = rs232_uart1_fp;
gps_xdummy = rs232_uart1_fp;
gps_ydummy = rs232_uart1_fp;
etc ...
My hardware is returning a 32bit floating point word, in hardware what
is happening is my UART is taking in the bytes one at a time of course and
shifting the into a 32bit register a byte at a time, and returning that
32bit value. S if FG is sending the data MSB(most significant byte
first), then I should be getting the correct value, right?
On Tue, Aug 16, 2011 at 1:37 PM, Anders Gidenstam
anders-...@gidenstam.org wrote:
On Tue, 16 Aug 2011, Derrick Washington wrote:
OK so I have to specify wether or not FG should be using host or
network
byte order. OK, I don't have the source code I just downloaded the
executable, so I'll have to figure out some way of checking it. OK
then
once I specify this I have to somehow check to see exactly what that
order box is using MSB first, or LSB first.
BTW in my generic protocol file I didn't not have this specified at
all, I
wasn't aware that I had to do that, maybe I over looked something, but
I
haven't seen this before. The battle continues, thanks for your input.
If you don't specify byte order, host order will be used. Anything x86 is
very likely to use LSB order (a PC certainly is).
If you post how your code decode the value we might be able to spot the
problem. Have you verified that your code does not receive the
expected value?
Your earlier code, with my correction, should receive float values in
network order (if reading the rs232_uart1 variable really gives you the
next byte from the serial port each time - I would have expected some
sort
of handshaking or waiting between the bytes?):
for ( int i = 0; i = 3; i++ )
{ dummy_var = (dummy_var 8) | rs232_uart1; }
return *(float *)dummy_var;
Cheers,
Anders
--
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/
--
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion
and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
On Tue, 16 Aug 2011, Derrick Washington wrote:
Anders
I have included the following line in my generic xml file
output
binary_modetrue/binary_mode
byte_ordernetwork/byte_order
My C++ code looks like this now.
float gps_vdummy, gps_xdummy, gps_ydummy, gps_zdummy;
if ( (quik_silva_status_reg 0x1000) != 0 ) { //CHECK TO SEE IF
SIMULATOR DATA IS AVAIABLE
gps_vdummy = rs232_uart1_fp;
gps_zdummy = rs232_uart1_fp;
gps_xdummy = rs232_uart1_fp;
gps_ydummy = rs232_uart1_fp;
etc ...
My hardware is returning a 32bit floating point word, in hardware what is
happening is my UART is taking in the bytes one at a time of course and
shifting the into a 32bit register a byte at a time, and returning that
32bit value. S if FG is sending the data MSB(most significant byte
first), then I should be getting the correct value, right?
So rs232_uart1_fp is a floating point variable located at the
address of the UART output register/port or something similar?
Are you sure it supports that (i.e. reading it as a float)? If not could
you try reading the 32bit value into an int variable and reinterpret it
as a float with something like
unsigned int foo = rs232_uart1_u32;
float bar = *(float *)foo;
Also, there is no need to wait before reading the next word from the UART?
Cheers,
Anders - who hasn't programmed an UART since the 68hc11 and late Amiga
days.
--
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
A little background would probably help here. The hardware I am using is my
hardware, I designed it from start to finish, so I'm pretty sure it supports
what I'm doing. Basically its like you said I just stored the float
variable at the address of the UART register, and yes when its gets read its
treated as a float, I looked at the disassemble list and no the software
does not try to convert the value in any way, because it was declared as a
float so it assumes float. And no there isn't any need to wait after a
read, the check I do before I read the UART checks to see if the total
number of bytes I am looking for is actually in the UART, so if it returns
positive, I know that the exact number of words/bytes (however I configure
the hardware) is waiting in the buffer.
On Tue, Aug 16, 2011 at 3:27 PM, Anders Gidenstam
anders-...@gidenstam.orgwrote:
On Tue, 16 Aug 2011, Derrick Washington wrote:
Anders
I have included the following line in my generic xml file
output
binary_modetrue/binary_mode
byte_ordernetwork/byte_order
My C++ code looks like this now.
float gps_vdummy, gps_xdummy, gps_ydummy, gps_zdummy;
if ( (quik_silva_status_reg 0x1000) != 0 ) { //CHECK TO SEE IF
SIMULATOR DATA IS AVAIABLE
gps_vdummy = rs232_uart1_fp;
gps_zdummy = rs232_uart1_fp;
gps_xdummy = rs232_uart1_fp;
gps_ydummy = rs232_uart1_fp;
etc ...
My hardware is returning a 32bit floating point word, in hardware what
is
happening is my UART is taking in the bytes one at a time of course and
shifting the into a 32bit register a byte at a time, and returning that
32bit value. S if FG is sending the data MSB(most significant byte
first), then I should be getting the correct value, right?
So rs232_uart1_fp is a floating point variable located at the
address of the UART output register/port or something similar?
Are you sure it supports that (i.e. reading it as a float)? If not could
you try reading the 32bit value into an int variable and reinterpret it
as a float with something like
unsigned int foo = rs232_uart1_u32;
float bar = *(float *)foo;
Also, there is no need to wait before reading the next word from the UART?
Cheers,
Anders - who hasn't programmed an UART since the 68hc11 and late Amiga
days.
--
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New aircraft: SF-25
Hi all, I have updated the model. Please download and test again if you are interested. http://www.avatarzenekar.hu/files/sf25b.tar.bz2 Many thanks to all especially Gary aka Buckaroo for his yasim xml and explanations. List of changes: - CG supposedly closer to real CG. - More realistic sink rates - Probably more realistic engine RPMs as well (can't remember how good the ones in the last version were) - Brakes now only start working on the last 20% of spoiler travel, as they should do - Working splash screen, yay :) - Incorporated Gary's nasal code snippet for managing the parking brake. List of known issues: - Above mentioned code snippet can't actually test it yet as Shift-B is remapped (d'oh). - Glide properties seem OK, but trim is nose heavy (stick must be pulled most of the time, neutral trim point seems to be near Vne or about 100 knots) - There seems to be some yaw instability at the moment when the tail gear comes off the ground. No idea if this is only in crosswind or not. No idea if the real plane does this in crosswind or not. Pulling the stick slightly during the takeoff run (which you should do anyway) seems to help. Comments from anyone familiar with the type would be very much welcome. Cheers, Vik I can't really follow the discussion on the Yasim internals On 08/16/2011 02:29 PM, Gene Buckle wrote: On Tue, 16 Aug 2011, Viktor Radnai wrote: http://www.avatarzenekar.hu/files/P1020617.JPG http://www.avatarzenekar.hu/files/P1020618.JPG Am I the only one that noticed that someone has been mowing a lawn with that prop? :) g. -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM Comment (was New aircraft: SF-25)
Hi Adrian, On 08/16/2011 12:46 PM, Adrian Musceac wrote: Viktor, During the long hours which have been spent by Emilian and I tweaking the IAR80 FDM, I have found out that three tag parameters have a very heavy influence on the solver: [approach aoa= glide-angle=] and [cruise glide- angle=] Basically if you get these two right your L/D ratio will come inside a usable range. After that you could tweak the other wing parameters like stall etc. I suggest taking a look at the IAR80 for some other ideas. Thanks, tweaking the touchdown AoA was definitely useful. My problem is that I don't have any solid figures for the AoA, so anything I put in there would be a guess. The best clue I could find was that the Falke touches down tail wheel first at around 65-70 km/h. That would require an AoA of about 10-20 degs wouldn't it? But that's not really an approach speed but a good approximation of the stall speed and critical AoA. Would that help the solver? Cheers, Vik -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
OK so this is my latest test.
I took the word from the UART assuming that they were integers, I took the
32bit word converted it to a string and printed that string out to a
terminal. Now in my generic protocol file I am only outputting one variable
now and thats the altitude. The list of numbers that FG is passing back to
me is shown below, looking at the altitude in the menu while FG is running I
see the altitude at some where around 631.77231~ does anyone have a clue why
I'm getting these numbers?
FF3C
FFC4
FFC4
FE4EFFC4
FEC4FFC4
FEFFFE4E
FFC4FFC4
FEFFFE27
FFC4FEFF
27BC
4EBC
FFBEFFC4
FFC4FFBC
BEFF
C4FFBCFF
C4FF67BC
FF4DBCFF
BCFF
FFBCFFBC
FFCDBCFF
67BCFFC4
78FF4DBC
FFCDBCFF
BC3C
FFFDC43C
FFFDFDFD
3CFF3CFF
3CFFC43C
FF3CFFC4
FDFDFD3C
FF4D3CFF
C4FD3CFF
3CFFC4FD
FEFEFEFE
FEC4FEFE
67FEFEFE
67FEFEFE
FEC4F9FE
FEFEC478
FE4CFE27
FEFEFCFE
FE27FE27
FEFCFCC4
FCFCFCC4
FFFC67FE
C4FEFCFE
On Tue, Aug 16, 2011 at 5:08 PM, Derrick Washington ddwas...@gmail.comwrote:
A little background would probably help here. The hardware I am using is
my hardware, I designed it from start to finish, so I'm pretty sure it
supports what I'm doing. Basically its like you said I just stored the
float variable at the address of the UART register, and yes when its gets
read its treated as a float, I looked at the disassemble list and no the
software does not try to convert the value in any way, because it was
declared as a float so it assumes float. And no there isn't any need to
wait after a read, the check I do before I read the UART checks to see if
the total number of bytes I am looking for is actually in the UART, so if it
returns positive, I know that the exact number of words/bytes (however I
configure the hardware) is waiting in the buffer.
On Tue, Aug 16, 2011 at 3:27 PM, Anders Gidenstam
anders-...@gidenstam.org wrote:
On Tue, 16 Aug 2011, Derrick Washington wrote:
Anders
I have included the following line in my generic xml file
output
binary_modetrue/binary_mode
byte_ordernetwork/byte_order
My C++ code looks like this now.
float gps_vdummy, gps_xdummy, gps_ydummy, gps_zdummy;
if ( (quik_silva_status_reg 0x1000) != 0 ) { //CHECK TO SEE IF
SIMULATOR DATA IS AVAIABLE
gps_vdummy = rs232_uart1_fp;
gps_zdummy = rs232_uart1_fp;
gps_xdummy = rs232_uart1_fp;
gps_ydummy = rs232_uart1_fp;
etc ...
My hardware is returning a 32bit floating point word, in hardware what
is
happening is my UART is taking in the bytes one at a time of course and
shifting the into a 32bit register a byte at a time, and returning that
32bit value. S if FG is sending the data MSB(most significant byte
first), then I should be getting the correct value, right?
So rs232_uart1_fp is a floating point variable located at the
address of the UART output register/port or something similar?
Are you sure it supports that (i.e. reading it as a float)? If not could
you try reading the 32bit value into an int variable and reinterpret it
as a float with something like
unsigned int foo = rs232_uart1_u32;
float bar = *(float *)foo;
Also, there is no need to wait before reading the next word from the UART?
Cheers,
Anders - who hasn't programmed an UART since the 68hc11 and late Amiga
days.
--
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
OK
I believe I've found the answer, its the baud rate, FG can't handle
115200, I changed the baud rate to 9600 and now it appears that the values
I'm getting back for the altitude are correct. I'm going to run a more
extensive test on all of the other outputs I need and see what happens.
On Tue, Aug 16, 2011 at 8:50 PM, Derrick Washington ddwas...@gmail.comwrote:
OK so this is my latest test.
I took the word from the UART assuming that they were integers, I took
the 32bit word converted it to a string and printed that string out to a
terminal. Now in my generic protocol file I am only outputting one variable
now and thats the altitude. The list of numbers that FG is passing back to
me is shown below, looking at the altitude in the menu while FG is running I
see the altitude at some where around 631.77231~ does anyone have a clue why
I'm getting these numbers?
FF3C
FFC4
FFC4
FE4EFFC4
FEC4FFC4
FEFFFE4E
FFC4FFC4
FEFFFE27
FFC4FEFF
27BC
4EBC
FFBEFFC4
FFC4FFBC
BEFF
C4FFBCFF
C4FF67BC
FF4DBCFF
BCFF
FFBCFFBC
FFCDBCFF
67BCFFC4
78FF4DBC
FFCDBCFF
BC3C
FFFDC43C
FFFDFDFD
3CFF3CFF
3CFFC43C
FF3CFFC4
FDFDFD3C
FF4D3CFF
C4FD3CFF
3CFFC4FD
FEFEFEFE
FEC4FEFE
67FEFEFE
67FEFEFE
FEC4F9FE
FEFEC478
FE4CFE27
FEFEFCFE
FE27FE27
FEFCFCC4
FCFCFCC4
FFFC67FE
C4FEFCFE
On Tue, Aug 16, 2011 at 5:08 PM, Derrick Washington
ddwas...@gmail.comwrote:
A little background would probably help here. The hardware I am using is
my hardware, I designed it from start to finish, so I'm pretty sure it
supports what I'm doing. Basically its like you said I just stored the
float variable at the address of the UART register, and yes when its gets
read its treated as a float, I looked at the disassemble list and no the
software does not try to convert the value in any way, because it was
declared as a float so it assumes float. And no there isn't any need to
wait after a read, the check I do before I read the UART checks to see if
the total number of bytes I am looking for is actually in the UART, so if it
returns positive, I know that the exact number of words/bytes (however I
configure the hardware) is waiting in the buffer.
On Tue, Aug 16, 2011 at 3:27 PM, Anders Gidenstam
anders-...@gidenstam.org wrote:
On Tue, 16 Aug 2011, Derrick Washington wrote:
Anders
I have included the following line in my generic xml file
output
binary_modetrue/binary_mode
byte_ordernetwork/byte_order
My C++ code looks like this now.
float gps_vdummy, gps_xdummy, gps_ydummy, gps_zdummy;
if ( (quik_silva_status_reg 0x1000) != 0 ) { //CHECK TO SEE IF
SIMULATOR DATA IS AVAIABLE
gps_vdummy = rs232_uart1_fp;
gps_zdummy = rs232_uart1_fp;
gps_xdummy = rs232_uart1_fp;
gps_ydummy = rs232_uart1_fp;
etc ...
My hardware is returning a 32bit floating point word, in hardware what
is
happening is my UART is taking in the bytes one at a time of course and
shifting the into a 32bit register a byte at a time, and returning that
32bit value. S if FG is sending the data MSB(most significant byte
first), then I should be getting the correct value, right?
So rs232_uart1_fp is a floating point variable located at the
address of the UART output register/port or something similar?
Are you sure it supports that (i.e. reading it as a float)? If not could
you try reading the 32bit value into an int variable and reinterpret it
as a float with something like
unsigned int foo = rs232_uart1_u32;
float bar = *(float *)foo;
Also, there is no need to wait before reading the next word from the
UART?
Cheers,
Anders - who hasn't programmed an UART since the 68hc11 and late Amiga
days.
--
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
