Topics

Cherry Picking Event *9 question


Vlad M
 

I apologize in advance if this question has already been answered or addressed, I thoroughly searched the group messages, but couldn't find the answer.
Observing the logic and behavior of the cherry picker with JTDX, I noticed that quite often after initiating a call of the "CQing" station, the cherry pickers "gives up" after the first call attempt.
There is a number of "legitimate" reasons why the cherry picker stops calling the station (e.g. the station has answered someone else or 3 times calling were exceeded).
However this one I cannot understand. I ran the event monitor to capture this:

I have been trying to to figure out why, but alas...
Any help would be appreciated.
I am running the latest version of Logger32 (4.xx) and latest stable JTDX.
--
73 de Vlad, NØSTL


Bob
 

The idea is that your call to KP4MAQ was not answered, but CT1GFK called. So, the cherry-picker stopped calling KP4MAQ and should have replied to CT1GFK. Apparently it didn't call CT1GFK. I don't know why, I will investigate. SeventyThree(s).
 

On 03/03/2021 3:26 PM Vlad M <n0stl@...> wrote:
 
 
I apologize in advance if this question has already been answered or addressed, I thoroughly searched the group messages, but couldn't find the answer.
Observing the logic and behavior of the cherry picker with JTDX, I noticed that quite often after initiating a call of the "CQing" station, the cherry pickers "gives up" after the first call attempt.
There is a number of "legitimate" reasons why the cherry picker stops calling the station (e.g. the station has answered someone else or 3 times calling were exceeded).
However this one I cannot understand. I ran the event monitor to capture this:

I have been trying to to figure out why, but alas...
Any help would be appreciated.
I am running the latest version of Logger32 (4.xx) and latest stable JTDX.
--
73 de Vlad, NØSTL


Vlad M
 

Bob,
Thank you for the reply.
I completely understand the fact of stopping the cherry picker upon the CQ station answering someone else.
Unfortunately, this is different. I took some time analyzing events numbered from *1 to *13, but wasn't sure on whos end this *9 is originated - my or the other station.
The only speculation I have (I could be wrong, though). If the station had previously unsuccessful incomplete QSO then gave up on it and went CQ-ing, maybe the previous QSO is still somewhere in a buffer "waiting" to be completed?
Like I said, it is just a pure speculation, unless it would make some sense to you.
Thank you very much again for your cooperation
--
73 de Vlad, NØSTL


Vlad M
 

This is additional data regarding this mysterious event trigger. The cherry picker called 6Y5EH upon his RR73 and "gave up" after the first call.
So, it is again EA5OL waiting ????? I thoroughly went through all decoded messages including mine and all other messages +/- 2 minutes in time.
I can not find the call EA5OL being mentioned anywhere... I wonder where it is being originated on my side, on 6Y5EH side or even just a stray data from UDP stream..?
BTW my PSK reporter is off - only Logger32 and JTDX comms via UDP


Has anyone experienced this or it is just me?
--
73 de Vlad, NØSTL


Bob
 

... and, not shown in the picture, but after terminating the call to 6Y5EH the cherry picker should have immediately replied to EA5OL. If/when it did call EA5OL then the decoded message will be shown EA5OL Sent: xxxxxxx Just like you see in the picture where it shows what 6Y5EH sent that triggered the initial call.  73.

On 03/12/2021 6:13 PM Vlad M <n0stl@...> wrote:
 
 
This is additional data regarding this mysterious event trigger. The cherry picker called 6Y5EH upon his RR73 and "gave up" after the first call.
So, it is again EA5OL waiting ????? I thoroughly went through all decoded messages including mine and all other messages +/- 2 minutes in time.
I can not find the call EA5OL being mentioned anywhere... I wonder where it is being originated on my side, on 6Y5EH side or even just a stray data from UDP stream..?
BTW my PSK reporter is off - only Logger32 and JTDX comms via UDP


Has anyone experienced this or it is just me?
--
73 de Vlad, NØSTL


Vlad M
 

Thank you for the comment, Bob.
However as I described before, aforementioned EA5OL (except being mentioned in the event viewer as "waiting") was nowhere to be found either in the general decode or my decode windows.
I scrolled back in time 2 min and couldn't find it being decoded like it never existed on the band.
I also waited 2 more minutes not changing anything - nope EA5OL never was mentioned in any decodes.
So, there was no such call for the cherry picker to respond to....
Hmm... it is a "mystery", hopefully we will eventually find out the reason..
--
73 de Vlad, NØSTL


Vlad M
 

Knowing that Bob is investigating this unexplained ending of the cherry picking event (*9), I was also trying to collect as much data as possible
to find out the cause.
For the most part the cherry picker does what it suppose to do - I am very well aware of its clever algorithm.
However, time to time this ending event would happen.

While running the event viewer, today I came across of this  event ending statement:

Please notice the change of the message - before it was just saying "waiting". Now it added this "I will reply". This tells me this was originated on the other side e.g. at GM2TT.
Obviously, he is running other FT8 application which is capable of generating these comments.
After further research, I came across of this program called MSHV by LZ2HV which is capable of Queueing calling stations.
So, whenever, my call is queued - it ends the cherry  picking causing this event being generated.
Well, for whatever its worth, Bob and All, thank you for you time reading my observations.
--
73 de Vlad, NØSTL


