Patch to monitor all color codes about md380tools HOT 31 CLOSED

We'll track RAS in Issue #42.

from md380tools.

Giving it some more thought, we can do without that register setting by starting a background thread that tries each color code (and maybe also timeslot?) in sequence until the first packet arrive, then displays and halts on that setting.

The OS and hardware functions for this have already been identified, but we'll need to understand the menu structure well enough to add a new entry. I'll dig up my notes on it and see about inserting a new menu item for scanning.

from md380tools.

I added support for peeking and poking C5000 registers from the host over USB, then wrote a quick script that scans for the color codes of the current channel by repeatedly changing the receiving code and looking for incoming traffic.

md380-tool findcc will identify the colors in use.

I can do the same on the device once I figure out how to add new menu items.

from md380tools.

Could you please run a quick test to verify that audio is only accepted when the color codes match?

The function that I call dmr_contact_check(void *hdr) at 0x0803f33c does plenty of checks on two address fields in the packet, but I don't see it checking for the color code or any other 5-bit field. If in fact the color code is squelching the audio, we could perhaps patch dmr_apple_squelch(char *foo, int squelch) at 0x080303b4 to unsquelch all audio, regardless of its source.

Assigning to @rct to reassign to me after verifying that the radio does squelch on an unmatched color code.

from md380tools.

Which firmware should I test with?

from md380tools.

Use 2.032 for everything until we migrate to a new version.

For the test:

1. Configure two MD380 radios to 441.0 simplex with any group as the Contact Name.
2. Configure the first radio to Color Code 1 and the second radio to Color Code 2.
3. Does audio come through?

from md380tools.

I only have one DMR radio so far. If there is a test I can do with repeaters let me know.

By which firmware, should I be running the experimental version of the patch or is private good enough?

from md380tools.

Experimental or the stock firmware would work for the test.

I performed this test using two of the UHF radios on 441.0 simplex, and the color code does seem to be checked somewhere. Setting the color code to 15 (0xF) did not seem to enable any built-in monitor mode for the color code.

I'm hunting through the code looking for a 4-bit check.

from md380tools.

I don't have a good handle on it yet, but I think that might depend on the admit criteria for the channel from some of the stuff I've read on the Yahoo group.

from md380tools.

Looks like the upper half of the byte at 0x2001c9b5 is the color code, and that this code is checked in multiple places of c5000_handle_interrupt() at 0x0803e900. I'm writing an experimental patch now, should be ready in the time it takes me to drink a coffee or two.

from md380tools.

You are awesome.

from md380tools.

Some notes:

1. Bits 7 to 4 of C5000 register 0x52 are "接收到的 CC", the Incoming Color Code.
2. These are checked multiple times in the C5000 interrupt handler, before it calls dmr_apply_squelch().
3. The comparison is performed at 0x0803ea60 and the branch is at 0x0803ea62.

[0x0803ea60]> pdx 2
            0x0803ea60      8842           cmp r0, r1                  ; Compare the color codes.
            0x0803ea62      40f0fd80       bne.w 0x803ec60             ; Skip the decoding if they don't match.
[0x0803ea60]> 

4. Nopping both half-words of the branch ought to create promiscuous mode with respect to color code, but it doesn't.
5. There is also a check for the color entry at late entry.

[0x0803e992]> pdx 2
│           0x0803e992      8842           cmp r0, r1                  ; Check late entry color code.
│           0x0803e994      40f06481       bne.w 0x803ec60             ; Jump if they don't match.
[0x0803e992]> 

6. Patching that check isn't enough.

I'll continue by chasing all references to the upper four bits of 0x2001c9b5.

from md380tools.

Patching a third check of the color code still doesn't produce audio, so I'm suspecting that the check is being performed both in software on the STM32 and in hardware on the C5000.

Some handy C5000 registers:

1. 0x1F contains the locate color code.
2. 0x52 contains the remote color code.
3. 0x20 and 0x21 hold the access policy, which would might suppress the event, but which are probably just for clear channel assessment before transmission.

