[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.
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.danpla... 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@jmlzone.com To: chirp_devel@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@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
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@yahoo.com To: "chirp_devel@intrepid.danplanet.com" chirp_devel@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.danpla... 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@jmlzone.com To: chirp_devel@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@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
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@yahoo.com To: "chirp_devel@intrepid.danplanet.com" chirp_devel@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@yahoo.com To: "chirp_devel@intrepid.danplanet.com" chirp_devel@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.danpla... 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@jmlzone.com To: chirp_devel@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@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
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@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@yahoo.com To: "chirp_devel@intrepid.danplanet.com" chirp_devel@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@yahoo.com To: "chirp_devel@intrepid.danplanet.com" chirp_devel@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@jmlzone.com To: chirp_devel@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:
- 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.
- 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.
- 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.
- 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.
- 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@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
participants (3)
-
James Lee -
Jens Jensen -
jml