Give directed commands higher priority over messaging#172
Conversation
|
Example of the new get info string on MacOS 
|
|
That's stupid. |
|
I agree, but that's what the community wants. While I was explaining better how it works Jordan showed up and blocked me from the thread and said the software should not be "policing" what people want to do with their fully automatic features. It was made perfectly clear that Full Automatic Animal Mode is JS8Call's main feature with HB's and directed commands. Messaging is secondary and was tacked on top of FT8 with some modifications. Even leaving in suppression of HB ACK's for incoming MSG is questionable because those all-important HB ACK's were DESIGNED to take priority. So this fixes it and restores JS8Call to fully automatic AA-12 "shotgun mode" so the band gets plastered with those all-important SNR's. |
|
It was also claimed that all this automatically generated "noise" on the band helps keep FT8 away. |
|
I couldn't cherry-pick this into a release/2.5.2 branch on top of release/2.5.1 due to refactoring and breaking down mainwindow.cpp in the meantime. So I manually applied the commit on top for a release/2.5.2 branch. |
|
I'll add that I don't think this actually changes much except for So I don't think it will change much for the "average" user, other than being able to watch the total chaos when some of these |
|
Well, I have grown to like it the way it is now, and was sad to see the complaints. I think the complaints may be from a small number of users, like those who continuously keep sending "@ group SNR?" queries, which really splatters the whole waterfall. There is nothing we can do about that, but I HOPED some education along with the current suppression scheme would calm down this situation. If we at least have the HB ACK suppression at my station while my station is receiving a MSG, that is worthwhile. So be it... 73, |
|
I agree with you @Chris-AC9KH that a quick 2.5.2 release based on the current 2.6.0 master so as to include the improvements there, would be good. Or, should we just call it 2.6.0 since the code reorganization is quite extensive? 73, |
|
@Chris-AC9KH I get your frustration, and feel the same, but suggest that we leave the get info string as it originally was so as to be a little conciliatory. 73, |
|
I do not want to release a patch on top of master right now. It's got stuff in there that needs more testing or refinement. I already got a release/2.5.2 branch on my local repo here, just haven't pushed it yet. It might take awhile on the weekend to get MacOS notarization tickets back from Apple, so I should do release builds on that branch and get them sent in. I do think the new description is more accurate. Despite the original claims re weak-signal, JS8Call is used primarily for automatic beaconing and signal reports at high power, messaging is secondary and according to Jordan that was by design. He spent most of his time designing fully automatic "features", very little time on refining weak-signal messaging. Frankly, Olivia 8/250 blows JS8 right out of the water for weak-signal MSG'ing reliability. I don't see that it's ever going to replace the 10's of thousands of ARES/RACES groups that use Olivia and the NBEMS system. JS8 just does not have that level of reliability with its "framed" sending/receiving system based on FT8, and all the extra automatic-generated noise it puts in the passband which blows the SNR. Olivia can make it thru all that QRM at -25dB with 100% reliability. JS8 can't. |
Ahhhh - I understand. Makes sense. Can we include the mailbox improvement in a 2.5.2 patch? That was a really good fix, and I don't think needs more testing to be confident it's a good one. I still think that leaving the info string as it was may help keep the feathers from getting further ruffled... Yeah, Olivia (and some of the other MFSK type modes) are impressive in their capability for message handling. 73, |
|
IMO, only applying one patch to a 2.5.2 release is sufficient for what many consider a "bug". The Message Box enhancement is more of a 2.6.0 thing and again, requires manual insertion into the 2.5.x codebase after refactor of the whole mainwindow class and UI. Patch releases are only to fix bugs (or in this case a perceived "bug"), not to add new features. |
|
@Chris-AC9KH Very good - makes sense. You are correct that we should not add new features to a bug patch release. One other minor thing that might be considered a bug: I noticed on the Help->About screen that the link to "this repository" points to https://github.com/js8call/js8call rather than the https://github.com/js8call-improved/js8call-improved where this variant comes from. Shouldn't the -improved version point to the -improved repo? 73, |
|
It COULD. But it was left that way because that section of the About describes the old js8call that originally came from that repo. While the link above it points to -improved where development is now, and which contains all of the same history, that was left that way un-purpose. So it's not an oversight or "bug". The js8call.com website actually points to that repo as the Official repository, despite the fact that it's dead. If that ever changes we'll fix that link in the About. |
wmiler
left a comment
There was a problem hiding this comment.
I don't like this, and one or two users shouldn't be forcing this.
@Chris-AC9KH O.k., I see what you are saying. It's a little confusing, but not a problem.
@wmiler I agree with you, but am good with at least having HB ACKs from my station suppressed while my station is receiving traffic. I think that is the most important function to retain. 73, |
|
@wmiler well, somebody will have conduct some sort of poll on the forum. Since I'm now censored/blocked by Jordan after trying to explain all the technical details, somebody else will have to try :-) |
|
@Chris-AC9KH @wmiler Here is another perspective: If we push this change out so that HB ACKs are only suppressed at the receiving station while that station is receiving a MSG, AND kindly ask that stations not do @ GROUP SNR? all over the place and instead use HBs, AND kindly ask that stations limit HB ACKs to below 1000 Hz, that will clean things up a LOT! So, maybe this change along with some gentle, kindly education & persuasion could yield some good? 73, |
|
I do have a draft 2.5.2 patch release in place, with MacOS assets, just in case. |
|
I vote for @Joe-K0OG to give that a whirl, he seems to be the most customer friendly person. :) |
|
@Joe-K0OG that's what I was thinking with this. It won't make much at all any difference to the "average" user. Only the big complainers that go into a panic if their SNR's don't come in. Then maybe scheme on coming up with a better solution for 2.6.0 since apparently Jordan is not liking his automatic "features" being suppressed in favor of MSG'ing taking priority over the automatic stuff. |
If you really knew me, you wouldn't say that... I'm not a people-person - just ask my wife! Here is what I suggest. Let's go with the patch that @Chris-AC9KH has prepared, and I'll post an explanation, and a plea for people to avoid these waterfall-filling techniques, and try to use HBs and keep them below 1000Hz in the settings. Are you guys good with that? 73, |
|
@Chris-AC9KH I'm testing 2.5.2 now, and find that other traffic on the waterfall (not involving my station) is still disabling HB ACK on my station. I think the "fix" didn't take effect. 73, |
|
@Chris-AC9KH By the way, none of that other traffic on the waterfall was MSG traffic, but was still some WFD exchanges going on. 73, |
|
@Joe-K0OG that's correct. It will disable HB ACK if MSG'ing is detected anywhere in the passband. Same as 2.3.1. Prevents the big ACK blast, which wouldn't be a problem if they were all below 1000Hz, but they're not. On 30m today EVERYBODY has HB ACK's scattered all over the place. |
|
@Chris-AC9KH I'm sorry for spamming you with so many quick messages... I just noticed that with 2.5.2, as soon as my station sees something like "AC9KH:" in a frame, HB ACK is immediately disabled for a frame, then is enabled when the next frame is sent (e.g. building the complete now two frames "AC9KH: K0OG HELLO"). If there are multiple staggered frames of "CALLSIGN:" due to a lot of traffic, my HB ACK will be disabled until these "CALLSIGN:" frames stop. Hopefully this makes some sense to you and you will understand where the problem is. 73, |
|
@Chris-AC9KH Well, I guess I'm really misunderstanding something. I thought that 2.5.2 would revert to this: only if "MSG" traffic is sent to my station, would the HB ACK be suppressed so that my station would not bust the incoming MSG traffic. EDIT: So, what is it that 2.5.2 does differently from 2.5.1? 73, |
|
Or what I'm saying is, this PR has nothing to do with release/2.5.2. That branch simply contains this PR, which I ported to the old codebase as a patch release. So this PR puts in place the same thing that release/2.5.2 has, but master and release/2.5.2 don't have to be the same as release/2.5.2 is the same as release/2.5.1 with this patch applied to it. In other words, when 2.5.0 diverged from master, all 2.5.x releases diverged forever and only have patches applied them. Branch master is a completely different animal from 2.5.x. |
|
O.k., I'm confused (again!) ;) Exactly where do I go to find what we intend to release as 2.5.2? Are you saying that it's not the same code as pulling the latest from Github, then checking out release/2.5.2? Also, should there be a parallel tag "release/2.5.2"? I don't see it there. @wmiler Wyatt, can you initiate the builds on the appropriate code so we can release it? I poked around and it wasn't clear to me how to do that. I'll break something if I poke any further, ha! 73, |
|
There is a release/2.5.2 branch, but the code in that branch is different from master because mainwindow.cpp was broken down into member functions in the mean time in master. The code functionality is the same between the two of them. But mainwindow wasn't broken down yet in 2.5.x. There will be no tag for release/2.5.2 until it is released because the tag gets generated when the release is published. |
Ahhhh - got ya. So, the code I'm testing from release/2.5.2 is correct. Do we need @rruchte Rob to review before we can proceed? 73, |
|
@Joe-K0OG I can pull that branch and run through it today. |
|
I've been running that branch ever since I built the MacOS releases. It works nice, same as 2.3.1 was. Haven't had anybody break and incoming yet with directed commands, but that was very uncommon in the first place except for callgroups with everybody sending out SNR?. It works perfectly for normal messaging and shuts off the HB ACK like it should. Frankly, and I think I've mentioned this numerous times, the original mod that 2.5.2 has I thought was pretty good. Shutting down the directed commands I never necessarily agreed with it, and only did it based on the complaints from the callgroup captains. So this actually restores it to what I thought was reasonable in the first place. |
rruchte
left a comment
There was a problem hiding this comment.
I personally don't like the change to the program description, but everything works as intended.
|
@rruchte I can change the description back to what it was. But it's not really accurate. My rough guess is that about 75% of JS8Call users use it for automatic beacon/SNR system, and that's all they use it for. |
d3d8821 to
c49a383
Compare
@Chris-AC9KH Doesn't it also need to be changed in the release/2.5.2 branch? It hasn't been built/distributed yet. 73, |
|
No, I don't think so. I don't know of anywhere it's used in the software anyway, except on MacOS which has a special info string that is separate the project description string. |
O.k., that makes sense. I was struggling to find out where (other than MacOS) it even appears - nowhere on Win or Linux that I can see. I guess we are still waiting for Rob @rruchte to run the builds so we can publish it. 73, |
|
I built locally to test before I approved the PR, do I need to do anything else? I don't how to use the build system here to create releases. |
@rruchte I've been testing 2.5.2 on Linux and Windows, and Chris on MacOS, so I think we are good to release 2.5.2. The MacOS distributables are in place, so we need CI builds for Windows and Linux. Is it @wmiler who can do that? 73, P.S. Oops - somehow another Wyatt got in my message! Apologies to whoever that was! |
|
@wmiler Wyatt, I hope I didn't mess up anything, but decided to start CI build workflows for Linux and Windows for the release/2.5.2 branch. I'm not sure what needs to be done next to post that as the latest release??? After the CI builds are finished, I'll test them. 73, |
|
I got the builds here for Linux and Windows. I usually grab those from the run, unpack them, test them to make sure they work, then upload to the assets. I'll do that this evening when I get time. Thanks Joe! |
Good Chris. @wmiler Wyatt, I put together a draft release. Please check and make sure I did everything correctly. I think all that needs to do is to tap "Publish" and she will go. The one thing I'm not sure of is the source code. Will that be tacked on automatically? I don't need to upload the source.zip and source.tgz files do I? 73, |
|
@Joe-K0OG the source archives will be generated on publish, along with the tag. However, do NOT publish until every installer has been tested, verified that it is ver 2.5.2, and runs correctly. Only the Mac installers have been tested to-date on both MacOS 12 and MacOS 26 with both Apple silicon and Intel. |
|
The arm64 Linux AppImage is verified. The Windows installer is verified on arm64 Windows 11, but not on x86_64. Wife is using my Intel Mac mini for recording some stuff so won't be able to test the x86_64 linux and Windows builds for awhile. |
|
I downloaded and tested the Linux x86_64 AppImage, and the Windows installer version earlier today when they finished CI builds. All good - showing version 2.5.2, and working properly. I'll leave it to one of you to publish when you think it is all in good order. 73, |
|
OK, I pushed out the 2.5.2 release, which will hopefully appease the masses. If people don't like directed command auto-replies they can turn it off in the Settings. For release assets it's very important to keep the same naming convention for downloads, i.e. the Windows installer should be I also updated the website. And while I was at it I formatted the HTML so it's easier to read and edit. I don't know what to do about the website. The official website is the GitHub Pages one that anybody can keep up-to-date. Jordan says he wants js8call.com but nothing ever happens with it - he either doesn't own that domain, or intends to keep it as-is with outdated information on it pointing to the old dead repo. Everybody now uses the js8call-improved.com website anyway. And it's basically a copy of the GitHub Pages one (or the other way around), and I think it would be trivial for @mgochoa57 to change the DNS records to point to the GitHub pages one to make it easier to keep up-to-date. This has been talked about several times, Jordan never does what he says. |
@Joe-K0OG Joe, you never need to grab the source.tgz/zip files. Just going with the installer(s) on windows/linux AppImages is enuf. I apologize for my out-of-loopness, this storm has done a number on some very expensive PA finals (and a bent antenna 🙀), and I've been going non-stop since I could get back on the roads. |
|
I will merge this so we got a starting base on which to come up with the Next Brilliant Idea on how to put some controls on all this automatic stuff in JS8Call turning the bands into chaos. |
I would stress the setting in the release notes.
|
Sorry about that guys. I thought I got the file names the same as the 2.5.1 release. That is why I didn't want to be the one to depress the "Publish" button! Ha! I'll post release announcements in several locations. 73, |
On groups.io it is claimed people are not getting their regularly scheduled SNR reports on time. JS8Call is primarily an automatic beaconing and signal reporting system, messaging is secondary. For weak-signal messaging it is probably advisable to switch to Olivia 8/250 with Reed Solomon ID anyway since it is faster and much more reliable than JS8, and doesn't rely on frame timing.
So this changes JS8Call to full Automatic Animal Mode so it will break MSG'ing with directed commands, which is what people want because they don't care about MSG'ing - uncontrolled automatic operation is the main MO. But it retains suppressing HB ACK for an incoming MSG.
And changes the description of the program to be more accurate.
I would suggest cherry-picking this to current release and push out a 2.5.2 patch release, since people are upset about not getting their (RSSR's) Regularly Scheduled Signal Reports.