[wsjt-devel] MSK144 Observationg
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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