TetraNetMonitor UI Experimentation

[digiman1]

Assessing the signal levels of all the BS's used for the monitored sites would be impractical (and beyond the scope) for this application.
You would probably have to dedicate a SDR just to poll all of the frequencies for their signal levels.
Then there is all the logic required to handle all this evaluation and call control.

It would be easier to just create some sort of carrier lockout for each site.
This would not be a "quick fix" to do.



Latest version (v1.1.2.0) can be found in this post here: Download

Ahh, 2 dongles is inconvenient but locking out carriers would do the job.

If you revisit this project or find the time, would you consider adding a lockout for specified carriers?

I flick between TTT and TNM regularly, the audio on TTT is second to none but having the multiple CCs in TNM is great meaning I don't miss any action, it's just the choppyness that gets to me. I had tried the multiple TTT instances but this was giving me lots of duplicated calls.

Cheers. G

 

[Zeifer69]

I leave you the results of my tests, using a Chinese clone of RSP1, I have 4 tuners working, 3 for control channels and 1 for voice. With 4 mhz I can cover the entire 400 mhz system in my city. There are other much larger 390 MHz systems, but everything is encrypted.
I would need another 3 tuners to cover all the control channels but my laptop is already at the limit.
@thewraith2008 I hope that one day you will resume the projects as it is unique and has a lot of potential, despite all the complaints about the encryption or the SDS messages, they don't seem to understand that you have done everything in good will, and there is no other project currently dedicated to tetra. Unlike all DSD forks, you should consider receiving donations or a payment program like the Fastlane project.

 

[fhebr]

Hi,

I would like to thank the author of this program. This is probably the best program that can scan multiple channels at the same time.

However, I have a problem with crashing the application. I scan and listen nonstop using TNM about 8 main control channels, mostly it works well, but about 1 - 2 times a day either TNM or more often SDR# crashes. In the SDR# error log I found this:

The given key 'SYNC_PDU_type' was not present in the dictionary.
at <Unknown>.ThrowHelper.ThrowKeyNotFoundException (IL offset: 0x0)
at SDRSharp.TetraNetMon.dll.‮‭‬‮‪‪‮‍‬‪‬‏‬‎‪‍‭‎‭‬‌‍‮.‎‭‫‏‍‬‭‌‭‌‏‫‎‫‏‭‍‬‭‎‎‭‎‫‮ (IL offset: 0x14e7)
at SDRSharp.TetraNetMon.dll.TetraPanel.‭‭‌‪‌‮‌‫‪‫‏‎‍‌‮‏‬‪‏‪‫‮ (IL offset: 0x827)
at <Unknown>.StartHelper.Callback (IL offset: 0x0)
at <Unknown>.ExecutionContext.RunInternal (IL offset: 0x80)
at <Unknown>.ExceptionDispatchInfo.Throw (IL offset: 0x11)
at <Unknown>.ExecutionContext.RunInternal (IL offset: 0x80)
at <Unknown>.Thread.StartCallback (IL offset: 0xe)


I tried new and old versions of SDR#, but both have the same problem.

Next, sometimes TNM crashes if I minimize its window. But that doesn't limit me so much.

Anyone have experience with this problem? Or do you know of a suitable alternative on Windows for listening to multiple Tetra channels (I tried Wintelive, it worked well, but unfortunately there was a problem that, unlike TNM, it could not separate encrypted content from unencrypted content within one radio network)?

Thank you very much

 

[thewraith2008]

However, I have a problem with crashing the application. I scan and listen nonstop using TNM about 8 main control channels, mostly it works well, but about 1 - 2 times a day either TNM or more often SDR# crashes. In the SDR# error log I found this:

The given key 'SYNC_PDU_type' was not present in the dictionary.
at <Unknown>.ThrowHelper.ThrowKeyNotFoundException (IL offset: 0x0)
at SDRSharp.TetraNetMon.dll.‮‭‬‮‪‪‮‍‬‪‬‏‬‎‪‍‭‎‭‬‌‍‮.‎‭‫‏‍‬‭‌‭‌‏‫‎‫‏‭‍‬‭‎‎‭‎‫‮ (IL offset: 0x14e7)
at SDRSharp.TetraNetMon.dll.TetraPanel.‭‭‌‪‌‮‌‫‪‫‏‎‍‌‮‏‬‪‏‪‫‮ (IL offset: 0x827)
at <Unknown>.StartHelper.Callback (IL offset: 0x0)
at <Unknown>.ExecutionContext.RunInternal (IL offset: 0x80)
at <Unknown>.ExceptionDispatchInfo.Throw (IL offset: 0x11)
at <Unknown>.ExecutionContext.RunInternal (IL offset: 0x80)
at <Unknown>.Thread.StartCallback (IL offset: 0xe)

