[aprssig] Best format for a Repeater Item (350 bug)

Fri Apr 26 13:03:29 EDT 2013

On Apr 26, 2013, at 12:13 PM, Lynn W. Deffenbaugh (Mr) wrote:

> Yaesu has gone on record that space is tight in their firmware.  They have said that KISS support cannot be done.  And the firmware updates they've released have fixed bugs, primarily, not added new features.  Being a software developer, adding a new place from which frequency information will be parsed is probably more than they have room for.
> 
I'm a software developer too, but I have no idea how much free space they have left or how modular their code is; what gives you that insight? If their programmers were any good the frequency parsing is a subroutine that could be called with a different parameter to parse from the object name and would only take a few bytes. If not it could be turned into a subroutine with a few more bytes. Since I have no idea how much code space they have anyway I can't say if this is an issue at all. Maybe they think it will take 8k to do KISS and they have 7k free. Or maybe they have 10 MB free and are just using this as an excuse to deflect feature requests.

Besides, my 37 years of programming experience tells me you can always make things more efficient in either speed or storage, and often both. In these days of gigabyte memory spaces the old tricks may not be needed often, but the means exist; to not try is a sign of laziness.

And finally, in this day and age of cheap memory, running out of flash space for code is unforgivable, more than enough reason to avoid this radio like the plague! If they can't fix their bugs the radio is even less upgradable than the D7/00 that caught so much grief for its difficulty to flash.

> Besides, it seems to be to not be a "bug" per se, but simply a partial implementation of the frequency specification.  They pick it up from the comment, but not from the object name.
> 
So you are saying if they only accepted mic-e positions and failed to parse uncompressed reports that is not a bug but a partial implementation that is nothing to worry about? Or that a computer that implements UDP but not TCP is not flawed? This isn't that they do not parse, say, telemetry parameters. In this case something Yaesu claims as a feature is implemented in such as way as to make it unusable in a large percentage of the time. That sure meets my definition of a bug!

> And how many other features of APRS are non-optimal simply because of existing hardware (KPC-3s) and software (UI-View).  Even the Item format is not recommended because Kenwood's D700 doesn't parse that.  And items were even part of the original spec!
> 
In my mind there is a huge difference between not accepting a proposed optimization of the APRS protocol because existing hardware and software will break, and changing the existing protocol because new hardware failed to implement it correctly.

There really is no excuse for this. A million real-world APRS packets can be captured in a few hours on the APRS IS. Either Yaesu did not do this for testing, tested sloppily, or knew about this bug and did not care. Any of these three should be enough to make people steer clear of buying it, and to demand a refund from Yaesu if they already bought it and want the QSY function.

Steve K4HG

> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
> 
> On 4/25/2013 5:05 PM, Jeff Dugas (Mobile) wrote:
>> IMHO, the proper solution is for the 350 to be fixed.  I am not familiar with it, but is it a radio that can receive a new firmware flash?
>> 
>> Jeff
>> N5TEV
>> 
>> 
>> Robert Bruninga <bruninga at usna.edu> wrote:
>> 
>>>> I'm all for putting the frequency in the list (object name),
>>>> but I sure don't see how it hurts to put it also in the comment
>>> I guess my only reservation is that it wastes 10 bytes, it creates a spec
>>> conflict with unknown results in radios that do follow the spec. For
>>> example, the FREQ-spec says that if there is a freq in the text in
>>> addition to the object name, that it is then an odd-split and the repeater
>>> output is the object name and the input is the frequency in the text.  If
>>> we make them the same then we cannot use this for anything but a simplex
>>> repeater since the spec calls for an automatic offset on 2m which will be
>>> canceled by having both freqs the same.
>>> 
>>> So if it breaks all the other radios, just to preserve a minor function on
>>> the 350, Is my concern.
>>> 
>>> I know we beat this to death a year or so ago, and found that the dual
>>> freq did work for the 350's but I do not remember if anyone tested to see
>>> if it broke the OFFSET TUNE function of the D710's and D72...
>>> 
>>>> We just need to nail down a consistent, ... most broadly usable...
>>> format
>>>> and THEN start "encouraging" the correction, update, and rollout of the
>>> frequency objects.
>>> 
>>> What we need is testing!
>>> I just spent some time and what I learned so far is:
>>> 
>>> 1) It cannot be an ITEM.  The D700's will not decode them.  It must be an
>>> object.
>>> 
>>> More permutations and testing still needed.
>>> 
>>> Bob, WB4aPR
>>> -------------------------------------------
>>> 
>>> My conclusion is that all FREQ objects should be done right so that the
>>> packets appear correctly and serve their designed purpose on *all* radios
>>> including all kenwood's and all Yaesu's.  The only loss is that the QSY
>>> button on the FTM-350 will not work properly, though nothing prohibits the
>>> operator from manually tuning to that frequency.
>>> 
>>> I prefer not to break the system to try to correct a bug in one radio that
>>> is only an inconvenience when all other value of this function works fine
>>> on all radios including this one.
>>> 
>>> Bob, Wb4aPR
>>> 
>>> -----Original Message-----
>>> From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
>>> Of Lynn W. Deffenbaugh (Mr)
>>> Sent: Thursday, April 25, 2013 9:39 AM
>>> To: TAPR APRS Mailing List
>>> Subject: Re: [aprssig] Best format for a Repeater Item (350 bug)
>>> 
>>> On 4/25/2013 8:20 AM, Robert Bruninga wrote:
>>>>> Bob!  You forgot the most important part that was recently discovered!
>>>>> The Yaesu FTM-350 REQUIRES the frequency at the beginning of the
>>>> comment!
>>>> 
>>>> All of the advantages of the FREQ objects come from them appearing in
>>>> the STATION list on mobile radios.  It makes no sense to me to break
>>>> that intentended system design due to a minor bug in the 350.
>>>> 
>>>> Putting the FREQ in the OBJECT name as designed appears just fine and as
>>>> intended in the 350 and the 350 can also sort them too.   So all of the
>>>> original functionality of this FREQ system also works on the 350. The
>>>> only thing the 350 won't do correctly is the QSY button.
>>> _______________________________________________
>>> aprssig mailing list
>>> aprssig at tapr.org
>>> http://www.tapr.org/mailman/listinfo/aprssig
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> http://www.tapr.org/mailman/listinfo/aprssig
>> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
> 