Re: DIGIFEST!


Tony G4NBS
 

Apologies for the shouting – seems my PC wanted to change Font without permission!

 

From: ukmicrowaves@... [mailto:ukmicrowaves@...]
Sent: Thursday, October 19, 2017 14:37
To: ukmicrowaves@...
Subject: RE: [ukmicrowaves] DIGIFEST!

 

 

Not sure if I’m a luddite or a pedant….

 

I think that’s a nice try from Andy. At first look (Coming from the MS procedure that most of us are used to) I was worried by the apparent lack of acknowledgement of data received prior to sending the next part but if everyone is aware of the procedure then I don’t see an issue with shortened calls, just with what RS format since so many are –dB. Maybe BOF needs to finalise the QSO with 73 so that JNT knows his RRR were received but that could be an endless loop!

 

I did “challenge” the guidelines when they were first proposed in a minor way though – There seems to be no real requirement to copy the locator over the air using this procedure.
The example assumes set up from KST and then suggests moving to TX2 if both calls are copied (surely this should only be changed if calls and locator are received?).

Likewise towards the end it suggests we should respond to a CQ with TX2. Works that way for MS QSO’s but for a contest requirement of exchanging locators then surely this should be TX1? I couldn’t see that sending the locator in TX4 or 5 “in case” the other operator had not copied it earlier would guarantee that it was copied “on air”. As said, pedantic as most locators are well known anyway….

 

I do note there is a NA Contest mode for some of the data types. Not looked at them but anything that we can base our procedures on or ask to be modified?

 

Regards

Tony G4NBS

 

 

 

From: ukmicrowaves@... [mailto:ukmicrowaves@yahoogroupscom]
Sent: Thursday, October 19, 2017 13:28
To: ukmicrowaves@...
Subject: Re: [ukmicrowaves] DIGIFEST!

 

 

Any hardcore VHF/UHF contesters out there with Qt coding skills fancy joining the WSJT dev team, and submitting a patch to extend the exchange structure for key modes to support a valid contest exchange in auto mode without any convoluted usage? Qt is nice to work with, totally cross-platform and (mostly) sensible.  At least, compared with certain other development environments. I've only used the free version https://www.qt.io/download-qt-for-application-development

The user base for VHF/UHF contest use under EU-style rules is tiny in comparison with even EME usage, never mind the HF twiddles users. Without a champion inside the dev team, our aspirations are not going to be prioritised.

Neil G4DBN
#notvolunteering


On 19/10/2017 12:37, 'Martin A Hall' gorrell77@... [ukmicrowaves] wrote:

 

 

That is why if someone can come up with a step-by-step guide to using the highly structured modes to exchange the standard European contest information I’m all ears.  Several operators I have discussed this with have said they believe it can be done, but none has yet succeeded in coming up with a protocol that actually works.  I am happy to buy several pints for anyone that does.

 

Join UKMicrowaves@groups.io to automatically receive all group messages.