JS8Call unexpectedly changes speeds during transmission of scheduled message sent from JS8Spotter

[John-W2KI]

• REVISED - 7-7-26 with video better illustrating the issue.

I don't know if this may be problem with JS8Call or with JS8Spotter, but I'll describe what I'm experiencing for experts such @Chris-AC9KH and @Joe-K0OG to decide. If this is not the best venue to report this please correct me.

Consider the case where JS8Spotter sends a scheduled message to JS8Call for transmission, and that message takes multiple Tx intervals. If, as an example, JS8Call was set to operate in NORMAL speed mode and Spotter wants to send the message in FAST mode. At the scheduled time, JS8Call receives the message from Spotter, changes speed to FAST as expected, and starts transmitting the message.

However, during transmission of the multi-interval message, JS8CCall autonomously and unexpectedly changes transmit speed back to NORMAL and continues to send the remainder of the message to completion at that (incorrect) speed.

I wouldn't expect the speed to revert to the original NORMAL mode until the message has been completely transmitted at the speed requested by JS8SPotter (in this case, FAST).

Environment: JS8Call version: v3.0.2,
JS8Spotter 1.19,
Windows 11 Pro,
using FLrig 2.0.10 to interface with transmitter,
JS8Call set to maintain PTT between transmit intervals.

A video illustrating this situation is at the following link:

https://youtu.be/8JCSvw02g8I

Is this intended behavior, or a bug? Does it affect the integrity of the received message?

Thanks for your attention.

73, John W2KI

[ghost]

@John-W2KI Try as I might, I could not observe the problem you describe. I tried it on both Windows and Linux, both with and without Flrig for rig control, also with v4-beta and 3.0.2, and of course using JS8Spotter 1.19, using the "Expect" system to generate messages using Fast speed, with JS8Call set to Normal. I found in all cases that JS8Call reverted from Fast to Normal in the next frame after a message-send was completed. This was with plain-text messages.

Then, I generated a sitrep, posted it to the Expect system, set the speed to Fast, and sent it, with no problem. Then, I found that if I tick the box to send it as a MSG, it fails as you describe. This was repeatable on both Windows and Linux.

If I then just create a clean message in the Expect system, typing text that looks like the sitrep messages that don't work as expected, and send them as a MSG, that does NOT fail.

Therefore, I conclude that some embedded code is sent from JS8Spotter to JS8Call a frame too early in some situations. This needs to be looked at by Joe, KF7MIX to see if he can determine what's happening.

73,
-Joe-
K0OG

[John-W2KI]

@Joe-K0OG,

Thanks for looking.

Take a look at the newly revised version of my original post, where the new video even better illustrates the problem. Here you can see that JS8Call changes speed WHILE still transmitting a frame (not between frames). This is fully repeatable here when Spotter sends longer (multi frame) text. I haven't tried it with short messages.

Does this change your supposition about Spotter sending something to Call a bit too early? In the case in the video, it would be FAR too early.

BTW, I am not sending the text as a MSG. I haven't tried that. The only difference between that and what I'm sending is the three extra 'MSG' characters before the other text, and the checksum at the end.

73, John W2KI

[ghost]

JS8Call changes speed WHILE still transmitting a frame

Yes, I observed that during the LAST frame, while transmitting, about halfway through the speed changes. This is kind of "ok" since it finishes the frame at the Fast speed, but certainly is odd, and ought not happen until AFTER the frame is finished. If the auto-generated message is sent as a MSG (tick box checked), this speed change comes into effect at the same time as without sending it as MSG, but there is a checksum appended at the end, and that last frame with the checksum is of course sent after the speed change. I could not observe this if I type the exact same characters into the Expect window as a new message and send it exactly the same way, so I suspect that the auto-generated forms are inserting some invisible control characters in the API stream. Again, Joe, KF7MIX needs to look into this as I think it is coming from JS8Spotter, not JS8Call, but I can't prove that. He can prove it one way or the other.

73,
-Joe-
K0OG

[John-W2KI]

The video shows the speed reversion quite a bit earlier than the last frame.

I imagine the speed change during a frame plays havoc at the receiving end. Did any stations ACK your MSG that had the anomalous transmission?

73, John W2KI

[John-W2KI]

I've sent a synopsis of the issue, referring to this discussion, to JS8Spotter's developer, Joe, KF7MIX, to see if he can take a look. It will be interesting to hear his opinion.

73, John W2KI

[John-W2KI]

Joe,

So after some email discussion with JS8Spotter's developer Joe, KF7MIX, for the time being I'm going to simply remove any speed change requests from my scheduled JS8Spotter messages. Perhaps after some more investigation, a long term solution can be found.

Thanks for listening and taking time to briefly look into it. :-)

73, John W2KI