[chirp_users] Displaying odd repeater splits

Wed Mar 2 18:11:28 PST 2016

I hope everyone remembers that the developers  of CHIRP offer this software for free.  What they have done is remarkable, considering the interoperability of programming such a wide variety of radios.  Also considering how each brand has it's own way of programming, just imagine all the time, sweat, and tears already put into this project.  It seems like a small thing,  to have to do a little basic math.  But look at how many fast food cashiers cannot make change without a computer to tell them what to give back.
After I catch up on some bills, I will be making a donation to the CHIRP team.  I just finished putting together a small school bus to use for SAR and Emergency Comms.
Jardy Dawson
WA7JRD Ham Radio

Sent by hurling dead pigeons over the wall by trebuchet.

      From: Dave VK2FDJS <vk2fdjs at gmail.com>
 To: Discussion of CHIRP <chirp_users at intrepid.danplanet.com> 
 Sent: Wednesday, March 2, 2016 5:53 PM
 Subject: Re: [chirp_users] Displaying odd repeater splits

Yes, good idea. 

Regards Dave S
Sent from my iPhone
On 3 Mar 2016, at 12:29, Eric Vought <evought at pobox.com> wrote:

Or a tooltip with the calculated value.
On Wed, Mar 2, 2016 at 5:55 PM, gerard <gmkayaker at gmail.com> wrote:

On 3/2/2016 4:03 PM, Dave VK2FDJS wrote:
> I wonder if it would be feasible to include both the offset amount and the resultant frequency - perhaps greyed-out or in smaller font - when it's a +/-.
It could just be another column whose value is derived from the combination of
the Duplex and Offset columns. Or you could enter either the Offset or the 2nd
frequency and calculate the other. I don't think it would affect what was stored
in the file or radio, just how the data was entered. But I don't know how the UI
code is structured.
> Although my radios are programmed as +/- they actually display the TX frequency when I hit the PTT, so I find myself doing the same mental arithmetic.
>
> Gerard, perhaps you could look at making the change yourself, as you're a software person, and submitting the change to the developers.  Although the developers probably prefer to keep away from the UI, it's SOP for us software types.
Unfortunately, I'm not familiar with Python and I doubt the developers would
want a python newbie messing with the code. And I'm more of a software
generalist than a programmer per se. Agile coaching, automated testing,
usability, etc. are my main areas of expertise these days.

