improve dmr output

[ZeroChaos-]

so I finally got dmr working, or at least it tells me the duration of each of my transmissions. I have no modulation set, and the system is set to conventionalP25 (feel free to tell me I'm doing it wrong).

this is what I get:

[2019-01-10 16:35:15.002356] (info) [sys_1] TG: 1 Freq: 4.343000e+08 Ending Recorded Call - Last Update: 15s Call Elapsed: 15

Now, the frequency is right and that's good. But the TG I am transmitting on is 31337, not 1. I'm not sure how much I'm supposed to get for dmr, but I'd really love to see Color code, slot, source id, private/group/all, and target talk group. Any way I can get closer to my goal? Is this user error or just current limitation?

[robotastic]

That is a good question! I am not sure how much DMR parsing OP25 does. I would be up for upgrading the Trunk Recorder objects to support all of the DMR fields.

It does look like the standards are available, so we maybe able to hack together full support... or atleast something useful: https://www.dmrassociation.org/dmr-standards.html

I am not aware of any systems nearby, so I haven't done any testing.

[ZeroChaos-]

How can I help you with that? I'm not giving glitter access to my github, do you hang out anywhere else that we might discuss?

[robotastic]

@ZeroChaos- any chance you are going to be at ShmooCon? I am in DC and live around the corner. My email is luke@robotastic.com

[ZeroChaos-]

lol, sorry I missed this while prepping for shmoocon. I was running the Wireless Capture the Flag, we likely saw each other :-) I'll email you.

[gavinrozzi]

Hey @ZeroChaos- would you mind sharing your DMR config? Trying to get it setup on my end as well. Thanks in advance!

[ZeroChaos-]

something something like this

{
    "sources": [

        {
            "center": 434350000.0,
            "rate": 2048000.0,
            "error": 0,
            "gain": 24,
            "digitalRecorders": 2,
            "analogRecorders": 2,
            "analogLevels": 32,
            "driver": "osmosdr",
            "squelch": -10,
            "device": "rtl=0"
        }
    ],
    "systems": [{
        "channels": [434300000],
        "type": "conventional"
    }],
  "DefaultMode": "digital",
  "captureDir": "/tmp"
}

Note, it doesn't work like this, or as conventionalP25

[gavinrozzi]

Thanks, I've been having difficulty getting it working on my end as well.

[kb2ear]

Poke, anything more on this?

[robotastic]

This is a good reminder for me to pull in the latest OP25 code. I think DMR support has improved. It might be possible to do a Conventional DMR recorder.

[photounit]

Any update on this??????

[Dygear]

I have multiple systems in my area that use DMR. What would you need to get this off the ground?

[ZeroChaos-]

@robotastic poke. I've finally had time to circle back to this and really loving it. Of course, there is no p25 in my area so I'm stressing you on conventional and dmr stuff :-) Just wanted to bump this bug and see what I can do to test

[robotastic]

This is a deserved ping! Let me go see if I can atleast enable DMR Conventional support. I think DMR support in OP25 is pretty well baked now.

[ZeroChaos-]

This is a deserved ping! Let me go see if I can atleast enable DMR Conventional support. I think DMR support in OP25 is pretty well baked now.

thank you! I have much dmr nearby and am able to test whatever git branch you like when ready.

[robotastic]

Awesome - as a next step, I will work on merging in the latest version of OP25... but I think I need to get the v4.0-beta version finally merged in first. One issue I remember is that OP25 switched Codecs and things now sound a little off to me.

[ZeroChaos-]

NP, I'll transition to v4.0-beta and open new bugs for anything unrelated to this bug which I find.

[ZeroChaos-]

Bump, it's been a month and a release so just curious on that status of this. My area is analog, dmr, and nxdn, so I'm anxious for more support in trunk-recorder :-)

[ZeroChaos-]

Just to keep this bug up to date, there is now a branch called trbo-support which implements the "conventionalDMR" type. This works surprisingly well for the DMR audio, however, the metadata isn't being decocded yet.

[ZeroChaos-]

the dmr capture doesn't succeed if the end is missed

sometimes I have output like this:

[2022-01-07 14:23:01.977406] (info)   DMR Frame Assembler - sending src: 1
[2022-01-07 14:23:01.977783] (info)   DMR Frame Assembler - sending src: 1
[2022-01-07 14:23:01.978078] (info)   DMR Frame Assembler - sending src: 1
01/07/22 14:23:01.978202 [1] Slot(0), CC(1), VOICE LC PF(0), FLCO(00), FID(00), SVCOPT(00), DSTADDR(ffffe0), SRCADDR(000001), rs_errs=0
[2022-01-07 14:23:01.978231] (info)   DMR Frame Assembler - sending src: 1
[2022-01-07 14:23:01.978257] (info)   DMR Frame Assembler - sending src: 1
[2022-01-07 14:23:01.978449] (info)   DMR Frame Assembler - sending src: 1
[2022-01-07 14:23:01.978498] (info)   DMR Frame Assembler - sending src: 1

When this happens, encode-upload is never run, which I assume means the call never "completed" and I suspect the audio is lost.

I only ever actually see encode-upload run (and get audio on rdio-scanner) if there are lines like this in the log:

01/07/22 14:02:17.623806 [1] END !! Slot(0), CC(1), EMB LC PF(0), FLCO(00), FID(00), SVCOPT(00), DSTADDR(ffffe0), SRCADDR(000001)

[ZeroChaos-]

please scratch my last comment. I've had my scanner on my desk all day and these messages have no output from my scanner either (but the light lights up like it's getting something) so I'll assume it's something like dead air.

I think it's time to merge this branch, unless you plan to work on the metadata soon. :-D

[ZeroChaos-]

trbo-support branch has been merged. Would you like a new bug to track metadata capture or is this one going to continue?

[photounit]

Great news! Could we get an example config that shows how to set up a DMR channel/Channels?

[robotastic]

I just add an example: https://github.com/robotastic/trunk-recorder/blob/master/examples/config-dmr.json I am going to close this thread - we can start a new one for metadata