CHIRP Driver

M0IVQ has been kind enough to send us the remaining bitfields for the codeplug memories. Close this issue when they have been imported into our CHIRP driver, and perhaps also into the patched firmware headers.

MD-380%20Memory%20Map.xlsx

I've added the 'General Settings' tab as well as correcting a couple of errors. (for some reason I couldn't upload the excel file directly so had to zip it. Hope it is of some help.

MD380MemoryMapV3.zip

Thank you kindly, neighbor. I've pushed your latest map.

Lately, progress has stalled a bit on the CHIRP plugin but it's speeding up on the Android client, which ought to free just as many folks from Tytera CPS.

It may be worth adding a note that all offsets given in the map are for .rdt files and not the headerless .bin files. I will add offsets for .bin files once I have decoded enough of the codeplug to release V4.

For what it's worth, the .rdt file contains:

• a 549 byte header
• the contents of the .bin file as is.
• 16 byte footer/trailer.

So .rdt vs .bin offsets are - 549. No need to remap. For example:

• Contacts are at 0x61a5 vs 0x5f80 (549)
• Scanlist 0x18a85 vs 0x18860
• Channels 0x1f025 vs 1ee0 (549)

The .rdt header has: (from some notes I've made)

• the radio type, DR780 for the MD-380 vs. D680 for the CS700.
• A Unique device ID at 0x16d - 0x178 (This is shown in the CPS software though reversed from what's in memory.
• Model/Control bytes at 0x136 and 0x22c.
• Frequency range: 0x139 - 0x13c (which are also in the .bin at 0x1f037-0x1f03b (using .rdt offsets)

The .rdt footer/trailer was the same on a half dozen or so files I examined so I wasn't able to figure out what it's meaning was. On the files I looked at the contents were always

00 02 11 df 83 04 1a 01 55 46 44 10 12 71 65 8e

could we make "officially submitting this driver to chirp" a part of this ticket? If it's incomplete and not ready that makes sense, but once you are happy with it this should be pushed upstream so everyone can benefit.

The CHIRP project is welcome to take this over at their earliest convenience, and we'll close this issue once they've taken it.

Could someone volunteer to coordinate creating an issue in CHIRP's tracker and handing off what's done of the plugin, for them to complete it?

although I have nothing to do with this project or chirp, I have submitted things to them before. I am happy to submit this to them, but it looks like there are a few bugs open against this driver still that should be cleared up before getting a wider audience. or is this ready to submit to chirp?

I doubt the current driver is in a form they'd accept it.

Chirp currently supports only serial, conventional radios. There are several areas of work:

1. Dealing with a non-serial radio, or stubbing out the serial stuff in a way that's acceptable to them. The easy for the developer/hard for the user approach is to just stub out serial and rely on md380too or the CPS software to read/write the radio.
2. To get direct USB read/write communications in chrip is going to require changing the build process for Windows, Mac, and Linux to incorporate pyusb and libusb. While this isn't rocket science, it might be someone time consuming and error prone to get something that works on all of the flavors of Windows, MacOS, and Linux that people use chirp on. At this point there aren't really any chirp stable build because the daily builds are stable enough through a fair about of unit testing. If there is a period where the daily builds are going to be less stable, there will need to be some changes to actually cut a stable release and get people to stick to that release until the daily builds are stable enough again.
3. Add support for the other "tables" in the code plug that are linked into the channels structure. Zones, Scan lists, Digital Contacts (talk groups), These "tables" all need to be linked so that moving things around maintains the referential integrity. So there is both an underlying model that needs to be implemented correctly, and a GUI view for it. Zones are similar to banks. I believe there has been some work to get bank model implemented that would handle zones. I don't know how complete it is: If you delete/move a channel, something you can't readily do in CPS, do the corresponding zone references to the channels get updated?

Let's ask them how (and if) they'd like to proceed. It might be that the radio is just too different to fit their framework.

@mach327 was going to engage some of the chirp developers, see #4,

Also see #3, and #18

Still haven't contacted them, been swamped with other work.

Latest update: Something working for programming entirely without the original CPS can be seen with the master branch of my DMR_Programmer, which uses the master branch of my md380tools and a chirp fork that i made before i knew about git-hg (I'll get that fixed soon (Edit to add: Fixed!)). The forks were necessary due to what i believe are necessary, breaking changes in Chirp and md380tools.

The current official chirp driver also has some updates including programmable button documentation, admit criteria, vox, rxgroups, encryption keys, and menu options. RXGroups appears to be correct, since my radio works and receives correctly - the other stuff is largely or completely untested.

FYI - Tom Hayward, one of the most active chirp developers has been working on MD-380 support in chirp. He's run into some things that need to be fixed in the current model implementations, but seems to be making some progress.

Putting a link here to the first RFC patch submitted to chirp_devel just to tie the activities together: http://intrepid.danplanet.com/pipermail/chirp_devel/2016-September/004240.html

@rct can you tell me where his code lives on the web?

@sijskes It doesn't seem to be on the web. Their workflow doesn't really encourage it. But he's made some changes to the chirp driver in particular that we might find interesting: http://intrepid.danplanet.com/pipermail/chirp_devel/2016-September/004244.html