search

travisgoodspeed / md380tools

Firmware patches for the TYT-MD380 handheld radio.
804 stars 244 forks source link

CHIRP Driver #41

Open travisgoodspeed opened 8 years ago

travisgoodspeed commented 8 years ago

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

m0ivq commented 8 years ago

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

travisgoodspeed commented 8 years ago

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.

m0ivq commented 8 years ago

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.

rct commented 8 years ago

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

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

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

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
ZeroChaos- commented 8 years ago

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.

travisgoodspeed commented 8 years ago

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?

ZeroChaos- commented 8 years ago

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?

rct commented 8 years ago

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?
travisgoodspeed commented 8 years ago

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.

rct commented 8 years ago

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

Also see #3, and #18

ghost commented 8 years ago

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

ghost commented 8 years ago

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.

rct commented 8 years ago

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

sijskes commented 8 years ago

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

ghost commented 8 years ago

@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