Return ACKS to APRSIS to prevent excessive message spamming. Add 120 second mute to a message after receipt to prevent excessive retries.#162
Conversation
…second mute to a message after receipt to prevent excessive retries.
|
I'm happy to see these PR's NOT going into mainwindow.cpp anymore! Since I don't use APRS at all, @Joe-K0OG care to test this one to see how it works? |
Trying hard to avoild mainwindow.cpp after your big refactor! :) |
|
Well, there's still some minor stuff that can be pulled out of mainwindow.cpp. But I feel it's more manageable now and we would prefer mainwindow.cpp just put everything together for QMainWindow instead of running the back end right in it in one big monolithic mess. Plus it provides for better code documentation with doxy! :-) |
For sure, its starting to feel like it might be properly classed and modularized now! |
Building now - will test tonight & in the morning (assuming we don't lose power!). Concerning the weather, we are expected to get 7-12" snow starting tonight, with temperatures hanging in the single digits the next few days. It's 9 deg. F here now. We should be o.k. for power here since it will be all snow. The poor folks south of us in TX, AR, TN, and points East are in for a major ice storm, with likely widespread and long-lasting power outages. Sad... Pray for their well-being. 73, |
Yikes! Stay safe Joe! |
|
@Joe-K0OG don't bother moving snow until it quits blowing. We had total white-out here yesterday with 30mph wind out of the north. It was -41° here this morning and never got above -16 today, so we didn't even bother to get the track loaders of out of the shop because I got #2 diesel fuel in 'em from last fall yet. Supposed to get up to -10 tomorrow so we'll start the loaders up and move snow after lunch sometime. We got drifts in our driveway that are 12-15ft deep right now with about 100" on the ground for the season. But nobody prays for us because the people that live in the Southern U.S. Tropics think us northerners that live in the Lake Superior snow belt are nuts. But the upside to that is, when it's 105° in the shade in Texas it's a nice comfy 65° here :-) |
|
Still a disaster. I suggest that we take this out of MASTER, and @punk-kaos you work on this off-line, perhaps setting up two off-air stations to test. I think this needs a LOT more development before we consider this. It appears that this is getting caught in some kind of loop. Here is the result of this-morning's traffic. Imagine if several stations had this code running, massive waterfall glut! This was on Linux Mint 22.3, built with code from https://github.com/punk-kaos/JS8Call-improved.git, MASTER. 73, |
I've been having a bit of a time trying to reproduce this Joe, could you tell me which direction you're sending the SMS? Is it TO or FROM the JS8 station? |
I'm sending nothing. My station is simply automatically doing this. I just put it on-air, enable the APRS inbound relay check box, and wait for a station to send some APRS traffic (in this case, it is an SMS message that N0GES sent to the "system"). Again, I'm not typing or sending anything -- this is automatically happening, getting caught in some endless loop. Again, I suggest that we remove this from 2.6.0 master unless/until this gets fully fleshed out. If this gets out into the wild, it could be an absolute disaster, and possibly get us in very hot water with the APRSIS folks. 73, |
|
Ahh, got it. You were just the relay... Again, there's nothing here to annoy APRSIS, as nothing HAPPEND on the APRS side. This caused 0 new packets on the APRS network. These are just ACKs from the packets that N0GES sent. They're absolutely valid and correct packets. They acked packets and we relayed them... I took a look at the archived APRS packets on aprs.fi and surprisingly this actually would have been the perfect example for why I wrote this feature in the first place. N0GES sent an SMS message FROM JS8 and with this feature would have been able to receive the response. There's absolutely no loop at all here. Those ACKs are from separate messages, they're not a loop. The only issue there is that we're causing extra noise on the JS8 side because there's absolutely no reason to relay the ACK to N0GES's back into the network... I should be suppressing those as they're useless in our case. I'll add that to the patch. |
@punk-kaos Ahhh, excellent. If all those are suppressed, it might be fine. We'll see with some more testing when you have another version ready. Let me know. 73, |
|
Ok, @Joe-K0OG give this one a shot. I've tested it myself specifically with the SMS gateway and didn't see any unexpected packets on either side. |
|
@punk-kaos Well, I've had it running all day long, and there has been NO APRS traffic for it to be tested. On a normal day, I usually see a few SMS messages. Maybe people are burned out from WFD over the weekend??? So, I can neither confirm nor deny whether your fix works properly... Ha! ;) 73, |
Heh, I've been running into EXACTLY the same issue... I've tested myself on the air a few times without issues but that doesn't really prove anything does it?? :) I'd bet you're right, people recovering from WFD. Bands seem fairly empty today. |
|
@punk-kaos Well, I'm still not convinced... After monitoring all day long, just as I was getting ready to shut down for the day, this came in (again, I did not initiate anything, but this was fully automatic by my station): The format is not valid. To send a message from APRS-IS to N5OBC, it should be formatted as a MSG to N5OBC, thusly: The sending to @APRSIS is what a JS8Call station would send TO APRS-IS, not what APRS-IS would send TO a JS8Call station. Again, I think this needs a lot more development, and should be removed from 2.6.0 before we consider it. @Chris-AC9KH @rruchte @wmiler What do you guys think about this? Take this "Enable relaying inbound APRS" out of 2.6.0 so it doesn't get into the wild until it's fully developed? I'm afraid it could cause problems until it's fully developed. 73, |
|
I have purposely added another message type so that ALL APRS traffic happens through @APRSIS. This allows stations to filter the APRSIS group if they don't want to see the traffic at all. It also appears in their MSG queue from APRSIS with the DE attached to it so they don't think the message came from another JS8 station, but instead from an APRS station. This is again expected behavior and purposeful. That was all documented in the original APRSIS inbound pull request so it was more obvious what it was designed to do. |
|
@Joe-K0OG @punk-kaos how's the testing of this going? Joe, master is the place to test new features like this. It is not slated to become a release branch any time soon, and with the code available anybody who wants to build it can test it and suggest improvements. It is obvious it will generate more traffic for participating stations, but it can be turned off if you don't want to participate. While I don't personally use it, there's a lot of people who will and it is a requested feature. So if this code is functional and working as intended I'd just as soon merge it into master where more people can test it. Further enhancements can be applied later, if needed. If it's in master I might even turn it on and try it. |
|
I'll note that it's surprising how many people, especially on linux because we have the build scripts in the tools directory, are building and running 2.6.0. When I did a poll the other day with INFO? requests there was a couple people on MacOS that I found that are running 2.6.0. But there was several on linux and some of those guys are showing up here with suggestions. It should never be assumed that customers only download releases. There's a lot of people interested in running and testing the "cutting edge" stuff. |
|
@punk-kaos Don't forget to document your new code, and fix any glaring documentation issues you spot :) |
|
Just as an aside, and most likely has nothing to do with this code, I did attempt to move my digipeater to the same Linux box, and I got into an aprsis race condition. I will need to see what's going on with that. |
I built master and have been running since yesterday afternoon, with inbound APRS messages enabled, but have yet to encounter any APRSIS feeds to JS8Call to see how it is working. I have not set myself up to do SMS via APRS, and have very limited/spotty access to 2m APRS here locally, so am not in a good position to pass messages via APRSIS. I could set up my own feed into APRSIS (did all that many years ago), but seems like a lot of trouble to test this one feature. My impression was that I would see several APRS messages on JS8Call per day in previous months, but not so much, especially since WFD. I'll keep testing it... 73, |
Testing is going well, after fixing the ACK bug Joe found it seems to be working as designed so far. I've been running it on the air all week and haven't seen anything unexpected... I did watch someone check into APRSTHURSDAY from JS8 then realize he was getting back inbound messages. He sent several tests to watch the return results and seemed happy to note it was happening though he never did actually message me directly to ask what the heck my station was doing :P |
Yeah, let me know what you find. I'd bet trying to run a digipeater and JS8 on the same box is probably a pretty edge case, but if it does turn out to be a bug it should be pretty easy to fix. |
|
This is still WAY not ready for getting out in the wild. In fact, it is so "dangerous" I still urge us to remove it from main unless/until it is far better than it is now. I built from main, and have been running it the last day, but was getting zero APRS traffic to test its functionality, so I put out an appeal on-air for someone to do some APRS SMS to test it, and it's still the same mess as before. Did @punk-kaos your code improvements make it into main? Please check, because I see no difference from the way it acted before, continously sending repeated ACKs and other stuff from APRSIS to RF. If we get a few stations on-air feeding the same ACKs etc. from APRSIS to RF, it will absolutely GLUT the waterfall for who knows how long (minutes to hours???). Again, this is SERIOUSLY not ready to get out into the wild, and I'm even concerned about it being in main. From a little while ago - a DISASTER which I had to manually kill to stop it... Again, PLEASE take this out of main until we get something reasonably close to useable! 73, |
No, its not merged to main. You're back to seeing the issue from before... If we merge this pull request that'll go away. |
|
I see that there is an "inbound-apris-formatted" branch, but it hasn't been updated for a long time. |
|
O.k., I misunderstood - I thought it was already merged into main. @punk-kaos I'll build from your repo and try it again (if I can scare up some more SMS traffic). HOWEVER: There is still the issue... if 20 stations have APRS feed turned on, and someone send an APRS message (like these SMS tests), will there be 20 stations across the waterfall sending a couple of APRS ACKs, thus glutting the waterfall? If so, is there a way to prevent this? If not, I suggest that we not implement this feature as it will cause more problems than it's worth in my opinion. 73, |
|
Basically onl
We don't transmit the ACKs at all, so no. Thats one of the things this patch addresses. I realized we had a big issue with the ACKs themselves and there wasn't much of a reason to transmit them so they're suppressed. |
Ok ok, forget about ACKs then. What about ANY APRS-IS fed message. Will we have 20 stations all dumping the SAME APRS message onto the waterfall all at once, glutting everything? I'm really concerned about this getting us back into the waterfall glut problems we have been so sorely trying to fix lately. 73, |
|
Also, a philosophical point: Do we want to keep dumping features into JS8Call, especially ones like APRS functionality which are so nicely developed by other software, for HF and V/UHF use? The same is true of message handling in general, which is better addressed by tools like Fldigi. At some point, we need to stop with feature creep. 73, |
Well, there is some potential for it yes. If 20 stations all were able to see the destination station potentially they might all relay it out into JS8. This mirrors basically how JS8 to APRS works right now... I've been pondering how to deal with that and am noodling through maybe only sending the packet if we KNOW the other station can hear us instead of just if we have seen it recently since we do track which stations hear us. It would reduce the chances of flooding out to a well connected station. |
Probably something to consider for sure. I feel like at least on THIS feature we've already got HALF of it. Its always been kinda 1/2 done. Might as well finish it but I agree JS8 can't be all things for all hams! |
|
@punk-kaos I'm afraid the best you can do is something like this: Only reply to stations which have replied to my station (e.g., via HB, QSO, or an ACK) in the last 15 minutes. That may (not necessarily will) limit the number of simultaneous APRS message feeds to RF, but will almost certainly (in normal band conditions, say on 40m) still result in 5, 10, 20, or more simultaneous transmissions to the destination station. The more I think about this, the more I'm opposed to implementing it with JS8Call. Let's encourage stations to use other tools to do bi-directional APRS messaging. I don't think this is appropriate for a tool like JS8Call. I would be interested to hear what the other developers think of this, but I'm SERIOUSLY concerned that it will land us too far afield of what JS8Call should be doing within itself, and get us back into a waterfall-glut problem. I'm sorry to rain on your parade -- what you are doing is a "neat" idea, but don't think it is a good fit here. 73, |
Yeah, thats more or less what I was thinking of. The app knows who has heard us. If we hear them and they hear us then relay. But you're not wrong that it does have some potential for small packet floods. Thats fair, and I get your point. I have tried a LOT of ways to reliably send APRS messages via HF in compromised transmission situations and have yet to find anything that can get a message out as effectively as JS8 does. I know others feel the same judging by all the videos and tutorials on how to send APRS messages with JS8 as well as the outside tools to make that easier. This was even one of the very first things requested as a feature when we asked our userbase. I just don't personally believe that there IS another tool that works well for this right now. I respect your opinion on this, but I'm afraid I disagree somewhat :) But I'm absolutely open to what everyone else thinks. I recognize I'm new to the project and maybe my thoughts on this aren't the team's goal. |
|
@punk-kaos To somewhat mimic how things work on packet networks, you have a sort of client/server situation. Someone who has set up a sort of JS8Call BBS (e.g., Joe, KF7MIX, https://kf7mix.com/js8spotter.html) could include an APRS-IS interface module in his system. That module would accumulate (I don't know how...) and hold (maybe for 24 hours) messages directed to JS8Call stations who have sent a message to APRS-IS via JS8Call. If you know that the KF7MIX BBS (JS8Spotter) is on-air and you can reach it, you could query his BBS for any APRS messages waiting for you, then pick them up. This maintains a station-to-station client/server communication, and won't spam the waterfall with duplicate messages. So, if you send an APRS message to someone, and want to see if they have replied, you just go pick it up from the BBS, point-to-point. Simple to use, maybe not so simple to implement? However, I suspect that you and others will find it fairly easy to script/program, even with something like Python. What do you think about that? Keep it out of JS8Call (thus keeping it simple), and use the API for what it was intended. 73, |
|
@Joe-K0OG personally, since it can be turned off if you don't want to use it, I don't see a problem with it. Kinda like HB's and ACK's. I turn that off because it's a design fracas and yet some people think it's great. As far as that goes, HB's and ACK's scattered all over tarnation are a bigger design issue than APRS messaging. I'd say if this is functional, merge it to master and let more testing proceed. It is a requested feature that people want to see in JS8Call since it was only ever half-implemented, and it is a messaging protocol, not something totally useless like HB's which is nothing but an automated beaconing system that can be replaced by WSPR. We won't really know how it works until more people try it. If necessary, we can make APRS ACK's all take place in the HB subchannel if we want. Or create a new APRS subchannel at 2500Hz. I would say since it is one of the most requested features we have to at least try it. |
|
Let me know if I need to do any hookups in the API since that's what I'm slogging thru now. I'm ok with sticking aprs acks down in the HB zone, and frankly would prefer it there. |
It could be done similar to the way MSG is handled. |
|
Sorry guys - I disagree and think this is a "feature creep" situation, and can better be done external to JS8Call, say through a BBS as I detailed. The more we cram into the application and waterfall, the more we will have interferences to the basic purpose and function of JS8Call. 73, |
|
I'll merge this so we can all test it some more with the aprs acks suppressed. It's been over a year since I've even seen a aprs message on JS8Call on the bands I hang out on. And there's absolutely zero acknowledgement that it ever got received. |
|
Built the latest merge and testing. Here is a possible nightmare situation: A station is active on 2m APRS. He has a system set up that frequently requests reports from WXBOT, or just a lot of 2m traffic. I use WXBOT as an example as this is what I'm observing right now happening. That same station happens to come up on 40m using the exact same callsign (no call modifiers) as what he is using on 2m (with no call modifiers there either). Suddenly, everyone on 40m who has the incoming APRS enabled will start dumping all of that guy's traffic onto 40m. Again, this is exactly what i'm observing on 40m RIGHT NOW. Hack away at it some more if you want to try to clean this up, but I'm not convinced that this will turn out good... 73, |
|
So everybody on 40 is running JS8Call master? All I see there is a bunch of HB chaos and KN4AM sending something out to |
|
My station was dumping a steady stream of messages - I pulled the output slider all the way down so that no significant RF went out on-air. This was due to a station being on 2m and 40m at the same time with the same callsign (no call modifiers). I was the one running the latest master, not someone else. It was 2m traffic dumping through my "gateway" onto 40m JS8Call. Philosophically, here is the problem: A wide-bandwidth gateway (potentially MANY gateways) is being opened onto a very narrow-band mode. Bad form... 73, |
|
I'll clarify a little further: No APRS traffic was being initiated on JS8Call, 40m, by that other station. My station simply saw his callsign on-air on 40m, then the (flood)gateway opened! All his 2m traffic deliverable to him from APRS-IS was dumped through my gateway onto 40m, non-stop. You can simulate (accurately) this situation the following way:
Now watch the traffic dump through your JS8Call onto HF.... 73, |
|
So I picked a beacon station from Italy (yes, I'm running the new Message Inbox UI enhancement by Rob also). 
There should be a APRS blacklist like there is for HB offenders. But the spotting blacklist only applies to PSK Reporter. @punk-kaos how hard is it to make that spotting blacklist also apply to the APRS client? There's not going to be too many people who do this. But when they appear, and they will just like the 15 minute automatic unattended HB offenders, they need to be blocked. 
|
|
Should be pretty simple. I'll get that rolled up.
…On Sun, Feb 1, 2026, 8:10 AM Chris Olson ***@***.***> wrote:
*Chris-AC9KH* left a comment (JS8Call-improved/JS8Call-improved#162)
<#162 (comment)>
So I picked a beacon station from Italy (yes, I'm running the new Message
Inbox UI enhancement by Rob also).
Screenshot.2026-02-01.at.10.01.27.png (view on web)
<https://github.com/user-attachments/assets/43fd93b8-5aee-4acd-8aa1-ef6e0be6fd7f>
There should be a APRS blacklist like there is for HB offenders. But the
spotting blacklist only applies to PSK Reporter. @punk-kaos
<https://github.com/punk-kaos> how hard is it to make that spotting
blacklist also apply to the APRS client? There's not going to be too many
people who do this. But when they appear, and they will just like the 15
minute automatic unattended HB offenders, they need to be blocked.
Screenshot.2026-02-01.at.10.05.05.png (view on web)
<https://github.com/user-attachments/assets/c2082e8e-9980-40fe-9f1f-937bdf03a458>
—
Reply to this email directly, view it on GitHub
<#162 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACKWQT3DNRG7PIM52GKPTL4JYQPPAVCNFSM6AAAAACSXHGFI2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQMZRGMYDOMJSGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I figured it won't be too hard. It has to check if the callsign is in the heard list anyway, just add another qualifier to ignore it if they're in the blacklist. There are going to be a few offenders that need to be blocked just like HB offenders. |
New pull-request in for this feature. Quick and surgical. |
This should resolve the cases Joe reported where the APRS SMS gateway seems happy to ACK us for tons of retries causing excessive packet load on the JS8 mesh side.