AUTOINF Auto 1 Anomaly
Locked
 
|
All of a sudden, my SteppIR stopped tracking my K3 even though the SteppIR controller was in General Mode. This has been working for years and I had made no recent changes to cabling. I confirmed that CONFIG AUTOINF was set to Auto 1. Then I ran a logging program that polls the radio and the SteppIR began tracking just fine. I turned off the logger and it stopped tracking again. It was exactly as if AUTOINF was set to nor. So I cycled that setting, changing AUTOINF to nor and then back to Auto 1. Finally, the SteppIR resumed tracking without the logger. Has anyone else seen this or have an idea why Auto 1 quietly stopped sending frequency messages until I cycled it?
(I could have power cycled the radio before cycling AUTOINF but did not. I'll try that if it happens again.) Thanks, /Rick N6XI ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
Rick,
When used with a logging program, the SteppIR controller only listens on the RS-232 signalling - it does not initiate any data requests from the K3 (it depends on the logging program to poll for that data. If the logging program is not active, then SteppIR must poll for band information - there is a setting in the SteppIR application to allow or disallow the SteppIR direct polling for K3 data. Check the SteppIR information for the details. It does come down to the fact that RS-232 buss definitions do not allow for multiple drivers on a signalling line. When in use with other com port oriented applications (such as a logger), the SteppIR controlled must disable its drivers (but not the receivers). When the logger application is not present, the SteppIR controller must issue commands (A driver must be enabled) to the K3 and apparently in your case, that is not happening. Check your settings for the SteppIR application. 73, Don W3FPR On 3/25/2015 9:32 PM, Rick Tavan wrote: > All of a sudden, my SteppIR stopped tracking my K3 even though the SteppIR controller was in General Mode. This has been working for years and I had made no recent changes to cabling. I confirmed that CONFIG AUTOINF was set to Auto 1. Then I ran a logging program that polls the radio and the SteppIR began tracking just fine. I turned off the logger and it stopped tracking again. It was exactly as if AUTOINF was set to nor. So I cycled that setting, changing AUTOINF to nor and then back to Auto 1. Finally, the SteppIR resumed tracking without the logger. Has anyone else seen this or have an idea why Auto 1 quietly stopped sending frequency messages until I cycled it? > > ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
I have been informed by those who really know that my statement is
incorrect. If the K3 is set to AUTOINFO=1, the SteppIR should receive the K3 band and frequency information without a logger being active. 73, Don W3FPR On 3/25/2015 10:29 PM, Don Wilhelm wrote: > Rick, > > When used with a logging program, the SteppIR controller only listens > on the RS-232 signalling - it does not initiate any data requests from > the K3 (it depends on the logging program to poll for that data. > If the logging program is not active, then SteppIR must poll for band > information - there is a setting in the SteppIR application to allow > or disallow the SteppIR direct polling for K3 data. Check the SteppIR > information for the details. > > It does come down to the fact that RS-232 buss definitions do not > allow for multiple drivers on a signalling line. When in use with > other com port oriented applications (such as a logger), the SteppIR > controlled must disable its drivers (but not the receivers). When the > logger application is not present, the SteppIR controller must issue > commands (A driver must be enabled) to the K3 and apparently in your > case, that is not happening. Check your settings for the SteppIR > application. > > 73, > Don W3FPR > > On 3/25/2015 9:32 PM, Rick Tavan wrote: >> All of a sudden, my SteppIR stopped tracking my K3 even though the >> SteppIR controller was in General Mode. This has been working for >> years and I had made no recent changes to cabling. I confirmed that >> CONFIG AUTOINF was set to Auto 1. Then I ran a logging program that >> polls the radio and the SteppIR began tracking just fine. I turned >> off the logger and it stopped tracking again. It was exactly as if >> AUTOINF was set to nor. So I cycled that setting, changing AUTOINF to >> nor and then back to Auto 1. Finally, the SteppIR resumed tracking >> without the logger. Has anyone else seen this or have an idea why >> Auto 1 quietly stopped sending frequency messages until I cycled it? >> ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
Thanks, Don. That's what I thought.
Cycling AUTOINF Off, then On got it working again. But after that it kept cycling between 14.000 and 14.050 as if the K3 were sending bogus IF; messages. It did this several times during most minutes until I power cycled the radio. So now I have seen two styles of AUTOINF misbehavior, not readily reproducible. I'm off to the other QTH now for a few days and won't be able to work on it but will try to characterize it better when I get back. Meanwhile, if others have seen errant AUTOINF operation, please let me know. Thanks, Rick -- Rick Tavan iPhone > On Mar 26, 2015, at 5:00 AM, Don Wilhelm <[hidden email]> wrote: > > I have been informed by those who really know that my statement is incorrect. > If the K3 is set to AUTOINFO=1, the SteppIR should receive the K3 band and frequency information without a logger being active. > > 73, > Don W3FPR > >> On 3/25/2015 10:29 PM, Don Wilhelm wrote: >> Rick, >> >> When used with a logging program, the SteppIR controller only listens on the RS-232 signalling - it does not initiate any data requests from the K3 (it depends on the logging program to poll for that data. >> If the logging program is not active, then SteppIR must poll for band information - there is a setting in the SteppIR application to allow or disallow the SteppIR direct polling for K3 data. Check the SteppIR information for the details. >> >> It does come down to the fact that RS-232 buss definitions do not allow for multiple drivers on a signalling line. When in use with other com port oriented applications (such as a logger), the SteppIR controlled must disable its drivers (but not the receivers). When the logger application is not present, the SteppIR controller must issue commands (A driver must be enabled) to the K3 and apparently in your case, that is not happening. Check your settings for the SteppIR application. >> >> 73, >> Don W3FPR >> >>> On 3/25/2015 9:32 PM, Rick Tavan wrote: >>> All of a sudden, my SteppIR stopped tracking my K3 even though the SteppIR controller was in General Mode. This has been working for years and I had made no recent changes to cabling. I confirmed that CONFIG AUTOINF was set to Auto 1. Then I ran a logging program that polls the radio and the SteppIR began tracking just fine. I turned off the logger and it stopped tracking again. It was exactly as if AUTOINF was set to nor. So I cycled that setting, changing AUTOINF to nor and then back to Auto 1. Finally, the SteppIR resumed tracking without the logger. Has anyone else seen this or have an idea why Auto 1 quietly stopped sending frequency messages until I cycled it? > > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[hidden email] > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html > Message delivered to [hidden email] Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
Rick, obviously if it worked before, and it's working now, your hookup can
not be the problem and never could have been. One possible cause: The communication chips that send and receive this sort of message have a little bit of on-board memory, which is used as a ring buffer. Sometimes, due to a static blip or an accident of timing or whatever, these buffers can get hosed. A hardware reboot will fix it. This might have been what happened in your case; the computer and the steppir chips were working okay and could talk to each other, but the k3 had gotten into a frozen state. This sort of thing can also be caused by rf in the shack. Anyway, you're up and going, so all is well. 73, Tony KT0NY On Thu, Mar 26, 2015 at 10:57 AM, Rick Tavan <[hidden email]> wrote: > Thanks, Don. That's what I thought. > > Cycling AUTOINF Off, then On got it working again. But after that it kept > cycling between 14.000 and 14.050 as if the K3 were sending bogus IF; > messages. It did this several times during most minutes until I power > cycled the radio. So now I have seen two styles of AUTOINF misbehavior, not > readily reproducible. I'm off to the other QTH now for a few days and won't > be able to work on it but will try to characterize it better when I get > back. > > Meanwhile, if others have seen errant AUTOINF operation, please let me > know. > > Thanks, > > Rick > > -- > Rick Tavan > iPhone > > > On Mar 26, 2015, at 5:00 AM, Don Wilhelm <[hidden email]> wrote: > > > > I have been informed by those who really know that my statement is > incorrect. > > If the K3 is set to AUTOINFO=1, the SteppIR should receive the K3 band > and frequency information without a logger being active. > > > > 73, > > Don W3FPR > > > >> On 3/25/2015 10:29 PM, Don Wilhelm wrote: > >> Rick, > >> > >> When used with a logging program, the SteppIR controller only listens > on the RS-232 signalling - it does not initiate any data requests from the > K3 (it depends on the logging program to poll for that data. > >> If the logging program is not active, then SteppIR must poll for band > information - there is a setting in the SteppIR application to allow or > disallow the SteppIR direct polling for K3 data. Check the SteppIR > information for the details. > >> > >> It does come down to the fact that RS-232 buss definitions do not allow > for multiple drivers on a signalling line. When in use with other com port > oriented applications (such as a logger), the SteppIR controlled must > disable its drivers (but not the receivers). When the logger application > is not present, the SteppIR controller must issue commands (A driver must > be enabled) to the K3 and apparently in your case, that is not happening. > Check your settings for the SteppIR application. > >> > >> 73, > >> Don W3FPR > >> > >>> On 3/25/2015 9:32 PM, Rick Tavan wrote: > >>> All of a sudden, my SteppIR stopped tracking my K3 even though the > SteppIR controller was in General Mode. This has been working for years and > I had made no recent changes to cabling. I confirmed that CONFIG AUTOINF > was set to Auto 1. Then I ran a logging program that polls the radio and > the SteppIR began tracking just fine. I turned off the logger and it > stopped tracking again. It was exactly as if AUTOINF was set to nor. So I > cycled that setting, changing AUTOINF to nor and then back to Auto 1. > Finally, the SteppIR resumed tracking without the logger. Has anyone else > seen this or have an idea why Auto 1 quietly stopped sending frequency > messages until I cycled it? > > > > ______________________________________________________________ > > Elecraft mailing list > > Home: http://mailman.qth.net/mailman/listinfo/elecraft > > Help: http://mailman.qth.net/mmfaq.htm > > Post: mailto:[hidden email] > > > > This list hosted by: http://www.qsl.net > > Please help support this email list: http://www.qsl.net/donate.html > > Message delivered to [hidden email] > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[hidden email] > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html > Message delivered to [hidden email] > Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
You know this but...
By hardware reboot, he means complete shutdown to power off; unplug power source; count to a hundred by Pi; then bringing it all back up. Sometimes 'off' isn't OFF and a soft reboot doesn't clear buffers (requires power gone). 73, Rick wa6nhc Tiny iPhone 5 keypad, typos are inevitable > On Mar 26, 2015, at 9:59 AM, Tony Estep <[hidden email]> wrote: > > Rick, obviously if it worked before, and it's working now, your hookup can > not be the problem and never could have been. > > One possible cause: The communication chips that send and receive this sort > of message have a little bit of on-board memory, which is used as a ring > buffer. Sometimes, due to a static blip or an accident of timing or > whatever, these buffers can get hosed. A hardware reboot will fix it. This > might have been what happened in your case; the computer and the steppir > chips were working okay and could talk to each other, but the k3 had gotten > into a frozen state. This sort of thing can also be caused by rf in the > shack. Anyway, you're up and going, so all is well. > > 73, > Tony KT0NY > > >> On Thu, Mar 26, 2015 at 10:57 AM, Rick Tavan <[hidden email]> wrote: >> >> Thanks, Don. That's what I thought. >> >> Cycling AUTOINF Off, then On got it working again. But after that it kept >> cycling between 14.000 and 14.050 as if the K3 were sending bogus IF; >> messages. It did this several times during most minutes until I power >> cycled the radio. So now I have seen two styles of AUTOINF misbehavior, not >> readily reproducible. I'm off to the other QTH now for a few days and won't >> be able to work on it but will try to characterize it better when I get >> back. >> >> Meanwhile, if others have seen errant AUTOINF operation, please let me >> know. >> >> Thanks, >> >> Rick >> >> -- >> Rick Tavan >> iPhone >> >>> On Mar 26, 2015, at 5:00 AM, Don Wilhelm <[hidden email]> wrote: >>> >>> I have been informed by those who really know that my statement is >> incorrect. >>> If the K3 is set to AUTOINFO=1, the SteppIR should receive the K3 band >> and frequency information without a logger being active. >>> >>> 73, >>> Don W3FPR >>> >>>> On 3/25/2015 10:29 PM, Don Wilhelm wrote: >>>> Rick, >>>> >>>> When used with a logging program, the SteppIR controller only listens >> on the RS-232 signalling - it does not initiate any data requests from the >> K3 (it depends on the logging program to poll for that data. >>>> If the logging program is not active, then SteppIR must poll for band >> information - there is a setting in the SteppIR application to allow or >> disallow the SteppIR direct polling for K3 data. Check the SteppIR >> information for the details. >>>> >>>> It does come down to the fact that RS-232 buss definitions do not allow >> for multiple drivers on a signalling line. When in use with other com port >> oriented applications (such as a logger), the SteppIR controlled must >> disable its drivers (but not the receivers). When the logger application >> is not present, the SteppIR controller must issue commands (A driver must >> be enabled) to the K3 and apparently in your case, that is not happening. >> Check your settings for the SteppIR application. >>>> >>>> 73, >>>> Don W3FPR >>>> >>>>> On 3/25/2015 9:32 PM, Rick Tavan wrote: >>>>> All of a sudden, my SteppIR stopped tracking my K3 even though the >> SteppIR controller was in General Mode. This has been working for years and >> I had made no recent changes to cabling. I confirmed that CONFIG AUTOINF >> was set to Auto 1. Then I ran a logging program that polls the radio and >> the SteppIR began tracking just fine. I turned off the logger and it >> stopped tracking again. It was exactly as if AUTOINF was set to nor. So I >> cycled that setting, changing AUTOINF to nor and then back to Auto 1. >> Finally, the SteppIR resumed tracking without the logger. Has anyone else >> seen this or have an idea why Auto 1 quietly stopped sending frequency >> messages until I cycled it? >>> >>> ______________________________________________________________ >>> Elecraft mailing list >>> Home: http://mailman.qth.net/mailman/listinfo/elecraft >>> Help: http://mailman.qth.net/mmfaq.htm >>> Post: mailto:[hidden email] >>> >>> This list hosted by: http://www.qsl.net >>> Please help support this email list: http://www.qsl.net/donate.html >>> Message delivered to [hidden email] >> ______________________________________________________________ >> Elecraft mailing list >> Home: http://mailman.qth.net/mailman/listinfo/elecraft >> Help: http://mailman.qth.net/mmfaq.htm >> Post: mailto:[hidden email] >> >> This list hosted by: http://www.qsl.net >> Please help support this email list: http://www.qsl.net/donate.html >> Message delivered to [hidden email] >> > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[hidden email] > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html > Message delivered to [hidden email] Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
In reply to this post by Rick Tavan N6XI
Hi Rick,
I would like to comment on the mystery cycling between 14000 and 14050. I have experienced this behavior. Do you have more than one SteppIR controller? Are they slaved together and is the master controller the older style and the slave controller(s) the SDA100 style? If yes, then the problem may be caused by the fact that the old controller resolves frequency to 10Hz and the SDA100 resolves to 1Hz. Logging programs tend to request frequency information every second or so. The SDA100 display will immediately display the exact frequency. But a second later it will correct itself to the 10Hz resolution of the master controller. 73, Mike K2MK
|
«
Return to Elecraft
|
1 view|%1 views
| Free forum by Nabble | Edit this page |