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

[f5djl]

Hi Steve 

Thanks a lot , a quick compile of R7034 and a rapid test confirmed the issue
with reported WSPR frequencies is fixed .  I must have been bind (or drunk
:-) ?  to not see the type in the structure  ! 
Many thanks again  for the fix well in advance of the weekend :-) !  I will
leave this version running thru the weekend . 

Best regards and have a very good day . 

Jean Louis F5DJL 

-Message d'origine-
De : Steven Franke [mailto:s.j.fra...@icloud.com] 
Envoyé : jeudi 18 août 2016 01:35
À : 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 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



--
___
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

[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 < <mailto:newsl...@f5djl.fr> 
> 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___> 
> http://sdm.link/zohodev2dev

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

[f5djl]

Hi Steve 

I have made some further investigation and have found the area of trouble . 

I have compiled R7032 and can reproduce the problem only if you are on band 
above 2m , try for example with 1296 as a band ( of course as a fake)  and you 
will see the problem , the wav file analysis by wsprd is giving the right 
frequency . It is in the process of adding the band information frequency 
offset  that there is a glitch . I could have a look at the code but thought 
you may know exactly where it could be ...

Best regards 

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  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
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
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
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
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 decisio

Re: [wsjt-devel] version 1.6 and 1.7

[f5djl]

Bonsoir  Bill 

Thanks a lot  ... FYI  I had sent off list a reply direct to Philippe with
Joe's message  , congrats for your French  and have a nice evening  :-) 

Best regards 

Jean Louis 

-Message d'origine-
De : Bill Somerville [mailto:g4...@classdesign.com] 
Envoyé : dimanche 14 août 2016 19:40
À : wsjt-devel@lists.sourceforge.net
Objet : Re: [wsjt-devel] version 1.6 and 1.7

On 14/08/2016 16:27, f5umy wrote:
> Bonjour f5djl. Pourriez vous me faire parvenir le lien de chargement 
> de le version 1.7   car impossible de la trouver. Amicalement F5UMY 
> Philippe

Bonjour Philippe,

https://sourceforge.net/p/wsjt/mailman/message/35262891/

73
Bill
G4WJS.



--
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
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
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
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSPR scheduler - no band hoping behavior

[f5djl]

Mike and Steve 

Thanks a lot for your answers , I see fully the benefit of moving the srand
at start and making it even more unique and calculated only once. 
It will definitely solve the issue happening when  the schedule is
recalculated at the top of the hour , so different machines will not get the
same seed and hence the same schedule.

However and to be precise in my previous findings what surprised me is that
with the current code even if the applications are started with 10 seconds
difference ( the machine could have been  started at any time) , srand
(time(0)  I believe create a different seed as long as there is more than
one second difference at its execution time ... , and  however I always
noticed the TX schedule being identical  ,  May be I was just unlucky and
the "top of the hour resynch always happened before the first Tx period ! 

I will retest all this after the week end and  do the modification you
suggested , as I am now focusing on the IARU HF World Championship contest
as part of the TM0HQ team for the next 3 days :-) 

Best 73 , have a very nice weekend and thanks again 

Jean Louis  F5DJL 

-Message d'origine-
De : Michael Black [mailto:mdblac...@gmail.com] 
Envoyé : jeudi 9 juillet 2015 22:03
À : 'WSJT software development'
Objet : Re: [wsjt-devel] WSPR scheduler - no band hoping behavior

Since srand(time(0)) is used then two machines started at the same second
will be synchronized.  Normally the odds of that happening are pretty rare.
But if srand is done at the end of every schedule period than it sounds like
a whole lot of WSJT-X's could be getting synchronized to the same schedule.

Try moving the srand to the constructor in WSPRBandHopping.cpp That way it
will set when the program is started rather than resetting constantly.
So as long as you don't start both programs at the same second no one should
be synchronized.

And really should replace srand with this so it's even less likely to
collide with anybody else.
struct timeval time;
gettimeofday(&time,NULL);
srand((time.tv_sec*1000) + (time.tv_usec/1000));


Index: WSPRBandHopping.cpp
===
--- WSPRBandHopping.cpp (revision 5709)
+++ WSPRBandHopping.cpp (working copy)
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "SettingsGroup.hpp"
 #include "Configuration.hpp"
@@ -118,6 +119,11 @@
   main_layout->addLayout (bottom_layout);

   setLayout (main_layout);
+  // init our random seed here just once and make it pretty unique  
+ struct timeval time;  gettimeofday(&time,NULL);
+  srand((time.tv_sec*1000) + (time.tv_usec/1000));
+
 }

 Dialog::~Dialog ()
Index: WsprTxScheduler.cpp
===
--- WsprTxScheduler.cpp (revision 5709)
+++ WsprTxScheduler.cpp (working copy)
@@ -104,7 +104,7 @@

 needed=60*(pctx/100.0)+0.5;

-srand(time(NULL));
+//srand(time(NULL));
 memset(tx,0,sizeof(char)*60);

 if( pctx < 17 ) {

73
Mike W9MDB


-Original Message-
From: f5djl [mailto:newsl...@f5djl.fr]
Sent: Thursday, July 09, 2015 2:33 PM
To: 'WSJT software development'
Subject: [wsjt-devel] WSPR scheduler - no band hoping behavior

Hi all ,

I believe these questions/remarks are more for Steve and Bill.  As part of
testing/implementation of WSPR on VHF with a group of french hams
(1HDI,2MM,6ABJ,6BYJ) we currently test v5700 with a variety of TRX and
interfaces , always in  non band-hopping mode .

My questions are related to  how is supposed to work the randomization of TX
slot process and how/when exactly is the TX  table recalculated  ? 

1/ For example if you start the application on  two machines carefully time
synchronized ( ntp sync < one second)  with a TX% at 20 % at a few seconds
interval but within same 2 mn slot,   is it expected that TX sequence will
be the same , ie the TX slots will be synchronous on the two machines  ? 

I had a quickly look at the code which I believe is  involved ie
create_tx_schedule (int pctx) and I saw  srand(time(0)) being used  , I
thought wrongly most probably that the intent was to randomize the table by
generating a seed based on  delta in seconds to reference 1970 ?  I must
admit , I did not fully understood the purpose of the series of if statement
on pctx and the process of filling of the tx[] array and I have some serious
doubt on the effect of the band Hoppng  .

2/ I understand that TX next or disable/enable TX have no impact on the
schedule, is my understanding correct ? 

3/ The table is calculated in next_tx_state function I believe at start of
application , then at the top of the hour ? BTW I saw a double TX
transmission at xx:58 and XX+1:00 today) 

