Feature #4421
closedGeneric Radio Option
0%
Description
Please consider adding support for a "Generic" radio type to allow User experimentation.
Something as simple as replacing the "Vendor & Model" fields within the download from Radio -> Radio" dialog with one or more "User defined - Open" format entries that would send communication data to ANY radio. Report/send radio response to simple CHIRP terminal window.
Approach could create several benefits;
Allow Users to be somewhat more self sufficient.¶
Potentially help CHIRP development efforts.¶
Provide efficient middle ground between radio supported User and those technical Python knowledgeable people.¶
Reduce "new Radio" requests.¶
Simplify "new Radio" additions through connection "parameters" rather than unique support for growing list of Brand/Models.¶
Thanks,
Bob James
Rochester, NY
Updated by Jim Unroe over 8 years ago
- Status changed from New to Incomplete
Bob,
I guess I don't follow what you are wanting. A user can click File -> New and get a Generic.csv template that allows him or her to experiment programming channels. Or for a more realistic and specific experimentation, one or more of around 90 CHIRP Radio Images (*.img) files can be downloaded from the "repository":http://chirp.danplanet.com/projects/chirp/repository/show/tests/images.
Jim KC9HI
Updated by Bob James over 8 years ago
Sorry, let me try again...
None of my 4 radios seem supported by CHIRP. As such, my options are either put in "New" radio requests which I'm guessing is fairly unlikely to be addressed given developer need for physical radio or I can step one-by-one through the various currently supported radios hoping for a match, and at best some sort of partial data/memory support, also not a great choice.
And although I clearly don't know how CHIRP is designed or communication to any particular radio works, as a long time software engineering, I'm guessing there must be some standards, or at least common ground, for data in and out to radios. For instance, CHIRP sends some sort of "Request" down the serial port wire and the radio responds. Or not if the Request is invalid.
My suggestion would add a "Generic" radio choice to the "Download from Radio" option and when selected would show a "Radio" dialog box with setup fields that would be basic to communicating with most radios. For instance, obviously need to keep the "Port" field but replace "Vendor" and "Model" with one or more fields that more directly attempt communication with radio. And if different manufacturers have different protocols then maybe keep Vendor as field but add "Generic" choice for those with new Vendor radios. History developing the over 90 radios should give a good idea of the "basics" that might be needed for simple start of communication with new radio.
Think about it this way - When adding support for a new radio, how does it start? Must be some "standard" basic CHIRP to Radio data communication steps that are common to most radios and form the basic I/O of the development process. Break out those parameters to a generic radio dialog for User experimentation with unknown radios. CHIRP would provide simple window for radio response, if any.
if User communication with new radio succeeds then CHIRP could make some data assumptions and show radio memory in Generic CSV template, Or provide for User feedback to Developer as a head start on official addition of new radio. Remove this feature to a more Advanced area of CHIRP if that makes sense.
Thanks for listenng,
Bob
Updated by Bernhard Hailer over 4 years ago
- Chirp Version changed from 0.4.0 to daily
Hello Bob, unfortunately every maker of radios uses their own method of storing data. There is no unified or standardized procedure to get just rudimentary channel parameters such as frequency, offset, tone into an Icom or a Kenwood - they do it in very different ways in terms of memory layout, serial communication, etc. So, as nice as this idea is, it is not really feasible with the current way Chirp handles things. Whenever possible, Chirp combines a group of radios into one driver. But between makers it's not doable: if the memory layout of an unsupported radio differs from already supported radios, or the serial protocol differs, then a driver needs to be adapted or even written from scratch.
I'll leave this open; perhaps someone comes up with a bright idea.
Updated by Dan Smith over 2 years ago
- Status changed from Incomplete to Rejected
I don't think this makes any sense to me. There are no standards, all radios are very different. Aside from turning chirp into a terminal program, I can't see how this could really progress. We have a lot of inbuilt development tools for developing new radio drivers, but all those efforts start with a very low-level analysis of the communication.