[Dx4win] Re : IC735 remote control

[Radivoj Kar, F6GNZ]

Hi Mel,
Thanks for your comments. Please find my responses after your text:

Best 73,

Radi F6GNZ




>________________________________
>De : Mel <ve2dc at videotron.ca>
>À : "Radivoj Kar, F6GNZ" <f6gnz at yahoo.com>
>Cc : DX4WIN Refelector <dx4win at mailman.qth.net>; "support at dx4win.com" <support at dx4win.com>; John Sweeney <johns707 at comcast.net>; Jim Hargrave <w5ifp at gvtc.com>
>Envoyé le : Lundi 18 Juillet 2011 1h32
>Objet : Re: [Dx4win] IC735 remote control
>
>re 1. That's interesting. The 735 and some Ten Tecs use the Icom protocol but the frequency string is one byte shorter. I used the 735 years ago without issue so I wouldn't have suspected the rig file. Good catch!
>Ihave used my IC735 many years ago  with one of very early versions of dx4winand it worked OK. In the meantime, replaced it qith IC706 for portable operation and now decided to leave 735 in my summer home permanently. But, as I made a new ci-v interface I suspected it rather than dx4win bug in new version. Testing with DXLab  Commander told me that interface is OK and something was wrong in dx4win, but couldn't find what. Jim, W5IFP detected a problem in the rig file in new dx4win releases. 
>2. This doesn't make any sense. Any polling rate should work providing it is not too short for the radio to respond. with 5000ms it will update every 5 seconds. You do need retries, with older Icoms they will ignore polling requests if they are busy, for example spinning the dial. I typically use 4 and timeouts are rare... but any number should work. With a number too low the rig might time out occasionally.Newer rigs can time out too but you almost have to go out of your way to trigger a timeout because of the faster processors. It has happened with my 7700 doing some major knob spinning (never think to use the keypad ;-) In any case, you should not have to play with these values to make it work. I've used from 500ms to 2 seconds without trouble. I never tried faster than 1 second with my old 751A.
>As I often change frequencies/ bands , a 5000ms polling time would be too long for updating logging window. Besides, as I said, the only way to update it quickly under this condition is to click on Receive in frequency control window. Everything happens faster and automatically with a shorter polling time. I know it shouldn't be too short, but 350 ms was OK and works all the time. 
>3. It is not actually necessary to change this value in the rig file, all it does is change the "default" speed. You can override in preferences.
>I know, but as I have set ic735 jumper for 9600 bps, I thought it was natural to set it as a default value in the rig file, not borhering to uncheck default and enter 9600 in the preferences box.
>I believe CI-V should be OFF for reliable performance with DX4Win. With older rigs (probably including the 735) leaving this on can cause data collisions and corrupt data which results in erroneous frequencies being reported. This can be dangerous if using amps or tuners relying on C-IV for frequency information.
>I had set the jumper off prior to testing, but when it stopped to respond to polling I thought I should put it back as Jim told me it worked OK with a new rig file with his 735 that had trx jumper ON. So I set it ON again and after having a success finding a good polling time compromise, I just left it ON. If I see any collision issues, will set it to OFF again, but so far I don't experience any problems with it. .But it's good to know that this could be an issue in some cases.
>I should mention that this has not happened to me recently... I no longer have my 781 which was the last radio with which I experienced this problem. My IC910H did not have this issue which is why I suspect the newer radios are "better" at detecting collisions.
>
>Can someone confirm if this data collision problem still happens with older Icoms with V8.05? I seem to remember it did in 8.01 causing the bandmap to shift erratically, but Paul did some tweaking in subsequent versions.
>
>
>On 2011-07-17 17:37, Radivoj Kar, F6GNZ wrote:
>> Hi,
>> 
>> With a precious help of Jim Hargrave , W5IFP, the problem was solved!
>> 
>> 1. Original IC735.rig files in dx4win  versions 8.04 and 8.05 are WRONG! Rig timeouts occur regularly with these versions, whatever polling time and retries numbers are chosen. Good file was found by Jim in version 8.01 and maybe was also good in earlier dx4win versions.
>> 
>> 2. With the good dx4win ver 8.01 rig file, to
>> obtain log window's band/mode to reflect changes on the rig selections, a
>> lot of combinations of polling times/retries were tried. In some of
>> them, like with default polling time of 5000ms, it was required to open
>> the radio frequency setup window and click on "read" to make logging
>> window reflect the changes. The combination that works automatically and FB, without having to open the frequency setup window, , is 350ms and 3 retries (set in Radio Preferences). Some other close to these numbers may work also, but this one works all the time in my case)
>> 
>> 3. Speed in ic735.rig  file and preferences was changed from 1200 bps to
>> 9600 bps and JU22 in radio was also set to 9600 bps (left position
>> contacts). Also, "ci-v transceive" jumper in radio ( the last contacts on the
>> right) was left ON.
>> 
>> RMX: transceiver band/frequency will not be reflected correctly in logging window if radio is tuned to a frequency out of HAM band limits, which is OK.
>> 
>> 
>> Now, I am haaaaappy again...... :)
>> 
>> 73,
>> Radi F6GNZ
>> ______________________________________________________________
>> DX4WIN mailing list
>> Home: http://mailman.qth.net/mailman/listinfo/dx4win
>> Help: http://mailman.qth.net/mmfaq.htm
>> Post: mailto:DX4WIN at mailman.qth.net
>> 
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>> 
>
>
>