Redundancy on APRS


Zack Clobes W0ZC
 

I always fly at least 2 APRS beacons, and I have always followed the conventional wisdom to start at -11. So I'll have -11, -12, and potentially -13 if I'm testing something or just want added insurance.

But this weekend while I've been prepping for a flight, I wondered if there's any value by just putting -11 on all of my trackers, thereby letting APRS.fi, and other tracking systems just think there's a single balloon up there. 

I would put something into the comment string so that I could tell the two transmitters apart if I needed to debug some behavior later on.

Is anyone else doing this, or does anyone else have any pro/cons?

Zack


Michael Hojnowski
 

Zack,

If you're using APRS Telemetry, it won't work.  The telemetry packets have a sequence number.  If a duplicate sequence number comes in, it'll generate "duplicate" messages and may or may not be ignored.  If you're NOT using telemetry, I think it'll work.

I fly mine on separate callsigns so that if a tracker has issues, I have a good idea of which one it is.  I build my own trackers, and sometimes I get a wonky one that's fine on the ground  but bad in the cold.  I suppose, also, if one tracker has a GPS failure, you might start getting alternating trackers with 0/0 lat/long or some such.   Though it's confusing for novices who see multiple balloons for one flight, I think I prefer unique callsigns.

Mike / KD2EAT

On 4/25/2021 2:03 PM, Zack Clobes W0ZC wrote:
I always fly at least 2 APRS beacons, and I have always followed the conventional wisdom to start at -11. So I'll have -11, -12, and potentially -13 if I'm testing something or just want added insurance.

But this weekend while I've been prepping for a flight, I wondered if there's any value by just putting -11 on all of my trackers, thereby letting APRS.fi, and other tracking systems just think there's a single balloon up there. 

I would put something into the comment string so that I could tell the two transmitters apart if I needed to debug some behavior later on.

Is anyone else doing this, or does anyone else have any pro/cons?

Zack


Andrew Koenig
 

If for some reason you forget to send the high altitude unlock commands to your uBlox GPS (ask me how I know this..), the tracker with the non-functional GPS will likely screw up the track from the other trackers. uBlox GPS units will still give NMEA strings, they just won't be anything close to accurate. 

The same logic could be applied to losing GPS fix on a tracker as well. 

Personally I'd keep them separate, but if you do run them on the same SSID I'd really like to hear how it goes. 

73 de KE5GDB

On Sun, Apr 25, 2021, 1:03 PM Zack Clobes W0ZC <zclobes@...> wrote:
I always fly at least 2 APRS beacons, and I have always followed the conventional wisdom to start at -11. So I'll have -11, -12, and potentially -13 if I'm testing something or just want added insurance.

But this weekend while I've been prepping for a flight, I wondered if there's any value by just putting -11 on all of my trackers, thereby letting APRS.fi, and other tracking systems just think there's a single balloon up there. 

I would put something into the comment string so that I could tell the two transmitters apart if I needed to debug some behavior later on.

Is anyone else doing this, or does anyone else have any pro/cons?

Zack


Martin Rothfield W6MRR
 

I've had just one APRS failure.  The antenna broke off due to lack of strain relief but luckily the payload was found and returned.

I've had more problems finding the payload on the ground.  I recently went with a secondary LoRa beacon that is cheap and light.  Once on the ground the LoRa works really well and penetrates some foliage.  Because it's low power, just a small LiPo will keep it running for days.  It also works well at altitude with just a 3/4" wire monopole for the antenna.

  73 Martin W6MRR

On Sun, Apr 25, 2021 at 6:30 PM Andrew Koenig <ke5gdb@...> wrote:
If for some reason you forget to send the high altitude unlock commands to your uBlox GPS (ask me how I know this..), the tracker with the non-functional GPS will likely screw up the track from the other trackers. uBlox GPS units will still give NMEA strings, they just won't be anything close to accurate. 

The same logic could be applied to losing GPS fix on a tracker as well. 

Personally I'd keep them separate, but if you do run them on the same SSID I'd really like to hear how it goes. 

73 de KE5GDB

On Sun, Apr 25, 2021, 1:03 PM Zack Clobes W0ZC <zclobes@...> wrote:
I always fly at least 2 APRS beacons, and I have always followed the conventional wisdom to start at -11. So I'll have -11, -12, and potentially -13 if I'm testing something or just want added insurance.

But this weekend while I've been prepping for a flight, I wondered if there's any value by just putting -11 on all of my trackers, thereby letting APRS.fi, and other tracking systems just think there's a single balloon up there. 

I would put something into the comment string so that I could tell the two transmitters apart if I needed to debug some behavior later on.

Is anyone else doing this, or does anyone else have any pro/cons?

Zack


James Ewen VE6SRV
 

We have flown out BEAR payloads and others with dual trackers using the same callsign. Use time slotting to keep them apart. You can set one to transmit at the top of the minute and the other at the bottom of the minute. It looks like a single tracker beaconing every 30 seconds. A short comment will let you know which is which in the raw packets if you aren’t looking at timestamps. 

You can get some issues if the GPS positions get out of sync. This can end up looking like a zig-zag stitch was used on a sewing machine to lay down your track if they get a bit out of sync. If you allow the tracker to send a position even with no GPS lock, then you can get longer and longer zigs back to the last known zag. Once they become far enough apart, aprs.fi will try to “help” by filtering out the bad positions, which might just end up being the good positions. It’s always best to listen directly to RF, and not rely on filtered feeds and sites that “help”. 

Don’t get me wrong, I use aprs.fi for chasing, and as long as things are perfect, it works well. But if things go haywire, direct RF is where you want to be. Straight from the horse’s mouth as it were. 

Obviously one would never use any hops at altitude as that is a serious waste of resources, and with what appears to be rapid beaconing from a single tracker, you might get people’s panties in a twist. 

Direct beaconing with no hops from 1000 feet or higher will always do better than a terrestrial hop unless you have huge alligator style mountaintop digipeaters in your area. 

The chances of your payload flying with no tracking at all until it is sitting on the ground,
and is in a spot that just happens to be able to get the attention of a digipeater, and that landing location beacon is the only position packet you have to use for recovery is slim to none. 

