Home New Trending Search
About Privacy Terms
#
#openhamclock
Posts tagged #openhamclock on Bluesky
Original post on mastodon.hams.social

I see that #openHamClock has finally gotten the clue that pins on the map of DX stations, regardless of whether they're heard by my station, or they heard me, upon being clicked, should show THEIR callsign.

It's a big relief. I was getting sick & tired of re-synchronizing my fork and re-fixing […]

0 0 0 0
You are absolutely right. I dug deeper into the logic, and there is a specific coding "prioritization" error in the upstream WorldMap.jsx that causes exactly what you are seeing.
The "Smoking Gun" in the Code
In src/components/WorldMap.jsx (around line 777), the code determines which callsign to display on the map pin like this:
const displayCall = spot.receiver || spot.sender;
Why this breaks for you:
The || (OR) operator in JavaScript picks the first value that isn't empty.
1.
When YOU hear THEM (RX Spot):
◦
spot.sender = The DX Station (e.g., K1ABC)
◦
spot.receiver = N0MQL (You)
◦
The code looks at spot.receiver || spot.sender. Since spot.receiver (N0MQL) exists, it picks N0MQL.
◦
The Result: The pin is placed at the DX station's location (the sender), but the label says "N0MQL".
2.
When THEY hear YOU (TX Spot):
◦
spot.sender = N0MQL (You)
◦
spot.receiver = The DX Station (e.g., G4XYZ)
◦
The code looks at spot.receiver || spot.sender. Since spot.receiver (G4XYZ) exists, it picks G4XYZ.
◦
The Result: The pin is placed at the DX station's location (the receiver), and the label correctly says the DX callsign.
Summary of the Bug
Because spot.receiver is checked first, any time you are the receiver (which is every single station you decode), the map overrides the DX callsign with your own.

(continued on alt text of next screenshot)

You are absolutely right. I dug deeper into the logic, and there is a specific coding "prioritization" error in the upstream WorldMap.jsx that causes exactly what you are seeing. The "Smoking Gun" in the Code In src/components/WorldMap.jsx (around line 777), the code determines which callsign to display on the map pin like this: const displayCall = spot.receiver || spot.sender; Why this breaks for you: The || (OR) operator in JavaScript picks the first value that isn't empty. 1. When YOU hear THEM (RX Spot): ◦ spot.sender = The DX Station (e.g., K1ABC) ◦ spot.receiver = N0MQL (You) ◦ The code looks at spot.receiver || spot.sender. Since spot.receiver (N0MQL) exists, it picks N0MQL. ◦ The Result: The pin is placed at the DX station's location (the sender), but the label says "N0MQL". 2. When THEY hear YOU (TX Spot): ◦ spot.sender = N0MQL (You) ◦ spot.receiver = The DX Station (e.g., G4XYZ) ◦ The code looks at spot.receiver || spot.sender. Since spot.receiver (G4XYZ) exists, it picks G4XYZ. ◦ The Result: The pin is placed at the DX station's location (the receiver), and the label correctly says the DX callsign. Summary of the Bug Because spot.receiver is checked first, any time you are the receiver (which is every single station you decode), the map overrides the DX callsign with your own. (continued on alt text of next screenshot)

Another of the exact same screenshot, but the alt text continues with what was missing from the other one, because of the character limit...

The upstream logic assumes that a spot object only contains one "interesting" callsign, but in your setup—where the server is tracking your specific station—the spot objects contain both your call and the DX call. The || logic is too simplistic and ends up "defaulting" to you whenever you're on the receiving end.
This confirms your observation: It shows the reporter (you) instead of the DX station for all your RX decodes.

Another of the exact same screenshot, but the alt text continues with what was missing from the other one, because of the character limit... The upstream logic assumes that a spot object only contains one "interesting" callsign, but in your setup—where the server is tracking your specific station—the spot objects contain both your call and the DX call. The || logic is too simplistic and ends up "defaulting" to you whenever you're on the receiving end. This confirms your observation: It shows the reporter (you) instead of the DX station for all your RX decodes.

