APRS 2M vs 70cm?

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

AllDigital

Well-Known Member
TRF Supporter
Joined
Jun 14, 2013
Messages
652
Reaction score
927
Location
SoCal
I've used APRS a handful of times for high altitude balloons and have used the same BRB transmitter in a rocket a couple of times, but APRS is not my usual "go to" tracker solution unless I can use it through a digipeater/gateway and see the tracks on a map like APRS.fi.

We have a lot of teams that come out to FAR with APRS, but the entire area in the Mojave desert has been an APRS digipeater and gateway dead zone, so I installed an APRS internet gateway FAR. I assumed every commercial APRS solution was on the standard 144.39Mhz APRS frequency, since APRS is both a packet standard and a frequency standard. I've come to find out that some of the more popular flight computers are using APRS packets on 70cm and don't have the 144Mhz option-- so no internet tracking for them. Since there is not a 70cm frequency standard there is no way to set up an APRS gateway on 70cm. They are stuck using 70cm HTs to recieve packets.

In theory, we could set up a radio/repeater that had a programmable 70cm RX that would repeat or forward the packets to 144mhz, but that would require standing up more antenna infrastructure (on a 35' mast) to provide the same performance as the 144Mhz gateway. Another option would be to just change the gateway frequency for a specific team and reboot the gateway, but that is a PITA.

I know that some people want to use APRS "off frequency" so they don't flood the APRS network, but out in the desert there are almost zero packets flowing on 144Mhz, unless it is another rocket team.

So, two questions... 1) What are your favorite commercial APRS trackers that support the 144Mhz standard frequency and 2) any other creative solutions to provide a repeater or bridge for those teams that show up on custom frequencies?

Thanks,

Mike
 
Heresy, no doubt, but are a lot of people still using APRS for rockets? I guess the implication of your message is that they are.

I've never used it on anything but 70 cm and I don't use it any more anyway.
 
If you're only using an Internet Gateway, the receiver frequency can be anything you want. Use a private frequency in the 70cm band. The baseband packets from the TNC are the same format. Just feed them into the gateway.

Most people set up their GPS trackers at a higher rate than allowed on the public APRS network. You'll have to filter the packets to a lower rate before feeding them out to APRS.fi. There's a chance that your feed will be blocked if the rate is too high.

Another issue will be if/when multiple rockets are powered up and transmitting on the same frequency. The protocol will automatically interleave *if* the receivers can hear each other. The highest priority should be the rocket in flight, but it will likely collide with the other transmitters still on the pad due the distance in flight. So, the onboard locators should be powered down until it's their turn to launch.

<KF5JUD>
 
In practice everyone sets their BRBs on slightly different frequencies so they don't interfere. 433.92 is common, but not standard, and field reprogramming is not common.

Altus Metrum devices use one of 10 frequencies in 434.x but again user choice. And those may or may not transmit APRS; the Altus Metrum protocol is vastly better anyways.

2 examples, to show, you can't really guess. However, if you have a tuneable receiver, and the team tells you their frequency before they launch, why not tune in? Doesn't hurt. However, I would caution to not forward to the larger APRS world.
 
If you're only using an Internet Gateway, the receiver frequency can be anything you want. Use a private frequency in the 70cm band. The baseband packets from the TNC are the same format. Just feed them into the gateway.
Right, but the internet gateway is a Raspberry Pi using a software defined radio stick hard coded to 144Mhz. It can be reprogrammed to listen to another frequency and rebooted but then it isn’t available to anyone else and that is a pain.

Regarding the rate… most of the community concern about a high rate is for the frequency/channel use and not the internet side. I’ve run into the gateway at 5 second intervals with no issues (except a warning message on the rate). In theory, rockets should be fine with 10 second intervals.
 
However, I would caution to not forward to the larger APRS world.
We aren’t currently repeating the radio signal over the air, only the data to the internet, so it can be viewed online in a simple track. APRS.fi provides a very good interface for tracking a rocket on a map and analyzing packet data. With a 35’ antenna we can hear packets from 30+ miles away.

It wouldn’t be too hard to remotely configure the receiver for other 70cm frequencies, so maybe that is the easiest solution. The antenna is a dual band, so it will support both two meter and 70cm reception.
 
Right, but the internet gateway is a Raspberry Pi using a software defined radio stick hard coded to 144Mhz. It can be reprogrammed to listen to another frequency and rebooted but then it isn’t available to anyone else and that is a pain.

