|
Post by Tihomir CA3TSK on Aug 27, 2023 15:42:19 GMT
Hi,
Last weekend of August 2023 was the ww-digi 2023 FT8/FT4 contest, but unfortunately JTDX doesn't support the reduced contest protocol where only the grids are exchanged.
WSJTX has a checkbox on the Advanced settings tab to enable the ww-digi contest protocol support.
I prefer JTDX, and therefore it would be great to enhance JTDX, so that next year it can be used for the ww-digi 2024 contest during last weekend of August.
If this request is not on the priority list, then I will do it on my own, and afterwards I would share the changes.
Protocol is something like:
CQ WW CALLSIGN1 GRID1 CALLSIGN1 CALLSIGN2 R GRID2 CALLSIGN2 CALLSIGN1 RR73 CALLSIGN1 CALLSIGN2 73
If I understood it correctly, then the contest mode should still be able to transparently interact with non contestants that use the normal protocol, i.e. detect non contest messages and respond accordingly temporarily. WSJTX did not seem to support the transparent requirement.
Thanks and 73 from Chile de Tihomir CA3TSK
|
|
|
Post by Tihomir CA3TSK on Mar 29, 2024 3:46:14 GMT
Hi,
After getting no reply I have started adding the WW digi contest support to the code, but I hit a wall, because unfortunately the high level FT8/FT4 decoding is done in two places, i.e. first there is a decoding in Fortran, and then again in C++, so my problem now is that when the grid report is sent from the other party for my reception (KH6RDO CB3R R FF46) that received message is not passed to the C++ side because it does not get passed from the FORTRAN based process.
After checking the Fortran files it can be seen, that all the contest code was deliberately deleted by the JTDX developers, and the code bases between JTDX and WSJT-X have now diverged too much, that it isn't trivial anymore to add back the contest part.
I would have expected the low level part that handles the audio, etc. to be written in Fortran, and then have the high level mode message decoding and message handling only in C++ avoiding this current unnecessary double handling, and allowing easier extensions.
73 from Chile de Tihomir CA3TSK
P.S.: WW DIGI protocol
CQ WW CB3R FF46 CB3R KH6RDO BK29 KH6RDO CB3R R FF46 CB3R KH6RDO RR73 KH6RDO CB3R 73
|
|
|
Post by Arvo ES1JA on Mar 29, 2024 5:48:14 GMT
Hi Tihomir JTDX developers (Igor and I) are not interested in contesting at all, thats why still no contest support in JTDX, sry. I can’t say it will be forever so.
|
|
|
Post by w9mdb on Mar 29, 2024 13:33:14 GMT
|
|
|
Post by Tihomir CA3TSK on Mar 29, 2024 14:48:36 GMT
Yes, WSJT-X and MSHV can handle WW DIGI, but I really like and prefer JTDX.
|
|
|
Post by Tihomir CA3TSK on Mar 29, 2024 14:55:31 GMT
Hi Tihomir JTDX developers (Igor and I) are not interested in contesting at all, thats why still no contest support in JTDX, sry. I can’t say it will be forever so. I understand, and still there are remnants of the contest handling in the Fortran files, e.g. 'R ' handling. It would be really great, if you could help me with a hint how to get the grid reply message reception (KH6RDO CB3R R FF46) accepted by the Fortran code and handed over to C++. I have tried to extend the parts where 'R+' and 'R-' are handled, but the grid reply message reception seems to be discarded/ignored somewhere else. Thanks and 73 from Chile de Tihomir CA3TSK
|
|