Feature Request: Visual indicator for Attended vs. Unattended (Automated) station states

[m-a-r-k-d]

Is your feature request related to a problem? Please describe.

Currently, there is no structural way in JS8Call to distinguish between an attended keyboard-to-keyboard operator and an unattended station operating as an automated relay node.

Because HB (Heartbeat) and CQ queries elicit automated background acknowledgments (HB ACK), a local station's physical presence cannot be verified without initiating a manual free-text chat. This often results in a high volume of missed connections when attempting live, conversational QSOs.

Describe the solution you'd like

I would like to propose a UI/protocol indicator that flags whether a station is actively being operated by a human or running completely in automated mode. This could be achieved by:

1. An "Attended Mode" Toggle Flag: A simple checkbox or status toggle in the main UI window. When checked (Attended), any outbound CQ or directed beacon appends a structural state marker or symbol to the message packet.
2. Automated Status Column Tracking: Expanding the Band Activity or Heard List to parse the user's IDLE state time automatically. If a station hasn't had local keyboard inputs for X minutes, their callsign tag could dynamically shift color (e.g., Green for active, Amber/Grey for unattended/automated auto-reply mode).

Describe alternatives you've considered

Currently, operators have to manually type directed STATUS? or INFO? queries to guess if an operator is sitting at the keyboard based on the idle macro response. This adds unnecessary RF traffic to an already congested waterfall slot.

Additional context

Providing a native way to quickly screen for keyboard-to-keyboard capability would greatly enhance real-time networking and minimize frustration for users searching for active dialogue on the bands.

[ghost]

I understand your point, but frankly, that is what "CQ" is for -- to elicit a response from those willing to reply in real time. Otherwise, using the MSG message-storage capability allows traffic if no one is willing or able to communicate real-time.

73,
-Joe-
K0OG

[Chris-AC9KH]

This one is quite difficult. My station is running unattended about 90% of the time and yet I still handle quite a bit of MSG traffic and relays when running unattended. I typically turn off HB ACK when running unattended. But there's some stations that use @ALLCALL QEURY CALL <THEIR CALLSIGN>? that elicits a response from my unattended station. And then somebody will drop a MSG in my Inbox or query my station for HEARING? and use it for relay. And they know full well I'm not there, but it doesn't make any difference.

[Chris-AC9KH]

I moved this to the Discussion category under Ideas. Anything like this would require a considerable amount of scheming and ideas (that are practical) on how to implement such a thing. It is not really a "bug" or issue that we can do anything with until a concrete plan is laid for it.

[bag-man]

@Chris-AC9KH

I'd like to come at this feature request from a slightly different angle.

Issue / Use case:

1. User does a heartbeat to see which stations they can work
2. User notices they can't communicate with station X, but can work A, B, C, all of which can hear/work station X.
3. Here the relay feature would be the appropriate way to reach X, however only station C has auto relays enabled
4. To find this out, the user has to send a request individually to station A, B & C to see if they give an automated reply. SNR? is fastest I think.
5. Once they see an automated reply from C, they can than try to message station X via station C

Proposed solution:

1. Add an extra bit to the heartbeat ack to dictate whether the station is running in auto mode
2. If a station hears a heartbeat ack with the automode it can use a different symbol than the star in the call list to indicate it's auto replying

I've read the docs and been experimenting, but this seems to be a valid use case without a nice way to work around it. Happy to learn if I have missed something.

Thanks all

[Chris-AC9KH]

Technical issue; there is not an extra "free" bit in the raw payload packet.

Take the example of: AC9KH: K1TWH HEARTBEAT SNR -23 (which I just copied from my incoming)

• Source Callsign (AC9KH): Compressed down to 28 bits using a base-37 hashing algorithm (which handles the standard amateur callsign structure).
• Destination Callsign (K1TWH): Compressed down to another 28 bits using the same algorithm.
• Command Token (HEARTBEAT SNR): A fixed 4-bit integer field that tells the decoder exactly how to interpret the rest of the message (identifying it strictly as a directed heartbeat response).
• SNR Value (-23): Packaged into a 7-bit value for the specific dB range.
• The Final Balance (remaining bits): The remaining 8 bits are entirely consumed by the inner parity check and standard message framing flags necessary to hand the payload over to the LDPC generator matrix.

There is zero extra "free" bits to get the reply to fit in one frame. We would have to break the protocol and transmit two frames for every HB ACK. Which is not acceptable since HB's and HB ACK's take up too much air time already.

[Chris-AC9KH]

Unless @punk-kaos can come up with an innovative way to implement something like this?

[punk-kaos]

Hmmmmmmmm...... Let me noodle on this. There might be a way, but I've not paid that much attention to that part of the code.

[punk-kaos]

Ok, I've got some ideas... There's actually TWO SNR bits in the HB response code. One is old and deprecated. Could potentially be reused for something like this. I'm trying to fit my head around how it might work, but there's a chance.

[bag-man]

Ah interesting, thanks for the quick reply and break down. Could you have a second Command Token? To differentiate between stations with autorelay enabled and those not?

JS8Call-improved/JS8_UDP/NetworkMessage.h

Line 554 in 5147432

enum Type {

[Chris-AC9KH]

@bag-man I'd say, at least in theory, it should be possible to have a different Command Token for normal HB ACK vs one that signifies auto-relay is enabled. While Kelly is scheming I'll look at the code and do some scheming too.

[punk-kaos]

That part should be possible, I'm just trying to find a way to do it thats not totally protocol breaking for older clients. Like it or not there's still a large number of users running ancient versions (Almost 1/2 our userbase according to PSKReporter!) and I'd like to figure out a solution that still decodes properly on older versions.

My current working idea is that we do in fact have TWO ACK commands. One that is returned on a HB response, and one that is returned on a manual ACK. There's absolutely nothing stopping us from having the HB response return ONE ACK reply for relay yes and the other for relay no.

There's also an unused bit on the SNR response itself thats supposed to indicate "Greater than +32dB" but I don't think it actually gets used. I'm trying to figure out a way to repurpose it while still sending a valid SNR number.

[punk-kaos]

And actually there's another potential. All the command frames have the ability to append a 6 bit data field, SNR uses that to transmit the SNR value. ALL of them support it but they're not used. We could potentially send for example the "FB" (CMD 18) message with the SNR bit as 'relay enabled'. Then decode the text the same as SNR. New clients would see the same "SNR -50" or whatever on their client, and older ones would see "FB -50" instead. Not TOTALLY clean, but possible.

[bag-man]

Yeah backwards compatibility is going to be a struggle there, especially if half of users are so behind on their versions. :(

It sounds like you guys understand what I was thinking about, I'm not sure how I can help more beyond this point, C++ is a bit above my skill level 😅 let me know if I can help in anyway. Always keen to learn more :)

[Chris-AC9KH]

There comes a point where you can't maintain backwards capability indefinitely when implementing something like this. If it's backwards compatible "enough" to display FB -50 instead of SNR -50 then you document the change in release notes and the User Guide, noting that you have to upgrade the newest software if you don't like it and that software versions older than 2.5.1 are no longer supported. People who still run 2.2.0 or 2.2.1-devel are linux users who get it from their distribution repo's, and let's face it - linux is at least 10 years behind the two major operating systems in desktop technology in everything from graphics processing to audio handling.

So I wouldn't lose any sleep over such a thing and I think Kelly's idea is workable.