Not that I know of, it is pretty much all or nothing.
DSD FME
- Thread starter lwvmobile
- Start date
Not that I know of, it is pretty much all or nothing.
lwvmobile
DSD-FME
It should mute any encrypted calls just as long as it can successfully decode a VCALL, and you haven't supplied it with a key, and you haven't toggled the mute the the open position.
I would suspect the first one though, which could be that you just need to tweak some settings somewhere to get clean signal, assuming the signal is good enough to get reliable data decoding out of it so that it'll mute when it needs to and so on.
- Joined
- Jan 18, 2005
- Messages
- 736
Can someone explain to me what DME-FME does? I tried seems like years ago I tried to get it
going, just wasn't smart enough. Is there a list of steps on what software has to be started,
and setup? Is it supposed to decode and follow a trunked system? DMR, P25 & NDXN?
SDRPP to DSD-FME via ?
DSD-FME to SDRPP via?
seems there was another program I had to have, a radio control program?
Mil
going, just wasn't smart enough. Is there a list of steps on what software has to be started,
and setup? Is it supposed to decode and follow a trunked system? DMR, P25 & NDXN?
SDRPP to DSD-FME via ?
DSD-FME to SDRPP via?
seems there was another program I had to have, a radio control program?
Mil
Basically it does what other digital decoders do - decodes digital modes 
Yes, it does DMR, P25 and NXDN. One of the main benefits are - it supports windows and linux as well, it allows some types of enryption/scrambler keys to be used, it does trunk tracking (it even has options to do it without external software).
SDRPP to DSD-DME and DSD-FME to SDRPP can be done by tcp connection or by virtual cables (TCP is a preffered one and gives you more options). I like to use it by tcp connection and have multipe vfo's on SDRPP and multiple instances of DSD-FME which allows me to monitor multiple frequencies within the range of my sdr at once.
There is a file included that has multiple examples and explanations on how to run it. There are even a few files, included in the prebuilt windows version, numbered from 0 to 4 to be executed consecutively (after being edited by your desires)
Yes, it does DMR, P25 and NXDN. One of the main benefits are - it supports windows and linux as well, it allows some types of enryption/scrambler keys to be used, it does trunk tracking (it even has options to do it without external software).
SDRPP to DSD-DME and DSD-FME to SDRPP can be done by tcp connection or by virtual cables (TCP is a preffered one and gives you more options). I like to use it by tcp connection and have multipe vfo's on SDRPP and multiple instances of DSD-FME which allows me to monitor multiple frequencies within the range of my sdr at once.
There is a file included that has multiple examples and explanations on how to run it. There are even a few files, included in the prebuilt windows version, numbered from 0 to 4 to be executed consecutively (after being edited by your desires)
- Joined
- Jan 18, 2005
- Messages
- 736
Thanks I'll try to find the windows version and read the txt files. Why I am doing this is that I have a site that is NXDN and FMPABasically it does what other digital decoders do - decodes digital modes
Yes, it does DMR, P25 and NXDN. One of the main benefits are - it supports windows and linux as well, it allows some types of enryption/scrambler keys to be used, it does trunk tracking (it even has options to do it without external software).
SDRPP to DSD-DME and DSD-FME to SDRPP can be done by tcp connection or by virtual cables (TCP is a preffered one and gives you more options). I like to use it by tcp connection and have multipe vfo's on SDRPP and multiple instances of DSD-FME which allows me to monitor multiple frequencies within the range of my sdr at once.
There is a file included that has multiple examples and explanations on how to run it. There are even a few files, included in the prebuilt windows version, numbered from 0 to 4 to be executed consecutively (after being edited by your desires)
has a problem with it, trying to see if its the radios or the software. Thought if DSD-FME decoded it ok then FMPA was the
problem.
Mil
Please consider opening up a thread under a DSDPlus topic outlining what type of problem you are having with NXDN.
- Joined
- Jan 18, 2005
- Messages
- 736
I did.
I use it to decode mainly NXDN and also have a problem with it when using DSDPlus. DSD-FME fiexes my issue. I do have other issues with it but not that irritating. But on top of that @lwvmobile is quite responsive. I provided some info about my issue and he is doing his magik to fix it.
It would be good if that alone is enough. I do experience my issue since DSDPlus was released. Posted it few times, snent mails to the developers, uploaded proof video (which I can confirm they saw).... So many verions later and still not fixed. It wouldn't be so irritating if at least they replied. But when you sent some money then no one is even bothering to answer your questions - not good! Don;t get me wrong. Sitll consider it a valuable piece of sotware but....
But let's not mess up this thread with side questions.
Fair enough, but how about posting your DSDPlus issue somewhere, or if you already have go in that thread and comment on it so I can find it.
Just checking. Any advances in using something like hamlib to control trunking with other receivers than rtl based chipsets?
Still giving FME a go here and there with my IC-R8600.
Raw audio input from the USB audio driver doesn't have the capability of discriminator outputs and the radio doesn't have one.
So using an I/Q SDR program like HDSDR and SDR-Console is the only way I can get any decoding.
Still confused a bit on how to get an input from radio>sdr application>vb cable piped into FME.
Also a bit "dumb" on all of the Linuxesque Windows integrations like TCP in #724.
Actually I've never tried using my radio in Linux. But certainly could use a VM or build a quickie 'nix box no problem.
NCURSES, Pulse Audio. All the things a regular Windows user might be unfamiliar with. How to get a grasp of hot to or if I even need to use them to get a simple, no-trunking (obviously) decode with FME?
Of course unless I use an old version of SDR#. My R8600 I/Q drivers won't work and I just don't have the antenna farm needed to hoist another antenna for an RTL radio. Actually I really don't want one. Although I do have a RSP2.
Is there a guide to get my feet wet to feed an SDR app audio out to VB cable into FME and get it to decode?
I have Fastlane and it just came out with an update. Still. Nothing but RTL/SDRPlay radio and Passive Digital Monitor (discriminator/vb cable from sdr apps) input.
Not being mean. But is there a mental block for enabling the "better" receivers to support these DSD flavors?
Bummer!
Still giving FME a go here and there with my IC-R8600.
Raw audio input from the USB audio driver doesn't have the capability of discriminator outputs and the radio doesn't have one.
So using an I/Q SDR program like HDSDR and SDR-Console is the only way I can get any decoding.
Still confused a bit on how to get an input from radio>sdr application>vb cable piped into FME.
Also a bit "dumb" on all of the Linuxesque Windows integrations like TCP in #724.
Actually I've never tried using my radio in Linux. But certainly could use a VM or build a quickie 'nix box no problem.
NCURSES, Pulse Audio. All the things a regular Windows user might be unfamiliar with. How to get a grasp of hot to or if I even need to use them to get a simple, no-trunking (obviously) decode with FME?
Of course unless I use an old version of SDR#. My R8600 I/Q drivers won't work and I just don't have the antenna farm needed to hoist another antenna for an RTL radio. Actually I really don't want one. Although I do have a RSP2.
Is there a guide to get my feet wet to feed an SDR app audio out to VB cable into FME and get it to decode?
I have Fastlane and it just came out with an update. Still. Nothing but RTL/SDRPlay radio and Passive Digital Monitor (discriminator/vb cable from sdr apps) input.
Not being mean. But is there a mental block for enabling the "better" receivers to support these DSD flavors?
Bummer!
lwvmobile
DSD-FME
Nothing new since the last time we went down the road of how to possible listen to and control your IC-R8600 with hamlib. I'll refrain from rehashing the same things that's been covered multiple times on this, other than to go back and re-read the last answers I provided on this and also to take a look at readme's, instructions, etc.
All I can say, is that its stated right on the front of the Github page. I don't claim to have the easiest to use software, but I also realize that 'easy' and 'familiar' are all relative to each individuals experience and hardware, etc.
I can only work with what I have possession of, I don't own a "better" receiver, so I can't figure out a surefire work flow for you on this one.
There is a TCP and Grepredict(rigctl) plugin for SDR#, its included in the precompiled Windows version zip folder for people who are hardset on using SDR#. Pretty sure that works with older versions, but no idea what the limit is as far as oldest and newest it works with. I don't use SDR#.
Didn't mean to rile you. I guess I'm trying to understand the "mechanism" that allows the RTL/SDRPlay receivers to trunk with FME and DSD+.
A flowchart of sorts would be satisfying.
"Something" is telling them that we are on a control channel. Oh. Here's a voice channel popping up with traffic. Lets bolt over to that and take a listen. Then when it's again idle, lets pop back over to the control channel.
If that is something at all how it's supposed to work.
I mean. There are many applications that interface with SDR apps to tune an I/Q receiver to a particular frequency, mode, etc. I use Orbitron a bit. No issues tuning my radio when a satellite passes in range of reception.
When the next pass comes up. The radio pops over to that freq.
Frequency Manager on older # versions worked good. Before they but their heads up their you-know-whats.
So. What's the deal with RTL based radios. What is the inner workings?
I'm suspecting that a lot of the RTL radio software "devs." are using canned "Lego kit" modules and don't actually program the core inner working of how they do what they do.
And I know very well how dealing with programmers works. If you find the right one with a true interest, you need to treat them like your best auto mechanic.
So. The Windows version is a crippled compiled version of FME. That crippled? Perhaps I did not dig deep enough to find Windows specific tutorials that does away with al of the Linux only stuff. Or just build that Linux box and give it a go that way.
By the way. I live in the boonies with good signals that DSD versions "should work: with. But only ever got anything but very short and garbled voice transmissions sitting on a voice channel. I mean. Using Dream to receive Radio Marti and BBC was fairly easy. But those have continuous voice to do the tweaks to get a decode.
Hello.
My first post on the board here. Hope this is the correct way to start. I tried to find a way to start a new thread, but couldn't. Think it ended up as a message to the florida man.. My apologies if this is bad form.
This is a question about using rtl_tcp with dsd-fme.
Has anyone ever tried to use dsd-fme with rtl_tcp? I've been trying for several days without success.
I have 2 raspberries, one out in the shop hooked with a dongle hooked up to a nice outdoor antenna. A nicer antenna that will fit in the house. The other side is a pi in my house. I launch rtl_tcp in the shop with:
rtl_tcp -a 192.168.0.11 -p 4444 -g 49.6 -f 853.8875m
Seems to work ok, it does say PLL is not locked, so that makes me wonder at bit.. BTW 853.8875 is the local NC Viper tower control channel. p25.
Inside, I launch dsd-fme with:
dsd-fme -i tcp:192.168.0.11:4444 -T -N 2>/dev/null
The program launches but no output is ever produced. I can launch sd-fme -i tcp:192.168.0.11:4444 -T -N without redirection and I see screen output that "control channel lost, searching for control channel". On the pi in the shop, I see sometime like this:
ll+ 201
ll+ 202
.....
this seems to start at 0, and increment sequentially until it gets to about ll+ 502, then it'll sit for a while and start over at 0. I guess it's trying to tune in the control channel, but apparently never finds it??
I tried running rtl_tcp and dsd-fme both on the same pi, taking the network out of the equation, and the result is the same. I tried rtl_fm and it tunes in to the control channel fine. Command was rtl_fm -f 853.8875e6 -s 200000 -r 48000 | aplay -r 48000 -f S16_LE
I can aslo use SDR++ to consume the stream, and it works fine.. So I believe the rtl_tcp pi is working correctly. I'm just not able to get dsd-fme to play nice with it.
Can anyone help? What am I missing here?
Thanks
Russ
K4RCC
My first post on the board here. Hope this is the correct way to start. I tried to find a way to start a new thread, but couldn't. Think it ended up as a message to the florida man.. My apologies if this is bad form.
This is a question about using rtl_tcp with dsd-fme.
Has anyone ever tried to use dsd-fme with rtl_tcp? I've been trying for several days without success.
I have 2 raspberries, one out in the shop hooked with a dongle hooked up to a nice outdoor antenna. A nicer antenna that will fit in the house. The other side is a pi in my house. I launch rtl_tcp in the shop with:
rtl_tcp -a 192.168.0.11 -p 4444 -g 49.6 -f 853.8875m
Seems to work ok, it does say PLL is not locked, so that makes me wonder at bit.. BTW 853.8875 is the local NC Viper tower control channel. p25.
Inside, I launch dsd-fme with:
dsd-fme -i tcp:192.168.0.11:4444 -T -N 2>/dev/null
The program launches but no output is ever produced. I can launch sd-fme -i tcp:192.168.0.11:4444 -T -N without redirection and I see screen output that "control channel lost, searching for control channel". On the pi in the shop, I see sometime like this:
ll+ 201
ll+ 202
.....
this seems to start at 0, and increment sequentially until it gets to about ll+ 502, then it'll sit for a while and start over at 0. I guess it's trying to tune in the control channel, but apparently never finds it??
I tried running rtl_tcp and dsd-fme both on the same pi, taking the network out of the equation, and the result is the same. I tried rtl_fm and it tunes in to the control channel fine. Command was rtl_fm -f 853.8875e6 -s 200000 -r 48000 | aplay -r 48000 -f S16_LE
I can aslo use SDR++ to consume the stream, and it works fine.. So I believe the rtl_tcp pi is working correctly. I'm just not able to get dsd-fme to play nice with it.
Can anyone help? What am I missing here?
Thanks
Russ
K4RCC
Signed up to ask about this… I run a local NXDN conventional system with scrambling. I’ve been trying to use DSD-FME and an SDR to listen to the system but for some reason I’m unable to decode the scrambled signal from a wav recording.
I’ve been using the -R command with the 5 digit dec code but I just get garbled audio, and the garbling is the same if I change the code to a knowingly incorrect one. I also get the exact same number of “total audio errors” whether the code is right or wrong.
Any ideas? The recording should have sufficient signal strength so it’s not that. I’ve also tried -s 96000
I’ve been using the -R command with the 5 digit dec code but I just get garbled audio, and the garbling is the same if I change the code to a knowingly incorrect one. I also get the exact same number of “total audio errors” whether the code is right or wrong.
Any ideas? The recording should have sufficient signal strength so it’s not that. I’ve also tried -s 96000
lwvmobile
DSD-FME
For anybody wondering the answer to above, I got the same message in a PM and answered it there before I realized there was a duplicate question here.
DSD-FME isn't directly compatible with rtl_tcp. If you use rtl_tcp, you'd have to use something on the client side like GQRX, SDR++ or similar to connect to it first. rtl_tcp is an IQ spectrum server, and DSD-FME only handles demodulated nfm audio, either from a disc tap of some sort, its own internal rtl_fm based rtl support, disc tap, or virtual cable/virtual sink from another application. The TCP connection support in DSD-FME is mainly for the TCP Network Audio Sink built into SDR++, but could be applied to any means of transporting NFM audio via TCP, its just not currently equiped to handle the IQ spectrum and do its own PLL lock on the relevant frequencies. Its been a feature request, I may try to look into it some time, just was trying to reassess whether or not to completely extern the 'signal' gathering portion of DSD-FME into a seperate thing and only have DSD-FME handle pure symbol or dibit decoding.
If you want to run DSD-FME on your raspberry pi, you can run that locally to the PI, and you'll have to figure out the best option to transport the decoded audio if its completely headless. Alternatively, you could still run either rtl_tcp or sdr++ server on your PI and connect to that on the client side with an SDR program like GQRX or SDR++, and do the decoding on the client side.
DSD-FME isn't directly compatible with rtl_tcp. If you use rtl_tcp, you'd have to use something on the client side like GQRX, SDR++ or similar to connect to it first. rtl_tcp is an IQ spectrum server, and DSD-FME only handles demodulated nfm audio, either from a disc tap of some sort, its own internal rtl_fm based rtl support, disc tap, or virtual cable/virtual sink from another application. The TCP connection support in DSD-FME is mainly for the TCP Network Audio Sink built into SDR++, but could be applied to any means of transporting NFM audio via TCP, its just not currently equiped to handle the IQ spectrum and do its own PLL lock on the relevant frequencies. Its been a feature request, I may try to look into it some time, just was trying to reassess whether or not to completely extern the 'signal' gathering portion of DSD-FME into a seperate thing and only have DSD-FME handle pure symbol or dibit decoding.
If you want to run DSD-FME on your raspberry pi, you can run that locally to the PI, and you'll have to figure out the best option to transport the decoded audio if its completely headless. Alternatively, you could still run either rtl_tcp or sdr++ server on your PI and connect to that on the client side with an SDR program like GQRX or SDR++, and do the decoding on the client side.
To ask about this, I've been running the windows version and have only done it with a SDR dongle, but are you saying I could use my TRX-1 scanner with IF out through the headphone jack? If so, do you have a sample BAT file to use for this.
I'm sure it won't work with a Harris TDMA CC, but maybe NXDN or P25 P1?
lwvmobile
DSD-FME
If its actual disc tap audio and not just regular headphone jack audio with filtering coming out of that scanner, then you should just be able to start DSD-FME with the default input method and have it try to decode what is there. Mileage may vary on what all it can decode well and not so well, just depends on what comes out, I suppose. It won't be able to steer or trunk by any means, just as a passive decoder. You'd also want to use squelch on that scanner if its NXDN (assuming it works the same in digital modes as analog). To use the default input, just don't specify the -i argument, and you'll probably need to use a volume mixer to make sure the input is set to your line in or mic port on your PC.
I'm going to go with...no...on that one, you can't pass any already decoded information between the two. I'm not even sure I understand the question, but pretty sure the answer is no.
Ok. Maybe I did not explain it correctly. DSD-FME does not decode SMS/TMS, but dsd+ fast line does - until the traffic is encrypted. So i was wondering if in the near future, there is any possibility to dsd-fme decode this kind of data or (as you already answered) to push decrypted signal to dsd+ fastline to decode sms/tms.
