Re: [Dx4win] Radio time outs with DX4WIN, LP_Bridge, K3 win XP PRO
Same here. It's been unusable since i upgraded to version 8.05. I keep getting radio timeouts. What has changed? 73, Andreas, N6NU On Jul 18, 2011, at 6:42 PM, Randy Farmer wrote: > I have the same setup and I also experience occasional dropouts of radio > control with the K3. I don't remember ever being in front of the radio > when it happened, so I don't know exactly how often it happens or if > it's correlated to anything in particular. I have observed that > sometimes when VFO A and VFO B are on different bands the bandmap will > momentarily jump to the VFO B band and then back to the normal VFO A > band. This may be a clue. > > My interface to the K3 is through a microHAM MK2R+ two-radio box, with > the radio run from the primary (virtual) CAT port and LP-Bridge run from > the (virtual) 2nd CAT port. Since the radio isn't a LP-Bridge client, I > suspect the problem is somewhere in the DX4WIN-K3 interface rather than > in LP-Bridge. I used a microHAM microKeyer II that runs the same Router > software with a FT-1000D and an Icom 746 for a couple of years and don't > recall seeing any dropouts with either of those radios. My money's on > some sort of subtle K3 software interface problem. > > 73... > Randy, W8FN > >> I am running a K3, DX4win 8.05, LP Bridge and a K3 from Elecraft. >> Approximately 2-3 times per hour I get a radio time out message from >> DX4WIN. I have to restart (START RADIO) again to accept entries. I have a >> friend with the same setup including computer, WINXP PRO SP3 and K3; he has >> the same issue. The computer is an E5300, INTEL @2.6 GHz with 3.49GB Ram. >> >> My gut tells me the issue is with LP_Bridge but that is a guess at the >> moment. I did not have this issue with my IC 756Pro 3. Running com 1 at >> 38.400 per the K3 spec. >> >> Has anyone out there experienced this problem and come up with a solution? > __ > DX4WIN mailing list > Home: http://mailman.qth.net/mailman/listinfo/dx4win > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:DX4WIN@mailman.qth.net > > 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:DX4WIN@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html
Re: [Dx4win] Radio time outs with DX4WIN, LP_Bridge, K3 win XP PRO
I have the same setup and I also experience occasional dropouts of radio control with the K3. I don't remember ever being in front of the radio when it happened, so I don't know exactly how often it happens or if it's correlated to anything in particular. I have observed that sometimes when VFO A and VFO B are on different bands the bandmap will momentarily jump to the VFO B band and then back to the normal VFO A band. This may be a clue. My interface to the K3 is through a microHAM MK2R+ two-radio box, with the radio run from the primary (virtual) CAT port and LP-Bridge run from the (virtual) 2nd CAT port. Since the radio isn't a LP-Bridge client, I suspect the problem is somewhere in the DX4WIN-K3 interface rather than in LP-Bridge. I used a microHAM microKeyer II that runs the same Router software with a FT-1000D and an Icom 746 for a couple of years and don't recall seeing any dropouts with either of those radios. My money's on some sort of subtle K3 software interface problem. 73... Randy, W8FN > I am running a K3, DX4win 8.05, LP Bridge and a K3 from Elecraft. > Approximately 2-3 times per hour I get a radio time out message from > DX4WIN. I have to restart (START RADIO) again to accept entries. I have a > friend with the same setup including computer, WINXP PRO SP3 and K3; he has > the same issue. The computer is an E5300, INTEL @2.6 GHz with 3.49GB Ram. > > My gut tells me the issue is with LP_Bridge but that is a guess at the > moment. I did not have this issue with my IC 756Pro 3. Running com 1 at > 38.400 per the K3 spec. > > Has anyone out there experienced this problem and come up with a solution? __ DX4WIN mailing list Home: http://mailman.qth.net/mailman/listinfo/dx4win Help: http://mailman.qth.net/mmfaq.htm Post: mailto:DX4WIN@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html
Re: [Dx4win] Speaking of /0
John, First time I've ever heard someone state to drop the /#. I once questioned one of the major contest sponsoring organization on this. They told me they strip the /# before doing the call checking. Reason is too many people are inconsistent in signing with the /#. I've experienced this many times myself when you can work a station on multiple bands. Generally I log what is sent. Then after the contest when I prepare the file to load into DX4WIN, if the exchange includes me a location, like NAQP, I will strip the /#. Then during the import process I will load the location info into the appropriate field. This way when I do a search I can see all the different locations I've worked you without having to include the /# or a wildcard. (I dislike wildcard characters mainly due to no two programs seem to use the same character so I am constantly trying to remember what character to use with what program). Bill AC0W -Original Message- From: dx4win-boun...@mailman.qth.net [mailto:dx4win-boun...@mailman.qth.net] On Behalf Of John Holmes Sent: Monday, July 18, 2011 12:48 PM To: dx4win@mailman.qth.net Subject: [Dx4win] Speaking of /0 All, At the end of the NAQP I was "told" by a station that I was calling that I should drop the /8 from my call (W9ILY/8) as it is not used in contests. Actually, that person was not correct in that some contests specifically state that the call zone must be indicated if different from the licensed call zone. The station I was working refused to add the /8 after my call, so I guess it won't count for one of us, probably him as he won't report the correct call. As many of you know, I have operated from a number of states and have used /7, /8, /9 and /0, mainly to differentiate between the operating locations. If I were only to give my name and state (with a variety of states such as OR, IA, MT, NE, WY, ND, SD, WI, IN, OH, MI, etc. from which I have operated) I'm sure that the correct state would be questioned many times. Am I not correct in this thinking? I sure don't want to make it more difficult for the receiving station to copy the correct info the very first time. In all the operations that I have made, this is the very first time that I have been "told" to drop the /8 suffix. 73, John W9ILY __ DX4WIN mailing list Home: http://mailman.qth.net/mailman/listinfo/dx4win Help: http://mailman.qth.net/mmfaq.htm Post: mailto:DX4WIN@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html
[Dx4win] Orion Radio File
Does anyone have a TenTec Orion II definition they prefer over the standard ones provided? Byron __ DX4WIN mailing list Home: http://mailman.qth.net/mailman/listinfo/dx4win Help: http://mailman.qth.net/mmfaq.htm Post: mailto:DX4WIN@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html
Re: [Dx4win] Speaking of /0
Hi John, Thanks for the Qs in NAQP. I have run into this a few times also but the contests that want you to add the number designator specify so in their rules. In NAQP it's not needed but certainly is a valid call just the same. I am WA1PMA in WA and only in very bad condx do I get questioned on where, MA or WA and in the recent RTTY QSO PARTY out of 400+ qs only was asked that question once. The op that gave you grief apparently had a bad day or was ill informed! 73 Wayne WA1PMA in WA On 7/18/2011 10:47 AM, John Holmes wrote: > All, > > At the end of the NAQP I was "told" by a station that I was calling that I > should drop the /8 from my call (W9ILY/8) as it is not used in contests. > Actually, that person was not correct in that some contests specifically > state that the call zone must be indicated if different from the licensed > call zone. The station I was working refused to add the /8 after my call, so > I guess it won't count for one of us, probably him as he won't report the > correct call. > > As many of you know, I have operated from a number of states and have used > /7, /8, /9 and /0, mainly to differentiate between the operating locations. > If I were only to give my name and state (with a variety of states such as > OR, IA, MT, NE, WY, ND, SD, WI, IN, OH, MI, etc. from which I have operated) > I'm sure that the correct state would be questioned many times. Am I not > correct in this thinking? I sure don't want to make it more difficult for > the receiving station to copy the correct info the very first time. In all > the operations that I have made, this is the very first time that I have > been "told" to drop the /8 suffix. > > 73, > > > John W9ILY > > __ > DX4WIN mailing list > Home: http://mailman.qth.net/mailman/listinfo/dx4win > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:DX4WIN@mailman.qth.net > > 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:DX4WIN@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html
[Dx4win] Radio time outs with DX4WIN, LP_Bridge, K3 win XP PRO
Hi Gang: I am running a K3, DX4win 8.05, LP Bridge and a K3 from Elecraft. Approximately 2-3 times per hour I get a radio time out message from DX4WIN. I have to restart (START RADIO) again to accept entries. I have a friend with the same setup including computer, WINXP PRO SP3 and K3; he has the same issue. The computer is an E5300, INTEL @2.6 GHz with 3.49GB Ram. My gut tells me the issue is with LP_Bridge but that is a guess at the moment. I did not have this issue with my IC 756Pro 3. Running com 1 at 38.400 per the K3 spec. Has anyone out there experienced this problem and come up with a solution? 73 -- Dave K3FT __ DX4WIN mailing list Home: http://mailman.qth.net/mailman/listinfo/dx4win Help: http://mailman.qth.net/mmfaq.htm Post: mailto:DX4WIN@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html
[Dx4win] Speaking of /0
All, At the end of the NAQP I was "told" by a station that I was calling that I should drop the /8 from my call (W9ILY/8) as it is not used in contests. Actually, that person was not correct in that some contests specifically state that the call zone must be indicated if different from the licensed call zone. The station I was working refused to add the /8 after my call, so I guess it won't count for one of us, probably him as he won't report the correct call. As many of you know, I have operated from a number of states and have used /7, /8, /9 and /0, mainly to differentiate between the operating locations. If I were only to give my name and state (with a variety of states such as OR, IA, MT, NE, WY, ND, SD, WI, IN, OH, MI, etc. from which I have operated) I'm sure that the correct state would be questioned many times. Am I not correct in this thinking? I sure don't want to make it more difficult for the receiving station to copy the correct info the very first time. In all the operations that I have made, this is the very first time that I have been "told" to drop the /8 suffix. 73, John W9ILY __ DX4WIN mailing list Home: http://mailman.qth.net/mailman/listinfo/dx4win Help: http://mailman.qth.net/mmfaq.htm Post: mailto:DX4WIN@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html
[Dx4win] Tr : IC735 remote control
Info for those interested in this topic. 73, Radi F6GNZ - Mail transféré - >De : Jim Hargrave >À : Mel >Cc : DX4WIN Refelector ; supp...@dx4win.com; John >Sweeney ; "Radivoj Kar, F6GNZ" >Envoyé le : Lundi 18 Juillet 2011 15h24 >Objet : RE: [Dx4win] IC735 remote control > >Mel, > >Let me offer some insight about the IC-735. I have had my IC-735 since the >early 1980's. >I have used it with several radio control programs. > >The IC-735 and a couple of other early ICOM radios use a first generation >CI-V protocol. This is a 4 bit system, whereas the later models all use a 5 >bit version. As such it is more limited in available commands. > >The IC-735 comes with CI-V factory default of 1200 baud with Transceive ON. >The CI-V address is set at 04(hex). All three of these parameters are >changeable with jumpers inside the radio. I have configured my IC-735 to run >at 9600 baud rate. It is much less prone for data collisions at this speed. > >Now the Transceive issue. The IC-735 will NOT send CI-V Data with Transceive >OFF. It will only receive commands, but not respond to polls. This is >different than later model ICOM Radios. Hence there is more of a possibility >of data collisions with the IC-735. This can easily be verified by using an >RS-232 line tester. I have found this tester a very valuable tool for >troubleshooting CAT/CI-V behavior. > >I run my ICOM IC-735 in an SO2R configuration with Logger32. I have found >that at 9600 baud with 2 stop bits, a poll interval of 250ms is the fastest >it will run and avoid data collisions. This polling interval might differ >with different control programs, depending on the complexity of the poll >data word and expected response. > >I have never used DX4WIN. I had a demo copy of ver 8.01 and it worked fine >with my IC-735. To assist Radi in his problem, I downloaded a demo copy of >ver 8.05. That is when I discovered the ICOM 735.rig file did not work. I >copied the rig file from my 8.01 version into the 8.05 folder and it then >worked. > >I am not a member of the DX4WIN group. Please feel free to post this on that >group if you feel it of any value to other IC-735 users. > > 73s de Jim > W5IFP > > > > -Original Message- > > From: Mel [mailto:ve...@videotron.ca] > > Sent: Sunday, July 17, 2011 6:33 PM > > To: Radivoj Kar, F6GNZ > > Cc: DX4WIN Refelector; supp...@dx4win.com; John Sweeney; Jim Hargrave > > Subject: 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! > > > > 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. > > > > 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 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 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
[Dx4win] Re : IC735 remote control
Hi Mel, Thanks for your comments. Please find my responses after your text: Best 73, Radi F6GNZ > >De : Mel >À : "Radivoj Kar, F6GNZ" >Cc : DX4WIN Refelector ; "supp...@dx4win.com" >; John Sweeney ; Jim Hargrave > >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 w
