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
