[chirp_devel] Could use a few hints on tyt - th_9800

Sun Dec 14 15:43:04 PST 2014

looks like there is a "channel active" bit flag for each channel starting at 0xCB80 (+10h in the chirp saved image), and then repeated again at 0xCC00 (+10h). The first block appears to be the one which is effective in the radio. Unsure why the second block... Experimentation may reveal why.
Also, to make offsets simpler to deal with, I'm thinking of moving storage of the radio ident string to the end of the chirp image. So 0x10000 main image+ 0x10 ident string. Currently it's 0x10 ident + 0xFF00 (due to the skip of first 0x100 bytes - mimicing the oem sw read).
-Jens
      From: Jens Jensen <af5mi at yahoo.com>
 To: "chirp_devel at intrepid.danplanet.com" <chirp_devel at intrepid.danplanet.com> 
 Sent: Sunday, December 14, 2014 5:03 PM
 Subject: Re: [chirp_devel] Could use a few hints on tyt - th_9800

Hi James.Ok, I too have got this started - let's review and merge our work.My email randomly addresses a few of your questions.
Here is my partially functional starter th9800.py, refactored a bit from Tom's start, and a few upload/download bits borrowed from other tyt radio modules.
https://gist.github.com/zerog2k/2ad80b5b58a924a98bdb

Since the file-backed and radio-clone classes share quite a bit of commonality, and I'm sure the oem .dat file and the radios memory are possibly identical, only differing by the offsets, and the way you transfer them, I have factored most of this out to a common base class, TYTTH9800Base, then subclassed into the file-backed class and the radio-class, so that only the necessary specific parts are in child classes.
Since the memory map will probably be the same, with just differences in offset, I have managed that with a trick to the way the memory string is read, using a format string to change up the offset where it starts applying the map to the image.
This experimental th9800.py module will download and upload a memory image, which we can start using to further work out the channel, and later - settings, maps.
On radio upload/download.here are serial session capture logs of oem software:http://chirp.danplanet.com/issues/1353#note-14

An interesting observation is that the oem software skips the first 0x100 bytes on download, but skips a different section (near the end) on upload:
download:0x0100 - 0xFFFF(also, on download before the main block, oem sw reads an 80h block at 0xCC00. Wild guess that this might have frequency ranges or capabilities - not sure why this needs to be read early. We'll probably find out later.)
upload:0x0000 - 0xF3FF0xFF00 - 0xFFFF
I'm guessing these other sections might contain some special information. We probably want to tread with caution, as it could be something simple, or could be something dangerous to manipulate (especially between radios) such as a calibration or configuration data block, or other individual-radio-specific data.

Regarding the dev process:basically, chirp uses mercurial "message queue" extension to do patch management. This allows you to work on things and pop/push patches which can be emailed to devel list for review and merging. (I totally prefer github fork-n-pull-request model for so many reasons - but that's probably another thread.) Review:http://chirp.danplanet.com/projects/chirp/wiki/Developershttp://chirp.danplanet.com/projects/chirp/wiki/DevelopersProcess

If you want to talk offline to sync up so we can break up the work, you can email me off the list and we can chat on skype or phone...
-Jens

     From: jml <jml at jmlzone.com>
 To: chirp_devel at intrepid.danplanet.com 
 Sent: Sunday, December 14, 2014 1:30 PM
 Subject: [chirp_devel] Could use a few hints on tyt - th_9800

Hi,
  Sorry in advance this will be a long email.

With a little advice from Tom Haward I have gotten started on adding the closing support to the tyt-th9800.  First some status and background, then a bunch of questions.

Status:
  First I do have a tyt9800 and the oem pc (windows xp) software and cable working.  I did use portmon and figure out what the radio protocol was.
  I do have the hex dump of my files from the oem software and compared them to what I see in the transfer.
  I have managed to mangle th9800.py to get it to download (on my mac) my radio and hex dump to stdout.
  I have identified some of the memory blocks and bits that Tom did not yet tag in his cut at reading the .dat file.

Background:
  Its been around 5 years since I did python so I’m a bit rusty, and generally more familiar with C, Perl and TCL (and of course Verilog)
  Being that I hate windows 7 and 8 I decided to go Mac.  I find the mac easy since I treat it like linux.  I have the mac setup for python with he proper packages to run the script form of chip.  (I also have a linux server at my disposal but  I am using it for file storage and utilities not Chirp development).
  I am familiar with hg for versioning and have cloned the repository to my mac and even done a pull and update.

Now for the first of what may be myriad of questions:
1) The channel memory format in the download vs the file are identical, however, the offset is different. So I wanted to re-use the struct that Tom defined and just define a new TH9800_MEM_FORMAT and rename his to TH9800_FILE_FORMAT.  I wanted to share the struct but could not figure out how to do that.

2) Tom Registered as chirp_common.FileBackedRadio, so when I tried to register as chirp_common.CloneModeRaio I got an error so I just added a x to the name of the radio to debug.  Obviously I want to share much of his code so I need to better understand how to merge the file IO stuff with with clone stuff.

3) Other than the template.py is there a cook book or tutorial on how it add things to chirp and how the framework of chirp is preferred to use. eventually I am going to know how to handle the busy lock out on some channels and I want to figure out how to program the 6 shortcut buttons on the face that are in the stat but not supported by the oem software.

4) When I have used HG in the past I would locally “hg commit” then “hg push”.  I am a bit new to how open source software is managed so if I have something worth sharing what is the proper avenue.

5) I have not yet gotten Toms functions to display the radio data after I have downloaded, but the hex dump to stout is good so I will continue to work on that while I wait for a response, but I think that his functions are in the class TYTTH9800File while the rest of my code is in class TYTTH9800Radio so I will the importing the functions but I think there needs to be some better solution here. Sugegstions?

Please feel free to point me to additional reading and if someone who is more fluent at python can can take a swag and merging my upload/download with toms code better than I did, I would welcome the help.

James N1DDK.

_______________________________________________
chirp_devel mailing list
chirp_devel at intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20141214/75f28645/attachment-0001.html 