locked sticky Why JTAlert does not support MSHV - The Definitive Answer!

HamApps Support (VK3AMA)

Over the last week I received several direct emails requesting MSHV support in JTAlert. Below is the copy & paste answer sent to each emailer.
  • JTAlert will never support MSHV until it corrects its badly broken UDP Status implementation.

  • MSHV does NOT send a Status UDP message when the Band or DXCall changes despite the UDP API having fields for both those values in the Status message.

  • When MSHV does send a Status message (on a Mode change) it correctly reports the Band and DXCall values. What this means is that JTAlert will never accurately know what Band your operating on or the Callsign of your current QSO partner.

  • Band and DXCall reporting on value changes is critical.

  • There may be other defects in the MSHV UDP implementation (which appears to be a very early version of the WSJT-X API which has received many enhancements), I don't know as my testing stopped after this Status reporting defect was encountered.

The workaround (I am hesitant to call it a workaround) is to temporarily change mode whenever the Band or DXCall is changed. This would have to be manually initiated by the user. This is not practical solution and is not one I will embrace in order to provide JTAlert support.

For those that will ask, yes the MSHV developer has been advised by myself and a MSHV user (who has been requesting JTAlert support).

I will revisit MSHV integration testing when I receive word that this fundamental flaw in its code has been corrected. I will no longer waist my time routinely downloading and testing in the hope these defects have been corrected.

de Laurie VK3AMA