If you just HAVE TO HAVE hops in your outgoing path, please do so with an altitude aware tracker that can run no hops at altitude. There’s enough noise and collisions on the ground, we don’t need to be adding to the problems for hundreds of miles in all directions from “near space”. 

And yes, if you are sending telemetry from both units, the sequence numbers may confuse the systems trying to plot the sequence. 

James
VE6SRV 
--
James
VE6SRV


Larry
 

I use a big red bee and I don't know about controlling hops.   I see the complaint message about transmitting too often (every 62 seconds) from high altitude but just ignore it.   Should I be doing something different?  I was using a SPOT as the backup but I got too cheap to continue the subscription.   I bought a LYNQME last year and it guided me right to where it was sitting. 

Larry 
KJ6PBS


On Sun, Apr 25, 2021, 7:12 PM James Ewen VE6SRV <ve6srv@...> wrote:
We have flown out BEAR payloads and others with dual trackers using the same callsign. Use time slotting to keep them apart. You can set one to transmit at the top of the minute and the other at the bottom of the minute. It looks like a single tracker beaconing every 30 seconds. A short comment will let you know which is which in the raw packets if you aren’t looking at timestamps. 

You can get some issues if the GPS positions get out of sync. This can end up looking like a zig-zag stitch was used on a sewing machine to lay down your track if they get a bit out of sync. If you allow the tracker to send a position even with no GPS lock, then you can get longer and longer zigs back to the last known zag. Once they become far enough apart, aprs.fi will try to “help” by filtering out the bad positions, which might just end up being the good positions. It’s always best to listen directly to RF, and not rely on filtered feeds and sites that “help”. 

Don’t get me wrong, I use aprs.fi for chasing, and as long as things are perfect, it works well. But if things go haywire, direct RF is where you want to be. Straight from the horse’s mouth as it were. 

Obviously one would never use any hops at altitude as that is a serious waste of resources, and with what appears to be rapid beaconing from a single tracker, you might get people’s panties in a twist. 

Direct beaconing with no hops from 1000 feet or higher will always do better than a terrestrial hop unless you have huge alligator style mountaintop digipeaters in your area. 

The chances of your payload flying with no tracking at all until it is sitting on the ground,
and is in a spot that just happens to be able to get the attention of a digipeater, and that landing location beacon is the only position packet you have to use for recovery is slim to none. 

If you just HAVE TO HAVE hops in your outgoing path, please do so with an altitude aware tracker that can run no hops at altitude. There’s enough noise and collisions on the ground, we don’t need to be adding to the problems for hundreds of miles in all directions from “near space”. 

And yes, if you are sending telemetry from both units, the sequence numbers may confuse the systems trying to plot the sequence. 

James
VE6SRV 
--
James
VE6SRV


greg@bigredbee.com
 

Larry,

On the BRB, you can use the config software to set the path to whatever you want.  There's also a way to switch the path settings based on the altitude in the 'profile switching' section.

Greg K7RKT


On Mon, Apr 26, 2021 at 10:38 AM Larry <larry.phegley@...> wrote:
I use a big red bee and I don't know about controlling hops.   I see the complaint message about transmitting too often (every 62 seconds) from high altitude but just ignore it.   Should I be doing something different?  I was using a SPOT as the backup but I got too cheap to continue the subscription.   I bought a LYNQME last year and it guided me right to where it was sitting. 

Larry 
KJ6PBS


On Sun, Apr 25, 2021, 7:12 PM James Ewen VE6SRV <ve6srv@...> wrote:
We have flown out BEAR payloads and others with dual trackers using the same callsign. Use time slotting to keep them apart. You can set one to transmit at the top of the minute and the other at the bottom of the minute. It looks like a single tracker beaconing every 30 seconds. A short comment will let you know which is which in the raw packets if you aren’t looking at timestamps. 

You can get some issues if the GPS positions get out of sync. This can end up looking like a zig-zag stitch was used on a sewing machine to lay down your track if they get a bit out of sync. If you allow the tracker to send a position even with no GPS lock, then you can get longer and longer zigs back to the last known zag. Once they become far enough apart, aprs.fi will try to “help” by filtering out the bad positions, which might just end up being the good positions. It’s always best to listen directly to RF, and not rely on filtered feeds and sites that “help”. 

Don’t get me wrong, I use aprs.fi for chasing, and as long as things are perfect, it works well. But if things go haywire, direct RF is where you want to be. Straight from the horse’s mouth as it were. 

Obviously one would never use any hops at altitude as that is a serious waste of resources, and with what appears to be rapid beaconing from a single tracker, you might get people’s panties in a twist. 

Direct beaconing with no hops from 1000 feet or higher will always do better than a terrestrial hop unless you have huge alligator style mountaintop digipeaters in your area. 

The chances of your payload flying with no tracking at all until it is sitting on the ground,
and is in a spot that just happens to be able to get the attention of a digipeater, and that landing location beacon is the only position packet you have to use for recovery is slim to none. 

If you just HAVE TO HAVE hops in your outgoing path, please do so with an altitude aware tracker that can run no hops at altitude. There’s enough noise and collisions on the ground, we don’t need to be adding to the problems for hundreds of miles in all directions from “near space”. 

And yes, if you are sending telemetry from both units, the sequence numbers may confuse the systems trying to plot the sequence. 

James
VE6SRV 
--
James
VE6SRV


Christopher Rose
 

Cut TX rate a little. Try 90 seconds and see what APRS.FI says. I forgot if Bob Bruninga reccomended some beacon schedule. Been a while since I used APRS mobile equipment.



Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: Larry <larry.phegley@...>
Date: 4/26/21 1:38 PM (GMT-05:00)
To: GPSL@groups.io
Subject: Re: [GPSL] Redundancy on APRS

I use a big red bee and I don't know about controlling hops.   I see the complaint message about transmitting too often (every 62 seconds) from high altitude but just ignore it.   Should I be doing something different?  I was using a SPOT as the backup but I got too cheap to continue the subscription.   I bought a LYNQME last year and it guided me right to where it was sitting. 

