JS8Call-improved
Collection of material: The HB conflict. #163
Replies: 72 comments 4 replies
|
I suggest we can collect material in the form of short "user stories". This can be actual stories, good or bad, that have actually happened, or else a more formal user story as used in (some) professional IT development. I suggest to follow industry custom and tell these stories in the first person, even if it isn't your personal story. |
User story: Having fun with down underI mostly work on 20m and 40m. My operating style entails sending HB every 10 or 15 minutes. One day, I received a HB reply indicating a good SNR from an Australian station. Given my mediocre equipment, Australia is somewhat rare and I got excited. It seemed the VK op wasn't ready to engage with me right away, so I left a MSG on his station. Some time later, another HB of mine was greeted with the announcement that a reply MSG was waiting at that station for me. I could successfully retrieve it. That rather made my day. Formal user storiesAs a little pistol station, I want to send HBs frequently to catch openings to faraway places or stations when they occur. |
User story: Need a quiet band to hear weak signalsI often work at SNR limit. Any strong signal also present in the frequency vicinity will degrade my experience. As a weak signal enthusiast, I frown on frequent HBs and wish people would limit their HB activity to the absolute minimum, or else not use HBs at all. (Harvested from #39 .) |
User story: Want a clean band for JS8 activityIn my end of the woods, there are often comparatively few JS8 stations on the air on any JS8 channel. According to the band plan, other modes are also invited to use those frequencies. I find regular HB activity helpful to keep other ops informed that this is the JS8 channel, in other words, to keep the JS8 channel clear of RTTY, Olivia, SSB, and similar traffic. |
Possible user story: QSY supportThis is an idea. I'm not sure whether anybody actually wants this. As a group roundtable or net participant, I would like to have a functionality that makes it easy for the entire group to QSY a few kHz up or down the band, so we can enjoy a clean QRG void of traffic that disrupts our group discussion or net activity. I want this support to leave no-one behind on the band's regular JS8 frequency, including people that joined the party a bit on the late side. And I want my station to return back to the regular JS8 QRG after the roundtable ended. |
A question that should be considered; is it proper to use a timer for automated transmission of HB's and/or CQ's? This constitutes the legal definition of a beacon station. Unattended automated beacons are illegal at frequencies below the 10m band (at least in the U.S.), and yet this is common practice with the JS8 mode, and current software, because the timer feature enables it. |
|
I suggest that we push the fix from #39 (comment) for now, unless/until some other approach is determined. It is a qucik, easy, painless fix. That will make the 2.4.1-devel code properly functional (based on the current expectation). I think the disablement of HB ACKs when there is ANY traffic passing (that is not to/through my station) is maybe too agressive, but the way it is now it seems to be working acceptably. I do occasionally observe that HB ACK is disabled for unreasonably-long times, but doesn't seem a deal breaker. Maybe some compromise solution is to make it less aggressively disabled below 1000 Hz (e.g., not disabled at all below 1000 Hz unless traffic is to/from/through my station), but only aggressively disable it above 1000 Hz. If this idea has any merit, take it and run with it! 73, |
The way it is now if a MSG is in-process and the EOT character is never received, the timer will reset it. I haven't personally tested the fix in the PR that @aknrdureegaesr submitted here #47 |
I built & and am testing https://github.com/JS8Call-improved/JS8Call-improved/tree/reestablish_HB_UI_kludge today, and it seems to work as before. It seems that it takes four 15-second cycles for the reset. As I mentioned before, this behavior is acceptable to me, and may be a reasonable compromise, if some more-sophisticated scheme is not put into place (like the 1KHz differentiation I mentioned earlier). 73, |
It should not take four frames for reset. The EOT character should reset it immediately when it is disabled for incoming MSG's. I'll have to take a look at the code closer and see what's broke this time. |
No, it is not a duplicate, it is only related. The issue over there was resolved by re-establishing the old HB UI. During the discussion, we found that there is more in the HB arena, stuff that needs to be addressed eventually, but is less urgent. Mainly: Which behavior do we want? How can we serve the community best? The present suppression of all HB activity while there is any ragchew QSO going on anywhere in the band is considered too aggressive by some (including me), but that functionality is applauded by others (including you, @Chris-AC9KH ). So it is an open question how we can serve our community best. Preferably both sub-communities. |
I am not a lawyer, but just using a timer does not mean that the station is unattended. I may still be present and attending to the station, at the same time use the timer, as a convenience feature. A timer is functionality that would allow me to leave the premises and still leave the station up and running, so it legally becomes a beacon. Yes. Personally, I never do that. I switch to RX only when leaving for a walk or for whatever. We are both harboring a suspicion that there may be people who let their station run while they're not controlling it, and in jurisdictions where that's not allowed. That's something they have to settle with their administrations. Rules differ from country to country. (FWIW: In Germany, any unattended transmission requires a special "beacon"-type license. There is no allowance for "answers to certain signals that come in over the air". So for us: You're not there, your station may not transmit. Period.) I run on the principle that adults are adults and responsible for knowing what they are doing. I would also not mind publishing, in amateur radio media, the schematics of an amplifier that can put out 1 kW of HF, even though the German legal limit is 750 W. As a matter of fact, I also harbor a suspicion that there are people who run power above the legal limit. So, in my opinion, the legal situation is not a reason to not have timers if we conclude that timers benefit our community. We might consider adding a warning about possible legal implications to our UI, if you'd feel better if we had that. |
Maybe I'm wrong (@Chris-AC9KH correct me if so), but I don't think this is how it currently works. As I understand it, if there is a directed MSG being passed (not just ragchew - normal keyboard-to-keyboard chat between two directed stations) then HB ACK is suppressed for all who see that a directed MSG is being passed. Is that the current behavior? If so, I think that's not overly-agressive. At least in my area on 40m and 80m, MSG is not used to do live chats (no need to store a MSG at each other's station for each "over" while chatting real-time), but MSG is only used to store a message at a presumably-unattended station for later retrieval by the receiving-station operator. 73, |
This might not be a bad idea. Not only about legal implications, but about courtesy considerations (set your beacon TX to below 1KHz, please!). However, if we have something that keeps popping up, it will irritate people (including me), so we need to be careful to place any such helpful hints in a way that it won't nag the operator, maybe by having it present in the appropriate settings windows. 73, |
|
I stick to the opinion that HB is not even a necessary feature. A forced channelizing is a poor band-aid and breaks utility of a segment of the WF for other purposes in multi-mode operations off standard frequencies; those users want out of channel to prevent putting HB in otherwise used WF. But removing HB solves that too. HB is a bad feature transfer from FT8 interactions and is more egregious than FT8 CQs running (because HB causes other stations to transmit thereby losing receives). The fix we have in for that is helping, but its not perfect. Checking if stations hear you should be via a manual directed SNR? to a station you have in heard list or relayed HEARD? checks. HB feature deprecation along with user manuals and video guides can fix this problem over time. The alternative is having the 'standard' frequencies become designated beaconing spectrum and abandon them. |
|
It's true that the HB is not even needed. I don't use it all and the mode works perfectly fine without it. Karl did not get hold of me yesterday by making the problem worse and sending out a HB. He put out a plea on ALLCALL and got a human operator on the line instead of a computer. It's also true that the HB itself is not the problem. It's the automated response to it that causes the issue. Using it to send out a MSG notification also does not work because about 9 times out of 10 the person sending the HB is not home and misses the MSG notification anyway. It's gotten to where this all people use the HB system for is to get SNR reports. Some of them send it automatically every 15 minutes. Some time back I wrote code that stores the callsign and timestamp of a HB sender in a sqlite database table. If they send again, it compares the timestamp from the previous and if it's less than 60 minutes it automatically adds them to my HB block list. Such a thing would probably not be suitable for a production release, but it was amazing how fast my block list filled up. |
|
For consideration HB deprecation plan Decreasing the impact of HB timers: standard release change minimum timer for HB to 30mins if in channel and 60mins if out of channel. Embracing Jordan’s suggestion to QSY, improved fork could handle deprecating HB across WF via a collective QSY to remove the HB channel from range users recommended to use a 1k shift from standard freq in improved version, moving the HB channel out of WF
deprecate HB ack outside channel in improved
this allows improved users to:
evaluate complete removal of HB in future pending outcome of adoption and feedback groups using JS8 on non-standard frequencies will still set collective group expectations for HB use and WF subchannels to run JS8 within
|
Trouble with that is then you're competing (on some bands like 80m) with other modes. The ARRL W1AW station runs their so-called "CW practice" on 3,581.5 kHz @ 1KW and they splatter across 3kHz worth of spectrum with it if you have a decent antenna. On my 1/2 wave end-fed ground-plane vertical it comes in 30 over 9 while I'm trying to get MSG's thru to a station in Sweden @ 3.8W. You can pick up their ridiculous transmission by hooking a up to coax feeder to a dead pine tree. We'll see how the new 60m segment turns out tomorrow. Since that is a shared military frequency with USAF air-to-air communications you have to get off it immediately if they come on the band. But how much you wanna bet the automatic, unattended HB'ers and ACK'ers will show up on it? |
|
While HB does get overused, I like to make my system available for message relay and I like to relay messages to people i cant make DX with. I think HB is pretty important to this feature is it not? |
|
I don't use HB at all for relays. I use either HEARING or QUERY CALL to establish a relay path. HB is only basically good for getting SNR reports, and that's all most people use it for. The original idea behind HB is that it's supposed to establish a "mesh network" of who you can communicate with. That don't work either because a lot of people turn it off. |
|
So many comments, I'm not sure where my response may fit into the flow, but please consider this... While HB may not be needed, though I suspect it's not the HB that is the issue but rather the flood of responses, I do suggest that an automated/timed send ability is needed. Propagation is a monkey throwing poo. I find it very convenient to return to my station and see the activity of other stations. It helps me know the 'likely' times of reaching certain stations. If they have been away, and I've been away, without some sort of TX there will be no data. This is usually filled in with incidental requests. So, the situation is not dire. Yet, perhaps if HB was altered in one of two ways, the information can be garnered without the current clashing. Consider one of the following as a potential solution...
When HB was introduced it was a good idea. Perhaps it's no longer needed, but a portion of it's original purpose is. |
|
@capitancurt I don't necessarily disagree with what you say. But I will point out that WSPR is much better at determining propagation, it's what it was designed for. This is the results of a single transmission on 60m at 500 milliwatts power input to my antenna. And this tells me way more, in a lot less time, than a bunch of HB's. 
So then run an The real reason most people use HB's is get SNR reports. And that is the most important thing to them, and all they use JS8Call for. Some people put them out every 10-15 minutes on a timer and they're not even at the station which is illegal in any jurisdiction I'm aware of. Now that it's already out there it's not an easy problem to solve. More thought should've gone into the potential abuses of automated operation of a HF transmitter at square one. Too much automation turns it into a computer socialization mode and takes the operator out of the picture. |
|
To prevent excessive spamming by HB's and ACK's I could expand the timeout to 60 minutes for HB ACK's. So if a station sends a HB, your station would ACK it the first time. But if another one is sent before 60 minutes expires it would not respond to the second one. And every time the sending station sends one, the timer resets and starts over. This would not fix anything in the older software to suppress the HB spammers, however. And now that the problem is already out there, and it's all some use the software for, I'm sure it would create an uproar if they don't get their Regularly Scheduled SNR reports. Like I said, this is not an easy problem to fix now that it's already been created. But I view a potential solution as being better than the alternative. Which is at present people get annoyed with it, just turn it off or put the HB spammer in their block list and it don't work at all. The other alternative would be to deprecate HB altogether. I personally haven't sent out a HB for months, and never reply to them. The software works fine without using it at all. |
|
I could get on board with a proposal to reduce or remove automatic HB acknowledgements. That seems like it would keep the value of a network announcement (hey my station is on the air if you’d like to leave a MSG) and reduce the amount of noise/interference of the replies breaking in every few minutes.
Best,
Jordan / KN4CRD
…On Feb 20, 2026 at 10:16 AM -0500, Chris Olson ***@***.***>, wrote:
To prevent excessive spamming by HB's and ACK's I could expand the timeout to 60 minutes for HB ACK's. So if a station sends a HB, your station would ACK it the first time. But if another one is sent before 60 minutes expires it would not respond to the second one. And every time the sending station sends one, the timer resets and starts over.
This would not fix anything in the older software to suppress the HB spammers, however. And now that the problem is already out there, and it's all some use the software for, I'm sure it would create an uproar if they don't get their Regularly Scheduled SNR reports.
Like I said, this is not an easy problem to fix now that it's already been created. But I view a potential solution as being better than the alternative. Which is at present people get annoyed with it, just turn it off or put the HB spammer in their block list and it don't work at all.
The other alternative would be to deprecate HB altogether. I personally haven't sent out a HB for months, and never reply to them. The software works fine without using it at all.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
@jsherer I think removing the HB ACK would create a major uproar over people not getting their SNR reports. But limiting the number of ACK's to a station that sends them constantly (say every 15 minutes) is very doable. |
|
I think that only a very small part of the js8call users are bothered by the hb. The majority of users use the heartbeat function and almost all of them do this in the intended band section. Of course, there are individuals who don't stick to that :) |
|
A possibility with regard to creating a reasonable limit of ACK responses is for every station that receives a HB and has HB ACK turned on would create a random callback timer to ACK only if it has not yet seen X number of other stations respond. This would have a race condition on how many start at exactly the same time, but at least it would reduce the flood and noise seen across the WF on these responses mixing with each other. |
|
HB system is invaluable for estimating relay pathways with JS8Call. if HB system is suppressed then we will have to @allcall SNR? And would that be enough? |
|
There is nothing being looked at currently, or in the works, to change anything with the HB networking system. For users that don't want to use it it can be turned off. And for users that do use it but are annoyed by people sending HB's every 15 minutes, they can end up in your block list and your station won't respond to them. That's the theory we're going with at present. |
|
So I wrote this code some time back. I just updated it to fit in the new source tree directory structure and rebased it on current master. Removed it from mainwindow.cpp and made a new class for it, and put the UI_Constructor member function() in JS8_Mainwindow, which houses the member functions() of the class. What it does:
I tried code that simply suppresses the ACK if it's less than 55 minutes. But I found out that the habitual offenders are always habitual offenders and your station will just ACK them again the next time they come on the air. They never learn that sending out frequent HB's just spams the bandpass. Adding them to the blacklist has worked the best and you can un-blacklist them any time you want. I never added any UI setting to turn it on or off because I think it should be universal. But I'm sure at least some of the habitual offenders who are "professional HB'ers" will go into a coma over it. Because it will effectively shut them down until they learn that sending HB's at less than 1 hour intervals is detrimental to the entire system. |
|
So I decided to add a UI setting to turn on or off automatic blacklisting of stations that send HB's at <55 min intervals. And decided to PR it into master: #283 Since there is no real consensus on use of HB's this does not change HB functionality at all. What it does is give users who want to use HB ACK, but are annoyed by stations that send at less than 1hr intervals, an option to turn on automatic blacklisting of those stations. Based on @jsherer comment above:
I decided to try this as a HB ACK rate limiting mechanism that is totally optional to use. That way if the "professional HB'ers" don't get their expected responses, maybe they'll realize they been blacklisted because people don't appreciate their rig firing up all the time to answer their timer-controlled HB's at unreasonable intervals. It allows users to use HB ACK but limit your ACK's to stations who "obey the rules". I've had this code laying around for about nine months. So we'll give it a shot in JS8Call 3.0 and make it optional so people can't complain if somebody chooses to turn it on. It is disabled by default. 
|
|
It’s opt-in and reasonable so I think it's a fair compromise. Thanks Chris!
Best,
Jordan
…On May 3, 2026 at 8:35 PM -0400, Chris Olson ***@***.***>, wrote:
So I decided to add a UI setting to turn on or off automatic blacklisting of stations that send HB's at <55 min intervals. And decided to PR it into master: #283
Since there is no real consensus on use of HB's this does not change HB functionality at all. What it does is give users who want to use HB ACK, but are annoyed by stations that send at less than 1hr intervals, an option to turn on automatic blacklisting of those stations. Based on @jsherer comment above:
> I could get on board with a proposal to reduce or remove automatic HB acknowledgements. That seems like it would keep the value of a network announcement (hey my station is on the air if you’d like to leave a MSG) and reduce the amount of noise/interference of the replies breaking in every few minutes.
I decided to try this as a HB ACK rate limiting mechanism that is totally optional to use. That way if the "professional HB'ers" don't get their expected responses, maybe they'll realize they been blacklisted because people don't appreciate their rig firing up all the time to answer their timer-controlled HB's at unreasonable intervals. It allows users to use HB ACK but limit your ACK's to stations who "obey the rules".
I've had this code laying around for about nine months. So we'll give it a shot in JS8Call 3.0 and make it optional so people can't complain if somebody chooses to turn it on. It is disabled by default.
Screenshot.2026-05-03.at.19.31.55.png (view on web)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Uh oh!
There was an error while loading. Please reload this page.
Over in #39 , we found that there are different styles of operating with JS8. These result in different opinions regarding what HB are good for, and when both HBs and also HB replies should be sent.
This issue aims to collect insight about those different operating styles.
The hope is, that some picture may emerge that will make it clearer
All reactions