APRS how to keep out of 144.390

[n1xtk]

I am not against using 144.39 but I am involved now with something I am trying to work out. I am a long time player on APRS but recently my fire department has asked me to set it up for our CERT team (many are hams) to set up for search and rescue so that we can track our people and the searches they are doing. All very doable. We will assume that they will be connected through Igates and the data is available on aprs-is or other webpages. What I need to be able to do is sort out them from all the other traffic in near realtime. By near I mean every 5 minutes or so would probably be adequate. My first assumption is that there would be an igate available so starting initially is going to be from the internet. First question, has anyone collected data from aprs-is.net? I am a long time programmer but haven't done a lot of api work. I have been able to get data from other API's but so far I haven't been able to figure out their method yet. Any help with that would be an enormous help. If I can make calls to that, I would be able to parse the data to separate out the people involved in our searches. Second, can the tocall category be used to specifically identify our people instead of having to sift through the callsigns?

Thanks in advance for any help.

73,
Keith
N1XTK

 

[eorange]

S&R with APRS? Oh my.

 

[rr60]

Start with the organizations lawyer and run that by them.

 

[n1xtk]

Start with the organizations lawyer and run that by them.

What? I was an active member on the FD for over a decade. I don't know what it is you think is a problem.

 

[exkalibur]

If you don't want their traffic being sent out on the wider APRS network, just use a different frequency. APRS is frequency agnostic. You could run it on 900MHz if you wanted to.

 

[n1xtk]

If you don't want their traffic being sent out on the wider APRS network, just use a different frequency. APRS is frequency agnostic. You could run it on 900MHz if you wanted to.

I understand. They specifically don't want it on the public service frequencies. They are looking to have backups for their PS radio traffic in case they loose comms so they have a fairly large commitment to Amateur radio communications and involvement of the CERT team. They recognize this as another opportunity for the CERT team to contribute.

Keith

 

[dickie757]

How will the members upload position packets?

Maybe an easy way to sort them from the rest....their symbol. All should have same, but different from typical traffic.

I dont see any operators in your area on aprs.fi. I see three gateways, all being Winlink. KB1AEV on 145.53 looks to be the goto, but will it give aprs-is some data?

You can also roll your own Pinpoint setup. Talk to the folks at KB1AEV to see if they can forward you the position info received from members.

 

[AK9R]

As previously stated, you can run APRS on any amateur radio frequency where the emission type is allowed by the rules and the originating station has operating privileges. I've run APRS on 144.990 MHz for an event in a city center where I wanted to be able to hear our packets directly, but didn't want our packets to be clobbered by a high-profile digipeater in the city.

The problem with moving off of 144.390 MHz is that whatever digipeaters and I-gates that you might want to take advantage of won't hear your APRS packets. If you are OK with that, then have at it.

Bob Bruninga WB4APR used to talk about an hiking/running event where the checkpoints were in valleys and the digipeaters in the area couldn't hear the APRS packets coming from the checkpoints. So, they set up temporary digipeaters on ridge tops that listened on 144.990 MHz and transmitted on 144.390 MHz. These temporary digis could hear the checkpoints and retransmit their packets (remember, AX.25 digipeating is store-and-forward) so that other digipeaters and I-gates could hear them. Conveniently, 144.990 and 144.390 are 600 kHz apart which is a transmit frequency shift that most 2m radios understand.

Or, if you want your packets to not be relayed to the APRS-IS by the I-gates, you can append either NOGATE or RFONLY in your path. For example, a path of "WIDE2-1,WIDE1-1,NOGATE" will be heard and acted on by local digipeaters, but won't be sent to the APRS-IS by any I-gates in the area.

 

[n1xtk]

How will the members upload position packets?

Maybe an easy way to sort them from the rest....their symbol. All should have same, but different from typical traffic.

I dont see any operators in your area on aprs.fi. I see three gateways, all being Winlink. KB1AEV on 145.53 looks to be the goto, but will it give aprs-is some data?

You can also roll your own Pinpoint setup. Talk to the folks at KB1AEV to see if they can forward you the position info received from members.

KB1AEV is a freind of mine. I will talk with him more about this. He also supports a couple of our groups and works on a lot of the repeaters in our area. I should of thought of him. Thanks for point it out.

Keith

 

[n1xtk]

