Thanks Joe for sharing. 1296Mhz and above is technically pretty easy to do with 
modest stations and not that much power especially when one end is doing the 
heavy lifting with a larger dish. I would say that many of my current QSO’s do 
have spare dB’s where even Phone would be possible. In routine operation we 
move from 23CM EME Q65-60C to 120D and up from 60C to 30B when conditions and 
equipment support it. 

Speaking for myself and as a wish list item, a mode faster than 30B would be 
desirable for both Contests and Equipment since 30B and 60C is pretty hard on 
Amps - 120D for some Amps is impossible. Maybe 20 seconds is a compromise but 
there would be some complexity around 3 cycles a minute.

Anyhow - Wishlist for now.

Thanks,
Dwayne AB6A

> On Jan 22, 2024, at 1:04 PM, Joe Taylor <j...@princeton.edu> wrote:
> 
> Hi Dwayne,
> 
> I discussed these issues at some length with Bob, KA1GT, some 1.5 years ago.  
> Here are the relevant details.
> 
> Sure, we could make a version of Q65-15A that can decode after normal EME 
> delays.  It would not be a very good fit for the channel, however.
> 
> This is because the duration of a Q65 transmission is 12.8 s, and the 
> transmission starts at t = 0.5 s into the 15-second sequence.  Add a 2.7 s 
> EME delay, and you're already 1 second into the next sequence -- even without 
> any clock errors.
> 
> You could make the Tx duration smaller, say 10 s.  Then, if the transmission 
> starts at t=0.5 s and there's a 2.7 s EME delay, reception would be complete 
> at t=10.5 + 2.7 = 13.2 s, and (if clocks were spot on) the decoder would have 
> 1.8 s to do its thing.  Even this is not really enough, because clocks are 
> not always "spot on".  Moreover, you would lose an additional 
> 10*log(12.8/10.0) = 1 dB of sensitivity.  WSJT moders do a lot to gain every 
> 0.1 dB of sensitivity, so we certainly don't want to to that!
> 
> Fifteen-second sequences are not an efficient choice for a path with delays 
> as large as 2.7 s.  If there were many times more EME activity than at 
> present, so that very fast QSOs were desirable in contests, and if nearly 
> everybody had many dB's to spare on the EME path, something like Q65-15A 
> might be desirable.  As things stand, our advice is to use Q65-30B for EME on 
> 1296 MHz.
> 
>       -- 73, Joe, K1JT
> 
> On 1/22/2024 3:36 PM, Dwayne Sinclair wrote:
>> Thanks Joe for QSO and the confirmation that Q65-15A is not to be used for 
>> EME. Our “bad” in that in our circles we may have been referring to it as 
>> broken.
>> The attached article details some of the testing that has occurred to date 
>> in an attempt to work with what we have.
>> I guess the EME community (including me) are looking for a faster QSO where 
>> conditions and equipment support it?
>> Regards Dwayne AB6A
>>> On Jan 22, 2024, at 11:54 AM, Joe Taylor <j...@princeton.edu> wrote:
>>> 
>>> Hi Dwayne,
>>> 
>>> Thanks for the QSO with W2ZQ, last evening.
>>> 
>>> Who is saying Q65-15A is broken, and why?
>>> 
>>> Are you (or they?) talking about EME?  If so, are you aware that the 
>>> Q65-15x submodes are not supposed to work for EME.  The 2.5 s EME delay is 
>>> too large.
>>> 
>>>    -- 73, Joe, K1JT
>>> 
>>>> On 1/22/2024 2:04 PM, Dwayne Sinclair via wsjt-devel wrote:
>>>> There have been ongoing reports from various operators best summarized in 
>>>> the post attached that Q65-15A is “broken”. What is current consensus on 
>>>> this and if it is broken, is there any plans to address the issues?
>>>> Q65-15A Part II Testing and Sensitivity Bob Atkins - KA1GT 
>>>> <https://www.bobatkins.com/radio/Q65-15_eme_II.html>
>>>> bobatkins.com <https://www.bobatkins.com/radio/Q65-15_eme_II.html>
>>>>    favicon.ico <https://www.bobatkins.com/radio/Q65-15_eme_II.html>
>>>> <https://www.bobatkins.com/radio/Q65-15_eme_II.html>
>>>> Regards Dwayne AB6A
>>>> _______________________________________________
>>>> 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

Reply via email to