[wsjt-devel] Incredible

[Pino Zollo]

I find incredible that WSJT-X can decode two signals on the same
frequency, one very strong and the other very weak

This was tonight on 80m band

0005  -4  0.3 1547 #  ZP4KFX PY2KP 73

0005 -25 -0.2 1545 #  ZP4KFX LU3ADP GF05


...excellent job guys !!

Best 73


Pino ZP4KFX

--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSPR-2 Question about difference of reported frequencies between version 1.6 and 1.7

[Steven Franke]

Hi Jean Louis - 
I believe that the problem is fixed now.
Steve k9an

> On Aug 17, 2016, at 6:08 PM, Steven Franke  wrote:
> 
> Jean Louis,
> I am aware of the problem. I think that this regression was introduced when 
> we did a wholesale switch from double to float in wsprd.c. I will fix this, 
> but it may have to wait til the weekend. 
> Regards,
> Steve k9an
> 
>> On Aug 17, 2016, at 5:48 PM, f5djl  wrote:
>> 
>> Hi Bill 
>> 
>> Totally agree with your analysis but I have so far failed to identify in 
>> wsprd.c  where to make the change ! It must be obvious and I am sure it is 
>> fixable specially as in 1.6  it was ok according to my tests.  I will do a 
>> compare tomorrow or I am sure Steve will point me to the obvious ! 
>> 
>> Best regards 
>> 
>> Jean  Louis  F5DJL 
>> 
>> De : Bill Somerville [mailto:g4...@classdesign.com] 
>> Envoyé : jeudi 18 août 2016 00:35
>> À : wsjt-devel@lists.sourceforge.net
>> Objet : Re: [wsjt-devel] WSPR-2 Question about difference of reported 
>> frequencies between version 1.6 and 1.7
>> 
>> On 17/08/2016 23:28, f5djl wrote:
>>> Clearly from the list below of  RX reported frequency , they are suspicious 
>>>  from 10  m to 23 cm : ie 1296.501465  is reported instead of the expected 
>>> 1296.501500 .
>>> 
>>> 
>>> 
>>> 1296.501465   
>>> 
>> Hi Jean Louis & all,
>> 
>> that error is within the bounds of a single precision floating point 
>> representation discrepancy. The main window UI code and rig control use a 64 
>> bit unsigned integer to represent frequencies to 1Hz resolution. In the 
>> codecs and a few other places where calculations are done on frequencies 
>> single precision floating point variables are used. In this case there seems 
>> to be a case for either double precision or switching to 64-bit unsigned 
>> intergers.
>> 
>> 73
>> Bill
>> G4WJS.
>> 
>> --
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 


--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSPR-2 Question about difference of reported frequencies between version 1.6 and 1.7

[Steven Franke]

Jean Louis,
I am aware of the problem. I think that this regression was introduced when we 
did a wholesale switch from double to float in wsprd.c. I will fix this, but it 
may have to wait til the weekend. 
Regards,
Steve k9an

> On Aug 17, 2016, at 5:48 PM, f5djl  wrote:
> 
> Hi Bill 
>  
> Totally agree with your analysis but I have so far failed to identify in 
> wsprd.c  where to make the change ! It must be obvious and I am sure it is 
> fixable specially as in 1.6  it was ok according to my tests.  I will do a 
> compare tomorrow or I am sure Steve will point me to the obvious ! 
>  
> Best regards 
>  
> Jean  Louis  F5DJL 
>  
> De : Bill Somerville [mailto:g4...@classdesign.com] 
> Envoyé : jeudi 18 août 2016 00:35
> À : wsjt-devel@lists.sourceforge.net
> Objet : Re: [wsjt-devel] WSPR-2 Question about difference of reported 
> frequencies between version 1.6 and 1.7
>  
> On 17/08/2016 23:28, f5djl wrote:
>> Clearly from the list below of  RX reported frequency , they are suspicious  
>> from 10  m to 23 cm : ie 1296.501465  is reported instead of the expected 
>> 1296.501500 .
>> 
>>  
>> 
>> 1296.501465   
>> 
> Hi Jean Louis & all,
> 
> that error is within the bounds of a single precision floating point 
> representation discrepancy. The main window UI code and rig control use a 64 
> bit unsigned integer to represent frequencies to 1Hz resolution. In the 
> codecs and a few other places where calculations are done on frequencies 
> single precision floating point variables are used. In this case there seems 
> to be a case for either double precision or switching to 64-bit unsigned 
> intergers.
> 
> 73
> Bill
> G4WJS.
> 
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSPR-2 Question about difference of reported frequencies between version 1.6 and 1.7

