Nate Eldredge <[EMAIL PROTECTED]> writes:
> +++ QLandkarte_0.7.3.new/src/device/CSerial.cpp 2008-07-24
> 18:32:11.000000000 -0700
> @@ -307,7 +307,7 @@
> }
>
> //wait 100 millisecs here (like GPSexplorer does)
> - usleep(100000);
> + usleep(500000);
> +++ QLandkarte_0.7.3.new/src/device/EtrexLegend/CDevice.cpp 2008-07-24
> 18:35:30.000000000 -0700
> @@ -171,6 +171,8 @@
> *(uint16_t*)command.payload = 0x000A;
> serial->write(command);
>
> + sleep(10);
> +
> ready= 0;
> while(!ready && serial->read(response) > 0) {
> if(response.id == 74) {
I'm not exactly sure the above will fix all such problems, it may
break with newer or older firmware again.
I think we should do it as Garmin recommends (I've sent a test patch
some time ago to the list) - use a fixed 1-second (or maybe half)
timeout for ACK/NAK packets, and variable timeout for "feedback"
packets. This way we don't need to sleep(10) and even with an RS232
port which drops data when switching speed we don't get out of "sync"
(because the timeout actually works and is short enough to allow
successful recovery (= the receiver doesn't revert to 9600 bps)).
Unfortunately I didn't get comments from CSerial authors last time,
would you like me to resend the patch?
--
Krzysztof Halasa
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
QLandkarte-users mailing list
QLandkarte-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qlandkarte-users
