They are both no-name usb/serial leads. lsusb isn't any help as they both
show up as:
ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
I was told by the guy I borrowed the working one from that there are
different versions of the PL2303 and ymmv with linux. Either that or one
companies hardware implementation is better.
I think what made me look at the software for the problem was that I was
getting *some* data through. I tend to agree about the disapearance of
adapter leads though.
Cheers
Stewart
On Wed, Aug 26, 2009 at 5:59 PM, Robert Lipe <robertlipe@...:
>
>
> On Wed, Aug 26, 2009 at 9:49 AM, Stewart Hardwick <
> hardwick.stewart@...> wrote:
>
>> Problem solved, different USB/serial cable works fine. Thanks for your
>> help
>>
>
> Please provide details on this device so that next time this comes up, I
> don't have to stare at protocol specs and implementation for an hour to work
> this through.
>
> I'll say it again: *The faster USB/serial adapters disappear from the
> planet, the happier I'll be. *
>
> RJL
>
>
>
>>
>> Cheers
>> Stewart
>>
>>
>> On 26 Aug 2009, at 16:03, Robert Lipe <robertlipe@...> wrote:
>>
>>
>>
>> On Wed, Aug 26, 2009 at 7:57 AM, Stewart Hardwick <<hardwick.stewart@...>
>> hardwick.stewart@...> wrote:
>>
>>> Thanks, I'll try and eliminate the USB/serial adapter this evening
>>> (unless it is guilty of course...)
>>>
>>
>> The faster USB/serial adapters disappear from the planet, the happier I'll
>> be. A pox upon Garmin for even releasing the etrex H with a serial port in
>> 2008 when the Venture HC (that is USB, includes the cable, has a color
>> screen and supports maps) costs about the same once you add a serial cable
>> and USB converter to the eTrex.
>>
>>
>>> I have tried some windows based stuff using a real serial port with
>>> success, so I guess gpsbabel on windows would be a place to start
>>>
>>
>> Definitely. It's not like GPSBabel on Windows has different tables for
>> A000 devices than GPSBabel on Linux.
>>
>> RJL
>>
>>
>>
>>
>>>
>>>
>>> On 26 Aug 2009, at 15:44, Robert Lipe < <robertlipe@...>
>>> robertlipe@...> wrote:
>>>
>>>
>>>
>>> On Tue, Aug 25, 2009 at 12:28 PM, Stewart <<hardwick.stewart@...>
>>> hardwick.stewart@...> wrote:
>>>
>>>> Trying to upload a waypoint to an etrex H using ubuntu and a usb/serial
>>>> adapter:
>>>>
>>>> sudo gpsbabel -D9 -i geo -f geocaching.loc -o garmin -F /dev/ttyUSB0
>>>> GPSBabel Version: 1.3.6
>>>> Tx Data:10 fe 00 02 10 03 : ...(PRDREQ )
>>>> Rx Data:10 06 02 fe 00 fa 10 03 .. (ACK )
>>>> Rx Data:10 ff 22 b8 02 36 01 65 54 72 65 78 20 48 20 53 6f 66 74 77 61
>>>> 72 65 20 56 65 72 73 69 6f 6e 20 33 2e 31 30 00 2b 10
>>>> 03 ..6.eTrex.H.Software.Version.3.10. (PRDDAT )
>>>> Tx Data:10 06 02 ff 00 f9 10 03 : .....(ACK )
>>>> Unit: eTrex H Software Version 3.10
>>>> ID: 696
>>>> Version: 3.10[WARNING] A001 protocol not supported
>>>> [ERROR] INIT: No table entry for ID 696
>>>>
>>>> GARMIN:Can't init /dev/ttyUSB0
>>>>
>>>> Does this mean my unit isn't supported?
>>>
>>>
>>> Wow. That's really a strange interaction with that unit. I'm skeptical
>>> that you're the first one to use an eTrex H with GPSBabel; GSAK users have
>>> surely exercised it, albeit on Windows.
>>>
>>> We issue a Product Request (see section 4.1.1 of the Garmin protocol
>>> spec) in packet 1.
>>> The device ACKs that response and then says it's a product ID 696 running
>>> version 3.10 and a description. We ACK that.
>>>
>>> The packet I'd expect to see next in an even vaguely contemporary unit is
>>> a PidProtocolArray so the unit can stream its capabilities to us. We don't
>>> get one (A001 not supported) so we fall back to the section 8.2 horror and
>>> consult Garmin's documented list of GPSes that have hard-coded
>>> capabilities. This is a set of last century gear like the GPS 38, the GPS
>>> 45, and the GPS 12. The original eTrex from early in this century (from
>>> which the eTrex H is derived) is even too new to be on this list - yellow
>>> eTrex definitely supported A001. As some perspective, Garmin product IDs go
>>> up over time. The newest unit in their table is product ID 112, the GPS
>>> 92. Yours is product ID 696.
>>>
>>> Here's the corresponding dump from the original eTrex:
>>>
>>> $ ./gpsbabel -D9 -i-f /dev/cu.USA19H1a2P1.1 -o csv -F /dev/null
>>> GPSBabel Version: 1.3.7-beta20090808
>>> Tx Data:10 fe 00 02 10 03 : ...(PRDREQ )
>>> Rx Data:10 06 02 fe 00 fa 10 03 .. (ACK )
>>> Rx Data:10 ff 20 82 00 d2 00 65 54 72 65 78 20 53 6f 66 74 77 61 72 65 20
>>> 56 65 72 73 69 6f 6e 20 32 2e 31 30 00 33 10 03
>>> ....eTrex.Software.Version.2.10. (PRDDAT )
>>> Tx Data:10 06 02 ff 00 f9 10 03 : .....(ACK )
>>> Unit: eTrex Software Version 2.10
>>> ID: 130
>>> Version: 2.10Rx Data:10 fd 3c 50 00 00 4c 01 00 41 0a 00 41 64 00 44
>>> 6c 00 41 c9 00 44 ca 00 44 6c 00 44 d2 00 41 2d 01 44 36 01 44 2d 01 41 f4
>>> 01 44 f5 01 41 58 02 44 58 02 41 bc 02 44 bc 02 41 20 03 44 20 03 db 10 03
>>> P..L..A..Ad.Dl.A..D..Dl.D..A..D6.D..A..D..AX.DX.A..D..A..D.. (PRTARR )
>>> Tx Data:10 06 02 fd 00 fb 10 03 : .....(ACK )
>>>
>>> Capability A10:
>>> Capability A100: D108
>>> Capability A201: D202 D108 D210
>>> Capability A301: D310 D301
>>> Capability A500: D501
>>> Capability A600: D600
>>> Capability A700: D700
>>> Capability A800: D800
>>> Link_type 1 Device_command 0
>>> Waypoint: Transfer 100 Type 108
>>> Route: Transfer 201 Header 202 Type 108
>>> Track: Transfer 301 Type 301
>>>
>>> From this, we could probably guess what protocols the unit uses and
>>> create an entry in the GPS_MP array in gpsprot.c for model number 696. But
>>> it strikes me as extremely unlikely that the eTrex H would be substantially
>>> more stupid than the eTrex. Is it possible that your USB/serial adapter is
>>> losing that data packet or something?
>>>
>>> Does any other software talk to this thing? If it really doesn't
>>> support A001, I'd expect it to not work with most software.
>>>
>>> RJL
>>>
>>>
>>
>
|