Larry 
KJ6PBS


On Sun, Apr 25, 2021, 7:12 PM James Ewen VE6SRV <ve6srv@...> wrote:
We have flown out BEAR payloads and others with dual trackers using the same callsign. Use time slotting to keep them apart. You can set one to transmit at the top of the minute and the other at the bottom of the minute. It looks like a single tracker beaconing every 30 seconds. A short comment will let you know which is which in the raw packets if you aren’t looking at timestamps. 

You can get some issues if the GPS positions get out of sync. This can end up looking like a zig-zag stitch was used on a sewing machine to lay down your track if they get a bit out of sync. If you allow the tracker to send a position even with no GPS lock, then you can get longer and longer zigs back to the last known zag. Once they become far enough apart, aprs.fi will try to “help” by filtering out the bad positions, which might just end up being the good positions. It’s always best to listen directly to RF, and not rely on filtered feeds and sites that “help”. 

Don’t get me wrong, I use aprs.fi for chasing, and as long as things are perfect, it works well. But if things go haywire, direct RF is where you want to be. Straight from the horse’s mouth as it were. 

Obviously one would never use any hops at altitude as that is a serious waste of resources, and with what appears to be rapid beaconing from a single tracker, you might get people’s panties in a twist. 

Direct beaconing with no hops from 1000 feet or higher will always do better than a terrestrial hop unless you have huge alligator style mountaintop digipeaters in your area. 

The chances of your payload flying with no tracking at all until it is sitting on the ground,
and is in a spot that just happens to be able to get the attention of a digipeater, and that landing location beacon is the only position packet you have to use for recovery is slim to none. 

If you just HAVE TO HAVE hops in your outgoing path, please do so with an altitude aware tracker that can run no hops at altitude. There’s enough noise and collisions on the ground, we don’t need to be adding to the problems for hundreds of miles in all directions from “near space”. 

And yes, if you are sending telemetry from both units, the sequence numbers may confuse the systems trying to plot the sequence. 

James
VE6SRV 
--
James
VE6SRV


Christopher Rose
 

Hops are how many digis you hit and ultimately may interfere with.  If yoo many are repeating your packets and really don't need to be that is unnecessary.



Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: Larry <larry.phegley@...>
Date: 4/26/21 1:38 PM (GMT-05:00)
To: GPSL@groups.io
Subject: Re: [GPSL] Redundancy on APRS

I use a big red bee and I don't know about controlling hops.   I see the complaint message about transmitting too often (every 62 seconds) from high altitude but just ignore it.   Should I be doing something different?  I was using a SPOT as the backup but I got too cheap to continue the subscription.   I bought a LYNQME last year and it guided me right to where it was sitting. 

Larry 
KJ6PBS


On Sun, Apr 25, 2021, 7:12 PM James Ewen VE6SRV <ve6srv@...> wrote:
We have flown out BEAR payloads and others with dual trackers using the same callsign. Use time slotting to keep them apart. You can set one to transmit at the top of the minute and the other at the bottom of the minute. It looks like a single tracker beaconing every 30 seconds. A short comment will let you know which is which in the raw packets if you aren’t looking at timestamps. 

You can get some issues if the GPS positions get out of sync. This can end up looking like a zig-zag stitch was used on a sewing machine to lay down your track if they get a bit out of sync. If you allow the tracker to send a position even with no GPS lock, then you can get longer and longer zigs back to the last known zag. Once they become far enough apart, aprs.fi will try to “help” by filtering out the bad positions, which might just end up being the good positions. It’s always best to listen directly to RF, and not rely on filtered feeds and sites that “help”. 

Don’t get me wrong, I use aprs.fi for chasing, and as long as things are perfect, it works well. But if things go haywire, direct RF is where you want to be. Straight from the horse’s mouth as it were. 

Obviously one would never use any hops at altitude as that is a serious waste of resources, and with what appears to be rapid beaconing from a single tracker, you might get people’s panties in a twist. 

Direct beaconing with no hops from 1000 feet or higher will always do better than a terrestrial hop unless you have huge alligator style mountaintop digipeaters in your area. 

The chances of your payload flying with no tracking at all until it is sitting on the ground,
and is in a spot that just happens to be able to get the attention of a digipeater, and that landing location beacon is the only position packet you have to use for recovery is slim to none. 

If you just HAVE TO HAVE hops in your outgoing path, please do so with an altitude aware tracker that can run no hops at altitude. There’s enough noise and collisions on the ground, we don’t need to be adding to the problems for hundreds of miles in all directions from “near space”. 

And yes, if you are sending telemetry from both units, the sequence numbers may confuse the systems trying to plot the sequence. 

James
VE6SRV 
--
James
VE6SRV


James Ewen VE6SRV
 

Hessu at aprs.fi has his algorithms set to trigger on a somewhat arbitrary hop count and beacon frequency. As you know, there are no “rules” about how many hops, how often you beacon, and how much power you use. 

Amateur radio is all about gentlemen’s agreements. Like on HF, you only use as much power as is required to get the job done. 

High altitude balloon payloads use very little transmitter power due to power constraints and weight limits, but due to the advantageous antenna location, we get some of the best HAAT around. Rapid transmissions for a short duration flight can be tolerated, but be aware of your impact on the ground. Running no hops at altitude means you cause no extra load on the terrestrial network. Your packets will be heard by ground stations for hundreds of miles in all directions. Multiple I-gates will probably hear your transmissions, as well as your ground track vehicles. Only one I-gate forwarded packet will ever be seen on the APRS-IS stream due to the massive filtering done by the APRS-IS backbone. 

Your low powered tracker hundreds of miles away isn’t going to overpower higher powered land based transmitters much closer to the local digipeaters, so you never interfere with activity on the ground. Only stations listening on an empty frequency will hear your low powered tracker. You are about as polite as you can be while still doing your thing. 

However if you run any path requesting a hop from a ground based digipeater, your polite tracker now starts saturating all of the terrestrial RF network for hundreds of miles because your tiny voice is now being digipeated by the terrestrial digipeaters. 