Thanks for your patience to explain and educate, understanding  this
behavior is important to us in  a small network of VHF stations (<10) as we
are trying to minimize the chance to get 

[wsjt-devel] WSPR scheduler - no band hoping behavior

[f5djl]

Hi all ,

I believe these questions/remarks are more for Steve and Bill.  As part of
testing/implementation of WSPR on VHF with a group of french hams
(1HDI,2MM,6ABJ,6BYJ) we currently test v5700 with a variety of TRX and
interfaces , always in  non band-hopping mode .

My questions are related to  how is supposed to work the randomization of TX
slot process and how/when exactly is the TX  table recalculated  ? 

1/ For example if you start the application on  two machines carefully time
synchronized ( ntp sync < one second)  with a TX% at 20 % at a few seconds
interval but within same 2 mn slot,   is it expected that TX sequence will
be the same , ie the TX slots will be synchronous on the two machines  ? 

I had a quickly look at the code which I believe is  involved ie
create_tx_schedule (int pctx) and I saw  srand(time(0)) being used  , I
thought wrongly most probably that the intent was to randomize the table by
generating a seed based on  delta in seconds to reference 1970 ?  I must
admit , I did not fully understood the purpose of the series of if statement
on pctx and the process of filling of the tx[] array and I have some serious
doubt on the effect of the band Hoppng  .

2/ I understand that TX next or disable/enable TX have no impact on the
schedule, is my understanding correct ? 

3/ The table is calculated in next_tx_state function I believe at start of
application , then at the top of the hour ? BTW I saw a double TX
transmission at xx:58 and XX+1:00 today) 

Thanks for your patience to explain and educate, understanding  this
behavior is important to us in  a small network of VHF stations (<10) as we
are trying to minimize the chance to get two stations TX simultaneously and
then long period of simultaneous silence. So far I must admit  we got some
rather unexpected results as the machines are much more than expected
simultaneously transmitting/receiving when at same Tx percentage . 

Best regards 

 Jean Louis 


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Microkeyer and r5700

[f5djl]

Hi Bill 

I hope you are well , apologies as the exchange about the Microkeyer issue
was handled in a direct email exchange with Mike (W9MDB) while we were
working on the FT991 last week !

We did not further progress and  I am not using a Microkeyer . I am using a
FT897 but CAT connected using FTDI chip  .  Jean Marc is using the
Microkeyer and he has now confirmed the problem  is happening with the FT817
and not with the IC7000 using the same Microkeyer. 

BTW , v5700 is running for nearly 24hours now in non-band hopping mode like
charm on the FT897/FTDI - your r 5700 Tx pct init  did the job for the
scheduler no glitch ( measured percentage 20.2 % for setting of 20% ) :-) 

Best regards 

Jean Louis F5DJL 

-Message d'origine-
De : Bill Somerville [mailto:g4...@classdesign.com] 
Envoyé : jeudi 9 juillet 2015 09:49
À : wsjt-devel@lists.sourceforge.net
Objet : Re: [wsjt-devel] r5700

On 09/07/2015 08:39, F1HDI wrote:
>
> Hi,
>
Bonjour Jean-Marc,
>
> Probably Jean-louis (F5DJL) already told you about issue with wsjt-x 
> and radio sets with microham microkeyer II.
>
> Lately, we tested wsjtx r 566x with a microkeyer II followed by an 
> IC7000, everything is fine, but replacing the 7000 by an FT817ND won't 
> work on the CAT side (yes all setup params have been reviewed and the
> 817 conf has been tested under hamradiodeluxe).
>
This is news to me! The Microham interfaces send extra CAT commands so that
they can track the radio mode and frequency, this may well be introducing a
compatibility issue with the Hamlib driver for the FT-817/857/897. This is
probably something I need to investigate directly and separately from the
other issues. Is it Jean-Louis (F5DJL) who is using the microkeyer II with
an FT-817?
>
> It looks to me this is related to some timing issues that you already 
> are looking about.
>
> 73
>
> Jean-marc
>
>
73
Bill
G4WJS.


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that you
need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Status WSJT R 5700

[f5djl]

Hello to all 

  Thanks a lot to all for your effort and comments on this . Status on this 
side of the big pond as of writing this email at lunch time ( important moment 
in France :-) ) 

  1/ I did compile this morning  V5700  using JTSDK 2.0  on windows , but 
without updating of Hamlib3 . 
  2/ V 5700  is running  at TX Pct 20% since 3 hours happily ... :-)  on 
I-7 / Win8.1/ FT897 
   
Regarding the "constrains" I realized reading your exchange  and 
WsprTxscheduler (code in a C I can still understand ..thanks Steve ) )  the 
complexity behind a simple percentage …

I am not sure of the complexity of implementation ( devil is in the detail as 
usual ) ,  but when Band Hopping is unchecked  , I must admit I like the idea 
of a maximum number of consecutive RX periods but I agree it does twist the 
random aspect seriously. 

Alternatively at the time the table is calculated a display of the maximum Rx 
period  length ( the operator can then decide to regenerate by a quick 
disable/enable TX a more “suitable” table )  or as another possible suggestion 
enhancing the last TX message on the bottom line with  a value of the next 
expected TX slot (counter decrementing down to zero when TX is going to happen 
next slot). 

I may have a look at the code but I am in discovery and (very) slow learning of 
the code for the moment!

Thanks again for your help and have a very nice day . 

Jean Louis F5DJL  



--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSPR-2 - Further test Scheduler in no band hopping mode

[f5djl]

Hi Steve and Bill 

 

   I have switched  on band hopping  on and filled the schedule  ( single
Band 40m however as the antenna system here does not yet allow thru BH) ! So
far it seems to work but more later on this to confirm. 

   Now it will be me who have to switch to stuff paying the bills for a few
hours  :) !!! 

 

Thanks a lot for your help and best 73 .  

 

Jean Louis  

 

