Hi Mel, Thanks for your comments. Please find my responses after your text:
Best 73, Radi F6GNZ >________________________________ >De : Mel <[email protected]> >À : "Radivoj Kar, F6GNZ" <[email protected]> >Cc : DX4WIN Refelector <[email protected]>; "[email protected]" ><[email protected]>; John Sweeney <[email protected]>; Jim Hargrave ><[email protected]> >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:[email protected] >> >> This list hosted by: http://www.qsl.net >> Please help support this email list: http://www.qsl.net/donate.html >> > > > ______________________________________________________________ DX4WIN mailing list Home: http://mailman.qth.net/mailman/listinfo/dx4win Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[email protected] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html
