robertlipe
commented
2 months ago I have an 18. It is a puck https://www.garmin.com/en-US/p/223 product with no screen. It's a PVT/NMEA device only. You can't transfer waypoints, routes, or tracks to/from it. All it knows how to do is shout out the current location every N second. I can't remember any evidence that the device had any storage at all of the types we care about. ISTR ensuring that we didn't crash when talking to lt was abot all we could do with that one beyond NMEA and PVT.
The 15 looks to be a little module https://www.garmin.com/en-US/p/51048/pn/010-00240-31?srsltid=AfmBOoqSD0r2WAwDSuXi5zho7N9fbdKbNRHNdpvjjHtT-C0FnQN6aqJdq2Y that's again just not applicable in our world, isn't it? (So you could imagine it being an 18 without the serial bridge and case.)
I'm not sure they're applicable to us, are they?
I glanced at eBay and they're priced a little crazy. They should be priced like salvage, not collectors items. :-) I'm pretty sure I can find some in old junk drawers once I can ask the right people.kk
I've thought in the past about doing crazy things like writing a Garmin protso emulation test jig something like the STM32 or ESP32 https://www.aliexpress.us/item/2251832814839254.html?. A little dash of ESP-IDF, sweeten with some protocol implementation https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference/peripherals/usb_device.html and then I'd have a customizable fake Garmin for packet capture and testing. But this is a fairly terrible idea because we've not needed to do any non-trivial Garmin USB dev in fifteen years and I don't really need another project. The idea just keeps coming up in my mind because it's something that came up in the past when I DID want to automate such things.
I'll try to find one or more for you. It'll just take a bit since the group I'm thinking of is about to be on the road.
RJL
On Fri, May 17, 2024 at 6:18 PM tsteven4 @.***> wrote:
@.**** commented on this pull request.
In jeeps/gpsserial.cc https://github.com/GPSBabel/gpsbabel/pull/1279#discussion_r1605609158:
return gps_errno;}
- if (global_opts.debug_level >= 1) fprintf(stderr, "Serial port speed set to %d\n", br);
- if (global_opts.debug_level >= 1) {
- fprintf(stderr, "Serial port speed set to %d\n", br);
I have a GPS12 that does 9600 serial only. I have no way to test baud rate changes. Baud rate changes were supported by some variants of the GPS 18. GPS 15xH/15xL had user-selectable baud: 4800, 9600, 19200, 38400. The return code from GPS_Serial_Set_Baud_Rate is also problematic, e.g. success and a tcsetattr error both return 0.
I don't have a usb device, so anything that could allow me to test gpsusb* would be useful as well. That would enable the next step - make GpsDevice an abstract base class - which gets rid of a bunch of casting and gpsdeviceops.
— Reply to this email directly, view it on GitHub https://github.com/GPSBabel/gpsbabel/pull/1279#discussion_r1605609158, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD3YFMNRMQNBZA4NOO2LZC2F5JAVCNFSM6AAAAABHYRSL2GVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDANRUGQ4DKMBRGM . You are receiving this because you commented.Message ID: @.***>
This moves OS specific code out of gpsbabel (taking advantage of OS specific code in QSerialPort). I have tested this with a GPS12 but I am unable to test the baudrate option with that device.
I have conversion of gpsdeviceh to a base class GpsDevice, with subclasses GpsSerialDevice and GpsUsbDevice. I am unable to test GpsUsbDevice at all.
Can we come up with a testing plan? Test in the GPSBabel lab? Relocate some devices to the GPSBabel west lab?