De : Bill Somerville [mailto:g4...@classdesign.com] 
Envoyé : mardi 7 juillet 2015 17:02
À : wsjt-devel@lists.sourceforge.net
Objet : Re: [wsjt-devel] WSPR-2 - Further test Scheduler in no band hopping
mode

 

On 07/07/2015 15:57, Steven Franke wrote:

Hi Steve & Jean-Louis,

Thanks Jean Louis for the detailed information. I will take a look this
afternoon (still at work this morning).  

 

In the meantime, one more question. Have you ever seen this behavior when
bandhopping? I ask this question because I have never seen this behavior,
but I am always bandhopping, so I wonder if this is restricted to the “no
hopping” situation.

I am working on this right now. I think it is due to some old code from the
original transmit %age algorithm before we started using the hopping
scheduler for all Tx scheduling. I should have a fix soon.

Sorry for the slow response to this, I am busy with much less interesting
stuff that pays the bills :(



 

Steve k9an

73
Bill
G4WJS.



 

On Jul 7, 2015, at 7:23 AM, f5djl mailto:newsl...@f5djl.fr> > wrote:

 

Hi Steve , Hi Joe and all 

 

   A few more details following some furthers tests today : 

 

  1/ T0 : start application enable TX ticked (red) ( nothing else touch
ie no modification of Tx% at 20% ) 

  2/ T0+1h : Happily decoding but no TX 

  3/T0+2h : same status 

  4/T0+2h10mn : press TX next  , one TX cycle and then no further TX  

  5/T0+3H : still no further TX 

  6/T0+3H20 : Change TX & at 25 % 

  7/ As at still no Tx the  press TX_next (09h48) and then process
started  :-) 

  8/ Now more than 2 hours later still running happily for how long …
but so far so good ! ?

 

You will find screenshots and log files at dropbox below . 

https://www.dropbox.com/s/w2f013omrzc9lu8/WSPR%20test%20scheduler.zip?dl=0

 

My conclusion so far is that to ensure start of the scheduler : Press
enable TX , followed by a change of percentage AND then a TX next  is
required !

Once started will it stop?  I do not know (yet) but it has been running more
than two hours now ! :-)  

 

I may try to have look at code :WsprTxScheduler, WSPR BandHopping and
mainwindows I assume , but I am sure you will be more efficient to correlate
it with above .  ( I am much more a C microcontroller man or financial
market  more than a QT expert :-) ) 

 

Very best regards 

 

Jean Louis  

 

Test environment : Windows 8.1 , WSJT-X r 5685 , FT897 

 

Summary to Steve's questions : 

 

Does this happen only if you have never touched TX Pct since starting the
program?

>Yes 

When you observed this behavior what was the TX Pct? 

>20 %

How long did you run with no transmissions?

>More than 2 Hours

In particular, did you go for a full 2 hours with no transmission?

>Yes 

 If so, then does the scheduler eventually kick in after 2 hours with no
transmission?

>Only triggered by a TxNext AND a change of %

 

 

-Message d'origine-
De : Steven Franke [mailto:s.j.fra...@icloud.com] 
Envoyé : mardi 7 juillet 2015 02:17
À : WSJT software development
Objet : Re: [wsjt-devel] WSPR-2 - Scheduler in no band hopping mode

 

Jean Louis, Joe - 

 

Does this happen only if you have never touched TX Pct since starting the
program?

 

When you observed this behavior what was the TX Pct? How long did you run
with no transmissions? In particular, did you go for a full 2 hours with no
transmission? If so, then does the scheduler eventually kick in after 2
hours with no transmission?

 

I haven’t changed anything in the wspr tx scheduler recently. I know that
Bill adjusted the band selection algorithm not too long ago, but that
shouldn’t have involved the scheduler. I just looked at the code, and it
seems that the tx table should be automatically generated the first time
that next_tx_state() is called.

 

I’ll also note that the statistics of the scheduler may “feel” different
when TX Pct is less than 17%, as a different algorithm is used in that
regime.

 

Steve k9an

 

> On Jul 6, 2015, at 6:32 PM, Joe Taylor < <mailto:j...@princeton.edu>
j...@princeton.edu> wrote:

> 

> Hi Jean Louis and all,

> 

> I have not yet tried to trace the cause, but I have also observed the 

> behavior you describe.  In WSPR mode, WSJT-X can stop initiating any 

> Tx sequences, even though "Enable Tx" remains ON (red background).

> 

> I think Bill (or was it Steve?) made the most recent changes to the 

> T/R scheduler.  Is it possible that somehow the T/R table becomes 

> lost, or is not re-

Re: [wsjt-devel] WSPR-2 - Scheduler in no band hopping mode

[f5djl]

Hello all 

 

If this can help regarding scheduler investigation ,  these are results 
collected by Jacques F2MM on 363 consecutive time slots : 

89  Tx slots over a total 363 , so quite good for a setting of 25% . however 
distribution of number of RX periods between TX time slot is also interesting : 
 ranging from 1 to 18  rx consecutive time slots but  46 % separated only by 
one RX period : 

 

Total Tx =  8924,52%
  

Total Rx =  274   75,48%
  

 

Distribution Delta between TX slots1 2 3 4 5 6  
   7  8 9 101112131415161718
Total

Occurrence =   41179 8 2 2  
   3  0 0 0 2 2 0 0 1 0 0 2 89

% = 46,1% 19,1% 10,1% 9,0%  2,2%  
2,2%  3,4%  0,0%  0,0%  0,0%  2,2%  2,2%  0,0%  0,0%  1,1%  0,0%  0,0%  
2,2%  100,0%

 

 

Apologies in advance , not sure if table will be very readable  !!!.

 

Best 73 

 

Jean Louis 

-Message d'origine-
De : Steven Franke [mailto:s.j.fra...@icloud.com] 
Envoyé : mardi 7 juillet 2015 02:17
À : WSJT software development
Objet : Re: [wsjt-devel] WSPR-2 - Scheduler in no band hopping mode

 

Jean Louis, Joe - 

 

Does this happen only if you have never touched TX Pct since starting the 
program?

 

When you observed this behavior what was the TX Pct? How long did you run with 
no transmissions? In particular, did you go for a full 2 hours with no 
transmission? If so, then does the scheduler eventually kick in after 2 hours 
with no transmission?

 