Gerard
>
> Regards Dave VK2FDJS
>
> Sent from my iPad
>
>> On 3 Mar 2016, at 07:26, gerard <gmkayaker at gmail.com> wrote:
>>
>> Thanks for the background info. As a software professional myself, I appreciate
>> the technical challenges as well as the natural tendencies of software
>> developers.  Your idea of basing the default behaviour based on the frequency
>> range makes sense to me. Another option would be to have a picklist or
>> check-box/toggle above the Offset column to force the display in one format or
>> another. Maybe only show it when the radio doesn't store the format.
>>
>> Unfortunately, the current behavior, of showing it always as +/- and providing
>> no way to convert back (selecting "split" on an existing memory slot zero's out
>> the rx offset by inserting the base frequency) really should be considered a bug
>> as it is effectively "Write-only Memory".  At least fix it so that when you
>> change + or - to split, it does the math and shows you the resulting frequency.
>> That *should* be trivial to do.
>>
>> I finally figured out what the  "Properties" button does (it does nothing and
>> provides no feedback if you have no memory item selected, so it really should be
>> disabled/greyed-out.) If I change from + to split in the Memory Properties pane,
>> it gives me a warning icon telling me the offset is out of range! Duhh! That's
>> because it *is* an offset, not a frequency. And Chirp should change it to a
>> frequency automatically when I change from +/- to split. That would at least
>> give me a way to see the frequency without having to do math in my head. I would
>> like to report this as a bug as this is just plain wrong!
>>
>> Thanks again,
>>
>> Gerard
>>
>>> On 3/2/2016 12:51 PM, Tom Hayward wrote:
>>>> On Wed, Mar 2, 2016 at 11:09 AM, gerard <gmkayaker at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I'm am a long-time user of VHF radios starting with a VX-150 some 15 years ago
>>>> and switching to Baofeng UV-5R when they were relatively new. I have been using
>>>> Chirp to program my UV-5R since I first got the radio. One thing that I find
>>>> annoying about how Chirp works with repeater splits is that it shows it as a +
>>>> or a -. Most people I deal with in Canada give me frequency pairs. And I haven't
>>>> found an easy way to get Chirp to show me the actual frequency (as opposed to
>>>> the +/-.)  When I enter a frequency as a "split", it immediately gets converted
>>>> to "+/-" and there seems to be no way to get Chirp to show it as a "split". This
>>>> makes it really hard to confirm that I have the correct frequency entered; I
>>>> need to do frequency math in my head or paper which increases the likelihood of
>>>> errors.
>>> This is a shortcoming of the UV5R. It cannot differentiate from offset
>>> and independent tx/rx records--the radio stores them identically.
>>> Chirp assumes that most users are hams and prefer the +/- offset view,
>>> so that's how Chirp displays offsets less than 70 MHz. (This is the
>>> conversion you're talking about.)
>>>
>>>> It would be great if Chirp had a setting that allowed me to say "Always show
>>>> splits using the format entered" or "Always show splits in: " and let me choose
>>>> between +/- and "split".
>>> Most ham radios (Yaesu, Icom, Kenwood) differentiate offset and
>>> odd-split records. With these radios, Chirp displays the frequency or
>>> offset as entered.
>>>
>>> For the UV5R, this would require storing the "format entered"
>>> somewhere. The UV5R memory provides nowhere to store this, so that
>>> means we would need some sort of proprietary Chirp file to store this
>>> information. The .img files are just a simple dump of the radio
>>> memory, not proprietary, and don't offer a place to store auxiliary
>>> data like this. This would only be beneficial when editing said
>>> proprietary file--after doing a "Download from Radio" you'd be back to
>>> just what was stored in the UV5R. Not really an optimal solution.
>>>
>>> I've proposed an alternative scheme: on radios that don't know the
>>> difference between an offset and an odd split, display as offsets in
>>> the ham band and as tx/rx frequency outside the ham band. This would
>>> work great for me as I program a number of Part 90 certified radios
>>> for mixed Part 90 and ham use. In my area, ham repeater channels are
>>> usually communicated by offset and commercial channels by their tx/rx
>>> frequencies. However, this scheme presents some challenges too. The
>>> hand bands differ by locale and not everyone has the same preference
>>> as myself.
>>>
>>> Your other idea, '"Always show splits in: " and let me choose between
>>> +/- and "split"' has its own challenges. Besides the UI work to add
>>> this preference selection (which most Chirp developers tend to avoid
>>> due to its complexity), I think it would require updating all radio
>>> drivers to support the new scheme--a monumental task. Also, it would
>>> defeat the feature of most ham radios that properly differentiate
>>> between offsets and odd-split records.
>>>
>>> The way Chirp does it now was chosen intentionally to please the
>>> largest number of users. Unfortunately we can't please everyone. We're
>>> always open to discuss new ideas--that's what this mailing list is for
>>> (or the chirp_devel list for the implementation details). Hopefully
>>> this background on the treatment of offsets and radios that don't
>>> support them is helpful fodder for discussion.
>>>
>>> Tom KD7LXL
>>> _______________________________________________
>>> chirp_users mailing list
>>> chirp_users at intrepid.danplanet.com
>>> http://intrepid.danplanet.com/mailman/listinfo/chirp_users
>>> This message was sent to Gerard Meszaros at chirp at gerardm.com
>>> To unsubscribe, send an email to chirp_users-unsubscribe at intrepid.danplanet.com
>> _______________________________________________
>> chirp_users mailing list
>> chirp_users at intrepid.danplanet.com
>> http://intrepid.danplanet.com/mailman/listinfo/chirp_users
>> This message was sent to Dave VK2FDJS at vk2fdjs at gmail.com
>> To unsubscribe, send an email to chirp_users-unsubscribe at intrepid.danplanet.com
> _______________________________________________
> chirp_users mailing list
> chirp_users at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_users
> This message was sent to Gerard Meszaros at chirp at gerardm.com
> To unsubscribe, send an email to chirp_users-unsubscribe at intrepid.danplanet.com
>

_______________________________________________
chirp_users mailing list
chirp_users at intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_users
This message was sent to Eric Vought at evought at pobox.com
To unsubscribe, send an email to chirp_users-unsubscribe at intrepid.danplanet.com

_______________________________________________
chirp_users mailing list
chirp_users at intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_users
This message was sent to Dave VK2FDJS at vk2fdjs at gmail.com
To unsubscribe, send an email to chirp_users-unsubscribe at intrepid.danplanet.com

_______________________________________________
chirp_users mailing list
chirp_users at intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_users
This message was sent to Jardy at jardy72 at yahoo.com
To unsubscribe, send an email to chirp_users-unsubscribe at intrepid.danplanet.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_users/attachments/20160303/078c3044/attachment.html 