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 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 is
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 without a problem
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 float. (It
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 ab
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 define fixed
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 should I look
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 convert
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
offsetA/offset
factorB/factor
within your chunk
offset and factor are used like
(output from flightgear): value_on_the_wire =
typeint/type
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
Ok Torsten, let's resume.
You suggest:
Send this as an INT with the generic protocol and use
offsetA/offset
factorB/factor
within your chunk
But then:
typeint/type
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 *
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).
typeint/type
For an input protocol this is the _target_ type. With int your
_string_ is parsed
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 I
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
or
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
accurately.
15 matches
Mail list logo
