OH1MRR suggested that because FH/OK1M does use pure wsjt-x it causes the
problem.
Could be he is using other software, but as far as I can understand
mainwindow.ccp lines 3930 - 3960 do not care is the Fox true fox or mshv.
If that is the reason, then the problem lays somewhere else in code.
Black Michael kirjoitti 18.9.2022 klo 16.59:
I think it's because your callsign is being hashed and the logic is
not allowing for a hashed callsign.
This section removes hash marks from the foxCall -- but not my_callsign.
I had plain call OH1KH (or OH1KJ) there. When my call is hashed it is
I think it's because your callsign is being hashed and the logic is not
allowing for a hashed callsign.
This section removes hash marks from the foxCall -- but not my_callsign.
if(m_mode=="FT8" and SpecOp::HOUND==m_specOp) {
if(decodedtext.string().contains(";")) { QStringLi
This with my patches in wsjt-x and my own call
20918_112700 21.091 Rx FT8 -19 0.7 382 FH/OK1M RR73
220918_112700 21.091 Rx FT8 -18 0.7 442 FH/OK1M RR73
220918_112715 21.091 Tx FT8 0 0.0 2238 OH1KH KP01
220918_112730 21.091 Rx FT8 -14 0.8 443 EA2DDE R-12
220918_
Can you post the relevant section of ALL.TXT with your QSO data including all
the other decodes around that too?
Mike W9MDB
On Sunday, September 18, 2022 at 07:11:56 AM CDT, Saku via wsjt-devel
wrote:
Hi!
Just worked FH/OK1M on 21.091 using hound mode.
After called a while I got an
