Hi Larry,
Hi — thank you very much for the detailed and thoughtful feedback. I really appreciate the time you took to analyze how the tool behaves in real operating conditions. Let me address your points one by one and clarify how DXLook currently works, as well as its limitations.
1) Big-gun stations, power levels, antennas, and unrealistic “open band” interpretation
You are absolutely right: a single station running high power and large antennas can make a band look “open” when, in practice, that opening is not usable by the average operator. This is a known and very real problem for all propagation visualization tools.
At the moment, DXLook does not apply any power-based or antenna-based filtering , mainly because:
- Transmit power is not reliably reported in most networks (and is often missing or incorrect).
- Antenna type is almost never available as structured data.
- Many stations that behave like “big guns” cannot be consistently identified across all networks.
That said, your concern is 100% valid. What can be done reliably — and what I have just implemented based directly on your and others’ feedback — is SNR-based mode interpretation, which already removes a very large portion of misleading data for SSB.
2) Digital SNR vs real SSB/CW usability — major backend change already applied
This is probably the most important point in your message, and I completely agree with you.
Based on your observations, I have now implemented SNR-based mode augmentation across DXLook:
- SSB: SNR ≥ 10 dB
- CW: SNR ≥ –5 dB
- Digital: SNR < –5 dB
What this means in practice is:
- Even if a spot comes from PSK Reporter, it can now be interpreted as SSB-capable or CW-capable if the SNR is high enough.
- This dramatically improves SSB and CW visibility, which previously looked empty simply because most spotting data today comes from digital modes.
- This logic is now applied consistently in:
3) Clear interpretation guidelines for SSB / CW / Digital
You are absolutely right here too. Even with better filtering, a visual map alone is not enough without interpretation guidance.
SSB, CW, and Digital:
- Behave very differently,
- Tolerate very different SNR thresholds,
- And require very different conditions to be considered “open.”
On DXLook we already have several blog articles that explain:
- How MUF works,
- How the different views (Summary, Cluster, MUF, Realtime, etc.) should be interpreted,
- How Personalized Band Conditions are calculated based on your grid, geomagnetic latitude, time of day, and space weather.
You can find those on our blog (I cannot insert links
here)
However — and this is an important point — while those articles explain how the system works, there is currently no single, simple “mode-by-mode cheat sheet” that explicitly says:
- “For SSB you generally want at least X dB SNR,”
- “For CW you can expect readability starting around Y dB,”
- “For Digital you can decode far below voice usability,”
- Or how to combine MUF + SNR + real paths into a practical “is it worth calling now?” decision.
I fully agree that such a simple, practical guideline would be extremely useful, and I do plan to add this as a dedicated reference article to DXLook’s documentation. This is an excellent suggestion.
4) Discrepancy between DXLook and dxview.
This is an important point, and I want to be completely transparent here:
I do not know exactly how dxview processes, filters, weights, or augments its data internally.
And this is exactly the original reason why I built DXLook in the first place.
I wanted:
- Full control over every filter,
- Full visibility over every transformation step,
- No black-box heuristics,
- No blind trust in what a colored map “suggests.”
DXView publicly states that it:
- Uses WSPRnet, RBN, and DX Cluster,
- Applies SNR thresholds for SSB (SNR > 10), CW (SNR > –1), and Digital (down to –28).
But there is no full public documentation of their internal logic regarding:
- Exact time windows,
- De-duplication rules,
- Path weighting,
- Multi-source merging behavior,
- Outlier handling,
- Or any possible reputation filtering of stations.
Because of that, when DXView shows more points, it could be due to:
- Different time windows,
- Less strict filtering,
- Different data merging strategies,
- Or simply duplicated overlapping data from multiple sources.
Without access to their internal processing rules, it is technically impossible for me to guarantee 1:1 visual parity, and I prefer to be honest about that rather than speculate.
Once again, thank you for the high-quality feedback — this is exactly the kind of input that genuinely improves the platform.
73,
Rodrigo - AK6FP