Regarding the rate… most of the community concern about a high rate is for the frequency/channel use and not the internet side. I’ve run into the gateway at 5 second intervals with no issues (except a warning message on the rate). In theory, rockets should be fine with 10 second intervals.
Most people transmit at 1 second intervals. Some use 5 packets per second. This is fine when using your own frequency, but not if you use a single frequency for all rocket activity onsite. Other than the collisions I mentioned, I believe APRS.fi will block your feed at those rates. If the gateway software is open source, it should be easy enough to filter the packets to a longer interval.

It's a software defined radio stick, it should be easy to change the receiver frequency.
 
If the gateway software is open source, it should be easy enough to filter the packets to a longer interval.

It's a software defined radio stick, it should be easy to change the receiver frequency.
That is a good idea. I like the idea of auto-filtering them down to something acceptable to the APRS information network. I’ll work on that.

Changing the frequency is not too hard, but only if I am onsite. The idea of having a permanent 24/7 APRS station at FAR is that it would relay any activity at any time including launches at Reaction Research next door on off weekends. I’ll need to come up with a SOP to change the receiver frequency that is easy.

In theory, the benefit of the station is student teams (with license) and regulars can buy cheap $125 boards and have a solid no frills 1 watt GPS tracking solution. But it would also be nice if it worked with all the 70cm boards too.
 
Heresy, no doubt, but are a lot of people still using APRS for rockets? I guess the implication of your message is that they are.

I've never used it on anything but 70 cm and I don't use it any more anyway.
I know of ONE person using APRS... there may be others, but I don't think it's very common. I bought a Byonics Micro APRS transmitter a couple of years ago, I have a Kenwood VG-74A too, but haven't played with it much either. They both look very fiddly.
 
Most people transmit at 1 second intervals. Some use 5 packets per second. This is fine when using your own frequency, but not if you use a single frequency for all rocket activity onsite. Other than the collisions I mentioned, I believe APRS.fi will block your feed at those rates. If the gateway software is open source, it should be easy enough to filter the packets to a longer interval.

It's a software defined radio stick, it should be easy to change the receiver frequency.
APRS is a distributed network, the operators get really cranky if you send data too often, because it generates excessive network traffic.. Once per minute is considered excessive... typical rates are once every 3 minutes or so, or even less for relatively slow-moving devices. It's not really designed for something that moves quickly.
 
I have just gotten back into rocketry and have been using @cerving ’s products mostly. I was considering adding an APRS as a “Hail Mary” backup (redundancy) if I had an issue with my main tracking. At that point, reporting interval is not really important. I’m just hoping to get a fix on the rocket that I’ve lost sight of. The interval could be every 10 or 15 minutes. I’m. not real interested in “realtime” tracking.

Just to be clear, I haven’t implemented this yet. But have been looking at the QRP labs transmitters for secondary tracking.

KQ4OCD
 
I have just gotten back into rocketry and have been using @cerving ’s products mostly. I was considering adding an APRS as a “Hail Mary” backup (redundancy) if I had an issue with my main tracking. At that point, reporting interval is not really important. I’m just hoping to get a fix on the rocket that I’ve lost sight of. The interval could be every 10 or 15 minutes. I’m. not real interested in “realtime” tracking.

Just to be clear, I haven’t implemented this yet. But have been looking at the QRP labs transmitters for secondary tracking.

KQ4OCD
I think APRS as a backup or in secondary places, like the booster on a two-stage rocket makes sense. BUT you need to be very careful and deliberate when putting two downlink transmitters on a rocket. I've seen dozens of teams show up with two trackers in an avBay and neither one can get GPS lock on the rail. The QRP Labs unit seems promising, but it has a very strong one watt transmitter, so it will smother any nearby GPS and could potentially scramble the primary altimeter. If flying two downlink radios I suggest one in the nose and one in the middle of the rocket, unless you can really get the antennas far away from each other and sensitive electronics.
 
As far as I know, the restrictions on beacon interval apply to the RF portion of the APRS system not the internet portion, ie aprs.fi. The restriction is in place because the APRS on air network has a low data rate of 1200 baud on 2M and too short of a beacon interval will flood the RF system.
I would recommend not using 144.390 and a short (less than 30 seconds) beacon interval since at 10,000 feet the rocket will be heard by other APRS digipeaters that might be a long distance away causing them problems.
Digipeaters are a store and forward system. When the digipeater receives a packet of data from your rocket tracker it stores it and then repeats (retransmits) it. The repeated signal is then repeated by other digipeaters up to a maximum number of repeats that is set in the software of your rocket tracker. So your tracker could interfer with other users some distance from you that you can't hear.
An internet gateway station is one that receives data packets over the air. They could be from a digipeater or from the rocket tracker directly. The gateway then sends the packets out on the internet. It doesn't repeat the data packets on the air so as to not cause further congestion.
If the goal is simply to get the data onto the internet and aprs.fi, you could use some other simplex channel on 2M or 70cm and your own internet gateway. That way your rocket data won't flood the APRS system with traffic and you will get to see your data on aprs.fi. I doubt that frquent beacon interval would cause aprs.fi any problems.
I recommend that you tell your users what frequency to use for your gateway station and maybe set up a second gateway on 70cm. That way there would be no need to reprogram the frequencies of your gateways.
 
