So far my limited experience with adding support for a radio (the 2730A is my first) is that it doesn't need any knowledge of C (the chirp library itself is python). A basic familiarity with memory (bytes, ascii, binary formats for numbers, etc), arrays, python and being comfortable digging into hex dumps is important, though. Depending on how similar to the existing drivers your radios are, this may or may not be easy or hard. For example, most Icom drivers have similar layouts and routines, but then the 2730A turns out to do things a bit differently, so that took some staring at hex dumps and scratching my head and debugging a bit to figure out what was different. Another recent example of a difficult driver was https://chirp.danplanet.com/projects/chirp/repository/revisions/e96b1bfcc450 where the developer reverse engineered an obfuscation routine of the memory.
If you have a radio that is supported with Chirp, an interesting exercise might be to try to use that one and reverse engineer it. Delete the existing driver file, and repeat the procedure. You have the existing driver file as a "cheat" to compare against when you get stuck.
As for dangers to your hardware, probably not much. I've tried writing a few times to the 2730A as I'm debugging, and the only thing that has happened so far is the radio beeps, displays CLONE ERROR and I have to power cycle it, after which the memory is reset. That is using the wrong protocol, though, and not writing bad data using the right protocol, so I'm not sure what happens there yet. I would imagine it might just display an error or reset itself if there's bad or corrupt data. You are unlikely to be able to actually harm it, but, of course, that's not a guarantee.
On Thu, Jan 4, 2018 at 10:36 AM, Rob Owens via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
I'm not well versed in C. I was hoping to be able to map out the memory locations, and modify an existing driver. And I'm very unsure of any dangers to my hardware, so I'd like a little better understanding in that area. I mean, at some point I have to try writing to my radio, and I'm not sure what the worst case scenario is there or how to avoid it.
On Thu, Jan 04, 2018 at 09:57:36AM -0800, Silverfox wrote:
I don't think you need constrain yourself to a regional area to
accomplish
what you want to do but I suggest that if you are not well versed in C development and knowledgable to use data collection and debug techniques, you will have a hard time moving forward. I am not saying "don't try it" but you should be aware of the requisites. 73, Alan - W6ARH
-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com [mailto:chirp_devel-bounces@intrepid.danplanet.com] On Behalf Of Rob
Owens
via chirp_devel Sent: Thursday, January 4, 2018 9:40 AM To: chirp_devel@intrepid.danplanet.com Subject: [chirp_devel] any Chirp developers in NJ, NY, or PA?
I now have three radios that are not supported by Chirp. Nobody has
stepped
up to add support, so I'm trying to teach myself how to do it. But I'm sure my learning curve would be much quicker if I had somebody experienced to work with for a day or so.
Is there anybody near northwestern New Jersey who would be willing to
help
me get started? I'm not looking for someone to do the work for me, just somebody to help remove the cloud of uncertainty I'm stuck in.
-Rob _______________________________________________ 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
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