Again watching anything that is fed by the APRS-IS will only show you the first packet heard by the APRS-IS, and not the dozens of copies that bounce around the terrestrial RF network. 

Be kind and polite, and frequent beacons will not cause an issue. 



On Mon, Apr 26, 2021 at 12:53 PM Christopher Rose <kb8uih88@...> wrote:
Cut TX rate a little. Try 90 seconds and see what APRS.FI says. I forgot if Bob Bruninga reccomended some beacon schedule. Been a while since I used APRS mobile equipment.



Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: Larry <larry.phegley@...>
Date: 4/26/21 1:38 PM (GMT-05:00)
Subject: Re: [GPSL] Redundancy on APRS

I use a big red bee and I don't know about controlling hops.   I see the complaint message about transmitting too often (every 62 seconds) from high altitude but just ignore it.   Should I be doing something different?  I was using a SPOT as the backup but I got too cheap to continue the subscription.   I bought a LYNQME last year and it guided me right to where it was sitting. 

Larry 
KJ6PBS


On Sun, Apr 25, 2021, 7:12 PM James Ewen VE6SRV <ve6srv@...> wrote:
We have flown out BEAR payloads and others with dual trackers using the same callsign. Use time slotting to keep them apart. You can set one to transmit at the top of the minute and the other at the bottom of the minute. It looks like a single tracker beaconing every 30 seconds. A short comment will let you know which is which in the raw packets if you aren’t looking at timestamps. 

You can get some issues if the GPS positions get out of sync. This can end up looking like a zig-zag stitch was used on a sewing machine to lay down your track if they get a bit out of sync. If you allow the tracker to send a position even with no GPS lock, then you can get longer and longer zigs back to the last known zag. Once they become far enough apart, aprs.fi will try to “help” by filtering out the bad positions, which might just end up being the good positions. It’s always best to listen directly to RF, and not rely on filtered feeds and sites that “help”. 

Don’t get me wrong, I use aprs.fi for chasing, and as long as things are perfect, it works well. But if things go haywire, direct RF is where you want to be. Straight from the horse’s mouth as it were. 

Obviously one would never use any hops at altitude as that is a serious waste of resources, and with what appears to be rapid beaconing from a single tracker, you might get people’s panties in a twist. 

Direct beaconing with no hops from 1000 feet or higher will always do better than a terrestrial hop unless you have huge alligator style mountaintop digipeaters in your area. 

The chances of your payload flying with no tracking at all until it is sitting on the ground,
and is in a spot that just happens to be able to get the attention of a digipeater, and that landing location beacon is the only position packet you have to use for recovery is slim to none. 

If you just HAVE TO HAVE hops in your outgoing path, please do so with an altitude aware tracker that can run no hops at altitude. There’s enough noise and collisions on the ground, we don’t need to be adding to the problems for hundreds of miles in all directions from “near space”. 

And yes, if you are sending telemetry from both units, the sequence numbers may confuse the systems trying to plot the sequence. 

James
VE6SRV 
--
James
VE6SRV

--
James
VE6SRV


Michael Hojnowski
 

Ya, personally I have no patience for the people complaining about my payload beaconing once/minute.  My region is totally peppered with weather stations polluting the APRS map, and beaconing 24/7 generating WAY more useless traffic than my trackers will generate in their 2 hour flights, twice/year.



If they complain to me, I direct them to the blue on my map and suggest they clean that up first.

Mike / KD2EAT

On 4/26/2021 3:08 PM, James Ewen VE6SRV wrote:
Hessu at aprs.fi has his algorithms set to trigger on a somewhat arbitrary hop count and beacon frequency. As you know, there are no “rules” about how many hops, how often you beacon, and how much power you use. 

Amateur radio is all about gentlemen’s agreements. Like on HF, you only use as much power as is required to get the job done. 

High altitude balloon payloads use very little transmitter power due to power constraints and weight limits, but due to the advantageous antenna location, we get some of the best HAAT around. Rapid transmissions for a short duration flight can be tolerated, but be aware of your impact on the ground. Running no hops at altitude means you cause no extra load on the terrestrial network. Your packets will be heard by ground stations for hundreds of miles in all directions. Multiple I-gates will probably hear your transmissions, as well as your ground track vehicles. Only one I-gate forwarded packet will ever be seen on the APRS-IS stream due to the massive filtering done by the APRS-IS backbone. 

Your low powered tracker hundreds of miles away isn’t going to overpower higher powered land based transmitters much closer to the local digipeaters, so you never interfere with activity on the ground. Only stations listening on an empty frequency will hear your low powered tracker. You are about as polite as you can be while still doing your thing. 

However if you run any path requesting a hop from a ground based digipeater, your polite tracker now starts saturating all of the terrestrial RF network for hundreds of miles because your tiny voice is now being digipeated by the terrestrial digipeaters. 

Again watching anything that is fed by the APRS-IS will only show you the first packet heard by the APRS-IS, and not the dozens of copies that bounce around the terrestrial RF network. 

Be kind and polite, and frequent beacons will not cause an issue. 



On Mon, Apr 26, 2021 at 12:53 PM Christopher Rose <kb8uih88@...> wrote:
Cut TX rate a little. Try 90 seconds and see what APRS.FI says. I forgot if Bob Bruninga reccomended some beacon schedule. Been a while since I used APRS mobile equipment.



Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: Larry <larry.phegley@...>
Date: 4/26/21 1:38 PM (GMT-05:00)
Subject: Re: [GPSL] Redundancy on APRS

I use a big red bee and I don't know about controlling hops.   I see the complaint message about transmitting too often (every 62 seconds) from high altitude but just ignore it.   Should I be doing something different?  I was using a SPOT as the backup but I got too cheap to continue the subscription.   I bought a LYNQME last year and it guided me right to where it was sitting. 

Larry 
KJ6PBS


On Sun, Apr 25, 2021, 7:12 PM James Ewen VE6SRV <ve6srv@...> wrote:
We have flown out BEAR payloads and others with dual trackers using the same callsign. Use time slotting to keep them apart. You can set one to transmit at the top of the minute and the other at the bottom of the minute. It looks like a single tracker beaconing every 30 seconds. A short comment will let you know which is which in the raw packets if you aren’t looking at timestamps. 

