Strategic Engineering

I stumbled on to a UHF frequency that I initially thought was a school, so I added it to my school system list for investigation later. On random days, I turn on that school system in my scanners and just passively listen to see which frequencies are actually being used, and if they are in fact schools.

One frequency in particular I very quickly realized was being used by 3 separate organizations and 2 of them were clearly not a school. On first pass, one still might be a school, one is a maintenance department at a facility, and one is DMR Digital Voice and appears to be a construction site.

An initial FCC license search confirms that this frequency is licensed by several users concurrently. So now the challenge is, can I determine a set of unique signal characteristics to match against each user. Frequency is obviously the same between all 3. But perhaps CTCSS/DCS is used on the 2 analog users and then DMR for the 3rd user should be easy to isolate.

I've performed alot of logging, now I just need to isolate the data and program it back into the scanners to see if I figured it out.

#Scanning #Radio

Server observations

I started playing with the TAK ecosystem( https://www.civtak.org/ ) with ATAK and iTAK on user devices. For the server component I've been utilizing TAKy( https://github.com/tkuester/taky ). So far its been working out great.

The setup guides for TAKy and other TAK servers are focused on the public IP address of the server you're setting up. In many cases though, you won't really have a public IP address to give the setup wizard. Things like hosting it on a consumer internet connection where you only get a DHCP address from the ISP make it a problem. But also how you choose to implement it via bare metal, Virtual Machines or Containers, there isn't a public IP address in scope to give the setup wizard.

I moved forward with TAKy on an internal VM and got that working and started connecting ATAK/iTAK clients that were already on my internal network. Everything worked as expected. As I used the onboarding/setup Datapackages( TAK term ) to get a client connected, I poked into the zip file to find a manifest. As part of this manifest it tells clients where the server is, and right there is the “public IP” the setup wizard was asking about.

TAKy is a pretty small server implementation for TAK, this was part of the reason I choose it. Its also implemented in python and is open source, so it was easy to go take a look at things. I found that the configuration file for TAKy is just a simple .ini type file. Further, the “public_ip” field ONLY gets used for making that onboarding manifest file, its never used internally for TAK server functionality.

So, I just tried putting in a DNS name for “public_ip” in the configuration file and restarted. Everything still functioned just fine. Even modifying an existing ATAK client server settings with the DNS name still worked just fine. I then created an onboarding datapackage for a brand new client and indeed, the manifest file included the DNS name instead of an IP address. Passing this onboarding datapackage to a friend worked flawlessly as well.

So, in fact, TAKy can use a DNS name for the public ip instead of a literal IP address. This simplifies hosting & infrastructure concerns. I'm not sure how this would effect other TAK server implementations.

Client DNS Observation

ATAK on an android device has been working great during several testing sessions. However, I noticed one interesting thing. It appears that ATAK( the program ) only makes up a single DNS query on startup. What ever IP address comes back as part of the response is cached internally for the duration of the program run and through connect/reconnect cycles to the server.

Normally, this is a good thing, less network traffic & noise. However when a client moves networks and the DNS response changes, this is a problem.

When my client moves from home WiFi to LTE, the IP response for the DNS changes from and internal IP address to the public facing WAN address. If I start ATAK while I'm connected to home WiFi, it gets the DNS response for the internal IP address of my TAKy hosting. As soon as I move to the LTE network, this no longer is valid and while ATAK tries to reconnect periodically, it never performs a DNS lookup to get the latest response. Thus, my ATAK client always shows offline. The same occurs if I start on LTE and move to home WiFi.

Note: this only occurs for me since I'm hosting the TAKy server. ATAK clients that are never on MY home WiFi have this issue and they can roam between LTE and THEIR home WiFi with out issue. This is because the DNS response while on LTE and on THEIR home Wifi is always the same.

Work around

If you go into the Settings of the ATAK client and disable( with the check box ) the server connection and then enable the connection, ATAK will perform another DNS query and get an updated response for the IP address of the TAKy server. This will then restore connectivity while on the LTE network.

#TAK #TAKy #ATAK #iTAK #DNS #hosting

Uniden recently provided a couple firmware updates for the SDS scanners. One of stated improvements was better reception of digital voice modes. Uniden didn't really clarify that statement, but on forums its believed to improved low signal performance.

I can confirm that for me, at a particular spot, on my particular SDS with my antenna hub antenna arrangement for UHF. I saw marked improvement on low signal DMR traffic. I was always able to receive it previously, however it took a while for the SDS to lock on. Coming back to that signal, I could tell the SDS locked on to the signal faster and this time started receiving a second site the organization has that is certainly obscured by terrain, when prior I could never receive it.

So, for me, the SDS firmware is a marked improvement when listening to low signal DMR.

On the topic of the SDS and weak signals, came across this video. https://www.youtube.com/watch?v=Z5bLbDeudIE While I don't have an R8600( I dream of one ) I was impressed with the comparison, and was impressed with the SDS200 performance on such a signal.

#SDS #Uniden #Scanning #Radio

I recently came across this forum post, https://forums.radioreference.com/threads/rubber-ducked-db-gain.469533/

The discussion that a typical rubber duck gain is somewhere in the -20 to -10db range confirms a lot of what I already knew from a practical sense. It also lines up with my findings for the Antenna Hub https://strategicengineering.dev/antennaHub/

The antenna hub antenna doesn't have positive gain like a large vertical or yagi antenna. Its more that a stock rubber duck antenna has negative gain.

#Radio #AntennaHub

On Uniden scanners when the modulation of a channel is specified as “Auto” the scanner will do its best job to demodulate it with everything its got. However, if the Modulation is set to something specific, it will only recognize that channel if the modulation matches. If the channel is set to DMR, it'll only match when a DMR signals comes through. If the channel is set to Analog however, it'll match everything but only pass the FM audio. So if a digital voice mode, like DMR, is received, the channel will open up but just play you the “hammer” FM sound of the DMR signal.

This same behavior extends to Systems. If the System type is specified as something other than Conventional, It must match.

I've been scanning a system that used to be a conventional analog system. They have since upgraded to a DMR network. The conventional system( assuming modulation is set to auto ) will still scan it just fine, show that its DMR, and even expose the TGID & CC to the user and software( Ex: ProScan ). However, when you try to program a specific DMR System for it. You must have all the parameters just right or it won't work .

A similar system in the area changed from conventional to MotoTRBO Capacity +, Single frequency. The new system has to be programed as MotoTRBO Trunk instead of DMR One Site to get the scanner to recognize it.

#Uniden #Scanning #Radio #DMR

We've added this blog to the site. We'll announce interesting observations and announcements here.