A while back, I wrote a CW functional test for the K3. In doing this, I ran straight into the programming problems cited earlier by Ed. My solution wasn't very innovative or elegant (not being involved in the firmware development at all), but it was adequate and met the requirements.
After establishing comm and getting control of the K3, the I would poll the toggle and multi-value states parameters that could be set by the program. There was a list of 25 or so controls of this type, and I would just add new ones as needed. The really fun part was reading back the values. I had to dump the VFO A or VFO B displays to do it. I took my cue from Dick Dievendorf, assuming he'd done something like this to read back the RTC time in the Set Date and Time tab on the K3 Utility. Having the MN and MP commands saved a lot of effort as above, but the implementation is partial. That is not all MN parameters can be polled or set. So displaying parameters' toggle or multi-value state is about the only way, in the general case. For a multi-value parameter (TEXT DEC is one I had to use a lot!), dialing through all the values is a little cumbersome and requires as many functions to get/set as the number of parameters that are used. OTOH, there are probably many MN parameters that would never be used by a hosted program and I believe that's why Wayne decided to implement the ones that were obviously needed or perhaps only those that were requested by software developers. At the start of the program, I'd store all the toggles and multi-value parameters that the program could touch. When exiting back to Windows, the app would restore these, including the initial baud rate. The idea was to leave the K3 in the same exact state before and after. I would guess the best argument for having a known default state is from Ed. But executing such a command would introduce a bit of entropy, meaning the K3 would end up in a different state from what it was when the hosted program was started. This might be ... disturbing ... to users, and disruptive to using the K3 without having to manually restore a bunch of parameters' states. 73, Matt Zilmer Consultant - Product Management Dept. Magellan Navigation / MiTAC Digital Corp. Tel: (909) 394-6052 Cell: (909) 730-6552 In status quo voluntas non sufficit -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of W0SD Ed Gray Sent: Friday, December 07, 2012 11:07 AM To: [email protected] Subject: [Elecraft] Big weakness in Macro's IMHO there is a big need for a command that can be use to define things back to the same state. One big rule in programming is you always set the state of things so you are always dealing with a known starting point. The command structure in the K3 does not permit this. A number of things in the K3 are toggle, for example in MIC SEL 1 toggles the mic back and forth from high to low and 2 toggles for bias on or no bias. There are a number of other instances of this in the K3. Not having a command to define things back to the same state, lets call it a default or reset state makes the programming commands in the K3 pretty weak IMHO. Ed W0SD ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft 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 ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft 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
