Menu
▾
▴
[wsjt-devel] JTSDK python error
|
From: Black M. <mdb...@ya...> - 2015-05-19 19:39:30
|
I installed JTSDK on a new computer and building wsjtx fails as it can't find python.
Turns out JTSDK now installs Python33 and not python27. Compiling on my old computer works as it has both 27 and 33. I assume the 33 came from a JTSDK update.
wsjtxexp compiles OK but doesn't appear to use python.
73
Mike W9MDB
From: Bill Somerville <g4...@cl...>
To: wsj...@li...
Sent: Tuesday, May 19, 2015 1:07 PM
Subject: Re: [wsjt-devel] Dial calibration errors
On 19/05/2015 05:18, Michael Black wrote:
Hi Mike & All
<!--#yiv3900820176 _filtered #yiv3900820176 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv3900820176 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv3900820176 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv3900820176 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv3900820176 #yiv3900820176 p.yiv3900820176MsoNormal, #yiv3900820176 li.yiv3900820176MsoNormal, #yiv3900820176 div.yiv3900820176MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:"Times New Roman", "serif";color:black;}#yiv3900820176 a:link, #yiv3900820176 span.yiv3900820176MsoHyperlink {color:blue;text-decoration:underline;}#yiv3900820176 a:visited, #yiv3900820176 span.yiv3900820176MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv3900820176 p.yiv3900820176MsoAcetate, #yiv3900820176 li.yiv3900820176MsoAcetate, #yiv3900820176 div.yiv3900820176MsoAcetate {margin:0in;margin-bottom:.0001pt;font-size:8.0pt;font-family:"Tahoma", "sans-serif";color:black;}#yiv3900820176 span.yiv3900820176BalloonTextChar {font-family:"Tahoma", "sans-serif";}#yiv3900820176 span.yiv3900820176EmailStyle19 {font-family:"Calibri", "sans-serif";color:#1F497D;}#yiv3900820176 span.yiv3900820176EmailStyle20 {font-family:"Calibri", "sans-serif";color:#1F497D;}#yiv3900820176 .yiv3900820176MsoChpDefault {font-size:10.0pt;} _filtered #yiv3900820176 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv3900820176 div.yiv3900820176WordSection1 {}--> Thanks Bill….yup…forgot to remove the RR73 from my other experimentation. Removed the public API too. So patch is definitely smaller now.
I have implemented a change based on your patch. I had to change it a bit to make it more robust and also corrected the math errors ;)
It does behave a bit strangely on rigs with less than 1 Hz resolution but there's not a great deal we can do that is better for them, at least it is benign if the calibration constants are zero.
Currently the intercept error is +/- 10 kHz and the slope factor is +/- 1000 ppm which is probably enough range.
73 Mike W9MDB
73
Bill
G4WJS.
From: Bill Somerville [mailto:g4...@cl...]
Sent: Monday, May 18, 2015 4:34 PM
To: wsj...@li...
Subject: Re: [wsjt-devel] Dial calibration errors On 18/05/2015 20:10, Michael Black wrote:
Hi Mike,
If you mean can you compute it yourself…sure… http://www.miniwebtool.com/slope-intercept-form-calculator/ Just put the frequencies expected in X and what you measure in Y. Attached is a patch against 1.6.1 that adds intercept and slope to the Frequencies tab. You do have to change band after setting as I couldn't quite figure out how to force an update and exactly when that should be done (on exiting dialog? After entering either number?). Might also need some mention that you do either this or the offsets in the table…both are possible but not sure that makes any sense to do.
You can simplify that patch considerably by not adding the linear correction constants to the Configuration public interface. They are only needed within the Configuration class implementation.
Also you probably want to take out the "RR73" change as it is unrelated and probably not intended.
73 Mike W9MDB 73
Bill
G4WJS.
From: Edson W. R. Pereira [mailto:ewp...@gm...]
Sent: Monday, May 18, 2015 2:03 PM
To: WSJT software development
Subject: Re: [wsjt-devel] Dial calibration errors Hi Mike, You are correct. I should have mentioned that the same measurement should be done on a different band in order to have the second set of measurements. With band hopping and one calibrated station it may be possible? 73, Edson PY2SDR
--- - We humans have the capability to do amazing things if we work together. - Nós seres humanos temos a capacidade de fazer coisas incríveis se trabalharmos juntos. On Mon, May 18, 2015 at 2:21 PM, Michael Black <mdb...@ya...> wrote: You have to have samples along the entire frequency band to get a fit for slope an intercept. One freq doesn't do it. You really only need 2 for a linear fit but more samples gets a bit more accurate. I've just about got this thing coded up…and you COULD just put a fixed value in A if all you do is one band. So in your case you could stick a -9 in A and perhaps that's all you need. Mike W9MDB From: Edson W. R. Pereira [mailto:ewp...@gm...]
Sent: Monday, May 18, 2015 12:14 PM
To: WSJT software development
Subject: Re: [wsjt-devel] Dial calibration errors Hello Joe, I just checked some of the common received spots between my station and Steve's on 15m and I am 9 Hz off (down). This makes me think that having a standard station in WSPR like Steve's could allow an automatic calibration by performing a query on the wsprnet database for our station and a standard one and compare the results The difference could be converted into the A and B values. Could this work? 73, Edson PY2SDR
--- - We humans have the capability to do amazing things if we work together. - Nós seres humanos temos a capacidade de fazer coisas incríveis se trabalharmos juntos. On Mon, May 18, 2015 at 11:09 AM, Joe Taylor <jo...@pr...> wrote: A few more thoughts about dial calibration errors.
A couple of days ago I put my TS-2000 radio through the calibration
procedure described in Appendix C of the WSPR 4.0 User's Guide
http://physics.princeton.edu/pulsar/K1JT/WSPR_4.0_User.pdf
The procedure takes about half an hour, end to end, yielding the values
of two constants A and B. These constants appear in the equation
d = A + B*f
where d is the radio's dial error in Hz and f is the received frequency
in MHz. In my case the constants are A = 2.14 Hz and B = 1.6254. I
note that the value of A has remained constant, but several years ago B
was somewhat smaller (B = 1.2885 in 2011), so the master oscillator in
my TS-2000 has aged a bit.
From the values of A and B I computed the dial error for each amateur
band and entered those values (expressed in MHz) in the "Offset" column
of the WSJT-X Settings | Frequencies tab. Frequencies reported for my
WSPR decodes now agree with those reported by Steve, K9AN, to within 1
Hz. (Steve's receiver uses GPS-disciplined oscillators, so his WSPR
reports are a good standard for comparison.)
It might be handy to permit a user of WSJT-X to enter values for A and B
and have the program calculate the resulting "Offset" values for the
Frequencies tab. The resulting system behavior is very sensible, in my
opinion. When WSPRing on 20 meters, for example, my TS-2000 dial now
reads 14.09562 MHz. WSJT-X intentionally sets the radio about 24 Hz
high on this band, to compensate for its dial error.
The dial frequency displayed on the WSJT-X main window is the corrected
value, 14.095 600 MHz.
-- 73, Joe, K1JT
On 5/13/2015 10:48 AM, Joe Taylor wrote:
> Hi all,
>
> One of the fun things about WSPR is the frequency accuracies that
> are involved. Having WSPR mode in WSJT-X motivates some serious thought
> about how best to handle frequency calibration errors in transceivers.
>
> Typical dial readout errors in modern radios are a few parts per million
> -- for example, a 20 Hz error at 14 MHz. For JT65 or JT9 such
> discrepancies are not very important. But the WSPR sub-bands in
> conventional use since 2008 are only 200 Hz wide, and we'd like to use
> all of that range effectively. If my transceiver's dial reads 20 Hz
> low, and yours reads 20 Hz high, and we both set our dials to the
> conventional 14.0956 MHz for 20 meters, after setting our WSPR Tx
> frequencies at random within the 200 Hz sub-band there's something like
> a 20% chance that we won't decode one another.
>
> Earlier production versions of WSPR have handled these issues in a
> rather sophisticated way. The User's Guide includes detailed
> instructions for determining calibration constants for your transceiver
> using over-the-air signals (see Appendix C of
> http://physics.princeton.edu/pulsar/K1JT/WSPR_3.0_User.pdf ). The
> resulting accuracies can be better than 1 Hz.
>
> If CAT control is in use and "Enable frequency correction" is ticked on
> WSPR's "Advanced Setup" window, frequencies sent to the radio are
> adjusted so as to compensate for the dial errors. For example, if
> 14.0956 MHz has been requested, the command for 14095620 Hz may be sent
> to the radio.
>
> I picture this being implemented in WSJT-X in a similar way. In this
> example, the radio dial would read 14.096520. I'm suggesting that the
> frequency readout on the WSJT-X screen would read 14.095600, the
> supposedly "true" frequency.
>
> Comments and suggestions would be welcome.
>
> -- 73, Joe, K1JT
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
wsjt-devel mailing list
wsj...@li...
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
|
