@Joe-K0OG as soon as this passes all the checks I'm going to merge it. Rebuild master and retest. Try your previous experiment, put the offending station callsign in the spot blacklist. It should fix it. There's always going to be a few of these, no mater what feature you try to run, including HB's and my my HB blacklist is long and distinguished to stop my station from replying to the offenders.

I don't know what's wrong with the linux runners today. Slower than molasses in January, and now it's February and it's really cold!

I don't know what's wrong with the linux runners today. Slower than molasses in January, and now it's February and it's really cold!

Man, for real. That's taking ages!

The Apple silicon Mac blows 'em all away. The x86_64 linux runner must be an old i386 Pentium.

Merged. Thanks Kelly!

The big European Beacon Offender shut down like flipping a switch. It works.

aprsisclient.js8: 26-02-01T20:18:38.573Z: APRSISClient Parsed Message: From: "IZ6RND" To: "IZ6RND" Msg: "T=20:17:59 A=29.7 B=0.97 C=0.94 RF=0 RP=0 RS=0 F=14.069750 TP=17 TD=22 TF=21 P1V=1.77 P2V=0.03 D1V=1.27 D2V=0.06 F1V=3.79 F2V=0.89 LST=2026-02-01@20:17Z NXT=2026-02-01@20:18Z" Id: ""
26-02-01T20:18:38.573Z: DEBUG: APRS Parsed Message "IZ6RND" "IZ6RND" "T=20:17:59 A=29.7 B=0.97 C=0.94 RF=0 RP=0 RS=0 F=14.069750 TP=17 TD=22 TF=21 P1V=1.77 P2V=0.03 D1V=1.27 D2V=0.06 F1V=3.79 F2V=0.89 LST=2026-02-01@20:17Z NXT=2026-02-01@20:18Z" Id: ""
26-02-01T20:18:38.573Z: DEBUG: APRS Message Received from "IZ6RND" to "IZ6RND" : "T=20:17:59 A=29.7 B=0.97 C=0.94 RF=0 RP=0 RS=0 F=14.069750 TP=17 TD=22 TF=21 P1V=1.77 P2V=0.03 D1V=1.27 D2V=0.06 F1V=3.79 F2V=0.89 LST=2026-02-01@20:17Z NXT=2026-02-01@20:18Z" id ""
26-02-01T20:18:38.573Z: DEBUG: Destination in spot blacklist: "IZ6RND"

So, now everyone has to start managing a blacklist to use a feature? Poor "solution" in my opinon. Best solution is to not cause the problem in the first place. I think I need to back away from this one completely, thank you.

73,
-Joe-
K0OG

Joe, how about getting rid of HB's first? I ran 40m all morning waiting to see a problem with the APRS and not a single issue, even without this patch, unless I manually entered IZ6RND into the list. However, the HB's continued to wreak havoc. I'm going back to 30 now where people have more common sense :-)

I will add that I have no problem with my station being an APRS inbound relay for stations in my "heard" list. It is a valid messaging protocol that is one of the most-requested features for JS8.

If I run into the occasional offender that abuses it, I have no problem putting that call into the blacklist. But I have a gut feeling the APRS blacklist will never reach the distinguished status of my HB blacklist!

For 2.6.0 I even changed how the UI is layed out under Networking & Autoreply so I can read my big HB blacklist! LOL!

This is mainly because I got code that I stick into new builds - cherry-pick it out of a branch. It stores callsigns that send HB's in a sqlite3 database table with a timestamp. If they send another one it queries the database and compares the timestamp of the last HB. If it's <60 minutes it automatically adds them to my HB blacklist. Works like a charm but I can just imagine the screaming, wailing and gnashing of teeth if I tried to PR that one!

It doesn't actually use the UI to do it. It just appends a comma and the offending callsign to the HBBlacklist= line in JS8Call.ini. But if you open the Preferences dialog it displays it in the UI.

One last comment, even though I think this whole thing is so wrong-headed...

If you are going to require users of this feature to maintain a blacklist, at least make it a separate blacklist from the others. It seems that an APRS feed "offender" (although it could totally be NOT his fault!) will not necessarily also be an HB "offender."

