I have written on incompatibility of Argent Data TNCs with other devices.
In pursuing apparent packet loss, I have run up a Paccomm Tiny-2 MK-2 TNC with 6PACK firmware, and my aprx server using Linux AX25 kernel support and 6PACK driver.
It has become apparent that although the system reliably decodes packets from a multi-packet burst from VK2AMW-1, it only ever decodes the first packet of a multi-packet burst from VK2RHR-1. Frame check errors are logged.
VK2RHR-1 uses a Argent Data T3-135 TNC which sends isochronous signals between successive frames in the same burst, something which I think is inconsistent with the AX.25 standards which require 0x7e bytes when idling. (VK2AMW-1 does send 0x7e bytes between frames.)
I have seen argument that Argent’s method is superior. It might be in a closed network of all Argent devices, possibly for reasons of the proprietary decoding technology, but it certainly is not interoperable in a mixed technology network.
Now, if I wrote the TNC code, I would simply regard the isochronous signals as a stream of zeros which on receipt of another 0x7e becomes a frame which is unlikely to have a valid CRC and would then be discarded. For some reason in the 6PACK firmware, that invalid frame affects decoding of the following valid frame.
Hams give little weight to standards in AX.25 / APRS, and it is one of the contributors to the manifest low quality of APRS.