You can get some issues if the GPS positions get out of sync. This can end up looking like a zig-zag stitch was used on a sewing machine to lay down your track if they get a bit out of sync. If you allow the tracker to send a position even with no GPS lock, then you can get longer and longer zigs back to the last known zag. Once they become far enough apart, aprs.fi will try to “help” by filtering out the bad positions, which might just end up being the good positions. It’s always best to listen directly to RF, and not rely on filtered feeds and sites that “help”. 

Don’t get me wrong, I use aprs.fi for chasing, and as long as things are perfect, it works well. But if things go haywire, direct RF is where you want to be. Straight from the horse’s mouth as it were. 

Obviously one would never use any hops at altitude as that is a serious waste of resources, and with what appears to be rapid beaconing from a single tracker, you might get people’s panties in a twist. 

Direct beaconing with no hops from 1000 feet or higher will always do better than a terrestrial hop unless you have huge alligator style mountaintop digipeaters in your area. 

The chances of your payload flying with no tracking at all until it is sitting on the ground,
and is in a spot that just happens to be able to get the attention of a digipeater, and that landing location beacon is the only position packet you have to use for recovery is slim to none. 

If you just HAVE TO HAVE hops in your outgoing path, please do so with an altitude aware tracker that can run no hops at altitude. There’s enough noise and collisions on the ground, we don’t need to be adding to the problems for hundreds of miles in all directions from “near space”. 

And yes, if you are sending telemetry from both units, the sequence numbers may confuse the systems trying to plot the sequence. 

James
VE6SRV 
--
James
VE6SRV
--
James
VE6SRV


Christopher Rose
 

So, all the weather stations "polluting the environment" are all on RF and not sending via the internet? If you are only on RF with no connection to the internet and still see so many wx icons then you need to help and find out why so many have aprs altogether?



Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: Michael Hojnowski <kd2eat@...>
Date: 4/27/21 11:01 AM (GMT-05:00)
To: GPSL@groups.io
Subject: Re: [GPSL] Redundancy on APRS

Ya, personally I have no patience for the people complaining about my payload beaconing once/minute.  My region is totally peppered with weather stations polluting the APRS map, and beaconing 24/7 generating WAY more useless traffic than my trackers will generate in their 2 hour flights, twice/year.



If they complain to me, I direct them to the blue on my map and suggest they clean that up first.

Mike / KD2EAT

On 4/26/2021 3:08 PM, James Ewen VE6SRV wrote:
Hessu at aprs.fi has his algorithms set to trigger on a somewhat arbitrary hop count and beacon frequency. As you know, there are no “rules” about how many hops, how often you beacon, and how much power you use. 

Amateur radio is all about gentlemen’s agreements. Like on HF, you only use as much power as is required to get the job done. 

High altitude balloon payloads use very little transmitter power due to power constraints and weight limits, but due to the advantageous antenna location, we get some of the best HAAT around. Rapid transmissions for a short duration flight can be tolerated, but be aware of your impact on the ground. Running no hops at altitude means you cause no extra load on the terrestrial network. Your packets will be heard by ground stations for hundreds of miles in all directions. Multiple I-gates will probably hear your transmissions, as well as your ground track vehicles. Only one I-gate forwarded packet will ever be seen on the APRS-IS stream due to the massive filtering done by the APRS-IS backbone. 

Your low powered tracker hundreds of miles away isn’t going to overpower higher powered land based transmitters much closer to the local digipeaters, so you never interfere with activity on the ground. Only stations listening on an empty frequency will hear your low powered tracker. You are about as polite as you can be while still doing your thing. 

However if you run any path requesting a hop from a ground based digipeater, your polite tracker now starts saturating all of the terrestrial RF network for hundreds of miles because your tiny voice is now being digipeated by the terrestrial digipeaters. 

Again watching anything that is fed by the APRS-IS will only show you the first packet heard by the APRS-IS, and not the dozens of copies that bounce around the terrestrial RF network. 

Be kind and polite, and frequent beacons will not cause an issue. 



On Mon, Apr 26, 2021 at 12:53 PM Christopher Rose <kb8uih88@...> wrote:
Cut TX rate a little. Try 90 seconds and see what APRS.FI says. I forgot if Bob Bruninga reccomended some beacon schedule. Been a while since I used APRS mobile equipment.



Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: Larry <larry.phegley@...>
Date: 4/26/21 1:38 PM (GMT-05:00)
Subject: Re: [GPSL] Redundancy on APRS

I use a big red bee and I don't know about controlling hops.   I see the complaint message about transmitting too often (every 62 seconds) from high altitude but just ignore it.   Should I be doing something different?  I was using a SPOT as the backup but I got too cheap to continue the subscription.   I bought a LYNQME last year and it guided me right to where it was sitting. 

Larry 
KJ6PBS


On Sun, Apr 25, 2021, 7:12 PM James Ewen VE6SRV <ve6srv@...> wrote:
We have flown out BEAR payloads and others with dual trackers using the same callsign. Use time slotting to keep them apart. You can set one to transmit at the top of the minute and the other at the bottom of the minute. It looks like a single tracker beaconing every 30 seconds. A short comment will let you know which is which in the raw packets if you aren’t looking at timestamps. 

You can get some issues if the GPS positions get out of sync. This can end up looking like a zig-zag stitch was used on a sewing machine to lay down your track if they get a bit out of sync. If you allow the tracker to send a position even with no GPS lock, then you can get longer and longer zigs back to the last known zag. Once they become far enough apart, aprs.fi will try to “help” by filtering out the bad positions, which might just end up being the good positions. It’s always best to listen directly to RF, and not rely on filtered feeds and sites that “help”. 

Don’t get me wrong, I use aprs.fi for chasing, and as long as things are perfect, it works well. But if things go haywire, direct RF is where you want to be. Straight from the horse’s mouth as it were. 

