On 24/11/2014 22:51, Michael Black wrote:
Hi Mike,
> 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
OK, some comments below.
> Mike W9MDB
>
> -----Original Message-----
> From: Bill Somerville [mailto:g4...@classdesign.com]
> Sent: Monday, November 24, 2014 4:38 PM
> To: wsjt-devel@lists.sourceforge.net
> 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.
read_string() is clearly documented as taking the receive buffer length
in the rxmax argument, i.e. including room for the terminating '\0' char
that will be added to the end.
>>
>> 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.
Most protocols have a specific terminating character, as does the
ten-tec protocol, you will not get a time out if the terminating
character is seen, i.e. the '\r' char.
Looks to me that the whole problem stems from tentec_transaction() in
tentec.c not using the message termination character set arguments to
read_string(). Are there some ten-tec protocols that don;'t use the '\r'
terminator character?
>> 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.
read_string() is clearly documented as requiring a buffer pointer and a
length including the space for the terminating '\0' char that will be
added to make the reply a valid C string. If you make that change you
will break many other back ends.
>>
>>
>> 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?
This area is definitely a bit dubious, I have made some fixes there but
it may still be broken.
The select further up is where the time out happens, total_count should
be incremented there because the read just above is guaranteed to have
read a character. If you are seeing the read being called after a time
out then something is broken in the select code.
>> Mike W9MDB
>>
> 73
> Bill
> G4WJS.
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
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