I haven’t changed anything in the wspr tx scheduler recently. I know that Bill 
adjusted the band selection algorithm not too long ago, but that shouldn’t have 
involved the scheduler. I just looked at the code, and it seems that the tx 
table should be automatically generated the first time that next_tx_state() is 
called.

 

I’ll also note that the statistics of the scheduler may “feel” different when 
TX Pct is less than 17%, as a different algorithm is used in that regime.

 

Steve k9an

 

> On Jul 6, 2015, at 6:32 PM, Joe Taylor < <mailto:j...@princeton.edu> 
> j...@princeton.edu> wrote:

> 

> Hi Jean Louis and all,

> 

> I have not yet tried to trace the cause, but I have also observed the 

> behavior you describe.  In WSPR mode, WSJT-X can stop initiating any 

> Tx sequences, even though "Enable Tx" remains ON (red background).

> 

> I think Bill (or was it Steve?) made the most recent changes to the 

> T/R scheduler.  Is it possible that somehow the T/R table becomes 

> lost, or is not re-calculated when that should happen?

> 

> -- Joe, K1JT

> 

> On 7/6/2015 9:20 AM, f5djl wrote:

>> Hello to all

>> 

>> While testing the patch kindly provided by Mike for the rig control 

>> of FT991 ( thanks Mike and it seems to work smoothly for WSPR/991)  , 

>> I noticed the following  (BTW observed on two different TX 

>> configurations FT897 and FT

>> 991) :

>> 

>>1/WSPR seems stuck in RX mode despite the enable TX button being red .

>> 

>>2/ Just changing the TXPct % seems to resume the transmit process 

>> ( I understand this action forces to recalculation of the table used 

>> by the scheduler )

>> 

>>3/ I tried a TX next button before changing the TX pct , and 

>> although it triggered a single transmission it did not resume the scheduler.

>> 

>>4/ I have not yet managed to figure what could have stopped TX 

>> process , is it the automatic ( every two hours ?)  recalculation not 

>> happening or something else not sure .

>> 

>>5/ I have seen it working for several hours without problem so it 

>> is not always the case .

>> 

>> Any advice on how to better capture the condition which lead to TX 

>> process stopping will be much appreciated ( I had a look at  

>> WSPR_history file and except the absence of TX slot could not see 

>> anything obvious)

>> 

>> Latest tests were performed on Win 8.1 , 1.6.0-dev r 5685  with FT897 

>> and

>> FT991 .

>> 

>> Very best regards

>> 

>> Jean Louis F5DJL

>> 

>> 

>> 

>> PS : If anybody has hand-on experience with FT991 in DATA-USB mode 

>> thru the TRX internal audio card ( ie audio  via internal USB 

>> interface )  , please contact me direct as the setting of the DSP 

>> filter in that specific mode ( Data-US

[wsjt-devel] WSPR-2 - Further test Scheduler in no band hopping mode

[f5djl]

Hi Steve , Hi Joe and all 

 

   A few more details following some furthers tests today : 

 

  1/ T0 : start application enable TX ticked (red) ( nothing else touch ie 
no modification of Tx% at 20% ) 

  2/ T0+1h : Happily decoding but no TX 

  3/T0+2h : same status 

  4/T0+2h10mn : press TX next  , one TX cycle and then no further TX  

  5/T0+3H : still no further TX 

  6/T0+3H20 : Change TX & at 25 % 

  7/ As at still no Tx the  press TX_next (09h48) and then process started  
:-) 

  8/ Now more than 2 hours later still running happily for how long …  but 
so far so good ! ?

 

You will find screenshots and log files at dropbox below . 

https://www.dropbox.com/s/w2f013omrzc9lu8/WSPR%20test%20scheduler.zip?dl=0

 

My conclusion so far is that to ensure start of the scheduler : Press  enable 
TX , followed by a change of percentage AND then a TX next  is required !

Once started will it stop?  I do not know (yet) but it has been running more 
than two hours now ! :-)  

 

I may try to have look at code :WsprTxScheduler, WSPR BandHopping and 
mainwindows I assume , but I am sure you will be more efficient to correlate it 
with above .  ( I am much more a C microcontroller man or financial market  
more than a QT expert :-) ) 

 

Very best regards 

 

Jean Louis  

 

Test environment : Windows 8.1 , WSJT-X r 5685 , FT897 

 

Summary to Steve's questions : 

 

Does this happen only if you have never touched TX Pct since starting the 
program?

>Yes 

When you observed this behavior what was the TX Pct? 

>20 %

How long did you run with no transmissions?

>More than 2 Hours

In particular, did you go for a full 2 hours with no transmission?

>Yes 

 If so, then does the scheduler eventually kick in after 2 hours with no 
transmission?

>Only triggered by a TxNext AND a change of %

 

 

-Message d'origine-
De : Steven Franke [mailto:s.j.fra...@icloud.com] 
Envoyé : mardi 7 juillet 2015 02:17
À : WSJT software development
Objet : Re: [wsjt-devel] WSPR-2 - Scheduler in no band hopping mode

 

Jean Louis, Joe - 

 

Does this happen only if you have never touched TX Pct since starting the 
program?

 

When you observed this behavior what was the TX Pct? How long did you run with 
no transmissions? In particular, did you go for a full 2 hours with no 
transmission? If so, then does the scheduler eventually kick in after 2 hours 
with no transmission?

 

I haven’t changed anything in the wspr tx scheduler recently. I know that Bill 
adjusted the band selection algorithm not too long ago, but that shouldn’t have 
involved the scheduler. I just looked at the code, and it seems that the tx 
table should be automatically generated the first time that next_tx_state() is 
called.

 

I’ll also note that the statistics of the scheduler may “feel” different when 
TX Pct is less than 17%, as a different algorithm is used in that regime.

 

Steve k9an

 

> On Jul 6, 2015, at 6:32 PM, Joe Taylor < <mailto:j...@princeton.edu> 
> j...@princeton.edu> wrote:

> 

> Hi Jean Louis and all,

> 

> I have not yet tried to trace the cause, but I have also observed the 

> behavior you describe.  In WSPR mode, WSJT-X can stop initiating any 

> Tx sequences, even though "Enable Tx" remains ON (red background).

> 