HB blacklist and the APRS blacklist are two different things. One is under Reporting, the other is under General->Networking & Autoreply.

I just relayed my first ever valid APRS incoming on 30m. It worked with no fanfare and nothing bad happened.

@punk-kaos the APRS incoming won't do anything unless the destination station is in the heard list. I normally expire my callsign list at 2 hrs just to keep track of who's on when I haven't been around for awhile. In the case of the one I just relayed, that station was only 15 minutes old. But what happens if the station is 2 hours old and no longer there?

@punk-kaos the APRS incoming won't do anything unless the destination station is in the heard list. I normally expire my callsign list at 2 hrs just to keep track of who's on when I haven't been around for awhile. In the case of the one I just relayed, that station was only 15 minutes old. But what happens if the station is 2 hours old and no longer there?

If it's in your heard list it's going to try. We can shorten that if we need to but I figured if we think it's been heard recently we would want to attempt.

Right. And then what happens if it fails because the station is no longer there?

Right. And then what happens if it fails because the station is no longer there?

Currently nothing. It won't attempt again. It'll only attempt once per APRS message.

That's what I figured. So it's not 100% reliable. For people like me that keep a long expire time on the callsign list, reliability probably (but not absolute) could be improved a little to have a better chance of actually finding somebody home. But I don't know what a good wait time would be to improve the delivery reliability.

That's what I figured. So it's not 100% reliable. For people like me that keep a long expire time on the callsign list, reliability probably (but not absolute) could be improved a little to have a better chance of actually finding somebody home. But I don't know what a good wait time would be to improve the delivery reliability.

Correct. I went pretty conservative to start out with because of Joe's concerns. There's also a 120s damper to rate limit messages per call sign. I could enable message acks potentially to confirm delivery but I don't really have a good plan on how we'd handle retries or confirmation.

Right. It seemed to work here without anything bad happening. And I think delivery uncertainty is kind of built-in anyway with APRS. I thought it was kinda cool to see it working and on a band like 40 where there's more chaos it would be less certain than 30 where the message came in today and the station just happened to be there. I MSG'd him to see if he got it and he ACK'd that, but I don't think he was around at the time.

So I'd say let's run this and test it. I'm pretty happy with it.

Right. It seemed to work here without anything bad happening. And I think delivery uncertainty is kind of built-in anyway with APRS. I thought it was kinda cool to see it working and on a band like 40 where there's more chaos it would be less certain than 30 where the message came in today and the station just happened to be there. I MSG'd him to see if he got it and he ACK'd that, but I don't think he was around at the time.

So I'd say let's run this and test it. I'm pretty happy with it.

Glad to hear it. It's been super solid in my tests so far. Been running it on the air about the last week.

HB blacklist and the APRS blacklist are two different things. One is under Reporting, the other is under General->Networking & Autoreply.

That is certainly not clear. What I see is "Never send spotting reports from these callsigns..." Above, I see the term "spotting" referring to PSKReporter, and spotting to APRS-IS. Does a callsign in that list also block those two? It seems it should NOT, but ONLY block "relayiing inbound APRS messages." If that is what it does, it should be worded so explicitly. If it blocks all the above, why? You don't need to answer me - I'm being rhetorical...

Here is an APRS feed feature request:

Add the ability to apply APRS-IS filters (like "r/37.96/-91.77/100" - in other words, 100km radius of my coordinates). This way I can limit the traffic feed and avoid the following problem: I am QRP, 3W. If another station is running 500W, so I can hear him at -20dB, there is no way I'll be able to feed an APRS reply to him, I might as well limit my replies to a what I consider a reasonable range. This is what I've been doing on 2m APRS for decades. At least, this will enable knowledgeable operators to more-intelligently control what their station is doing (beyond the blacklist). If we are going to get into the realm of bi-directional APRS, let's do it rightly.

I'm still very concerned with many stations feeding wide-bandwidth (fast) data onto this narrow-band (slow) mode; a directed messaging system (point-to-point) to an undirected (multi-point-to-all) messaging system, again in a slow mode. This has been a problem on APRS, but it was somewhat tolerable because of the relatively-fast baud rate, so the network would clear in just a few seconds. This could glut the passband with useless data for literally minutes (only ONE feed is needed by the receiving station).