Obviously one would never use any hops at altitude as that is a serious waste of resources, and with what appears to be rapid beaconing from a single tracker, you might get people’s panties in a twist. 

Direct beaconing with no hops from 1000 feet or higher will always do better than a terrestrial hop unless you have huge alligator style mountaintop digipeaters in your area. 

The chances of your payload flying with no tracking at all until it is sitting on the ground,
and is in a spot that just happens to be able to get the attention of a digipeater, and that landing location beacon is the only position packet you have to use for recovery is slim to none. 

If you just HAVE TO HAVE hops in your outgoing path, please do so with an altitude aware tracker that can run no hops at altitude. There’s enough noise and collisions on the ground, we don’t need to be adding to the problems for hundreds of miles in all directions from “near space”. 

And yes, if you are sending telemetry from both units, the sequence numbers may confuse the systems trying to plot the sequence. 

James
VE6SRV 
--
James
VE6SRV
--
James
VE6SRV


Michael Hojnowski
 

On 4/28/2021 10:38 AM, Christopher Rose wrote:
So, all the weather stations "polluting the environment" are all on RF and not sending via the internet? If you are only on RF with no connection to the internet and still see so many wx icons then you need to help and find out why so many have aprs altogether?
Actually, the complaint I've heard the most is that my tracker, at altitude, will be heard by a ton of iGates and Digipeters, and that the ensuing traffic will "melt down the network and overload aprs.fi".  Meanwhile, in New York State alone, I see well over 100 APRS weather stations beaconing via IP, on average at 5 minute intervals.  I don't know an easy way to check, but lets' be hyper conservative and say there are 2000 weather stations worldwide. That's 400 weather updates/minute.  24/7/365.   My tracker making a beacon once/minute, and being heard by a 5 iGates generates, say 5/minute for 2 hours.  If that tips the aprs network over the edge, then perhaps some consideration should be given into exactly which traffic is sent on the aprs network.

For my own purposes, I'm beginning to dabble in alternate protocols like LoRa and 4FSK, and I also usually run a backup tracker on an alternate frequency.  None of that traffic goes to aprs.fi by default.  My own gateways are routing traffic directly to Habhub, just to offload aprs of that redundant traffic.  Also, Habhub is OK with slightly higher update rates, so I can send telemetry at shorter intervals if I choose, and not feel guilty.

Mike / KD2EAT


Christopher Rose
 

Hi Michael,

Hopefully nobody is beaconing at 1 minute intervals unless they are mobile, and better yet that should be 90 seconds to 2 mins based on how fast someone may travel. Anybody beaconing faster is indeed overloading the system. WX stations should send at about 10 minutes or so? I am not sure about how fast our locals are sending.

A group here at the local school district launched balloons for several years until covid stopped all the group gatherings and in school instruction. I forgot what their beacon rate was but I think they were using Relay-Wide then wide1-2 then no path as they got more information on how to set up the trackers. No path still will make the aprs-is if the tx hits a digi. Better still you can still pick it up mobile as long as the tracker functions. Maybe one of them are on this list and may chime in with their knowledge.

The system won't melt down but your packets are important to you just as others are important to them.

Do you send notices to the GPSL list or other balloon lists when you schedule a launch? I like tracking them for fun. 

73,
Chris
KB8UIH

-----------------------------------------

From: "Michael Hojnowski"
To: GPSL@groups.io
Cc:
Sent: Wednesday April 28 2021 2:45:09PM
Subject: Re: [GPSL] Redundancy on APRS


On 4/28/2021 10:38 AM, Christopher Rose wrote:
> So, all the weather stations "polluting the environment" are all on RF
> and not sending via the internet? If you are only on RF with no
> connection to the internet and still see so many wx icons then you
> need to help and find out why so many have aprs altogether?

Actually, the complaint I've heard the most is that my tracker, at
altitude, will be heard by a ton of iGates and Digipeters, and that the
ensuing traffic will "melt down the network and overload aprs.fi". 
Meanwhile, in New York State alone, I see well over 100 APRS weather
stations beaconing via IP, on average at 5 minute intervals.  I don't
know an easy way to check, but lets' be hyper conservative and say there
are 2000 weather stations worldwide. That's 400 weather updates/minute. 
24/7/365.   My tracker making a beacon once/minute, and being heard by a
5 iGates generates, say 5/minute for 2 hours.  If that tips the aprs
network over the edge, then perhaps some consideration should be given
into exactly which traffic is sent on the aprs network.

For my own purposes, I'm beginning to dabble in alternate protocols like
LoRa and 4FSK, and I also usually run a backup tracker on an alternate
frequency.  None of that traffic goes to aprs.fi by default.  My own
gateways are routing traffic directly to Habhub, just to offload aprs of
that redundant traffic.  Also, Habhub is OK with slightly higher update
rates, so I can send telemetry at shorter intervals if I choose, and not
feel guilty.

Mike / KD2EAT







James Ewen VE6SRV
 

So I'm going to address statements made in the past two messages in this one reply. In no way am I trying to admonish anyone for their efforts, but rather just address some mis-statements, and other issues as written. 

> Actually, the complaint I've heard the most is that my tracker, at
> altitude, will be heard by a ton of iGates and Digipeters,

This is a fairly accurate statement. You can determine what "a ton" actually is by determining your RF footprint from any altitude, and then plot a circle of the appropriate diameter around your payload location, and then count all the i-gates and digipeaters inside that circle.

> and that the
> ensuing traffic will "melt down the network and overload aprs.fi". 

Not so accurate a statement here. There's a lot of assumptions happening in this part of the statement. 

1) What path is the payload using? No path, no major impact on the network. Bad path, more impact on the network.
2) What is the network? Generally the network would consist of the APRS digipeaters inside the RF footprint, plus all APRS digipeaters as many hops outside that RF coverage area as there are path elements. I-gates really don't factor into the part of the network that might "melt down" because they are passive listen only devices.
3) What does "melt down" mean? Packets heard by a digipeater with no hops to be acted upon. Don't cause any issues. A digipeater will simply hear the packet and do nothing. If the packet's next path element to be acted upon is supported by the digipeater, then the digipeater *should* immediately attempt to resend the packet out on RF. Digipeaters by WB4APR's definition should immediately resend the packet regardless of activity on the channel. Some digipeaters are poorly implemented and will hold off for a while, and then send the packet, causing the channel to be occupied for longer than necessary by the same information.
4) Who cares if aprs.fi is overloaded? It is a single server (group of servers) running a single website. It is simply a portal that allows limited observation of APRS packets via a website. The amount of bandwidth available and hardware to ingest the stream from the APRS-IS is probably more than adequate to handle all of the traffic worldwide at peak demand. One more packet from a high altitude balloon every so often will not take down aprs.fi. Yes, you read that right... one more packet. The APRS-IS is designed to drop all but the first copy of any packet heard, so all that ends up being delivered to aprs.fi is just one copy of a packet sent by that high altitude payload.  

So let's deal with all of that:

If we are flying at altitude with no path, then the only impact the payload has on the "ton of digipeaters and i-gates" is that they hear a packet being sent out over RF, but only if it isn't clobbered by a louder signal from some station nearby. Remember FM capture effect rules... your pip-squeak tracker dozens of miles away, far above the gain pattern of a ground based digipeater or i-gate will easily be clobbered by a higher powered signal from a nearby station with a higher gain antenna, and higher powered transmitter. Your low powered tracker will only ever take up space that others aren't using. Some stations on the ground will hear your packets and hold off on transmitting, so you can slow down some stations for a 1/2 second or so.

Now, if you are asking for a hop from a main digipeater (WIDE2-n or more), then any digipeater that hears your packet will then resend the packet, at a much stronger level, which takes up time on the local RF network. Multiply that by all the digipeaters in your RF footprint. That can be seen as a major impact. Will it melt down the network? No, but it will occupy the channel over a large area. Multiple hops mean multiply the impact even more. Many digipeaters nearby will probably already have handled your packet, so properly implemented digipeaters will drop the packet. Some digipeaters that may not have heard and acted upon the initial packet will now digipeat the packet again, occupying more channel airtime.

Using a path such as WIDE1-1,WIDE2-1 is a huge problem. Home fill-in digipeaters which act upon the WIDE1-1 alias are now drawn into the fray. By design, home fill-in digipeaters DO implement hold off until the channel is clear, so by design, the main digipeaters will repeat the packet acting upon the WIDE1-1 element, then other digipeaters that have not acted upon the packet will act upon the WIDE2-1 element. Only then once things go quiet on the channel will the home fill-in digipeaters kick up and send the packet out again. WIDE1-1 is only to be used by extremely low powered ground based equipment that need assistance from home fill-in digipeaters to be able to get heard by the main digipeaters. Using WIDE1-1 as a path element from a normal mobile station, or worse yet any fixed station is asking for causing network congestion problems.

> Meanwhile, in New York State alone, I see well over 100 APRS weather
> stations beaconing via IP, on average at 5 minute intervals.

Look at the packets and see what they are using as their medium. Are they on RF or only on TCP/IP?

I have half a dozen weather stations on the map in my area. Click on the station and look at the path. Here's one from my area.

[APRS via TCPXX*,qAX,CWOP-7]
That's an IP only packet on the CWOP network.

Here's another that is an actual amateur radio station on RF.
[APOTW1 via ALIANC*,WIDE2-1,qAR,ELNORA]

Go have a look at the "q" construct to understand what you are looking at. http://www.aprs-is.net/q.aspx

>  I don't
> know an easy way to check, but lets' be hyper conservative and say there
> are 2000 weather stations worldwide. That's 400 weather updates/minute. 
> 24/7/365.   My tracker making a beacon once/minute, and being heard by a
> 5 iGates generates, say 5/minute for 2 hours.

You are underestimating the number of weather stations... remember from above, 5 i-gates may hear your packet, but the APRS-IS is designed to drop all but the first copy heard, so no matter how many i-gates hear your packet, only one copy survives to travel the APRS-IS network.

> If that tips the aprs
> network over the edge, then perhaps some consideration should be given
> into exactly which traffic is sent on the aprs network.

You have the right conclusion, but you are missing key points and concepts. If you invest some time into understanding the way the various components work, and what impact your station has on the network, you can refute false claims. If you configure your tracker politely, you never have to explain to people why you are causing so much congestion. With little to no understanding of what impact you have, arguing your side is equivalent to the schoolyard response of  "Oh yeah? Well my Dad can beat up your Dad!", or maybe the logic of a former President of a major country... "Many people say we have a great APRS network. Some say it's the best APRS network".

Take the time to educate yourself and learn about the subject at hand so that you can present reasoned arguments backed by fact, and not be just making noise because you can.

Again, the above is not aimed at anyone in particular, but as a general statement to all. Time invested educating oneself is never time wasted.

> Hopefully nobody is beaconing at 1 minute intervals unless they are mobile, and better yet that 
> should be 90 seconds to 2 mins based on how fast someone may travel. Anybody beaconing
> faster is indeed overloading the system. WX stations should send at about 10 minutes or so?
> I am not sure about how fast our locals are sending. 

Transmission frequency is only part of the equation that contributes to network load. A station sending packets every 60 seconds with no path is causing less load on the network than a station sending packets every 3 minutes with a WIDE2-2 path. How does that work you say? Both should be equal? Nope... using a path of WIDE2-2 means that the channel is busy once while the initial packet is sent, again when the first digipeater repeats the packet, and then a third time when the second digipeater sends it again. How much area did the initial packet impact? Let's assume that it covers the same area as the first digipeater can cover. The first digipeater then uses up as much time and area as the initial packet. Then the second digipeater uses up as much time again, but impacts additional area that the initial packet and the first digipeater impacted. It's not just the amount of time the packet is occupying on the channel, but also the area impacted.

This is all assuming that there are only 2 digipeaters in the network. Think about the impact if 2 digipeaters can hear the initial packet, and then 2 additional digipeaters each can hear those 2 first digipeaters. Remember the Fabrege shampoo commercial? https://www.youtube.com/watch?v=mcskckuosxQ

