Hello,
Some interesting observations earlier in the thread. I have a nearby EDACS Extended Addressing (EA) system using ProVoice and would be interested in decoding more of the data.
I am not surprised that the automute does not work well. I noticed the NAC and other display values vary during decode, even with a good signal. One reason P25 decode is fair to poor is the P25 moving-average filter is missing. This filter allows a FM demodulator to decode both C4FM and QPSK. Another problem is the P25 bit sync has too much jitter because of the simple sync detector.
Adding the proper filtering to the existing code causes problems with mode autodetection and the other modes. One way to do it properly is to split the incoming audio stream into multiple streams. Each stream would go through the proper filter and then to the proper sync detection and decoder for each similar mode. The upside is the program could autodetect all the modes. The downside is this may take more processor time and require restructuring of DSD code. The processor time increase may be mitigated by the elimination of the unneeded QPSK code.
DSD does not implement error correction, only mbelib does for voice. I think the voice error correction corrects much of the dsd code shortcomings. When I implemented table driven error correction for DMR data, I found weak signal decoding of data noticeably improved over just having the DMR filter. I have also added code to decode most of the DMR CSBK and TLC information, so I use dsd instead of DMRDecode.
There are a bunch of other annoyances. The dsd code is structured to only decode one DMR voice slot when it is present, so control channel decoding goes away. When two voice slots are active, it will decode one voice slot and then jump to the other voice slot when TLC frames appear on the first voice slot between transmissions.
I have a feeling that most of the dsd code would need to be restructured to fix all the problems, or it may be easier to just start from the ground up. Apparently this was done with DSDplus, although I would not use it. I can not add DMR decoding, and USB3000 support since DSDPlus is closed source.
I do not want to bring another dsd clone into the world. I am more interested in developing a program that decodes digital trunked radio systems, which means a new program from the ground up. I am using dsd to test some concepts. This development will take months.
Another improvement I am working on is to use ncurses for a better display. I think adding this may break a cygwin windows port as it is not clear if cygwin can use the ncurses library.
73 Eric