[f5djl]

Hi Bill 

 

Totally agree with your analysis but I have so far failed to identify in
wsprd.c  where to make the change ! It must be obvious and I am sure it is
fixable specially as in 1.6  it was ok according to my tests.  I will do a
compare tomorrow or I am sure Steve will point me to the obvious ! 

 

Best regards 

 

Jean  Louis  F5DJL 

 

De : Bill Somerville [mailto:g4...@classdesign.com] 
Envoyé : jeudi 18 août 2016 00:35
À : wsjt-devel@lists.sourceforge.net
Objet : Re: [wsjt-devel] WSPR-2 Question about difference of reported
frequencies between version 1.6 and 1.7

 

On 17/08/2016 23:28, f5djl wrote:

Clearly from the list below of  RX reported frequency , they are suspicious
from 10  m to 23 cm : ie 1296.501465  is reported instead of the expected
1296.501500 .

 

1296.501465   

Hi Jean Louis & all,

that error is within the bounds of a single precision floating point
representation discrepancy. The main window UI code and rig control use a 64
bit unsigned integer to represent frequencies to 1Hz resolution. In the
codecs and a few other places where calculations are done on frequencies
single precision floating point variables are used. In this case there seems
to be a case for either double precision or switching to 64-bit unsigned
intergers.

73
Bill
G4WJS.

--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSPR-2 Question about difference of reported frequencies between version 1.6 and 1.7

[Bill Somerville]

On 17/08/2016 23:28, f5djl wrote:


Clearly from the list below of  RX reported frequency , they are 
suspicious  from 10  m to 23 cm : ie 1296.501465  is reported instead 
of the expected 1296.501500 .


1296.501465


Hi Jean Louis & all,

that error is within the bounds of a single precision floating point 
representation discrepancy. The main window UI code and rig control use 
a 64 bit unsigned integer to represent frequencies to 1Hz resolution. In 
the codecs and a few other places where calculations are done on 
frequencies single precision floating point variables are used. In this 
case there seems to be a case for either double precision or switching 
to 64-bit unsigned intergers.


73
Bill
G4WJS.

--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSPR-2 Question about difference of reported frequencies between version 1.6 and 1.7

[f5djl]

Hi Steve and team  

 

Not sure if you saw my previous email  following your attempt to reproduce the 
problem , but I am looking for more help to correct the reported Rx frequency , 
if you inject a perfectly stable 1500Hz WSPR2 signal (drift reported = 0)  , 
and just change the RX band on version  wsjt-x 1.7 R7033  . You get the 
following list of reported frequency .  I have reset the frequency list and 
checked that intercept and slope are at 0 value before starting the test.  I 
also confirmed that Version 1.6 behavior is different ie reporting the expected 
frequency.

 

Clearly from the list below of  RX reported frequency , they are suspicious  
from 10  m to 23 cm : ie 1296.501465  is reported instead of the expected 
1296.501500 .

 

1296.501465

432.301514

144.490494

70.092499

50.294498

28.126101

24.926100

21.096100

18.106100

14.097100

10.140200

7.040100  

 

I had a quick look at mainwindows.cpp and wsprd.c  to see if I could identify 
the way the nominal frequency (dial frequency )  was added to the decoded 
signal frequency  and calibration factor but miserably  fail to identify the 
exact issue , which I believe however  is in wsprd.c  (or associated library ?) 
but I might well be very wrong hence the request for help ! 

 

Thanks again for your help and for those of you on the way to Trevise enjoy the 
EME weekend,  best 73 to all .  

 

Jean Louis F5DJL  

 

-Message d'origine-
De : Steven Franke [mailto:s.j.fra...@icloud.com] 
Envoyé : dimanche 14 août 2016 19:27
À : Joe Taylor 
Objet : Re: [wsjt-devel] WSPR-2 Question about difference of reported 
frequencies between version 1.6 and 1.7

 

Hi Jean Louis,

 

I did a couple of experiments here to see if I could reproduce the results 
described in your item 1. 

 

1. I transmitted a WSPR signal using WSJT-X 1.7 r7032 using my GPSDO-referenced 
TS-480 and received that signal using my Gnuradio/USRP1 SDR which is referenced 
to the same GPSDO. Received wav files were decoded using the wsprd from wsjt-x 
1.7. I did not find any significant frequency offset. 

 

Measured frequency was within 0.1 Hz of expected - the 0.1 Hz difference could 
be explained partly by TS-480 DDS resolution. I used the high resolution (0.1 
Hz) frequency estimates available in the ALL_WSPR.TXT file for this.

 

