Fix breaking change that makes the Ten Tec Omni VI (564) not work

[ny4i]

The code for the Omni VI was included in uRadioPolling in pIcomNew. But I left out the Ten Tec code. Put this back into its own procedure called pOmni564.

[n4af]

pOmni564 would definitely help. Tho I am concerned re:coverage of OTHER omni's ? Like newer Omnivii (Omni588)

right now, IcomRadiosThatSupportVFOB does not include omni6- which forces the ELSE in RadioPolling it seems to match up to 4.108.0 fairly well until we drop past get_mode and get_freq and make a call for get_state command '1A'. This is line # 1592 of https://github.com/n4af/TR4W/blob/master/tr4w/src/uRadioPolling.pas I cannot see where TT 564 knows anything about rig.GetIcomDataStateCommand; This was not issued in 4.108.0 ?? Depending on f/b from Cliff, I would like to pull that geticomdatastatecommand out and see what happens ?

[ny4i]

Give me another day to get setup. I say that because I tested that code with several Icom radios and it was fine. I saw the info about the 746 so I’ll check that too. I would like to make the procedure for the 564 Omni. TomPrincipal Solutions ArchitectBetter Software Solutions, Inc. 727-437-2771On Nov 8, 2022, at 8:34 AM, Howie Hoyt @.***> wrote: pOmni564 would definitely help. Tho I am concerned re:coverage of OTHER omni's ? Like newer Omnivii (Omni588) right now, IcomRadiosThatSupportVFOB does not include omni6- which forces the ELSE in RadioPolling it seems to match up to 4.108.0 fairly well until we drop past get_mode and get_freq and make a call for get_state command '1A'. This is line # 1592 of https://github.com/n4af/TR4W/blob/master/tr4w/src/uRadioPolling.pas I cannot see where TT 564 knows anything about rig.GetIcomDataStateCommand; This was not issued in 4.108.0 ?? Depending on f/b from Cliff, I would like to pull that geticomdatastatecommand out and see what happens ?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[n4af]

Ok. Thanks for all your support Tom ! We need to hand this to HamLib to worry about ;-)

73, Howie

[n4af]

Hi Tom - I have the trace from 4.108.0 pIcomNew procedure sub'd into 4.117 that just arrived. Frequency now works but Cliff reports Mode still switches to NON. The trace all looks good to me- I can see where he turns the knob and 10M freq readout dutifully changes, but the mode query comes back looking good also-so not understanding the switch to NON. Read FE FE 04 E0 04 FD FE FE E0 04 04 03 02 FD from serial port

[ny4i]

I noticed the two command sequences in what was read from the buffer.

Read FE FE 04 E0 04 FD FE FE E0 04 04 03 02 FD from serial port

I presume when the buffer is read, it stops at the first full message and saves the second hal;f for the next Read. Is that a correct assumption?

Tom

On Nov 8, 2022, at 9:30 PM, Howie Hoyt @.***> wrote:

Hi Tom - I have the trace from 4.108.0 pIcomNew procedure sub'd into 4.117 that just arrived. Frequency now works but Cliff reports Mode still switches to NON. The trace all looks good to me- I can see where he turns the knob and 10M freq readout dutifully changes, but the mode query comes back looking good also-so not understanding the switch to NON. Read FE FE 04 E0 04 FD FE FE E0 04 04 03 02 FD from serial port

— Reply to this email directly, view it on GitHub https://github.com/n4af/TR4W/issues/623#issuecomment-1308116616, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC6TWSRPVNRTWIOHHPL43CLWHMEE3ANCNFSM6AAAAAARZPTDNU. You are receiving this because you authored the thread.

[n4af]

well, i read as command/response ? [OMNI VI] Calling WriteFile to write 6 bytes <�� � �> [ReadFromSerialPort] Read FE FE 04 E0 03 FD FE FE E0 04 03 00 14 10 28 00 FD from serial port FE FE 04 E0 03 FD -- FE FE E0 04 03 00 14 10 28 00 FD the way i read it the 'NOT OK's' are from quit-split ? Read FE FE 04 E0 0F FD FE FE E0 04 FA FD from serial port

Not understanding WHY no 'NOT OK' response on the query mode commands ? Read FE FE 04 E0 04 FD FE FE E0 04 04 03 02 FD from serial port All mode response's seem correct to me ?

He has FT1000 entries interspersed in the trace. Any chance TR4W is confused re: addressing ?

Encl latest trace with 4.108.0 with pIcomNew substituted into 4.117

73, Howie

On Tue, Nov 8, 2022 at 11:55 PM Tom Schaefer @.***> wrote:

I noticed the two command sequences in what was read from the buffer.

Read FE FE 04 E0 04 FD FE FE E0 04 04 03 02 FD from serial port

I presume when the buffer is read, it stops at the first full message and saves the second hal;f for the next Read. Is that a correct assumption?

Tom

On Nov 8, 2022, at 9:30 PM, Howie Hoyt @.***> wrote:

Hi Tom - I have the trace from 4.108.0 pIcomNew procedure sub'd into 4.117 that just arrived. Frequency now works but Cliff reports Mode still switches to NON. The trace all looks good to me- I can see where he turns the knob and 10M freq readout dutifully changes, but the mode query comes back looking good also-so not understanding the switch to NON. Read FE FE 04 E0 04 FD FE FE E0 04 04 03 02 FD from serial port

— Reply to this email directly, view it on GitHub < https://github.com/n4af/TR4W/issues/623#issuecomment-1308116616>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AC6TWSRPVNRTWIOHHPL43CLWHMEE3ANCNFSM6AAAAAARZPTDNU . You are receiving this because you authored the thread.

— Reply to this email directly, view it on GitHub https://github.com/n4af/TR4W/issues/623#issuecomment-1308210642, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVLCUFDOXQTYMNX7NWBEV3WHMVDNANCNFSM6AAAAAARZPTDNU . You are receiving this because you commented.Message ID: @.***>

[ny4i]

Please try HamLib for this radio. The only TenTec radio TR4W supports well is the Orion.