> I think Bill (or was it Steve?) made the most recent changes to the 

> T/R scheduler.  Is it possible that somehow the T/R table becomes 

> lost, or is not re-calculated when that should happen?

> 

> -- Joe, K1JT

> 

> On 7/6/2015 9:20 AM, f5djl wrote:

>> Hello to all

>> 

>> While testing the patch kindly provided by Mike for the rig control 

>> of FT991 ( thanks Mike and it seems to work smoothly for WSPR/991)  , 

>> I noticed the following  (BTW observed on two different TX 

>> configurations FT897 and FT

>> 991) :

>> 

>>1/WSPR seems stuck in RX mode despite the enable TX button being red .

>> 

>>2/ Just changing the TXPct % seems to resume the transmit process 

>> ( I understand this action forces to recalculation of the table used 

>> by the scheduler )

>> 

>>3/ I tried a TX next button before changing the TX pct , and 

>> although it triggered a single transmission it did not resume the scheduler.

>> 

>>4/ I have not yet managed to figure what could have stopped TX 

>> process , is it the automatic ( every two hours ?)  recalculation not 

>> happening or something else not sure .

>> 

>>5/ I have seen it working for several hours without problem so it 

>> is not always the case .

>> 

>> Any advice on how to better capture the condition which lead to TX 

>> process stopping will be much appreciated ( I had a look at  

>> WSPR_hi

[wsjt-devel] WSPR-2 - Scheduler in no band hopping mode

[f5djl]

Hello to all 

 

While testing the patch kindly provided by Mike for the rig control of FT991
( thanks Mike and it seems to work smoothly for WSPR/991)  , I noticed the
following  (BTW observed on two different TX configurations FT897 and FT
991) : 

 

   1/WSPR seems stuck in RX mode despite the enable TX button being red .

   2/ Just changing the TXPct % seems to resume the transmit process ( I
understand this action forces to recalculation of the table used by the
scheduler ) 

   3/ I tried a TX next button before changing the TX pct , and although it
triggered a single transmission it did not resume the scheduler.

   4/ I have not yet managed to figure what could have stopped TX process ,
is it the automatic ( every two hours ?)  recalculation not happening or
something else not sure .  

   5/ I have seen it working for several hours without problem so it is not
always the case .

 

Any advice on how to better capture the condition which lead to TX process
stopping will be much appreciated ( I had a look at  WSPR_history file and
except the absence of TX slot could not see anything obvious) 

Latest tests were performed on Win 8.1 , 1.6.0-dev r 5685  with FT897 and
FT991 . 

 

Very best regards 

 

Jean Louis F5DJL 

 

PS : If anybody has hand-on experience with FT991 in DATA-USB mode thru the
TRX internal audio card ( ie audio  via internal USB interface )  , please
contact me direct as the setting of the DSP filter in that specific mode (
Data-USB not USB) on the unit at hand does not perform as per the page 58
the manual ! I will be interested to share experience with another owner of
FT 991) . I have also joined FT991 group as this is not specific to WSJT
modes. 

 

 

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wspr two-pass decoder status and .c2 file problem

[f5djl]

Hello Bill and all team 

 

While I am working on the Hamlib / FT991 issue with Michael I got caught too by 
the wsprd issue .  

 

 

1/ 5644 :error message in wsjtx at decode time starting or running wsprd 

2/ Dos command wsprd without parameter : just the usage ok 

3/ Dos command but  trying to open a c2 file from command line it crashes 

4 / tried 5647 and it works  

 

I suspect it gives an idea of the root cause ! I am back to hamlib issue now … 

 

Regards 

 

Jean Louis 

 

C:\WSJT\wsjtx\bin>wsprd

Usage: wsprd [options...] infile

   infile must have suffix .wav or .c2

 

Options:

   -a  path to writeable data files, default="."

   -c write .c2 file at the end of the first pass

   -e x (x is transceiver dial frequency error in Hz)

   -f x (x is transceiver dial frequency in MHz)

   -H do not use (or update) the hash table

   -m decode wspr-15 .wav file

   -q quick mode - doesn't dig deep for weak signals

   -s single pass mode, no subtraction (same as original wsprd)

   -v verbose mode (shows dupes)

   -w wideband mode - decode signals within +/- 150 Hz of center

   -z x (x is fano metric table bias, default is 0.42)

 

C:\WSJT\wsjtx\bin>

 

 

C:\WSJT\wsjtx\bin>wsprd 150526_1904.c2   error  wsprd.exe has stopped  (windows 
message) 

 

 

 

-Message d'origine-
De : Bill Somerville [mailto:g4...@classdesign.com] 
Envoyé : mercredi 1 juillet 2015 12:20
À : wsjt-devel@lists.sourceforge.net
Objet : Re: [wsjt-devel] wspr two-pass decoder status and .c2 file problem

 

On 01/07/2015 06:16, Robert Kalkwarf wrote:

> Steve,

Hi Bob,

> 

> Win7 32 bit

> 

> I get an Error running or starting c:/WSJT/wsjtx/bin/wsprd

That looks like you have installed using an installer generated by the package 
build option. Have a look in the installed folder and see if wsprd.exe is 
there. It will be "C:\WSJT\wsjtx\bin\wsprd.exe". If it is there, try running it 
from the command line and tell us what you get.

> 

> Tried build-wsjtx install

> 

> Tried build-wsjtx package

> 

> Answered y both times to update.  HELP says I am running r5644

> 

> Clue Please?

> 

> 

> 73 Bob w7wo

73

Bill

G4WJS.

> 

> 

> 

>> On Jun 30, 2015, at 3:18 PM, Steven Franke <  
>> s.j.fra...@icloud.com> wrote:

>> 

>> For those testing wspr mode in wsjt-x ver 1.6, I’ve just committed r5644 
>> which makes decoder #5 from Joe’s table, below, the default decoder in 
>> wsjt-x ver 1.6. It is no longer necessary to separately compile wsprd_exp to 
>> get the benefits of two-pass decoding.

>> Steve k9an

>> 

>>> On Jun 29, 2015, at 6:25 PM, Joe Taylor <  
>>> j...@princeton.edu> wrote:

>>> 

>>> Hi Steve,

>>> 

> The test runs all used the same set of 386 *.wav files, processed 

> with the following decoders:

> 

> 1. wsprd, from WSPR-X (baseline decoder) 2. wspr4 3. wsprd, as 

> built for WSJT-X v1.6.0 r5636 4. wsprd_exp, signal subtraction 

> using symbol-by-symbol coherence 5. wsprd_exp, subtraction with 

> full coherence and test for local maxima 6. wsprd_exp, subtraction 

> with full coherence and snr>  min_snr

> 

> For each run the following table gives the number of decodes, the 

> wall-clock running time, the average time per wav file, and the 

> "improvement factor" for number of decodes and speed.

> 

>Decodes Time1  AvgTimeImprovement   Decoder

>  (s)(s)Decodes  Speed

> 

> 1.  1451   2111 5.5 1.001.00   baseline

> 2.  1693   1599 4.1 1.171.32   wspr4

> 3.  2208335 0.9 1.526.30   WSJT-X v1.6.0 r5636

> 4.  2464413 1.1 1.705.11   partial coherence

> 5.  2567431 1.1 1.774.90   full coherence

> 6.  2839   2136 5.5 1.960.99   more candidates

 Thanks for running these tests. These agree with my results, 

 although I see somewhat more improvement as you go down the list, 

 probably because my test files are all from 20m under crowded band 
 conditions.

>>> Agreed: I think my test files were not quite so homogeneous as yours.

>>> 

 At some point, we should look at the coherent subtraction lowpass 

 filter. The length (nfilt) and impulse response were chosen without 

 much thought...

>>> Yes, this may need further tweaking.  In addition, I suspect we can 

>>> find a criterion better than simply "smspec[j] > min_snr" for 

>>> choosing candidate frequencies, and likely some other speedups, as well.

>>> 

>>>-- Joe

 

 

--

Don't Limit Your Business. Reach for the Cloud.

GigeNET's Cloud Solutions provide you with the tools and support that you need 
to offload your IT needs and focus on growing

Re: [wsjt-devel] Progress - WSJT-X and FT991 CAT issue - rigctl-wsjtx results

[f5djl]

Bill 

 

Thanks for educating me on SVN , got it and make sense to use stored fixed
version ! J  I will continue with Michael on the subject of FT991 . 

 

Best regards 

 

JL

 

De : Bill Somerville [mailto:g4...@classdesign.com] 
Envoyé : mardi 30 juin 2015 14:00
À : wsjt-devel@lists.sourceforge.net
Objet : Re: [wsjt-devel] Progress - WSJT-X and FT991 CAT issue -
rigctl-wsjtx results

 

On 30/06/2015 12:49, f5djl wrote:

Hi Michael and Bill 

Bonjour Jean-Luis,



 

A quick "lunch time" compile and here below are the result , not yet there
but we are on the right path !:-) 

Applied patch provided by Michael and recompiled hamlib3 , then compiled
WSJT-X at this morning version 5640 . 

 

1/ WSJT :  Hamlib error  : invalid parameter while getting current frequency


2/  rigctl requesting frequency , see result below ( same parameter error) 

3/  rigctl requesting mode , seems all ok ! 

 

So not yet 100% but some interesting progress ... I have put also below the
link to the FT991 CAT documentation released by Yaesu and I will have a look
at the code tonight , but being totally unfamiliar with it , I might rather
rely on your expertise ! :-) it looks the answer is not what is expected . 

 

https://www.yaesu.com/downloadFile.cfm?FileID=8715
<https://www.yaesu.com/downloadFile.cfm?FileID=8715&FileCatID=158&FileName=F
T%2D991%5FCAT%5FOM%5FENG%5F1502%2DB0.pdf&FileContentType=application%2Fpdf>
&FileCatID=158&FileName=FT%2D991%5FCAT%5FOM%5FENG%5F1502%2DB0.pdf&FileConten
tType=application%2Fpdf

Looks like Mike has this fix in hand, I will leave the details of that to
him.



 

Best regards and thanks for your help 

 

Jean Louis F5DJL 

 

PS : I am not an expert on SVN but despite the svn version giving me 5640 as
checkout version , I get the result of the QT-SDK  compilation as in the in
“about box ” at 5636 ?  totally unrelated but noticed this today ! 

If you change to to your WSJT-X source workspace directory and use the
command 'svn info' you will see where the revision information is coming
from. The difference between the latest revision for the whole repository
and the latest change in the sub tree that is the workspace
(^/branches/wsjtx) is the explanation. This is one reason why we use a fixed
version stored in svn (Versions.cmake) for WSJT-X rather than using svn
change set numbers to identify releases.

...

73
Bill
G4WJS.

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Progress - WSJT-X and FT991 CAT issue - rigctl-wsjtx results

[f5djl]

Hi Michael and Bill 

 

A quick "lunch time" compile and here below are the result , not yet there
but we are on the right path !:-) 

Applied patch provided by Michael and recompiled hamlib3 , then compiled
WSJT-X at this morning version 5640 . 

 

1/ WSJT :  Hamlib error  : invalid parameter while getting current frequency


2/  rigctl requesting frequency , see result below ( same parameter error) 

3/  rigctl requesting mode , seems all ok ! 

 

So not yet 100% but some interesting progress ... I have put also below the
link to the FT991 CAT documentation released by Yaesu and I will have a look
at the code tonight , but being totally unfamiliar with it , I might rather
rely on your expertise ! :-) it looks the answer is not what is expected . 

 

https://www.yaesu.com/downloadFile.cfm?FileID=8715
<https://www.yaesu.com/downloadFile.cfm?FileID=8715&FileCatID=158&FileName=F
T%2D991%5FCAT%5FOM%5FENG%5F1502%2DB0.pdf&FileContentType=application%2Fpdf>
&FileCatID=158&FileName=FT%2D991%5FCAT%5FOM%5FENG%5F1502%2DB0.pdf&FileConten
tType=application%2Fpdf

 

Best regards and thanks for your help 

 

Jean Louis F5DJL 

 

PS : I am not an expert on SVN but despite the svn version giving me 5640 as
checkout version , I get the result of the QT-SDK  compilation as in the in
“about box ” at 5636 ?  totally unrelated but noticed this today ! 

 

**

 

Request frequency NOT OK 

 

C:\hamlib3\bin>rigctl - -m 135 -r com5 -s 38400 f