Because of this, I think someone (NOT me) should write a cautionary instruction set on best practices when using the APRS feed to RF so as to carefully watch and control what is being transmitted. Maybe such an instruction set will help, but you know how it is: Most operators will install/turn on all "neat" features/set it to run unattended for hours. Expect the expected result.

73,
-Joe-
K0OG

Unfortunately, I can't get a APRS to come in today yet. Not even a weather bot one showed up. Maybe we can test this manually. Joe, if you sent a message to WA9CXN on 40 meters, he and I are on 30m right now, will it show up and cause my station to send him the message?

I've never used APRS before so learning more about this!

Unfortunately, I can't get a APRS to come in today yet. Not even a weather bot one showed up. Maybe we can test this manually. Joe, if you sent a message to WA9CXN on 40 meters, he and I are on 30m right now, will it show up and cause my station to send him the message?

I've never used APRS before so learning more about this!

Yes that should work.

I figured it would work. I don't know where that message I relayed yesterday came from for sure. But it sure was cool to see it work! So if somebody sends a message to Jerry WA9CXN, he's only like 10 miles from me, he should get it and I don't think there's anybody else on 30m running JS8Call 2.6.0 right now. So say something like "test msg for Jerry relayed APRS thru Chris" and I got a "controlled" environment where I can watch all this happen and get feedback from him on how it worked with the old v2.2.0 of the software.

I would imagine it should say something like @APRS MSG TO: like the one did yesterday.

If I send a JS8Call message to WA9CXN, nothing with APRS will happen. I would have to send him an APRS message somewhere on APRS-IS, which I could theoretically do on 2m, but I'm in a dead zone now. All the regional/local APRS digitpeaters and gateways have gone defunct. I suppose I could get on 40m APRS and send a message to him and hope someone gates it to his station through APRS-IS. I'll try that.

73,
-Joe-
K0OG

Yeah, let's try that. Try to do it totally by HF and see if it gets thru. I think KF7MIX or one of those guys usually has the APRS stuff running. So it might work.

Well, send two of 'em. Let's see if it works. I just sent him a JS8Call MSG and told him we might try this.

I just sent a message through 40m APRS/VARA, and verified that it went into the APRS-IS. It was a message to AC9KH, so maybe it will push through the system and spit out at WA9CXN station??? We'll see...

73,
-Joe-
K0OG

P.S. I'm back on 40m JS8Call now.

Sent one.

Kelly, it worked and he got it! That was even pretty fast. I'm impressed.

I guess I can't send a message from APRS to JS8Call? Should have been simple... I verified that it gated into the APRS-IS, destination call for the message was AC9KH. Oh well, only partial functionality it guess...

73,
-Joe-
K0OG

Kelly, it worked and he got it! That was even pretty fast. I'm impressed.

If he's running MASTER he should see it in his inbox too.

I guess I can't send a message from APRS to JS8Call? Should have been simple... I verified that it gated into the APRS-IS, destination call for the message was AC9KH. Oh well, only partial functionality it guess...

Oh, I see what I did wrong. AC9KH was the gateway, and the destination call should have been WA9CXN. I had them backwards...

73,
-Joe-
K0OG

I had to go fix a hydraulic hose on a track loader that wife was using to move some wood. But I never got one from you, Joe. The one I got to relay from Kelly looked just like the one yesterday. Jerry is still on 2.2.0 so it did not appear in his inbox. The formatting of the MSG is @APRSIS MSG which 2.2.0 does not recognize as a valid group MSG format.

It did appear in his incoming directed MSG pane, just not in the inbox. Depending on what other things he had come in he might have to scroll back to see it, and he's big into the HB thing so he's sending those out all day. 2.2.0 also does not recognize that there's an incoming MSG so it can fire up on HB ACK at any time, which would break it. But on 2.3.1 and later it would be delivered with much higher reliability even if the station is a HB ACK'er.

So the test was a success as it still did (kinda) work even being relayed to a 2.2.0 station.

@punk-kaos just so I understand how to use this better, how did you format your transmission to spot it onto the APRS-IS network? Do you use the CMD like it says in the documentation, or do you use the MSG TO:?

