TRLog
[Top] [All Lists]

[TRLog] Band Changing Anomalies? (OMNI-VI)

Subject: [TRLog] Band Changing Anomalies? (OMNI-VI)
From: rrossi@btv.ibm.com (Ron D. Rossi)
Date: Fri, 10 Jan 2003 15:32:53 -0500
Thanks Kevin that helps. My head was spinning a bit on this one. There was a 
GREAT DEAL of beta work done on this release by Icom users. I don't know of 
any complaints on that front at this point (folks correct me if I am wrong). 
There has to be some difference between Icom and TenTec which I am exploiting.

Let me detail the change that was made between 6.70 (and earlier) and 6.72 
regarding ***Icom/Ten-Tec***. This does not apply to other radio brands.

COMMANDS TO THE RADIO
6.70 and earlier:
* When a command is sent to the radio TRLog waited ICOM COMMAND PAUSE 
milliseconds before moving on in the code.

* Additionally when setting a frequency if the radio was not defined as an 
IC735 a "filter byte" was sent to the radio as well. This forced a narrow 
filter for that mode if one was available.

6.72:
* When a command is sent to the radio TRLog reads the interface port for a 
"good" response from the radio (excluding the echo) before moving on. If this 
is not received in ICOM RESPONSE TIMEOUT milliseconds TRLog tries again. After 
five tries (hard coded at this point) a communications warning is displayed 
and the command is not executed.

* Additionally when setting a frequency if the radio was defined as an IC765 a 
"filter byte" was sent to the radio as well if in CW mode. This forced a 
narrow filter for that mode if one was available.


FREQ/MODE POLLING
6.70 and earlier:
*When polling the radio for frequency/mode information if the data returned 
ended in the correct character (0xFD and ignoring the echo) and was less than 
160 bytes the data was parsed. The frequency parsing stripped the leading five 
bytes and looked at the remaining bytes prior to the 0xFD. If five bytes were 
present then the bytes were decoded accordingly otherwise it was assumed there 
were four bytes. No attention was paid to rig type here, just the data 
returned. The mode parsing simply looks at the byte preceding the 0xFD.

6.72:
*When polling the radio for frequency information the data returned (excluding 
the echo) is strictly checked for length. For IC735 the length must be 10 
bytes. For all others it is 11 bytes. In each case the data must end with 
0xFD. The frequency is parsed as above, but four byte frequency information is 
excluded by the length check for all but the IC735. There is no support for 
"four byte compatibility mode in non-IC735 radios.

*When polling the radio for mode information the data returned (excluding the 
echo) is strictly checked for length. The length must be 8 bytes. The data 
must end with 0xFD. The mode is parsed as above.

-- 
73 es God Bless de KK1L...ron rossi(kk1l@arrl.net) <><
Support Programmer for TRLog http://www.qth.com/tr
QTH: Jericho, Vermont
My page: http://www.qsl.net/kk1l


>Ron & OMNI-VI Users,
>
>Setting TR to IC781 does not cure this problem.  Setting TR to IC781
>cures the problem of not being able to change bands/frequency by
>entering a frequency into the call window.  Setting TR to any ICxxx
>except IC735 solves this problem.
>
>Setting TR to IC781 and attempting to change bands using the alt-V/B
>results in the bug described for an OMNI-VI radio.
>
>Kevin, W3DAD
>
>
>----- Original Message -----
>From: "Ronald Rossi" <rrossi@btv.ibm.com>
>To: "Kevin Arber" <karber@smart.net>
>Cc: "TRLog Reflector" <trlog@contesting.com>
>Sent: Thursday, January 09, 2003 11:59 PM
>Subject: Re: [TRLog] Band Changing Anomalies?
>
>
>> The Omni6 does not emulate the IC735 like it is said to. Set TR to
>talk
>> to an IC781.
>>
>> Kevin Arber wrote:
>> >
>> > Dale,
>> >
>> > This is exactly what I noticed when using 6.72 or 6.71 with my
>> > OMNI-VI.  Changing back to 6.69 solves the problem.  I ran
>radiodebug
>> > and looked at the log file, but it didn't show anything abnormal
>to
>> > me.  Ron knows about this bug.
>> >
>> > Kevin
>> > W3DAD
>> > ----- Original Message -----
>> > From: "Dale L Martin" <kg5u@hal-pc.org>
>> > To: "TRLog Reflector" <trlog@contesting.com>
>> > Sent: Thursday, January 09, 2003 5:13 PM
>> > Subject: [TRLog] Band Changing Anomalies?
>> >
>> > >
>> > > Anyone notice any band changing anomalies in the new version?
>> > >
>> > > I'm running two omni-vi's and 6.72.
>> > >
>> > > When I change bands, I have to hit the Alt-V or Alt-B twice to
>> > effect a band
>> > > change and then it is not guaranteed the radio will actually
>change
>> > bands
>> > > (the software will/may, but probably not the radio).
>> > >
>> > > If I hit Alt-V or Alt-B once only, the cursor on the band column
>at
>> > the top
>> > > of the screen moves up or down appropriately, but bounces right
>back
>> > to
>> > > where it was and the radio never changes.
>> > >
>> > > I've had TR on 15m showing 21058, but the radio it was
>controlling
>> > on 14027.
>> > >
>> > > Am I missing a command setting or something?
>> > >
>> > > 73,
>> > > dale, kg5u
>> > >
>> > > _______________________________________________
>> > > TRLog mailing list
>> > > TRLog@contesting.com
>> > > http://lists.contesting.com/mailman/listinfo/trlog
>> > >
>> >
>> > _______________________________________________
>> > TRLog mailing list
>> > TRLog@contesting.com
>> > http://lists.contesting.com/mailman/listinfo/trlog
>>
>> --
>> 73 es God Bless de KK1L...ron (kk1l@arrl.net) <><
>> QTH: Jericho, Vermont
>> My page: http://www.qsl.net/kk1l
>> _______________________________________________
>> TRLog mailing list
>> TRLog@contesting.com
>> http://lists.contesting.com/mailman/listinfo/trlog
>>
>
>_______________________________________________
>TRLog mailing list
>TRLog@contesting.com
>http://lists.contesting.com/mailman/listinfo/trlog




<Prev in Thread] Current Thread [Next in Thread>