MDC1200 number format

[frameshift18]

Messing with MDC decoding here and it looks like the src id that is written into the JSON file is a decimal representation of the decoded MDC src id.

So for example a MDC unit id of 2216 will get written to the JSON file as 8726.

I haven't looked at where else the MDC unit id is used but could it just be converted to a string somewhere in the mdc decode functions?

[robotastic]

Interesting! I do not have any MDC systems near me, so I can't really test. It would be this line here... https://github.com/robotastic/trunk-recorder/blob/master/lib/gr_blocks/decoders/signal_decoder_sink_impl.cc#L80 I think if you change the x to a d it should fix it. Let me know if that works.

[robertlynch3]

I get the MDC message fine in the logs

{"type":"MDC1200","timestamp":"1626985908","op":"01","arg":"00","unitID":"0495","ex0":"00","ex1":"00","ex2":"00","ex3":"00"}

But it looks like that string is converted to an INT in the Call JSON

{
"freq": 1.58835e+08,
"start_time": 1626985902,
"stop_time": 1626985920,
"emergency": 0,
"duplex": 0,
"mode": 0,
"priority": 0,
"call_length": 17.9928,
"talkgroup": 2,
"srcList": [ {"src": 1173, "time": 1626985900, "pos": 4.681438, "emergency": 0, "signal_system": "MDC1200", "tag": ""} ],
"freqList": [ ]
}

1173 to hex is 0x495, the unit number that comes over the radio is 495.

Where is the Call JSON built? I can look at playing around with the code.

[zero48]

Few years algo I did a MDC1200 encoder (microcontoller bases) which worked correctly with Motorola radios de coser (display) and Cimarrón profesional decoders and always sent 4 characters un HEX from 0000 to DEEE if this info may help , never un decimal , Also did GESTAR which was in decimal 00000 yo 16383

El lun., 1 de febrero de 2021 12:51 a. m., frameshift18 < @.***> escribió:

Messing with MDC decoding here and it looks like the src id that is written into the JSON file is a decimal representation of the decoded MDC src id.

So for example a MDC unit id of 2216 will get written to the JSON file as 8726.

I haven't looked at where else the MDC unit id is used but could it just be converted to a string somewhere in the mdc decode functions?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/robotastic/trunk-recorder/issues/435, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAF4C35FKLF3YLERFU6KYOTS4YXN7ANCNFSM4W4DK2EQ .

[ZeroChaos-]

I can confirm that in my area it works the same, the line from the mdc decoder shows the unit id in hex which happens to be the unit number in decimal. Yeah, I know, that's kinda wierd.

Example: {"type":"MDC1200","timestamp":"1629913661","op":"01","arg":"80","unitID":"0609","ex0":"00","ex1":"00","ex2":"00","ex3":"00"}

This is a transmission from car 609. I don't know how common this is, but a "mdchex" or "mdcnoconvert" kind of option would make things a little easier. for folks

[ZeroChaos-]

I wrote a garbage parser for this because it suited me to do so. I used it as part of an uploadScript which I am working on. If it helps anyone, here it is.

#!/bin/bash
filename="$1"
basename="${filename%.*}"
json="$basename.json"

#parse caller
caller="0"
if jq -reM '.srcList[].src' "${json}" > /dev/null 2>&1; then
  #caller=$(jq -reM '.srcList[].src' "${json}")
  caller=$(printf "%x\n" $(jq -reM '.srcList[].src' ${json})| tr '\n' ',')
fi
if [ "${caller}" != "0" ]; then
  printf "Unit(s): ${caller:0:-1}\n"
fi

[robotastic]

Yea - that is a bit a weird. I bet you we could change the way the JSON is formatted based on the type of Signaling used for the System. I think I may have broken MDC1200 in the new beta I am working on, so when I try to patch everything back together I can try to make this fix.

[leee]

In general trunk-recorder treats human-facing representations of talkgroups and IDs in decimal. This isn't the case for say system information (system/site IDs, etc.) but off the top of my head I think those only show up in the logs, but nothing in configuration or file outputs.