2. I compared the WSPR-estimated frequencies of off-the-air signals using my 
Gnuradio/USRP/GPSDO setup and the TS-480 with WSJT-X 1.7.0 r7032. Comparison of 
received frequencies shows no offset (at the 1 Hz resolution level). Offsets on 
the order of 0.1-0.2 Hz are present in the high resolution data — but this is 
not unexpected, especially on weak signals. The two rigs use different 
antennas, so the noise will not be perfectly correlated between the two 
receivers.

 

Is it possible that you had different settings in the 
Preferences/Frequencies/Frequency Calibration in your two instances of WSJT-X?

 

Steve k9an

 

> On Aug 14, 2016, at 10:04 AM, f5djl <  
> newsl...@f5djl.fr> wrote:

> 

> Hello all

>  

> I am  still having a lot of fun with WSPR/WSJT-X and I am  getting prepared 
> for the new modes  but I have questions for you on our good old friend WSPR-2 
> J  : 

>  

> 1/I  have noticed a difference of behavior between 1.6.0 R 6263 and 1.7.0 r 
> 7005 both executable from Joe's site  , The difference is in the reported 
> frequency.   I hope the screen shot attached below will describe the problem 
> .Same  wspr2 signal generated by an instance of 1.7.0 is decoded by an 
> instance 1.6.0 and an another instance  1.7.0 , it produces different results 
> ( frequency difference 4 Hz)  and the frequency reported does not match the 
> one of the transmit side in case of 1.7 receive instance .   Is it a normal 
> behavior ? 

>  

> 

>  

>  

> 2/ I also noticed that the Tune frequency is initially off frequency by 2Hz 
> in WSPR mode  , until you adjust manually the TX freq parameter then on 1500 
> Hz it is at 1500 ( variable initialization ?) ! 

>  

> Thanks in advance for your help to clarify  and this great wsjt-x piece of 
> code . 

>  

> Let me know if any further details are needed and very best regards 

> from France

>  

> Jean Louis F5DJL

> --

>  What NetFlow Analyzer can do for you? Monitors network 

> bandwidth and traffic patterns at an interface-level. Reveals which 

> users, apps, and protocols are consuming the most bandwidth. Provides 

> multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make 

> informed decisions using capacity planning reports. 

>   
> http://sdm.link/zohodev2dev___

> 

> wsjt-devel mailing list

>   

Re: [wsjt-devel] WSJT-X and gain staging

[Dani EA4GPZ]

El 17/08/16 a las 19:57, George J Molnar escribió:
> Then, as some suggest, it might be a good time to consider retiring the 
> slider, while retaining the thermometer. Not a "stop the presses" 
> change, but it might be a good usability bump. Perhaps even a color 
> coded indication for the dB-impaired?

Just to point out a usage scenario where the slider can be useful: On
the HF bands, you can encounter very strong signals or not for each
period. If you're using a conventional receiver, you'll need to use its
AGC. Otherwise, the receiver will saturate if the RF gain is set too
high or you'll lose SNR in the periods where there are no strong signals
if the RF gain is set low enough to prevent saturation on strong
signals. At least, this is what seems to work best on my FT-817ND.

With this setup, the radio will present a constant audio output level
whenever there are strong signals. Therefore, you can adjust your
soundcard level (and perhaps any attenuation you have in front of it) to
make the level, say 90% of maximum when there are strong signals. The
soundcard will never clip, because the radio AGC prevents it.

When using this strategy, I find that I have to set the slider in WSJT-X
quite low to get 30dB when only receiving the noise floor. The level in
WSJT-X will only raise to 40dB when receiving strong signals, because
the AGC of the radio prevents a further increase.

Of course, the slider in WSJT-X doesn't make any difference in decoding
performance, but can be used to ensure a good level in the waterfall
without having to tweak the waterfall sliders (same effect can be
achieved with them, of course, but you have to tweak both the waterfall
and spectrum zero points).

At least, this is what I've being doing so far with my rig. Perhaps
others can suggest a better strategy for a conventional receiver and the
HF bands.

73,

Dani EA4GPZ.


--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X and gain staging

[George J Molnar]

Then, as some suggest, it might be a good time to consider retiring the 
slider, while retaining the thermometer. Not a "stop the presses" 
change, but it might be a good usability bump. Perhaps even a color 
coded indication for the dB-impaired?

Geo/KF2T

-- Original Message --
From: "Michael Tharp" 
To: wsjt-devel@lists.sourceforge.net
Sent: 8/17/2016 10:52:02 AM
Subject: Re: [wsjt-devel] WSJT-X and gain staging

