Hello Csaba,

Thanks for that, I have done some experimenting today with the input data with from Pic today,

Using printf("%02x ", ch); it seems the data is intact as long as its normal printables, with a 128 byte hex test block incrementing from 0x00 to 0x7F, it seems from 0x0E to 0x7f is ok, I did not test 0x80 to 0xFF but some chars in that range did send  it nuts before.

Therefore I thing the best option I have without modifying low level drivers elsewhere in FG is come up with a compressed format in printables.

But the issue remains as to why the data is read in to the parse call from the input io stream with "in" on the command line but not "bi"?

Thanks and regards Harry.

On Wed, Mar 25, 2009 at 1:26 AM, Csaba Halász <csaba.halasz@gmail.com> wrote:
On Tue, Mar 24, 2009 at 6:06 PM, Harry Campigli <harrycam2@gmail.com> wrote:
> Thus at the moment,  the process routine calls the parse routine as in
> yesterday, There  I am picking up the number of chars in "buf" from
> "length". In the parse routine then I am testing each char and at the same
> time sending the char to a printf.
> If I test each char, from "buf" I can find 0x5a "Z" but not 0xA5. Futher the
> terminal shows only the printable characters from "buf". However it is a
> steady cycle of the same pintable char data 10 times a sec with the non
> printables missing.

Try using printf("%02x ", ch);


Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
Flightgear-devel mailing list