Support GX1400

[mbof]

GX1400 is another popular SH radio model. It can be programmed over serial wires and could benefit from being supported.

[johannessen]

I keep getting Error: Timeout alerts when trying to connect on https://mbof.github.io/hx/ (current build id 1d3f22776f9134aad9b5bec0834e6b242060e5c0). What would be the best way for me to help debug this?

[mbof]

Thanks for testing! Could you drop here the contents of the console log from the browser's Developer Tools? It probably starts with something like

Wrote command "#CEPSR\t00\t74\r\n"

That would allow me to see at which point it's getting blocked. It sounds like it's either getting timed out right there, or maybe a bit later in the flow.

Another thing you could try, especially if it's getting timed out at the top, is connecting through https://www.serialterminal.com/ and manually sending serial commands like #CMDSY to see if you even get a response through the browser serial API, or if that depends on settings like baud rate etc. If you can figure out a sequence of commands that leads to a working data read, even better — that'll give me a known-good cold-start sequence to try and match.

Thanks in advance for your help!

[johannessen]

All the console log says is this, repeated a couple of times:

Wrote command "#CEPSR\t00\t74\r\n"
Disconnected

I did notice that the timeout happens really fast. What’s it set to, 1 second? Could be worth trying to increase it a bit. Maybe 5 s or so?

I also looked at the stack trace in the debugger, but it didn’t really tell me anything – unsurprising, considering the JS is minified. Would it be possible to deploy a non-minified version on your GitHub Pages? Perhaps that might help a little here.

Thanks for the serialterminal.com tip, I'll try that as soon as I get a chance (~probably tomorrow~ on tuesday).

[mbof]

Thanks. In that case it looks like it's not getting anything back and being able to see if the browser can at least connect via serialterminal.com would be useful, to figure out whether the problem is that HxSync is not sending the right commands, or something lower level having to do with the browser serial connection.

Timeout is 1s. I can try to increase timeout to 5s and produce a non-minified version but will not be able to do it today — will update again when I am able to! (The instructions for running a dev server in the README file should work more or less out of the box if you wanted to try a local build too.)

[mbof]

I pushed an update to https://mbof.github.io/hx-alpha/ with

• Timeout set to 5s
• Built in development mode (not minified)

[johannessen]

Thanks, that’s helpful!

With serialterminal.com, the device’s response is immediate. FWIW, the other tools begin communication by doing a #CMDSY first. But the device seems to respond well to #CEPSR 00 as the first command, too. So I don’t see any obvious problem with the Web Serial API, nor with waitForReady_().

A while back, I suggested it might be possible to simply try and read the first two memory bytes to determine the device model, and branch everything off that. I realise now that this strategy is complicated by the fact that not all device models expect the same speed. You would have to try at least 38400 baud (for the GX1400), possibly also 9600 baud (for the HX models, if they can’t be identified by the USB device metadata).

In the current build, I can’t seem to find the connection speed for the GX1400 at all. Have I overlooked it? All I see is the open() in connectUsb(), but that’s hardcoded to 9600 Bd:

https://github.com/mbof/hxsync/blob/1d3f22776f9134aad9b5bec0834e6b242060e5c0/src/app/devicemgr.service.ts#L88

[mbof]

You're right, the baud rate is hardcoded. At that point in the connection, we don't necessarily know what device we're talking to. We could perhaps try different baud rates after a timeout... What are the baud rates that work for GX1400?

[johannessen]

The GX1400 connection only works at 38400 baud, as far as I can tell.

[mbof]

Thank you. I just pushed an update to https://mbof.github.io/hx-alpha/ that will try 38400 bauds unless it detects the device via USB, which in practice should do the right thing. It's not the cleanest code, but if you can confirm that it works, I could clean it up. Thanks!

[johannessen]

In principle, the new build is working pretty well. After successfully connecting, I've (briefly) tested reading and writing the MMSI directories, as well as DAT save and restore. Looks like all that is working correctly on my GX1400. Nice work!

The timeout may have been short before, but it seems it wasn’t too short. A timeout of 1 s or 2 s should probably be fine.

There still remains an issue, similar to one I've been seeing with hxtool: The first connection after the device is switched on sometimes fails. However, simply trying to connect a second time works fine. So do any subsequent connections.

The exact failure mode varies. hxtool tends to just run into a timeout (on #CMDSY). With HxSync, I’m seeing the following two variations:

config-protocol.ts:60  Wrote command "#CEPSR\t00\t74\r\n"
config-protocol.ts:72  Received line ␀#CMDOK
devicemgr.service.ts:148  Disconnected

Error: Device did not acknowledge status request

config-protocol.ts:60  Wrote command "#CEPSR\t00\t74\r\n"
config-protocol.ts:72  Received line #CMDOK
config-protocol.ts:72  Received line #CEPSD␉00␉62
config-protocol.ts:60  Wrote command "#CMDOK\r\n"
config-protocol.ts:60  Wrote command "#CEPRD\t0000\t02\t68\r\n"
config-protocol.ts:72  Received line #CMDUN
devicemgr.service.ts:148  Disconnected

Error: Device did not acknowledge read

Again, I’ve only seen this issue on the very first connection attempt after switching on the device. The second attempt always succeeds if the first one didn’t. Also, I’ve seen this only when using a Prolific adapter with HxSync, not when using an FTDI adapter. So this issue might be caused by the chipset or driver, and is perhaps not worth worrying about.

[mbof]

Thanks a lot, Arne, for the detailed test and report!

Glad we could confirm that it works when connected. I'll work to clean this up a bit, though unlikely this week.

Re the flakiness of the connection — now that we can confirm that the radio isn't just slow in responding, I was planning on shortening the timeouts back to 1s (which is probably still very generous). Knowing that sometimes the first exchanges hand up, I could try to put this into a probing loop, which would retry getting to the magic bytes a couple times before giving up.