Hi Bill, Il 09/09/2015 23:03, Bill Somerville ha scritto: > On 09/09/2015 21:46, Joe Taylor wrote: >> Hi Sandro, >> >> Thanks, as always, for your detailed comments on WSJT-X v1.6.1 r5870. I >> am copying this response to the wsjt-devel list, since some of the >> points you raise may be best answered by another one of us. >> >> On 9/9/2015 1:12 PM, Alessandro Gorobey wrote: >>> Hi Joe, >>> >>> I write directly to your address as probably this considerations are >>> only my errors or misunderstanding. >>> >>> Working in WSJT-X 1.6.1 r5869 or 1.6.0 r5870 under windows compiled by >>> QT 5.5. >>> >>> Starting several times the programs the frequency on startup is red on >>> yellow and show 18.446.744.073.709,550 781 (a space before last 781) >>> The number is all time the some, but I cannot realize where it is >>> created. One second and it disappears, and the cat work well. > This large number is the result of the frequency of zero stored as a > 64-bit unsigned wrapping when a small number is subtracted from it. It > is a transient state that clears when the rig is first polled for the > actual frequency. It should not cause any issues. >>> >>> In if I select two times the some band from band selector it show a >>> number, eg. 00000001, selecting full field is 14.076000000000001, >>> instead of 20m. >>> Note that if change focus to another window the value return to correct >>> 20m. > This looks like a floating point issue, the frequency should be stored > and manipulated throughout as a 64-bit exact unsigned integer number of > Hertz but a few floating point calculations remain that could cause > this. Again this should not cause any issues as the number will be for > display purposes only, the underlying rig control frequencies are > correctly stored. QT 5.2 gcc version 4.8.0 --> show 144.55 contain 144.55 QT 5.5 gcc version 4.9.2 --> show 000001 contain 144.55000000000001 >>> >>> I inserted a new frequency for understand the fast modes. >>> On frequency input the dot is not accepted, but comma is ok. 144.55 is >>> wrong, 144,55 is good sorry, it's the opposite >>> It is not a problem and is caused by program localization, as QT for >>> some field use it. > Are you saying that the frequency input in not correctly localized? I > would expect input to only accept the decimal separator character of the > current system locale. IMPORTANT: it is only a "Easter Egg" of nationalization and not compromises program work. It may be deferred to a far future.
Italian Windows, localization "Italia" (Italy) Output is everywhere correct. Input depend on field. in Settings --> frequencies - frequency calibration, "Intercept" and "Slope" fields: comma give correct results, dot is accepted but skipped in calculation eg. in "Slope": 1,23 --> 1,2300 ppm 1.2,3 --> 12,3000 ppm 12.3 --> 123,0000 ppm - Working frequency o Station Information, "double-click" on Frequency or Offset or mouse-right insert comma is simple refused. Only 0-9 and "dot" are accepted. > > ... > > 73 > Bill > G4WJS. > 73 Sandro IW3RAB > ------------------------------------------------------------------------------ > Monitor Your Dynamic Infrastructure at Any Scale With Datadog! > Get real-time metrics from all of your servers, apps and tools > in one place. > SourceForge users - Click here to start your Free Trial of Datadog now! > http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > ------------------------------------------------------------------------------ Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