As previously stated, you can run APRS on any amateur radio frequency where the emission type is allowed by the rules and the originating station has operating privileges. I've run APRS on 144.990 MHz for an event in a city center where I wanted to be able to hear our packets directly, but didn't want our packets to be clobbered by a high-profile digipeater in the city.

The problem with moving off of 144.390 MHz is that whatever digipeaters and I-gates that you might want to take advantage of won't hear your APRS packets. If you are OK with that, then have at it.

Bob Bruninga WB4APR used to talk about an hiking/running event where the checkpoints were in valleys and the digipeaters in the area couldn't hear the APRS packets coming from the checkpoints. So, they set up temporary digipeaters on ridge tops that listened on 144.990 MHz and transmitted on 144.390 MHz. These temporary digis could hear the checkpoints and retransmit their packets (remember, AX.25 digipeating is store-and-forward) so that other digipeaters and I-gates could hear them. Conveniently, 144.990 and 144.390 are 600 kHz apart which is a transmit frequency shift that most 2m radios understand.

Or, if you want your packets to not be relayed to the APRS-IS by the I-gates, you can append either NOGATE or RFONLY in your path. For example, a path of "WIDE2-1,WIDE1-1,NOGATE" will be heard and acted on by local digipeaters, but won't be sent to the APRS-IS by any I-gates in the area.

I saw another thread that you were involved with and re-read some of the information you posted. Thanks. I am old enough and remember using RELAY and WIDE in the old days. I now primarily use WIDE1-1 and WIDE2-1 for my radio setup on aprs. I have thought that we could setup a digi in an area if needed. Whether to use a TNC on another freq or cull the data from an igate will probably depend on the circumstances. Again, I appreciate your information.

73,
Keith

 

[jeepsandradios]

So we use APRS for SAR not as much as we would like but have used it for 20+ years. Currently all our radios are on the 144.390 frequency. We do one "event" in a national park and without other digi's and igates APRS would not work for the event. I guess our area is pretty remote so never run into problems with figuring out who is where. We use tac call signs so they jump out. Our command truck has a FTM400 in it that we can track on all incidents on top of our CAD system. Over the years we did try using other frequencies but coverage was always the issue. I even built a solar digi for one event and put it on top of the mountain. We had marginal coverage yet year prior on 39 had full coverage. So your area may dictate what is best to do. I have tried many options for putting the locations out to the web. Currently we use SARTopo and it will pull from aprs servers so 39 is the best route. I have built a small Igate for the command post so stuff local does make it to the web.

Lastly we only use APRS for situational awareness. Procedure and Policy helps with location of teams already. APRS is just a fallback to get some info. With todays tech of mapping apps that share location (SARAprs) and IV&D Location data over P25 its less important but definitely useful tool for areas where cell is not ideal. We currently have 2 Digi's in the state sponsored by the SAR Team to help with coverage for those in the hobby as well as SAR stuff.

 

[n1xtk]

So we use APRS for SAR not as much as we would like but have used it for 20+ years. Currently all our radios are on the 144.390 frequency. We do one "event" in a national park and without other digi's and igates APRS would not work for the event. I guess our area is pretty remote so never run into problems with figuring out who is where. We use tac call signs so they jump out. Our command truck has a FTM400 in it that we can track on all incidents on top of our CAD system. Over the years we did try using other frequencies but coverage was always the issue. I even built a solar digi for one event and put it on top of the mountain. We had marginal coverage yet year prior on 39 had full coverage. So your area may dictate what is best to do. I have tried many options for putting the locations out to the web. Currently we use SARTopo and it will pull from aprs servers so 39 is the best route. I have built a small Igate for the command post so stuff local does make it to the web.

Lastly we only use APRS for situational awareness. Procedure and Policy helps with location of teams already. APRS is just a fallback to get some info. With todays tech of mapping apps that share location (SARAprs) and IV&D Location data over P25 its less important but definitely useful tool for areas where cell is not ideal. We currently have 2 Digi's in the state sponsored by the SAR Team to help with coverage for those in the hobby as well as SAR stuff.

I appreciate all the information. I have been looking at SARTopo as a possibility for using on our SAR missions. Most of the areas that we will likely operate in should generally have good coverage. If we are deployed outside the area I expect that we might deploy a digi on a hilltop.

