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

[James Lee]

Hi Jens,
  Yes funny that we both started to work on it at about the same time.
I may need to wait until next weekend before I have a chance to look
at it again.  I'll look at your changes and see what I can learn.

  Other than the duplication of work on noticing the odd download and
upload behavior it sounds like you may have taken a cleaner approach
to the handling of the classes. I will have to look.

  Other than getting the basic download to work and display I managed
to add the 4 levels of power settings to it.  Since I have some issues
with my audio reports on 6m with the radio i learned that some of the
settings like:
Busy channel lockout,
Bandwidth,
Companding,
and emphasis
are important on this radio and may be random in the initial image.
So I plan to add those bits and clarify some of the unknowns in the
per channel structure.

I would also love to learn how to unlock the 220 capability and add
that band into it.

So in short, I will look at what you have done (likely on the weekend)
and I will also try to figure out the all the known bits that are
controllable through the OEM software.

I also want to figure out how to program the 6 short cut buttons on
the radio that don't program through the OEM software but are
overwritten on a download so it looks like I can program them on the
radio and then download and dump.

If you have other ideas as how I can be helpful without duplicating
work as we did this weekend, let me know,

James
N1DDK.


On Sun, Dec 14, 2014 at 11:20 PM, Jens Jensen <af5mi at yahoo.com> wrote:
> Ok,
> I was able to get the channel active bit flags mostly working. I noticed
> some strange behavior with right vfo in memory mode not seeing some of the
> higher numbered channels, while left vfo will cycle through them.
> https://gist.github.com/zerog2k/2ad80b5b58a924a98bdb
>
> This is a development-only module right now. Lots of debugging sprinkled
> throughout.
> (also made me wish we had a CHIRP_DEBUG env var switch right in the
> developer menu - so we dont have to show people how to set an env var to get
> all the juicy debug output for issues)
>
> -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:43 PM
> Subject: Re: [chirp_devel] Could use a few hints on tyt - th_9800
>
> 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 - 0xF3FF
> 0xFF00 - 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/Developers
> http://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
>
>
>
>
>