from md380tools.

These patches combined aren't enough to enable audio for an unmatched color code. I'll return to this after I wire up a JTAG debugger.

    patcher.nopout(0x0803ea62,0xf040);  #Main CC check.                                                                                                                                                      
    patcher.nopout(0x0803ea64,0x80fd);
    patcher.nopout(0x0803e994,0xf040);  #Late Entry CC check.                                                                                                                                                
    patcher.nopout(0x0803e996,0x8164);
    patcher.sethword(0x0803fd8e,0xe02d, #Check in dmr_dll_parser().                                                                                                                                          
                     0xd02d);
    patcher.nopout(0x0803eafe,0xf100); #Disable CRC check, in case CC is included.                                                                                                                           
    patcher.nopout(0x0803eb00,0x80af);

from md380tools.

Is this idea already dead, or is still worked on it? Would be one of the coolest features I could imagine :)

from md380tools.

It'll come, but it will probably require a bit of help from a Linux or Android host. I'll scan for color codes by rotating between the 16 possible colors until a packet arrives.

Expect this in two to three weeks, when the host side software become more stable and the protocol extension more featureful.

from md380tools.

The Connect Systems CS750 has a monitor mode that admits all color codes, so it's likely possible to instruct the C5000 to not discriminate. Or they could be doing the same thing Travis suggests.

from md380tools.

I suppose that I'll call them up today and order a CS750. They were quite fast in shipping my CS800.

from md380tools.

The CS800 may have the same monitor mode.

from md380tools.

This sounds much more promising; an external solution is not really the big thing. When I need a PC anyway I just would let my SDR handle it all, reception, decoding, analyzing :)

I also searched through the C5000 documentation, but I could not make out anything new.

from md380tools.

Recent patches hook dmr_call_start(), dmr_call_end(), and dmr_hanlde_data() in dmr.c in order to trigger on arriving audio and text messages.

These hooks apply before the call is interpreted, and they show that indeed the color code check at 0x0803ea62 is redundant. To be agnostic about the color code, I think we'll need to find a register setting that allows for it.

from md380tools.

Travis, when we try to listen to DMR repeater with RAS code activated, radio don't sound anything and also don't show any codes. Only green LED and RSSI meter active. But software "DSD Plus" shows traffic, color code and station IDs.
May be you can kindly pay attention to this, and also remove RAS code check from firmware?

from md380tools.

I've been going through the ARM code in R2 looking at this but not made any progress, how have you managed to get function names from the code, I don't see names like dmr_apply_squelch() that you mention?

from md380tools.

Apologies, the vast majority of symbols haven't yet been imported. I'll take care of that when I get some time.

from md380tools.

It seems like a slow way to open the channel if the cc isn't known, would it be possible to trick the C5000 to always thinking that a particular cc was in use, say 15, by forcing register 0x52 to 0xF ??

from md380tools.

Nope, register 0x52 is read-only and even if it weren't, the C5000 ignores any non-matching packets in hardware.

Somewhere there ought to be a mask that'll match on more than one color code, probably as a reserved bit of a register.

--Travis

from md380tools.

Were you able to watch what the CS750 / CS800 does when it goes into Monitor Mode?
I also wonder if Jerry would just tell you what they did to make that work.

from md380tools.

Closing this issue as it doesn't appear that the C5000 supports a color code monitor mode. Will reopen if such a register is found.

from md380tools.

I know this issue has been closed, but is it possible to patch the first compare colorcode to read the value of the incoming colorcode (0x52 bits 4-7) and then change the current channels colorcode to match thus enabling receive on the next interrupt?

from md380tools.

No, the color code register isn't updated when the CC doesn't match. You are welcome to verify this yourself by running md380-tool c5000 to dump the register contents of the radio.

We'd all love this feature, but I'm sorry to say that I don't think the hardware allows it. The best we'll get is scanning, as is performed by md380-tool findcc.

73 from Pizza Rat City,
--Travis KK4VCZ

from md380tools.

any findings with CS radio?

from md380tools.