locked JTAlert 2.16.4 & earlier: Caller's sign mistakenly ID'd as grid, then falsely alerts New Grid - there being no match.


TomK
 

I noticed this bug for at least the last 5 versions.
JT mistakenly interprets the caller's call sign as a grid no when the message's format is abbreviated to only contain the caller and called signs.
E.g., JT wen detects/decodes the message, "974Y AN195A" - the caller being a Spanish station.
JT parses out the "AN195A" as a grid no, not the caller's sign.
It then populates the grid column in the DECODES matrix with "AN195A"
I assume it then leaves the caller's sign value blank
It then triggers a new grid alert by not finding any grid value of "AN195A" in the Log DB.
Since call signs rarely match valid grid nos, a New Grid Alert is generated.
If I'm chasing grids, I double click the entry, nothing happens and my head gets balder. 
I assume nothing happens because there is no Caller Call Sign so JT goes NOP.

For the moment  don't recall the other call signs that trigger this bug.
Suffice it to say, "974Y AN195A" triggers this bug.

Suggested Code Change:
Pre-flight check the format of the messages based on token count.
Parse tokens left to right.
If only 2 tokens and 1st is not a call director group (CQ, CQ DX, CQ etc)
.. assume they are Called and Caller
Voila. Fudged and fixed.
Just a thought.

Ps. Still holding my breath for US County alert either by band or not.

Thanks Laurie.
TomK

Join Support@HamApps.groups.io to automatically receive all group messages.