Roberto,
> though on the wire I send precisely 7 digit numbers: 3 digits
> followed by a dot and 3 decimal digits);
As you describe correctly, you're transmitting strings (= series of
ASCII characters).
>>> int
For an input protocol this is the _target_ type. With "int" your
_string_ is parsed an
Ok Torsten, let's resume.
You suggest:
> Send this as an INT with the generic protocol and use
> A
> B
> within your
But then:
>> int
> that's the nature of an INT: no fractions at all :-P
I don't see a way out.
- I send an INT to FGFS, the ((value_on_wire * factor) + offset) calculation
get
> int
>
that's the nature of an INT: no fractions at all :-P
Torsten
--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you nee
> You only need a uint8_t (8-bit) variable for the NAV and a uint16_t
> (16bit) variable for the COMM part.
>
> Send this as an INT with the generic protocol and use
> A
> B
> within your
>
> offset and factor are used like
> (output from flightgear): value_on_the_wire = property_value * factor
> You only need a uint8_t (8-bit) variable for the NAV and a uint16_t
> (16bit) variable for the COMM part.
>
> Send this as an INT with the generic protocol and use
> A
> B
> within your
>
> offset and factor are used like
> (output from flightgear): value_on_the_wire = property_value * factor
>
> "Others"? Who? Where in the code should I look for it? What should I search
> for?
>
Me ;-)
But even simpler for the microcontroller: the internal representation neither
khz nor mhz but channel. For the COMM, channel 0 is 118.000 Mhz and channel
759 equals 136.975 MHz. The formula to conve
On Sun, 2011-04-03 at 12:01 +0200, Roberto Inzerillo wrote:
> > One solution others have used is to express the frequency in kHz instead of
> > MHz so use 131925 instead of 131.925 and some nasal magic to copy your kHz
> > value to the MHz value.
> >
> > Ron
>
> "Others"? Who? Where in the code s
On Sun, 2011-04-03 at 12:00 +0200, Roberto Inzerillo wrote:
> >> Well, readme.protocol does not mention a double format, float only;
> >> should I think double is anyway, just undocumented? I should really study
> >> more
> >> C++ and read the code by myself, damn
> >
> > Note, you could also
> One solution others have used is to express the frequency in kHz instead of
> MHz so use 131925 instead of 131.925 and some nasal magic to copy your kHz
> value to the MHz value.
>
> Ron
"Others"? Who? Where in the code should I look for it? What should I search for?
--
GMX DSL Doppel-Flat
>> Well, readme.protocol does not mention a double format, float only;
>> should I think double is anyway, just undocumented? I should really study
>> more
>> C++ and read the code by myself, damn
>
> Note, you could also define "fixed" which is a fixed point integer
> representation of a fl
>> Well, readme.protocol does not mention a double format, float only;
>> should I think double is anyway, just undocumented? I should really study
>> more
>> C++ and read the code by myself, damn
> That's an omission in the documentation, you could define "double"
> instead of "float" with
On Sun, 2011-04-03 at 01:52 +0200, Roberto Inzerillo wrote:
> Well, readme.protocol does not mention a double format, float only; should I
> think double is anyway, just undocumented? I should really study more C++ and
> read the code by myself, damn
Note, you could also define "fixed" which
On Sun, 2011-04-03 at 01:52 +0200, Roberto Inzerillo wrote:
> Well, readme.protocol does not mention a double format, float only; should I
> think double is anyway, just undocumented? I should really study more C++ and
> read the code by myself, damn
That's an omission in the documentation,
On Saturday 02 April 2011 17:52:58 Roberto Inzerillo wrote:
> > It's an issue with the finite precision of floating point variables.
> > Everyone is suprised when first seeing this. Only values which happen to
> > be a sum of "binary fractions" (e.g. 1/2 + 1/4 + 1/8) can be represented
> > accurate
> It's an issue with the finite precision of floating point variables.
> Everyone is suprised when first seeing this. Only values which happen to
> be a sum of "binary fractions" (e.g. 1/2 + 1/4 + 1/8) can be represented
> accurately. Everything else, even simple _decimal_ values such as "0.1"
> Every standby-mhz value Arduino is sending has been previously formatted so
> that it has at most three decimals, something like that: 139.775 or 129.675.
> Problem is FGFS shows /instrumentation/comm/frequencies/standby-mhz as
> 139.7749939 or 129.6750031. There's something wrong with that and
As a followup to Thorsten's suggestion I was fooling around with my Arduino,
making it send a series of fixed lenght float values to FGFS but they got
"corrupted"!?!? How's that?
Ok, to be more precise, Arduino is sending 7 bytes long strings and a constant
int value to FGFS that reads it all u
17 matches
Mail list logo