>On 8/17/2016 12:49, Joe Taylor wrote:
>>  Seems pretty clear to me.  Use controls ON THE TRANSCEIVER to set the
>>  noise level to around 30 dB on the WSJT-X "thermometer" scale, with 
>>no
>>  strong signals present and the slider at mid-scale.
>>
>>  If the background noise level is well above 40 dB with the digital
>>  slider at mid-scale, you lose some "headroom" for handling strong
>>  signals.  If the background noise level is much lower than 20 dB, you
>>  may lost a dB or more of sensitivity to the weakest detectable 
>>signals.
>
>Is there a scenario in which moving the slider from the middle position
>is helpful?
>
>If the audio coming in is too hot, then moving the slider will make the
>number lower but it won't fix clipping. As you point out, only changing
>the analog part of the chain will prevent that.
>
>-- mike NF4E
>
>--
>___
>wsjt-devel mailing list
>wsjt-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X and gain staging

[Michael Tharp]

On 8/17/2016 12:49, Joe Taylor wrote:
> Seems pretty clear to me.  Use controls ON THE TRANSCEIVER to set the
> noise level to around 30 dB on the WSJT-X "thermometer" scale, with no
> strong signals present and the slider at mid-scale.
>
> If the background noise level is well above 40 dB with the digital
> slider at mid-scale, you lose some "headroom" for handling strong
> signals.  If the background noise level is much lower than 20 dB, you
> may lost a dB or more of sensitivity to the weakest detectable signals.

Is there a scenario in which moving the slider from the middle position 
is helpful?

If the audio coming in is too hot, then moving the slider will make the 
number lower but it won't fix clipping. As you point out, only changing 
the analog part of the chain will prevent that.

-- mike NF4E

--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X and gain staging

[Joe Taylor]

Hi Mike,

> Does the input gain slider actually affect anything other than the level
> readout? I recall Joe saying that the decoder always uses the raw PCM
> data. Though I don't know fortran very well skimming the symspec routine
> suggests that only the readout is affected.

The gain slider does not affect the decoding procedure.

> If it doesn't affect decodes then is there some other purpose for its
> existence?

See below.

> I've run into a great many operators who are confused or
> mistaken about it doing more than it actually does. Many see that the
> manual says to adjust the levels to 30dB and then do so by changing the
> slider rather than the RF gain or analog attenuation, which of course
> doesn't help if the audio is already clipping.
>
> It might make sense to give the input readout a makeover in 1.8 to
> resolve this confusion and make it intuitive where the "sweet spot" is.

In Section 5, Transceiver Setup, the WSJT-X User Guide says this:

"Use the receiver gain controls and/or the computer’s audio mixer 
controls to set the background noise level (scale at lower left of main 
window) to around 30 dB when no signals are present. It is usually best 
to turn AGC off or reduce the RF gain control to minimize AGC action. If 
necessary you can also adjust the slider next to the dB scale, but note 
that the overall dynamic range will be best with this slider not too far 
from its mid-point."

Seems pretty clear to me.  Use controls ON THE TRANSCEIVER to set the 
noise level to around 30 dB on the WSJT-X "thermometer" scale, with no 
strong signals present and the slider at mid-scale.

If the background noise level is well above 40 dB with the digital 
slider at mid-scale, you lose some "headroom" for handling strong 
signals.  If the background noise level is much lower than 20 dB, you 
may lost a dB or more of sensitivity to the weakest detectable signals.

-- 73, Joe, K1JT

--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X and gain staging

[Michael Tharp]

On 8/17/2016 08:45, Bill Somerville wrote:
> We use 16-bit audio so the dB range is ~90 so that means +30dB on the
> thermometer indicator is ~ -60dBFS. It also means there is ~30dB
> headroom off the top of the thermometer indicator.

Does the input gain slider actually affect anything other than the level 
readout? I recall Joe saying that the decoder always uses the raw PCM 
data. Though I don't know fortran very well skimming the symspec routine 
suggests that only the readout is affected.

If it doesn't affect decodes then is there some other purpose for its 
existence? I've run into a great many operators who are confused or 
mistaken about it doing more than it actually does. Many see that the 
manual says to adjust the levels to 30dB and then do so by changing the 
slider rather than the RF gain or analog attenuation, which of course 
doesn't help if the audio is already clipping.

It might make sense to give the input readout a makeover in 1.8 to 
resolve this confusion and make it intuitive where the "sweet spot" is.

-- mike NF4E

--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] QSO Problem

[Black Michael]

