Hi all again.
After the release of 2.5.0rc2, we checked the issue again and the result is the following;
-
The issue with /P in Q65/JT65 seems to be fixed. (thank you for working on this.)
-
On Q65 and JT65, If either side of the call has foreign prefix/suffix (i.e. 3A/JO1LVZ or JO1LVZ/3A ) the issue still occurs with Tx2/3 because other side of the station will not know
who is being called. (i.e. I as 3A/JO1LVZ receives <…> G4WJS -01 so that I will not know if it is for me. )
If I double click on the decode above, I start calling G4WJS with TX1 as if G4WJS is calling someone else.
This forces me to click on Tx3 to send R report.
-
Similar issue occurs if callsign has portable number. (i.e. JO1LVZ/6)
Please continue to check on this.
Thanks.
JO1LVZ/Hatt
toggle quoted message
Show quoted text
From: Hattori, Yoshihisa
Sent: Friday, June 18, 2021 10:00 AM
To: main@WSJTX.groups.io
Subject: RE: [EXTERNAL] Re: [WSJTX] Cannot use /P in callsign when using JT65 and JT9 modes #JT65 #JT9 #BugReport
We might be talking about something different.
-
Decode a sig from /P station. (ex. G4WJS/P)
-
Double click on the decode to generate the message, or populate the DX call manually then click on generate standard message, which will result TX1 without GL. (i.e. G4WJS/P JO1LVZ.
Note: This does not occur in FT8.)
-
If I send the message as it is, DX will receive G4WJS/P <…> so that he will not know who is calling.
The only solution at this moment is manually add my GL to TX1. (i.e. TX1 with GL is mandatory to make the protocol work.)
It was originally reported to wsjt-devel back in Mar, too.
All the issues could be fixed by adding GL correctly in TX1 when standard message is generated. (not exactly sure though.)
Hatt/JO1LVZ
are you sure? The Q65 mode uses a 77-bit payload with a different message source encoding scheme that allows messages like:
so the problem does not occur for that mode.
On 17/06/2021 03:01, Hattori, Yoshihisa wrote:
Bill,
This also happens to Q65, so please make sure the issue gets fixed for that mode, too.
Thanks.
Hatt/JO1LVZ
|
[CAUTION] This email originated from outside Travelport. Do not click links or open attachments unless you recognize the sender and know the content is safe.
|
On 16/06/2021 10:23, Jim Brown wrote:
On 6/16/2021 1:10 AM, Panos wrote:
Hi Bill, thanks I am waiting for it 73
I am not. Just like on all other bands and modes, the definition of a QSO is the ack of receipt of two pieces if information from the other party. When I copy RRR or RR73, I log the QSO, because I've already sent R plus a report, and the fact that he's sent
me RRR or RR73 indicates he's copied my R-report. If he sends RR73 or R and his report again, it tells me he hasn't copied my R, so I send it again. And again, if he keeps sending. He can log it when he's satisfied. When he stops sending his report, I log
it. If he doesn't, we don't have a QSO. It's that simple. And for skeds, like online, it's perfeectly legit for the guy getting RRR or RR73 to say so online, like Slack or ON4KST or Ping Jockey. This is VERY common practice when working grid expeditions.
73, Jim K9YC
Jim,
this issue is about operating with a /P or other type 1 prefix or suffix in JT65 mode (same applies to JT9 and JT4 modes), the defect means it is not possible to send a signal report, RRR or 73 message unless the generated messages are
manually edited. The defect is a regression that happened some considerable time ago and it needs to be fixed, which is what I am doing.
73
Bill
G4WJS.
|