I have found the cause of this error.
For what ever reason, the signal is been detected as DMO. (Assuming TMO was the intended signal)
Regardless, the problem is a bug where it's looking for the TMO key 'SYNC_PDU_type' when it should be looking for the DMO key. (which stupidly is using 'SYNC_pdu_type')

Next, sometimes TNM crashes if I minimize its window. But that doesn't limit me so much.

I can't get TNM to crash when minimizing/minimized here.
Is there any crash log for this. (see Event Viewer)
It could be possible that this is coincidence and maybe related to above bug.

Can you tell me:

• Version of TNM - Both EXE and DLL
• Mode you are using (as selected in 'Tuners' tab 'Mode')
• Configuration of all the options (in TMN program only)
• Other:
  • Was call in progress
  • More than one monitor (screen) been used
  • If more than one monitor (screen) used, which one was TMN open in when minimized
  • Was SDR# open yet
  • Where options been changed before minimizing (crash)
  • Anything else?

Latest version (v1.1.2.1) can be found in this post here: Download

 

[fhebr]

Hi,

about problem with minimizing:

• ver. of TNM 1.1.2.1, DLLs are from TNM 1.1.2.1 archive
• Tuners mode: One master, other slave
• Config: only Save call event log is on
• Other
  • No
  • Only one virtual screen (VNC) is used
  • No
  • SDR# is minimized
  • I am scanning 8 control carriers
  • Version of SDR# is 1788 and 1919 - I will try oldest version

Since TNM is on a remote computer that is not used, the problem with minimization does not bait me so much, only if I accidentally minimize the window while setting up TNM, then I have to restart the whole PC so that TNM can be loaded correctly again. I'm much more annoyed by the spontaneous shutdown of SDR# during the night, when I have to set SRD# and TNM again every morning (the first part).

Thank you so much

 

[thewraith2008]

only if I accidentally minimize the window while setting up TNM

Is this crash occurring when minimizing the VNC window or TNM window?



Latest version (v1.1.2.1) can be found in this post here: Download

 

[Bernt112]

Is with this possible to log MS Registrations from multiple frequency with one SDR usb? Aux VFO not working for me. This i am searching already for over a week. Thank you for your programs!

 

[thewraith2008]

Is with this possible to log MS Registrations from multiple frequency with one SDR usb? Aux VFO not working for me. This i am searching already for over a week. Thank you for your programs!

No, TNM is only meant for voice monitoring



Latest version (v1.1.2.1) can be found in this post here: Download

 

[FR33MAN]

Hello again, I've been using sdr# 1716 for years, I like how that old version works because I could use TNM, TTT, aux vfo, and many more plugins. But today I decide because I'm tired of this version being blocked when I hit stop or close, I decide to try the most modern version of sdr# 1919 and I have the problem that I can't install TNM with several machine lines like we always do. My surprise is that I can't use TNM and the TTT doesn't give me sound...

Do you plan to do something in update? or can you tell me an old version of Sdr# that does not block when stopping

Thank you very much and as always very happy with the work you did and do.

 

[thewraith2008]

Not sure what you mean by "blocked".


You can get TMN to have multiple tuners in SDR# v1919:

That's about all I could muster with this version of SDR# before I wanted to step out in to traffic.

Because of the way SDR# interferes with the plug-in UI, it does not look that good.



Latest version (v1.1.2.1) can be found in this post here: Download

 

[FR33MAN]

I mean, I like the structure of the plugins better in previous versions, but the problem is that with sdr#1716,1732, whenever I have no stock, the sdr# always remains blocked. That's why I decided to try the new one and when I tried with TNM I saw that I only got one, can you tell me how you do it to put more than one tnm.

Another question from the old Sdr# doesn't have the problem that it crashes when closing?