I've found most all offsets less than 100Hz are due to poorly calibrated rigs.I 
usually contact them to let them know and have helped a few get their rigs 
calibrated.
Any movement due to QRM is usually more than 200Hz away. 
de Mike W9MDB
  From: Wolfgang 
 To: WSJT software development  
 Sent: Wednesday, August 17, 2016 9:24 AM
 Subject: Re: [wsjt-devel] QSO Problem
   
Re: [wsjt-devel] QSO ProblemHello Dan,

you started at 2516/2517 Hz your QSO and PA3CPS came back at 13:18 at 2781 Hz
Therefore it's in the band activity. Guess PA3CPS clicked around and set his
TX frequency to 2781 Hz.

73 de Wolfgang
OE1MWW

Wednesday, August 17, 2016, 3:33:11 PM, you wrote:


| 
 | I just had this QSO with PA3CPS (See screen capture 
https://dl.dropboxusercontent.com/u/60505123/WSJT-X%20v1.7.0-rc1.JPG).  I 
called CQ, PA3CPS responded and his response was shown in “Rx Frequency”.  I 
replied.  His next 3 responses, including a “73” did show up under “Band 
Activity” but not under “Rx Frequency”.
 
 
 
Dan Malcolm
CFI/II   K4SHQ

On cable TV they have a weather channel - twenty-four hours of weather.
We had something like that where I grew up. We called it a window.
  |






--
Amateur radio is the most expensive type of free-of-charge communication!
Amateurfunk ist die teuerste Art der kostenlosen Kommunikation!
--

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


  --
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] QSO Problem

[Wolfgang]

Title: Re: [wsjt-devel] QSO Problem


Hello Dan,

you started at 2516/2517 Hz your QSO and PA3CPS came back at 13:18 at 2781 Hz
Therefore it's in the band activity. Guess PA3CPS clicked around and set his
TX frequency to 2781 Hz.

73 de Wolfgang
OE1MWW

Wednesday, August 17, 2016, 3:33:11 PM, you wrote:





I just had this QSO with PA3CPS (See screen capture https://dl.dropboxusercontent.com/u/60505123/WSJT-X%20v1.7.0-rc1.JPG).  I called CQ, PA3CPS responded and his response was shown in “Rx Frequency”.  I replied.  His next 3 responses, including a “73” did show up under “Band Activity” but not under “Rx Frequency”.
 
 
 
Dan Malcolm
CFI/II   K4SHQ

On cable TV they have a weather channel - twenty-four hours of weather.
We had something like that where I grew up. We called it a window.
 






--
Amateur radio is the most expensive type of free-of-charge communication!
Amateurfunk ist die teuerste Art der kostenlosen Kommunikation!


--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] QSO Problem

[Dan Malcolm]

I just had this QSO with PA3CPS (See screen capture
https://dl.dropboxusercontent.com/u/60505123/WSJT-X%20v1.7.0-rc1.JPG).  I
called CQ, PA3CPS responded and his response was shown in "Rx Frequency".  I
replied.  His next 3 responses, including a "73" did show up under "Band
Activity" but not under "Rx Frequency".

 

 

 

Dan Malcolm

CFI/II   K4SHQ


On cable TV they have a weather channel - twenty-four hours of weather.
We had something like that where I grew up. We called it a window.

 

--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X and gain staging

[Bill Somerville]

We use 16-bit audio so the dB range is ~90 so that means +30dB on the 
thermometer indicator is ~ -60dBFS. It also means there is ~30dB headroom off 
the top of the thermometer indicator.
73BillG4WJS.



How does the displayed input level relate to dBFS (decibels related to full 
scale)? 

--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJT-X and gain staging

[ea2ekh]

Hello,

First, I am late with my translation to Spanish but I will have time next week 
(finally!).

And I've been wondering about proper gain staging in WSJT-X for optimum 
reception. The manual suggests adjusting the input level and RF gain until the 
noise level is at around 30 dB according to the program display, but at least 
being audio minded it's difficult to refer to some external measure.

I am considering writing an article about this, giving some (hopefully useful) 
guidelines. I will send it to the URE magazine but I can write it in English as 
well and share, of course.

I have some questions:

Does the input level send gain adjustment orders to any USB device or is it 
purely a digital gain applied to the sampled signal? At least on Mac OS X I 
haven't observed any change in the input gain of an IC-7200 (it has a TI 
PCM2901E)

What is supposed to be the unity gain setting for the input level slider? 

How does the displayed input level relate to dBFS (decibels related to full 
scale)? 

I could measure that but I am not sure about its behavior on different 
platforms (Windows, Linux, Mac OS X) and with different devices, so it would be 
great to know what it's supposed to be.

TNX DE EA2EKH



--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel