Re: [chirp_devel] I'd like to add some features to the developer tools
Tom, thanks for responding.
On Jun 4, 2014, at 12:42 PM, Tom Hayward - esarfl@gmail.com
I'm not sure I understand everything you're suggesting. If you have already implemented this, can send the changes in patch format so I can try them myself?
Yes, implemented and working for several months now. I will do that today. Privately, just to keep the noise level down.
Most of the time, I like having full context in the memory diff. It's not like it's very long. I don't understand why a negative channel number was chosen to enable this feature. Wouldn't a checkbox be more appropriate?
Well, channel -1 to enable the diff was what was built into Chirp to enable the diff when I showed up here. It's not advertised, I discovered it from browsing the code. See mainapp.py line 212. Using -2 for the "diffs-only" version seemed like a reasonable extension.
In fact, one of the changes I've made is to advertise the function.
Added some help text to the "Diff Radios" dialog explaining the hex dumps available with mem # = -1 and -2.
I agree about wanting the context a lot of the time, and I'm not proposing to eliminate that, at all. But twiddling some radio buttons and dumping state, and wanting to be sure I notice ALL the changes, get's pretty hairy when the scroll is ~3600 lines as in the FT-60. I disagree that it's not very long, and I found myself wanting a tool that allows me to be sure I got them all. So I built it.
That's also the focus of the diff_charflag mode. I just want to be sure I see ALL the differences.
Can you read the font size from the operating system default? I think this is the appropriate way to do it, but I don't know specifics. Ability to override this is reasonable, but maybe the problem is that you have your OS configured the way you like and Chirp isn't honoring it. That sounds more critical than implementing a font size override.
My eyesight is what you might expect for late 60s. I probably have most apps configured to a slightly larger font than the majority, but in actual practice, I switch them larger or smaller within apps (e.g. browser, mail, pdf viewer, ...) pretty dynamically so I can see detail when needed, and more context when not.
Just importing a "system font size" is not what I want. I've worked out what I want the Chirp diffs and browser to be so I can work with them, and I'd like to be able to set that directly, not futz with inheriting some system property that I'd have to set globally to get Chirp how I want it, that might make other apps not behave as I'd like.
Not to mention introducing system dependencies. All I have is a Mac. If you or someone wants to import a system font size as the default, fine with me. I note that in the existing code, the browser and diff sizes are different, so someone thought they needed to be. Just allow me to override the default, however it's set.
These sound like a number of small, atomic features. Each distinct feature should be its own patch and we can discuss it independently if needed. If one feature is dependent on another, just make sure the order of your patches is appropriate.
Groan. Yeah, I know the rules. Look over the changes and see if they're trivial enough to do some lumping. But whatever it takes.
Patch equivalent coming soon.
-dan
This may well be a faulty radio, but I will ask here just in case I am missing something subtle.
I own a UV3R Plus, works fine, programs ok with CHIRP - I will call this my "original" radio.
I have just purchased from EBAY a shiny new UV3R as a second radio.
I can plug the original radio into the laptop and program it with no problems, if I then unplug the cable and plug it into the new radio it fails to work (No ACK). I have tried re-starting CHIRP, I even tried the manufacturer software, nothing seems to make it work.
Do I need to do something to prepare the new radio or is it just faulty ?
Thanks, Jon
In short, my guess is a faulty radio. Check that plug is fully seated and also try pushing it inside or left/right while cloning.
73 de IZ3GME Marco Il 17/set/2014 14:26 "jon" jon@jonshouse.co.uk ha scritto:
This may well be a faulty radio, but I will ask here just in case I am missing something subtle.
I own a UV3R Plus, works fine, programs ok with CHIRP - I will call this my "original" radio.
I have just purchased from EBAY a shiny new UV3R as a second radio.
I can plug the original radio into the laptop and program it with no problems, if I then unplug the cable and plug it into the new radio it fails to work (No ACK). I have tried re-starting CHIRP, I even tried the manufacturer software, nothing seems to make it work.
Do I need to do something to prepare the new radio or is it just faulty ?
Thanks, Jon
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
What Marco describes is very common with the UV-5R series of radios and the 2-pin Kenwood "style" programming cable. Sometimes the shell of the plug needs to be trimmed to allow the plug to fully seat in the socket. Sometimes it requires some wiggling of the plug and a firm push to get the plug fully seated. I've never been in possession of a UV-3R, and don't follow any UV-3R groups, so I don't know if the UV-3R even has this issue. I assume that both of your UV-3R radios use the 2-pin plug. Or are they both the single pin version?
Another possibility is that Baofeng (or should I say Pofung) changed the "string" (aka "ident") that triggers the cloning process. They did this for the UV-5R about a year ago when they introduced the BFB291 firmware. This same thing just happened recently with the UV-6.
Unfortunately, if this is what happened, CHIRP can't be updated until the new "ident" is known. This is don't by "sniffing" the serial communications between the OEM software and the radio during a download. So until/unless you can find OEM software that works with the radio, there is nothing CHIRPwise that can be done.
Jim KC9HI
On Wed, Sep 17, 2014 at 8:26 AM, jon jon@jonshouse.co.uk wrote:
This may well be a faulty radio, but I will ask here just in case I am missing something subtle.
I own a UV3R Plus, works fine, programs ok with CHIRP - I will call this my "original" radio.
I have just purchased from EBAY a shiny new UV3R as a second radio.
I can plug the original radio into the laptop and program it with no problems, if I then unplug the cable and plug it into the new radio it fails to work (No ACK). I have tried re-starting CHIRP, I even tried the manufacturer software, nothing seems to make it work.
Do I need to do something to prepare the new radio or is it just faulty ?
Thanks, Jon
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
On Wed, 2014-09-17 at 17:54 -0400, Jim Unroe wrote:
What Marco describes is very common with the UV-5R series of radios and the 2-pin Kenwood "style" programming cable. Sometimes the shell of the plug needs to be trimmed to allow the plug to fully seat in the socket. Sometimes it requires some wiggling of the plug and a firm push to get the plug fully seated. I've never been in possession of a UV-3R, and don't follow any UV-3R groups, so I don't know if the UV-3R even has this issue. I assume that both of your UV-3R radios use the 2-pin plug. Or are they both the single pin version?
Yes, both new and existing radio are the same Kenwood style 2 prong plug.
The new radio is cosmetically identical to the one I own, the program cable has plugs that are quite proud of the moulding so I doubt it is a connection problem (with the plug anyway). It looks and feels properly seated, I also tried giving it "an extra push and wiggle" (tm).
With both handsets side by side one programs, one does not - same CHIRP/cable setup - both handsets look identical, I can only tell them apart because I left the LCD protector on the new one.
Another possibility is that Baofeng (or should I say Pofung) changed the "string" (aka "ident") that triggers the cloning process. They did this for the UV-5R about a year ago when they introduced the BFB291 firmware. This same thing just happened recently with the UV-6.
Unlikely the manufacture date is 2010 best I can tell? Just in case anyone else ends up with it.
Radio is marked UV3R+ CMIT ID: 2010FP6535 NO: 3120479219
Unfortunately, if this is what happened, CHIRP can't be updated until the new "ident" is known. This is don't by "sniffing" the serial communications between the OEM software and the radio during a download. So until/unless you can find OEM software that works with the radio, there is nothing CHIRPwise that can be done.
Ok, the "latest" software for the radio (as pointed to by the seller) fails to work - yet same cable and software works with the old handset. Doubt it is a changed ident string, looks very much like a faulty radio to me. It could be fussy about cables, but I only have one cable so cant investigate further.
I am willing to bet cash that each time a faulty handset is returned to one of these sellers they simply send it out again in the hope the next sucker does not notice - or am I just old and cynical ;-)
I give up on this radio, I have packaged it up for return.
Thanks everyone for the help/comments :-)
Jon
participants (4)
-
chirp.cordless＠xoxy.net -
Jim Unroe -
jon -
Marco Filippi