TetraNetMonitor UI Experimentation

[ronenp]

This is the fix for your problem: #56

Thank U Sir
It is not in the install instructions
but now it work

 

[ronenp]

May anyone tell me what are the description MCC NMC LA in the tuner ? and what are the number there ?
Thanks Forward

 

[thewraith2008]

---------------------------

---------------------------
Tetra plugin exception -System.DllNotFoundException: Unable to load DLL 'tetraVoiceDec': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

at SDRSharp.TetraNetMon.NativeMethods.tetra_decode_init()

at SDRSharp.TetraNetMon.TetraDecoder..ctor(Control owner)

at SDRSharp.TetraNetMon.TetraPanel..ctor(ISharpControl control, Int32 pluginNumber)
---------------------------
OK
---------------------------
This is the error i get when i turn on the SDRSHARP what is it ?

I know you got it going, but for the sake of answering the question for others.
This error is because the 'tetraVoiceDec.dll' is not in the SDR# working folder.
Or 'TetraNetMon.exe' was not run in the SDR# working folder or was run in folder but like above, 'tetraVoiceDec.dll' was not there.

May anyone tell me what are the description MCC NMC LA in the tuner ? and what are the number there ?
Thanks Forward

MCC = Country Code
MNC = Network code
LA = Location Area
CC = Color Code

These values serve to uniquely identify a provider network.
This is not always the case in some countries that don't regulate the issuing of the values.
So you can see different networks using same values.
This is a problem for TNM (and TTT) with the way it stores GSSI and ISSI records. I can't think of a way around this issue at the moment.



Latest version (v1.0.0.6) can be found here: Download

 

[thewraith2008]

Hello

after a while I get this error
Is it a known problem?

The arithmetic operation has caused an overflow.
at SDRSharp.TetraNetMon.dll.CmceSdsProtocol.ParseTextMessage (IL offset: 0x257)
at SDRSharp.TetraNetMon.dll.CmceSdsProtocol.ParseSDS (IL offset: 0xd9)
at SDRSharp.TetraNetMon.dll.CmceProtocol.ParseCMCEPDU (IL offset: 0x1e1)
at SDRSharp.TetraNetMon.dll.MleLevel.Parse (IL offset: 0x3d)
at SDRSharp.TetraNetMon.dll.LlcLevel.Parse (IL offset: 0x127)
at SDRSharp.TetraNetMon.dll.MacLevel.ResourcePDU (IL offset: 0x27c)
at SDRSharp.TetraNetMon.dll.MacLevel.TmoParseMacPDU (IL offset: 0x94)
at SDRSharp.TetraNetMon.dll.TetraDecoder.Process (IL offset: 0x893)
at SDRSharp.TetraNetMon.dll.TetraPanel.DecodingThread (IL offset: 0x276)
at mscorlib.dll.ThreadHelper.ThreadStart_Context (IL offset: 0x14)
at mscorlib.dll.ExecutionContext.RunInternal (IL offset: 0x79)
at mscorlib.dll.ExecutionContext.Run (IL offset: 0x0)
at mscorlib.dll.ExecutionContext.Run (IL offset: 0x2b)
at mscorlib.dll.ThreadHelper.ThreadStart (IL offset: 0x8)

Win10 home
intel i7 8th 16mb ram
tnm 1.06
sdrsharp 1700
rtl-sdr dongle

2010, 2013 and 2015 C + runtimes installed x86 + x64

Is it crazy to think that it is due to overheating of the dongle?

This is mostly likely a bug and not due to over heating dongle.
I'll need to investigate
EDIT: It's obviously related to 'D_SDS_Data' PDU which I haven't done much/anything with yet.



Latest version (v1.0.0.6) can be found here: Download

 

[thewraith2008]

@pingirona

Are you able to indicate the types of 'D_SDS_Data' PDUs you are receiving.
This may narrow down what is causing the error.
Not sure if you use TTT, but using the logs of TTT you will be able to determine that for me.

I have tried a few different D_SDS_Data PDUs though IQ samples I have, but none are seeing this error.



Latest version (v1.0.0.6) can be found here: Download

 

[thewraith2008]

Updated to v1.1.0.0 with the following changes (This is a major update)

• Backup 'NetMonitorSettings.xml'

This is a developing software:

• Implemented features may not be 100% working or be the final way it functions.
• Crashes may be possible.
• Bugs will exist.
• Manual editing of files maybe required to fix things for a newer versions (like this one).
• Things can be changed without notice.

I plan to try and improve the GSSI/ISSI records display sometime. Hopefully changes won't affect the storing of this data. But I can't promise anything.

Please read the 'Changelog.txt' for how to use new features.
I have not had time to update any of the documentation other than the changelog.

v1.1.0.0

Changed: 'NetMonitorSettings.xml'
- Removed storing of the groups list there.

Added: 'NetMonitorGroups.xml'
- For storing groups list.

Added: 'NetMonitorusers.xml'
- For storing user list.

Added: More CMCE Protocol PDUs

Fixed: Some private simplex calls were shown as [half]
- when both ISSI where in call.

Fix: 'Calls' tab
- Improvements to UI to stop flicker and other annoying quirks.

Changed: 'Calls' tab
- when list has many calls, make sure active call is visible in UI.

Added: Auto save Groups and Users list every 10 minutes.

Changed: Corrected variable name from "NMI" to "MNI"
Changed: Corrected variable name from "KnowGroups" to "KnownGroups"

Added: Option - Ignore priorities
- This will also hide 'Pri' column from the 'Calls' tab list.

Change/Fix: Some calls go active but tuner is not activated.
- This is a multi-part issue
- e.g. #1. Don't have un-used tuners. If you have 5 tuners defined but only have set 2 tuners (#1,3 and #2 is float), #4,5 are
not set but are on a carrier that call is on, then tuner is not enabled.
NOTE: You need to either remove the extra tuners or set them on unused carrier/frequency.
This fix does not address this.

#2. Tuner #2 (floating tuner) is already on carrier where call is to occur, TNM was not enabling tuner.
This fix addresses this.

Added: Single tuner mode
- One running SDR# and one dongle and one defined tuner (inside of SDR#).
- Best suited for small bandwidth dongles.
- Can monitor more than one MCCH so long as it is in range (of the current SDR# RF bandwidth).
-- When a call is followed and the spectrum view moves outside of the initial SDR# spectrum view and the set MCCH are no
longer visible, then monitoring MCCH is no longer possible from that point until call returns to MCCH.
- Currently priorities are ignored in this mode.
Was getting bad triggering after call had started causing weird issues.
Will try and sort in future. This will still be limited if MCCHs move out of view anyway.
- There still maybe bugs in this mode.

Added: To plugin: 'Current cell', 'Neighbour cell' and MS Registrations tabs.
- This view is toggled by pressing 'F1' in Remote Tuner window.
- In this 'Info' view, the window is sizable and its size is remembered (for the session only).
- On window close(X), the window is restored to initial cell detail view.
- If window is closed using 'Remote' button, then the window size and tab is remembered (for the session only).

Added: User list
- This will store seen ISSI in a list.
- The 'LO' is not implemented yet. If set-up the idea is the block a call if started by this ISSI.
- GSSI field stores all GSSIs seen with this ISSI.
- This (Groups and Users) tab needs more work.

BUGs: Groups and Users tabs are not 100% stable. If new entries are added the list can jump about (to top).
These tabs can be sluggish because of the amount of entries.
Priorities seem to rapid fire sometimes. A call overrides itself for priority.

Added: Display an image for group calls in 'Call view' (F12) - Experimental
- Add PNG images with GSSI# (e.g. 123456.png) to folder 'pics' in SDR# working folder (where TNM is run from)
- Keep images small (50x50). While other size will resize, larger image will impact performance.
- Currently not cross network (MNC) friendly.

Changed: General UI behavioral improvements.


=====================================================================================================
v1.0.0.8 - Not public release

Added: Option: Stop windows screensaver (from activating) while in fullscreen mode.

Fixed: 'Call view' field text color was not set before a call was seen.

Fixed: Corrected a start-up trapped error value.

=====================================================================================================
v1.0.0.7 - Not public release

Fixed: 'Calls' tab
- Depending on time format used, time for calls list and call events was displaying differently.

Added: Call view window.
- Shows Group/User/Call duration/Priority and hold indicators (when used).
- Use F12 to show/hide. Windowed and fullscreen option for F12 (see options)
-- Depending on the window position, fullscreen will be on the monitor that the window is visible on.
- Can set colors for this view:
-- Main window background.
-- Fields (Group/User/Call duration) background.
-- Field text.
- Use F11 (in call view window) to show buttons to set colors.

Added: 'Users' tab
- The underlying code has not been implemented yet.

This version requires some manual editing of some of the xml files.
Simply, if this is a new set-up then ignore instructions in 'Must_Readme.txt' and just extract 2nd zip (.7z) in 1st zip.
Otherwise read 'Must_Readme.txt'.

If you have issues as a result of not reading the instructions, I don't want to hear about it.
If you don't understand something about it, then ask away.


Download

MD5 Hash: 12f81f2fa98c58e3414d72bd1670f9a6

 

[pingirona]

@pingirona

Are you able to indicate the types of 'D_SDS_Data' PDUs you are receiving.
This may narrow down what is causing the error.
Not sure if you use TTT, but using the logs of TTT you will be able to determine that for me.

I have tried a few different D_SDS_Data PDUs though IQ samples I have, but none are seeing this error.



Hi, I've been doing tests with this over the weekend. I tell you what I see, although I do not know if it makes much sense
1- when I have deactivated the call control, TNM has been in operation longer without showing the error
2- for the launch of SDRsharp + TNM had created 2 shortcuts in the taskbar, configured to launch as administrator. I have deleted these shortcuts and now I launch directly from the file explorer, as administrator. This has allowed me to listen for 20 straight hours without error
3-although after 20 hours without error, when I went to close SDR sharp + TNM to restart, I found that SDRdharp was not allowed to close because it was hung, but it worked equally!

I'm not currently using TTT, I'm focused on TNM, but I keep some TTT record dated 3/7 from file .log. Can I upload these types of files here?

Is there an optimal launch sequence for SDRsharp + tnm?

 

[thewraith2008]

Almost missed your reply as it was in my quoted post.

Hi, I've been doing tests with this over the weekend. I tell you what I see, although I do not know if it makes much sense
1- when I have deactivated the call control, TNM has been in operation longer without showing the error

This is most likely a coincidence. The error occurred in the plug-in.
I do not recommend using TNM with Call control OFF. Most features won't work when OFF. And I don't do much testing with it OFF.

2- for the launch of SDRsharp + TNM had created 2 shortcuts in the taskbar, configured to launch as administrator. I have deleted these shortcuts and now I launch directly from the file explorer, as administrator. This has allowed me to listen for 20 straight hours without error
3-although after 20 hours without error, when I went to close SDR sharp + TNM to restart, I found that SDRdharp was not allowed to close because it was hung, but it worked equally!

I'm not currently using TTT, I'm focused on TNM, but I keep some TTT record dated 3/7 from file .log. Can I upload these types of files here?

I don't use Windows 10, but I don't know why you would need to 'run as administrator'.
Again, this is most likely a coincidence.

My thoughts on posting logs and IQ samples on main forum here

Is there an optimal launch sequence for SDRsharp + tnm?

Assuming 'Master/Slave' mode and dongle is already configured to go:
All I do is start SDR#.
Then start TNM.
Then play SDR# (or 'Remote start SDR#s' in TNM)
Enable tuners in SDR# except #2 tuner (floating) NOTE: Each tuner must be a MCCH. (At least in Master/slave mode)
Another than tuner #2, there should be no extra tuners (un-used) defined in SDR#.

Another thing your (TTT) logs have revealed, is you have private calls starting that don't really have carrier/timeslot defined. These calls should not be set-up. Strange the logs show 'D_Connect_Acknowledge' PDU but not a 'D_Setup' PDU preceding it. This goes against whats mentioned in the standards.



Latest version (v1.1.0.0) can be found here: Download

 

[The_freakquency]

I just saw in the call tabs of v1.1.0.0 that only the PRI column is resizable. all others seems to be dynamically resized, which requires me to focus a lot with my eyes not sure if it was like that in previous version. Just wondering if this is by design?

Other than that, it's working fine on my end! Thanks!!

 

[The_freakquency]

When PDUs are encrypted, nothing about the contents of the PDU is visible except the address. And even that address is encrypted from the way I read the standards. The whole point of encryption is to conceal the identity of user, call control, voice and anything else from 3rd party monitoring.

This level of encrypted must be unique to TETRA because DSD+ can seem to show call control of other encrypted systems like DMR and P25.

Make sense. I'm coming from the P25 world and it's a different behavior. I had that confirmed by my colleagues.

So there is nothing to add to the call list in TNM because we have no information about call control to be able to populate the list.
Sending/Notifying of encrypted PDUs to the main program will only congest the link between plug-in and main program with traffic it doesn't need or use.

I am more focused on what I can hear rather than what I can't.

I understand your point of view. I'm using TNM to better understand the network protocol and usage. I don't care about discussions the users are having. Hence my feature request to dump the raw data to disk


Thanks for all the time and effort you put into this project!

 

[thewraith2008]

I just saw in the call tabs of v1.1.0.0 that only the PRI column is resizable. all others seems to be dynamically resized, which requires me to focus a lot with my eyes not sure if it was like that in previous version. Just wondering if this is by design?

The PRI column should be fixed like the rest. Will fix in next release.
I will also fix 'From/To' columns to use a minimum size of 8 digits to suit GSSI/ISSI max sizes, so 1 digit will still be same width as 8 digits.
If labels are used and are longer than 8 characters, then these columns will still expand and contract to suit the label length which is not limited by me yet (don't go crazy with label length as I will probably restrict this at some point).
I could make it so you would have to manually adjust From/To columns to see all of label, but I think I would get tired of having to do this all the time I run TNM.

As for the raw data, not all elements of PDUs are pushed to main program.
I may just have the logging done from plug-in side. This will mean there would be a separate log for each set-up tuner (on a MCCH). This would probably be desirable anyway.
I will get to this sometime in the future.


Latest version (v1.1.0.0) can be found here: Download

 

[Syrah]

Hi thewraith2008,

Thank you for your work with TTT and TNM, it is very useful.
For next release of TNM, is it possible to add the remote window like with TTT (very convenient to see GSSI/ISSI) ?

How to import to NetMonitorGroups.xml and NetMonitorUsers.xml a GSSI/ISSI/Name excel database already existing ?
With TTT it was possible quite easily with excel and then merge into TETRA_GSSI.txt and TETRA_SSI.txt
But with TNM and the .xml synthax I can't find how to do this.

Thanks!

 

[thewraith2008]

Hi thewraith2008,

Thank you for your work with TTT and TNM, it is very useful.
For next release of TNM, is it possible to add the remote window like with TTT (very convenient to see GSSI/ISSI) ?

There is no 'remote window'. What your are looking for is called 'Call view window'. This is part of main TNM window.
It can be windowed or fullscreen (via options).
It is accessed by pressing F12. Its usage is explained in changelog.txt under v1.0.0.7.

How to import to NetMonitorGroups.xml and NetMonitorUsers.xml a GSSI/ISSI/Name excel database already existing ?
With TTT it was possible quite easily with excel and then merge into TETRA_GSSI.txt and TETRA_SSI.txt
But with TNM and the .xml synthax I can't find how to do this.

Thanks!

The GSSI/ISSI data is handled differently in TNM so it is saved differently. (serialization to xml)
You would need some script/program to parse the excel data (CSV?) and format it to the xml format used by TNM.
Or manually enter this data in as GSSI/ISSI are added to the list.
I known this is a painful exercise but it's just the way it is.
It's impossible for me to know how existing external data is organized to add a function to import this external data.



Latest version (v1.1.0.0) can be found here: Download

 

[hamradionl]

It's impossible for me to know how existing external data is organized to add a function to import this external data.

Point of view network operators or programmers i understand the quest from Syray
Why use XML, is there a particular reason?

 

[thewraith2008]

Point of view network operators or programmers i understand the quest from Syray

I understand exactly what was said.
Are you saying I should know how data in a file is organize that I've never seen before. No chance.

Why use XML, is there a particular reason?

Programmers prerogative.



Latest version (v1.1.0.0) can be found here: Download

 

[pingirona]

Hi @thewraith2008

the tetra network in my city has a Mcarrier in frequency A and then has 2 carriers in frequencies B and C. It happens very often that tomorrow Mcarrier can be frequency B and A is simply carrier. A few days later, the Mcarrier returns to the frequency A. This happens several times even within the same day. I tested TNM in "multi" mode by adding 3 tuners to an #SDR tuned to carrier A, B and C, but with the passage of minutes it crashes. Using TNM in main 1 mode + 1 slave happens that when the Mcarrier moves of frequency, TNM continues listening the same frequency and can no longer follow the calls, because it is no longer listening to the Mcarrier. With TTT when the Mcarrier moves frequency. TTT moved with her. Is there any solution in sight? Thank you!

 

[hamradionl]

pingirona,
I have same case,

 

[Syrah]

There is no 'remote window'. What your are looking for is called 'Call view window'. This is part of main TNM window.
It can be windowed or fullscreen (via options).
It is accessed by pressing F12. Its usage is explained in changelog.txt under v1.0.0.7.

Sorry for missing this feature in changelog. Is it possible to make this "F12 window " not in full screen but in a classic window? So we could place it as desired.
Otherwise, If I have more than 1 SDR# running with tuners, all the tuners are seen in only 1 TNM instance, not in others.
I mean for example if I have 1 SDR# with tuners 1&2 on TETRA network 1 and another SDR# with tuners 3&4 on TETRA network 2, I could not see tuners 3&4 on the second TNM (assuming I have a TNM in each SDR# folder).
Is it designed to work like that ? Is it possible that each TNM instance only see tuners in its SDR# folder ? If I want to tune to 10 TETRA networks, the only-1-TNM instance is going to be very active

The GSSI/ISSI data is handled differently in TNM so it is saved differently. (serialization to xml)
You would need some script/program to parse the excel data (CSV?) and format it to the xml format used by TNM.
Or manually enter this data in as GSSI/ISSI are added to the list.
I known this is a painful exercise but it's just the way it is.
It's impossible for me to know how existing external data is organized to add a function to import this external data.

Okay, If I find a way to do so (CSV to XML) I'll tell you.

 

[Syrah]

Forget when I said to put TNM in a classic window when pressing F12, I tried after, it's OK. (checkbox unchecked).

I was thinking if it would be possible, when pressing on F12, to display in the window as many Group/User fields as there are MNC tuned ?
So it will be clearer to see which TETRA network is "talking".

 

[thewraith2008]

Hi @thewraith2008

the tetra network in my city has a Mcarrier in frequency A and then has 2 carriers in frequencies B and C. It happens very often that tomorrow Mcarrier can be frequency B and A is simply carrier. A few days later, the Mcarrier returns to the frequency A. This happens several times even within the same day. I tested TNM in "multi" mode by adding 3 tuners to an #SDR tuned to carrier A, B and C, but with the passage of minutes it crashes. Using TNM in main 1 mode + 1 slave happens that when the Mcarrier moves of frequency, TNM continues listening the same frequency and can no longer follow the calls, because it is no longer listening to the Mcarrier. With TTT when the Mcarrier moves frequency. TTT moved with her. Is there any solution in sight? Thank you!

I will add main carrier switching to to list of things to do. Not sure when I'll get it completed.

Not sure the MCCH switching you see happens at same times, but if you can capture a IQ samples of this occurring as it would be of great help to use in testing.
Ideally the IQ sample bandwidth would need to be wide enough to see both carriers as seen between light blue lines in image. Hopefully these two carriers are not to far apart (close like in image, red and green lines) so the capturing bandwidth is not to big increasing file size.

Latest version (v1.1.0.0) can be found here: Download