SDR# TETRA Demodulator Trunk Tracking Demonstration

[thewraith2008]

As stated in the documentation the DMO implementation is a bit rough around the edges.
It's probably far from 100% but it did seem to work with the samples (only 2) I tried it with.

I added some more stuff to the MAC layer and it seem to show a decent amount of information as is.

The Source SSI and Destination SSI and Repeater Adderess (if used) is shown in the image of the SDR# side panel.

The image is only a mockup of the panel. It does not show labels and red lines as shown.

The output of the DMO PDUs are currently seen in 'burst type' tab in 'Network Info' window of the plug-in.

You have to enable DMO via Config > Settings in the plug-in.
It does not save the enable state, this is by design at the moment. (so people don't leave on by mistake.)
Read the changelog for the plug-in for more details on use.

Enjoy.

 

[thewraith2008]

Changelog in last release:
PHY level:
optimized pi/4 demodulator
added AFC
Mac level:
More that one mac pdu in mac block
stolen half slot
defragmentation
fill bits
Usignals PDU
Mle level:
increase parsed parameters

If needed i can show source code.
My pi/4 demodulator work fine with TMO and continous burst. For DMO need change demodulator synchronization.

Hello TSSDR, welcome back to the scene and thank you for the creation of this plug-in (and others).

I saw your return on your local forum (via Google translate)
I did not see your post here until after I posted the new release above.

In you absence I have create many changes to your plug-in (I hope you don't mind.) to better work with the companion program I created.

Yes I have added the required training sequences and preambles for the bursts used in DMO.
The use of the 3rd training sequence in TMO and the preambles (DMO) helps with false positives. May affect decoding weaker signals. In any case it's an option that can be turn off.
The MAC layer and rules have been created for DMAC-SYNC and DPRES-SYNC as well as processing of the stolen half slots (both signalling and speech).
I wish I had more DMO IQ samples to test with.

I have not done much with fragmentation as it mainly seems to address the MLE protocol (D-NWRK-BROADCAST) and the Neighbour cell information. If it does address CMCE then the useful information seems to be in the 1st fragment anyway. Which was not original been processed.

I was focused on the CMCE protocol to make sure no downlink PDUs where missing.

Your "optimized pi/4 demodulator" and "added AFC" sound good.
I also saw your BER/MER/FEC addition.
I only added a rolling average of successful CRC of bb block (AACH) over every multiframe.

Did you change the libtetradec.dll (decoder) for processing the half slot TCH? I had to expose the frame stealing feature that already existed in the code.

OK, I need to sleep, Hope to hear from you again.

 

[lynzoid]

And with this release thewraith knocked out the only existing device, that can monitor DMO at the moment - AOR DV Kudos and Thank you!!!

 

[hamradionl]

If needed i can show source code.
My pi/4 demodulator work fine with TMO and continous burst. For DMO need change demodulator synchronization.

Warm welcome in this worldwide hot topic over 300.000 hits

 

[hamradionl]

We need thewraith and Tssdr both a very Big thank you in behave of the worldwide tetra community.
Some free donation will be in place.

 

[R3Natas]

Hello thewraith2008,

Many thanks for the update, it's great, especially about "MS Registration", I asked for this function since long time ago. Also, I see you added support for Status message (User defined) decoding and SDS messages, only thing I don't see a decoded text. Finally, about DMO, it's a huge progress as well, the only report from me is that I don't hear my voice and ISSI data is wrong, but GSSI, MCC, MNC and other data is correct. So, thanks again for this huge update!

 

[hamradionl]

Finally, about DMO, it's a huge progress as well, the only report from me is that I don't hear my voice and ISSI data is wrong, but GSSI, MCC, MNC and other data is correct.

What type radio you using?
Original or modify firmware for hamradio use?

 

[R3Natas]

What type radio you using?
Original or modify firmware for hamradio use?

For this test I used Sepura radio on “National 430” channel

 

[thewraith2008]

Ok that that didn't take long.

- Popup screen telling:
"one of the SDR# or network info window position fields etc etc etc"
1.05 + 1.07 never have this popup screen, 1.08 TTT seem working OK

That's a bug for TTT in single mode.
This is related to the option "Position SDR#" in "O" [General Options]

The message seen is:
"One of the SDR# or Network Info window positioning fields has not been set."
"Will remain disabled until all set."

This message is normal if you try and use (enable) "Position SDR#" option when the positions have not been retrieved first.

Before you can set "Position SDR#" checkbox, you need to set the positions of the SDR#, Network Info windows.
- Dual mode there are 3 boxes that need setting.
- Single mode there are 2 boxes that need setting.

To set these fields you need to double click the fields (the texboxes with the red lines under them in image) to retrieve position information of the SDR#(CC and/or VC) and Network Info windows.

Problem is, when in single mode it checks if the 3 fields are set not 2, so this message will always show in single mode because the SDR# VC position field will remain blank. Unless you have used "Position SDR#" in dual mode then this won't occur.

As a work around:
Just run 2x SDR# then run TTT as dual mode (No need to have 2x dongles for this or to start a session)
Then double click all required 3 fields then change back to single mode and exit TTT and SDR#.
Run TTT again and you should be able to set "Position SDR#" when in single mode.

This is now fixed for next release.
I may release a hotfix if a few bugs show up in the next week or so and can be fixed quickly.

 

[hamradionl]

Hi, thank you.
i allways run dual mode 2x SDR# 2x RTL-SDR and will try your work around.
Wait later this week for this bug fix.

 

[thewraith2008]

Hello thewraith2008,

Many thanks for the update, it's great, especially about "MS Registration", I asked for this function since long time ago. Also, I see you added support for Status message (User defined) decoding and SDS messages, only thing I don't see a decoded text. Finally, about DMO, it's a huge progress as well, the only report from me is that I don't hear my voice and ISSI data is wrong, but GSSI, MCC, MNC and other data is correct. So, thanks again for this huge update!

The D_Status PDUs only shows the element "Pre-coded status" which is a 16bit value (that's 0 to 65535)
I think this is like an index to messages list stored on a MS. I could be wrong though.
e.g. A Pre-coded status value of "5" may point to message in a list "Delivery complete".
There is no way to know what these messages are unless you can read the targeted radio.

Did you select timeslot 1?
'A' channel uses timeslot 1 and 3 (TS:1 for speech)
'B' channel uses timeslot 2 and 4 (TS:2 for speech, I think. I've not seen to try.)

Maybe you can provide IQ samples of you DMO transmissions. Implementation from only read standard if only going to get this so far.

Is the ISSI showing any value?

EDIT: The D_Status PDU is quite useless really, I only added it for the sake of it to see what showed up.

 

[TSSDR]

Demodulator source - Demodulator.cs
For dmo need search training sequence in iq samples for every burst before demodulation and synchronize symbols with founded positions.
For this demodulator need decrease iq samplerate limits from 48000 to 25000.

 

[paparazzo]

I tried to run the Plug-In on a DMO Repeater Signal but while recieving the first Burst of the presence beacon the Plug-In crashed. The crash is reproduceable each time the Burst is recieved.
This is the content of the crash.txt:

Der angegebene Schlüssel war nicht im Wörterbuch angegeben.
at mscorlib.dll.Dictionary`2.get_Item (IL offset: 0x1e)
at SDRSharp.Tetra.dll.TetraDecoder.Process (IL offset: 0x2ac3)
at SDRSharp.Tetra.dll.TetraPanel.DecodingThread (IL offset: 0xb8)
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)

 

[thewraith2008]

I tried to run the Plug-In on a DMO Repeater Signal but while recieving the first Burst of the presence beacon the Plug-In crashed. The crash is reproduceable each time the Burst is recieved.
This is the content of the crash.txt:

Der angegebene Schlüssel war nicht im Wörterbuch angegeben.
at mscorlib.dll.Dictionary`2.get_Item (IL offset: 0x1e)
at SDRSharp.Tetra.dll.TetraDecoder.Process (IL offset: 0x2ac3)
at SDRSharp.Tetra.dll.TetraPanel.DecodingThread (IL offset: 0xb8)
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)

The error (log) unfortunately does not help solve the problem. It only points to an area in code, not what part of the decodeing cause it.
"Der angegebene Schlüssel war nicht im Wörterbuch angegeben." or "The specified key was not specified in the dictionary."
Indicates that something expected was looked up but not found (result is a crash). Without an IQ sample, I can do much to solve it.

As mentioned, I was a bit rough with this code.
Please, if people what to see this develop further then DMO IQ samples are going to be needed. Both DMO DM-MS and DM-REP types.

 

[R3Natas]

The D_Status PDUs only shows the element "Pre-coded status" which is a 16bit value (that's 0 to 65535)
I think this is like an index to messages list stored on a MS. I could be wrong though.
e.g. A Pre-coded status value of "5" may point to message in a list "Delivery complete".
There is no way to know what these messages are unless you can read the targeted radio.

Did you select timeslot 1?
'A' channel uses timeslot 1 and 3 (TS:1 for speech)
'B' channel uses timeslot 2 and 4 (TS:2 for speech, I think. I've not seen to try.)

Maybe you can provide IQ samples of you DMO transmissions. Implementation from only read standard if only going to get this so far.

Is the ISSI showing any value?

EDIT: The D_Status PDU is quite useless really, I only added it for the sake of it to see what showed up.

Yes, I understand that, the point is, I know these status values, so I can monitor what statuses subscribers send

About DMO, I will try to send you sample IQ later today and yes I tried "auto" and all the slots, but no voice is decoded, only data and the strange thing, talking to group it shows correct GSSI and wrong ISSI, but when doing private call all the data is correct.

 

[thewraith2008]

Yes, I understand that, the point is, I know these status values, so I can monitor what statuses subscribers send

Also, I see you added support for Status message (User defined) decoding and SDS messages, only thing I don't see a decoded text

You may know, but TTT has no way of knowing, so it can't show "decoded text".

About DMO, I will try to send you sample IQ later today and yes I tried "auto" and all the slots, but no voice is decoded, only data and the strange thing, talking to group it shows correct GSSI and wrong ISSI, but when doing private call all the data is correct.

This will be a great help.
I've made no attempt so far to determine individual or group call types. It's most likely why the number is wrong.

Thanks for the feedback.

 

[hamradionl]

Same here, No voice
Try later this day for i/Q files.

 

[Kenzi]

Hello could someone, who has (TETRA DMO signals active) post pictures how does look TETRA DMO signal with sdrsharp and post audio files how does TETRA DMO sound with FM modulation.

 

[hamradionl]

DMO

 

[thewraith2008]

For people with DMO issues please tell me some details of setup and call type.

Things to mention

• Is it DM-MS to DM-MS and what channel is call supposed to occur on (Channel A or B)
• Is it DM-REP (Type 1A, 1B or 2)
• Is call individual or group

The sample I have, seems to be DM-MS to DM-MS on channel 'A' and a group call.


I have added some Layer 3 PDUs rules for the ones I've seen so far:

• DM-SETUP
• DM-TX-CEASED
• DM-OCCUPIED
• DM-RESERVED

This helps identify Group/Individual calls (and help get GSSI and ISSI around the right way) and If call is speech and if E2E encryption is used. Air interface encryption is determined earlier in DMAC-SYNC (and will stop there if seen)