rigctl, Hamlib 3.0~git

Report bugs to 

 

rig:rig_init called

yaesu: initrigs3_yaesu called

rig_register (121)

rig_register (127)

rig_register (110)

rig_register (105)

rig_register (106)

rig_register (107)

rig_register (109)

rig_register (120)

rig_register (101)

rig_register (122)

rig_register (123)

rig_register (111)

rig_register (115)

rig_register (113)

rig_register (114)

rig_register (128)

rig_register (131)

rig_register (116)

rig_register (103)

rig_register (124)

rig_register (104)

rig_register (125)

rig_register (129)

rig_register (132)

rig_register (130)

rig_register (117)

rig_register (119)

rig_register (118)

rig_register (126)

rig_register (133)

rig_register (134)

rig_register (135)

ft991_init called

newcat_init called

rig:rig_open called

newcat_open called

newcat_set_trn called

newcat_valid_command called

newcat_get_vfo called

newcat_valid_command called

Opened rig model 135, 'FT-991'

Backend version: 0.22.1, Status: Alpha

newcat_get_freq called

newcat_valid_command called

get_freq: error = Invalid parameter

rig:rig_close called

newcat_close called

rig:rig_cleanup called

newcat_cleanup called

 

C:\hamlib3\bin>

 



Request Mode OK 

 

C:\hamlib3\bin>rigctl - -m 135 -r com5 -s 38400 m

rigctl, Hamlib 3.0~git

Report bugs to 

 

rig:rig_init called

yaesu: initrigs3_yaesu called

rig_register (121)

rig_register (127)

rig_register (110)

rig_register (105)

rig_register (106)

rig_register (107)

rig_register (109)

rig_register (120)

rig_register (101)

rig_register (122)

rig_register (123)

rig_register (111)

rig_register (115)

rig_register (113)

rig_register (114)

rig_register (128)

rig_register (131)

rig_register (116)

rig_register (103)

rig_register (124)

rig_register (104)

rig_register (125)

rig_register (129)

rig_register (132)

rig_register (130)

rig_register (117)

rig_register (119)

rig_register (118)

rig_register (126)

rig_register (133)

rig_register (134)

rig_register (135)

ft991_init called

newcat_init called

rig:rig_open called

newcat_open called

newcat_set_trn called

newcat_valid_command called

newcat_get_vfo called

newcat_valid_command called

Opened rig model 135, 'FT-991'

Backend version: 0.22.1, Status: Alpha

newcat_get_mode called

newcat_valid_command called

newcat_get_rx_bandwidth called

newcat_valid_command called

USB

1800

rig:rig_close called

newcat_close called

rig:rig_cleanup called

newcat_cleanup called

 

 

 

-Message d'origine-
De : Michael Black [mailto:mdblac...@gmail.com] 
Envoyé : mardi 30 juin 2015 06:14
À : wsjt-devel@lists.sourceforge.net
Objet : Re: [wsjt-devel] WSJT-X and FT991 CAT issue - rigctl-wsjtx results

 

I think (i.e. hope) the attached fixes the problem.

 

73

Mike W9MDB

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X and FT991 CAT issue - rigctl-wsjtx results

[f5djl]

Michael 

   Thanks a lot ,  I will apply the patch and recompile tonight . I will let
you know the outcome .  Have a nice day and 73 . 

Jean Louis 

-Message d'origine-
De : Michael Black [mailto:mdblac...@gmail.com] 
Envoyé : mardi 30 juin 2015 06:14
À : wsjt-devel@lists.sourceforge.net
Objet : Re: [wsjt-devel] WSJT-X and FT991 CAT issue - rigctl-wsjtx results

I think (i.e. hope) the attached fixes the problem.

73
Mike W9MDB


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X and FT991 CAT issue - rigctl-wsjtx results

[f5djl]

Hi Bill 

 

Thanks a lot , I will do a quick test tomorrow but that was my impression
too , it seems to fail quite early in the init process . 

I will be happy to help with testing  of driver patch when availaible .  

 

Thanks again and best regards 

 

JL

 

De : Bill Somerville [mailto:g4...@classdesign.com] 
Envoyé : mardi 30 juin 2015 01:04
À : wsjt-devel@lists.sourceforge.net
Objet : Re: [wsjt-devel] WSJT-X and FT991 CAT issue - rigctl-wsjtx results

 

On 29/06/2015 23:51, f5djl wrote:

Bill and Michael 

Bon Soir Jean-Louis,



 

Thanks a lot for your advice and here below is the result of rigctl-wsjtx .

OK, looks like the recently added driver for the FT-991 is incomplete. It is
falling over when it tries to check if the CAT command it is about to use is
valid for the rig.



I will get the official version 1.5.0  installed tomorrow to confirm if I
get similar results. 

I think you will get the same result.

We will sort out a patch for Hamlib3 to fix this.



 

Very best regards 

 

Jean-Louis - F5DJL 

73
Bill
G4WJS.



 

C:\WSJT\wsjtx\bin>rigctl-wsjtx - -m135 -scom5 f

rigctl, Hamlib 3.0~git

Report bugs to  <mailto:hamlib-develo...@lists.sourceforge.net>


rig:rig_init called

yaesu: initrigs3_yaesu called

rig_register (121)

rig_register (127)

rig_register (110)

rig_register (105)

rig_register (106)

rig_register (107)

rig_register (109)

rig_register (120)

rig_register (101)

rig_register (122)

rig_register (123)

rig_register (111)

rig_register (115)

rig_register (113)

rig_register (114)

rig_register (128)

rig_register (131)

rig_register (116)

rig_register (103)

rig_register (124)

rig_register (104)

rig_register (125)

rig_register (129)

rig_register (132)

rig_register (130)

rig_register (117)

rig_register (119)

rig_register (118)

rig_register (126)

rig_register (133)

rig_register (134)

rig_register (135)

ft991_init called

newcat_init called

rig:rig_open called

newcat_open called

newcat_set_trn called

newcat_valid_command called

newcat_valid_command: 'FT-991' is unknown

rig_open: error = Feature not available

 

C:\WSJT\wsjtx\bin>

  

 

