Sorry for the off-topic post, but maybe someone here in can help me analyze the following problem.
I’m using APRS2SOTA for spotting for quite some time now and never had any problems. On my activation today all seemed to go nice and smooth until I realized that some of the (already sent and spotted) message packets appeared again in the APRS network at a later time, the delay was almost 60 minutes …
During my activation I was already beginning to wonder about these spots appearing again, but did not have the time to have a closer look at the problem.
So now I had a look at the raw data on APRS.fi and that’s what I found out:
Another “false” spot again almost 1 hour after I sent it out into the APRS network … at that time I was already on the way down from the summit.
So … what happened? I’n not quite sure yet, but every time the problem occured there was OK2VOP-1 and OE6XTR involved. Maybe @G0LGS@SOTAPRS can have a look and share his point of view …
Is OK2VOP-1 or OE6XTR causing the problem? It seems so to me …
Any other explaination?
I hope that on the next activation no “false” spots will appear!
despite I cannot contribute too much to the exact problem I want to share my experience:
I also know the problem of delayed packets. In former time some digipeater within the coverage of DB0RIE also repeated packets with a delay of hours. When driving around and sending position packets this looks like one is jumping back to a former position. Most of the delayed packets are ignored by aprs.fi and in the raw data colored in red with comments like “moving too fast”.
I am not absolutely sure whether OK2VOP-1 or OE6XTR causing the problem. But there is a good chance they do:
The good condx on 2m the last days also may have contributed to this. OE6XTR is in a very exposed location regularily picking up packets in distances of 400 km and more. I could imaging its TX buffer for packets runs full as it is waiting for a clear frequency to send them. So it could digipeat your message packet with the given delay of more than 50 minutes.
You propably know this effect from your TH-D72 sitting on a summit with a very crowded 144,8 MHz and waiting with the “STA” sign in the display until the TH-D72 can send the message packet. Here you have only a single packet - a digi receives many packets to digipeat.
In addition the Website of OE6XTR claims they are using a Kantronics KPC3. The aprx manual explicitly warns from using a Kantronics KPC3+ because of broken KISS. But it doesn’t warn about the Kantronics KPC3 but gives the KISS init string. Who knows?!
OK2VOP-1 also looks like a complicated setup: On HF it identifies as PE1MEW: DIGI_NED whereas at the APRS-Server it logs in as aprx. Two systems interconnected with real time clocks being offset by one hour because of daylight saving time switching?!
Perhaps dropping the sysops of the two digis a note can help to elucidate this problem.
Looks like I was teleported back up to the ridge.
And it is again OE6XTR
I checked on the phone while on the summit. There everything was fine. But now it looks like packets got delayed and submitted way to late with the wrong timestamp.
Michaels theory with 1 hour time delay is confirmed.
Martin did you get in contact with the responsible OP for OE6XTR ?
I find it interesting that the problem occures exactly every hour (12:24 / 13:24 / 14:24). That was also the case when I first noticed these problems 11 days ago, my beacons were “retransmitted” at 11:24 / 13:24 / 14:24. Again it’s OE6XTR and OK2VOP in the raw data … on my last two activations I did not have any problems with APRS and APRS2SOTA, so I thought it was a single event. That’s why I did not contact the SysOP of OE6XTR so far.
O.K. thanks for the info Joe … must be another problem then?!?
But anyway, looking at the raw data from OE6XTR it seems to me that that digipeater is not configured correct. Here is some of the raw data from OE6XTR:
So at OE6XTR the destination address is missing in the path. It’s a 6-digit code that looks like “APxxxx” or “TWxxxx”, the last 4 digits give a hint what hardware is used.
But I don’t think that this misconfiguration of OE6XTR might explain the problem that occured.
As the SysOP of OE6XTR is now aware of this thread, maybe he is reading this … here is some info about “Destination Addresses”: http://aprs.org/aprs11/tocalls.txt
PROBLEM(0): There is a random problem with KPC3 digis that at some
point hold up and then regurgitate LOTS of packets. Here is a possible
fix. Kantronics recommends shorting the RTS and CTS pins together
within my serial cable. (PINS 4/5 on DB25 and PINS 7/8 on DB9).
Shorting the RTS and CTS together prevents the software from holding
the RTS pin low. If the RTS pin is at low voltage the KPC3+ will
start buffering and does not get caught back up.
This applies to all 8.3 and 9.1 ROMS running on the KPC-3+(PLUS) TNC.
With one small change (noted below), it also applies to KPC-3+ TNC’s
running the last version of the 8.2 ROMS ending in “7265”. The
difference is noted below in section 4) and “6E”.
“the hold up and regurgitate” sounds like this effect?
Definitly not the same problem. It is not a resending of the message. Looking at the position data one can see that I was at the spot - but this digipeater adds an hour.
I have sent the information on the hold up issue to the sysop.
I only activated 2m today, stayed on the summit for about 45 minutes and started descend at 13:15 (12:15 UTC). Later at home I noticed that a second spot appeared on SOTAwatch at 13:24 (12:24 UTC). At that time I was on my way down from the summit, my Kenwood TH-D72 was turned off and in my rucksack. So I am 100% sure that I did not send out any unintended beacon/message. Again OK2VOP-1 was involved and again it was exactly 24 minutes past the hour.
So I guess I will have to ask the SysOP of OK2VOP-1 to have a look at his setup and check if his iGate is causing these “false spots” …
Maybe @G0LGS@APRS2SOTA has an idea how we can prevent these “false spots” from appearing in the future? Maybe checking if the reply ACK (in this case “ack2e5”) was heard before?
Hi everybody,
I’m the aprs sysop in Brno. There was a problem at VOP-1 site, after power outage, the linux system rebooted in a weird state. It uses direwolf1.5 as modem, then multi-KISS pipe to ax25 ports, then aprx as igate, and digi_ned for digipeating/periodic object transmission. It also has UHF RXonly, and does crossband digipeating from 432.5 → 144.8.
What i have seen is the pipe filled with some packets (about 70-80), then it held them for some random amount of time, approx 21-50 minutes, and then regurgitated them to the axports, causing them to be igated to aprs-is. I failed to notice this strange behaviour, as “some” packets were leaving VOP-1, so it looked like it was working normally. Usually when there is a problem, it just stops working (completely).
I’ve made some changes to the boot scripts, so fingers crossed, i don’t want that happening again.
Well, sorry for the chaos and thanks for informing me, please feel free to write me as soon as you see a problem. 73 de Martin OK5MP
thank you for registering to the SOTAreflector to tell everyone what caused the problem. It’s good to hear that you managed to solve it and your APRS setup is now running smoothly again.