I think we've all converged on the same recommendations (including the responses Mike got on the APRS groups.io board). A fixed private 70cm frequency and filtering in the iGate. No RF repeating unless you want to have a separate Tx on a different frequency.

The rate filtering might not be necessary when feeding into APRS.fi, but it makes sense to be considerate in case there are unexpected side effects. I like the idea of a lower rate for rockets on the ground vs the one(s) in the air. This would also work to keep track of people out on recovery who are carrying a locator on this same private APRS frequency at a low rate.

The APRS transmitter should be designed to listen and wait to transmit in a clear interval. But that only works if the "rockets on the pad" are sensitive enough to hear the "rocket(s) in the air". There's a good chance the rockets close to the iGate receiver won't hear the rocket at altitude and will collide with the important packets from the rocket in flight. Probably best to turn on the GPS locator on a rocket just before it's ready to launch (if practical).
 
I use Altus Metrum altimeters that support APRS on 70cm. In addition to carrying a HT with APRS tuned to 70cm (Yeasu FT3DR) I also cross band packets from 70cm to the standard 2m frequency using the dual band Kenwood TM-D710G in my Jeep. This works well as long as I can reach a digipeater on 2m from wherever the field is. Truthfully I don't depend on the cross banding but I do it because I can. It also allows other people to track the rocket if needed just using aprs.fi if needed/desired.
 
Last edited:
I use Altus Metrum altimeters that support APRS on 70cm. In addition to carrying a HT with APRS tuned to 70cm (Yeasu FT3DR) I also cross band packets from 70cm to the standard 2m frequency using the dual band Kenwood TM-D710G in my Jeep. This works well as long as I can reach a digipeater on 2m from wherever the field is. Truthfully I don't depend on the cross banding but I do it because I can. It also allows other people to track the rocket if needed just using aprs.fi if needed/desired.
I hope you don't spam the 144.390 APRS frequency with the typical 6 second updates that Altus Metrum sends!!!
 
I think we've all converged on the same recommendations (including the responses Mike got on the APRS groups.io board). A fixed private 70cm frequency and filtering in the iGate. No RF repeating unless you want to have a separate Tx on a different frequency.

The rate filtering might not be necessary when feeding into APRS.fi, but it makes sense to be considerate in case there are unexpected side effects. I like the idea of a lower rate for rockets on the ground vs the one(s) in the air. This would also work to keep track of people out on recovery who are carrying a locator on this same private APRS frequency at a low rate.
Yep, as John mentions, I got some feedback from the APRS community and emails back from a few APRS OG's that are still around. I've also done some experimenting with the iGateway code and a handful of APRS beacons. I've made two changes to the gateway software that should provide flexibility to fliers, but will also play nice with the APRS information network and radio frequencies. Here are the changes:

1. APRS internet gateway packet throttling based on altitude: It likely doesn't matter how fast packets go into the APRS internet gateway -- like it does over air, but to minimize the hit to the servers and the database I have created an automatic filter by callsign that will only allow an update every 30 seconds on the ground and every 10 seconds while in the air (above 500' AGL). Any packets for that callsign in-between will get dropped by the gateway and not forwarded on to the internet servers.

2. Configurable frequencies: My gateway uses a software defined radio, so any of the common frequencies in the 435Mhz and 900Mhz range can be configured, along with the standard 144 Mhz frequency. I've tested this with a couple of commercial altimeters, along with the filtering, and it works well. This means we can only have one rocket at a time flying APRS on a "custom frequency" while forwarding to the internet, but we don't have that many people flying APRS today so it shouldn't matter much. I am working on a simple web page on the same raspberry pi that will allow us to switch frequencies easily. If someone wants to update faster than 30 second intervals they will be asked not to use 144 Mhz out of public courtesy, since they might hit other digipeaters or gateways when up in the air and/or saturate the channel.

I played around with a TeleMega and I like how it broadcasts both custom telemetry and APRS on the same channel (or an offset). With the two additions above, a team could fly the telemega and everyone with a phone could monitor the position using APRS.fi and not just the person with the telemetry base. Since we've got a 35' antenna on the gateway it would also serve as a backup to the teams "ground station" setup. The gateway will also allow regulars to buy a $125 GPS tracking board and not worry about a base station.

If any clubs are interested in how this is set up I'd be happy to share.
 
Back
Top