• Effective immediately we will be deleting, without notice, any negative threads or posts that deal with the use of encryption and streaming of scanner audio.

    We've noticed a huge increase in rants and negative posts that revolve around agencies going to encryption due to the broadcasting of scanner audio on the internet. It's now worn out and continues to be the same recycled rants. These rants hijack the threads and derail the conversation. They no longer have a place anywhere on this forum other than in the designated threads in the Rants forum in the Tavern.

    If you violate these guidelines your post will be deleted without notice and an infraction will be issued. We are not against discussion of this issue. You just need to do it in the right place. For example:
    https://forums.radioreference.com/rants/224104-official-thread-live-audio-feeds-scanners-wait-encryption.html

Technical details about APRS packets

Joined
Apr 9, 2018
Messages
265
Location
CO, USA
#25
Anyone in an area where APRS is so congested that multiple retries are necessary to get a packet through?

If you tune to 144.390 or whatever it is in your locale and hear an APRS packet every couple of seconds where it's less than 5-10 seconds or so, that locale is pretty much congested I'd say. Then I wonder how many of those packets are digipeater packets versus initial transmits? Then I wonder what the packet loss rate is due to collisions in that locale...

It's still fairly sparse around my locale, maybe once every 45 seconds or so, depending on the time of day.
 

JeffDS3

Member
Premium Subscriber
Joined
Jun 5, 2016
Messages
447
Location
Kings County, CA
#26
I’m surprised there isn’t more coordination regarding APRS, such as splitting up a time frame for different types of packets/stations.
 

JeffDS3

Member
Premium Subscriber
Joined
Jun 5, 2016
Messages
447
Location
Kings County, CA
#28
I'm sure there is, you could do something like how Ethernet (or AlohaNet which is even more applicable) works, but it only goes so far...
If you implement the timing control on the software side, you could enforce it easier. Weather stations would only TX every 10 minutes (or less), digipeaters at 15 and 45 seconds of the minute, Internet linked digipeaters at the top and 30 seconds, etc. You could also implement in the RX side of a device to “study” the frequency and determine when reoccurring signals occur and then figure out the best time to transmit itself.
 
Joined
Apr 9, 2018
Messages
265
Location
CO, USA
#29
There are also the transmit-only nodes, what should be done about these? Also if there are more than one weather stations within radio range, which one gets which slot without coordination?

Definitely time slotting would help, but yeah, it depends if that node also has a receiver. The nodes that have receivers could work with the transmit only nodes (btw, that would be interesting, is there a bit in the spec that tells whether a transmitting node is transmit-only? That could be useful to help work around collisions.)
 

JeffDS3

Member
Premium Subscriber
Joined
Jun 5, 2016
Messages
447
Location
Kings County, CA
#30
There are also the transmit-only nodes, what should be done about these? Also if there are more than one weather stations within radio range, which one gets which slot without coordination?

Definitely time slotting would help, but yeah, it depends if that node also has a receiver. The nodes that have receivers could work with the transmit only nodes (btw, that would be interesting, is there a bit in the spec that tells whether a transmitting node is transmit-only? That could be useful to help work around collisions.)
True, but I would say there should be a spec, and TX only wouldn’t be included in there so going forward, hopefully they would go away over time. You could also encourage those people to only transmit at a specific time slot (determined by area and station type).

For weather stations, it would be the same thing. Just have to get people to coordinate. You could also say that they should only transmit once every 10 minutes, so you could put about 10 in a 10 minute period (idk if you really need more than that in a area).

And for everything else, they would just have to listen and figure it out and map out the time slot system. I believe AIS for marine tracking does something similar.
 
Joined
Jul 25, 2004
Messages
3,667
#32
Both my 710 and my old TNC setup would use the squelch to hold a packet transmission until the channel was clear (not sure it actually sensed that the radio had squelched or if the audio had dropped, but either way it wouldn't send a packet if the channel was busy. It's not easy to tell the transmission was held on the typical timed beacon, but if you manually attempt to beacon you may notice that sometimes it will send immediately (the channel was clear) and other times it waits a bit, perhaps quite a bit, before sending the packet (the channel was busy).

For this to work, you'll need the various RS-232 control pins to be in place and operational. You'll also need to have your software configured to recognize and respect the status to wait for a clear channel to transmit. Some information on this operation is given on this discussion page from the APRSIS32 software --> Setup TNC to transmit with squelch open??? - APRSISCE/32 The future of Amateur Radio APRS
DCdconn ON|OFF Default: OFF

OFF RS-232 cable Pin 8 is permanently set high (default).
ON RS-232 cable Pin 8 follows the state of the CON (or DCD) LED.

DCDCONN defines how the DCD (Data Carrier Detect) signal affects pin 8 in the RS-232 interface to your computer or terminal. Some programs such as PBBS software require that DCDCONN be ON. DCDCONN also works in the RAWHDLC and KISS modes. In RAWHDLC and KISS, no packet connections are known to the PK-96. With DCDCONN ON, the state of the radio DCD is sent to the RS-232 DCD pin (pin-8). This may be necessary to some Host applications that need to know when the radio channel is busy.
 
Joined
Apr 9, 2018
Messages
265
Location
CO, USA
#33
With software TNCs it's even easier, but if you have multiple stations waiting, both may decide to want to send as soon as it's clear and you get a collision that you can't tell until you get a response.

Keeping everything random helps, having collisions with random events... eventually one packet will get through.

All of this is solved in cellular networks by carefully controlled TDMA FDMA CDMA etc., etc. Having people not have to strictly follow rules results in this kind of chaos...
 
Top