Hello, now that you are testing with Win10, can I suggest a test? Since the launch of .NET 4.8 I observed that TTT + SDR 1700 apparently worked fine, but with the passing of the hours, it made SDRsharp stop working. The only way to close SDRsharp was with the task manager + finish task. I insist that to detect the fault, it was necessary to leave TTT running for 12 or even 24 hours. In Windows 7 the same problem, but at least I can uninstall .NET 4.8 and check that nothing new is installed beyond .NET 4.7. I have tried combining different C ++ (2015 alone, 2015 + 2013, etc ...) but without success. Also with versions under 1700 of Sdrsharp, also without success. Always with TTT in single mode. Regards.
SDR# TETRA Demodulator Trunk Tracking Demonstration
- Thread starter thewraith2008
- Start date
-
- Tags
- digital tetra trunktracking
Hello, now that you are testing with Win10, can I suggest a test? Since the launch of .NET 4.8 I observed that TTT + SDR 1700 apparently worked fine, but with the passing of the hours, it made SDRsharp stop working. The only way to close SDRsharp was with the task manager + finish task. I insist that to detect the fault, it was necessary to leave TTT running for 12 or even 24 hours. In Windows 7 the same problem, but at least I can uninstall .NET 4.8 and check that nothing new is installed beyond .NET 4.7. I have tried combining different C ++ (2015 alone, 2015 + 2013, etc ...) but without success. Also with versions under 1700 of Sdrsharp, also without success. Always with TTT in single mode. Regards.
thewraith2008
Member
- Joined
- Nov 22, 2016
- Messages
- 1,850
Not much using/testing in Windows 10, only when need arises. Windows 10 is just horrid.
I have SDR# 1700 + Plug-in and TTT running in dual mode there just to get it of the main PC while doing other things.
It's been running full time with no issues seen.
I have not installed .NET 4.8 yet (on anything). Last SDR# I have installed is 1727 but I don't use it.
I have found the most unexplained SDR# crashes (with no error messages) seem to point to the RTLSDR driver (rtlsdr.dll).
For whatever reason it hangs/stalls on calls to the driver. Maybe the hardware just drops out?
Problem is that rtlsdr.dll also calls code from libusb-1.0.dll, so it's difficult to tell which one is hanging.
Latest version (v1.0.20.2) can be found here: Release post
hamradionl
Member
- Joined
- Mar 23, 2014
- Messages
- 730
yesterday reading about there wil be new or other rtlsdr.dll drivers?
thewraith2008
Member
- Joined
- Nov 22, 2016
- Messages
- 1,850
The 'rtlsdr.dll' that SDR# downloads is quite old. Dated January 2014.
Development of rtlsdr.dll has continued on the osmocom git.
This requires compiling to use but this is fairly painless.
Alternatively one can use the updated rtlsdr.dll that DSDPlus (DSD+) supplied in the Fastlane version (from v2.197).
Not sure at what point that this DLL was taken from the source code.
Wouldn't hurt either to try the updated 'libusb-1.0.dll' either as the SDR# one is also dated (September 2015).
Get if from here (the file libusb-1.0.22.7z)
Remember that it's not SDR#s responsibility to keep the drivers up to date for the RTL.
NOTE: Even with the updated DLLs it doesn't mean it will fix the crashing. It may cause new issues.
Latest version (v1.0.20.2) can be found here: Release post
Development of rtlsdr.dll has continued on the osmocom git.
This requires compiling to use but this is fairly painless.
Alternatively one can use the updated rtlsdr.dll that DSDPlus (DSD+) supplied in the Fastlane version (from v2.197).
Not sure at what point that this DLL was taken from the source code.
Wouldn't hurt either to try the updated 'libusb-1.0.dll' either as the SDR# one is also dated (September 2015).
Get if from here (the file libusb-1.0.22.7z)
Remember that it's not SDR#s responsibility to keep the drivers up to date for the RTL.
NOTE: Even with the updated DLLs it doesn't mean it will fix the crashing. It may cause new issues.
Latest version (v1.0.20.2) can be found here: Release post
DarkAngelT
Member
- Joined
- Sep 27, 2018
- Messages
- 131
@thewraith2008
Could something like a tetra demodulator run on a cell phone?
Could something like a tetra demodulator run on a cell phone?
thewraith2008
Member
- Joined
- Nov 22, 2016
- Messages
- 1,850
Considering what they can do, I don't see why not. It would require some effort from someone to do.
Latest version (v1.0.20.2) can be found here: Release post
It’s perfect to have Android phone software.
Hi,
I'm using TTT from v105 and I don't had any problems. I use 2 silver RTL's. Last time I've upgraded to v1.0.20.2 and I'm suprised how many I can learn from site error in MS Registration on NET Info in tetra demodulator. I have so many data, than I ask for posibility of creation a log file from that. Because evety hour tab is reset and I cannot see what was in the net when I was away from the desk.
Darek
I'm using TTT from v105 and I don't had any problems. I use 2 silver RTL's. Last time I've upgraded to v1.0.20.2 and I'm suprised how many I can learn from site error in MS Registration on NET Info in tetra demodulator. I have so many data, than I ask for posibility of creation a log file from that. Because evety hour tab is reset and I cannot see what was in the net when I was away from the desk.
Darek
thewraith2008
Member
- Joined
- Nov 22, 2016
- Messages
- 1,850
I have already added this as an option to the plug-in to be included in next release.
It creates a file daily with the MS Registrations activity.
I am making some major changes to the way TTT and SDR# communicate.
This change is delaying the next release as I need to check and test if all is OK with the change.
This change should simplify installation and the running of TTT and the plug-in.
- No more 'Net Remote' plug-in.
- No more 'Checkbox detection' setup.
- No need to make sure 'Demodulator', 'Auto' and Net Remote 'Network' checkboxes are visible and on top on start.
Early testing looks good.
Latest version (v1.0.20.2) can be found here: Release post
DarkAngelT
Member
- Joined
- Sep 27, 2018
- Messages
- 131
It would be a dream! A big dream! Just like the Tetra Demodulator, TTT (which is coming to perfection) and TNM which is also an interesting project under development, it would be very good in the not too distant future for us to be able to tune in to a tetra frequency and listen over the phone.
thewraith2008
Member
- Joined
- Nov 22, 2016
- Messages
- 1,850
Porting to a mobile device is something that will not be done by me.
These OSes change every 5 minutes and I think running TETRA decoding would break some terms and conditions somewhere on those platforms.
For me, TETRA will be dead and gone by years end.
It's sadly been replaced by a vastly inferior DMR. Honestly, I don't understand how DMR ever got excepted. It's just the worst sounding ever.
Latest version (v1.0.20.2) can be found here: Release post
After these changes, will TTT dual mode still be necessary to listen to private communications? Until version 1.11, private conversations worked well in single mode. Version 1.20.2 is very stable and I don't want to go back but I use TTT just to listen, so I only use single mode and I really miss private conversations in TTT single mode. Thank you very much for your amazing work!
RMW1010
Member
Would it be possible to add the ISSI numbers to the recording file names?
@DarkAngelT It's already possible.
I'm using Virtual Cable to connect SDR# to Soundwire (an app only for Android).
It let's you listen to your chosen audio output with very low latency on your phone, less than 100ms if you are on the same network.
I recommend the pro version, it allows you more tweaking and compression settings for ultra low latency and no ads.
You'll need to open a port on your router if you plan on using it outside your home network (Default port: 59010)
thewraith2008
Member
- Joined
- Nov 22, 2016
- Messages
- 1,850
You have always been able to listen to private calls with TTT in dual and single modes.
Single mode is always limited in hearing all of call, see below.
Two types of Private calls exist:
- Simplex
- Duplex
This is how it currently works and will continue to work this way.
Simplex calls will play OK in both TTT dual and single mode as they use the same carrier and timeslot.
It's possible to have one of the ISSI parties not present on the current LA, so you will only hear one ISSI.
Duplex calls normally occur on same carrier but two different timeslots.
Duplex calls can also occur on two different carriers (and a timeslot on each carrier).
Duplex calls only in TTT dual mode will play both ISSI (if present).
Duplex calls in TTT single mode will only play one ISSI if two ISSI if present.
It's possible to have one of the ISSI parties not present on the current LA, so you will only hear one ISSI.
What problems are you seeing with private calls?
I see private simplex/duplex (half and full) working fine here in both dual and single modes.
ISSI values are only added to private calls.
Using ISSI for group calls could see the filename length get out of control when more than one ISSI is part of call. There is already a filename length limitation because of the way recording is done.
Latest version (v1.0.20.2) can be found here: Release post
EarHoles
Member
long time since i have played with this great software.
just set up Single Mode,
Does this appear fine?
Getting late in NZ so no calls yet.
I obviously
only run 1 instance of SDR# in Single mode right.
just set up Single Mode,
Does this appear fine?
Getting late in NZ so no calls yet.
I obviously
only run 1 instance of SDR# in Single mode right.thewraith2008
Member
- Joined
- Nov 22, 2016
- Messages
- 1,850
Looks OK.
When you see call activity you will know for sure.
Gets like that here on the network at night.
EDIT: Yes, only one SDR# in TTT Single mode. (2 x SDR# and 2 x Dongle in TTT Dual mode)
Latest version (v1.0.20.2) can be found here: Release post
EarHoles
Member
Looks OK.
When you see call activity you will know for sure.
Gets like that here on the network at night.
EDIT: Yes, only one SDR# in TTT Single mode. (2 x SDR# and 2 x Dongle in TTT Dual mode)
Chur bro.
I just remember when i first used many moons/revisions ago it changed the SDR# name to CC and VC.
I guess in Single mode its meant to just stay as SDR# V.xxxxxxx etc?
thewraith2008
Member
- Joined
- Nov 22, 2016
- Messages
- 1,850
Only dual mode prefixes the title, this is only to help with identifying all the windows.
Latest version (v1.0.20.2) can be found here: Release post
In the attached image are the changes from version 13. I have always had TTT configured as single mode. If I go back to version 1.11, I listen to private calls. If I install 13 or higher, I stop listening to them. Now I use TTT 1.20.2 which is the most stable version but I will try to install TTT 1.11 in another machine to see if I can provide more information. Thank you.
Attachments
Similar threads