Ok, thanks. I just sent a test relay to Joe. Might not be enough JS8 stations running 2.6.0 so he gets it, but we'll see what happens.

Edit: I sent it on 80m and I got nationwide coverage on 80 tonite, including Canada and I even got one station from Spain that I QSO'd with a bit ago on 80. So somebody should be able to spot it into the APRS-IS network anyway.

If I'm understanding how this works, any JS8Call station clear back to 2.2.0 who has APRSIS spotting turned on can spot a APRS formatted MSG to the APRS-IS network, correct? So It doesn't necessarily depend on local digipeaters or gateways like 2m would, like Joe was mentioning. Any JS8 station that gets the APRS formatted MSG with that enabled will get it into the APRS-IS network.

At least that's that I think.

I've seen the inbound relay part work now and that was very effective. The one part I wonder about that is say several people that could hear WA9CXN were running the latest software with inbound relay enabled. Would Jerry get several relays, or the first one that grabs it gets it?

That is certainly not clear. What I see is "Never send spotting reports from these callsigns..." Above, I see the term "spotting" referring to PSKReporter, and spotting to APRS-IS. Does a callsign in that list also block those two? It seems it should NOT, but ONLY block "relayiing inbound APRS messages." If that is what it does, it should be worded so explicitly. If it blocks all the above, why? You don't need to answer me - I'm being rhetorical...

@Joe-K0OG yes, this was a patch to see if it works. It is effective for testing this out, but we'll either eventually change the wording that any station in that list is blocked from spotting to anything, or make a separate one for APRS inbound relay. I think the one block list is sufficient for the whole works, just need to change the wording a bit. That's minor for testing it and putting it thru the wringer. But I think the capability to block it is necessary in case somebody who gets the weather bot stuff (or something) would appear on HF JS8. Or in my case a APRS beacon from Italy, sending APRS beacons to himself. That didn't need to be blocked here. But if that dude suddenly showed up on JS8 sending APRS beacons every 2 minutes, and people on JS8 could hear him, he would get blocked. There's always going to be a few.

If I'm understanding how this works, any JS8Call station clear back to 2.2.0 who has APRSIS spotting turned on can spot a APRS formatted MSG to the APRS-IS network, correct? So It doesn't necessarily depend on local digipeaters or gateways like 2m would, like Joe was mentioning. Any JS8 station that gets the APRS formatted MSG with that enabled will get it into the APRS-IS network.

At least that's that I think.

I've seen the inbound relay part work now and that was very effective. The one part I wonder about that is say several people that could hear WA9CXN were running the latest software with inbound relay enabled. Would Jerry get several relays, or the first one that grabs it gets it?

Yes, any station back to at least 2.2.0 can spot outbound into APRS. So every station on JS8 that has the feature on essentially becomes an igate for APRS packets.

Its quite possible for the destination station to get several relays, though only the first will be added to the inbox. I'd love there to be a way to know which station was the first to get it but I've not thought of anything that really works. So yes, you may see multiple packets pushed onto JS8 when an inbound message comes in for a seen station.

My station relayed a yahoo email off APRS-IS this morning. It looked like it worked fine.

Technically, APRS inbound relay should be disabled when the station is unattended due to FCC regs that say the station can automatically transmit if being queried by another station that is attended. I don't think APRS relay qualifies for that since it comes off the internet.

My station relayed a yahoo email off APRS-IS this morning. It looked like it worked fine.

Technically, APRS inbound relay should be disabled when the station is unattended due to FCC regs that say the station can automatically transmit if being queried by another station that is attended. I don't think APRS relay qualifies for that since it comes off the internet.

Thats the first email relay I'm aware of. Very nice!

I suppose we could monitor idle time and disable after a bit, but is this any different than HBs for automated transmissions?

No, it is no different from the HB thing. I think I would put (maybe in parenthesis) after the checkbox description something like: "(WARNING: regulations prohibit enabling this unless the station is attended)" then we're covered if somebody turns it on and walks away. IMO, same thing should be done with the HB timer system - there maybe have a self-destruct warning that pops up and says the same thing every time a timer is enabled.

Thats not a terrible idea... Just a CYA warning.