De : Bill Somerville [mailto:g4...@classdesign.com] 
Envoyé : lundi 29 juin 2015 23:51
À : wsjt-devel@lists.sourceforge.net
Objet : Re: [wsjt-devel] WSJT-X and FT991 CAT issue

 

On 29/06/2015 22:21, f5djl wrote:

Hello to all 

Bon Soir Jean-Louis




 

Not sure if this report is more relevant to  Hamlib  or the WSJT team,  I am
testing  a  Yaesu FT-991 with WSJT-X  release 5636  mainly in WSPR-2 mode : 

 

  PC  : Windows 8.1Intel I7  8GB  Memory 

  TRX :   Yaesu FT 991  - USB connected 

  Drivers : CP_210X_windows  as per Yaesu site 

  Hambib3   Build from G4WJS Public using JTSDK-Mysys (29/06/2015)

 

Issue :  CAT not working 

In setting radio Windows :  Rig failure , Hamlib error : feature not
available while opening connection to rig . 

I have  tried  via command line rigctl an seems to get same issue ! 

To test with rigctl you must use the rigctl-wsjtx.exe that the WSJT-X
produces if you want to compare with the same Hamlib 3 rig drivers.




 

Am I using the correct version of Hamlib3  to build WSJT-X ?  is there some
further debug information I can provide you to assist with identification of
the issue? ( FYI exactly same code work like a charm with an FT897 and an
FTDI based interface) 

The easiest way to eliminate build issues is to try with the official v1.5.0
release, this has essentially the same Hamlib 3 code as the error you are
seeing is not mode specific.




 

Congratulations and thanks to all for the great job done in inclusion of
wspr mode in wsjt-x,  the enhancements to the wspr decoder are just terrific
! J

It is good! Congratulations to Steve and Joe.




 

Best regards 

 

Jean Louis   F5DJL

73
Bill
G4WJS.

 

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X and FT991 CAT issue - rigctl-wsjtx results

[f5djl]

Bill and Michael 

 

Thanks a lot for your advice and here below is the result of rigctl-wsjtx .

I will get the official version 1.5.0  installed tomorrow to confirm if I
get similar results. 

 

Very best regards 

 

Jean-Louis - F5DJL 

 

C:\WSJT\wsjtx\bin>rigctl-wsjtx - -m135 -scom5 f

rigctl, Hamlib 3.0~git

Report bugs to 

rig:rig_init called

yaesu: initrigs3_yaesu called

rig_register (121)

rig_register (127)

rig_register (110)

rig_register (105)

rig_register (106)

rig_register (107)

rig_register (109)

rig_register (120)

rig_register (101)

rig_register (122)

rig_register (123)

rig_register (111)

rig_register (115)

rig_register (113)

rig_register (114)

rig_register (128)

rig_register (131)

rig_register (116)

rig_register (103)

rig_register (124)

rig_register (104)

rig_register (125)

rig_register (129)

rig_register (132)

rig_register (130)

rig_register (117)

rig_register (119)

rig_register (118)

rig_register (126)

rig_register (133)

rig_register (134)

rig_register (135)

ft991_init called

newcat_init called

rig:rig_open called

newcat_open called

newcat_set_trn called

newcat_valid_command called

newcat_valid_command: 'FT-991' is unknown

rig_open: error = Feature not available

 

C:\WSJT\wsjtx\bin>

  

 

De : Bill Somerville [mailto:g4...@classdesign.com] 
Envoyé : lundi 29 juin 2015 23:51
À : wsjt-devel@lists.sourceforge.net
Objet : Re: [wsjt-devel] WSJT-X and FT991 CAT issue

 

On 29/06/2015 22:21, f5djl wrote:

Hello to all 

Bon Soir Jean-Louis



 

Not sure if this report is more relevant to  Hamlib  or the WSJT team,  I am
testing  a  Yaesu FT-991 with WSJT-X  release 5636  mainly in WSPR-2 mode : 

 

  PC  : Windows 8.1Intel I7  8GB  Memory 

  TRX :   Yaesu FT 991  - USB connected 

  Drivers : CP_210X_windows  as per Yaesu site 

  Hambib3   Build from G4WJS Public using JTSDK-Mysys (29/06/2015)

 

Issue :  CAT not working 

In setting radio Windows :  Rig failure , Hamlib error : feature not
available while opening connection to rig . 

I have  tried  via command line rigctl an seems to get same issue ! 

To test with rigctl you must use the rigctl-wsjtx.exe that the WSJT-X
produces if you want to compare with the same Hamlib 3 rig drivers.



 

Am I using the correct version of Hamlib3  to build WSJT-X ?  is there some
further debug information I can provide you to assist with identification of
the issue? ( FYI exactly same code work like a charm with an FT897 and an
FTDI based interface) 

The easiest way to eliminate build issues is to try with the official v1.5.0
release, this has essentially the same Hamlib 3 code as the error you are
seeing is not mode specific.



 

Congratulations and thanks to all for the great job done in inclusion of
wspr mode in wsjt-x,  the enhancements to the wspr decoder are just terrific
! J

It is good! Congratulations to Steve and Joe.



 

Best regards 

 

Jean Louis   F5DJL

73
Bill
G4WJS.

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJT-X and FT991 CAT issue

[f5djl]

Hello to all 

 

Not sure if this report is more relevant to  Hamlib  or the WSJT team,  I am
testing  a  Yaesu FT-991 with WSJT-X  release 5636  mainly in WSPR-2 mode : 

 

  PC  : Windows 8.1Intel I7  8GB  Memory 

  TRX :   Yaesu FT 991  - USB connected 

  Drivers : CP_210X_windows  as per Yaesu site 

  Hambib3   Build from G4WJS Public using JTSDK-Mysys (29/06/2015)

 

Issue :  CAT not working 

In setting radio Windows :  Rig failure , Hamlib error : feature not
available while opening connection to rig . 

I have  tried  via command line rigctl an seems to get same issue ! 

 

Am I using the correct version of Hamlib3  to build WSJT-X ?  is there some
further debug information I can provide you to assist with identification of
the issue? ( FYI exactly same code work like a charm with an FT897 and an
FTDI based interface) 

 

Congratulations and thanks to all for the great job done in inclusion of
wspr mode in wsjt-x,  the enhancements to the wspr decoder are just terrific
! J 

 

Best regards 

 

Jean Louis   F5DJL 

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel