- Users - lists.chirpmyradio.com

[chirp_users] First time user (help)
by Graham S 29 May '19

29 May '19

Hello chirp folk My first time using chirpw - not yet totally working yet. The mission was to program a Baofeg Radio ---------------------------------------------------------- Platform is Linux (Mint - Ubuntu based) chirpw does install OK in /usr/bin It also runs from $HOME/bin if I put a copy there. I check with "lsusb" to see that the USB device is seen OK, and all is well. 1. Firstly, I get a permissions refusal on attempting the communication. "An error has occurred [Errno 13] could not open port /dev/ttyS0" 2. If I run chirpw from a terminal, I get message: (process:5560): Gtk-WARNING **: 10:09:24.416: Locale not supported by C library. Using the fallback 'C' locale. Gtk-Message: 10:09:24.418: Failed to load module "atk-bridge" I check to see libatk-bridge2.0-0 is present - and all is well Also libatk-bridge2.0-dev is there I do not understand why the module is not loaded. The messages seem to come from a process that is named like a LAN network address which keeps changing except for the first number "10". It might some GTK process -------------------------------------------------------------- Have I done something catastrophic? Maybe missed out something essential? Thanks if you can help My regards all

2 2

Re: [chirp_users] Truth or Fiction Kenwood radios
by Gary Craig 28 May '19

28 May '19

Pavel, Thanks for the info on the Kenwood TK series. I was given a TK-762HG and saw it was supported in Chirp. Looking forward to programming it. Is the hack for the 12 channels included in the driver? Mine has 8. Be blessed! May 2019 be our year of change & growth! Gary Craig KI5CCD Maintenance Webco Industries Texas Distribution 750 Martin Luther King Jr Dr Orange, TX 77630-3094 409-886-0807 ext. 107 Fax 918-246-7045 gcraig(a)webcotube.com -----Original Message----- From: chirp_users-bounces(a)intrepid.danplanet.com <chirp_users-bounces(a)intrepid.danplanet.com> On Behalf Of Pavel Milanes Costa Sent: Tuesday, May 28, 2019 8:36 AM To: chirp_users(a)intrepid.danplanet.com Subject: Re: [chirp_users] Truth or Fiction This email originated from an external sender. Use caution when following links or opening attachments as they could be malicious El 24/5/19 a las 18:27, John Kemker escribió: > I find it hard to believe that they don't have as good a software > standard as less-expensive brands. I was not eager to take a side here, but... I'm developing a driver (CHIRP) for an old Yaesu/Vertex Radio family right now (FTL 1011/2011/7011) and there a BUG in the firmware, they DON'T Validate the radio info once I pass to the program space... I can program a 2011 like if a 7011 and vice versa... there is an old hack to convert any of them from 4 to 8 to 12 channels on SOFTWARE, etc.. "less-expensive brands?" I developed the driver for Commercial Grade Kenwood TK-x60/x70 & TK-x60G/x70G families (for CHIRP) and there is a lack of validation out there in the same aspect... In fact for YEARS fleet/ham operators knows that ANY of the in that familly can be programed like a x78 and you will get features that ONLY that radio has... yes I can program a TK-760G and get all the features of a TK-768G (A key for low power, true reverse, etc...) and the radios are happy with that... [The OEM software HIDE the key features for particular radios but the functions are there, I have given ACCESS to that functions in CHIRP, once you know that all of them uses the same firmware, literally: the same firmware...] The TK-790 is another monster [never completed the driver for it...], better programmed, locks on the important things, a separate mode for firmware, but has a quirk or two also... As many of the previous OM said: Fast, Reliable, Cheap; pick just two of them. Cheers, Pavel CO7WT. _______________________________________________ chirp_users mailing list chirp_users(a)intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Gary at gcraig(a)webcotube.com To unsubscribe, send an email to chirp_users-unsubscribe(a)intrepid.danplanet.com

1 0

Re: [chirp_users] Truth or Fiction
by JOCK SOUTAR 28 May '19

28 May '19

Never bricked any of mine. Could it be the operator rather than the radio? On Tuesday, May 21, 2019 Dennis Wage <chirp_users(a)intrepid.danplanet.com> wrote: Chirp has bricked Yeasu radios? I know what I think. What's the real truth? Dennis M. Wage (W9BOQ) 245 Corum Hill Road Castalian Springs, TN 37031 (615) 310-4242 Cell (615) 562-5128 Home http://hammondb3organ.net http://overdubs.net _______________________________________________ chirp_users mailing list chirp_users(a)intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Jock at kc6iih(a)aol.com To unsubscribe, send an email to chirp_users-unsubscribe(a)intrepid.danplanet.com

15 26

[chirp_users] Truth or Fiction
by Dennis Wage 28 May '19

28 May '19

Chirp has bricked Yeasu radios? I know what I think. What's the real truth? Dennis M. Wage (W9BOQ) 245 Corum Hill Road Castalian Springs, TN 37031 (615) 310-4242 Cell (615) 562-5128 Home http://hammondb3organ.net http://overdubs.net

5 5

Re: [chirp_users] Truth or Fiction
by Dave B 26 May '19

26 May '19

On 25/05/2019 20:00, chirp_users-request(a)intrepid.danplanet.com wrote: <Snipped> > They say they've seen bricked radios caused by CHIRP.? Said it's > because CHIRP wrote to areas they're not supposed to write to.? Said > that RT Systems "works with Yaesu" and that's why they support RT > Systems.? *Who would write the internal software for a radio where the > programming software could brick it?* ------------------------------------------------------------------------ Hi. Probably so they can load/update the entire firmware via the programming port during production with minimal effort on their part. However... Any "Sensible" designer would have put procedures in place in the final "User Release" firmware (as opposed to Production Test firmware) so that someone has to put the radio in a firmware load mode, perhaps like some other gadgets, by holding particular keys while it is powered up. Otherwise, leave it able to have memory data pulled and pushed, but other areas protected, perhaps flagging a warning on any display, of beeping, if anything tries to push data where it's not supposed to go, but otherwise ignoring it. But, these are products built down to a price, software/firmware development is expensive in time, and time costs money, due to the team of people involved. Plus, they are probably working on a host of other products too, so rightly or wrongly, only the bare minimum is done to meet the project's specified needs, and that's all. At the expense of "sanitisation" code for any remote memory read/write functions over any I/O port. Remember, just one bit flipped in the wrong place could cause mayhem or utterly brick a product. Or cause no issue, if the internal code does not use that location. But, a later updated firmware might use that location for something critical! The RT systems people have probably paid Yaesu for the needed information to do it the right way, or even purchased a software library from them, so they are understandably trying to protect their investment, in this case by (allegedly) perhaps spreading untruths about competing software. It's sadly not uncommon in the professional/industrial world too. Regarding CHIRP. It's good, very good. But by the nature of things that are built as a result of reverse engineering someone else's protocol without sight of any makers documentation, mistakes can be made, or features/methods that are default if not touched are fine on one product, but on another outwardly similar product, is the wrong way to do things. Heck, in my life where I've created code for products and customers, where documentation DOES exist, there are often errors and omission in the doc's that turn out to be a tripping point! And that's for products that cost many times more than any Ikensu radio! Reverse engineering is not trivial either, lots of testing is needed, with access to examples of (in this case) the particular make/model of radio in question, and known working software (all at a cost.) All that takes time, LOTS of time, plus at a guess, I expect the developers working on this are volunteers who as such are unpaid and have lives to get on with too. I have to say, they do a great job all things considered. I myself have a HH radio I'd like to use with CHIRP (A Puxing PX-2R) that CHIRP doesn't understand correctly, at this time. A Bug has been filed, with log files etc (January this year.) But I'm not expecting a rapid fix as other issues affect a lot more people. I have the hardware, some Python knowledge, but I'm not up at the level needed to do much with it, sadly. I also don't get enough of "the right sort of contiguous time" to dive in, learn, and have a go myself, but I might re-visit the code, and see if I can learn what's going on, or not. But as always, that takes time, and I have many many other things I need to be doing in the domestic and work world too. Regards to All. Dave B G0WBX -- Created on and sent from a Unix like PC running and using free and open source software:

1 0

Re: [chirp_users] Homebrew formula and daily builds
by Dave B 24 May '19

24 May '19

Date: Thu, 23 May 2019 14:26:58 -0400 (EDT) From: "Nigel A. Gunn G8IFF/W8IFF" <nigel(a)ngunn.net> Subject: Re: [chirp_users] Homebrew formula and daily builds To: Discussion of CHIRP <chirp_users(a)intrepid.danplanet.com>, Brian McCaffrey <brian(a)w1bp.net> Message-ID: <693315801.787648.1558636018565(a)email.ionos.com> Content-Type: text/plain; charset=UTF-8 For those Linux users who feel neglected, you can install Homebrew with: sh -c "$(curl -fsSL https://raw.githubusercontent.com/Linuxbrew/install/master/install.sh)" ------------------------------------------------------------------------ No thank you! I've seen what that can do, and anyway, that fails miserably if Ruby is not installed. #!/bin/sh set -e umask 022 if test -n "$HOMEBREW_FORCE_VENDOR_RUBY" || ! command -v ruby >/dev/null; then eval "`curl -fsSL https://raw.githubusercontent.com/Linuxbrew/install/master/install-ruby`" fi exec ruby -e "`curl -fsSL https://raw.githubusercontent.com/Linuxbrew/install/master/install`" "$@" (I've removed what it put there, cleaned and sterilised the brewery!) Mac's are an odd case, as they are curated by Apple, who vehemently do not want anyone "polluting" the system with unknown software. However, as we all know, there are ways... Best stick to the instructions on the chirp website I think. 73. Dave G0WBX. -- Created on and sent from a Unix like PC running and using free and open source software. ::

1 0

[chirp_users] New Daily Build
by Build System 24 May '19

24 May '19

Greetings, A new daily build of CHIRP is available. This includes changes made directly to the tree yesterday, and may include additional features, bug fixes, and/or bugs. If you are interested in trying it, grab it from the following location: http://trac.chirp.danplanet.com/chirp_daily/daily-20190524 A list of the changes included in this build (since the last daily) follows: Changes for Build #581 [Ray Cielencki <rayslinky(a)gmail.com>] [VX-6] Add settings support for Yaesu VX-6 #1289

1 0

[chirp_users] Homebrew formula and daily builds
by Brian McCaffrey 23 May '19

23 May '19

I installed Chirp on macOS using Homebrew, but it seems to have installed the daily build from 20190206. What would be the best way to install the daily build using Homebrew? Should I re-write the formula to get the daily build? Suggestions? 73, Brian

4 7

[chirp_users] CHIRP and HP Chromebook
by O O 22 May '19

22 May '19

Hello, I purchased a Baofeng BF-F8HP, cable, and HP Chromebook. I have no experience with either program. The software CHIRP lists doesnt download on the laptop. The laptop has Linux capability, but I don't have any idea how to execute the program. Any assistance would be appreciated. Thanks. Jim

4 3

[chirp_users] PPA and auto CHIRP update/upgrade 'issue'
by Mike Parks 19 May '19

19 May '19

Hi, I'm having a problem with the automatic update of CHIRP since I upgraded Ubuntu from 16.xx to 19.04 64 bit. I get various error messages when entering the three lines of instruction on the dansmith site. I then see: Unable to download updates: failed to refresh cache E:The repository 'http://ppa.launchpad.net/dansmith/ chirp-snapshots/ubuntu <http://ppa.launchpad.net/dansmith/chirp-snapshots/ubuntu?fbclid=IwAR1bQXquR…> disco Release' does not have a release file. Everything worked fine until the upgrade to 19.04. So now I have to manually update CHIRP. Any thoughts for a Linux/Ubuntu novice? Thanks. Mike - G4UPD

3 2