Here are some answers to some of the questions posed about LP-Bridge behavior...
1. LPB responds to all application "GET" commands from memory, without passing the commands to the K3. This happens asynchronously from up to five applications at the same time. Each application only sees responses to its own queries, unless the user has checked the "AI1" or "AI2" options for that virtual port. 2. LPB forces the K3 into AI2 and K31 meta modes. There are optional check boxes for each virtual port to change the AI behavior on a per-application basis, as mentioned above. Making adjustments at the K3 will not generate commands to any application unless its virtual port has the "AI1" or "AI2" option checked. There is no provision for accommodating K30 meta-commands. 3. The only commands that LPB allows to propagate to the K3 are SET commands. Normally, this is not a problem, but there is a chance that two applications could conflict in this regard when accessing menu data. This is complicated by timing considerations. This should be a rare occurrence, but I can see possible cases where it could be a problem. For instance, if a program uses periodic VFO UP or DN commands to implement scanning and then a second program starts a menu access operation during the scan. I would have to think through all the combinations, but it seems that the operator's limitation of only having one mouse and one free hand would limit the cases where a problem could exist. 4. LPB will not allow use of the K3 Utility through a virtual port for safety reasons. I am considering adding code to lock out SET commands from other virtual ports once one app sends a MNnnn; command, until the MN255; command is sent. This could cause other problems, though. It would be better if the UP/DN commands associated with the menu functions could be changed to menu specific special commands, like UPM and DNM, as opposed to using the regular VFO UP/DN commands. This of course would become an issue with existing programs. 73, Larry N8LP Barry asked for the ability to display AGC parameters. These values are currently read by accessing menus and reading them from the VFO A display area. During that menu access, another application might send an UP or DN command, which could change one of the AGC parameters. That's my only point. New single-command queries could solve that particular issue. I don't know the list of K3 commands that LP-Bridge blocks. I don't know how LP-Bridge uses its knowledge of what one application is doing to influence the commands permitted by another. I'm using the TelepostInc.com LPB html help page as my source of info on what LP-Bridge does. LP-Bridge offers a useful subset of the K3 Command set to many applications. But it's the LP-Bridge virtualization that these applications see, and that's different from the K3 programmer's reference command set. This is a very useful subset, but arguably insufficient for the requested application. Dick, K6KR -- View this message in context: http://n2.nabble.com/K3-needs-survey-firmware-and-application-software-tp4209832p4211541.html Sent from the Elecraft mailing list archive at Nabble.com. ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html
