DSD FME

[lwvmobile]

Also, figured I'd ask, are you trying to use DSD-FME with a Raspberry Pi for the EDACS decode?

 

[leoaln]

RMS varies between 35-55 with agc on. With gain set at 36, 49 or 19, rms is at 10 and under. Very few decodes. I am going to try some antenna work this evening

 

[leoaln]

Also, figured I'd ask, are you trying to use DSD-FME with a Raspberry Pi for the EDACS decode?

I was, but was experiencing lots of freeze ups. I have switched to an i5 laptop running Ubuntu 22.04

 

[leoaln]

I relocated my antenna and running with this command
dsd-fme -fp -i rtl:0:851.15M:0:-2:24:-50 -T -C edacs_channel_map.csv -G harrisoncounty.csv -N 2> log.ans
gets me 110-150 rms andthe audio decode area text turns green and shows about 25% In Level. Every now and then, I get a burst of voice and rms jumps significantly higher when that happens. Still lots of BCH Fail errors in the log

 

[leoaln]

Okay, I'm making some progress.I think. Out of 8 Control Channels, there is traffic on 5 or 6 of them. Can DSD-FME use the edacs_channel_map file and scan the listed frequencies? Or will I have to run each Control Channel as a separate instance?
Also Call Info and Call History is not showing information

 

[lwvmobile]

Okay, so I think what is happening for you is that you are getting those voice calls randomly while DSD-FME is changing frequencies hunting for the control channel, which makes sense if the control channel itself has poor reception, then it'll loose sync and start cycling all channels in the csv file until it finds an edacs or a provoice sync pattern. If you don't have any call history, then that means its on a provoice channel that wasn't tuned to from the edacs control channel. provoice frames that belong to EDACS standard, as far as I know from the limited information I have and samples, don't carry any sort of AFS values on them, or if they do, I've never seen that value.

There is a way to scan, instead of trunk, but you'll want to use a csv file without the primary control channel listed in it, and instead of using the -T option, you want to use the -Y option. The downside of doing that on EDACS/PV is that you won't know the call's AFS value, so you'll have to just know who is talking based off of context of the call itself, and if the system is busy, or has many channels, you'll be missing a lot of calls and/or getting pieces of each call and not a coherent call progression.

 

[lwvmobile]

Also, something worth mentioning, if the signal is marginal, then RTL input using built in rtl_fm doesn't always handle that very well, just really depends on your setup. If you have the option to use either RTL input, or TCP input w/ SDR++, I always tend to go for the SDR++ setup.

I think you may have had some issues getting that setup earlier to use SDR++, but in this case, it's probably worth a shot, that way you can see the signal and determine how weak or strong it is, and SDR++ does a better job at delivering good audio compared to rtl_fm.

I'm terrible at making tutorial videos, but here is a 'demonstration' of using SDR++ and tuning to a couple of EDACS sites, I figure the best tutorials are really just to see what the correct process is, and not somebody rambling forever and not getting to the point.

 

[DaveNF2G]

With TCP input, it seems like this program should be able to connect with FMPx from DSDPlus.

 

[LimaZulu]

Can't remember exactly the case why, but it can't do that. Even if it does, there is no way to control FMPx using DSD-FME.

 

[leoaln]

With TCP input, I show In Level at 80-100%, but I get lots of BCH errors in the log and no voice with the frequency locked on the control channel. That is with either antenna, including the new L-com 906

 

[leoaln]

No voice Beginning of log file
Build Version: v2.1-15-g4a85726
MBElib Version: 1.3.2
Setting symbol rate to 9600 / second
Decoding only ProVoice frames.
Enabling NCurses Terminal.
TCP Direct Link: 127.0.0.1:7355
TCP Connection Success!
Audio In Device: tcp
21:31:10 Sync: +EDACS
21:31:10 Sync: +EDACS
21:31:10 Sync: +EDACS
21:31:10 Sync: +EDACS

 

[lwvmobile]

If you can, make about a 1 minute baseband recording in SDR++ without dsd-fme and I'll take a look at it, see if its an issue with dsd-fme and that system in particular. If you can do that and then upload it, upload it to somewhere that doesn't require user login to download it.

Ufile.io - Upload files for free & share them without registration is a good option if you don't have any other file hosting service in mind.

 

[leoaln]

This is the url for the file

Upload files for free - baseband_851150000Hz_08-24-06_19-08-2023.wav - ufile.io

Download baseband_851150000Hz_08-24-06_19-08-2023.wav for free from ufile.io instantly, no signup required and no popup ads

ufile.io

 

[lwvmobile]

Okay, so, after looking at that baseband file and doing a little work. I discovered that dsd-fme may not always be able to correctly detect which type of EDACS system is in use (Standard/Networked/Extended Addressing) and by default, its set to not start decoding EDACS frames until after it makes a determination as to which type is being used.

I just pushed an update to all branches to allow the user to choose standard/networked with the -9 switch, and now I am getting a good decode on the Control Channel.



Something else I've noticed is that the Control Channel doesn't appear to be on 851.15, but rather on 852.186ish, which I am not sure what PPM you have inserted for the IQ sample, I'm not sure if that carries over when saving a baseband file or not. Site 2 in the RR database shows LCN 2 (the control channel decoded by dsd-fme) as 852.125, but I had to tune slightly out of the way to get to that. PPM may be off by 1 or 2, not sure.

So, you'll need to do a git pull or run the rebuild script and rebuild the latest version and see if that works for you now (remember, add the -9 switch to your startup command). Also, worth mentioning, if you have any analog calls on that EDACS system, you may want to switch to branch 2.1b, I recently added the ability to monitor analog calls and raw audio as well, but its only in the 2.1b and audio_work branches.

 

[lwvmobile]

BTW, you do have analog calls on that system.

13:31:20 Sync: +EDACS  FR_1 [002EAA1FBD] FR_4 [0CCEAA12E0] Unknown Command
13:31:20 Sync: +EDACS  BCH FAIL
13:31:20 Sync: +EDACS  AFS [0x302] [06-002] LCN [08] Digital
13:31:20 Sync: +EDACS  AFS [0x2A1] [05-033] LCN [14] Analog
13:31:21 Sync: +EDACS  FR_1 [FCE0C8907A] FR_4 [FCE0C8907A] Unknown Command
13:31:21 Sync: +EDACS  Site ID [02][002] on CC LCN [02] Standard/Networked
13:31:21 Sync: +EDACS  FR_1 [FC21210262] FR_4 [EF30274BB5] Unknown Command
13:31:21 Sync: +EDACS  AFS [0x302] [06-002] LCN [08] Digital
13:31:21 Sync: +EDACS  AFS [0x2A1] [05-033] LCN [14] Analog
13:31:21 Sync: +EDACS  Site ID [02][002] on CC LCN [02] Standard/Networked
13:31:21 Sync: +EDACS  FR_1 [FC8FFFFC7B] FR_4 [FC8FFFFC7B] Unknown Command
13:31:21 Sync: +EDACS  AFS [0x274] [04-116] LCN [06] Digital
13:31:21 Sync: +EDACS  AFS [0x31B] [06-027] LCN [12] Analog
13:31:21 Sync: +EDACS  Site ID [02][002] on CC LCN [02] Standard/Networked
13:31:21 Sync: +EDACS  FR_1 [FC9FFFFEBA] FR_4 [FC9FFFFEBA] Unknown Command
13:31:21 Sync: +EDACS  AFS [0x274] [04-116] LCN [06] Digital
13:31:21 Sync: +EDACS  AFS [0x31B] [06-027] LCN [12] Analog
13:31:21 Sync: +EDACS  Site ID [02][002] on CC LCN [02] Standard/Networked
13:31:21 Sync: +EDACS  FR_1 [FC2040054A] FR_4 [EF30274BB5] Unknown Command
13:31:21 Sync: +EDACS  AFS [0x302] [06-002] LCN [08] Digital
13:31:21 Sync: +EDACS  Site ID [02][002] on CC LCN [02] Standard/Networked
13:31:21 Sync: +EDACS  BCH FAIL
13:31:21 Sync: +EDACS  AFS [0x302] [06-002] LCN [08] Digital
13:31:21 Sync: +EDACS  Site ID [02][002] on CC LCN [02] Standard/Networked
13:31:21 Sync: +EDACS  FR_1 [FC21210262] FR_4 [EF30274BB5] Unknown Command
13:31:21 Sync: +EDACS  AFS [0x302] [06-002] LCN [08] Digital
13:31:21 Sync: +EDACS  Site ID [02][002] on CC LCN [02] Standard/Networked
13:31:21 Sync: +EDACS  FR_1 [FC8FFFFC7B] FR_4 [FC8FFFFC7B] Unknown Command
13:31:21 Sync: +EDACS  BCH FAIL
13:31:21 Sync: +EDACS  Site ID [02][002] on CC LCN [02] Standard/Networked
13:31:21 Sync: +EDACS  FR_1 [FC9FFFFEBA] FR_4 [FC9FFFFEBA] Unknown Command
13:31:21 Sync: +EDACS  AFS [0x274] [04-116] LCN [06] Digital
13:31:21 Sync: +EDACS  AFS [0x31B] [06-027] LCN [12] Analog
13:31:21 Sync: +EDACS  Site ID [02][002] on CC LCN [02] Standard/Networked
13:31:21 Sync: +EDACS  FR_1 [FC2040054A] FR_4 [EF30274BB5] Unknown Command
13:31:21 Sync: +EDACS  FR_1 [FCE197A5B0] FR_4 [FCE197A5B0] Unknown Command
13:31:22 Sync: +EDACS  BCH FAIL

 

[leoaln]

Okay, I switched to 2.1b and have decoding now, but no voice being sent to pulseaudio.

 

[lwvmobile]

Try increasing the BW to 24000, and use the squelch checkbox if you listen to analog channels, the squelch break is currently the only way I have of knowing when analog channels end when using SDR++

 

[lwvmobile]

Also, what does your channel map look like? Are you using channels for Site 1, or Site 2? That baseband had the CC for Site 2 much stronger (but still kind of meh) at 852.125 compared to 851.15 which was barely there at all, and no way that would be good enough to sync off of and get a good decode.

 

[leoaln]

This may sound elementary but, when a talkgroup becomes active -someone talking- is the frequency at the top of sdr++ supposed to switch to the talkgroup frequency and then switch back to the control channel?

 

[lwvmobile]

This may sound elementary but, when a talkgroup becomes active -someone talking- is the frequency at the top of sdr++ supposed to switch to the talkgroup frequency and then switch back to the control channel?

Yes, that is correct, you should see the frequency in SDR++ change to the frequency that is being tuned to. The Ncurses Terminal should also show a *T* designation by the lcn/group tuned to. You can watch that youtube video I posted yesterday again if you need to for behavior references.

Also, figured I'd ask, are you trying to use DSD-FME with a Raspberry Pi for the EDACS decode?

I was, but was experiencing lots of freeze ups. I have switched to an i5 laptop running Ubuntu 22.04

Also, Just FYI, I just pushed a commit to disable the RTL RMS function on ARM devices due to high cpu usage, so that's why it may have been slow and freezing up. I dusted off my Pi 3B+ last night to test it, and it was chugging samples very slowly and pegging out a CPU core. The upside is that it isn't slow anymore, but the downside is that on any ARM device, the RMS function doesn't work, and by extension, that kills dPMR, NXDN, M17, EDACS Analog, and Raw Analog Audio Monitor. So, its a trade off, but only for Raspberry Pi when its using built in rtl input. Maybe in the future I can figure out a better way to gauge signal strength when squelch is required.