开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育

APRS-IS passes weather, RF does not


 

I recently picked a new TNC so I have been passing weather traffic across the room. I love how Andrew attaches the weather to a beacon which allows using other than just the wx symbol.?But I experienced a problem that may be related to this attachment technique.

All of my weather flows OK into APRS-IS. When I send weather from my Pi-9K6 station to my Pi-TNC station only the position beacon arrives, no weather. When I send from the Pi-TNC station to the Pi-9K6 station it provides the weather about 60% of the time.

I ended up setting the new station up with aprx and it passes weather fine, so it's not a hardware issue.


 

开云体育

Did you set up the WXNOW.TXT ?port to read the wxnow file?

?

Sent from for Windows 10

?

From: Bill WA4OPQ
Sent: Friday, April 10, 2020 9:25 PM
To: [email protected]
Subject: [yaac-users] APRS-IS passes weather, RF does not

?

I recently picked a new TNC so I have been passing weather traffic across the room. I love how Andrew attaches the weather to a beacon which allows using other than just the wx symbol.?But I experienced a problem that may be related to this attachment technique.

All of my weather flows OK into APRS-IS. When I send weather from my Pi-9K6 station to my Pi-TNC station only the position beacon arrives, no weather. When I send from the Pi-TNC station to the Pi-9K6 station it provides the weather about 60% of the time.

I ended up setting the new station up with aprx and it passes weather fine, so it's not a hardware issue.

?


 

Hmmm.... I presume aprx sends the weather data without checking the symbol code? As in, it only needs one packet rather than converting to a 2-frame transmission?

Since a possibly related issue has been mentioned elsewhere for some other TNCs, I'm wondering if the problem is that some TNCs can't handle receiving a second packet from the computer before the TNC is finished transmitting the first packet, due to lack of buffering capacity and possible hold-back due to a busy RF channel. Some TNCs (such as the Kenwood TM-D7100/D710 radios) use RS232 hardware flow control to stop the local computer from sending more frame bytes when the TNC can't handle receiving any more, but not all TNCs do that, and not all USB-to-RS232 adapters actually support the RTS and CTS modem control signals in RS232 (as in, the computer would ignore the TNC's demand to stop sending).

As such, I'm considering an inter-packet transmit delay feature if multiple frames are backed up for transmission on a particular TNC port, so as to ensure the TNC gets the packet out before YAAC tries to shove another packet into the TNC. As a first draft, I'm going to assume that twice the expected transmit time should be used for each packet, so as to allow the packet to be modulated and transmitted fully and then to release the PTT long enough for someone else to get a packet in before your station transmits again.

In the interim, you might consider using a weather station code with an overlay character. For example, I have seen weather stations with an 'S' overlay to indicate they were solar-powered, a 'D' overlay for digipeater/weather stations, 'R' for a station with a Geiger counter measuring nuclear radiation, etc.

Andrew, KA2DDO
author of YAAC


 

I was so busy futzing with TNCs it didn't occur to me to try YAAC with the wx symbols. I needed a way to determine if I had a hardware or software issue, so I tried aprx.

aprx doesn't check symbols, that is how I found that only wx symbols will make it as far as findu. I ended up using the D overlay.

Bill


 

I'll always be a YAAC enthusiast, but for a remote wx station I'll probably use aprx on a pi zero.? By copying the weather format from YAAC I've got it sending positionless weather packets and using the digipeater symbol.??

It has a weather packet every ten minutes and a position packet every 30 minutes.

So there is no reason (that I can see) that YAAC has to immediately send the weather packet following the position packet. It appears that any reasonable delay is possible.


 

开云体育

That's what I'm planning for the next build. Just a little bit of delay before sending the next packet, and filling in the packet when it is transmitted, rather than when it is queued.

And no problem with using another APRS app better suited for the platform. Even if there wasn't a lack of Java support for the lower-powered processor on the Pi Zero, it's just too undersized to handle all of YAAC's graphical UI. And a remote station doesn't really need a graphical UI anyway.

Andrew, KA2DDO
author of YAAC


-------- Original message --------
From: Bill WA4OPQ <wa4opq@...>
Date: 4/22/20 17:14 (GMT-05:00)
To: [email protected]
Subject: Re: [yaac-users] APRS-IS passes weather, RF does not

I'll always be a YAAC enthusiast, but for a remote wx station I'll probably use aprx on a pi zero.? By copying the weather format from YAAC I've got it sending positionless weather packets and using the digipeater symbol.??

It has a weather packet every ten minutes and a position packet every 30 minutes.

So there is no reason (that I can see) that YAAC has to immediately send the weather packet following the position packet. It appears that any reasonable delay is possible.


 

It turns out I had the delay code already in most of the TNC drivers, but the time units were screwed up, so I didn't calculate enough delay time. Fixing it all for build 149.