Thank you for your response. I will continue to look at SARTopo and will examine SARAprs.

73,
Keith
N1XTK

 

[jeepsandradios]

You will need a team account to share with SARTopo but they aren't that expensive considering the cost of APRS gear needed. And you can send a QR code to those not on your team to share tracking info as well. Dont get me wrong I'm not saying APRS is not suited just other tools in the toolbox. With SARTopo able to share APRS objects in the map via internet it allows a seamless transition to RF. We actually have a base map we use on deployments and anyone can go to it to see if the command bus is on the road or not as well as track certain members who use APRS. Much simpler to train on one system vs multiple.

 

[n1xtk]

You will need a team account to share with SARTopo but they aren't that expensive considering the cost of APRS gear needed. And you can send a QR code to those not on your team to share tracking info as well. Dont get me wrong I'm not saying APRS is not suited just other tools in the toolbox. With SARTopo able to share APRS objects in the map via internet it allows a seamless transition to RF. We actually have a base map we use on deployments and anyone can go to it to see if the command bus is on the road or not as well as track certain members who use APRS. Much simpler to train on one system vs multiple.

Agreed. Thanks. Yeah, I just checked, I downloaded SARTrack but I am pretty sure I also looked at SARTopo as far as I could without a license and will probably test it more after the department buys the license if they want. It certainly was cheap enough. It looks like it would be a good addition and very useful.

Thanks again,
73,
Keith
N1XTK

 

[jeepsandradios]

SARTrack is more APRS than mapping. Also no support for mobile phones. You can use SARTopo for free by registering for an account. Just cant save more than a certain amount of maps and such. I actually use it alot for work now. We tried APRSTrack and it was just another program we had to train folkso n and learn how to use. With SARTopo being used to build assignments and map the incident already the interface was perfect. Now the advantage of SARTrack is offline use where as SARTopo offers offline use at that point APRS does not feed to it. We know the limitation so thats not an issue when in that scenario. You can always run APRSIS with basic maps if you want to play around. I ran that at home for a while. It shows some basic maps, allows me to feed to the internet and would track local resources via RF if needed. Another option is APRSDroid on a tablet synched to a APRS mobile in the command post. We ran that for some time also with a BT adapter on the FTM400. That allowed same. Just ran out of space for monitors and stuff.

 

[n1xtk]

SARTrack is more APRS than mapping. Also no support for mobile phones. You can use SARTopo for free by registering for an account. Just cant save more than a certain amount of maps and such. I actually use it alot for work now. We tried APRSTrack and it was just another program we had to train folkso n and learn how to use. With SARTopo being used to build assignments and map the incident already the interface was perfect. Now the advantage of SARTrack is offline use where as SARTopo offers offline use at that point APRS does not feed to it. We know the limitation so thats not an issue when in that scenario. You can always run APRSIS with basic maps if you want to play around. I ran that at home for a while. It shows some basic maps, allows me to feed to the internet and would track local resources via RF if needed. Another option is APRSDroid on a tablet synched to a APRS mobile in the command post. We ran that for some time also with a BT adapter on the FTM400. That allowed same. Just ran out of space for monitors and stuff.

Excellent. Thank you very much for this. I will look closer at SARTopo. I have used APRSDroid to test a few times in the near past and that may be an option in some of the areas we would operate in.

Again, thanks for your responses.

73,
Keith
N1XTK

 

[serial14]

@n1xtk I saw you asked about the aprs-is API. I have found it to be a fairly easy service to interact with for read/RX only type use cases. I've never tried TX type things yet. Granted, that's not a helpful qualitative statement for you.

Take a look at Connecting to APRS-IS for information on how to connect. There are a couple key points.

1. TCP sockets are used. Not HTTP REST API
2. Several TCP ports are mentioned. I find 14580 to be the most useful
3. Its not clear, but the information coming across this TCP port is all ASCII text in "TNC2" format.

Server-side Filter Commands is also a helpful link. When your application "logs in" to APRS-IS you can specify a filter of what you want to receive. This will greatly help reduce how much information your APRS-IS connected application might need to process/display/etc

Finally, I don't know what programming language background you have( or other's reading this ). But I have found this python module to be helpful in recent times.

• aprslib
• GitHub - rossengeorgiev/aprs-python: 📡 Python module for working with APRS
• aprslib documentation — aprslib 0.6.42 documentation

