View Issue Details

IDProjectCategoryView StatusLast Update
00028231 - BacklogMaintenancepublic2019-08-30 03:59
ReporterPD9FERAssigned ToKB3NPH 
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionopen 
Summary0002823: Digital Master - Worked status in receive window not showing
DescriptionIn Digital master's receive window there should be a Station worked icon behind the received Call sign.
Problem:

When running digital master on first start and decoding a signal, it does not show the V checkmark when there is a call in the decodeing window that has been worked before.
If you restart digital master the icon does show up.
Steps To ReproduceStart Rig control
Start Logbook
Start Digital Master

In Digital Master decode some signals and observe if you see one that you have worked before.
When it does, there should be a V icon behind the Call sign. (which does not happen)

Restart Digital Master and repeat the step.
You now will see the Icon appearing behind the worked station's Call sign.
Additional InformationTicket #303249

Video showing the issue: https://www.facebook.com/kees.vanengelen/videos/2017592451598050/
 
TagsNo tags attached.
ModuleDM780
Sub-ModuleQSO Window
TestingNot Started

Activities

PD9FER

2018-07-31 05:00

updater  

PD9FER

2018-11-21 09:13

updater   ~0006438

Another report from Ticket #785491

K7ZCZ

2019-08-22 14:34

administrator   ~0008430

We looked at this in the 2019-08-22 meeting. The description isn't particularly clear, so I'm not able to understand the issue. Please augment the description with step-by-step instructions that clearly show the issue.

PD9FER

2019-08-24 09:31

updater   ~0008433

The video says enough to me.
The worked status in the received window of DM is not consistent.

Not sure what steps to show...
Just have a properly Configed Logbook and Digital Master and tune in to any signal of a worked before station (one confirmed in Logbook)

K7ZCZ

2019-08-29 17:26

administrator   ~0008469

We revisited this issue in the team call on 2019-08-29. I was able to extract this information:


  • The "receive window" is reachable by using the "New Window" command in the "QSO" menu; or the "QSO" button on the toolbar. The "receive window" is actually the borderless pane at the top of the per-mode QSO tab that appears after using these commands. Some configurations might have this tab visible by default; mine doesn't.

  • The desired behaviour is that any call sign which appears in the stream of decoded text should be checked against the Logbook. (Thus, the Logbook app must be started and have a Logbook database open.) If the call sign is not found in the Logbook, it appears in the receive window's text stream without augmentation. If the call sign is found in the Logbook, it appears in the text stream with a check mark graphic next to it.

  • It's this behaviour that doesn't work reliably. In the call, it was revealed that the issue is intermittent. In particular, Ferry said that it will fail until DM780 is restarted, then after a restart it will work fine.

  • The issue is reproducible with any scheme that we can decode; RTTY, PSK, CW, and so on.



To repro the issue, we can:


  1. Start up the Logbook. Use a Logbook database with some entries.

  2. Start up DM-780. If necessary, use the "QSO" tool bar button to open a receive window

  3. Set DM-780 to use the sound card for input and output; we don't need a radio and can have DM-780 decode itself as it transmits.

  4. Enter text, including a call sign, in the transmit window

  5. As it's decoded, the call sign should appear in the receive pane.

  6. Entering (and thus receiving) a call sign previously logged should show a check mark decoration in the receive window.



Exercising the feature this way is expected to make it easy to exercise the feature and demonstrate the problem.

In the call, we discussed using the scheduled ARRL Bulletin as a reliable source for some encoded text which might be useful for reproducing the issue. While feasible, The Bulletin isn't particularly desirable, as the transmissions are done only once a day and reception might not be reliable. There are a few RTTY stations active near me which I might be able to utilize, but they're not even as reliable as the Bulletin.

The above process seems feasible, but Tim further offered to provide some recordings which included call sign transmissions to use for testing. This issue is presently assigned to him as a reminder to provide those recordings, though I might be able to make progress without them using the sound card loop-back.

PD9FER

2019-08-30 03:59

updater   ~0008470

Those Repro steps looking okay to me.
One thing to make as a variable though.
Do test it with an MS Access DB as well an MySQL DB

Issue History

Date Modified Username Field Change
2018-07-31 05:00 PD9FER New Issue
2018-07-31 05:00 PD9FER File Added: 37971865_2016650745025554_8599019001881821184_n.jpg
2018-11-21 09:13 PD9FER Note Added: 0006438
2019-08-22 14:34 K7ZCZ Assigned To => PD9FER
2019-08-22 14:34 K7ZCZ Status new => feedback
2019-08-22 14:34 K7ZCZ Note Added: 0008430
2019-08-24 09:31 PD9FER Note Added: 0008433
2019-08-29 17:26 K7ZCZ Note Added: 0008469
2019-08-29 17:26 K7ZCZ Assigned To PD9FER => KB3NPH
2019-08-30 03:59 PD9FER Note Added: 0008470
2019-08-30 03:59 PD9FER Status feedback => assigned