The #openhamclock team has rapidly made more improvements, but they still don't grok the point of clickable pins on the map.

Like, this should be THE MAIN POINT of painting a map with pins of spots, as the CENTER window of a web UI.

They Just... Don't […]

[Original post on mastodon.hams.social]

0 0 1 0

I've been impressed with the work being done on #OpenHamClock - and it's a very nice look, has good flexibility.

But I can't help thinking it's intentionally built for a very different audience.

#HamClock (of old) is for casual, general use. The openhamclock is very active-DXer-focused.

0 0 0 0
Screen photo of openhamclock, but with modification so that when you click on a pin on the map, it doesn't show your own callsign (because showing my callsign there would be incredibly daft and un-useful).

Screen photo of openhamclock, but with modification so that when you click on a pin on the map, it doesn't show your own callsign (because showing my callsign there would be incredibly daft and un-useful).

I've re-modified my fork of #openhamclock from v15.1.7 & have set up a #socat thing to grab WSJT-X UDP messages & rebroadcast them to all hosts on my (tiny) network.

So the web browser GUI display on Rasp-pi gets every decode quickly, & the map display […]

[Original post on mastodon.hams.social]

0 0 0 0
Post image Post image

#FT8 #hamradio #digitalham #hamclock #openhamclock
Sometimes it's hard to skip out of the country. West coast really strong. Here are the 2 Hamclocks. The new one and the older classic.

3 0 0 0
Preview
GitHub - accius/openhamclock: "The original HamClock will cease to function in June 2026. OpenHamClock aims to carry on Elwood's legacy with a modern, open-source implementation that the community can maintain and improve together." "The original HamClock will cease to function in June 2026. OpenHamClock aims to carry on Elwood's legacy with a modern, open-source implementation that the community can maintain and impr...

#OpenHamClock #アマチュア無線 #hamradio

github.com/accius/openh...

0 0 0 0
Original post on mastodon.hams.social

@n0mql.com
Not that we REALLY care about "engagement" in the greater sense. Not at all. That's vanity, & makes me think #AttentionWhore every time I see it mentioned.

To the contrary, all I really care about is making #OpenHamClock more useful to more types of hams, & not just super […]

0 0 1 0
Tighly cropped screenshot of openhamclock.com showing that I've clicked an East Coast station, and it says
N0MQL
FT8 @ 7.077 MHz
SNR: -6 dB

Tighly cropped screenshot of openhamclock.com showing that I've clicked an East Coast station, and it says N0MQL FT8 @ 7.077 MHz SNR: -6 dB

1st problem, #OpenHamClock does not give me the same count-per-band summary. I intend to fix that soon.

2nd problem, though more annoying, click on a dot on the map that your station reported (heard), & the map shows you YOUR callsign!

I mean... insanely un-helpful. I know my callsign.

0 1 1 0
Tightly-cropped screenshot of just the "Live Spots" section of HamClock, wherein 
160m  0
80m   0
60m   0
40m  19
30m  19
20m 116
17m    0
15m 102
12m 105
10m 161
6m     0

Tightly-cropped screenshot of just the "Live Spots" section of HamClock, wherein 160m 0 80m 0 60m 0 40m 19 30m 19 20m 116 17m 0 15m 102 12m 105 10m 161 6m 0

Much heard lately about #OpenHamClock & I'm quite grateful that someone's making something that can replace the soon-expiring #HamClock

However, its author is clearly more on-air than I am. My station is RX FT8 band-hopping 24x7, & my HamClock shows me at a glance what bands are hot HERE.

0 1 1 0
Post image

OpenHamClock as an alternative to HamClock! Completely new development, and it's being expanded with new features every hour.

I'm excited

it's going to be great!

#hamradio #amateurfunk #openhamclock

9 1 3 0

Yes at first glance I'd say that's not nearly as LOUD as HamClock is. 🙂 Like it or not, nice that it's available. I wonder if I can get it to run on my little Inovato Quadra when HamClock bites the dust. #OpenHamClock
#HamRadio

2 0 1 0