I'd love to see everything represented by hexadecimal, but that's of course a personal preference 🙂 But given everything else is being output in decimal representation, I think you're better off keeping everything following that unified stance, and doing any sort of parsing/handling after the fact like you're doing now with that modified uploadScript.

[ZeroChaos-]

My little hack works, but for some of the front ends I need to do things like sed the json and I'm not a huge fan. Honestly a generic "iWantHex=true" and just convert nothing would be nice, or even better a per item and/or per system option to not convert would be great. I can imagine even just in my local area that some departments use hex and some use decimal with the unit number. I'll decode a few more and see how needed that is.

I don't think this is a high priority request, but I don't think it's incredibly difficult to address either, so I'd love to hear the maintainer's thoughts.

[ZeroChaos-]

Yea - that is a bit a weird. I bet you we could change the way the JSON is formatted based on the type of Signaling used for the System. I think I may have broken MDC1200 in the new beta I am working on, so when I try to patch everything back together I can try to make this fix.

If the code you are working on is in git just tell me which branch to build and I'm happy to test for you. I'm just getting going with trunk-recorder so I can restart and rebuild this as many times as I want without angering my non-existent listeners.

[leee]

If the code you are working on is in git just tell me which branch to build and I'm happy to test for you. I'm just getting going with trunk-recorder so I can restart and rebuild this as many times as I want without angering my non-existent listeners.

You can find v4.0 on branch 4.0-beta. You can also find a tagged image for the beta branch on Docker Hub as well. ​v4 provides support for extensions/plugins using Boost, and moves around or even reimplements some extensions such as the uploaders. You should install using make install instead of moving files around, or use the install.sh script.

My little hack works, but for some of the front ends I need to do things like sed the json and I'm not a huge fan.

I'm also a fan of piping things around for quick queries, but if you're building out an application for this, it seems you'd be better off using also having that application parse json and cast values. I'd imagine you can do this server-side, but you could possibly do this just as well client-side in-browser.

Honestly a generic "iWantHex=true" and just convert nothing would be nice, or even better a per item and/or per system option to not convert would be great. I can imagine even just in my local area that some departments use hex and some use decimal with the unit number. I'll decode a few more and see how needed that is.

I don't think this is a high priority request, but I don't think it's incredibly difficult to address either, so I'd love to hear the maintainer's thoughts.

Not disagreeing with you, I'd much rather work on hex values across the board, but the use of decimal values is pretty strongly ingrained already both for ingested values and outputs, that working on this at the core is indeed closer to being "incredibly difficult to address" than it is trivial.

Applying some sort of "output transformation filter" would also require a lot of handling, not just config file handling additions and parsing judgement, but also output management for every single thing that gets consumed.

A simpler solution (which leans on the user) that solves your problem right now would be to have an uploadScript that modifies call jsons after the fact, loading the json, enumerating through srcList and replacing values in-situ or creating a new json. But if you're already handling the jsons, you might as well just integrate it into your application, right?

[robotastic]

Yea, the right way to do this would be with input/output format converters. This was sort of started with some of the frequency output. The trick would be making sure it is done the same everywhere. If this could be done in a compact way, I would be supportive of merging it in if someone wanted to tackle it. It would probably have to default to Decimal to keep things backwards compatible. I think I would also have to check on the OpenMHz side to make sure Hex numbers are supported. Some of the parsers maybe looking for decimal integers and would fall over if they saw any Alpha.

[ZeroChaos-]

so after some quick testing, seding a hex representation into the json is a bad idea as it expects unquoted numbers and hex may violate that. adding quotes makes the json right, but then rdio scanner (what I'm testing with because it looked easy to set up) can't read the id since it's not expecting a string. I still think offering hex would be a great addition, but it looks to be a bit more painful as the whole ecosystem has to support it.

On the bright side, if you are a reader looking to solve your problems, I can highly recommend the unitTagsFile. I quite literally add "binary,hex" for each of the units I want to convert and the tag shows in the logs. As a short term solution, this helps more than a little.