Is this simulcast distortion? Baltimore City on Unitrunker/DSD

[thedrizzle]

My head is swimming in radio terms I can't quite grasp. Looking to bounce my situation off of people smarter than I; thanks in advance for your time and help.

For the past year I have been running a private implementation of a SDR system that monitors Baltimore City Police & Fire system (system link: https://www.radioreference.com/apps/db/?sid=6906 ). I am just outside of the city, in NW Baltimore county, and I am in a basement apartment with only one room that faces the towers. This is to say, all the radio towers of this system are all within a 45 degree slice from where I am. I can't really discriminate which tower I point to.

On the Hardware side I have the following: Single 800mhz Yagi Anteanna -> CM3418 8-port distribution amp (with power connected) -> RTL-SDR (x 7) -> USB Hub (x 2) -> Quad-core, Intel i5 PC. On the software side I have Unitrunker v1 -> (odd numbered Virtual Audio Cables) -> DSD Fast Lane (x 6 instances) -> (even numbered VACs) -> Trunking Recorder Beta.

Over this past year, I have been learning as I go. I have a good background in computers and networking but near-zero skills in RF (but growing). I have gotten to a point where the system in running okay, but it has good days and bad days. By rotating the yagi around I get varying degrees of okay, but I have never been able to get it to 100% good. I posted here last year about how I was sure it wasn't SimuDist, and was deep in denial, but I am now to a point where I think I have looked at everything else (to varying degrees of "looked at") and I'm being receptive to chalking it up to SimuDist.

I have looked at a lot of the posts and links from this jump-off page https://wiki.radioreference.com/index.php/Simulcast_digital_distortion , so I kind of have an idea of what I am hitting, but looking for clarification/confirmation.

The biggest manifestion of pain I get is that it seems for each transmission that gets a voice VCO pointed at is has about a 30-50% chance of not locking on right. Another way to say this is a transmission entry is either really good, or really choppy. And a xmission that starts bad will stay bad the whole transmission and a good one will stay good. No call will change from good or bad mid-call. Seems almost(?) like it locks on incorrectly and can't correct mid-call.

Also, I can use Uniscope and point it to one of the odd-numbered VACs and see the eye pattern. In watching the pattern I can see the big difference between a good lock and a bad lock. Good xmissions have a very clear pattern, and the bad ones are super fuzzy to the point where you can barely make out the shape. I've looked for commonalities between the good and bad ones, and there is none. A dongle/stick that gets a crappy lock/xmission could very well have a crystal clear xmission the very next time. Sometimes on the same conversation/talkgroup. It seems like a complete dice toss every time it assigns a VCO to tune in a talkgroup.

I could write pages more (and might if someone asks a relevant question), but I'll keep the summary short at this point. I am also aware this is a topic that can generate disagreement so I will try to steer away from any questions like that.

General questions:

1 - Does this fit the profile of SimuDist? In the articles I read linked off of that wiki page, there was mention that it seems to flake out on the stronger/louder signals voices. I have noticed this. Where a lot of the chop/break-ups happen during stressed sylables. Like "P"s and "T"s can cause a momentary dropout.

2 - Is there any possible way I can 100% be sure this is SimuDist and not something else? Or is this one of those situations where it is a diagnoses made when everything else is excluded? I sooooo wish there was a log output or something that confirmed this. I do not have the radio chops to be sure it is *not* something else like gain or squelch, or environmental, etc.

3 - I started installing Ubuntu and OP25 on a test PC a few weeks ago, and got it to the point where it would see the control channel, but i couldn't get it to even try to switch to a voice channel. I then put that harddrive on a shelf and gave up because my main system was doing okay at the time. Back then, my system was running okay, with only maybe 10-20% of xmissions getting heavy choppiness. Last few days, after much antenna aiming attempts, I get about 30-40% crappy entries. (Sidenote, but its kind of funny that after trying different antenna aiming the good calls are a ton more clearer, but the bad calls are more often and worse quality; to the point where they are silent instead of super choppy.) Would OP25 be helpful and overcome these issues if they are SimuDist? Would it give me more information to help verify what is the cause?


Unitrunker question:

4 - The wiki entry above mentions changing AGC and squelch and other such settings on a scanner. However, it doesn't mention this under the section for SDR. Does anyone know if changing these setting on the VCOs would be worthwhile, or are these settings ignored for digital signals on Unitrunker?


In closing, this is frustrating me so much, and I wish I knew more than I do so that I could better describe what I am experiencing. The system I am trying to monitor is super, super busy so going to an actual hardware scanner is not really an option, since I would miss so much traffic. Me and my few users love the possibility of having an archive of the comms to reference. I'm not adverse to spending some money to get to where I want to be, but I'm just not seeing the path forward that gets me the archive ability with clear reception. I have small hopes that OP25 + Trunk Recorder will be very close to what I currently have, and might overcome the issue. Can anyone confirm that this might be worth working towards? Please help me learn to fish, not looking for someone to do it for me. This was a lot to type, please let me know if I can clear anything up. If it helps I can send privately a link to my Trunking Recorder page.

Thanks,
Dan

 

[thedrizzle]

And then I get home and move the antenna around while watching the Uniscope pattern and I found a spot that makes all my troubles go away. It sounds beautiful now, but I've been here before. I won't touch it, but it will only last for a little bit it seems. In that way its almost more frustrating these moments of the clouds parting. My questions still stand, but maybe this helps rule out SD? Takes the stress down a notch for the time at least.

 

[jcook11]

It is most likely simulcast distortion. Have you looked at SDRTrunk? If you can't get OP25 working give it a shot. Works in Windows too, and much easier to set up (no virtual cables or any of that junk). Both OP25 and SDRTrunk properly decode simulcast if you select the right option, because they were designed to do that. SDRTrunk only does Phase 1 at the moment but looks like that is fine for your system.

 

[slicerwizard]

It's pretty much a given that the system is using phase shift keying with an amplitude component. With Unitrunker using FM demodulation, it leads to decoding problems any time the signal gets weak or two simulcast towers come in at similar strengths. FM demodulation is the real problem; your fixes (antenna aiming, etc.) are band-aids, but they're all you've got unless you use other software.

 

[thedrizzle]

System remains stable and crystal clear with new antenna position. I still remain skeptical it will remain so, but am enjoying it for the time.


Jcook,
I've really latched on to the Trunking Recorder software. Its is wonderful, and perfect for what I want to do. I worked backwards from there and locked in to Unitrunker+DSD. My understanding is that Trunking Recorder is a port or very similar to Trunk Recorder which requires an OP25 backend. So in my mind, in order to get a webpage that allows browsing historical traffic I need Trunking or Trunk Recorder. I looked at SDRTrunk and it looks amazing and super flexible. However I didn't see any equivalent frontend/GUI for SDRTrunk that works similar to TR.

I did at one point upgrade to Unitrunker v2 which can do the voice decode and drop the VAC and DSD stuff but rolled back due to some random issue. I think if I can get stable I'll look to upgrading up to UT v2.

Slicer,
I didn't realize the signal has both AM and FM components and that UT only looks at one of the two. Good information and helpful to get me to a place of better understanding. I've tried a few times to understand the information at this link LSM 101 and I think your information might help me make more sense of it.

 

[slicerwizard]

Well, that page starts out by pointing out the AM component...

Note that in contrast to a constant-magnitude FM signal (in which all of the energy would be confined to the unit circle), we see that the signal passes close to the (0,0) origin while in transit between constellation points. In the complex representation shown here we can clearly see the amplitude variations; when the signal is near the (0,0) origin there is much less transmitted power than when the signal is near the circumference of the circle.

...we also include (in red) a plot of the signal magnitude-squared. In simple essence the green line is the output of the FM discriminator, and the red one is a plot of the signal's amplitude (AM)

 

[KA1RBI]

Well, that page starts out by pointing out the AM component...

Wow, that page is an oldie, but in this post I just wanted to clarify some terminology that I've used in the past that could and perhaps should be clarified...

In regular broadcast AM the transmitted signal can be broken out into multiple components. For our purposes we'll break it into two separate pieces, the carrier itself and the modulation (sidebands). In broadcast AM the carrier's amplitude is unvarying; the variations occur only in the sidebands. During periods when there is no modulation the RF carrier is still present and has exactly the same strength as during periods of 100% modulation.

The situation for "LSM" is different; there the carrier itself varies in strength and (depending on the exact secret sauces present at any given instant) the RF signal can vanish entirely during a portion of each signalling period. The exact instant when this occurs will not necessary be in phase across all of the transmitters in the simulcast ensemble (as perceived at a receiver). The result is known in the vernacular as "simulcast distortion". In PSK this is mostly irrelevant since we need only sample the signal at the peak-power point and we can mostly ignore the parts where the signal may vanish.

So the point is that "AM" may not be the best way of talking about when happens in "LSM", since the LSM RF carrier amplitude itself varies, unlike in broadcast AM where the RF carrier doesn't vary in strength. If this prior usage of "AM" was less than accurate, I have been as guilty as anyone...

Incidentally, for more info about the LSM secret sauces (conceding that this murky issue was known only secondhand by observation, not by inside knowledge), you might look at my "LSM page 2" page which is at
LSM Gallery - Page 2
- and even that page is years old now, and only reflects what had been uncovered as of the date it was posted...

73

Max

Edited to add: one of the key US patents that appears to describe (some of) the LSM secret sauces (modulo the usual obfuscation) is 6,061,574

 

[boatbod]

3 - I started installing Ubuntu and OP25 on a test PC a few weeks ago, and got it to the point where it would see the control channel, but i couldn't get it to even try to switch to a voice channel. I then put that harddrive on a shelf and gave up because my main system was doing okay at the time. Back then, my system was running okay, with only maybe 10-20% of xmissions getting heavy choppiness. Last few days, after much antenna aiming attempts, I get about 30-40% crappy entries. (Sidenote, but its kind of funny that after trying different antenna aiming the good calls are a ton more clearer, but the bad calls are more often and worse quality; to the point where they are silent instead of super choppy.) Would OP25 be helpful and overcome these issues if they are SimuDist? Would it give me more information to help verify what is the cause?

OP25's demodulator does work very well locking on to signals that regular scanners have trouble decoding. I'd encourage you to pursue the config issues a little further; it's really not that hard if you have a little assistance to point you in the right direction.

If you feel like PM'ing me your startup script and contents of trunk.tsv then I'd be happy to take a look and see if there are any obvious omissions. A link to the appropriate RRDB trunked system entry would also be useful.

 

[KA1RBI]

It seems the "LSM Page 2" link was something of a non-sequitor, as there are actually (at least) three pages I've done on this topic. I'll have to plead C.R.S. inasmuch as it has been years since these pages were put up. So to set the record more straight, here are all three links

LSM Gallery
LSM Gallery - Page 2
LSM 101

Max

 

[maus92]

System remains stable and crystal clear with new antenna position. I still remain skeptical it will remain so, but am enjoying it for the time.


Jcook,
I've really latched on to the Trunking Recorder software. Its is wonderful, and perfect for what I want to do. I worked backwards from there and locked in to Unitrunker+DSD. My understanding is that Trunking Recorder is a port or very similar to Trunk Recorder which requires an OP25 backend. So in my mind, in order to get a webpage that allows browsing historical traffic I need Trunking or Trunk Recorder. I looked at SDRTrunk and it looks amazing and super flexible. However I didn't see any equivalent frontend/GUI for SDRTrunk that works similar to TR.

I did at one point upgrade to Unitrunker v2 which can do the voice decode and drop the VAC and DSD stuff but rolled back due to some random issue. I think if I can get stable I'll look to upgrading up to UT v2.

Slicer,
I didn't realize the signal has both AM and FM components and that UT only looks at one of the two. Good information and helpful to get me to a place of better understanding. I've tried a few times to understand the information at this link LSM 101 and I think your information might help me make more sense of it.

UT2 will not solve your SD problems as far as DAQ is concerned. Although it deodes cch data perfectly and *can* decode P25 Phase 1 audio, its audio performance on P25 simulcast / LSM systems like Baltimore County and Baltimore City, is unsat in my experience. OP25 however, does a very good job. Take boatbod up on his offer.

 

[thedrizzle]

Thank you all for the great info. I've seen a good number of helpful posts from BoatBod in the Maryland sub-forum, so especially glad to hear from him/you. Also thanks KA1 for the links. To be honest, 90% of the info goes over my head but the 10% is helpful and I hope to come back to them later on when Im armed with better understanding.

My previous effort at OP25 was only a few hours in duration, and ended up just unplugging the hard drive and setting it aside. I don't recall a lot of what I did or didn't do, but I do remember working towards, and getting the beautiful 4 level line plot that I was hoping to see. But then after that I wasn't able to actually get it to act on the signal.

There seems to be a very large consensus here that OP25 is the way to go, so I'm planning to dust off that PC and move the SATA cable back to that hard drive with Ubuntu and my short OP25 install. Once I get re-acclimated to where I was, I very much anticipate taking you up on your offer of assistance if the blog posts and how to guides that I can pull up don't get me there. I am subscribed to the UT2 beta Google Group mailings, and hope some day maybe they'll work on this issue there.

My current UT cycle seems to be: 1. Get all pissed when the signal on the UT system gets bad, 2. Reach out and/or plan work for my next block of free time. Jiggle antenna around. 3. When free time arrives either UT system has cleared up by then or I discover a need to order a part that will arrive when I'm busy again. and then after some time, back to #1.

Thanks again, I'll let everyone know where I end up.
(edit to add)
You know what I didn't fully read who I was responding to. I've seen a lot of good information from you, Maus, also in the Maryland sub-forum. Thanks.

 

[thedrizzle]

Ok I picked this back up finally. I spent past 5 hours pounding away at it. Got OP25 fixed after about 2 hours and it sounds AMAZING! The issue was I had some of the examples still in my trunk.tsv with the bad assumption it would work through those to my line 6 system. Removed them and made my system #1 and boom. But my main/production PC is running UniTrunker->DSD+->Trunking Recorder, so now I need to get Trunk Recorder working for this test box to replace.

The last 3 hours were spent trying to get that going. I'm beat and have to get some sleep but want to throw this text file up with my configs and outputs to see if rings any bells. If I get time tomorrow I think I'll start a new thread but wanted to get this out there. Thanks ahead of time. I do know for a fact 853.875 is the right CC. Works in op25 and my UniT system. Kinda did some bad math to get the center freqs so those are weak. Attached file is bad in notepad but looks good in wordpad. Here it is shared on my Gdrive RadRef - Google Drive

Here is the db entry for the system: https://www.radioreference.com/apps/db/?sid=6906

 

[thedrizzle]

Please disregard the above.

I ended up adjusting config.json to the following and it clicked and is recording now. I think the gain was too low was a main thing. Still tweaking but didn't want some nice person wasting time on the above.

{
"sources": [{
"center": 853000000,
"rate": 2048000,
"ppm": -1.5,
"gain": 300,
"digitalRecorders": 6,
"modulation": "qpsk",
"driver": "osmosdr",
"device": "rtl=0"
}, {
"center": 851000000,
"rate": 2048000,
"ppm": 52,
"gain": 300,
"digitalRecorders": 6,
"modulation": "qpsk",
"driver": "osmosdr",
"device": "rtl=1"
}],
"systems": [{
"control_channels": [853875000],
"type": "p25",
"shortName": "BPD",
"talkgroupsFile": "bpd.csv"
}],
"captureDir": "/home/dan/recs/"

}

 

[dave3825]

I did at one point upgrade to Unitrunker v2 which can do the voice decode and drop the VAC and DSD stuff but rolled back due to some random issue. I think if I can get stable I'll look to upgrading up to UT v2

Were you using malwarebytes? That's the only program I ever had that reported UT as being bad. I deleted Malwarebytes.

The issue was I had some of the examples still in my trunk.tsv with the bad assumption it would work through those to my line 6 system. Removed them and made my system #1 and boom.

Boatbod gave a pretty detail explanation of the different uses of the trunk.tsv.

Bear in mind there are several different hunting methodologies designed to achieve different objectives depending how you configure trunk.tsv. I'll try to explain the options:

SINGLE SYSTEM
- Configure trunk.tsv with a single line entry and single control channel frequency. NAC=0 is permitted, or you may set the NAC to the expected value.

ROAMING SYSTEM
- Configure trunk.tsv with a single line entry, but a comma separated list of control channel frequencies and NAC=0. The trunking app will lock on to the first active control channel and remain locked on until the signal fades, at which point it will attempt to find a new signal from the given list. This configuration is good for a mobile setup that travels around and moves between systems.

MULTIPLE SYSTEMS
- Configure trunk.tsv with multiple entries, one line per system. Each system needs to have its control channel frequency and NAC specified. NAC=0 is not permitted. Trunking app will tune to a control channel and look for voice activity. If none is found, it will cycle to the next system in the list. This configuration is going to allow you to (partially) monitor multiple systems accessible from a common location. Not ideal for busy systems because hunting will never take place as the control channel is rarely idle.

So even tho those systems in the stock trunk.tsv may not be near you, some of the freqs may be in use in your area. To avoid any confusion, I renamed that trunk.tsv to _trunk.tsv (kept for reference) I made my own trunk.tsv file for each system I listen to and then seperate ones named by system giving me the option to, either read a trunk.tsv with multiple systems, like a scanner, or use a system_named.tsv with just one system. (You removed those entries so this won't apply to you, but it may help others).

But my main/production PC is running UniTrunker->DSD+->Trunking Recorder, so now I need to get Trunk Recorder working for this test box to replace.

Trunk recorder can be tricky to get going but once it's done, it works good. Ran it on Ubuntu 16 and 18 beaver something. Now I have a pi 3b+ and will be doing the Raspbian stretch install one of these days. Trunk recorder has a google group, like Unitrunker V2 has, but there is not much activity there. Google Groups

They also have a Gitter chat room: trunk-recorder/Lobby where they answer questions rather quickly.

Trunk recorder does have some options. Open Mhz, Trunk Player and Audioplayer. See audio player live here .
I use Openmhz for one system (still a work in progress) and Jason's audio player for another that I wish to not stream. I installed lighttpd server and can access my recordings from anywhere I have internet.

The last 3 hours were spent trying to get that going. I'm beat and have to get some sleep but want to throw this text file up with my configs and outputs to see if rings any bells. If I get time tomorrow I think I'll start a new thread but wanted to get this out there. Thanks ahead of time. I do know for a fact 853.875 is the right CC. Works in op25 and my UniT system. Kinda did some bad math to get the center freqs so those are weak. Attached file is bad in notepad but looks good in wordpad. Here it is shared on my Gdrive RadRef - Google Drive

Here is the db entry for the system: https://www.radioreference.com/apps/db/?sid=6906

Your center freq should be 852587500 (9 numerical characters and no decimal point). It looks like yours is set to 8.540480e+08 (854.0480). I take lowest freq, add it to highest freq, then divide by 2.

Can you list what dongle you are trying to use with trunk recorder? I believe the dongles cover about 2.4mhz so you need to figure out, or someone who knows can help, how far does 851.225 to 853.950 span?. I am only good at math after 6 cups of coffee but if I did it right, it's about 2.725 mhz. So if the dongle you use is centered properly, but not covering that systems complete spread, of 2.725Mhz, it will not see the highest and lowest freqs. Hope that makes sense. One system I have fits in that window and that lets me use a nooelec. Another system I listen to is over 2.4mhz so I need to use an airspy mini with that one.

As for this,
(error) [BPD] There is only one control channel defined
You need to list all the control channels in the config.json with 9 numeric characters and no decimal point. You can actually just copy this line to your config.json. Also if you copy it, copy the empty space before it or just use tab to get it to line up in your file.

    "control_channels": [853700000, 853737500, 853875000, 853950000],

Can you copy your config.json file and post it here using the insert <code> your config.json text here </code> feature? You can X out your api number if your using Openmhz.com.

Another thing of importance is the modulation type. That Baltimore system is simulcast with 9 sites as seen here,
https://www.radioreference.com/apps/db/?action=siteFCCMap&siteId=17807

The choices are "qpsk or fsk4" One is recommended for simulcast and one is not. I am not on my pi and do not remember which one is for simulcast. I am sure someone will chime in with the correct answer..

Here are the rest of the arguments with descriptions: robotastic/trunk-recorder

Ok, time for more coffee.

 

[dave3825]

Still tweaking but didn't want some nice person wasting time on the above.

Lol. I started replying around 8 30 and got sidetracked getting my son off to school. Did not see you posted until after I posted. It's all good. I will leave it I guess as it might help others..

 

[thedrizzle]

Thank you a million times. I think I am slightly past that part (but know all to well 5 mins from now I might be be right back there). That's very good information in a field that could use more. Definitely please leave it up

 

[dave3825]

A few months ago I wanted to learn all the op25 and related Linux only software. I asked many questions, and many helped me along the way. I learned a lot in a short time.

 

[thedrizzle]

Current battle:

I have Trunk Recorder working good, I have the Trunk Player working almost-good. However, when I go to play an entry through the browser, the console throws this 404 error:

[2019/01/10 09:11:27] HTTP GET /home/dan/recs/BPD/2019/1/10/9267-1547140269_8.533e+08.mp3 404 [0.05, xxxxxxxxxx:45641]

I can copy the file path from the error and paste it into a "file" linux command and it sees it and tells me its an mp3. So it seems its looking in the right place. Is this a permissions thing? Any thoughts?

-Dan

 

[dave3825]

I , back then was not able to get trunk player going. Now that I know more about Linux I may have another try at it. When I started, my problem was it was not creating .m4a files to upload to OpenMhz.com. The second time around I compiled FFMPEG again and then that worked for me.

Are you trying locally or over the web? If I had to guess, it looks like it might be something with the server portion of your setup.