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
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
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
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:
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?
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
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
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
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
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
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 (
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
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
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
OK so I tried to trick FG several different ways, none of which really work,
I tried to get it to send data to one serial port and receive it on another
that sort of works but after about a minute or so FG just stalls and stops
sending data, and basically stops responding to all command inputs.
So I tried it with the joystick unplugged and nothing changed, FG will
transmit, and it will receive just not at the same time, no matter how I try
to trick it, I can't even get it transmit on one port and receive on another
(using serial). Is it possible that someone can create a fix for this?
Right, as you noticed, it doesn't appear that the generic interface code
is setup to transmit and receive at the same time. You can't open up the
same device twice, so you two command line options won't work either. As
far as I can tell this will require some code modifications if you want to
As far as I can tell this will require some code modifications if you want
to use direct serial communcation.
Yeah I figured that, hmmm I'm not very familiar with FG's source code at
all, and I downloaded the exe, can any of you make a suggestion as to what I
might attempt to correct?
What
Press the / key or it should also be a menu option.
On Mon, Aug 8, 2011 at 10:12 AM, Derrick Washington ddwas...@gmail.comwrote:
As far as I can tell this will require some code modifications if you want
to use direct serial communcation.
Yeah I figured that, hmmm I'm not very familiar
On Sat, 6 Aug 2011 23:09:44 -0400, Derrick wrote in message
CAF74wjbov8xiA26W3_n2EA6HX04B2_8+U6mPn=9votkv8hu...@mail.gmail.com:
OK so I found a solution, I think, I changed the COM port number to
COM3. That seems to work but now FLIGHTGEAR will not accept inputs
for some reason, when I set as
Inputs: what inputs are you sending? Are they getting overwritten by
internal processing? If you are inputting position and orientation (for
instance) you need to turn off the internal flight dynamics engine
(--fdm=null) If you are inputting control surface positions, you probably
don't want a
On Sat, 6 Aug 2011, Derrick Washington wrote:
OK, has anyone actually attempted this method, and got it too work, lol bcus
I just tried it got the bluescreen of death twice. The syntax definitely
does something but it also take the computer down, any suggestions?
Typically when a BSOD
Gene,
Unless you've got 26 other serial ports on that machine, I'd strongly
suggest researching what caused Windows to assign COM27 to your device.
It's NOT typical behavior.
You can assign any number you want to a COM port when it is driven by
a USB-to-COM or Ethernet-to-COM adapter. Simply
On Sun, 7 Aug 2011, Frederic Bouvier wrote:
Gene,
Unless you've got 26 other serial ports on that machine, I'd strongly
suggest researching what caused Windows to assign COM27 to your device.
It's NOT typical behavior.
You can assign any number you want to a COM port when it is driven by
Curt...
I believe I'm just inputting control surface positions, however but I did
have the remote plugged in, I'll make sure to unplug it on my next try.
On Sun, Aug 7, 2011 at 11:10 AM, Curtis Olson curtol...@gmail.com wrote:
Inputs: what inputs are you sending? Are they getting
OK
So I believe I've got it to work on COM27 by using the \\.\COM27 syntax.
I still have a problem sending and receiving at the same time, FG will not
allow me to open up multiple generic serial protocols to the same COM port
for in and out, only one at a time and bi directional doesn't seem to
OK, has anyone actually attempted this method, and got it too work, lol bcus
I just tried it got the bluescreen of death twice. The syntax definitely
does something but it also take the computer down, any suggestions?
On Aug 3, 2011 9:11 PM, Derrick Washington ddwas...@gmail.com wrote:
Ill try
OK so I found a solution, I think, I changed the COM port number to COM3.
That seems to work but now FLIGHTGEAR will not accept inputs for some
reason, when I set as shown below, FG just sits there and spins its wheels.
If I set it up for output that works just fine. In addition to that I can't
-- Forwarded message --
From: Derrick Washington ddwas...@gmail.com
Date: Aug 2, 2011 12:49 AM
Subject: Generic Protocol Error -- Error opening serial device COM27 The
system cannot find the file specified.
To: curtol...@gmail.com
Hi Curt
I have been trying for a few weeks
I personally have never tested the generic protocol over a serial port on
windows. I'm not sure I have tested any IO over a serial port on windows
since the very early days of the project back when we were building with
cygwin. I do recall at the time being (this is maybe 10 years ago at
least?)
On Wed, 3 Aug 2011, Curtis Olson wrote:
I personally have never tested the generic protocol over a serial port on
windows. I'm not sure I have tested any IO over a serial port on windows
since the very early days of the project back when we were building with
cygwin. I do recall at the time
On Wed, Aug 3, 2011 at 8:53 PM, Gene Buckle ge...@deltasoft.com wrote:
COM27 is also a suspicously(sp) high port#.
That seems to be quite normal for usb adapters. However you are right
that this is the cause of the problem.
Quote from msdn:
To specify a COM port number greater than 9, use the
Ill try this see if it works, ill get back to u guys later on this week,
away on vacation now. But thanks for responding, if anyone else know of
sure solution let me know though, but I will be sure to try this out. Oh
yes the com port number is correct, not sure y its that high but it is
33 matches
Mail list logo
