Project

General

Profile

Actions

New Model #553

closed

Add support for ID-51

Added by Dean Gibson about 11 years ago. Updated about 11 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
-
Target version:
Start date:
02/12/2013
Due date:
% Done:

100%

Estimated time:
Equipment Loan/Gift Offered:
No
I read the instructions above:

Description

Icom's CS-51 software that comes with the radio is mostly sufficient, so I gave this a "Low" priority. I have ID-51 .ICF files, if you want them.

Actions #1

Updated by Tom Hayward about 11 years ago

  • Status changed from New to Blocked
  • Equipment Loan/Gift Offered set to No

Awaiting radio loan.

Actions #2

Updated by Dean Gibson about 11 years ago

Actually, I don't mind working on this myself, depending upon the build process. Dan knows, but for the rest: I wrote DStarCom, a Win32/Linux command line program a few years ago in C++ to do what Chirp does, for the IC-91/92AD, IC-2820H, ID-1, and ID-800/880H. When Dan came out w/ Chirp, I made my program open source and ceased development, so I'm very familiar w/ reverse engineering .ICF files.

I have both Linux and Windows machines. The Linux machines are all active web DB servers, and I'd like not to do development on them. I despise the CentOS GUIs and have very little experience with them, and would not even have installed them if I could have gotten away with it. Installed is CentOS 4.4 w/ python-devel-2.3.4-14.2.i386.rpm and gnome-python2-2.6.0-3.i386.rpm. Yes, I know it's very long in the tooth ...

On Windows 7/64-bit, I have Visual Studio 2005 (and some prior editions), which is where I prefer to do development. I don't care for (yet even more on the planet) IDEs, and do my development in a straight text editor, using GNU make (on both platforms. I use CVS for source code control but can adapt. I have no idea what tools/libraries I'd need on the Windows box. My first and only exposure to Python source code is that in Chirp.

Ideally, someone would copy the ID-31 code to a new id51.py file and I would modify it. Each day I do development, I would submit patches, wait for the overnight build, and next day test it. Obviously, others downloading the nightly build should avoid using the module until it has some semblance of readiness.

From my past experience w/ Icom radios, I'd think this should be a very simple port, by updating code for file signatures, memory sizes, and valid frequency ranges. I would not plan to implement the ID-51's broadcast memory slots and banks, at least not without significant architectural guidance.

Actions #3

Updated by Dan Smith about 11 years ago

  • Status changed from Blocked to In Progress
  • Assignee set to Dean Gibson

Hi Dean,

Submitting patches that aren't known to work is not really how we manage these things. However, the instructions for getting a windows development environment set up are available here: DevelopersWin32Environment. Once you've got that up, you can copy the id31.py to id51.py if necessary and do your work, although it may be more fruitful to add it to id31.py and inherit from that class to make the necessary changes.

Please see DevelopersProcess for details on how to properly submit patches, run the automated tests, etc.

Thanks!

Actions #4

Updated by Dean Gibson about 11 years ago

OK, I've installed the listed tools and run "python chirpw". An x64 install of Python goes nowhere, due to the GTK tool apparently only being available for x86, so that's what I settled on. I thought the tools installation would be more of a chore, so I had to ask (grin) about submitting untested changes for a new device/file. Of course, if the ID-51 code is in the ID-31 file, that would obviously be a no-no anyway.

So, I'm not sure how you are suggesting I proceed: Are you suggesting that I just modify the id31.py file, and inherit from the existing "ID31Bank" and "ID31Radio" classes? I'm not familiar with Python classes, but that seems not the best architectural form. Should the source filename remain the same?

Or, should I create from the ID-31 classes, "abstract" (in the C++) sense that are common to both radios, and have new ID-31 and ID-51 classes that inherit from those? If I do the latter, I have no way of testing the resultant code for the ID-31.

Actions #5

Updated by Dan Smith about 11 years ago

First off, I'd really like to have this discussion on the devel mailing list and not in the bug tracker, if that's okay.

Python convention does not dictate one class per file like Java, so it's perfectly fine to add another class in id31.py. It's also fine to put the subclass in a different file if you like. The former is usually done because it's easier to re-use module-scope utility functions that are common to both but aren't (for what ever reason) class methods.

My recommendation would be to copy the id31.py to id51.py and get started. If it's clear that the memory formats are very similar once you get started, then it's probably best to look at an inheritance model. If it's not strikingly similar, then perhaps a separate implementation is better since you can't test changes against the id31 driver.

In any case, lets take this to the chirp_devel mailing list for further discussion.

Thanks!

Actions #6

Updated by Dean Gibson about 11 years ago

I was just going to ask on the list, about where the detailed development discussion should be for device-specific issues, so I shall "reappear" on the list (grin).

Actions #7

Updated by Dean Gibson about 11 years ago

Shouldn't this be closed, so interested users can see the details of the radio was tested/added, and any further work on combining classes with the ID-31, be a separate bug/enhancement?

Actions #8

Updated by Tom Hayward about 11 years ago

  • Status changed from In Progress to Closed
  • Target version set to 0.4.0
  • % Done changed from 0 to 100
  • Chirp Version changed from 0.3.0 to daily
Actions

Also available in: Atom PDF