Someone it seems must’ve put together some “X-Digi” device that is sending out a junk packet ever 30 seconds. The “sender” is “CDM AL”, whatever that means, and of course DireWolf hates it because there is whitespace in the fourth position. The packet also says it’s an “X-Digi Test”. (Whatever an X-Digi is.)

This has been going on now non-stop over a month.

You’d think someone would notice their radio is TX’ing ever 30 seconds.

What’s the best way to tactfully approach this? I suppose “Fox hunting” is possible (would have to decode the signal while searching as there is a lot of traffic on APRS), but even if did find the sender what’s the best approach to be tactful about it (some people can be weird if they think you are “calling them out”).


Sent from my iPhone 13 Pro Max

开云体育

Hello k9wkj,

Sorry for the delay but I've been researching your issue and needed to setup an RTL SDR to do actual testing.? During that testing, I remember this issue was brought up some time ago:

??

I can confirm this specific post/approach within this Github issue works for me where as the other posts/approaches don't work.? I think the root issue here is the multiple levels of abstraction using variables when trying to be user friendly actually makes the Bash shell script break.?

I've attached a copy of the modified script here and we'll see if groups.io posts it or not.? If it does, review it and give it a try and let us know if it works or not.

--David
KI6ZHD

Thanks David,
that worked well.
73
Ian ZL1VFO

David,
the stream bandwidth is not a issue
as I said this is all inside our own network, with big fat pipes
we run 5.8Ghz wifi links to all our sites with even 30 mile links at upwards of 100Mbs
no firewalls, no port forwards and with battery backups
the links around town are past 300Mbs with a couple at past 600Mbps

but a stream seems like a last resort
when I get a bit of time i will look harder at it

de k9wkj

开云体育

Hey Everyone,

Rob had mentioned:

?? Make your "best" receive only site send the audio over UDP on 7355 to an instance of Direwolf that can transmit.

I personally don't think this would be a great idea.? Having a great high level receiver getting it's transmitted responses sent at a different, less-ideal lower level site could create all kinds of strange coverage area issues.? Yes, it could be better than what the user has now but I imagine it will be messy.? Then there is the matter of this constant UDP stream going between the two sites, consuming X Kbps of data, packet loss, possible challenges getting traffic through the firewalls (TCP port forwards won't work here), dynamic IPs, etc. all worth it??

--David
KI6ZHD

Rob,
W9CVA-10 has been running along fine for a few years, but it doesnt hear very well, because of its site
W9CVA-11 is the proposed remote receiver that can get on a great site??
everything is on our own network
-13 is just a HT I am using at low power in the house. -10 cant hear it from here, so -11 is being used to test the concept of the remote


I had started messing with the UDP stream idea a few days back
had not gotten far enough along to see if I could pass the decoded stream data from channel 1 to channel 0 so as to keep both receivers

?ADEVICE0 plughw:1,0
?ADEVICE1 UDP:7355 default
plus the channel definitions

then pass 1 to 0 with a filter action

dont know

now my head hurts more

de k9wkk

On Fri, Mar 17, 2023 at 01:17 PM, k9wkj wrote:

I can install a receive only setup at the very finest spot in the county (at the tippy top of a 300ft tower on a 400ft ridge via a receive only VHF stick?
on a multicoupler. this site is on our clubs intranet (it has internet, but using our network, we have wide area VHF machine there as well)
so utilizing that great receiver, we should be able to hear many if not all of the devices on RF.

Do I have the correct understanding of the issue?
? ?Your "best site" can only be receive only, so you cannot use it for the "best TX coverage".? This site does have network capability.
? ?On the other hand, you have other sites (also with network capability) that you want to take that receive data and "DIGI" to RF.
My suggestion:
? ?Make your "best" receive only site send the audio over UDP on 7355 to an instance of Direwolf that can transmit.
? ?Since the UDP audio is a normal input, Direwolf will evaluate it for normal DIGI rules, and if met, DIGI the packet.

? ? ADEVICE0 UDP:7355 default? ? ? ? ? ? ? ? ? ? ? ? ? ? ? This will receive the "remote" audio and the TX will be the?
This will work, but only with audio from the remote site.? You have no audio from the attached receiver (transceiver).
If that is acceptable, this is a good solution.
So, if W9CVA-13 transmits a packet with a path of WIDE1-1,WIDE2-1 and it is received by the receive only antenna (was W9CVA-11 - simple RTL can do this easily),
The audio is sent over UDP:73555 and?actually received/decoded at W9CVA-10.? If W9CVA-10 is set to DIGI the packet, it gets sent out from that site.
W9CVA (you indicate it has internet) would also inject it to APRS-IS, so that is covered as well.
I am not sure how many sites can receive the UDP?audio from the same source.

If you need W9CVA to also handle local RF (that the "bets site" may not hear), you could try to 'double up" on the audio device.
This would require a different device.??I have seen this work with some things, but never tried it with Direwolf.? It may give you a "device unavailable" type error.
? ?ADEVICE1 plughw:1,0? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? If plughw:1,0 is the same as default, this might work with no issue.

-------
Rob KB8RCO

开云体育

Andrew,
I guess I am trying to understand why I cant get position packets from W9CVA-13 (a FT3dr) which gets heard by W9CVA-11 (receive only gate) and sends that position report to APRS.IS? does not get repeated by W9CVA-10, even though -10 can not hear it directly.-10 does receive the report from APRS.IS.
the behavior I am trying to exhibit is desired in this case?
W9CVA-10 does not hear as well as we would like, that is a function of its site.
we need to be able to hear HTs and those little 1 watt trackers and some phones sending position reports
to support a county wide event at the end of May
I can install a receive only setup at the very finest spot in the county (at the tippy top of a 300ft tower on a 400ft ridge via a receive only VHF stick?
on a multicoupler. this site is on our clubs intranet (it has internet, but using our network, we have wide area VHF machine there as well)
so utilizing that great receiver, we should be able to hear many if not all of the devices on RF.

I will mess with some filtering and see if that helps
the confounding thing being, even if configured wrongly, it isnt changing the behavior?
My last out here maybe to run a UDP stream from the remote to channel 1 and pass it to channel 0.

my brain hurts

de k9wkj

开云体育

开云体育

Again, the _normal_design of an I-gate is not to do that. Are you referring to local APRSdroid and aprs.fi-on-iOS clients that don't _have_ 2-meter radios attached to them? Well, that is a problem, since these are not amateur radio stations (they are in the commercial cellular telephone service). You would have to configure your I-gate to forcibly transmit such stations (without forcibly transmitting other stations that do have direct RF connectivity). If your I-gate supports supplemental Tx filtering, there are some options you can try. However, the phone apps tend to make themselves hard to identify, because they probably use MicE packet format, which does not contain a tocall value that could be matched by the u/ filter. But the u/ filter doesn't support a range limit anyway, so if that worked, you would get

Morning Andrew
well this is not about the fact it is not sending distant stuff over RF, I dont want it to.
it is that it wont send locally generated traffic over RF unless it comes in on RF
I need it to do that, as even if it is not a permanent setup, it needs to fill in the holes
I opened up the gate radius to try and get traffic to be transmitted
things are not very well covered around here so I normally ran the digi at a 50km radius which?
gives a bit of overlap with a big digi well to the northwest of us, but I never noticed it was not working as expected

FYI we use YAAC and Direwolf as a receive only standalone to populate a display on the wall of our
ARES tralier

de k9wkj

From: [email protected] <[email protected]> on behalf of k9wkj

On Thu, Mar 16, 2023 at 03:59 PM, David Ranch wrote:
That is way too broad. You should not be transmitting over RF all traffic within a 80km >>diameter.

thats the trouble it doesnt transmit anything unless it hears it on RF

And that is how a Tx I-gate is supposed to work. Not flooding the local channel with extraneous and irrelevant packets from far away, but only transmitting traffic destined for an RF station heard by that I-gate. See the I-gating rules on

For example, if someone 80km away is sending an APRS text message addressed to someone else 80km away, why is that relevant to your _local_ RF environment? Now, if they were sending the text message to someone within 1km of your I-gate (and _heard_ by your I-gate), then it makes sense, as your I-gate might be the only path from the Internet to that RF-only station.

APRS is meant to be a local tactical network. Traffic out of RF range (or Aloha circle) of the local RF stations is not relevant unless it is explicitly addressed to a local station. And, with a 1200-baud transmission rate and issues with packet collisions, you really can't handle more than about 50 to 80 unique stations (depending on transmission rates) before the local channel is saturated.

If _you_ want to hear distant (non-locally-tactical) traffic, then _you_ need to make the Internet connection, not expect someone else to clog the local RF channel forwarding all that stuff to you.

Hope that helps you understand why your I-gate is working the way it does (and the way it was designed).

Andrew, KA2DDO
author of YAAC

On Thu, Mar 16, 2023 at 03:59 PM, David Ranch wrote:

That is way too broad.? You should not be transmitting over RF all traffic within a 80km diameter.

thats the trouble? ?it doesnt transmit anything unless it hears it on RF
toggling on some debug flags
this is W9CVA-13? coming over the network

I’m making an APRS beaconer with an Alinco DR-140 radio, a tone-key radio-to-soundcard interface (page 6 of ) and a Debian Bullseye computer with audio, that hosts direwolf.? The PTT part is giving me trouble.? To test the interface, I’m emulating the sound card output with my phone playing Spotify, but I get no activity on the PTT line.? Besides something being wrong with the circuit, an obvious mistake would be a wrong pinout on the RJ-45 microphone jack.? Am I right to assume that UP means transmit and DOWN means receive?? Also I’m assuming the PTT ground is the MIC ground.

From the Alinco DR-140 Service Manual, page 39:		Tone-keyed soundcard interface
DR-140 microphone jack	8 ??UP 7 ??GROUND 6 ??MIC 5 ??MIC GROUND 4 ??PTT 3 ??NC 2 ??DOWN 1 ??5vdc	TX audio to radio ground ? PTT ground PTT ? from radio receiver audio 5vdc
?	?	?

?

Have I properly mapped the outputs of the interface to the radio?

开云体育

Hello k9wkj,

1.? ? ?Ok.. just to confirm, this setup you're using is NOT using an SDR for RX correct?
correct it is a Midland LMR rig with a RA interface on a OrangePi One,? been doing it thing for several years

Ok

2.? ?When you say "the server", do you mean APRS-IS?
yes APRS-IS

Ok

3.? ?What traffic are you expecting to be transmitted from APRS-IS to RF?
anything that is incoming from within that 80Km radius including W9CVA-13 which comes in but does not go out over RF
there is plenty of incoming

That is way too broad.? You should not be transmitting over RF all traffic within a 80km diameter.?

--David
KI6ZHD

David,

here is the tail of /var/tmp/dw-start.log