DSD-NEO Cygwin Issues #2

interesting, can you try removing the build directory and re-run? i'm not seeing that, but it seems like a stale/missing cmake file or something... you might want to re-clone the repo if that doesn't work...

rm -r build
cmake --preset dev-release
cmake --build --preset dev-release -j

i have the opposite problem, no TETRA for 4000+ miles... so it'll be a long term goal, but not unreasonable. there is already some good work being done in other open source projects, so probably won't be terribly difficult...

i have and it's not a trivial process. pthreads, pulseaudio, network stuff, etc. don't have a direct port to MSVC, so maybe if i get bored one day i'll attempt it but it's far too much work right now given the state the code is in... and i don't use or dev on Windows.

in the meantime, i'm working on setting up a GitHub action to compile and zip up a portable Cygwin install of dsd-neo so you don't have to compile it. i'll let you know once it's ready. i'll probably run the workflow once a day or after i've introduced enough changes to warrant a new Windows build, but not on every commit.... it's a long build.

fwiw, dsdplus fastlane is pay to play and i'm giving this away for "free".... soo.... if their RTL-SDR support suddenly gets a lot better, you'll know why. 😉

here you go: https://github.com/arancormonk/dsd-neo/releases/tag/nightly, the zip file contains portable cygwin install. github actions will update the nightly tag on every push to the main branch.

be aware, windows defender might flag the unsigned exes as a virus... i assure you they're not... but you can always VirusTotal it yourself if you don't believe me: https://www.virustotal.com/gui/file/569fa8b4a5d5ea8a2607d9508049eececcdc7a9dd423ee091f779d4c7a83111b?nocache=1

also, you might want to try pulling down the latest main again and see if it compiles now. i did fix some linkage/ordering issues that might have been causing problems.

should be fixed now: 64e580e

just guessing.... but do not run cmake from the build directory, follow the instructions: https://github.com/arancormonk/dsd-neo?tab=readme-ov-file#build-from-source

cd ..
rm -r build
# From the repository root
cmake --preset dev-release
cmake --build --preset dev-release -j

i can look into it, a short "training" period during startup might be the best way instead of trying to keep adjusting it... the rtl-sdr should be relatively stable once it has thermally stabilized.

it's a command line program, so you'll want to open a terminal/PowerShell and CD into the directory:

everywhere you see dsd-neo replace it with run-dsd-neo.bat or run-dsd-neo-mintty.bat, for example: run-dsd-neo.bat -h to view the help... i may end up changing the script naming in the future, but this was to get a quick and dirty way to get a portable build going on Windows so users don't have to install or compile in Cygwin.

thats what iam doing and getting a error message flashing up and dissapearing .
Screenshot 2025年09月25日 112915

are you opening the terminal this way? right click the folder and select "Open in Terminal"... you might have to pick Show more options if it's not listed.

that .ico error won't stop it from executing and i see dsd-neo running in the background terminal from your screenshot... it just defaults to the help menu when nothing was passed to it. you'll need to provide it some parameters like .\run-dsd-neo.bat -i rtl:0:850M -ft -T -N... run .\run-dsd-neo.bat -h to see all the command line arguments.

i might remove the run-dsd-neo-mintty.bat option, i think it works fine in the normal windows shell... though, i don't use windows.

fwiw, i'm addressing these issues with a more user friendly .bat script (imo)... should be available in an hour or so.

the latest nightly has an updated dsd-neo.bat where you can now double click on it and it will keep the terminal window open. passing arguments to the script should also still work, e.g, dsd-neo.bat -i rtl:0:850M -ft -T -N

sounds like another crc issue... can send me short lrrp captures for each path? one with rtl-sdr as input and one with the tcp input? im guessing your tcp input results in cleaner symbols than what is being decoded from the discriminator audio of the rtl-sdr path. what are the rtl gain & filter bw settings you're setting in sdrpp/sdrsharp? if you're seeing a burst in CRC errors near the bad lrrp data/payload then it's probably that.

I think you're right Arancormonk, because with RTL input it doesn't decode as many ARS messages as it does with TCP input, somehow it seems to skip them or not see them.

yea, thanks for the files. still investigating, might have to pull out some more rtl tricks to improve performance...

you are using the default sampling bw with the rtl, right? 48 khz? latest commit, i added a crc guard to not show anything if all crc blocks fail, but that doesn't really solve the problem... i also added a low sps symbol sampling adjustment to prefer the center instead of edge-pair window, but that shouldn't be necessary if the dsp-bw is at least 24 khz

the latest capture files you provided didn't show any outlier cases, so these adjustment are just based on a hunch... if you can try to capture again with bad lrrp data i can reinvestigate.

i'll think about it, i'm leaning more towards making it user configurable to load/play a file from the local machine rather than packaging any copyrighted stuff. i guess simple tones would be easy to generate, but then i have to get creative 😝.

that's actually a very good idea, if you want make a pull request with these changes please do so!

Can you leave me your personal email address? This is mine romanremusvasile@yahoo.com

my personal email!? i dunno about that... nothing against you, but the internet is a terrible place 😝

in the meantime....you can attach files to github, zip files should be fine i think:

ah, yes. i should have prefaced with that, all the shortcuts present in fme should be present in neo. if you find one that doesn't work, let me know... the input handler has been completely rewritten, so i might have missed something.

Hello,
A possible issue with DMR trunking. I use SDR++ with the Rigctl TCP connection. When tuned to the DMR control channel, the program will run fine initially. Once the program plays the first transmission, the "In Level" % drops to zero, and the program stops working until it is restarted. It's like the program doesn't return to the control channel after the first transmission. This doesn't affect P25 systems

can you post a screenshot of the terminal output (no -N switch) so i can see what it's doing during the failed retune? i wonder if it's because of LCN mismatch or something, i'll have to check with a DMR T3 system out here... i'm in the middle of nowhere, so it's tricky to find a test subject at times...i added some ui notification logic to the nxdn path, i might add the same to dmr trunking

can you share command line arguments you're using and the csv file with LCN and freq pairings?

arancormonk, did you receive the info that you requested from me?

arancormonk, did you receive the info that you requested from me?

i did not, can you post it to this github discussion? i'm looking into this now, sorry for the delay... i had to do the job that pays the bills first 😉

Thank you for all the effort you are putting into this!

try the latest build.. again. i rearranged some stuff in the code, event history is working for me with p25 trunking in windows...

The latest version worked for me the first time I tried it. I then closed the terminal window, then re-launched the program, and Event History no longer worked. This is both P25 and DMR trunked systems. NXDN trunked systems don't seem to have an issue.
The screenshot shows the program after it's been running on a busy P25 system for about 10 minutes. I get the same results on three different Windows 11 machines. I have no idea.
NEO-SNIP

i just thought of something... are you loading aliases files for both dmr and p25? can you try running without loading the aliases files? (no -G switch)

I just tried that. Made no difference.
BUT...as the terminal window was just opening, there were two extra lines under the Event History that are usually present when it's working properly. But these extra lines disappeared after the terminal window was up and running.

i don't think -f2 will work without a TDMA/p25p2 control channel or a strictly p25p2 recording/playback. for p25p1/2 trunked systems, -ft should be all you need... the code is smart enough to switch SPS between p25p1 and p25p2