Umm... as I was getting these links, I just noticed that arpslib includes capability for APRS-IS directly! I didn't know that. I am just using it as a parser. I have developed my own APRS-IS clients a couple times over the years for small things and have always found connecting to APRS-IS straightforward and the easy part. Its what you do with the information that gets fun/hard.

 

[n1xtk]

@n1xtk I saw you asked about the aprs-is API. I have found it to be a fairly easy service to interact with for read/RX only type use cases. I've never tried TX type things yet. Granted, that's not a helpful qualitative statement for you.

Take a look at Connecting to APRS-IS for information on how to connect. There are a couple key points.

1. TCP sockets are used. Not HTTP REST API
2. Several TCP ports are mentioned. I find 14580 to be the most useful
3. Its not clear, but the information coming across this TCP port is all ASCII text in "TNC2" format.

Server-side Filter Commands is also a helpful link. When your application "logs in" to APRS-IS you can specify a filter of what you want to receive. This will greatly help reduce how much information your APRS-IS connected application might need to process/display/etc

Finally, I don't know what programming language background you have( or other's reading this ). But I have found this python module to be helpful in recent times.

• aprslib
• GitHub - rossengeorgiev/aprs-python: 📡 Python module for working with APRS
• aprslib documentation — aprslib 0.6.42 documentation

Umm... as I was getting these links, I just noticed that arpslib includes capability for APRS-IS directly! I didn't know that. I am just using it as a parser. I have developed my own APRS-IS clients a couple times over the years for small things and have always found connecting to APRS-IS straightforward and the easy part. Its what you do with the information that gets fun/hard.

I have been looking at the api for APRS.IS. It looks like I don't need a password if I am just receiving. Technically you pass -1 as the password. I don't intent to transmit to the APRS-IS server. I have been looking at some of that information. I am currently looking at YAAC. I played a little with that. It is pretty good but still would prefer to get the information and parse it myself but it might be of use. I have programmed in machine code, assembler and then BASIC, Fortran and for over 30 years C/C++. I would hate to have to learn a new language at this point in my life but I might look at the source and possibly convert something. I do see some information on github. If aprslib can just pass through the data, that may be the solution I am looking for. I will look closer at that as well.

Thank you for your help also.

73,
Keith
N1XTK

 

[serial14]

I have been looking at the api for APRS.IS. It looks like I don't need a password if I am just receiving. Technically you pass -1 as the password. I don't intent to transmit to the APRS-IS server. I have been looking at some of that information. I am currently looking at YAAC. I played a little with that. It is pretty good but still would prefer to get the information and parse it myself but it might be of use. I have programmed in machine code, assembler and then BASIC, Fortran and for over 30 years C/C++. I would hate to have to learn a new language at this point in my life but I might look at the source and possibly convert something. I do see some information on github. If aprslib can just pass through the data, that may be the solution I am looking for. I will look closer at that as well.

Thank you for your help also.

73,
Keith
N1XTK

Python certainly isn't required for interacting with APRS-IS. I believe I've read that APRS-IS its self is written in java. In the past I've interacted with APRS-IS with Java and C/C++. This Python APRS-IS is just the latest thing I've come across and has worked well for a current project.

 

[KB3KBR]

I echo all that was said above and also add that stations do not need to have the callsign in the callsign field on RF. They can have a tactical name like SAR1, EMS5, etc as long as there is a callsign in the payload ie in the comment field, that satisfies the FCC ID requirement. That makes tracking and organizing a lot easier.
I would also suggest having a local radio on site connected to the mapping client. That way you are not 100% reliant on the internet.
Also take a look at shrieks, they can be filtered on APRSIS32 to be the only units on your screen.
You can also use 32's multitrack function to follow each individual station in a separate window.

Welcome to APRSISCE/32 - APRSISCE/32 The future of Amateur Radio APRS

APRSISCE/32 The future of Amateur Radio APRS, The most fully featured Windows APRS software available, Official support site For KJ4ERJ software

aprsisce.wikidot.com

View Menu - APRSISCE/32 The future of Amateur Radio APRS

APRSISCE/32 The future of Amateur Radio APRS, The most fully featured Windows APRS software available, Official support site For KJ4ERJ software

aprsisce.wikidot.com