Re: [Flightgear-devel] Custom protocol issues

2007-12-04 Thread K. Hoercher
On Sat, 01 Dec 2007 20:46:33 +0100
AnMaster [EMAIL PROTECTED] wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 I'm working on a custom protocol (generic protocol via xml file) for talking
 with a daemon, however I do have some issues:
 
 * How do I make fg send some properties less often than others?
 * How do I make fg only send a property when it changes?
 * How can I send custom strings to the daemon from nasal?
 
 I use udp for the protocol and I really need these features.


Hi,

just to throw out a few more thoughts on that. I stumbled upon roughly
the same set of needs a couple of months ago. I was hacking on some
external fmc sort of thing, which needed to get the basic flight
parameters (such as position, orientation, speeds, eventually engine
settings, you get the picture). The generic protocol lended itself
quite readily to such task.

Problems arose when I wanted to send the needed information for a
tcas/radar-like display, which would need (preferrably configurable)
the pertinent data for all mp/ai aircraft (or perhaps even carriers or
other objects). I did a even more hackish workaround using nasal,
writing to a local file, but clearly missed a feature to do some basic
networking with nasal too.

For preliminary inspection on how to possibly improve the protocol/io
stuff I also looked at the opengc protocol. There I found some changes
needed to get it into working order, and how easy it would be with some
small changes to not rely on that hard-coded module.

Around that time I got distracted by the internal ATC/radar stuff (and
real life too). But up to that time I thought a rewrite of the Protocol
code along the following lines desireable:

- generic enough to substitute the easier ones (opengc, nmea,
lfsglass, atlas, perhaps others too..) with fitting xmlconfigs

- a possibility in the defining xml to specify a class of nodes from
the property tree to be trasmitted
(e.g. /ai/models/aircraft*/callsign). Perhaps even recursive?

- make the actual sending conditional/changeable at runtime (sounds
like getting to nasal style of doing things)

- eventually incorporating some changes suggested here a couple of
weeks ago regarding binary input

While I think the needed changes are to massive to do before the
release, I might give it a try afterwards and would like to solicit
some opinions or comments as to avoid marching off into a completely
unwanted direction. (and I'm constantly fearing the ever creative nasal
gurus coming up with a Oh sure, look here, we've done a couple of
functions, it can now also do this and control your refrigerator as a
bonus *g*)

regards
K. Hoercher

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Custom protocol issues

2007-12-04 Thread AnMaster
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Well my need is this:
I got an advanced joystick (X52 Pro) that got some programmable features. For
example:
* Setting colors of LEDs on buttons (red, yellow or green for most). (19 LEDs in
total!)
* Setting text on the display on the throttle. (3 rows x 16 chars)
* Setting brightness of the backlit display and of the LEDs.
* Setting the built in date and time (including 2 alternative offset timezones
from main time, I would use UTC as main time, and local where you fly as the
second time)

I wrote a daemon that uses libusb to do this and parse the commands as udp
packages, now I need nasal to send the commands as needed. For example:
* If gear is down, show green on that button, yellow if it gear is moving
up/down and red if it is up.
* Same for flaps and speedbrakes and other buttons.
* Show stuff like current speed, heading and such on the display.
  The data shown on the display would be change depending on what
  mode the joystick is in (a 3-state mode selector on the top of
  joystick), what button below the MFD you clicked, and so on.

Doing this with the current custom protocol support turned out as a bad idea
that either caused stutter or didn't provide enough properties. Sending from
nasal would be the SANE way to solve this for me.

Regards,

Arvid Norlander

K. Hoercher wrote:
 On Sat, 01 Dec 2007 20:46:33 +0100
 AnMaster [EMAIL PROTECTED] wrote:
 I'm working on a custom protocol (generic protocol via xml file) for talking
 with a daemon, however I do have some issues:

 * How do I make fg send some properties less often than others?
 * How do I make fg only send a property when it changes?
 * How can I send custom strings to the daemon from nasal?

 I use udp for the protocol and I really need these features.
 
 
 Hi,
 
 just to throw out a few more thoughts on that. I stumbled upon roughly
 the same set of needs a couple of months ago. I was hacking on some
 external fmc sort of thing, which needed to get the basic flight
 parameters (such as position, orientation, speeds, eventually engine
 settings, you get the picture). The generic protocol lended itself
 quite readily to such task.
 
 Problems arose when I wanted to send the needed information for a
 tcas/radar-like display, which would need (preferrably configurable)
 the pertinent data for all mp/ai aircraft (or perhaps even carriers or
 other objects). I did a even more hackish workaround using nasal,
 writing to a local file, but clearly missed a feature to do some basic
 networking with nasal too.
 
 For preliminary inspection on how to possibly improve the protocol/io
 stuff I also looked at the opengc protocol. There I found some changes
 needed to get it into working order, and how easy it would be with some
 small changes to not rely on that hard-coded module.
 
 Around that time I got distracted by the internal ATC/radar stuff (and
 real life too). But up to that time I thought a rewrite of the Protocol
 code along the following lines desireable:
 
 - generic enough to substitute the easier ones (opengc, nmea,
 lfsglass, atlas, perhaps others too..) with fitting xmlconfigs
 
 - a possibility in the defining xml to specify a class of nodes from
 the property tree to be trasmitted
 (e.g. /ai/models/aircraft*/callsign). Perhaps even recursive?
 
 - make the actual sending conditional/changeable at runtime (sounds
 like getting to nasal style of doing things)
 
 - eventually incorporating some changes suggested here a couple of
 weeks ago regarding binary input
 
 While I think the needed changes are to massive to do before the
 release, I might give it a try afterwards and would like to solicit
 some opinions or comments as to avoid marching off into a completely
 unwanted direction. (and I'm constantly fearing the ever creative nasal
 gurus coming up with a Oh sure, look here, we've done a couple of
 functions, it can now also do this and control your refrigerator as a
 bonus *g*)
 
 regards
 K. Hoercher

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHVdkMWmK6ng/aMNkRCsMkAKCjGhCrtWgAdglU/iuXyJqip9Nq0gCfdvZm
31+Uc7dqDvlfTIUGiUhNhf4=
=2qrW
-END PGP SIGNATURE-

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel