DSD FME

[n5pwp]

I'm sure it must just be a lack of knowledge about DMR Cap+. I set up a site here using the Cap+.csv example file. I don't see a CC so I'm curious how the system knows where to go. It looks like it just rotates around all of the frequencies. I watched and saw activity on one of the frequencies but the red line wasn't on that frequency so it missed the transmission.
Here is the entry in RRDB
DMR Cap+

Here is my springISD.csv file

LSN(dec),frequency(Hz) (do not delete this line or won't import properly)
-1,151985000
0,151985000
-1,151715000
0,151715000
-1,151497500
0,151497500
1,152870000
2,152870000
3,153020000
4,153020000

I don't see a CC so I don't know how it coordinates where to go. It looks like it tries to hold on the Rest ch. but then it hops off to another frequency.

Mike

 

[lwvmobile]

At 2/4 MHz they sound the same. At 3 MHz there is no audio but I can see the signal on the spectum/waterfall.

Seems more like an issue between your device, driver/API, and SDR++, and not an issue with DSD-FME, or indicitive of using an RTL dongle at 2.048 Ms.

Here is my springISD.csv file

Yeah, those LSNs aren't enumerated correctly, can't use 0 and -1 for values like that. Needs to be sequential LSN values on a Cap+ system.

Also, the link you provided is to a Connect Plus system with different frequencies, which does have the correct LCN listing (Use LCN on Con+, LSN on Cap+)

Maybe something like this:

LSN(dec),frequency(Hz)
1,151985000
2,151985000
3,151715000
4,151715000
5,151497500
6,151497500
7,152870000
8,152870000
9,153020000
10,153020000

No idea if that's the correct order, but the frequencies should be in pairs like this on Cap+

 

[n5pwp]

Seems more like an issue between your device, driver/API, and SDR++, and not an issue with DSD-FME, or indicitive of using an RTL dongle at 2.048 Ms.


Yeah, those LSNs aren't enumerated correctly, can't use 0 and -1 for values like that. Needs to be sequential LSN values on a Cap+ system.

Also, the link you provided is to a Connect Plus system with different frequencies, which does have the correct LCN listing (Use LCN on Con+, LSN on Cap+)

You must've gotten to my post before I corrected it. The link now is correct. I checked to make sure. I will try what you suggested. I looked at the log.ans file and this is what I see:

Capacity Plus Channel Status - FL: 3 TS: 0 RS: 0 - Rest LSN: 1 - Single Block
Bank One F80 Private or Data Call(s) - LSN 02: TGT 60000;
LSN 01: Rest; LSN 02: 60000; LSN 03: Idle; LSN 04: Idle;
LSN 05: Idle; LSN 06: Idle; LSN 07: Idle; LSN 08: Idle;
It looks like the Rest ch is #1.

Maybe something like this:

LSN(dec),frequency(Hz)
1,151985000
2,151985000
3,151715000
4,151715000
5,151497500
6,151497500
7,152870000
8,152870000
9,153020000
10,153020000

No idea if that's the correct order, but the frequencies should be in pairs like this on Cap+

I sorted them into ascending order. It seems to hang on the Rest channel longer (151497500) but eventually it breaks away and starts looking for the CC/Rest ch.

Its amazing what RRDB considers confirmed.
Mike

 

[lwvmobile]

I sorted them into ascending order. It seems to hang on the Rest channel longer (151497500) but eventually it breaks away and starts looking for the CC/Rest ch.

You may need to increase the trunk hangtime so that it'll hang around a little longer. use -t 2 or -t 2 to increase from 1 second to 2 or 3 seconds. Cap+ beaconing can be programmed to different values, sounds like it may be CC hunting when it doesn't need to.

Its amazing what RRDB considers confirmed.

Well, I wouldn't be too quick to jump the gun on that. Probably worth more observation, testing, and confirmed tuning to correct LSNs before making a determination like that. I've been quick to jump the gun a few times assuming data entries were B.S., on here only to find multiple errors on my own part.

EDIT: Looking at that system, it does have the LCN/LSN values as 0's and -1's, so that probably means those values were never confirmed. Again, you know, can't confirm stuff that people don't test out and submit information with data to back it up, so if its like that, its because nobody saw it and said, "Hey, I need to let these guys know that's wrong, and maybe I can figure it out and contribute".

 

[lwvmobile]

Well, looking at that image now, I think those may be single frequency site Cap+ systems, they all seemingly have different Color Codes(again, something to test and verify). If the rest channel never goes above 2, then its most definitely a single frequency system. Those aren't that uncommon, I guess people use them with the idea of expansion in mind, and since its Cap+, they have some pseudo trunking features without loosing a voice path.

 

[n5pwp]

I let it run for a while and now it seems to be staying on the Rest channel. It's a school district so when the buses start running in the morning I'll see if it actually tracks the channel map.

 

[n5pwp]

Looks like everything is fine with the Cap+ site. The map has been worked out.

Now I'm on another CapMax TIII site. We've been saying the rule of thumb is that the channels are laid out in ascending order. The CC should be at the top of the list. Which would imply it would be the lowest frequency. The system I'm working on now seems to have 2 CCs. One is in 3rd place in the list and one is at the end of the list. It also seems to be carrying LRRP mapping info. Do i still list them in ascending order or do I lock both CC's at the top of the list? Also, what does DSD-FME do with the location data other than display them as text on the window? I haven't seen anything about mapping locations. DSDPlus FL does that.

I've managed to get a couple more systems added. But I have found a LOT of systems that seem to be gone. No activity what so ever.
Mike

 

[grosminet]

thanks for answer fir capacity +.

 

[ki4hyf]

those are ticks ``` (the key to the left of the 1 key on the top row), not single quotes ''' , just run make if make -j `nproc` doesn't work.

Not trying to be the syntax police, but "back-ticks" to encapsulate a command are deprecated. The preferred method is to encapsulate with $(command here).

 

[lwvmobile]

Now I'm on another CapMax TIII site. We've been saying the rule of thumb is that the channels are laid out in ascending order. The CC should be at the top of the list. Which would imply it would be the lowest frequency.

I've never said the CC frequency should be at the top of the list. I've stated that its optional to put the frequency at the top of the csv file (so you land on it faster) as a bogus channel number. Adding the correct channel number in the csv file with that same frequency is perfectly fine to do. I have several csv files where I've assigned the main cc frequency at the very top but with an arbitrary channel number that doesn't belong to the system at all, and later on, have it listed again as its actual correct LCN number.

The system I'm working on now seems to have 2 CCs.

Not quite sure about that. While DMR has a method to employ two TSCC channels (one for Cat A and one for Cat B) I don't know if those are actually used often, at all, or not. I sounds more likely that its two different systems there. What is the site information and CAT on both of those control channels? If it is an instance where there are two TSCC for that one site, then you may need to remove the LCN of the second CC and let that be decoded in a separate instance. I really don't know if a dual TSCC setup would otherwise share the opposite timeslot of one of the CC channels for voice calls from the other cat (if that makes any sense).




Before we jump down that rabbit hole though, let's just look at the site branding/net id, site id, and category (c_aloha_sys_parms in the log) and see what each control channel says.

 

[lwvmobile]

Not trying to be the syntax police, but "back-ticks" to encapsulate a command are deprecated. The preferred method is to encapsulate with $(command here).

I'm gonna back tick you in a minute . So...what command should be used instead of make -j `nproc` -- I need it used in a sentence, please.

 

[ki4hyf]

I'm gonna back tick you in a minute . So...what command should be used instead of make -j `nproc` -- I need it used in a sentence, please.

I think the accepted syntax would be "make -j $(nproc)". I do hope things will quickly get back to "normal" for you soon. It seems like some people think hurricanes are "normal" for Floridians. Thank you for your awesome work.

 

[n5pwp]

I've never said the CC frequency should be at the top of the list.

OK, thank you for the clarification. As it turned out I went ahead and just left the CC frequency in its proper spot in the list and the system trunk tracks just fine. When I saw the template for the csv file I 'assumed' that was the proper structure.

While DMR has a method to employ two TSCC channels (one for Cat A and one for Cat B) I don't know if those are actually used often, at all, or not. I sounds more likely that its two different systems there.

Well, I've gone back to re-visit the 2 CC systems and it appears that it is an issue with RRDB not updating the database. It seems that over time 2 frequencies were reported to be CCs but on monitoring now it seems there is no signal on one. The CC frequency was updated without notifying the RRDB contact to let them know it had changed. I suppose that would be my cue to let the administrator know that it has been changed.

The only other thing I found was a system with a CC and a frequency for reporting LRRP location data. I rechecked and it appears your program allows the capture of that data to a file and then it can be fed to another program.

The NXDN sites seem to be a real bear to get working. Apparently, they're doing a lot of scrambling (I've seen the 'Scrambler' text show). Most of the time the audio is just jibberish. I found the toggle for muting encrypted audio. Sometimes it works sometimes it doesn't. Which leads me to believe that if you just have a weak signal or marginal signal it sounds like its scrambled but it's not so the mute doesn't work.

I've got several different systems mapped out now. I have to figure out how to jump from system to system and be able to issue the appropriate start command. Which raises a question. I have been changing the '-f' parameter on the start command. I can also change what type of system to decode from the esc menu.It looks like the menu can override the start command. so I could just use:

dsd-fme -i tcp -U 4532 -T -N 2> log.ans

Then pick the protocol from the esc menu, right? Of course, then you have to change the '-c' and '-G' parameters to go with the system you're on... Nevermind.
Mike

 

[lwvmobile]

The NXDN sites seem to be a real bear to get working. Apparently, they're doing a lot of scrambling (I've seen the 'Scrambler' text show). Most of the time the audio is just jibberish. I found the toggle for muting encrypted audio. Sometimes it works sometimes it doesn't. Which leads me to believe that if you just have a weak signal or marginal signal it sounds like its scrambled but it's not so the mute doesn't work.

Use Squelch with NXDN, it'll clean up a lot of the false sync patterns and decoding errors. A lot of that can probably be attributed to bad decodes. Unfortunately, NXDN uses a very short frame sync word, so I've had tons of issues trying to gate out bad framesyncs, and this is actually a lot better than it used to be, but even still, bad sync will get through and bad decodes will occur. If they really are using voice scrambler though, good luck with that.

The only other thing I found was a system with a CC and a frequency for reporting LRRP location data. I rechecked and it appears your program allows the capture of that data to a file and then it can be fed to another program.

Yeah, in Linux, you can use QGIS and open that map file (preferably after you've generated a lrrp.txt file) and it will plot those points for you. Alternatively, you can copy and paste the lrrp.exe file and its config file into your running directory and launch that with Wine, and it'll do the same thing.

I've got several different systems mapped out now. I have to figure out how to jump from system to system and be able to issue the appropriate start command. Which raises a question. I have been changing the '-f' parameter on the start command. I can also change what type of system to decode from the esc menu.It looks like the menu can override the start command. so I could just use:

If you are doing trunking then you'll just need to stop and start each time. I don't have a way to 'site load' or anything while its running, and presenting a little directory listing menu in ncurses would be way mode coding gymnastics than I'm honestly going to want to put into it. I just don't see it being worth the effort in the current project, especially when you can just make multiple .sh files and run them when you want to move from one system to another.

 

[n5pwp]

Use Squelch with NXDN, it'll clean up a lot of the false sync patterns and decoding errors.

I saw you recommend that to another user so I have been using the squelch.

you can just make multiple .sh files and run them when you want to move from one system to another.

That was my solution. I guess you could create a script that would be a collection of calls to different system scripts.

My next task is setting up some P25 TRS. I have OP25 running on a RPi now it seems to do a good job. Let's see how DSD-FME does with them.
Mike

 

[n5pwp]

You knew it was coming.

So, I copied the start command out of trunking.sh for the P25p1 Simulcast. The system I'm trying to track is a Simulcast site.

TXWARN Site: 1-14

As you can see there are 2 CCs. The main one is 774.43125. I start DSD-FME up and set SDRpp on the main CC. I've tried all 4 combinations for P25 p1/p2 C4FM/QPSK. None of them provides a complete decode. Yes, when I was using the P25p2 I did enter the p2 parameters. On the DB page for the site it says it is Phase 1,2. The phase 2 start commands didn't give good decodes so I went back to phase1 C4FM and QPSK since the DB says it is a simulcast site.

This is my start command:

dsd-fme -i tcp -U 4532 -f1 -T -mq -F -N 2> log.ans

I used the -F because I saw a bunch of FEC errors. But, i did try it without that parameter. After a while running it finally picks up the WACN/SysID and NAC. It shows channel calls at the bottom of the Call History but there is no audio. I didn't see in your samples in the trunk.sh file a '-C' or '-G'. Is there supposed to be a channel map for P25? I didn't see a template for P25 in your examples directory so I assumed it didn't need one. I don't remember it needing one in DSDPlus. I seem to remember that the program would build a map from what it got from the CC.

I'm not sure what is going on. I just looked again and now DSD-FME is jumping between the two CC frequencies. I look at OP25 (my Pi based scanner) and it is happily decoding into audio for that same system.

I thought I remembered from earlier in this thread that you said you didn't have many or any P25 systems so it is hard for you to troubleshoot them. If you want I can try to grab an audio file of the process here and send it to you.
Mike

 

[lwvmobile]

So, I copied the start command out of trunking.sh for the P25p1 Simulcast. The system I'm trying to track is a Simulcast site.

If its simulcast, it may or may not handle so well. I'm tending to lean toward the latter.

I've found for P25 QPSK, you'll want to use 12,000 BW and also, toggle on the low pass filter in SDR++, that really seems to help.
If its Phase 1 and Phase 2, you'll want to use the -ft switch instead, and honestly, I'd leave off the -F for P25.

dsd-fme -i tcp -U 4532 -ft -T -mq -N 2> log.ans

Anyways, it may take a moment to fill in the iden values and get good net_sts_bcst so it can descramble phase 2 frames, so it won't be availble to tune to channels until then. Just depends on how bust that system is as to how fast it can fill in the iden values and net info.

If those things don't get it going sufficiently, then its most likely the simulcast. DSD wasn't originally written to handle simulcast very well, and I haven't done anything to aid it, I honestly just need to re-write the demodulator, or externalize it to a separate program that can do that and just send symbols to dsd-fme to decode.

Also of note, Phase 2 audio 'may' be choppy in the audio_work branch if dual voices are present. I started to rewrite portions of the audio backend, and haven't figured that one little thing out yet.

 

[n5pwp]

Since it appears that DSD-FME has issues with P25p2 and simulcast systems have you considered checking out Osmocom's or Boatbod's OP25. They seem to have mastered those protocols

Open Source Osmocom OP25

I don't know if the specific code is here but since it is Open Source you might be able get some ideas about how to implement it.

Of course it goes without saying (but I'll say it anyway) I understand you're still recovering from Idalia. So I know you have other pressing issues right now. Something for the future.
Mike

 

[n5pwp]

I've started testing other P25 systems in my area and if it is a P25p1 non-simulcast it seems to do every bit as good a job as OP25. Like you said be sure all filtering or signal modification is turned off. I had de-emphasis on and as soon as I unchecked it the audio was perfectly clear.

Now to see if it will work with a -G groups file and set-up blocking/whitelisting of TGs.

Nice job.
Mike

 

[n5pwp]

OK, to answer my own question. No, the P25 command doesn't seem to allow group.csv files. When I issue the start command I get the error "Unable to open group file 'test.csv'". I used the example 'group.csv' and configured it with

2914,B,MCSO2_Disp

But, I did find the DSD-FME with the -ft parameter makes a nice hunting tool. I went CC crawlingand looked for P25 CCs and when I found one I launched the start command

dsd-fme -i tcp -U 4532 -ft -T -mq -N 2>log.ans

Give it a few seconds and it fills in all the information about WACN/SysID/NAC CC frequency RFSS/Site numbers and it tells you if it is P25p1 or p2 and if it is Simulcast or not (QPSK for Simulcast and C4FM for non-simulcast. Also, thanks to lwvmobile I learned that the bit rate will toggle from 4800 for phase 1 and 6000 for phase 2. Probably everybody knew that. but, I didn't.

I found a new system while exploring and thought I was really on to something. It decoded pretty well. I then went through the 'log.ans' file with grep and found all the frequencies that the system uses. I then went to RRDB and did a frequency search for all systems in the area and , awww, it was a known system. So much for my safari.
Mike