Gary Hinson
 

Hi Vlad.

 

You may have found a bug in Logger32’s cherry-picker logic but personally I doubt it has anything to do with unusual messages sent by MSHV and received on air.

 

As I understand it, MSHV and Logger32 have the capability to queue up our responses to people who call us while we are busy calling or working someone else.  Beyond that, I don’t know how the programs actually do this e.g. how the software selects certain callers for the queue (presumably prioritising one or more out of all the callers), how many callers are queued at one time, how long they are expected to wait patiently in the queue, and how they are called from the queue at some point (possibly when there are no riper cherries to pick?). 

 

Message types in FT8 are defined in the protocol using 6 ‘message-type’ bits.  The Tx1-6 buttons show the most common ones but 6 digital bits allows up to 64 message types.  For example, ‘message containing a hashed callsign’ is another type, as are the contest messages and telemetry.  As far as I know, there is no message type for “Queue me!  Queue me!  Put me in the queue!  I’m patient, I’ll wait!”.

 

You can read more of this stuff in my FT8 Operating Guide, or check out the definitive technical information on the FT8 protocol published by Joe Taylor and team.

 

“K7SP is waiting. I will reply” in the event viewer is Logger32 telling you what’s going on.  The cherry picker has, somehow, previously queued K7SP and is now ready to start calling him.  It is a message from Logger32 to you, the operator, not a message transmitted on-air.

 

73

Gary  ZL2iFB

 

From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Vlad M
Sent: 19 March 2021 05:41
To: hamlogger@groups.io
Subject: Re: [hamlogger] Cherry Picking Event *9 question

 

Knowing that Bob is investigating this unexplained ending of the cherry picking event (*9), I was also trying to collect as much data as possible
to find out the cause.
For the most part the cherry picker does what it suppose to do - I am very well aware of its clever algorithm.
However, time to time this ending event would happen.

While running the event viewer, today I came across of this  event ending statement:

Please notice the change of the message - before it was just saying "waiting". Now it added this "I will reply". This tells me this was originated on the other side e.g. at GM2TT.
Obviously, he is running other FT8 application which is capable of generating these comments.
After further research, I came across of this program called MSHV by LZ2HV which is capable of Queueing calling stations.
So, whenever, my call is queued - it ends the cherry  picking causing this event being generated.
Well, for whatever its worth, Bob and All, thank you for you time reading my observations.
--
73 de Vlad, NØSTL


Vlad M
 

Gary, wow...!!
What a coincidence, your FT8 Operating Guide has been my bedtime reading during this week.
It is a wonderfully written FT8 reference. Thank you for such good job.
What you were saying does make sense.
However, here are some confusing points of the JTDX and Logger32 interaction:
  • I was not aware and never witnessed a queue buffer operation (I will dig deeper into that)
  • Whenever there was a reference to a waiting station, I could not find it  in previously decoded messages. I waited for awhile after this event ending the cherry picking, it showed no any decodes with the referenced call.
So, it is possibly, a bug.
--
73 de Vlad, NØSTL


Gary Hinson
 

HI Vlad,

 

‘Bedtime reading’ eh?  Having trouble getting off to sleep maybe?  😊

 

The idea of [manually] queueing up callers is seen in the fox side of fox-and-hounds operation in WSJT-X, I believe (I’ve never been in sufficient demand to operate as a fox!).  From what I understand, the DX op quickly clicks a selection of callers on his decoded list and the software queues them up to work in turn, allowing the op meanwhile to continue running his legacy-mode pileups, fill the genny, grab a seagull sandwich or take a milli-nap.

 

In Logger32, coupled with the ‘sympathy calls’, queueing is a way to make more QSOs, particularly as I think it prioritizes working “new ones” in the same way as the cherry picker function.  So if we are called by P5DX and VK1ABC while we are working E51ABC, Logger32 sees the decodes and, when the current QSO completes, tells JTDX/WSJT-X to work P5DX next.  I’m not sure if VK1ABC is also queued, or for how long anyone remains patiently in the queue (which may explain why you don’t see queued callers on your screen: I very much doubt that Logger32 randomly invents callsigns to call!).

 

However, we’d have to ask Bob about the logic behind the screen … and Bob’s taking his annual break from this reflector so it’d have to wait.

 

73

Gary  ZL2iFB

 

From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Vlad M
Sent: 19 March 2021 10:42
To: hamlogger@groups.io
Subject: Re: [hamlogger] Cherry Picking Event *9 question

 

Gary, wow...!!
What a coincidence, your FT8 Operating Guide has been my bedtime reading during this week.
It is a wonderfully written FT8 reference. Thank you for such good job.
What you were saying does make sense.
However, here are some confusing points of the JTDX and Logger32 interaction:

·         I was not aware and never witnessed a queue buffer operation (I will dig deeper into that)

·         Whenever there was a reference to a waiting station, I could not find it  in previously decoded messages. I waited for awhile after this event ending the cherry picking, it showed no any decodes with the referenced call.

So, it is possibly, a bug.
--
73 de Vlad, NØSTL