[wsjt-devel] MSK144 Observationg

[Bill Ockert - ND0B]

Good morning Joe,

Thank you for all the great work you have been doing.  I am hoping my work 
slows down a bit so I can start contributing again.

Two quick observations on MSK144...

I note with SH ON the TX2 message is sent with the calls hashed.Considering 
the flow of the contact

ND0BK1JT
KIJT ND0B EN07   ->(receives ND0B TX1 so has RXed the calls)
(Has not RXed)<-  00

The hashed  version of the calls is not the calls and cannot be reverse decoded 
to the calls.  It is only a high probability of being unique for those calls, 
i.e. you cannot calculate the hash without already knowing the calls which in 
this case ND0B only knew because that is who he is working.  With K1JT sending 
the hashed version ND0B never actually decodes the calls, only the hash.   

Question:  Should TX2 be sent in the clear rather than hashed to fulfill the 
calls both ways part of the minimal QSO requirement???

Second I have started letting people know, it is important to run CW ID when 
using SH ON to meet the FCC rules requirements on IDing.

Thanks Joe, and again, thanks for all your (and everyone else's) great work.

73 de Bill ND0B

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] New mode JTMSK

[Bill Ockert - ND0B]

Thank you Joe!!

-Original Message- 
From: Joe Taylor
Sent: Friday, August 28, 2015 11:11 AM
To: WSJT software development
Subject: [wsjt-devel] New mode JTMSK

Hi all,

Many VHF users of WSJT-X are now playing with the new mode JTMSK.
I view this mode as a candidate replacement for FSK441 and JTMS, for all
meteor scatter work.

For some further details and a download link, see the info posted at
http://physics.princeton.edu/pulsar/K1JT/Fast_Modes.txt

As always, reports on the new experimental features in WSJT-X will be
very welcome.

-- 73, Joe, K1JT

--
___
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] File lockup issue

[Bill Ockert - ND0B]

Bill and George,

Thank you for the replies.   I will interact with Gary and find out if JT9.exe 
is running 
or if there is a process going under Details.

Yes, thia is the EXP version of WSJTX

Bill

From: Bill Somerville 
Sent: Tuesday, August 25, 2015 10:44 AM
To: wsjt-devel@lists.sourceforge.net 
Subject: Re: [wsjt-devel] File lockup issue

On 25/08/2015 16:33, Bill Ockert - ND0B wrote:

  Good morning / afternoon Bill
Hi Bill,


  Thank you for the reply!

  As you might note in Gary’s comments he is getting into the screen allowing 
deletion of the locked file but when he tells it to do so it comes right back 
to that screen.   He is not seeing WSJTXas a program in the task manager and 
(claims) that XT has no tab for processes so we were unable to check for that.  
 I believe he is ending up rebooting whenever this happens. 
IIRC (it's been a long time since I used XP) the full process list is available 
via a "Details..." button or similar and from there individual processes can be 
listed and controlled.

If the message is repeating then the lock file is almost certainly not stale 
and a prior wsjtx.exe process is still running.


  I am thinking the best route on this is to wait until Joe releases another 
experimental version and see if it goes away.
If someone can explain how to reproduce this issue and it can be reproduced on 
later Windows versions then I can easily diagnose it.

Can I assume we are talking about WSJT-X built from the ^/branches/wsjtx_exp 
repository branch here?


  Bill
73
Bill
G4WJS.






  From: Bill Somerville 
  Sent: Tuesday, August 25, 2015 9:37 AM
  To: wsjt-devel@lists.sourceforge.net 
  Subject: Re: [wsjt-devel] File lockup issue

  On 25/08/2015 15:15, Bill Ockert - ND0B wrote:

Good morning Joe,
  Hi Bill,


Don’t know if this got fixed in later versions but appears some folks are 
having an issue with a locked file in 5789.   This is on an XP machine.   
  I'll try and help since I implemented the lock file functionality.

  The intent is to disallow multiple identical instances of WSJT-X running 
concurrently. This is disallowed because it will not work due to the way that 
WSJT-X communicates with the associated program jt9.

  The message means that a prior instance of WSJT-X is still running or has 
crashed ungracefully. It is possible that a defect has been introduced that is 
stopping WSJT-X from closing down completely even though it may closed down all 
visible windows. For anyone seeing this issue I suggest that they check if more 
than one instance of WSJT-X is running by using Windows task manager or 
equivalent utility on other operating systems. Make this check while the 
message is showing before proceeding.

  If no second instance is running then it is possible that a crash is 
happening during shutdown before the lock file is removed.

  There is no need to manually delete the lock file since there is already an 
option to do that in the message box that pops up. The lock file is stored in 
the application temporary directory which on Windows is 
"%LOCALAPPDATA%\Temp\WSJT-X.lock" for a normal default instance of WSJT-X (not 
to be confused with "%LOCALAPPDATA%\Temp\WSJT-X\.lock" which has a dfifferent 
purpose).


Thanks!

73 de Bill ND0B

  73
  Bill
  G4WJS.


25Aug 14:02 AG0N/6M Gary NE DN81fv =>  Tnx. Is there anything I can do to 
get rid of the locked file problem that myself and others are having with the 
later revs of X ?
25Aug 14:03 ND0B/10THRU432 Bill ND EN07gn =>  Not familiar with that.  Can 
you give a few details?
25Aug 14:04 AG0N/6M Gary NE DN81fv =>  If I close down X and later reopen 
it, it won't run. Gives locked file error, allows me to try to get rid of old 
file but always fails, endless circle. Only cure is to reboot. If I knew where 
the loc
25Aug 14:04 AG0N/6M Gary NE DN81fv =>  ked file was, maybe I could manually 
kill it.
25Aug 14:05 AG0N/6M Gary NE DN81fv =>  this is on 5789
25Aug 14:06 ND0B/10THRU432 Bill ND EN07gn =>  rr I have been on vacation 
and have not even upgraded to 5789.   I wll forwared the info to Joe   





--




___
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] File lockup issue

[Bill Ockert - ND0B]

Good morning / afternoon Bill

Thank you for the reply!

As you might note in Gary’s comments he is getting into the screen allowing 
deletion of the locked file but when he tells it to do so it comes right back 
to that screen.   He is not seeing WSJTXas a program in the task manager and 
(claims) that XT has no tab for processes so we were unable to check for that.  
 I believe he is ending up rebooting whenever this happens. 

I am thinking the best route on this is to wait until Joe releases another 
experimental version and see if it goes away.

Bill





From: Bill Somerville 
Sent: Tuesday, August 25, 2015 9:37 AM
To: wsjt-devel@lists.sourceforge.net 
Subject: Re: [wsjt-devel] File lockup issue

On 25/08/2015 15:15, Bill Ockert - ND0B wrote:

  Good morning Joe,
Hi Bill,


  Don’t know if this got fixed in later versions but appears some folks are 
having an issue with a locked file in 5789.   This is on an XP machine.   
I'll try and help since I implemented the lock file functionality.

The intent is to disallow multiple identical instances of WSJT-X running 
concurrently. This is disallowed because it will not work due to the way that 
WSJT-X communicates with the associated program jt9.

The message means that a prior instance of WSJT-X is still running or has 
crashed ungracefully. It is possible that a defect has been introduced that is 
stopping WSJT-X from closing down completely even though it may closed down all 
visible windows. For anyone seeing this issue I suggest that they check if more 
than one instance of WSJT-X is running by using Windows task manager or 
equivalent utility on other operating systems. Make this check while the 
message is showing before proceeding.

If no second instance is running then it is possible that a crash is happening 
during shutdown before the lock file is removed.

There is no need to manually delete the lock file since there is already an 
option to do that in the message box that pops up. The lock file is stored in 
the application temporary directory which on Windows is 
"%LOCALAPPDATA%\Temp\WSJT-X.lock" for a normal default instance of WSJT-X (not 
to be confused with "%LOCALAPPDATA%\Temp\WSJT-X\.lock" which has a dfifferent 
purpose).


  Thanks!

  73 de Bill ND0B

73
Bill
G4WJS.


  25Aug 14:02 AG0N/6M Gary NE DN81fv =>  Tnx. Is there anything I can do to get 
rid of the locked file problem that myself and others are having with the later 
revs of X ?
  25Aug 14:03 ND0B/10THRU432 Bill ND EN07gn =>  Not familiar with that.  Can 
you give a few details?
  25Aug 14:04 AG0N/6M Gary NE DN81fv =>  If I close down X and later reopen it, 
it won't run. Gives locked file error, allows me to try to get rid of old file 
but always fails, endless circle. Only cure is to reboot. If I knew where the 
loc
  25Aug 14:04 AG0N/6M Gary NE DN81fv =>  ked file was, maybe I could manually 
kill it.
  25Aug 14:05 AG0N/6M Gary NE DN81fv =>  this is on 5789
  25Aug 14:06 ND0B/10THRU432 Bill ND EN07gn =>  rr I have been on vacation and 
have not even upgraded to 5789.   I wll forwared the info to Joe   






--




___
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] File lockup issue

[Bill Ockert - ND0B]

Good morning Joe,

Don’t know if this got fixed in later versions but appears some folks are 
having an issue with a locked file in 5789.   This is on an XP machine.   

Thanks!

73 de Bill ND0B


25Aug 14:02 AG0N/6M Gary NE DN81fv =>  Tnx. Is there anything I can do to get 
rid of the locked file problem that myself and others are having with the later 
revs of X ?
25Aug 14:03 ND0B/10THRU432 Bill ND EN07gn =>  Not familiar with that.  Can you 
give a few details?
25Aug 14:04 AG0N/6M Gary NE DN81fv =>  If I close down X and later reopen it, 
it won't run. Gives locked file error, allows me to try to get rid of old file 
but always fails, endless circle. Only cure is to reboot. If I knew where the 
loc
25Aug 14:04 AG0N/6M Gary NE DN81fv =>  ked file was, maybe I could manually 
kill it.
25Aug 14:05 AG0N/6M Gary NE DN81fv =>  this is on 5789
25Aug 14:06 ND0B/10THRU432 Bill ND EN07gn =>  rr I have been on vacation and 
have not even upgraded to 5789.   I wll forwared the info to Joe--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

[Bill Ockert - ND0B]

This discussion started out as a question as to if the auto sequencer could
respond to a specific non standard message and I digressed it.   My 
apologies.

Back to that original question...   I pseudo coded the WSJT auto sequencer 
in
order to document it in the manual.   One of my projects is looking through 
the
JT9 auto sequencer to see if there are any improvements to be made either
to either the ISCAT one or the JT9 one.   This is the pseudo code as it 
exists now...

if TX Auto is checked and Auto is On
if Current TX Sequence equals TX1
  if Received Message equals valid TX1
   Set Signal Report
   Advance to TX2
  else if Received Message equals valid TX2
   Set Signal Report
   Advance to TX3
else if Current TX Sequence equals TX2
  if Received Message equals valid TX2
   Set Signal Report
   Advance to TX3
  else if Received Message equals valid TX3
   Advance to TX4
else if Current TX Sequence equals TX3
  if Received Message equals valid TX3
   Advance to TX4
  else if Received Message equals TX4
   Set TXStopCount to Auto73Count
   Advance to TX5
   Set Log QSO to blink
else if Current TX Sequence equals TX4
  if Received Message equals valid TX4
   Set TXStopCount to Auto73Count
   Advance to TX5
   Set Log QSO to blink
  else if Received Message equals valid TX5
   Set TXStopCount to Auto73Count
   Advance to TX5
   Set Log QSO to blink
else if Current TX Sequence equals TX5
  if Received Message equals valid TX5
   Set TXStopCount to 0
   Set Auto is ON to Auto is OFF
  else if Received Message equals valid TX4
   Set TXStopCount to Auto73Count
  else
   Decrement TXStopCount
   if TXStopCount equals 0
Set Auto is ON to Auto is OFF

As you can see the auto sequencer is highly situational and the end game, 
when to
quit transmitting gets a little complicated.   There is an inherent catch 22 
that needs
to be dealt with and is to some degree in the pseudo code.  The reports I 
had during
the ISCAT craze this summer was that it was working OK.

The RR73 question really boils down to can the statement

if Received Message equals TX4

be modified to also recognize RR73 as a combined RRR and 73.   The answer is 
obviously yes
however in the context of the auto sequencer that really does not change 
much.  The
end game still needs to be played out so the station that sent RR73 is at 
some point
going to need to send a 73 anyway for things to gracefully stop under 
automatic
control.

Assuming we were to recognize RR73 as a valid RRR what else do we recognize? 
I have
seen variations of this such as R73, 73RR, etc.   This gets a little 
complicated and
someone will be left out.

Also a practice I have seen repeatedly is that of skipping the TX4 message
completely and going straight to TX5.   Should the auto sequencer recognize 
that as
valid?

My point, and my opinion for what it is worth, is that the auto sequencer 
should not
be in the business of attempting to recognize an infinite variation of 
possible
non standard messages.  That would  be a programming nightmare.   Once 
WSJT(x)
is set up with proper from and to calls (and possibly grid) the messages 
recognized by
the auto sequencer should be "by the book".  If the book changes, then and 
only then
should the auto sequencer change.

Does this mean non standard messages are not allowed?   No, it simply means 
they need
to be dealt with manually.   That leaves it up to the operator to decide if 
a non standard
message meets the QSO criteria for their station.

73 de Bill ND0B



by the auto sequencer should be fixed based on those standard messages.




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

Re: [wsjt-devel] Fw: sending RR73 message on JT9H voice fromDownunder

[Bill Ockert - ND0B]

Yes it does on the free form protocols like FSK, ISCAT, etc.On protocols 
with FEC like JT9 it is all (and exact) or nothing so is clear without any 
other conventions. 

From: Alan VK2ZIW 
Sent: Monday, August 24, 2015 8:24 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] Fw: sending RR73 message on JT9H voice fromDownunder

Hi all, 

We must ALWAYS send the sending callsign. Period. 

Downunder, we replace the " " (space) with a "/" between the receiving callsign 
and the report eg. 


VK3AMZ/26 VK2ZIW 26 

So, onlookers can figure out, in garbled MS messages, who's who. 

Does this make sense? 

Alan VK2ZIW 

On Mon, 24 Aug 2015 15:23:47 -0700, George J Molnar wrote 
> Agree, Bill. Auto-sequence should be the same as manual, and RR73 isn't a 
> good way to complete, nor is anything else that fails to include your 
> callsign. 
> 
> George J Molnar, CEM, CHPP 
> Nevada Statewide Interoperability Coordinator 

> @GJMolnar | KF2T | AFA9GM 
> 
> On Aug 24, 2015, at 3:18 PM, Bill Ockert - ND0B  wrote: 
> 
> 

  > 
  > Mike, 
  >   
  > No   I do treat RRR 73 as a valid ending when I handle it manually.  I 
treat RR73 as improper in both in content and in white space.  
  >   
  > Bill 
  > 
  >   
  > 
  > From: Michael Black 
  > Sent: Monday, August 24, 2015 4:53 PM 
  > To: Bill Ockert - ND0B ; WSJT software development 
  > Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer 
  >   
  > 
  > Just curious Bill -- do you treat RR73 as a valid QSO ending? 
  > About 7% of users use that according to my logs. 
  > 
  > Mike W9MDB 
  > 
  >   
  > On Mon, Aug 24, 2015 at 3:40 PM, Bill Ockert - ND0B  wrote: 
  > 
Jay, 
> 
> I do not view it as harsh.  Harsh was when I went off HF JT modes 
completely 
> for well over a year 
> because of it.   I am one of about five stations in ND that are on JT HF 
> modes, one 
> of about three on both JT HF modes and LOTW and one of  one on JT HF 
modes, 
> LOTW 
> and 12 and 160 meters.I get on about twice a year to help folks with 
> WAS,  I am 
> not a fan of HF period so it is generally not an enjoyable experience and 
I 
> get a 
> resentful when folks start counting teeth...  I already know I am about 
> ready for McDonalds 
> or the glue factory. 
> 
> Both the WSJT and WSJTX manual clearly state what is considered a minimal 
> QSO 
> and I am in complete agreement with it.   A QSO is complete when all of 
the 
> essential elements of if are complete and that includes one station 
> receiving an RRR. 
> 
> If others choose to use a different format that is purely their business 
> just as it 
> is mine to choose not to accept less than the published minimal contact. 
> At one point 
> I had a much more lenient policy about that which included sending TX3 a 
> second 
> time then emailing the station letting them know what the issue was and 
> offering a 
> retry.   However I was point blank told that I had no right to tell other 
> stations what 
> to transmit, I capitulated completely and now have a policy where I 
> terminate the contact 
> immediately upon deviation from the minimal QSO and do not offer a retry. 
> The person 
> who was doing the complaining called me a crazy old ^&%$#$% when I made 
the 
> change 
> so it must have been exactly the right thing to do. 
> 
> As a personal side note I was hoping to make it to 60 before that 
happened 
> but oh well... 
> 
> I believe if there is going to be an auto sequencer one of its functions 
> should be to 
> enforce the minimal QSO and not facilitate less than minimal QSOs.   That 
is 
> both 
> for integrity of the QSO reasons and because it would be a pain to 
program 
> all of the 
> variations that are floating around out there.   The only question mark 
> there should 
> be for an auto sequencer is how to gracefully shut down the contact.  
There 
> is a catch 22 in the logic to handle 73's that I believe is handled 
> reasonably well in the WSJT 
> ISCAT auto sequencer that I hope to move over the WSJTX. 
> 
> For those users who feel otherwise they can always override the auto 
> sequencer and advance 
> if they feel the auto sequencer was being too strict. 
> 
> 73 de Bill ND0B 
> 
> -Original Message- 
> From: Jay Hainline 
> Sent: Monday, August 24, 2015 2:13 PM 
> To: WSJT software development 
> Subject: Re: [wsjt-devel] sending RR73 message on JT

Re: [wsjt-devel] Fw: sending RR73 message on JT9H withauto sequencer

[Bill Ockert - ND0B]

Jay,

I concur completely on all points.  With JT9 there is NO ambiguity that the 
incorrect
message was sent.   I will feel even less bad about not logging those 
contacts.

Thank you for the discussion.

73 de Bill ND0B


-Original Message- 
From: Jay Hainline
Sent: Monday, August 24, 2015 6:42 PM
To: WSJT software development
Subject: Re: [wsjt-devel] Fw: sending RR73 message on JT9H withauto 
sequencer

Bill I know what constitutes a QSO. I always use the standard messages
myself. However this QSO was using the JT9H mode with FEC. There is no
mistake in what was sent and received. There is no partials involved like
there is in ISCAT or FSK441 modes. It's either all or nothing. I think that
needs to be considered. If it is such a big deal, then why isnt WSJTX
hardcoded with the standard messages so they cannot be changed?

This is the final word from me on this subject. Time to move on.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: Bill Ockert - ND0B
Sent: Monday, August 24, 2015 23:27
To: WSJT software development
Subject: Re: [wsjt-devel] Fw: sending RR73 message on JT9H withauto
sequencer


Jay,

From the WSJTX manual...

By longstanding tradition, a minimal valid QSO requires the exchange of
callsigns, a signal report or some other information, and acknowledgments.
WSJT-X is designed to facilitate making such minimal QSOs using short,
formatted messages. The process works best if you use them and follow
standard operating practices. The recommended basic QSO goes something like
this:

1. CQ K1ABC FN42
2. K1ABC G0XYZ IO91
3. G0XYZ K1ABC –19
4. K1ABC G0XYZ R-22
5. G0XYZ K1ABC RRR
6. K1ABC G0XYZ 73

The messages suggested and in fact the messages that WSJTX (and WSJT)
generate reflect RRR as the long standing minimal acknowledgement.

The manual is clear, the software is clear and the effort to do it that was
is actually less than doing it the other way... no messages to change every
time you change modes.

Bill


From: Jay Hainline
Sent: Monday, August 24, 2015 5:40 PM
To: WSJT software development
Subject: Re: [wsjt-devel] Fw: sending RR73 message on JT9H withauto
sequencer

Just to clarify, the line contained both calls and RR73. This was AFTER
reports had been sent both ways. So I don't know what the difference would
be in receiving 2 "Rogers" instead of 3. :-)



Jay KA9CFD

Sent from my U.S. Cellular® Smartphone


 Original message 
From: George J Molnar 
Date: 08/24/2015 5:23 PM (GMT-06:00)
To: Bill Ockert - ND0B , WSJT software development

Subject: Re: [wsjt-devel] Fw: sending RR73 message on JT9H with auto
sequencer


Agree, Bill. Auto-sequence should be the same as manual, and RR73 isn't a
good way to complete, nor is anything else that fails to include your
callsign.



George J Molnar, CEM, CHPP
Nevada Statewide Interoperability Coordinator

@GJMolnar | KF2T | AFA9GM

On Aug 24, 2015, at 3:18 PM, Bill Ockert - ND0B  wrote:


Mike,

No   I do treat RRR 73 as a valid ending when I handle it manually.  I treat
RR73 as improper in both in content and in white space.

Bill


From: Michael Black
Sent: Monday, August 24, 2015 4:53 PM
To: Bill Ockert - ND0B ; WSJT software development
Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

Just curious Bill -- do you treat RR73 as a valid QSO ending?
About 7% of users use that according to my logs.

Mike W9MDB

On Mon, Aug 24, 2015 at 3:40 PM, Bill Ockert - ND0B  wrote:
Jay,

I do not view it as harsh.  Harsh was when I went off HF JT modes completely
for well over a year
because of it.   I am one of about five stations in ND that are on JT HF
modes, one
of about three on both JT HF modes and LOTW and one of  one on JT HF modes,
LOTW
and 12 and 160 meters.I get on about twice a year to help folks with
WAS,  I am
not a fan of HF period so it is generally not an enjoyable experience and I
get a
resentful when folks start counting teeth...  I already know I am about
ready for McDonalds
or the glue factory.

Both the WSJT and WSJTX manual clearly state what is considered a minimal
QSO
and I am in complete agreement with it.   A QSO is complete when all of the
essential elements of if are complete and that includes one station
receiving an RRR.

If others choose to use a different format that is purely their business
just as it
is mine to choose not to accept less than the published minimal contact.
At one point
I had a much more lenient policy about that which included sending TX3 a
second
time then emailing the station letting them know what the issue was and
offering a
retry.   However I was point blank told that I had no right to tell other
stations what
to transmit, I capitulated completely and now have a policy where I
terminate the contact
immediately upon deviation from the minimal QSO and do not offer a retry.
The person
who was doing the complaining called me a crazy old ^&%$#$% when I made the
change
so it must have been 

Re: [wsjt-devel] Fw: sending RR73 message on JT9H withauto sequencer

[Bill Ockert - ND0B]

Jay,

>From the WSJTX manual...

By longstanding tradition, a minimal valid QSO requires the exchange of 
callsigns, a signal report or some other information, and acknowledgments. 
WSJT-X is designed to facilitate making such minimal QSOs using short, 
formatted messages. The process works best if you use them and follow standard 
operating practices. The recommended basic QSO goes something like this: 

1. CQ K1ABC FN42 
2. K1ABC G0XYZ IO91 
3. G0XYZ K1ABC –19 
4. K1ABC G0XYZ R-22 
5. G0XYZ K1ABC RRR 
6. K1ABC G0XYZ 73 

The messages suggested and in fact the messages that WSJTX (and WSJT) generate 
reflect RRR as the long standing minimal acknowledgement. 

The manual is clear, the software is clear and the effort to do it that was is 
actually less than doing it the other way... no messages to change every time 
you change modes.  

Bill


From: Jay Hainline 
Sent: Monday, August 24, 2015 5:40 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] Fw: sending RR73 message on JT9H withauto sequencer

Just to clarify, the line contained both calls and RR73. This was AFTER reports 
had been sent both ways. So I don't know what the difference would be in 
receiving 2 "Rogers" instead of 3. :-)



Jay KA9CFD 

Sent from my U.S. Cellular® Smartphone


 Original message 
From: George J Molnar  
Date: 08/24/2015 5:23 PM (GMT-06:00) 
To: Bill Ockert - ND0B , WSJT software development 
 
Subject: Re: [wsjt-devel] Fw: sending RR73 message on JT9H with auto sequencer 


Agree, Bill. Auto-sequence should be the same as manual, and RR73 isn't a good 
way to complete, nor is anything else that fails to include your callsign.



George J Molnar, CEM, CHPP 
Nevada Statewide Interoperability Coordinator

@GJMolnar | KF2T | AFA9GM

On Aug 24, 2015, at 3:18 PM, Bill Ockert - ND0B  wrote:


  Mike,

  No   I do treat RRR 73 as a valid ending when I handle it manually.  I treat 
RR73 as improper in both in content and in white space.  

  Bill

  From: Michael Black 
  Sent: Monday, August 24, 2015 4:53 PM
  To: Bill Ockert - ND0B ; WSJT software development 
  Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

  Just curious Bill -- do you treat RR73 as a valid QSO ending?

  About 7% of users use that according to my logs.


  Mike W9MDB


  On Mon, Aug 24, 2015 at 3:40 PM, Bill Ockert - ND0B  wrote:

Jay,

I do not view it as harsh.  Harsh was when I went off HF JT modes completely
for well over a year
because of it.   I am one of about five stations in ND that are on JT HF
modes, one
of about three on both JT HF modes and LOTW and one of  one on JT HF modes,
LOTW
and 12 and 160 meters.I get on about twice a year to help folks with
WAS,  I am
not a fan of HF period so it is generally not an enjoyable experience and I
get a
resentful when folks start counting teeth...  I already know I am about
ready for McDonalds
or the glue factory.

Both the WSJT and WSJTX manual clearly state what is considered a minimal
QSO
and I am in complete agreement with it.   A QSO is complete when all of the
essential elements of if are complete and that includes one station
receiving an RRR.

If others choose to use a different format that is purely their business
just as it
is mine to choose not to accept less than the published minimal contact.
At one point
I had a much more lenient policy about that which included sending TX3 a
second
time then emailing the station letting them know what the issue was and
offering a
retry.   However I was point blank told that I had no right to tell other
stations what
to transmit, I capitulated completely and now have a policy where I
terminate the contact
immediately upon deviation from the minimal QSO and do not offer a retry.
The person
who was doing the complaining called me a crazy old ^&%$#$% when I made the
change
so it must have been exactly the right thing to do.

As a personal side note I was hoping to make it to 60 before that happened
but oh well...

I believe if there is going to be an auto sequencer one of its functions
should be to
enforce the minimal QSO and not facilitate less than minimal QSOs.   That is
both
for integrity of the QSO reasons and because it would be a pain to program
all of the
variations that are floating around out there.   The only question mark
there should
be for an auto sequencer is how to gracefully shut down the contact.  There
is a catch 22 in the logic to handle 73's that I believe is handled
reasonably well in the WSJT
ISCAT auto sequencer that I hope to move over the WSJTX.

For those users who feel otherwise they can always override the auto
sequencer and advance
if they feel the auto sequencer was being too strict.

73 de Bill ND0B


-Original Mes

[wsjt-devel] Fw: sending RR73 message on JT9H with auto sequencer

[Bill Ockert - ND0B]

Mike,

No   I do treat RRR 73 as a valid ending when I handle it manually.  I treat 
RR73 as improper in both in content and in white space.  

Bill

From: Michael Black 
Sent: Monday, August 24, 2015 4:53 PM
To: Bill Ockert - ND0B ; WSJT software development 
Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

Just curious Bill -- do you treat RR73 as a valid QSO ending?

About 7% of users use that according to my logs.


Mike W9MDB


On Mon, Aug 24, 2015 at 3:40 PM, Bill Ockert - ND0B  wrote:

  Jay,

  I do not view it as harsh.  Harsh was when I went off HF JT modes completely
  for well over a year
  because of it.   I am one of about five stations in ND that are on JT HF
  modes, one
  of about three on both JT HF modes and LOTW and one of  one on JT HF modes,
  LOTW
  and 12 and 160 meters.I get on about twice a year to help folks with
  WAS,  I am
  not a fan of HF period so it is generally not an enjoyable experience and I
  get a
  resentful when folks start counting teeth...  I already know I am about
  ready for McDonalds
  or the glue factory.

  Both the WSJT and WSJTX manual clearly state what is considered a minimal
  QSO
  and I am in complete agreement with it.   A QSO is complete when all of the
  essential elements of if are complete and that includes one station
  receiving an RRR.

  If others choose to use a different format that is purely their business
  just as it
  is mine to choose not to accept less than the published minimal contact.
  At one point
  I had a much more lenient policy about that which included sending TX3 a
  second
  time then emailing the station letting them know what the issue was and
  offering a
  retry.   However I was point blank told that I had no right to tell other
  stations what
  to transmit, I capitulated completely and now have a policy where I
  terminate the contact
  immediately upon deviation from the minimal QSO and do not offer a retry.
  The person
  who was doing the complaining called me a crazy old ^&%$#$% when I made the
  change
  so it must have been exactly the right thing to do.

  As a personal side note I was hoping to make it to 60 before that happened
  but oh well...

  I believe if there is going to be an auto sequencer one of its functions
  should be to
  enforce the minimal QSO and not facilitate less than minimal QSOs.   That is
  both
  for integrity of the QSO reasons and because it would be a pain to program
  all of the
  variations that are floating around out there.   The only question mark
  there should
  be for an auto sequencer is how to gracefully shut down the contact.  There
  is a catch 22 in the logic to handle 73's that I believe is handled
  reasonably well in the WSJT
  ISCAT auto sequencer that I hope to move over the WSJTX.

  For those users who feel otherwise they can always override the auto
  sequencer and advance
  if they feel the auto sequencer was being too strict.

  73 de Bill ND0B


  -Original Message-
  From: Jay Hainline
  Sent: Monday, August 24, 2015 2:13 PM
  To: WSJT software development
  Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

  Not logging it? That seems a little harsh. The sequencing was correct up to
  that point. He had already received my R-signal report from me and just
  bunched the RR73 into one transmit sequence. All I wanted to do was send the
  73 transmission but for QSO purposes, it was complete at that point. I did
  manually send the 73 sequence and the QSO was logged.

  73 Jay

  Jay Hainline KA9CFD
  Colchester, IL EN40om

  -Original Message-
  From: Bill Ockert - ND0B
  Sent: Monday, August 24, 2015 15:54
  To: wsjt-devel@lists.sourceforge.net
  Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

  The auto sequencer, while it should not have gone back to TX2, actually
  acted in a
  benign manner compared to what I would have done manually, namely ended the
  contact
  without the  benefit of logging it.

  73 de Bill ND0B


  -Original Message-
  From: Jay Hainline
  Sent: Monday, August 24, 2015 6:56 AM
  To: wsjt-devel@lists.sourceforge.net
  Subject: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

  I had a small issue this morning working a station on 6 meters using
  WSJTX-devel r5808 using JT9H mode and auto sequencing. The station I was
  running with sent calls followed by RR73 programmed in the TX4 message
  button. The auto sequencer on my end got confused by this and went back to
  TX2 to send the report again. I was wondering if this is something where the
  auto sequencer can be programmed to be a little more flexible? I think if I
  copy either RRR or RR73, it should go to transmit TX5 which I have as
  sending calls and 73.

  The station I ran with says he is using version r5803 and claims RR73 was
  pre-set for TX4 inside that particular version he downloaded. My WSJTX 1.6.1
  copy has always had TX4 p

Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

[Bill Ockert - ND0B]

Jay,

No toes stepped on.   I am actually quite surprised the discussion is about 
setting
the auto sequencer up to complete on less than minimal contacts.  I fully
expected instead to be having a discussion about the legitimacy of the
auto sequencer in general.

Bill



-Original Message- 
From: Jay Hainline
Sent: Monday, August 24, 2015 4:01 PM
To: WSJT software development
Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

I am not the one that sent RR73. I just try and get along and use common
sense to complete the contact. :-)

It's too bad the world cant agree on a global standard for the sequences
which is the base of the issue. People think they want to tinker with it. I
just thought it might be good to think about how the auto sequence works.

Nevermind if I stepped on a toe.

73 Jay KA9CFD

-Original Message- 
From: Bill Ockert - ND0B
Sent: Monday, August 24, 2015 3:40 PM
To: WSJT software development
Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

Jay,

I do not view it as harsh.  Harsh was when I went off HF JT modes completely
for well over a year
because of it.   I am one of about five stations in ND that are on JT HF
modes, one
of about three on both JT HF modes and LOTW and one of  one on JT HF modes,
LOTW
and 12 and 160 meters.I get on about twice a year to help folks with
WAS,  I am
not a fan of HF period so it is generally not an enjoyable experience and I
get a
resentful when folks start counting teeth...  I already know I am about
ready for McDonalds
or the glue factory.

Both the WSJT and WSJTX manual clearly state what is considered a minimal
QSO
and I am in complete agreement with it.   A QSO is complete when all of the
essential elements of if are complete and that includes one station
receiving an RRR.

If others choose to use a different format that is purely their business
just as it
is mine to choose not to accept less than the published minimal contact.
At one point
I had a much more lenient policy about that which included sending TX3 a
second
time then emailing the station letting them know what the issue was and
offering a
retry.   However I was point blank told that I had no right to tell other
stations what
to transmit, I capitulated completely and now have a policy where I
terminate the contact
immediately upon deviation from the minimal QSO and do not offer a retry.
The person
who was doing the complaining called me a crazy old ^&%$#$% when I made the
change
so it must have been exactly the right thing to do.

As a personal side note I was hoping to make it to 60 before that happened
but oh well...

I believe if there is going to be an auto sequencer one of its functions
should be to
enforce the minimal QSO and not facilitate less than minimal QSOs.   That is
both
for integrity of the QSO reasons and because it would be a pain to program
all of the
variations that are floating around out there.   The only question mark
there should
be for an auto sequencer is how to gracefully shut down the contact.  There
is a catch 22 in the logic to handle 73's that I believe is handled
reasonably well in the WSJT
ISCAT auto sequencer that I hope to move over the WSJTX.

For those users who feel otherwise they can always override the auto
sequencer and advance
if they feel the auto sequencer was being too strict.

73 de Bill ND0B


-Original Message- 
From: Jay Hainline
Sent: Monday, August 24, 2015 2:13 PM
To: WSJT software development
Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

Not logging it? That seems a little harsh. The sequencing was correct up to
that point. He had already received my R-signal report from me and just
bunched the RR73 into one transmit sequence. All I wanted to do was send the
73 transmission but for QSO purposes, it was complete at that point. I did
manually send the 73 sequence and the QSO was logged.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message----- 
From: Bill Ockert - ND0B
Sent: Monday, August 24, 2015 15:54
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

The auto sequencer, while it should not have gone back to TX2, actually
acted in a
benign manner compared to what I would have done manually, namely ended the
contact
without the  benefit of logging it.

73 de Bill ND0B


-Original Message- 
From: Jay Hainline
Sent: Monday, August 24, 2015 6:56 AM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

I had a small issue this morning working a station on 6 meters using
WSJTX-devel r5808 using JT9H mode and auto sequencing. The station I was
running with sent calls followed by RR73 programmed in the TX4 message
button. The auto sequencer on my end got confused by this and went back to
TX2 to send the report again. I was wondering if this is something where the
auto se

Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

[Bill Ockert - ND0B]

Jay,

I do not view it as harsh.  Harsh was when I went off HF JT modes completely 
for well over a year
because of it.   I am one of about five stations in ND that are on JT HF 
modes, one
of about three on both JT HF modes and LOTW and one of  one on JT HF modes, 
LOTW
and 12 and 160 meters.I get on about twice a year to help folks with 
WAS,  I am
not a fan of HF period so it is generally not an enjoyable experience and I 
get a
resentful when folks start counting teeth...  I already know I am about 
ready for McDonalds
or the glue factory.

Both the WSJT and WSJTX manual clearly state what is considered a minimal 
QSO
and I am in complete agreement with it.   A QSO is complete when all of the
essential elements of if are complete and that includes one station 
receiving an RRR.

If others choose to use a different format that is purely their business 
just as it
is mine to choose not to accept less than the published minimal contact. 
At one point
I had a much more lenient policy about that which included sending TX3 a 
second
time then emailing the station letting them know what the issue was and 
offering a
retry.   However I was point blank told that I had no right to tell other 
stations what
to transmit, I capitulated completely and now have a policy where I 
terminate the contact
immediately upon deviation from the minimal QSO and do not offer a retry. 
The person
who was doing the complaining called me a crazy old ^&%$#$% when I made the 
change
so it must have been exactly the right thing to do.

As a personal side note I was hoping to make it to 60 before that happened 
but oh well...

I believe if there is going to be an auto sequencer one of its functions 
should be to
enforce the minimal QSO and not facilitate less than minimal QSOs.   That is 
both
for integrity of the QSO reasons and because it would be a pain to program 
all of the
variations that are floating around out there.   The only question mark 
there should
be for an auto sequencer is how to gracefully shut down the contact.  There
is a catch 22 in the logic to handle 73's that I believe is handled 
reasonably well in the WSJT
ISCAT auto sequencer that I hope to move over the WSJTX.

For those users who feel otherwise they can always override the auto 
sequencer and advance
if they feel the auto sequencer was being too strict.

73 de Bill ND0B


-Original Message- 
From: Jay Hainline
Sent: Monday, August 24, 2015 2:13 PM
To: WSJT software development
Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

Not logging it? That seems a little harsh. The sequencing was correct up to
that point. He had already received my R-signal report from me and just
bunched the RR73 into one transmit sequence. All I wanted to do was send the
73 transmission but for QSO purposes, it was complete at that point. I did
manually send the 73 sequence and the QSO was logged.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message- 
From: Bill Ockert - ND0B
Sent: Monday, August 24, 2015 15:54
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

The auto sequencer, while it should not have gone back to TX2, actually
acted in a
benign manner compared to what I would have done manually, namely ended the
contact
without the  benefit of logging it.

73 de Bill ND0B


-Original Message- 
From: Jay Hainline
Sent: Monday, August 24, 2015 6:56 AM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

I had a small issue this morning working a station on 6 meters using
WSJTX-devel r5808 using JT9H mode and auto sequencing. The station I was
running with sent calls followed by RR73 programmed in the TX4 message
button. The auto sequencer on my end got confused by this and went back to
TX2 to send the report again. I was wondering if this is something where the
auto sequencer can be programmed to be a little more flexible? I think if I
copy either RRR or RR73, it should go to transmit TX5 which I have as
sending calls and 73.

The station I ran with says he is using version r5803 and claims RR73 was
pre-set for TX4 inside that particular version he downloaded. My WSJTX 1.6.1
copy has always had TX4 programmed with calls and RRR.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om



--
___
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] sending RR73 message on JT9H with auto sequencer

[Bill Ockert - ND0B]

The auto sequencer, while it should not have gone back to TX2, actually 
acted in a
benign manner compared to what I would have done manually, namely ended the 
contact
without the  benefit of logging it.

73 de Bill ND0B


-Original Message- 
From: Jay Hainline
Sent: Monday, August 24, 2015 6:56 AM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] sending RR73 message on JT9H with auto sequencer

I had a small issue this morning working a station on 6 meters using
WSJTX-devel r5808 using JT9H mode and auto sequencing. The station I was
running with sent calls followed by RR73 programmed in the TX4 message
button. The auto sequencer on my end got confused by this and went back to
TX2 to send the report again. I was wondering if this is something where the
auto sequencer can be programmed to be a little more flexible? I think if I
copy either RRR or RR73, it should go to transmit TX5 which I have as
sending calls and 73.

The station I ran with says he is using version r5803 and claims RR73 was
pre-set for TX4 inside that particular version he downloaded. My WSJTX 1.6.1
copy has always had TX4 programmed with calls and RRR.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om



--
___
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] A few JT9 Comments

[Bill Ockert - ND0B]

Joe,

I updated the users guide pages for WSJT to include a section on the auto 
sequencer.   It includes a pseudo code description of how the iscat auto 
sequencer works.   It is in the doc directory of the latest check-ins.

Thanks for the other comments.   I look forward to the FEC version of JTMS.

73 de Bill ND0B



-Original Message- 
From: Joe Taylor
Sent: Tuesday, August 11, 2015 1:16 PM
To: Bill Ockert - ND0B ; WSJT software development
Subject: Re: A few JT9 Comments

Hi Bill,

I'm moving this discussion to wsjt-devel, since others will be interested.

Many thanks for the comments.  Obviously I need to deal with some issues
you had already solved, for ISCAT.

> 1. I was calling CQ and W3ZUP answered me while I had the auto sequencer
> enable. I would not expect the auto sequencer to do anything in that
> instance (I do not respond automatically to CQ replies with what I did
> with ISCAT) When W3ZUP answered the auto sequencer jumped to TX1 but
> without updating the call so still had call from last QSO.

I should have insisted that a message must contain both "MyCall" and
"HisCall" for the auto-sequencer to take any action.

> 2. I double clicked on W3ZUP to get his call into the next messages. My
> next decoded was of both W3ZUP calling me and of KB7IJ calling W3ZUP.
> The auto sequencer changed the call to KB7IJ and moved me back to TX1
> calling him.

Ditto to above.

> It is my thought that the auto sequencer should not answer CQs nor
> should it be changing the DX Call.

Yes, that's important, too.

> I was quite surprised to see the double decode as they were right on top
> of each other. They were very similar in signal strength.

The decoder looks intentionally for multiple messages -- possibly
different stations, possibly a message that was changed in mid-transmission.

There's another possibility, too -- not presently implemented in JT9,
but in everyday use with WSPR.  After one of these tightly defined
messages is decoded, we know exactly what the Tx waveform was (up to
small shifts in frequency and time, and possibly a small frequency
drift).  That waveform can be subtracted from the received time-domain
data, and then another decoding attempt made.  With WSPR, it works like
a charm -- and often finds additional good decodes.

> Just curious if it would be possible to have variants of JT9G and H with
> the same bandwidth but with the nsps dropped down into the 12 (or so)
> range so t_msg is short enough to accommodate meteor scatter on 144 and
> 222? I understand the s/n advantage would drop accordingly but pings,
> especially on 222, tend to be strong but very short.

No, because the tones for each submode already have the closest usable
spacing -- equal to the baud rate.

But I am looking at another possibility: an extension to the JTMS
protocol that would include FEC and standard messages like those in JT9.
  Might be able to try that within a week or so.

-- Joe 


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

[wsjt-devel] A few JT9 Comments

[Bill Ockert - ND0B]

Joe,

A couple of things on the auto sequencer

1.   I was calling CQ and W3ZUP answered me while I had the auto sequencer 
enable.   I would not expect the auto sequencer to do anything in that 
instance (I do not respond automatically to CQ replies with what I did with 
ISCAT)When W3ZUP answered the auto sequencer jumped to TX1 but without 
updating the call so still had call from last QSO.

2.  I double clicked on W3ZUP to get his call into the next messages.My 
next decoded was of both W3ZUP calling me and of KB7IJ calling W3ZUP.   The 
auto sequencer changed the call to KB7IJ and moved me back to TX1 calling 
him.

It is my thought that the auto sequencer should not answer CQs nor should it 
be changing the DX Call.

I was quite surprised to see the double decode as they were right on top of 
each other.   They were very similar in signal strength.

Just curious if it would be possible to have variants of JT9G and H with the 
same bandwidth but with the nsps dropped down into the 12 (or so) range so 
t_msg is short enough to accommodate meteor scatter on 144 and 222?   I 
understand the s/n advantage would drop accordingly but pings, especially on 
222, tend to be strong but very short.

Thank you for all the work Joe, much appreciated.

73 de Bill ND0B




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

Re: [wsjt-devel] WSJT Experimental Release r5755 Available

[Bill Ockert - ND0B]

Everyone,

With Gregs help I have successfully updated to V2 of the development 
environment.   This
should hopefully keep future issues like this from happening.

73 de Bill ND0B


-Original Message- 
From: Bill Ockert - ND0B
Sent: Thursday, August 06, 2015 12:09 PM
To: WSJT software development ; Greg Beam
Subject: Re: [wsjt-devel] WSJT Experimental Release r5755 Available

Also fixed

-Original Message- 
From: Greg Beam
Sent: Thursday, August 06, 2015 11:31 AM
To: Bill Ockert - ND0B ; WSJT software development
Subject: Re: [wsjt-devel] WSJT Experimental Release r5755 Available

Hi Bill, All,

I forgot to add, the wsjt-main.adoc file also needs fixing

It should state:

include::../common/links.adoc[]

not

include::../../global/license.adoc[]

This looks to be another v1 edit that breaks v2 builds.

73's
Greg, KI7MT


On 8/6/2015 9:27 AM, Bill Ockert - ND0B wrote:
> Jay,
>
> It should be but I will be the very first to admit that I am a blind user
> of
> the development environment (not correctly
> as it turns out) so I could have done something wrong.
>
> There is one new file FSKParameters.f90 that I added and that "appeared"
> to
> check in OK.   Is that the one it is
> complaining about?  It is an include file so the make file are currently
> unaware it even exists.
>
> Thanks
>
> 73 de Bill ND0B
>
>
>
>
> -Original Message-
> From: Jay Hainline
> Sent: Thursday, August 06, 2015 7:11 AM
> To: WSJT software development
> Subject: Re: [wsjt-devel] WSJT Experimental Release r5755 Available
>
> Is this new version of WSJT available through JTSDK-PY? When I try and
> build, I get an error message that a file cannot be found.
>
> 73 Jay
>
> Jay Hainline KA9CFD
> Colchester, IL EN40om
>
> -Original Message-
> From: Bill Ockert - ND0B
> Sent: Wednesday, August 05, 2015 20:45
> To: WSJT Developers ; wsjtgr...@yahoogroups.com ; K1JT
> Subject: [wsjt-devel] WSJT Experimental Release r5755 Available
>
>
> Good Afternoon/Morning/Evening Everyone
>
> WSJT Experimental Release r5755 and associated manual are now available on
> the shared google drive
>
> https://drive.google.com/folderview?id=0B42rF4Jby8-vfjd0dl9udXNTOVlOa1hnQldVeFg2c05LZkhIOUhONEprdExiYndwaFJCZkU&usp=sharing
>
> As has been the norm for these experimental versions this is a zip of the
> directory not an installer.   Most folks find it works well to replace
> the bin directory in their current WSJT 10.0 installation with the bin
> directory from this experimental release.   Be sure to keep a copy of
> your old bin directory in a safe place and always be sure to preserver
> your
> call3.txt file.
>
> This version contains the following fixes / enhancements over r5639 the
> previous experimental release:
>
> 1.  A few minor ISCAT cosmetic changes.
> 2.  The ISCAT auto sequencer now looks for the strongest matching decode
> and
> reports that instead of the first one it finds.
> 3.  ISCAT auto configuration now only occurs if the information block
> itself
> is clicked on.   Clicking on the call will only update To Radio
> and not the system parameters.   Clicking on the information block updates
> everything.
> 4.  This version includes a variation of FSK441 called FSK315.   FSK315 is
> legal on 10m under the current FCC rules.
>
> If you have any questions or comments please contact me either on the
> lists
> or directly at n...@ockert.us
>
> 73 de Bill ND0B
>
>
>
>
>
>
> --
>
>
>
>
>
>
> ___
> 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
>


--
___
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 Experimental Release r5755 Available

[Bill Ockert - ND0B]

Also fixed

-Original Message- 
From: Greg Beam
Sent: Thursday, August 06, 2015 11:31 AM
To: Bill Ockert - ND0B ; WSJT software development
Subject: Re: [wsjt-devel] WSJT Experimental Release r5755 Available

Hi Bill, All,

I forgot to add, the wsjt-main.adoc file also needs fixing

It should state:

include::../common/links.adoc[]

not

include::../../global/license.adoc[]

This looks to be another v1 edit that breaks v2 builds.

73's
Greg, KI7MT


On 8/6/2015 9:27 AM, Bill Ockert - ND0B wrote:
> Jay,
>
> It should be but I will be the very first to admit that I am a blind user 
> of
> the development environment (not correctly
> as it turns out) so I could have done something wrong.
>
> There is one new file FSKParameters.f90 that I added and that "appeared" 
> to
> check in OK.   Is that the one it is
> complaining about?  It is an include file so the make file are currently
> unaware it even exists.
>
> Thanks
>
> 73 de Bill ND0B
>
>
>
>
> -Original Message-
> From: Jay Hainline
> Sent: Thursday, August 06, 2015 7:11 AM
> To: WSJT software development
> Subject: Re: [wsjt-devel] WSJT Experimental Release r5755 Available
>
> Is this new version of WSJT available through JTSDK-PY? When I try and
> build, I get an error message that a file cannot be found.
>
> 73 Jay
>
> Jay Hainline KA9CFD
> Colchester, IL EN40om
>
> -Original Message-
> From: Bill Ockert - ND0B
> Sent: Wednesday, August 05, 2015 20:45
> To: WSJT Developers ; wsjtgr...@yahoogroups.com ; K1JT
> Subject: [wsjt-devel] WSJT Experimental Release r5755 Available
>
>
> Good Afternoon/Morning/Evening Everyone
>
> WSJT Experimental Release r5755 and associated manual are now available on
> the shared google drive
>
> https://drive.google.com/folderview?id=0B42rF4Jby8-vfjd0dl9udXNTOVlOa1hnQldVeFg2c05LZkhIOUhONEprdExiYndwaFJCZkU&usp=sharing
>
> As has been the norm for these experimental versions this is a zip of the
> directory not an installer.   Most folks find it works well to replace
> the bin directory in their current WSJT 10.0 installation with the bin
> directory from this experimental release.   Be sure to keep a copy of
> your old bin directory in a safe place and always be sure to preserver 
> your
> call3.txt file.
>
> This version contains the following fixes / enhancements over r5639 the
> previous experimental release:
>
> 1.  A few minor ISCAT cosmetic changes.
> 2.  The ISCAT auto sequencer now looks for the strongest matching decode 
> and
> reports that instead of the first one it finds.
> 3.  ISCAT auto configuration now only occurs if the information block 
> itself
> is clicked on.   Clicking on the call will only update To Radio
> and not the system parameters.   Clicking on the information block updates
> everything.
> 4.  This version includes a variation of FSK441 called FSK315.   FSK315 is
> legal on 10m under the current FCC rules.
>
> If you have any questions or comments please contact me either on the 
> lists
> or directly at n...@ockert.us
>
> 73 de Bill ND0B
>
>
>
>
>
>
> --
>
>
>
>
>
>
> ___
> 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
> 


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

Re: [wsjt-devel] WSJT Experimental Release r5755 Available

[Bill Ockert - ND0B]

Jay,

It should be but I will be the very first to admit that I am a blind user of 
the development environment (not correctly
as it turns out) so I could have done something wrong.

There is one new file FSKParameters.f90 that I added and that "appeared" to 
check in OK.   Is that the one it is
complaining about?  It is an include file so the make file are currently 
unaware it even exists.

Thanks

73 de Bill ND0B




-Original Message- 
From: Jay Hainline
Sent: Thursday, August 06, 2015 7:11 AM
To: WSJT software development
Subject: Re: [wsjt-devel] WSJT Experimental Release r5755 Available

Is this new version of WSJT available through JTSDK-PY? When I try and
build, I get an error message that a file cannot be found.

73 Jay

Jay Hainline KA9CFD
Colchester, IL EN40om

-Original Message----- 
From: Bill Ockert - ND0B
Sent: Wednesday, August 05, 2015 20:45
To: WSJT Developers ; wsjtgr...@yahoogroups.com ; K1JT
Subject: [wsjt-devel] WSJT Experimental Release r5755 Available


Good Afternoon/Morning/Evening Everyone

WSJT Experimental Release r5755 and associated manual are now available on
the shared google drive

https://drive.google.com/folderview?id=0B42rF4Jby8-vfjd0dl9udXNTOVlOa1hnQldVeFg2c05LZkhIOUhONEprdExiYndwaFJCZkU&usp=sharing

As has been the norm for these experimental versions this is a zip of the
directory not an installer.   Most folks find it works well to replace
the bin directory in their current WSJT 10.0 installation with the bin
directory from this experimental release.   Be sure to keep a copy of
your old bin directory in a safe place and always be sure to preserver your
call3.txt file.

This version contains the following fixes / enhancements over r5639 the
previous experimental release:

1.  A few minor ISCAT cosmetic changes.
2.  The ISCAT auto sequencer now looks for the strongest matching decode and
reports that instead of the first one it finds.
3.  ISCAT auto configuration now only occurs if the information block itself
is clicked on.   Clicking on the call will only update To Radio
and not the system parameters.   Clicking on the information block updates
everything.
4.  This version includes a variation of FSK441 called FSK315.   FSK315 is
legal on 10m under the current FCC rules.

If you have any questions or comments please contact me either on the lists
or directly at n...@ockert.us

73 de Bill ND0B






--






___
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] WSJT Experimental Release r5755 Available

[Bill Ockert - ND0B]

Greg,

It has been a while and my intent was to start with a fresh environment in 
case that
was the issue or just to recreate the steps I needed.

Biggest issue I recall is the doc files were showing up in... three? 
separate places and the
development environment was not looking in any of them.   I changed things 
so the doc
directory in trunk was where it looked for things which seemed to get me a 
clean compile
of the doc so I left it at that.

I will try to get better information for you.

Bill


-Original Message- 
From: KI7MT
Sent: Wednesday, August 05, 2015 4:28 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT Experimental Release r5755 Available

Just for Info,

What are the errors that occur?

I've not tested on JTSDK v1 in some time, and there are several
differences in the Python environment, none of which would have anything
to so with documentation build. However, they may have implications to
the application itself, as the version(s) of things like Numpy, pywin32,
etc were different from JTSDK v1

If you need help with getting JTSDK v2 up and running let me know,
should not be too difficult ( hopefully :-) )

73's
Greg, KI7MT



On 08/05/2015 03:13 PM, Bill Ockert - ND0B wrote:
> Sandro,
>
> I had some issued getting the doc to compile so there likely are some
> errors.   I will update
> in the future.
>
> Thanks!
>
> 73 de Bill ND0B
>
>
> -Original Message- 
> From: Alessandro Gorobey
> Sent: Wednesday, August 05, 2015 4:07 PM
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] WSJT Experimental Release r5755 Available
>
> Hi Bill,
>
> the Makefile.jtsdk2 is modified to work in C:/JTSDK-PY that refer to old
> jtsdk.
>
> --- a/trunk/Makefile.jtsdk2
> +++ b/trunk/Makefile.jtsdk2
> @@ -7,7 +7,7 @@
>   NAME = WSJT
>   VER = 10.0
>   OS = Win32
> -SDK = C:/JTSDK
> +SDK = C:/JTSDK-PY
> .
> .
> With JTSDK2 the program is compiled, but there is an error in doc, that
> in JTSD2 whose relocated.
>
> Can you verify ?
>
> 73
> Sandro
> IW3RAB
>
>
> Il 05/08/2015 22:45, Bill Ockert - ND0B ha scritto:
>> Good Afternoon/Morning/Evening Everyone
>> WSJT Experimental Release r5755 and associated manual are now available
>> on the shared google drive
>> https://drive.google.com/folderview?id=0B42rF4Jby8-vfjd0dl9udXNTOVlOa1hnQldVeFg2c05LZkhIOUhONEprdExiYndwaFJCZkU&usp=sharing
>> As has been the norm for these experimental versions this is a zip of
>> the directory not an installer.   Most folks find it works well to 
>> replace
>> the bin directory in their current WSJT 10.0 installation with the bin
>> directory from this experimental release.   Be sure to keep a copy of
>> your old bin directory in a safe place and always be sure to preserver
>> your call3.txt file.
>> This version contains the following fixes / enhancements over r5639 the
>> previous experimental release:
>> 1.  A few minor ISCAT cosmetic changes.
>> 2.  The ISCAT auto sequencer now looks for the strongest matching decode
>> and reports that instead of the first one it finds.
>> 3.  ISCAT auto configuration now only occurs if the information block
>> itself is clicked on.   Clicking on the call will only update To Radio
>> and not the system parameters.   Clicking on the information block
>> updates everything.
>> 4.  This version includes a variation of FSK441 called FSK315.   FSK315
>> is legal on 10m under the current FCC rules.
>> If you have any questions or comments please contact me either on the
>> lists or directly at n...@ockert.us <mailto:n...@ockert.us>
>> 73 de Bill ND0B
>>
>>
>> --
>>
>>
>>
>> ___
>> 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
>

--
___
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 Experimental Release r5755 Available

[Bill Ockert - ND0B]

Sandro,

I had some issued getting the doc to compile so there likely are some 
errors.   I will update
in the future.

Thanks!

73 de Bill ND0B


-Original Message- 
From: Alessandro Gorobey
Sent: Wednesday, August 05, 2015 4:07 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT Experimental Release r5755 Available

Hi Bill,

the Makefile.jtsdk2 is modified to work in C:/JTSDK-PY that refer to old
jtsdk.

--- a/trunk/Makefile.jtsdk2
+++ b/trunk/Makefile.jtsdk2
@@ -7,7 +7,7 @@
  NAME = WSJT
  VER = 10.0
  OS = Win32
-SDK = C:/JTSDK
+SDK = C:/JTSDK-PY
.
.
With JTSDK2 the program is compiled, but there is an error in doc, that
in JTSD2 whose relocated.

Can you verify ?

73
Sandro
IW3RAB


Il 05/08/2015 22:45, Bill Ockert - ND0B ha scritto:
> Good Afternoon/Morning/Evening Everyone
> WSJT Experimental Release r5755 and associated manual are now available
> on the shared google drive
> https://drive.google.com/folderview?id=0B42rF4Jby8-vfjd0dl9udXNTOVlOa1hnQldVeFg2c05LZkhIOUhONEprdExiYndwaFJCZkU&usp=sharing
> As has been the norm for these experimental versions this is a zip of
> the directory not an installer.   Most folks find it works well to replace
> the bin directory in their current WSJT 10.0 installation with the bin
> directory from this experimental release.   Be sure to keep a copy of
> your old bin directory in a safe place and always be sure to preserver
> your call3.txt file.
> This version contains the following fixes / enhancements over r5639 the
> previous experimental release:
> 1.  A few minor ISCAT cosmetic changes.
> 2.  The ISCAT auto sequencer now looks for the strongest matching decode
> and reports that instead of the first one it finds.
> 3.  ISCAT auto configuration now only occurs if the information block
> itself is clicked on.   Clicking on the call will only update To Radio
> and not the system parameters.   Clicking on the information block
> updates everything.
> 4.  This version includes a variation of FSK441 called FSK315.   FSK315
> is legal on 10m under the current FCC rules.
> If you have any questions or comments please contact me either on the
> lists or directly at n...@ockert.us <mailto:n...@ockert.us>
> 73 de Bill ND0B
>
>
> --
>
>
>
> ___
> 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

[wsjt-devel] WSJT Experimental Release r5755 Available

[Bill Ockert - ND0B]

Good Afternoon/Morning/Evening Everyone

WSJT Experimental Release r5755 and associated manual are now available on the 
shared google drive 

https://drive.google.com/folderview?id=0B42rF4Jby8-vfjd0dl9udXNTOVlOa1hnQldVeFg2c05LZkhIOUhONEprdExiYndwaFJCZkU&usp=sharing

As has been the norm for these experimental versions this is a zip of the 
directory not an installer.   Most folks find it works well to replace
the bin directory in their current WSJT 10.0 installation with the bin 
directory from this experimental release.   Be sure to keep a copy of
your old bin directory in a safe place and always be sure to preserver your 
call3.txt file.  

This version contains the following fixes / enhancements over r5639 the 
previous experimental release:

1.  A few minor ISCAT cosmetic changes.
2.  The ISCAT auto sequencer now looks for the strongest matching decode and 
reports that instead of the first one it finds.
3.  ISCAT auto configuration now only occurs if the information block itself is 
clicked on.   Clicking on the call will only update To Radio
and not the system parameters.   Clicking on the information block updates 
everything.
4.  This version includes a variation of FSK441 called FSK315.   FSK315 is 
legal on 10m under the current FCC rules. 

If you have any questions or comments please contact me either on the lists or 
directly at n...@ockert.us

73 de Bill ND0B
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] ISCAT in WSJT-X

[Bill Ockert - ND0B]

Joe,

Sounds like a fun and interesting challenge.I am gone for several days 
(activating EN67 and the new ISCAT will be used a lot) so will start 
thinking about this when I get back.

The auto sequencer code is concentrated in one area of wsjt.py with the 
intent of breaking it out into its own file.   Moving it to its own file 
will be a good first step in that it will give high visibility of the hooks 
it needs to run.   Finding those hooks and translating the code from pyton 
should be reasonably straightforward.

I will start getting up to speed on the environment.

73 de Bill ND0B


-Original Message- 
From: Joe Taylor
Sent: Thursday, July 02, 2015 3:11 PM
To: WSJT software development
Subject: [wsjt-devel] ISCAT in WSJT-X

Hi all,

I'm writing to keep everyone up to date on what's happening with WSJT-X
in the experimental branch.

Effective with code revision r5666, WSJT-X includes most of what's
needed to be operational in ISCAT mode.  The mode might be fully
operational (though perhaps with a few rough edges) within a few days.

As you probably know, Bill/ND0B has been working diligently on several
improvements to ISCAT mode in WSJT: in particular, T/R sequence lengths
of 5, 10, and 15 s as well as the default 30 s, and optional automatic
sequencing through the messages of a minimal QSO.

Assuming that these features will be seen as desirable by most ISCAT
users, we will want to include them in WSJT-X as well.  Bill, I don't
know how familiar you are already with the Qt-based WSJT-X, as opposed
to the Python-based WSJT.  I can do what's needed to activate the short
sequence lengths, but you might want to start thinking about how best to
implement auto sequencing in WSJT-X.  Do let us know if you need some
help finding your way around the WSJT-X code!

Comments from anyone about these plans will be welcome.

-- 73, Joe, K1JT

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

Re: [wsjt-devel] Doc checkout and generation

[Bill Ockert - ND0B]

Figured it out, thanks!!

-Original Message- 
From: KI7MT
Sent: Wednesday, July 01, 2015 2:09 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Doc checkout and generation

Hi Bill/ND0B,

There are several things in play here. First, documentation builds are
in a state of transition, from JTSDK-DOC to In-Application builds.
WSJT-X was the first to convert over to In-App building of documentation.

Since then, I've updated WSJT ( Windows only ) and WSPR ( Windows and
Linux ) to build documentation as party of the normal build process (
added doc targets ).

The sources ( for WSJT ) are located within the trunk/doc/user_guide
directories at present. However, I've not a gotten a final go ahead from
Joe to formally shift Doc builds over to In-Apps builds, and that will
require a couple Small Makefile changes for Linux. Makefile.jtsdk2 ( for
Windows ) I believe is working OK.

So, at present, we have to sets of Source Files for WSJT and WSPR. Those
that reside within ../branches/doc/{wsjt,wspr} and those that reside
within their respective ../doc/user_guide locations. , trunk or branch.

The difference between ( .bat and .sh with respect to JTSDK-DOC ) is due
to the fact, we use a Windows environment (*.cmd ) to build WSJT-X and
WSJT, thus the .bat stuff, whereas JTSDK-DOC is actually a full Cygwin32
Bash environment, thus using a shell script (.sh) to do the building.

Once Joe OK's / is happy with the In-App build, we can eliminate both
WSJT and WSPR builds from JTSDK-DOC ( ../branches/doc ). As stated
before, that will require a WSJT Makefile update on Linux.

73's
Greg, KI7MT


On 07/01/2015 11:21 AM, Bill Ockert - ND0B wrote:
> Good afternoon,
>
> I am attempting to update the WSJT documentation to include my recent 
> changes to ISCAT and am running into issues...
>
> As per the developers guide I did a windows install and then an update for 
> developers using
>
> svn co https://us...@svn.code.sf.net/p/wsjt/wsjt/branches/doc replacing 
> user with my ID.   That all seemed to work well and I am checked outat 
> revision 5649. I made my changes and then attempted to compile.   As per 
> the developers guide at the C:JTSDK-DOC> prompt in the JTSDK-DOC 
> environment I typed “build wsjt” and hit enter.  Iget the following: 
> 'build' is not recognized as an internal or external command,
> operable program or batch file.
>
> I have done some investigation comparing the JTSDK-PY environment and the 
> JTSDK-DOC environment in the PY environment “build” is set to call a .bat 
> file when invoked and in the DOC environment no such mechanism exists.
>
> On further detail.  An information blip in the documentation suggests:
>
> Be sure to update JTSDK-DOC after checkout. Simply browse to and run: 
> C:\JTSDK-DOC\doc\dev-guide\scripts\install-scripts.bat. Running the script 
> will update all the SDKs you have installed.
>
> A scripts directory does not exist at that location and the only one I was 
> able to find, in tools, does not contain that file.
>
> Did I set something up wrong or is something awry?
>
> Any help or insite greatly appreciated
>
> 73 de Bill ND0B
>
>
>
>
> --
> 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
>

-- 

Launchpad: https://launchpad.net/~ki7mt
Ubuntu Hams..: https://launchpad.net/~ubuntu-hams-devel
Debian Hams..: https://alioth.debian.org/projects/pkg-hamradio/
JTSDK: https://sourceforge.net/projects/jtsdk/
OpenPGP..: C177 6630 7115 78FE 9A2B 9F7F 18C0 F6B7 0DA2 F991

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

Re: [wsjt-devel] Doc checkout and generation

[Bill Ockert - ND0B]

Greg,

Thank you for the helpful reply.   I have found the doc files in WSJT but 
the build file does not seem to reference them.   I as assuming I did 
something wrong when I installed the development environment and am 
backtracking to see what that might be.

Much Appreciated!

73 de Bill ND0B


-Original Message- 
From: KI7MT
Sent: Wednesday, July 01, 2015 2:09 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Doc checkout and generation

Hi Bill/ND0B,

There are several things in play here. First, documentation builds are
in a state of transition, from JTSDK-DOC to In-Application builds.
WSJT-X was the first to convert over to In-App building of documentation.

Since then, I've updated WSJT ( Windows only ) and WSPR ( Windows and
Linux ) to build documentation as party of the normal build process (
added doc targets ).

The sources ( for WSJT ) are located within the trunk/doc/user_guide
directories at present. However, I've not a gotten a final go ahead from
Joe to formally shift Doc builds over to In-Apps builds, and that will
require a couple Small Makefile changes for Linux. Makefile.jtsdk2 ( for
Windows ) I believe is working OK.

So, at present, we have to sets of Source Files for WSJT and WSPR. Those
that reside within ../branches/doc/{wsjt,wspr} and those that reside
within their respective ../doc/user_guide locations. , trunk or branch.

The difference between ( .bat and .sh with respect to JTSDK-DOC ) is due
to the fact, we use a Windows environment (*.cmd ) to build WSJT-X and
WSJT, thus the .bat stuff, whereas JTSDK-DOC is actually a full Cygwin32
Bash environment, thus using a shell script (.sh) to do the building.

Once Joe OK's / is happy with the In-App build, we can eliminate both
WSJT and WSPR builds from JTSDK-DOC ( ../branches/doc ). As stated
before, that will require a WSJT Makefile update on Linux.

73's
Greg, KI7MT


On 07/01/2015 11:21 AM, Bill Ockert - ND0B wrote:
> Good afternoon,
>
> I am attempting to update the WSJT documentation to include my recent 
> changes to ISCAT and am running into issues...
>
> As per the developers guide I did a windows install and then an update for 
> developers using
>
> svn co https://us...@svn.code.sf.net/p/wsjt/wsjt/branches/doc replacing 
> user with my ID.   That all seemed to work well and I am checked outat 
> revision 5649. I made my changes and then attempted to compile.   As per 
> the developers guide at the C:JTSDK-DOC> prompt in the JTSDK-DOC 
> environment I typed “build wsjt” and hit enter.  Iget the following: 
> 'build' is not recognized as an internal or external command,
> operable program or batch file.
>
> I have done some investigation comparing the JTSDK-PY environment and the 
> JTSDK-DOC environment in the PY environment “build” is set to call a .bat 
> file when invoked and in the DOC environment no such mechanism exists.
>
> On further detail.  An information blip in the documentation suggests:
>
> Be sure to update JTSDK-DOC after checkout. Simply browse to and run: 
> C:\JTSDK-DOC\doc\dev-guide\scripts\install-scripts.bat. Running the script 
> will update all the SDKs you have installed.
>
> A scripts directory does not exist at that location and the only one I was 
> able to find, in tools, does not contain that file.
>
> Did I set something up wrong or is something awry?
>
> Any help or insite greatly appreciated
>
> 73 de Bill ND0B
>
>
>
>
> --
> 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
>

-- 

Launchpad: https://launchpad.net/~ki7mt
Ubuntu Hams..: https://launchpad.net/~ubuntu-hams-devel
Debian Hams..: https://alioth.debian.org/projects/pkg-hamradio/
JTSDK: https://sourceforge.net/projects/jtsdk/
OpenPGP..: C177 6630 7115 78FE 9A2B 9F7F 18C0 F6B7 0DA2 F991

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

[wsjt-devel] Doc checkout and generation

[Bill Ockert - ND0B]

Good afternoon,

I am attempting to update the WSJT documentation to include my recent changes 
to ISCAT and am running into issues...

As per the developers guide I did a windows install and then an update for 
developers using 

svn co https://us...@svn.code.sf.net/p/wsjt/wsjt/branches/doc replacing user 
with my ID.   That all seemed to work well and I am checked outat revision 
5649. I made my changes and then attempted to compile.   As per the developers 
guide at the C:JTSDK-DOC> prompt in the JTSDK-DOC environment I typed “build 
wsjt” and hit enter.  Iget the following: 'build' is not recognized as an 
internal or external command,
operable program or batch file.

I have done some investigation comparing the JTSDK-PY environment and the 
JTSDK-DOC environment in the PY environment “build” is set to call a .bat file 
when invoked and in the DOC environment no such mechanism exists.

On further detail.  An information blip in the documentation suggests: 

Be sure to update JTSDK-DOC after checkout. Simply browse to and run: 
C:\JTSDK-DOC\doc\dev-guide\scripts\install-scripts.bat. Running the script will 
update all the SDKs you have installed.

A scripts directory does not exist at that location and the only one I was able 
to find, in tools, does not contain that file.   

Did I set something up wrong or is something awry?

Any help or insite greatly appreciated

73 de Bill ND0B

--
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] Version R 5637 up on Google Driver

[Bill Ockert - ND0B]

Everyone,



the latest release, R 5637 is up on Google Drive along with the text file.   



https://drive.google.com/folderview?id=0B42rF4Jby8-vfjZza0I3VUN6UXFEa2NDdGszajZlOGk0TEhTeTFhSUY3UF81WmV4THVaVE0&usp=sharing



Note:   If you were running with AFC checked (like me) please uncheck it.   
While the old decoder may or may not have worked better with it checked it 
should not be checked with the new decoder.  



If you see anything odd with the decoder please send a wav file and a 
description of the issue to Joe and myself.   If you see anything odd with the 
auto sequencer or auto configuration please send a wav file and description to 
me.   In both cases screen shots are very helpful. 



Change Log



1.  Starting with this version the source code is being checked into the WSJT 
source code repository so the changes become part of the next release of WSJT.  
 As a consequence we have gone from ISCAT Experimental versions to R Versions 
both for discussion and what is shown on the title line of the program.



2.  Joe's RRR bug fix is in this version.  IF YOU WERE (LIKE ME) RUNNING WITH 
AFC CHECKED YOU MUST UNCHECK IT.



3.  Fixed bug where Auto sequencer was active even if Auto is Off was set.



4.  Fixed bug where auto configure was not setting the signal report if 
appropriate.



5.  Added Setup/Report All ISCAT Messages if you want to see all the messages 
the decoder produces while not in auto mode.If this is not checked only the 
best message is shown.  In auto mode only the message used is shown.




Enjoy!




73 de Bill ND0B







__._,_.___


Posted by: n...@ockert.us 


  Reply via web post  • Reply to sender  • Reply to group  • Start a New 
Topic  • Messages in this topic (1)  

Visit Your Group a.. New Members 30 
 • Privacy • Unsubscribe • Terms of Use 

.
 
 __,_._,___--
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] Fw: [WSJT_SS_ISCAT] "RRR" bug fixed

[Bill Ockert - ND0B]

Forwarded without wav file attachment and embedded screen shot to reduce size, 
if anyone would like those drop me an email direct

From: mailto:wsjt_ss_is...@yahoogroups.com 
Sent: Monday, June 29, 2015 10:44 AM
To: wsjt_ss_is...@yahoogroups.com ; K1JT 
Subject: Re: [WSJT_SS_ISCAT] "RRR" bug fixed

  

Good morning Joe,

I just completed integrating my changes and have committed them as Rev 5637.

Part of the integration process was modifying the version of ISCAT.f90 to 
encompass both mine and your changes, your change was very close to what I was 
doing do the changes I had to make were mostly cosmetic although I did move 
writing all messages up to the wsjt.py level with a Setup check on when to do 
it.

I have noticed an issue with decode of a strong non repetitive signal.  The 
attached wav is a TX2 from W3CP to myself that is pretty much full sequence and 
very strong.   As you will note, with one exception the decode is garbage.   
The decoder and also my auto sequencer did find the right one but this seemed 
odd based on the quality of the received signal.

To get this dump check Setup/Report All ISCAT Messages.   If this is not 
checked then just the ISCAT decoder selected messages is displayed.

Your thoughts appreciated,

73 de Bill ND0B






From: mailto:wsjt_ss_is...@yahoogroups.com 
Sent: Saturday, June 27, 2015 12:49 PM
To: 'WSJT software development' ; wsjt_ss_is...@yahoogroups.com 
Subject: [WSJT_SS_ISCAT] "RRR" bug fixed

  
Hi all,

I have found and corrected a problem that several have noticed in the 
ISCAT decoder in WSJT. The bug was especially troublesome in messages 
containing a single repeated character, such as the message "RRR".

The problem is fixed in the WSJT code repository as of revision 5634.
Bill (ND0B) should update his code branch accordingly, so that the 
"ISCAT_SS" test version of WSJT will use the improved decoder.

Note: Up to now the ISCAT decoder has made its own decision about the 
most reliable decoded message and displayed only that one. For testing, 
at least, I have changed the logic so that if the "Sync" limit is set to 
0, many decodes (based on different parts of the received signal) can be 
displayed. With higher Sync settings only the best will be displayed, 
as before.

This is a good time also for me to make a special request of all those 
using ISCAT with Bill's recent program improvements. Further 
improvements to the ISCAT decoder are possible. The necessary work will 
be easier and the results more reliable if I have a good collection of 
*.wav files containing real over-the-air ISCAT signals. The most useful 
files will be ones where the signal is weak and barely decodable or "not 
quite decodable".

If you are testing ISCAT and this is easy for you to do, please zip up a 
collection of several such files and send them to me. Many thanks!

-- 73, Joe, K1JT


__._,_.___

--------
Posted by: "Bill Ockert - ND0B"  


  Reply via web post  • Reply to sender  • Reply to group  • Start a New 
Topic  • Messages in this topic (5)  

Visit Your Group a.. New Members 29 
 • Privacy • Unsubscribe • Terms of Use 

.
 
 __,_._,___--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] [WSJT_SS_ISCAT] "RRR" bug fixed

[Bill Ockert - ND0B]

Good morning Everyone,

I am rolling Joe’s RRR fix into what what will be a numbered version to be (if 
all goes well) released later today.  Instead of ISCAT Experiment Vx it will 
have a number like other versions of WSJT.   This is because as of the changes 
today I am moving the development over to the source code repository to avoid 
conflict with any further changes Joe and others might make.  This will also 
allow folks who want to run on other platforms to compile and hopefully run 
with the new changes. 

While it was convenient to run the experimental version offline from the 
repository there is a danger in that in when other developers do something it 
can sometimes be at odds with what you are working on.   The fixes Joe made to 
how WSJT reports ISCAT decodes are a case in point, I had already done that in 
order to pass multiple decodes to the auto sequencer, it is looking for exact 
text so it was one way to sometimes get around the RRR issue.   Now that Joe 
has also done this I need to merge what I did, what he did and at the same time 
make sure I do not break the fix.

Because I have already dealt extensively with reporting ISCAT the decoder 
routing will go back to always placing all decodes into file that is processed 
by higher level routines.   At the decode level it will only write the “best” 
decode into All.txt.   Up at the auto sequence level I have added at a “Report 
All ISCAT Decodes” to the Setup menu that will cause all of the decodes to be 
reported and written to all.txt.   As before if a decode was used by the auto 
sequencer to advance it will be marked with an ‘a’.   The Sync setting will not 
affect this.

I am excited to see how the changes work.   And remember Joe has put out a call 
for wav files showing when the decoder was not working.   Remember to include 
comments about what you were expecting to RX, what you did RX and screenshots 
showing context are always helpful.

73 de Bill ND0B




From: mailto:wsjt_ss_is...@yahoogroups.com 
Sent: Saturday, June 27, 2015 12:49 PM
To: 'WSJT software development' ; wsjt_ss_is...@yahoogroups.com 
Subject: [WSJT_SS_ISCAT] "RRR" bug fixed

  
Hi all,

I have found and corrected a problem that several have noticed in the 
ISCAT decoder in WSJT. The bug was especially troublesome in messages 
containing a single repeated character, such as the message "RRR".

The problem is fixed in the WSJT code repository as of revision 5634.
Bill (ND0B) should update his code branch accordingly, so that the 
"ISCAT_SS" test version of WSJT will use the improved decoder.

Note: Up to now the ISCAT decoder has made its own decision about the 
most reliable decoded message and displayed only that one. For testing, 
at least, I have changed the logic so that if the "Sync" limit is set to 
0, many decodes (based on different parts of the received signal) can be 
displayed. With higher Sync settings only the best will be displayed, 
as before.

This is a good time also for me to make a special request of all those 
using ISCAT with Bill's recent program improvements. Further 
improvements to the ISCAT decoder are possible. The necessary work will 
be easier and the results more reliable if I have a good collection of 
*.wav files containing real over-the-air ISCAT signals. The most useful 
files will be ones where the signal is weak and barely decodable or "not 
quite decodable".

If you are testing ISCAT and this is easy for you to do, please zip up a 
collection of several such files and send them to me. Many thanks!

-- 73, Joe, K1JT


__._,_.___


Posted by: Joe Taylor  


  Reply via web post  • Reply to sender  • Reply to group  • Start a New 
Topic  • Messages in this topic (1)  

Visit Your Group a.. New Members 30 
 • Privacy • Unsubscribe • Terms of Use 

.
 
 __,_._,___--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] ISCAT Experiement V9 Released

[Bill Ockert - ND0B]

Good morning

I just released WSJT ISCAT Experiment V9 on the google drive we have been using 
for that purpose.   This is hopefully the last experimental release and 
assuming it survives the weekend mostly unscathed my intent is to check it in 
to the repository early next week after doing a clean upload, moving the files 
I have changed over to it and fixing any diffs that might have popped up while 
I have been doing the development the last few weeks.  

A comprehensive list of the changes made as well as updated manual pages will 
be forthcoming.

I have thoroughly enjoyed working on this and rediscovering Fortran after way 
too many years, learning Python and even, after saying where the heck did that 
complex waveform come from, remembering Euler’s equation.   It has been an 
interesting couple of weeks.

I am hoping I can continue to make contributions to the cause.

73 de Bill ND0B


--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Back in town

[Bill Ockert - ND0B]

Good afternoon Dr. Joe,

Glad to hear you had such a wonderful trip.

Responding to the comments aimed at my efforts:

2.   The user base is currently on ISCAT Experimental V8a and is testing it. 
A few small issues and minor feature requests are going into V9 but the 
features are there and working well.   I plan to let V8a run through the 
weekend, fix anything that comes up, then let V9 run for a couple of weeks 
before committing it.  The only issue I know of and have not fixed yet is 
its propensity to write out ISCAT .wav files when there was clearly no 
decode regardless of the Save settings.   Working on that one.

Yes, I did form the Yahoo group and possibly a Google Group for testing. 
These were not meant to be long term and will be disbanded and any new users 
directed to the regular Yahoo group.   It was not my intent to step on any 
toes with this but rather to keep the bandwidth down on the mainline groups. 
I have announced the Yahoo group both here and on the regular WSJT group. 
My apologies if protocols were broken.

3.  Yes, I have a file that shows the RRR -> RRT mis-decode which I will 
send to you.   For this file the demodulator returns 30 or so demods to the 
decoder about 1/2 of which are the correct RRR.   The one having the highest 
"worst"  value happens to be RRT.

In general I think the uptick in activity is showing some possible  issues 
with the demodulator / decoder.   In instances it will decode signals that 
cannot be heard which shows the true potential of the protocol.   Next time 
a clearly audible signal sometimes even a full sequence strong signal will 
fail to decode.   I have been studying the demodulator / decoder code and 
while I have made a couple of small changes to allow auto sequencing to pick 
a correct decode I am not up to speed enough to fully dig into it yet.   But 
I will be.

Thank you,

73 de Bill ND0B




-Original Message- 
From: Joe Taylor
Sent: Thursday, June 25, 2015 3:03 PM
To: 'WSJT software development'
Subject: [wsjt-devel] Back in town

Hi all,

My, you've been busy here -- lots of very impressive progress!  Many
thanks to all of you contributors to the WSJT-related projects!

[Brief aside: My wife and I thoroughly enjoyed our 8-day cruise -- 
Venice to Athens, with stopovers at ports on the Dalmatian coast: Split,
Korcula, Dubrovnik, Kotor, Butrint, Corfu, and Delphi; then into the
Ionian sea and through the Corinth canal into the Aegean, ending at
Piraeus.  Two canceled flights on the way home extended our trip by more
than 24 hours, and 2 of our 3 bags are currently lost -- but otherwise
all is well.]

Here's a start toward responding to some issues raised in the past two
weeks:

1. I've briefly tried the G4WJS "r5629-dirty" version of WSJT-X -- the
one with Bill's suggested changes to the user interface.  They look very
good, and I suggest they should be committed to our -devel branch.

2. Our other "Bill", ND0B, has made great progress with implementing
short-sequence ISCAT capability in WSJT.  Bill has a bunch of
enthusiastic testers using it on 6 meters with excellent results.  I
haven't tried it yet, but after reading the reports from others it seems
that you must be nearing the point of committing the "v9" code (or
something similar) to the SVN repository.  Is that right?

A related question: Bill has started a Yahoo Group (possibly to changed
to a Google Group?) to host discussion among the testers of his
experimental version.  No doubt this made good sense in early phases of
the effort; there's a downside, however, to moving away from this list
some important communication among programmers working on WSJT-related
code.  If others have views on this matter, please share them here.

3. Related to the above ISCAT developments: Bill (ND0B), do you have a
few example *.wav files illustrating the "RRS/RRT" decoding problem?  If
so, could you post them somewhere or send them to me?  I'd like to look
into the problem.

4. It's hardly surprising that Charlie (G3WDG) and others have found
that "correlation decodes" (in WSJT-X, presently implemented only for
JT4) can produce different confidence levels and (rarely) even different
message results when run against CALL3.TXT files of very different
lengths.  After all, the correlation algorithm is effectively answering
these two questions:

A) Which one of the following list of plausible messages best
matches the tone sequence of the received signal?

B) Is the "best" match better than the "second-best" match by a
large enough margin for us to be reasonably certain we have a valid decode?

Obviously, the answers to both questions will depend on the length of
the list of plausible messages, which is generated from call+grid
combinations derived from CALL3.TXT, augmented by the "DX Call" and "DX
Grid" entries on the main window.  If the list is short (but still
contains the call and grid actually in the message), the chances of a
correct decode and the estimated confidence in i

Re: [wsjt-devel] WSJT10 - templates

[Bill Ockert - ND0B]

A similar but related question came up in relation to Sync and Tol retention 
by Mode...

In both instances, the templates and the Sync/Tol retention there are 
several modes that we
would want to remember the users setting for as well as having a method of 
setting back to
defaults.Messy but there is nothing about it that is not doable.

Because I was already thinking about this for Sync/Tol I would be happy to 
take this
on once I am done with the ISCAT project.   Getting pretty good at Python 
these days.

73 de Bill ND0B

-Original Message- 
From: Allan Downie
Sent: Wednesday, June 24, 2015 8:33 PM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] WSJT10 - templates


I am not sure if this problem has been mentioned before, but here goes.

  I (and others), have had an issue with the templates in WSJT 10.0 for
some time now. Any templates which may be modified by the user, are
reset to the default templates when changing from one mode to another
and then back again.  I am currently using r5490, however this issue has
been evident over many revisions.

Case in point - I use WSJT 10.0 mainly for meteor scatter (FSK441), 70cm
EME (JT65b) and occasionally 2meter and 70cm Terrestrial( JT65b2). In VK
and ZL we use a different template for FSK441 compared with North
America and Europe. Both callsigns are always sent and the report
attached to the respondents callsign with a"/". That way, when multiple
users are active on the same frequency, there can be no mistake to whom
the report is intended. This format works extremely well.  Consequently
when I change from FSK441 to JT65B and then later back to FSK441, I lose
the local template format as it reverts to the default and subsequently
have to re-enter the local template. I notice WSJT 9.7 did not have this
issue.

Would it be possible to add a 'Region 3' template as per LZ2HV's FSK441
software, 'MSHV'?

Allan
VK4QG


--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical & virtual servers, alerts via email & sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel 


--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Short Sequence ISCAT Experiement

[Bill Ockert - ND0B]

A group of us are experimenting on 6m with a modified version of WSJT that 
support ISCAT sequences as short as 5 seconds, auto TX sequencing as well as 
auto configuration.   Results are very promising with closed band QSO being 
made regularly.   Both short Es and meteor pings are being taken advantage of.  

Most conversation about this in on Ping Jockey and N5TM Chat page. 

A Yahoo group, WSJT_SS_ISCAT has been formed to support it.   Please request to 
join if interested.

73 de Bill ND0B--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] ISCAT RRR Decode

[Bill Ockert - ND0B]

Good Morning Rex,

Thank you for the reply, it is useful to know I am looking at an actual problem.

Started digging into the protocol specification and the code last night.   I am 
quite a ways from understanding the code completely but did get the general 
outline and have added some comments.   Now that I know I am looking for an 
actual issue I have a bit more focus.

One of the things I did notice, which is obvious from how it is reported, is 
that the decoder is only putting the strongest decode into the files.   This is 
significant as the strongest decode may not be the best decode.  I can 
understand why the choice was made but think the decision on what should be 
reported needs to be moved up to a higher level in the code.  

What I am up to is there is a group of us who have started playing with short 
sequence ISCAT-B to take advantage of short Es openings on 6m.   While JT65 (HF 
style) is getting popular on 6m it is not unusual for an attempt to fail either 
because the opening closed or because meteor scatter pings hosed the decode.   
ISCAT gets around this by having shorter sequences and being somewhat immune to 
ms pings, at times even taking advantage of them.

Using ISCAT to best advantage on 6m involves a few changes to ISCAT which you 
might be interested in:

1.  Added 5 and 10 second sequences so now supports 5, 10, 15 and 30 second 
sequences.
2.  Added support for alternate messages (Cntl-G) which adds both calls to TX3 
- TX5 
3   Added an auto sequencer to step through the TX sequencing based on received 
messages.

The auto sequencer is very particular about when to advance.  On messages 
containing the calls they must match exactly.   On messages containing reports 
the structure is checked exactly and I am in the process of adding bounds 
checking.   RRR and 73 must match exactly.
These detail put the auto sequencer in a position to walk through multiple 
decoded messages finding the one that is both the correct decode and the 
strongest and then both acting on and reporting that one.   Consequently I was 
already planning an expedition into the decoder code.   This just pushes me 
along.

Again, thank you for the feedback.   I will be looking hard for the RRR issue.  
 If you are interested in the work we are doing there is a Yahoo group  where 
the current EXE is distributed and information distributed, WSJT_SS_ISCAT.

73 de Bill ND0B




From: Rex 
Sent: Wednesday, June 17, 2015 4:53 PM
To: Bill Ockert - ND0B ; WSJT software development ; David Smith 
Subject: Re: [wsjt-devel] ISCAT RRR Decode

Hi Bill

I have noticed similar problems with sending just RRR on its own on 10 and 24 
GHz aircraft scatter where RRR often comes out as RRT or RRS.  We have also 
tried sending R R R as you did and this does seem to solve it but at the 
expense of extra time which we often don't have on very short aircraft scatter 
bursts.  Your finding that SSS works well is useful and might give a clue as to 
what is causing this and what might be the solution but as it does not happen 
all the time it will be worthwhile your testing that the SSS result is always 
consistently good.  David VK3HZ and I commented as below in a DUBUS article 
2015 vol 1 (it might have been 2014 vol 4 as I don't have it with me) on 10 and 
24 GHz aircraft scatter.  It would certainly be good to find out the reasons 
and any solution that still allows the use of the shortest messages.



6. Decoding of RRR

We often see RRR decoded with only two of the Rs correct such as RRS.  It seems 
this error is due in some way to having three of the same tones in a row 
together with Doppler shift in the signal.  In addition to the RRR one also 
sees the length of the message in the first column as 4.  As it is unlikely 
that any message with two RRs and a length of 4 would be other than RRR (i.e. 
beginning-of-message plus 3 characters) we have taken the view that two RRs in 
a message of length 4 is sufficient to confirm that RRR is being transmitted.  
It is also possible with some experience to decode RRR and 73 by ear.


73 Rex VK7MO



On 18/06/2015 5:30 AM, Bill Ockert - ND0B wrote:

  Good afternoon,

  Several of us playing with ISCAT on 6m have noticed that it has a difficult 
time decoding the RRR message regardless of signal strength.   This is 
occurring both with the standard RRR message in WSJT 10 and with alternate 
messages in an experimental version of WSJT we are using.   Typical non decode 
is as follows, note the consistency

  180545   4  -3  3.1  -43   0 *  ND0B W5LDA -6 14 10 10  2.2
  180615   3  -2 11.5  -43   0 *  ND0B W5LDA RRT15  5 10  1.1
  180645   6  -2 12.6  -43   0 *  ND0B W5LDA RRT15  5 10  2.2
  180715   3  -2 11.5  -43   0 *  ND0B W5LDA RRT15  5 10  1.1
  180745   2  -5  2.6  -43   0 *  ND0B W5LDA RRR15  6 10  2.2
  180815   6  -2 14.3  -43   0 *  ND0B W5LDA RRT15  5 10  2.2
  1808

[wsjt-devel] ISCAT RRR Decode

[Bill Ockert - ND0B]

Good afternoon,

Several of us playing with ISCAT on 6m have noticed that it has a difficult 
time decoding the RRR message regardless of signal strength.   This is 
occurring both with the standard RRR message in WSJT 10 and with alternate 
messages in an experimental version of WSJT we are using.   Typical non decode 
is as follows, note the consistency

180545   4  -3  3.1  -43   0 *  ND0B W5LDA -6 14 10 10  2.2
180615   3  -2 11.5  -43   0 *  ND0B W5LDA RRT15  5 10  1.1
180645   6  -2 12.6  -43   0 *  ND0B W5LDA RRT15  5 10  2.2
180715   3  -2 11.5  -43   0 *  ND0B W5LDA RRT15  5 10  1.1
180745   2  -5  2.6  -43   0 *  ND0B W5LDA RRR15  6 10  2.2
180815   6  -2 14.3  -43   0 *  ND0B W5LDA RRT15  5 10  2.2
180845   2  -3  4.2  -43   0 *  ND0B W5LDA 73 14 10 10  1.1

As an experiment we put spaces between the Rs, this decoded every time


181045   8  -2  9.8  -43   5 *  ND0B W5LDA R R R  17  5 10  4.5
181115   8  -2  9.3  -43   5 *  ND0B W5LDA R R R  17  5 10  4.5
181145   8  -2 11.5  -43   5 *  ND0B W5LDA R R R  17  4 10  4.5


As a further experiment we changed it to SSS... again decoded every time


182115   3  -2  9.8  -43   0 *  ND0B W5LDA SSS15  9 10  1.1
182130   0 -20  0.00   0   0  0  0  0.0
182145   3  -2  2.0  -43   0 *  ND0B W5LDA SSS15 10 10  1.1
182200   0 -20  0.00   0   0  0  0  0.0
182215   3  -2  1.5  -43   0 *  ND0B W5LDA SSS15 10 10  1.1

Any thoughts on where I might start looking for this issue would be greatly 
appreciated.   

This is happening on 10.0 5490 release as well as the experimental version I 
developed.  It also happens with just the RRR message.  

Thank you!

73 de Bill ND0B


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