Hi Bill,
Since you're working on code in the WSJT "trunk", presumably to be saved
there in due course, I am copying this message to the wsjt-devel
reflector. In future, let's carry on our discussion there, so others in
the development group can know what's happening.
I'm OK with including one's grid in the default CQ message in all modes.
-- Joe, K1JT
On 6/10/2015 9:37 AM, Bill Ockert - ND0B wrote:
> Good morning Dr. Joe,
>
> The changes have been made and initial results are looking promising. We
> are waiting for suitable prop again and in the meantime I am in the
> process of making auto sequencing more robust and adding support to it
> for EU type messages, the NA messages were too ambiguous without a call
> included to safely support auto sequencing. We are going to experiment
> with the EU messages for now rather than add a different message
> structure. We may eventually settle on something more like the NA JT65
> HF style messages where both calls are included in each message but for
> now the EU messages work.
>
> On a separate issue one of the guys in the group complained/suggested
> that as long as I was in there could I add grid to the the standard CQ
> message for all modes. This turned into a bit of a chorus and is a
> complaint I have had. I just about always edit the standard CQ message
> when I change from reports to grids and back and based on the CQs I see
> I think that is pretty standard. It is an easy enough change but
> something I felt I should query about before touching. What are your
> thoughts?
>
> Thank you Joe,
>
>
>
> -----Original Message----- From: Joe Taylor
> Sent: Thursday, June 04, 2015 1:06 PM
> To: Bill Ockert - ND0B
> Subject: Re: 6m Es ISCAT Mods
>
> Hi Bill,
>
> By all means give it a try, and see how it works!
>
> -- Joe
>
> On 6/4/2015 11:34 AM, Bill Ockert - ND0B wrote:
>> Hi Joe,
>>
>> Thank you for your feedback.
>>
>> The 5 and 10 second sequences are simply aimed at speeding up the
>> contact. I figured I would put them in and let the guys figure out if
>> they are useful as it is an easy enough change. Since I started doing
>> Meteor Scatter a few years ago I have became aware that there are
>> nearly always what seem to be brief Es openings that last 5 to 10
>> seconds... these act different than pings which is why I think its
>> just a little E cloud that got in the way. The 5 and 10 second modes
>> would be aimed at taking advantage of them.
>>
>> As to auto mode, I am not a huge fan of a pure computer to computer
>> contacts and would thump any requests to have an auto response to CQ
>> or anything like that. This is purely a step through the sequences
>> once the contact is started and I am contemplating implementing it
>> because with 5 second sequence things start to happen awfully darn
>> fast. I have trouble keeping up with the 15s sequences and would be
>> about 3 steps behind on a 5s sequence.
>>
>> There IS precedence for this as PSK2K not only implements auto
>> sequencing but auto response to CQ. I like the first of these but
>> detest and refuse to use the second.
>>
>> Just to be clear I will NOT do the auto mode even on an experimental
>> basis without your permission. I think it is needed if 5s (or perhaps
>> faster) sequencing is viable but once the cat is out of the bag it is
>> pretty tough to catch. You can always blame that damn programmer... I
>> do this professionally too so am used to that LOL.
>>
>> There will be nay sayers to nearly anything new. I have read some of
>> the "scholarly" articles on how JT65 cannot be doing what it claims
>> written by the CW forever folks. It is usually easy to "prove" nearly
>> any premise if you set out with that as a goal however math and logic
>> tend to be abused a bit along the way. I would challenge those folks
>> to explain how repeatedly, out of the blue I get decodes on calls that
>> are not in my calls3.txt file nor in my "to Radio" field on signals I
>> cannot see.
>>
>> I see auto sequencing as no different. As I indicated this would be
>> purely to take the reigns of the contact once it is started and would
>> not have a response to CQ mode. If it proves useful in the short term
>> then work would be done to insure it is robust, as I indicated either
>> the calls or a hash could be added to insure the shorter messages are
>> going between the intended stations. Exact match of the calls or the
>> hash would be required to move forward. It would also be limited to
>> ISCAT. I see no use for it in the other modes.
>>
>> Also while an exact false decode is highly unlikely I am contemplating
>> adding an ASCIIized, or more precisely symbolized, CRC to the message
>> when in auto mode to ensure few if any false decodes occur while in
>> auto mode. That should satisfy all but the worst nay sayers.
>>
>> I have Chriso's stuff loaded and have played with it a bit. I have a
>> lot of other fish in the pan right now so have not taken the time to
>> really look at it.
>>
>> I have also played with the MSRX decoder that the PSK2K author DJ5HG
>> has done. It does appear to work better than the WSJT FSK decoder but
>> it is a pain to use in that it (like PSK2K) sits on top of the MATLAB
>> bloatware and uses the last audio file that WSJT wrote. In my
>> particular case I have to jump through hoops to see the results
>> because for some undetermined reason the font color is is using is the
>> same as the background color.
>>
>> Your further thoughts much appreciated.
>>
>> 73 de Bill ND0B
>>
>>
>>
>> -----Original Message-----
>> From: Joe Taylor
>> Sent: Thursday, June 04, 2015 9:32 AM
>> To: Bill Ockert - ND0B
>> Subject: Re: 6m Es ISCAT Mods
>>
>> Hi Bill,
>>
>> Interesting ideas!
>>
>> You're using ISCAT-B in just the way that it was intended (and used,
>> starting 5 years ago). It has been slow to catch on, perhaps in part
>> because I didn't promote it enough. I was more into EME and the WSJT
>> "slow" modes, at the time.
>>
>> Adding 5/10 second sequences might be useful, though I'm not sure what
>> you're after -- faster completion of QSOs, perhaps for contesting?
>>
>> About your second idea -- automated or semi-automated QSOs...
>>
>> When I started work on WSJT in 2001 I decided to resist any temptation
>> to play with "automated" modes -- by which I mean programmed algorithms
>> that can complete a QSO (according to normally accepted definitions)
>> without human interaction. I didn't want my modes -- first FSK441 for
>> meteor scatter, then JT65 for EME -- to be susceptible to an argument
>> made by some that "it's only computers talking to computers". For this
>> reason I've always required operator decisions to be made about what has
>> been received, what to transmit next, etc.
>>
>> Of course, some might have no objection to having the computer make more
>> of the necessary decisions...
>>
>> Another thought that you might find of interest: Probably you've noticed
>> that nearly all of our recent development work has been devoted to
>> WSJT's "slow" modes. We're thinking that further work on the "fast"
>> modes (FSK441, JTMS, ISCAT, JT6M) might be based in part on the
>> excellent work done by Christo, LZ2HV. Are you aware of this?
>> See https://sourceforge.net/projects/mshv/
>>
>> -- 73, Joe, K1JT
>>
>> On 6/4/2015 9:56 AM, Bill Ockert - ND0B wrote:
>>> Good morning Dr. Joe,
>>>
>>> There is group of us who have been discussing the limitations of
>>> JT65A used in terrestrial 6m contacts and have started playing with
>>> ISCAT-B in 15 second sequences. The results are highly promising with
>>> a group of us routinely making 1000mi plus contacts with very minimal
>>> Es conditions.
>>>
>>> To further enhance this experimentation I plan to make two changes to
>>> ISCAT....
>>>
>>> 1. Short term: Add 5 and 10 seconds sequences
>>>
>>> 2. Longer term: Add auto TXx sequencing based on received messages.
>>>
>>> I realize the second one comes with some baggage as the simple Rxxx,
>>> RRR and 73 messages would be subject to possible reception from other
>>> contacts occurring simultaneously. A simple solution would to add the
>>> calls into these messages if auto mode is enabled. A more complex
>>> solution would use a hash code of the calls to keep the messages short.
>>>
>>> In the longer term if this works out some method of passing sequence
>>> length information, replying to CQs, etc will need to be worked out.
>>> Those issues will be dealt with if ISCAT works out as well as we hope
>>> for this application.
>>>
>>> Everything I currently plan to do fits into the existing ISCAT
>>> message structure. If this works out perhaps some discussion could be
>>> had on an ISCAT-6 aimed directly at this. For now ISCAT-B is good.
>>>
>>> Your thoughts on this would be greatly appreciated before I dive into
>>> this.
>>>
>>> Thank you Joe!
>>>
>>> 73 de Bill ND0B
>>>
>>>
>>>
>
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
