Figured it out. It does work in Main Branch with ffmpeg to Icecast server.
The UDP audio output that comes from dsd-fme is only available in the audio_work branch, and I've only ever been able to get it to work with the following commands on the receiving end.Does the new main branch include the udp audio output, or is it only in the audio_work branch?
//short 8k/2
socat stdio udp-listen:23456 | play --buffer 640 -q -b 16 -r 8000 -c2 -t s16 -
//short 8k/1
socat stdio udp-listen:23456 | play --buffer 320 -q -b 16 -r 8000 -c1 -t s16 -
Figured it out. It does work in Main Branch with ffmpeg to Icecast server.
I noticed was that nothing seems to get logged in the Call History.
I don't really know what to tell you on that. Just going by what the manual says to decode those as. Its possible the extra information you are looking for is in the extra DT frames FN6 and FN7, but the manual doesn't say anything about how those are decoded. This is all I have to go on from the manual when dealing with V/D1 and V/D 2 voice and data.Also, I noticed the RMn: shows something completely different from the YSF Reflector or room number. Not sure where that comes from.
RTL-SDR options:
Usage: rtl:dev:freq:gain:ppm:bw:sq:udp
NOTE: all arguments after rtl are optional now for trunking, but user configuration is recommended
dev <num> RTL-SDR Device Index Number or 8 Digit Serial Number, no strings! (default 0)
freq <num> RTL-SDR Frequency (851800000 or 851.8M)
gain <num> RTL-SDR Device Gain (0-49)(default = 0; Hardware AGC recommended)
ppm <num> RTL-SDR PPM Error (default = 0)
bw <num> RTL-SDR Bandwidth kHz (default = 12)(4, 6, 8, 12, 16, 24)
sq <num> RTL-SDR Squelch Level vs RMS Value (Optional)
udp <num> RTL-SDR Legacy UDP Remote Port (Optional -- External Use Only)
Example: dsd-fme -fs -i rtl -C cap_plus_channel.csv -T
Example: dsd-fme -fp -i rtl:0:851.375M:22:-2:24:0:6021
dsd-fme -f1 -i rtl:0:772.60625M:0:0:12:0 -T -G examples\vipergroup.csv -N 2> VIPER-log.ans
Looks like the way its currently coded, if it doesn't find the group file, its going to automatically close. I would double check the spelling on both the command and the file, and also, if its in a bat file, remember, the bat file does a cd into the dsd-fme directory for the windows builds. I usually find it easiest to just put your stuff in the Examples folder and point to it like this.
-G examples\vipergroup.csv
Also, just worth mentioning, on the rtl input configuration, there are only certain values it will properly accept. Here is a list of the RTL syntax. No decimal values are allowed, and I'd probably just stick to 12 for RTL BW. Instead of AUTO, you should use 0. If its a value it can't parse, it should just revert to the default value, but just FYI.
Code:RTL-SDR options: Usage: rtl:dev:freq:gain:ppm:bw:sq:udp NOTE: all arguments after rtl are optional now for trunking, but user configuration is recommended dev <num> RTL-SDR Device Index Number or 8 Digit Serial Number, no strings! (default 0) freq <num> RTL-SDR Frequency (851800000 or 851.8M) gain <num> RTL-SDR Device Gain (0-49)(default = 0; Hardware AGC recommended) ppm <num> RTL-SDR PPM Error (default = 0) bw <num> RTL-SDR Bandwidth kHz (default = 12)(4, 6, 8, 12, 16, 24) sq <num> RTL-SDR Squelch Level vs RMS Value (Optional) udp <num> RTL-SDR Legacy UDP Remote Port (Optional -- External Use Only) Example: dsd-fme -fs -i rtl -C cap_plus_channel.csv -T Example: dsd-fme -fp -i rtl:0:851.375M:22:-2:24:0:6021
So, maybe try putting your csv files in the Examples folder, and running something like this instead.
dsd-fme -f1 -i rtl:0:772.60625M:0:0:12:0 -T -G examples\vipergroup.csv -N 2> VIPER-log.ans
Also, if its P25 phase 1 only, run -f1, if its Phase 1 and Phase 2, run -ft, if its Phase 2 only, run -f2.
Well, can you zip up the entire log.ans file you had and the group.csv file you were using and send it to me, it could be something in there causing the crash, or at least, it'll be able to give me a clue about what might have happened there.
Does the crash happen without specifying a group.csv file?
Okay, I think I found what is going on, actually, I had figured the same thing out a while back. Again, a quirk of the Windows/Cygwin builds. Maximum supported groups is 1023, and you group file was at 2908. I must have made a comment on the code way back last year regarding it, looks like you did the thing.The crash does not happen without the group file.
groupinfo group_array[0x3FF]; //max supported by Cygwin is 3FFF, I hope nobody actually tries to import this many groups
Thanks, I'll trim it down. Being the state capital, and having the SHP Training Center and State Fair here, we get a lot of traffic from across the state affiliated to our towers. Working fine after I decreased number of TGs in file.Okay, I think I found what is going on, actually, I had figured the same thing out a while back. Again, a quirk of the Windows/Cygwin builds. Maximum supported groups is 1023, and you group file was at 2908. I must have made a comment on the code way back last year regarding it, looks like you did the thing.
Code:groupinfo group_array[0x3FF]; //max supported by Cygwin is 3FFF, I hope nobody actually tries to import this many groups
Sometime, in the future, I need to revisit that and see if I can allocate more memory for it and still have it import correctly.
Thanks, I'll trim it down. Being the state capital, and having the SHP Training Center and State Fair here, we get a lot of traffic from across the state affiliated to our towers. Working fine after I decreased number of TGs in file.
@lwvmobile
hola,
Me gustaría saber si se puede trabajar con distintas líneas de audio virtual, como se hacía con la versión de DSD+ o DSD fastline.
Con las anteriores la línea de comandos quedaba tal que así:
DSDPlus -i2 -o2 -fr -f1 -v4 -u1 -T -E -Pwav -g300 -wel6.684 -wes200.590 -wcl243.684 -wsl243.1054 -wss57.200 >DSD.log
Donde -i2 es la variable de VAC
Alguien lo ha probado?
Me gustaría saber si se puede trabajar con distintas líneas de audio virtual, como se hacía con la versión de DSD+ o DSD fastline.
Con las anteriores la línea de comandos quedaba tal que así:
seems like any new update to SDR# will come in and break everything, going by what other threads on this forum seem to indicate.