You referred to me to whatever version this is which I assume is the hamlib3 custom one you've referred to for WSJT-X? git clone git://git.code.sf.net/u/bsomervi/hamlib src Mike W9MDB
-----Original Message----- From: Bill Somerville [mailto:[email protected]] Sent: Monday, November 24, 2014 4:38 PM To: [email protected] Subject: Re: [wsjt-devel] Rig control problem with RigBlaster On 24/11/2014 22:27, Michael Black wrote: Hi Mike, > The string length logic seems a bit inconsistent on hamlib. > It looks to me like all rigs that use hamlib serial com should be > having problems. > > I checked some other rigs and it appears they should have similar > problems with truncated responses. > > If you read_string() with a correct expected length for the response > you get back length-1. Maybe this doesn't cause problems if most rigs > return a 0x0d or such on the end of their responses. > If you ask for more bytes than you expect you get a timeout and an > extra byte. > > It's fairly obvious that you don't want to hit a timeout on every > command...so the "expected response length" should be the right argument. > The Omni VII has some commands which are binary and exact length is > returned plus the implementation for several commands was wrong and I'm fixing those. > I've got basic operation working now and am working on split mode. > > In read_string() it does this incorrect logic which ends up return one > less byte than requested > while (total_count < rxmax-1) { > Presumably to make room for this > rxbuffer[total_count] = '\000'; > > I changed that and commented out the insertion of the terminator > while (total_count < rxmax) { > // rxbuffer[total_count] = '\000'; > // maybe this should be rxbuffer[total_count+1]='\000' but I'm leary > of this since I'm sure many calling functions may not expect to have > to allow for an extra byte Either string_read should add the > terminating zero and the calling functions ensure they have length+1 > bytes available.... > Or...the calling functions should be responsible for ensuring a > terminating zero. > > > With that change it behaves for the Omni VII with the corrected > command set that I've implemented getting back the correct length for all commands. > > And I think the extra byte on timeout is fixed with this in iofunc.c > by adding a rd_count > 0 check instead of always incrementing total_count > rd_count = port_read(p, &rxbuffer[total_count], 1); > if (rd_count > 0) { > ++total_count; > } These changes are very familiar. What version of hamlib are you basing your changes on? > Mike W9MDB > 73 Bill G4WJS. ---------------------------------------------------------------------------- -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