When you are thinking about your station's impact, it's not only time, but multiplied by area (digipeater hops) that really counts. From altitude, you aren't just telling two friends about that shampoo, but maybe dozens. 

> I forgot what their beacon rate was but I think they were using Relay-Wide then
> wide1-2 then no path as they got more information on how to set up the trackers.  

Let's just ignore the ancient and no longer supported RELAY,WIDE hop requests. Please never use WIDE1-2. This is a malformed hop request. Many digipeaters will act upon it as a normal hop request, and then decrement it to WIDE1-1, which is ONLY ever to be used as an initial hop. Here it would be a second hop request, basically having every main digipeater asking every home fill-in digipeater to act upon the packet. This is a major faux pas. 

> No path still will make the aprs-is if the tx hits a digi.  

This is an incorrect statement. A packet with no hop requests will not make it to the APRS-IS if a digipeater hears the packet. The digipeater will not act upon the packet because there is no valid hop request. I-gates hearing the packet will forward the packet to the APRS-IS network. That is the role of an i-gate. An i-gate colocated with a digipeater may be what was insinuated, but digipeaters only repeat packets on the RF network, and do not pass packets along to the APRS-IS. I-gates pass packets heard on RF along to the APRS-IS and vice-versa in specific cases. I-gates do not repeat packets on RF. This may seem like semantics, but a clear understanding of the roles of the various APRS network components is necessary to ensure a proper understanding of how the network functions.

Hopefully some of the information and clarification helps with understanding the operation of the APRS network, and the potential impact of operations.

No one person can dictate to another what constitutes "proper" operation of their station. There are people who feel it is of vital importance that the world knows the temperature in their backyard every 10 minutes. I've read where this high density, high frequency data that is freely available is being ingested by research teams and is being used to test models of micro-climate predictions. Who knows what future climate models might come from this research. 

Personally, I believe the APRS RF network should be available for real time information sharing between local assets. Telling me the weather in your backyard every 10 minutes is not of interest to me. But I will make an exception for weather stations at local model aircraft fields, or paragliding sites that need to use RF and the APRS network for low cost local weather observations. But that's my opinion, and I won't try to force someone to shut down their backyard weather station. If you have the ability to send the weather information via CWOP, I would find that to be a better solution though. aprs.fi drives me crazy with all of the non-APRS traffic displayed on the map. It would be nice if Hessu created a URL that one could use that only showed APRS traffic, and not all the AIS and CWOP stations. It's feature creep like a Microsoft operating system. A system that started with a single well defined task, that has been overwhelmed by add-on tasks that make the original use almost an afterthought.

So, where does that get us in the end? Learn about the APRS network, and the impact your operations have on the network. Balance your desired operation against the impact you will have on the network and the enjoyment of others. If you hog channel sending position reports every few seconds, with a nasty digipeater path which causes the RF channel to be clogged with noise, you are not going to make any friends. But if you send packets at a reasonable rate with little impact on the RF network on the ground, you stand a better chance of not raising the ire of anyone.

You may still have someone complain, but if you can explain how little impact your operations have, and your need to send position reports as often as you are doing, you may be able to alleviate some complaints. You may not, and that's where you really need to understand what you are doing, and be able to defend your position well.

As a last resort, you can always explain that your flight is of a very short duration, only a few hours up and back down. Long duration flights however don't get to use this excuse, and they really need to be aware of just how large of an area they are affecting as they can literally drift around the world. You can make enemies worldwide with poor operating practices. 


James
VE6SRV


On Wed, Apr 28, 2021 at 1:09 PM Christopher Rose <kb8uih88@...> wrote:
Hi Michael,

Hopefully nobody is beaconing at 1 minute intervals unless they are mobile, and better yet that should be 90 seconds to 2 mins based on how fast someone may travel. Anybody beaconing faster is indeed overloading the system. WX stations should send at about 10 minutes or so? I am not sure about how fast our locals are sending.

A group here at the local school district launched balloons for several years until covid stopped all the group gatherings and in school instruction. I forgot what their beacon rate was but I think they were using Relay-Wide then wide1-2 then no path as they got more information on how to set up the trackers. No path still will make the aprs-is if the tx hits a digi. Better still you can still pick it up mobile as long as the tracker functions. Maybe one of them are on this list and may chime in with their knowledge.

The system won't melt down but your packets are important to you just as others are important to them.

Do you send notices to the GPSL list or other balloon lists when you schedule a launch? I like tracking them for fun. 

73,
Chris
KB8UIH

-----------------------------------------

From: "Michael Hojnowski"
To: GPSL@groups.io
Cc:
Sent: Wednesday April 28 2021 2:45:09PM
Subject: Re: [GPSL] Redundancy on APRS

On 4/28/2021 10:38 AM, Christopher Rose wrote:
> So, all the weather stations "polluting the environment" are all on RF
> and not sending via the internet? If you are only on RF with no
> connection to the internet and still see so many wx icons then you
> need to help and find out why so many have aprs altogether?

Actually, the complaint I've heard the most is that my tracker, at
altitude, will be heard by a ton of iGates and Digipeters, and that the
ensuing traffic will "melt down the network and overload aprs.fi". 
Meanwhile, in New York State alone, I see well over 100 APRS weather
stations beaconing via IP, on average at 5 minute intervals.  I don't
know an easy way to check, but lets' be hyper conservative and say there
are 2000 weather stations worldwide. That's 400 weather updates/minute. 
24/7/365.   My tracker making a beacon once/minute, and being heard by a
5 iGates generates, say 5/minute for 2 hours.  If that tips the aprs
network over the edge, then perhaps some consideration should be given
into exactly which traffic is sent on the aprs network.

For my own purposes, I'm beginning to dabble in alternate protocols like
LoRa and 4FSK, and I also usually run a backup tracker on an alternate
frequency.  None of that traffic goes to aprs.fi by default.  My own
gateways are routing traffic directly to Habhub, just to offload aprs of
that redundant traffic.  Also, Habhub is OK with slightly higher update
rates, so I can send telemetry at shorter intervals if I choose, and not
feel guilty.

Mike / KD2EAT