Hi David,
No, the Linux "listen" program can print out TXed packets but you need to enable that feature with the "-a" option:
?? ?????? "-a??????? Allow for the monitoring of outgoing frames as well as incoming ones."
? What I mean by this is that a client and a service sharing the same ax port will never hear each other. ?If rmsgw listens for -10 on ax0 and pat tries to call -10 on ax0, the two will never connect. ?I built the loopback to solve this problem.
Ok, this is the second part of new news.? Pat is making an outbound connection via a local digi and back to your Raspberry Pi.? Now to be clear, are you digipeating or NODEing out and back?? I ask because when you NODE around, your SSID gets decremented by one.? That nuance might matter here.
? ?So, nomenclature here to make sure we are on the same page, by digipeating you mean adding a digipeater to the initial connection, correct? ?Versus NODEing, where you make an initial connection to a NODE and make a second, in-band connection to the destination? ?In that context, definitely digipeating. ?In general form, the pat connect alias looks like this: ?ax25://dw12/DIGI/MYRMS-10 where "dw12" is the ax port, DIGI is any digipeater, and MYRMS-10 is rmsgw on the Pi.
That's a LOT of power for only being so close to each other.? Can you put them in to "EL" or Extra Low mode which is 0.5w?? That might help here.? I would also argue that moving them father apart and also onto different Z-planes aka elevation might help if this is really an RFI issue.? If it is RFI related, I would expect to see other errors like USB device drops, etc.
I'm not sure what you mean here by "close to each other". ?Are you referring to distance between Pi and radio, or are you talking about my RF partners? ?I actually think 10w is pretty conservative, given my closest RF partners are 25-30 miles away. ?I did run this radio at 5w for a few years, but noticed that distant partners were unreliable at that power setting. ?I would be glad to test with the power set to "low", but I don't have an "EL" option. ?Again, a single radio being controlled by a single Pi (PROD). ?You used the plural "them" when referring to "EL" setting as if maybe you thought I had 2 radios, but I don't.
The Z-plane confused me for a minute because I was thinking cartesian coordinates, but you must be referring to an antenna coordinate system where Z runs up and down (parallel to gravity). ?In that coordinate system, the relationship between radio and Pi would be described as the radio at the origin, and the Pi is at x=0, y=0, z=-3 where units are in feet. ?To paint a word picture, the radio is mounted on the top of a bakers rack, with the Pi directly underneath, but 3 shelves down. ?If I moved the Pi, the best distance I could practically get would be x=-2, y=-8 and z=-5. ?It would take me a while to get the lengths of cables needed to make that happen.
Swapping the SD cards around might help here and I imagine that "LEGACY" os is using an older kernel that might not have these AX.25 issues.? Did that LEGACY setup also have rmsgw and Pat running at the same time on it?? In addition to this test and since you have multiple PIs, you might consider splitting apart of the Pat and rmsgw onto different Pis.? That might help isolate the issue as well.
My thought was actually swapping the whole Pi (LEGACY for TEST). ?The value in the LEGACY unit is that it is a known quantity; working software, firmware and hardware in the RF environment. ?Besides, LEGACY is a Pi3, where TEST is a Pi4, so I don't think a swapped SD would boot. ?Correct, LEGACY is an older build, maybe jessie or buster, but definitely an older kernel. ?LEGACY has both rmsgw and Pat; it's nearly an identical configuration to PROD/TEST, just older software versions. ?However, LEGACY was using different sound hardware, a UDRC-II. ?I would pry the UDRC-II off the header and use the CM108 usb adapter from TEST.
As for splitting up rmsgw and Pat, I decided that I would just turn off Pat for a test cycle. ?If the Pi crashes, then we know that the kernel blaming Pat is a red-herring. ?Since we need some traffic to trigger the crash, I've been just axcall'ing to another node and disconnecting on occasion.
? Thanks
? Mike
