Log4OM

I have been trying to figure out why some SOTA spots don't show up in the Cluster tab. There may be other cases, but certainly the RBNHOLE "reporter" spots don't show up (normally). I don't have any filtering on, but I did notice that if I click the "mode lock" ON they do show up when the radio is in CW mode. However with "mode lock" OFF, and CW, Digital and Phone all checked they don't show up.

I am using the GMA Spider Cluster: https://www.cqgma.org/wwff/doc/DX_Spider_EN.pdf

Image below shows the situation where the RBNHOLE only spots in the cluster management window (see red tick marked spots) don't show up in the Cluster tab. This is the situation with "Mode Lock" OFF and CW, Digital and Phone checked ON.

Note, I think this behavior only happens when the spots come in one-by-one as you are monitoring the cluster. I believe if you do a sh/dx command the RBNHOLE only spots will then show up during the bulk load.

Thoughts?
Thanks! Jim/K7MK

Screen shot of the cluster filter tab please

Terry, this is my normal filter setting.

Well I set up for this in accordance with the file that you provided and it all works fine, see below.

So perhaps you have a CQGMA filter set that is stopping the display


What Log4OM version are you using?

Jim,

I set up your cluster as well and got a RBNHOLE spot pretty quick.

.

Terry,

Version is 2.12.0.0

So I did some detailed logging and found the RBNHOLE spots which come in real time (not via initial load or via a sh/dx) get an "unable to parse message" and therefor don't show up in the cluster tab. RBNHOLE spots which come in via initial (sh/dx) cluster connect or via a sh/dx later in time show up just fine. These spots are formatted differently than a real time spot and are parsed okay (see attached file for comparison).

The only difference I can see between a good "DX de..." spot and a bad one is that the RBNHOLE spot doesn't have a colon after the "callsign". I am not sure that is what is causing the "Unable to parse" message, but it is the only difference I can see. Attached file has comparisons between good and bad as well as the unable to parse message.

For example:

• DX de RBNHOLE <-on the "bad" spot
  DX de AC7MA: <- on the good spot

Anyhow, not sure if that lack of colon is making the parser barf. For now, I can probably just add another sota cluster so I get a duplicate spot in maybe a different format that will drop in fine.

Thanks, Jim

Also..

As an FYI... Here's a comparison, looks like the sota_cluster does include the colon where the dxspider/GMA cluster leaves out the colon on RBNHOLE spots. So if the parser is looking for the colon in the real time spot format, then based on my (random) theory, it looks like the dxspider format is the culprit.

2041 151.236.24.42:7300: K7MK de MM0FMF sota_cluster >
2041 151.236.24.42:7300: DX de SMS: 146560.0 K7JRO/P W7W/CW-086 1841Z
2041 151.236.24.42:7300: DX de K6HPX: 5332.0 K6HPX/P W7A/AE-023 1844Z
2041 151.236.24.42:7300: DX de RBNHOLE: 14063.0 AA0BV W6/NC-235 1849Z
2041 151.236.24.42:7300: DX de N0DNF: 7034.0 N0DNF W7I/SI-153 1851Z
2041 151.236.24.42:7300: DX de SMS: 10116.0 AG7GP W7O/SC-044 1854Z

1858 www.cqgma.org:7300: K7MK de DL0GMA 21-Apr-2021 1858Z dxspider >
1902 www.cqgma.org:7300: DX de WA7NCL: 14062.0 WA7NCL x04s W7W/CW-086 1902Z
1907 www.cqgma.org:7300: DX de AC7MA: 10114.5 AC7MA x04s W7W/CW-086 1907Z
1907 www.cqgma.org:7300: DX de SMS: 14346.0 K7JRO/P x04s W7W/CW-086 1907Z
1909 www.cqgma.org:7300: DX de K6HPX: 18083.0 K6HPX/P x04s W7A/AE-023 1909Z
1909 www.cqgma.org:7300: DX de RBNHOLE 18081.5 AA0BV x04s W6/NC-235 1909Z
1911 www.cqgma.org:7300: DX de SMS: 7253.0 K7JRO/P x04s W7W/CW-086 1911Z


...and it looks like dxspider format doesn't have the colon on aprs2sota spots as well and we get the parsing barf as well.

DXSpider (parse barf):
2021-04-21 21:15:03.4828 TRACE: [ClusterManagement][#=zbWzDXVgIeBx7] : [CLUSTER INBOUND MESSAGE] DX de APRS2SO 7186.0 K6RIN x04s W6/CC-030 2115Z from www.cqgma.org:7300
2021-04-21 21:15:03.4869 TRACE: [FormClusterManagement][#=zbLQOcHWDLGyL_zmH2g==] : CLUSTER: 4/21/2021 9:15:03 PM : [www.cqgma.org:7300] DX de APRS2SO 7186.0 K6RIN x04s W6/CC-030 2115Z
2021-04-21 21:15:03.6847 DEBUG: [#=zf5GnWG5$92Ijwzj5tg==][MoveNext] : [CLUSTER] Unable to parse message:
DX de APRS2SO 7186.0 K6RIN x04s W6/CC-030 2115Z

SotaCluster(okay):
2021-04-21 21:14:43.3422 TRACE: [ClusterManagement][#=zbWzDXVgIeBx7] : [CLUSTER INBOUND MESSAGE] DX de APRS2SOTA: 7186.0 K6RIN W6/CC-030 2114Z from 151.236.24.42:7300
2021-04-21 21:14:43.5160 DEBUG: [#=z9W1chUdmRKnL86Sh$pOpQ6_ke6rG][MoveNext] : Performing QSO search on callsign K6RIN

I'll try to reproduce that issue.
We actually read the 2 main formats, but this seems a little bit out of standard.
I'll check if we can bring it to the standard, assuming that being conformed to the "standard" (or the use) is something on their side

Agree that this looks to be an issue/anomaly with how the dxspider cluster software or GMA's interpretation of how it handles the RBNHOLE and APRS2SOTA spots (i.e. not adding the colon). Other clusters handle it just fine.

So... seems like no issue with log4om, you guys are just using the standard format to parse. I'll send a message over to the WWFF/GMA cluster folks as an FYI.

In Log4OM, I have added the MM0FMF SOTA cluster and Andy's spots are coming through just fine with the colon so avoiding the issue from the WWFF/GMA cluster.

73, K7MK