Re: [chirp_devel] chirp_devel Digest, Vol 20, Issue 13
All,
OK, I am trying to start on the IC-V80 driver:
- Devl env OK on my 32 bit PC
- Created a driver "icv80.py" by renaming the one for the IC-T70. That is their identical HT but dual band, so is presumably close
- Did a download and saw the mode string 0x32 0x54 0x00 0x01. Changed _model to match and HT seems to now be recognized
- Increased _memsize greatly and ran a new download. Where is the debug log that you speak of? I have no familiarity with this lang or env.
So I have error messages of course, but nothing that shows a last address. Should this be in the command prompt window that I used to initiate the program? That is where I get error messages. Or is there some debug log somewhere else in Python? I'm familiar with using *nix, but never developed in it.
73, Drew K3PA
----------------------------------------------------------------------
Hi Drew,
I?d like to help by working on a driver for my IC-V80 HT. How to start?
What platform are you on? Windows? If so, get started with these instructions:
http://chirp.danplanet.com/projects/chirp/wiki/DevelopersWin32Environment
Once you're able to run chirp directly from the source tree, you can start work on a driver. Take a look at the template driver for a start, which is in chirp/template.py. Also look at some of the other Icom drivers, since they share a lot (like all of the clone code). You may want to start by taking something similar and simple, like the ict8.py file as a starting point. Copy that to icv8.py and change the names within the file. Simply doing that will cause the new model to show up in the download box.
Here is the rough set of steps after that:
1. Figure out what the model identifier for that radio is. This can be done by trying to download it and watching the debug log to see what it finds from the radio. Change the _model in your driver to match.
2. Figure out what the size of the device's memory is. Do this by setting the memsize in your driver to something large and trigger a download. The debug log will tell you what the last address was before the radio stopped sending.
3. Capture the "end frame" from the end of the clone process in the debug log during step 2, and adjust in your driver appropriately.
4. Now you should be able to get a clean download from the radio. Save that to a .img file and start examining it in a hex editor. Depending on how the radio is designed, this may be obvious, or it may require doing a series of changes on the radio, followed by a download, followed by looking at the hex dumps. You'll be modifying the MEM_FORMAT structure definition in your driver file to tell it where and how the memories are laid out.
Once you get to step 4, we may be able to help you spot some common Icom-isms to get you started.
Make sense?
-- Dan Smith www.danplanet.com KK7DS
- Created a driver "icv80.py" by renaming the one for the IC-T70. That is
their identical HT but dual band, so is presumably close
Probably, but not definitely :)
It's possible that they're very similar and that just tweaking the mem_format (or the offset where it starts looking for it) is all that is needed. If so, it may be best to make the V80 driver inherit from the T70, and only change a few things. However, keeping it separate like you have it now is probably the best way to start. If you start making minor tweaks to T70 code, that would be your indication that sharing is warranted.
- Did a download and saw the mode string 0x32 0x54 0x00 0x01. Changed
_model to match and HT seems to now be recognized
Cool.
- Increased _memsize greatly and ran a new download. Where is the debug log
that you speak of? I have no familiarity with this lang or env.
It's not a language or environment thing, it's a CHIRP thing:
http://chirp.danplanet.com/projects/chirp/wiki/How_to_report_issues
There is a section on there for "getting your debug log".
So I have error messages of course, but nothing that shows a last address.
The debug log will give you what you need.
Should this be in the command prompt window that I used to initiate the program? That is where I get error messages. Or is there some debug log somewhere else in Python? I'm familiar with using *nix, but never developed in it.
Oh, you're running from the command-line, then yeah, the debug log contents are just echoed to the console in that case. When the download is complete, you should see it echo the "Last addr:" and "End Frame:" to the console there. It may have scrolled off the screen amidst all the failures to parse the V80 data in T70 format. Might be good to pipe it to a file for perusal or something.
Sounds like you're getting there... :)
Dan,
Your directions talk about what to do with the debug log, but they never say where it is. I don't see it in ..\chirp.hg. Also, no idea how to pipe it to a file. Don't know this env.
Thx, Drew
-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com [mailto:chirp_devel-bounces@intrepid.danplanet.com] On Behalf Of Dan Smith Sent: January 01, 2013 14:30 To: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] chirp_devel Digest, Vol 20, Issue 13
- Created a driver "icv80.py" by renaming the one for the IC-T70.
That is their identical HT but dual band, so is presumably close
Probably, but not definitely :)
It's possible that they're very similar and that just tweaking the mem_format (or the offset where it starts looking for it) is all that is needed. If so, it may be best to make the V80 driver inherit from the T70, and only change a few things. However, keeping it separate like you have it now is probably the best way to start. If you start making minor tweaks to T70 code, that would be your indication that sharing is warranted.
- Did a download and saw the mode string 0x32 0x54 0x00 0x01. Changed
_model to match and HT seems to now be recognized
Cool.
- Increased _memsize greatly and ran a new download. Where is the
debug log that you speak of? I have no familiarity with this lang or env.
It's not a language or environment thing, it's a CHIRP thing:
http://chirp.danplanet.com/projects/chirp/wiki/How_to_report_issues
There is a section on there for "getting your debug log".
So I have error messages of course, but nothing that shows a last address.
The debug log will give you what you need.
Should this be in the command prompt window that I used to initiate the program? That is where I get error messages. Or is there some debug log somewhere else in Python? I'm familiar with using *nix, but never developed in it.
Oh, you're running from the command-line, then yeah, the debug log contents are just echoed to the console in that case. When the download is complete, you should see it echo the "Last addr:" and "End Frame:" to the console there. It may have scrolled off the screen amidst all the failures to parse the V80 data in T70 format. Might be good to pipe it to a file for perusal or something.
Sounds like you're getting there... :)
-- Dan Smith www.danplanet.com KK7DS
Your directions talk about what to do with the debug log, but they never say where it is.
Yes, they do:
Windows Go to Start->Run and type "%APPDATA%\CHIRP". Your debug.log file will be in the folder that opens.
However, as I said, if you're running from the command line, the contents go to the screen, not the log.
Also, no idea how to pipe it to a file. Don't know this env.
In this case "this env" is Windows. The standard way of redirecting the output of a program to a file is all you need:
C:\foo\chirp.hg> python chirpw > my_log_file.txt
No, that only includes debug logs from yesterday before I installed the dev env...
-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com [mailto:chirp_devel-bounces@intrepid.danplanet.com] On Behalf Of Dan Smith Sent: January 01, 2013 14:50 To: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] chirp_devel Digest, Vol 20, Issue 13
Your directions talk about what to do with the debug log, but they never say where it is.
Yes, they do:
Windows Go to Start->Run and type "%APPDATA%\CHIRP". Your debug.log file will be
in the folder that opens.
However, as I said, if you're running from the command line, the contents go to the screen, not the log.
Also, no idea how to pipe it to a file. Don't know this env.
In this case "this env" is Windows. The standard way of redirecting the output of a program to a file is all you need:
C:\foo\chirp.hg> python chirpw > my_log_file.txt
-- Dan Smith www.danplanet.com KK7DS
No, that only includes debug logs from yesterday before I installed the dev env...
Sorry, I don't mean to get overly blunt, but are you even reading my messages?
From your quoted text, I said:
However, as I said, if you're running from the command line, the contents go to the screen, not the log.
Which implies that the debug log in the profile area is only going to be from the last time you ran it normally.
This is what you want in order to capture the console output to a file for later examination:
In this case "this env" is Windows. The standard way of redirecting the output of a program to a file is all you need:
C:\foo\chirp.hg> python chirpw > my_log_file.txt
Dan,
I'm just following the instructions to the best of my ability. I am not aware of any other way to run this except from the command line, because that is what the developer instructions noted. "python chirpw" from a Windows command prompt.
I was able to get the log from piping as you noted. I did not remember how to do that, as we haven't used anything but an integrated dev env in many years. I don't know what is specific to Chirp vs Python vs the OS... I'm a hardware guy. Anyway, I did not see the last address information you noted, unless End frame (11) means something I am unfamiliar with. 0e80 was the size I used, and this resulted in:
User selected Icom IC-V80 on port COM10 Clone thread started Sent clone frame ICF Size change from 0 to 32 at 0000 End frame (11): 000: 49 63 6f 6d 20 49 6e 63 Icom.Inc 008: 2e 37 34 00 00 00 00 00 .74.....
Last addr: 0e80 Clone thread ended Exception running RadioJob: list index out of range -- Exception: -- Traceback (most recent call last): File "P:\Chirp\chirp.hg\chirpui\common.py", line 97, in _execute result = func(*self.args, **self.kwargs) File "P:\Chirp\chirp.hg\chirp\icv80.py", line 95, in get_memory mem.ctone = chirp_common.TONES[_mem.ctone - 1] IndexError: list index out of range
Anyway, you seem to be looking for someone with more experience at this than I have, so I'd best pass on driver work. Maybe the info above is useful to someone... Thanks for the fine program.
73, Drew K3PA
-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com [mailto:chirp_devel-bounces@intrepid.danplanet.com] On Behalf Of Dan Smith Sent: January 01, 2013 15:01 To: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] chirp_devel Digest, Vol 20, Issue 13
No, that only includes debug logs from yesterday before I installed the dev env...
Sorry, I don't mean to get overly blunt, but are you even reading my messages?
From your quoted text, I said:
However, as I said, if you're running from the command line, the contents go to the screen, not the log.
Which implies that the debug log in the profile area is only going to be from the last time you ran it normally.
This is what you want in order to capture the console output to a file for later examination:
In this case "this env" is Windows. The standard way of redirecting the output of a program to a file is all you need:
C:\foo\chirp.hg> python chirpw > my_log_file.txt
-- Dan Smith www.danplanet.com KK7DS
0e80 was the size I used, and this resulted in:
Right, and if you look at this:
Last addr: 0e80
It's saying it stopped there. That's because the radio has a larger memory than 0x0E80, and so the driver stopped because you told it to, not because the radio refused a read. If you set the memsize to 0x10000 or something else large, then you should see that "Last addr" change to the actual end. The T70's size is 0x19E0, which is much larger than the 0x0E80 you told it to look for.
Anyway, you seem to be looking for someone with more experience at this than I have, so I'd best pass on driver work. Maybe the info above is useful to someone...
Well, that's your call, I didn't mean to scare you off. Writing a driver is not trivial thing and it does require some study. I'm not a Windows developer, but I did expect that even a power user would have familiarity with the platform enough to search for files and redirect output. Maybe that's a bad assumption on my part.
I won't push you, but I think you're pretty close to at least getting an image of the radio. Once you do, all that is left is sifting through it looking for the data and fields you need...
Dan,
Thank you for explaining. I also found I made an error and was using the wrong driver to begin. Some of the names are very close; ict7h vs ict70. Got the new driver and set the things I already knew; model string, number of memories, band limits etc.
Began again and got a memory size of 0xE80.
Next thing: I know from the manual that the T70 uses ASCII channel labels and had memory banks. The V80 has neither. Do you recommend I just delete those items from the structure and try again, or how do you go about reverse engineering the memory channel structure?
-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com [mailto:chirp_devel-bounces@intrepid.danplanet.com] On Behalf Of Dan Smith Sent: January 01, 2013 15:28 To: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] chirp_devel Digest, Vol 20, Issue 13
0e80 was the size I used, and this resulted in:
Right, and if you look at this:
Last addr: 0e80
It's saying it stopped there. That's because the radio has a larger memory than 0x0E80, and so the driver stopped because you told it to, not because the radio refused a read. If you set the memsize to 0x10000 or something else large, then you should see that "Last addr" change to the actual end. The T70's size is 0x19E0, which is much larger than the 0x0E80 you told it to look for.
Anyway, you seem to be looking for someone with more experience at this than I have, so I'd best pass on driver work. Maybe the info above is useful to someone...
Well, that's your call, I didn't mean to scare you off. Writing a driver is not trivial thing and it does require some study. I'm not a Windows developer, but I did expect that even a power user would have familiarity with the platform enough to search for files and redirect output. Maybe that's a bad assumption on my part.
I won't push you, but I think you're pretty close to at least getting an image of the radio. Once you do, all that is left is sifting through it looking for the data and fields you need...
-- Dan Smith www.danplanet.com KK7DS
Thank you for explaining. I also found I made an error and was using the wrong driver to begin. Some of the names are very close; ict7h vs ict70. Got the new driver and set the things I already knew; model string, number of memories, band limits etc.
Ah, okay, makes sense.
Began again and got a memory size of 0xE80.
Next thing: I know from the manual that the T70 uses ASCII channel labels and had memory banks. The V80 has neither. Do you recommend I just delete those items from the structure and try again, or how do you go about reverse engineering the memory channel structure?
The mem_format structure is only used for parsing after the image has been downloaded, not for the download itself, so no need to worry about that part until you're confident that you're getting the whole image.
So, yes, the alpha labels, banks, and bank names will need to come out of the structure definition. Once you get a clean download of the image, you'll need to start sorting through the image contents to find the relevant settings (frequency, tones, etc). When you do that, you should be able to immediately see which (if any) of the structure definition from the T70 matches the V80. If it looks totally different, then it may be better to start a new definition from scratch, using the other one just as a syntax guide.
Once you get an image, post it here for folks to look at, with a little info about what frequencies are stored in the first few channels. I may be able to help you spot some of the stuff to get you started.
I dont follow, where do I find the image?
...sent from my cell phone
On Jan 1, 2013, at 18:54, Dan Smith dsmith@danplanet.com wrote:
Thank you for explaining. I also found I made an error and was using the wrong driver to begin. Some of the names are very close; ict7h vs ict70. Got the new driver and set the things I already knew; model string, number of memories, band limits etc.
Ah, okay, makes sense.
Began again and got a memory size of 0xE80.
Next thing: I know from the manual that the T70 uses ASCII channel labels and had memory banks. The V80 has neither. Do you recommend I just delete those items from the structure and try again, or how do you go about reverse engineering the memory channel structure?
The mem_format structure is only used for parsing after the image has been downloaded, not for the download itself, so no need to worry about that part until you're confident that you're getting the whole image.
So, yes, the alpha labels, banks, and bank names will need to come out of the structure definition. Once you get a clean download of the image, you'll need to start sorting through the image contents to find the relevant settings (frequency, tones, etc). When you do that, you should be able to immediately see which (if any) of the structure definition from the T70 matches the V80. If it looks totally different, then it may be better to start a new definition from scratch, using the other one just as a syntax guide.
Once you get an image, post it here for folks to look at, with a little info about what frequencies are stored in the first few channels. I may be able to help you spot some of the stuff to get you started.
-- Dan Smith www.danplanet.com KK7DS
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
Gents,
Here is the image from my Icom IC-V80. As confirmed by Icom's software, the first two memory locations are filled, and contain:
1) 146.52, simplex. No tone. Label AAAAA
2) 146.76, offset minus, 600 KHz. Tone, 88.5. Label BBBBB
It appears to me that a memory channel is 16 bytes long. The first two bytes appear to be frequency / 5000, not three as in IC-T70. So, I have changed frequency in the mem structure to ul16. The next two appear to be offset / 5000, same as IC-T70 . (I am aware of the IC-T70 changes to that for oddball spacings, which I will later confirm are the same here.) The next 5 bytes are the memory label. After that, I can start setting/unsetting bits and figure out the other features.
Is it correct that CTCSS tones are usually enumerated rather than literal values? Where can I find the enumerations?
Also, since this radio does not use memory banks, do I have to strip out any bank code and/or structures from the IC-T70 driver, or does setting:
rf.has_bank = FALSE
rf.has_bank_index = FALSE rf.has_bank_nmames = FALSE
...take care of all that?
Making the changes noted to the data structure and bank definitions does not result in the UI showing the correct frequency (it just says ERROR), so I am not clear on what else I am missing. Any tips appreciated.
73,
Drew K3PA
-----Original Message----- From: Drew Vonada-Smith [mailto:drew@whisperingwoods.org] Sent: January 01, 2013 16:34 To: 'chirp_devel@intrepid.danplanet.com' Subject: RE: [chirp_devel] chirp_devel Digest, Vol 20, Issue 13
Dan,
Thank you for explaining. I also found I made an error and was using the wrong driver to begin. Some of the names are very close; ict7h vs ict70. Got the new driver and set the things I already knew; model string, number of memories, band limits etc.
Began again and got a memory size of 0xE80.
Next thing: I know from the manual that the T70 uses ASCII channel labels and had memory banks. The V80 has neither. Do you recommend I just delete those items from the structure and try again, or how do you go about reverse engineering the memory channel structure?
-----Original Message-----
From: mailto:chirp_devel-bounces@intrepid.danplanet.com chirp_devel-bounces@intrepid.danplanet.com [ mailto:chirp_devel-bounces@intrepid.danplanet.com mailto:chirp_devel-bounces@intrepid.danplanet.com] On Behalf Of Dan Smith
Sent: January 01, 2013 15:28
To: mailto:chirp_devel@intrepid.danplanet.com chirp_devel@intrepid.danplanet.com
Subject: Re: [chirp_devel] chirp_devel Digest, Vol 20, Issue 13
0e80 was the size I used, and this resulted in:
Right, and if you look at this:
Last addr: 0e80
It's saying it stopped there. That's because the radio has a larger memory than 0x0E80, and so the driver stopped because you told it to, not because the radio refused a read. If you set the memsize to 0x10000 or something else large, then you should see that "Last addr" change to the actual end. The T70's size is 0x19E0, which is much larger than the
0x0E80 you told it to look for.
Anyway, you seem to be looking for someone with more experience at
this than I have, so I'd best pass on driver work. Maybe the info
above is useful to someone...
Well, that's your call, I didn't mean to scare you off. Writing a driver is not trivial thing and it does require some study. I'm not a Windows developer, but I did expect that even a power user would have familiarity with the platform enough to search for files and redirect output. Maybe that's a bad assumption on my part.
I won't push you, but I think you're pretty close to at least getting an image of the radio. Once you do, all that is left is sifting through it looking for the data and fields you need...
--
Dan Smith
http://www.danplanet.com www.danplanet.com
KK7DS
- 146.52, simplex. No tone. Label AAAAA
- 146.76, offset minus, 600 KHz. Tone, 88.5. Label BBBBB
I thought you said the V80 couldn't do names? Were you just talking about bank names?
It appears to me that a memory channel is 16 bytes long.
Agreed.
The first two bytes appear to be frequency / 5000, not three as in IC-T70.
Could be, but watch out for the case when/where frequencies are 6.25kHz step (unless the V80 doesn't support that).
After that, I can start setting/unsetting bits and figure out the other features.
Cool!
Is it correct that CTCSS tones are usually enumerated rather than literal values? Where can I find the enumerations?
On Icom radios, that is usually the case, yes. The enumerations are in chirp_common.TONES, and you should see that array used in the T70 driver in the same way you'll need to use it.
Also, since this radio does not use memory banks, do I have to strip out any bank code and/or structures from the IC-T70 driver, or does setting:
You should strip out any code that is not used, yes. Are you sure it doesn't even support the low-end bank model of just A-J? If you look at something like the IC2200 driver, you'll see that simpler model in use. I've not seen any Icom radios in the last ten years that didn't support at least that bank model.
Making the changes noted to the data structure and bank definitions does not result in the UI showing the correct frequency (it just says ERROR), so I am not clear on what else I am missing. Any tips appreciated.
Well, it's probably failing to parse something else. You'll need to look at the output on the console while it's trying to parse the image to see why. Probably a stack trace that ends in a complain about something on a specific line in the code. I would comment out everything in get_memory() that you don't have implemented and slowly add them back, starting with frequency.
Good progress, sounds like success is on the horizon :)
See below
...sent from my cell phone
On Jan 2, 2013, at 11:10, Dan Smith dsmith@danplanet.com wrote:
- 146.52, simplex. No tone. Label AAAAA
- 146.76, offset minus, 600 KHz. Tone, 88.5. Label BBBBB
I thought you said the V80 couldn't do names? Were you just talking about bank names?
The manual does not mention ch names. They do however appear in the icom programming GUI and are saved
It appears to me that a memory channel is 16 bytes long.
Agreed.
The first two bytes appear to be frequency / 5000, not three as in IC-T70.
Could be, but watch out for the case when/where frequencies are 6.25kHz step (unless the V80 doesn't support that).
Already noted
After that, I can start setting/unsetting bits and figure out the other features.
Cool!
Is it correct that CTCSS tones are usually enumerated rather than literal values? Where can I find the enumerations?
On Icom radios, that is usually the case, yes. The enumerations are in chirp_common.TONES, and you should see that array used in the T70 driver in the same way you'll need to use it.
Ok
Also, since this radio does not use memory banks, do I have to strip out any bank code and/or structures from the IC-T70 driver, or does setting:
You should strip out any code that is not used, yes. Are you sure it doesn't even support the low-end bank model of just A-J? If you look at something like the IC2200 driver, you'll see that simpler model in use. I've not seen any Icom radios in the last ten years that didn't support at least that bank model.
I havent a clue or any idea how to find out about banks. The manual doesnt note banks nor does the Icom s/w.
I'll look at the bank code but not sure im up to that. I dont do python...
Making the changes noted to the data structure and bank definitions does not result in the UI showing the correct frequency (it just says ERROR), so I am not clear on what else I am missing. Any tips appreciated.
Well, it's probably failing to parse something else. You'll need to look at the output on the console while it's trying to parse the image to see why. Probably a stack trace that ends in a complain about something on a specific line in the code. I would comment out everything in get_memory() that you don't have implemented and slowly add them back, starting with frequency.
Good progress, sounds like success is on the horizon :)
-- Dan Smith www.danplanet.com KK7DS _______________________________________________ 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
The manual does not mention ch names. They do however appear in the icom programming GUI and are saved
Page 28 in the manual. It also gives the character set, so you can declare the correct set of supported glyphs in rf.valid_characters.
I havent a clue or any idea how to find out about banks. The manual doesnt note banks nor does the Icom s/w.
Yeah, looks like the radio doesn't support it, that's interesting! So, yeah, you can just nix all the bank-related code from the driver.
I stripped out the bank code, no idea if done correctly. Latest code is attached.
I really have no idea how to debug past this. No knowing Python or this code, all I can do is capture the errors and pass along out.txt. I've tried commenting out the majority of the code and still get the same errors.
If I can get a working UI, I am capable of setting items bit wise and teasing apart the structure. But I will need someone to look at the code.
73, Drew K3PA
-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com [mailto:chirp_devel-bounces@intrepid.danplanet.com] On Behalf Of Dan Smith Sent: January 02, 2013 14:15 To: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] chirp_devel Digest, Vol 20, Issue 13
The manual does not mention ch names. They do however appear in the icom programming GUI and are saved
Page 28 in the manual. It also gives the character set, so you can declare the correct set of supported glyphs in rf.valid_characters.
I havent a clue or any idea how to find out about banks. The manual doesnt note banks nor does the Icom s/w.
Yeah, looks like the radio doesn't support it, that's interesting! So, yeah, you can just nix all the bank-related code from the driver.
--
- 146.52, simplex. No tone. Label AAAAA
- 146.76, offset minus, 600 KHz. Tone, 88.5. Label BBBBB
I thought you said the V80 couldn't do names? Were you just talking about bank names?
It appears to me that a memory channel is 16 bytes long.
Agreed.
The first two bytes appear to be frequency / 5000, not three as in IC-T70.
Could be, but watch out for the case when/where frequencies are 6.25kHz step (unless the V80 doesn't support that).
After that, I can start setting/unsetting bits and figure out the other features.
Cool!
Is it correct that CTCSS tones are usually enumerated rather than literal values? Where can I find the enumerations?
On Icom radios, that is usually the case, yes. The enumerations are in chirp_common.TONES, and you should see that array used in the T70 driver in the same way you'll need to use it.
Also, since this radio does not use memory banks, do I have to strip out any bank code and/or structures from the IC-T70 driver, or does setting:
You should strip out any code that is not used, yes. Are you sure it doesn't even support the low-end bank model of just A-J? If you look at something like the IC2200 driver, you'll see that simpler model in use. I've not seen any Icom radios in the last ten years that didn't support at least that bank model.
Making the changes noted to the data structure and bank definitions does not result in the UI showing the correct frequency (it just says ERROR), so I am not clear on what else I am missing. Any tips appreciated.
Well, it's probably failing to parse something else. You'll need to look at the output on the console while it's trying to parse the image to see why. Probably a stack trace that ends in a complain about something on a specific line in the code. I would comment out everything in get_memory() that you don't have implemented and slowly add them back, starting with frequency.
Good progress, sounds like success is on the horizon :)
-- Dan Smith www.danplanet.com KK7DS
I really have no idea how to debug past this. No knowing Python or this code, all I can do is capture the errors and pass along out.txt.
Okay, maybe there was some misunderstanding about the intentions here. I thought you were looking to learn enough Python to write the driver (several people have). If not, this may not be a very realistic endeavor (but read on).
I've tried commenting out the majority of the code and still get the same errors.
I commented out the majority of the code and it seems to get pretty far. Attached is an updated copy where I did the following:
- Spotted the rtone and ctone fields in your two memories and moved the appropriate bits in the structure definition to match - Guessed about where the dtcs code is stored - Spotted the "used" bits (which tell us which memories have valid data in them) and changed the structure definition to match - Commented out the code that looks for: - skip and pskip bits - tuning_step - mode - duplex - power - dtcs polarity - tone mode
With the attached code, I'm able to open your .img file and see your first two memories (frequency, tones, alpha labels, and offsets).
If you right-click on one of the memories and choose "Show Raw Memory" you can see how chirp has parsed the data into the structure definition. The "Diff Raw Memories" option is pretty handy for sussing out the differences between two almost-identical memories (and is how I typically most of my bit sniffing for these).
At a very minimum, the following needs to be done:
- Finding the tone mode bits (None, Tone, TSQL, DTCS, etc) - Finding the mode bits (FM and AM presumably?) - Changing set_memory() to match the changes in the structure as needed - Removing all the commented-out code that remains after finding this stuff - Test/fix uploading to the radio
Ideally we'd also find the remaining bits covered by the commented-out code, but even if we don't, I think it'd be usable with just the above.
I suppose if you're not interested in attempting any of the code stuff, I can make those changes if you're willing to sniff out the bits. I normally won't develop by proxy like this, but the radio appears pretty simplistic, and it's pretty close to usable right now.
I've attached the updated .py file, and included a diff of the changes I made below. How would you like to proceed? I sense your frustration with what I expect is a difference of expectations about what this process would be, but I appreciate the work you've done so far and I think we're pretty close to having something worth putting into the tree.
Thanks Drew!
Hi Dan,
Sorry, no time to learn yet another lang; just need to be as quick as I can during HF contest season. Getting rid of the HT shortly, but since I like and use the program, thought I should at least *try* to contribute first. Tons of IC-V80 users out there.
Here is the *almost* completed driver and image file used as my test dataset. Please note:
- Tuning steps, tmode enums redefined. Icom seemed to take out the redundant items. - New power levels. Same L, M, H, just different power values. - Icom items for "Reverse Offset" and "TX Inhibit" identified and defined in structure but I see no UI exposure for them. ICOM does expose them in their V80 software. Frankly, who cares; seems unimportant to me. Your call, just FYI; the structure is there.
All seems to work great, *except* skip. I have no idea how skip is supposed to work. Memory item MEM6 has skip set, but I see no bitwise difference in the memory values. Is this something that was handled via the banks? Maybe there is some minimal bank feature to support this and it just isn't documented? Thoughts?
Let me know what else I can do. To me, this is ready other than skip, but you should certainly QA my uneducated code changes.
Want to try to get the ID-51A supported?
73, Drew K3PA
-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com [mailto:chirp_devel-bounces@intrepid.danplanet.com] On Behalf Of Dan Smith Sent: January 02, 2013 18:44 To: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] chirp_devel Digest, Vol 20, Issue 13
I really have no idea how to debug past this. No knowing Python or this code, all I can do is capture the errors and pass along out.txt.
Okay, maybe there was some misunderstanding about the intentions here. I thought you were looking to learn enough Python to write the driver (several people have). If not, this may not be a very realistic endeavor (but read on).
I've tried commenting out the majority of the code and still get the same errors.
I commented out the majority of the code and it seems to get pretty far. Attached is an updated copy where I did the following:
- Spotted the rtone and ctone fields in your two memories and moved the appropriate bits in the structure definition to match - Guessed about where the dtcs code is stored - Spotted the "used" bits (which tell us which memories have valid data in them) and changed the structure definition to match - Commented out the code that looks for: - skip and pskip bits - tuning_step - mode - duplex - power - dtcs polarity - tone mode
With the attached code, I'm able to open your .img file and see your first two memories (frequency, tones, alpha labels, and offsets).
If you right-click on one of the memories and choose "Show Raw Memory" you can see how chirp has parsed the data into the structure definition. The "Diff Raw Memories" option is pretty handy for sussing out the differences between two almost-identical memories (and is how I typically most of my bit sniffing for these).
At a very minimum, the following needs to be done:
- Finding the tone mode bits (None, Tone, TSQL, DTCS, etc) - Finding the mode bits (FM and AM presumably?) - Changing set_memory() to match the changes in the structure as needed - Removing all the commented-out code that remains after finding this stuff - Test/fix uploading to the radio
Ideally we'd also find the remaining bits covered by the commented-out code, but even if we don't, I think it'd be usable with just the above.
I suppose if you're not interested in attempting any of the code stuff, I can make those changes if you're willing to sniff out the bits. I normally won't develop by proxy like this, but the radio appears pretty simplistic, and it's pretty close to usable right now.
I've attached the updated .py file, and included a diff of the changes I made below. How would you like to proceed? I sense your frustration with what I expect is a difference of expectations about what this process would be, but I appreciate the work you've done so far and I think we're pretty close to having something worth putting into the tree.
Thanks Drew!
-- Dan Smith www.danplanet.com KK7DS
% diff -u chirp/icv80.py.orig chirp/icv80.py --- chirp/icv80.py.orig 2013-01-02 16:31:14.126653149 -0800 +++ chirp/icv80.py 2013-01-02 16:33:17.178657828 -0800 @@ -22,24 +22,16 @@ ul16 freq; ul16 offset; char name[5]; - char junk[2]; u8 unknown2:2, rtone:6; u8 unknown3:2, ctone:6; u8 unknown4:1, dtcs:7; - u8 tuning_step:4, - narrow:1, - unknown5:1, - duplex:2; - u8 unknown6:1, - power:2, - dtcs_polarity:2, - tmode:3; + u8 unknown[4]; } memory[200];
-#seekto 0x12E0; +#seekto 0x0D10; u8 used[38];
#seekto 0x1306; @@ -105,8 +97,8 @@
_mem = self._memobj.memory[number] _usd = self._memobj.used[byte] - _skp = self._memobj.skips[byte] - _psk = self._memobj.pskips[byte] + #_skp = self._memobj.skips[byte] + #_psk = self._memobj.pskips[byte]
mem = chirp_common.Memory() mem.number = number @@ -124,13 +116,13 @@ mem.rtone = chirp_common.TONES[_mem.rtone] mem.ctone = chirp_common.TONES[_mem.ctone] mem.dtcs = chirp_common.DTCS_CODES[_mem.dtcs] - mem.tuning_step = TUNING_STEPS[_mem.tuning_step] - mem.mode = _mem.narrow and "NFM" or "FM" - mem.duplex = DUPLEX[_mem.duplex] - mem.power = POWER_LEVELS[_mem.power] - mem.dtcs_polarity = DTCS_POLARITY[_mem.dtcs_polarity] - mem.tmode = TMODES[_mem.tmode] - mem.skip = (_psk & bit and "P") or (_skp & bit and "S") or "" + #mem.tuning_step = TUNING_STEPS[_mem.tuning_step] + #mem.mode = _mem.narrow and "NFM" or "FM" + #mem.duplex = DUPLEX[_mem.duplex] + #mem.power = POWER_LEVELS[_mem.power] + #mem.dtcs_polarity = DTCS_POLARITY[_mem.dtcs_polarity] + #mem.tmode = TMODES[_mem.tmode] + #mem.skip = (_psk & bit and "P") or (_skp & bit and "S") or ""
return mem
Here is the *almost* completed driver and image file used as my test dataset. Please note:
Cool, and it uploads to the radio okay?
All seems to work great, *except* skip. I have no idea how skip is supposed to work. Memory item MEM6 has skip set, but I see no bitwise difference in the memory values. Is this something that was handled via the banks? Maybe there is some minimal bank feature to support this and it just isn't documented? Thoughts?
Skips are usually stored in a separate array somewhere in memory. Diffing the hexdumps of whole images is how I find them.
Let me know what else I can do. To me, this is ready other than skip, but you should certainly QA my uneducated code changes.
Okay, I'll take a look in the next couple days.
Want to try to get the ID-51A supported?
If the ID-51A is anything like the ID-31A, it's probably more than I want to do remotely like this. I have pretty good success getting my hands on current Icom gear, though, so I'll probably be able to do this one in the not to distant future.
I'll get back to you on this V80 stuff in a bit, thanks!
Here is the *almost* completed driver and image file used as my test dataset. Please note:
Cool, and it uploads to the radio okay?
Nope! Was focused on reading, having pulled an all-nighter, and hadn't gotten to writing... Write resulted in:
RadioError: Failed to communicate with the radio: Did not get clone result from radio
Log attached. The errors don't note my driver file and I don't recognize the variable "split", so I'm lost here. The radio did legitimately throw an error (visible on display) but I don't know why. Guess I was thinking this would be pretty symmetric.
All seems to work great, *except* skip. I have no idea how skip is supposed to work. Memory item MEM6 has skip set, but I see no bitwise difference in the memory values. Is this something that was handled via the banks? Maybe there is some minimal bank feature to support this and it just isn't documented? Thoughts?
Skips are usually stored in a separate array somewhere in memory. Diffing the hexdumps of whole images is how I find them.
I can probably manage diffing a hex dump if you like, but I don't know what to do with it when found.
Let me know what else I can do. To me, this is ready other than skip, but you should certainly QA my uneducated code changes.
Okay, I'll take a look in the next couple days.
Want to try to get the ID-51A supported?
If the ID-51A is anything like the ID-31A, it's probably more than I want to do remotely like this. I have pretty good success getting my hands on current Icom gear, though, so I'll probably be able to do this one in the not to distant future.
It's the dual band version of ID-31A, so even a bit more complicated. Not available yet, but due soon.
I'll get back to you on this V80 stuff in a bit, thanks!
-- Dan Smith www.danplanet.com KK7DS
Nope! Was focused on reading, having pulled an all-nighter, and hadn't gotten to writing... Write resulted in:
RadioError: Failed to communicate with the radio: Did not get clone result from radio
That's fine, actually, and is just a result of the common icom routines not being very tolerant of the different radio speeds (and me being lazy about fixing it).
Log attached. The errors don't note my driver file and I don't recognize the variable "split", so I'm lost here. The radio did legitimately throw an error (visible on display) but I don't know why.
Hmm, that log is after an attempted upload? I don't see anything related to even early negotiation with the radio...
Guess I was thinking this would be pretty symmetric.
Well, it usually is.
Let me know if I can help with anything on this. HT sold on eBay and will probably ship tomorrow or Tue.
73, Drew K3PA
-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com [mailto:chirp_devel-bounces@intrepid.danplanet.com] On Behalf Of Dan Smith Sent: January 04, 2013 16:09 To: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] chirp_devel Digest, Vol 20, Issue 13
Nope! Was focused on reading, having pulled an all-nighter, and hadn't gotten to writing... Write resulted in:
RadioError: Failed to communicate with the radio: Did not get clone result from radio
That's fine, actually, and is just a result of the common icom routines not being very tolerant of the different radio speeds (and me being lazy about fixing it).
Log attached. The errors don't note my driver file and I don't recognize the variable "split", so I'm lost here. The radio did legitimately throw an error (visible on display) but I don't know why.
Hmm, that log is after an attempted upload? I don't see anything related to even early negotiation with the radio...
Guess I was thinking this would be pretty symmetric.
Well, it usually is.
-- Dan Smith www.danplanet.com KK7DS
I was able to get the log from piping as you noted. I did not remember how
<pedant> Strictly speaking ">" or "<" is redirection, a pipe is different again "|" </pedant>
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-...
Dan,
I found where you said to get the debug log from the Windows user profile. Sorry, I had missed it the first time. However, this contains the debug file from the last time I ran CHIRP outside of the dev env. It does not include when I run it from python.
Where can I find the development copy of same?
Drew
-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com [mailto:chirp_devel-bounces@intrepid.danplanet.com] On Behalf Of Dan Smith Sent: January 01, 2013 14:30 To: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] chirp_devel Digest, Vol 20, Issue 13
- Created a driver "icv80.py" by renaming the one for the IC-T70.
That is their identical HT but dual band, so is presumably close
Probably, but not definitely :)
It's possible that they're very similar and that just tweaking the mem_format (or the offset where it starts looking for it) is all that is needed. If so, it may be best to make the V80 driver inherit from the T70, and only change a few things. However, keeping it separate like you have it now is probably the best way to start. If you start making minor tweaks to T70 code, that would be your indication that sharing is warranted.
- Did a download and saw the mode string 0x32 0x54 0x00 0x01. Changed
_model to match and HT seems to now be recognized
Cool.
- Increased _memsize greatly and ran a new download. Where is the
debug log that you speak of? I have no familiarity with this lang or env.
It's not a language or environment thing, it's a CHIRP thing:
http://chirp.danplanet.com/projects/chirp/wiki/How_to_report_issues
There is a section on there for "getting your debug log".
So I have error messages of course, but nothing that shows a last address.
The debug log will give you what you need.
Should this be in the command prompt window that I used to initiate the program? That is where I get error messages. Or is there some debug log somewhere else in Python? I'm familiar with using *nix, but never developed in it.
Oh, you're running from the command-line, then yeah, the debug log contents are just echoed to the console in that case. When the download is complete, you should see it echo the "Last addr:" and "End Frame:" to the console there. It may have scrolled off the screen amidst all the failures to parse the V80 data in T70 format. Might be good to pipe it to a file for perusal or something.
Sounds like you're getting there... :)
-- Dan Smith www.danplanet.com KK7DS
participants (3)
-
Dan Smith -
Drew Vonada-Smith -
Jonathan Andrews