Thank you and as always very grateful for your work.

 

[thewraith2008]

Installation is given in: "02-0.Install.txt"

Copy the following files to SDR# folder: (NOT PLUGINS folder)
- TetraNetMon.exe
- SDRSharp.TetraNetMon.dll
- NAudio.dll
- tetraVoiceDec.dll

Add MagicLines to Plugins.xml

Include the number of tuners as required into each running copy of SDR# (number of tuners is limited to 10)

   <add key="Tetra1" value="SDRSharp.TetraNetMon.TetraNetMonPlugin,SDRSharp.TetraNetMon" />
   <add key="Tetra2" value="SDRSharp.TetraNetMon.TetraNetMonPlugin,SDRSharp.TetraNetMon" />    <--- as required
   <add key="Tetra3" value="SDRSharp.TetraNetMon.TetraNetMonPlugin,SDRSharp.TetraNetMon" />    <--- as required
   <add key="Tetra4" value="SDRSharp.TetraNetMon.TetraNetMonPlugin,SDRSharp.TetraNetMon" />    <--- as required
   <add key="Tetra5" value="SDRSharp.TetraNetMon.TetraNetMonPlugin,SDRSharp.TetraNetMon" />    <--- as required
   <add key="Tetra6" value="SDRSharp.TetraNetMon.TetraNetMonPlugin,SDRSharp.TetraNetMon" />    <--- as required
   <add key="Tetra7" value="SDRSharp.TetraNetMon.TetraNetMonPlugin,SDRSharp.TetraNetMon" />    <--- as required
   <add key="Tetra8" value="SDRSharp.TetraNetMon.TetraNetMonPlugin,SDRSharp.TetraNetMon" />    <--- as required
   <add key="Tetra9" value="SDRSharp.TetraNetMon.TetraNetMonPlugin,SDRSharp.TetraNetMon" />    <--- as required
   <add key="Tetra10" value="SDRSharp.TetraNetMon.TetraNetMonPlugin,SDRSharp.TetraNetMon" />   <--- as required (Last)

Latest version (v1.1.2.1) can be found in this post here: Download

 

[FR33MAN]

Ok perfect, TNM working with all your tuners.
Now I just need to be able to hear the TTT because in the latest version sdr#1919 the audio doesn't work.
Is there something I can do or just have to wait if you can see how to fix it and update?

I'm going to expose it in the TTT forum, since this is from TNM.

Greetings and thanks for everything

 

[fhebr]

Zjistil jsem příčinu této chyby.
Z jiného důvodu je signál detekován jako DMO. (Za předpokladu, že TMO byl zamýšlený signál)
Bez ohledu na to je problém, kdy hledá klíč TMO 'SYNC_ PDU _type' , když by měl hledat klíč DMO. (což hloupě používá 'SYNC_ pdu _type' )


Nemohu přimět TNM k pádu při minimalizaci/minimalizaci zde.
Existuje na to nějaký protokol o selhání. (viz Prohlížeč událostí)
Je možné, že se jedná o náhodu a možná souvisí s výše uvedenou chybou.

Můžeš mi říct:

• Verze TNM - EXE a DLL
• Režim, který používá (jak je vybrán na kartu „Tunery“ „Režim“)
• Konfigurace všech možností (pouze v programu TMN)
• jiný:
  • Probíhá hovor
  • Bylo použito více než jeden monitor (obrazovka).
  • Pokud byl použit více než jeden monitor (obrazovka), na kterém bylo TMN otevřeno, když byl minimalizován
  • Byl ještě otevřený SDR#
  • Kde byly možnosti změny před minimalizací (selhání)
  • Něco dalšího?

Nejnovější verzi (v1.1.2.1) najdete v tomto příspěvku zde: Stáhnout

Hi, sorry for the delay in replying, I was away from home.

The minimization problem has mysteriously resolved itself, but I'm still very bothered by the problem of the constant irregular drop of SDR#, most likely caused by TNM. I tried SDR# 1700, 1716, 1732, 1788 and 1919 versions, all of them had this problem. You described above what could be causing the error, but unfortunately that didn't help me resolve the issue. Can't you think of any? Sometimes SDR# works continuously for two days, but for example today I had to turn SDR# back on and set it up about 4 times already, which makes the receiving system very unreliable for my purposes.

TNM version: 1.1.2.1
Allow me to attach the current error log once more:

The given key 'SYNC_PDU_type' was not present in the dictionary.
at <Unknown>.ThrowHelper.ThrowKeyNotFoundException (IL offset: 0x0)
at SDRSharp.TetraNetMon.dll.‮‭‬‮‪‪‮‍‬‪‬‏‬‎‪‍‭‎‭‬‌‍‮.‎‭‫‏‍‬‭‌‭‌‏‫‎‫‏‭‍‬‭‎‎‭‎‫‮ (IL offset: 0x14e7)
at SDRSharp.TetraNetMon.dll.TetraPanel.‭‭‌‪‌‮‌‫‪‫‏‎‍‌‮‏‬‪‏‪‫‮ (IL offset: 0x827)
at <Unknown>.StartHelper.Callback (IL offset: 0x0)
at <Unknown>.ExecutionContext.RunInternal (IL offset: 0x80)
at <Unknown>.ExceptionDispatchInfo.Throw (IL offset: 0x11)
at <Unknown>.ExecutionContext.RunInternal (IL offset: 0x80)
at <Unknown>.Thread.StartCallback (IL offset: 0xe)


Thank you very much for any help with solving the problems

 

[Mackintr]

Here is release v1.0.0.1 of Tetra Network Monitor (TetraNetMon)

Concept and foundation code by TSSDR (Originally based on TETRA Demodulator)
Documentation by thewraith2008

Contributors:
- TSSDR
- thewraith2008

Currently due to time constraints, TSSDR has handed development to me (thewraith2008) for the foreseeable future.


This is still early development and is considered a Alpha release.
As such:

• Is still rough around the edges.
• Probably buggy.
• Is feature poor.
• Documentation does not cover all areas of features and usage.
• You use it at you own risk.

I put this release out there so people can test and get an idea about what it can do and the direction it is heading.

Please read the supplied documentation.


Download

MD5 Hash: 72fd04c7f8e4f4e4e7c83122df75028b

Hi, Is it possible to email a copy of this software please mackintr@outlook.com

 

[thewraith2008]

You described above what could be causing the error, but unfortunately that didn't help me resolve the issue.

This requires me to do an updated to TNM and release it.
When I get time, I will try and make it available.



Latest version (v1.1.2.1) can be found in this post here: Download

 

[fhebr]

Thank you. If you would like, I can send you more description about this problem or later try TNM on Tetra site in our citry.

 

[thewraith2008]

Thank you. If you would like, I can send you more description about this problem or later try TNM on Tetra site in our citry.

I believe the issue is now fixed. I just need time to package it up.

From what I remember, it was strange that you seemed to be getting random detection of DMO on a TMO signal.
This wasn't the problem in any case but a enum naming bug.



Latest version (v1.1.2.1) can be found in this post here: Download

 

[fhebr]

I noticed one other error, but I don't know if it's caused directly by TNM. Only one frequency does this to me (TNM 2 window in SDR#), when the given frequency changes itself from 425.675 set by me to 426.750 (sometimes also to 426.900) and turns off. Neither of these self-set frequencies is a control channel and their control channels are different. AFC is disabled.

https://imgur.com/LyOF3U9

 

[thewraith2008]

I noticed one other error, but I don't know if it's caused directly by TNM. Only one frequency does this to me (TNM 2 window in SDR#), when the given frequency changes itself from 425.675 set by me to 426.750 (sometimes also to 426.900) and turns off. Neither of these self-set frequencies is a control channel and their control channels are different. AFC is disabled.

That is not an error but how the program works in "one master, other slave".
A number of tuners set on the main carriers (control channels) with the second tuner (always #2) to work as the traffic follower for when calls are not on the main carriers.

Depending on your configuration of TNM (and SDR#), the tuner #2 will follow to any frequency in the visible spectrum.
If a 2nd SDR (or last SDR) is setup with another (or last) SDR# with only one tuner, then this will tune anywhere it is required too to follow to traffic carriers.

You can change to other TNM setup configurations but the "one master, other slave" seems to be the most logic to use in most cases.

The documentation should help explain different setup configurations.



Latest version (v1.1.2.1) can be found in this post here: Download