On 30/11/2015 21:32, Michael Hartje wrote: > The wsjtx shows in the command line start console: >> >QIODevice::write: device not open >> >Got a buffer underflow! >> >Got a buffer underflow! > rigctl -m 2 -L shows some more available features, which could reduce > the problem: >> >write_delay: "Delay in ms between each byte sent out" >> > Default: 0, Value: 0 >> > Range: 0.0..1000.0, step 1.0 >> >post_write_delay: "Delay in ms between each command sent out" >> > Default: 0, Value: 0 >> > Range: 0.0..1000.0, step 1.0 >> >timeout: "Timeout in ms" >> > Default: 0, Value: 2000 >> > Range: 0.0..10000.0, step 1.0 >> >retry: "Max number of retry" >> > Default: 0, Value: 3 >> > Range: 0.0..10.0, step 1.0 Hi Michael,
none of the above have any relevance to rig control in your setup. When using the Hamlib NET rigctl driver the command I/O from WSJT-X is small and all the work is done at the other end. I assume quisk has an emulation of the Hamlib rigcrtld daemon built in. It is possible that quisk is not assigning enough CPU resource to servicing the TCP/IP traffic. An easy fix would be to reduce the polling interval in WSJT-X. Try a long interval like 99s at first to see what happens. WSJT-X does several retries to re-establish rig control after errors, if it is getting as far as an error message then the situation is very poor. 73 Bill G4WJS. ------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
