Menu
▾
▴
pyusb-users
|
From: stuart l. <stu...@gm...> - 2022-04-24 00:42:36
|
I am seeing a consistent issue with Garmin Ant+ dongles under Windows with
libusb0.
They work the first time my application runs, but fail on the second
attempt.
I have verified the same behaviour across three Garmin Dongles. I have
verified that the Cycplus Dongle works correctly.
To maintain compatibility with the other applications running (Zwift and
PerfPro CT Smart) which rely on libusb0 I need to use that backend.
Those applications do not have any problems with the Garmin (or Cycplus)
dongles, using them multiple times without a problem.
Is it possible that I need to do something on exit that might cause this?
Is there anything I can do to remediate this when seen?
Thanks!
2022-04-23 17:13:40,318 INFO:usb.core:find(): using backend
> "usb.backend.libusb0"
> 2022-04-23 17:13:40,318
> DEBUG:usb.backend.libusb0:_LibUSB.enumerate_devices()
> 2022-04-23 17:13:40,318
> DEBUG:usb.backend.libusb0:_LibUSB.get_device_descriptor(<usb.backend.libusb0._usb_device
> object at 0x000002073629D940>)
> is_ant_device: dev: 0x1009
> @
>
>
> /reap
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.get_interface_descriptor(<usb.backend.libusb0._usb_device
> object at 0x000002073629D940>, 0, 0, 0)
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.get_configuration_descriptor(<usb.backend.libusb0._usb_device
> object at 0x000002073629D940>, 0)
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.get_endpoint_descriptor(<usb.backend.libusb0._usb_device
> object at 0x000002073629D940>, 0, 0, 0, 0)
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.get_interface_descriptor(<usb.backend.libusb0._usb_device
> object at 0x000002073629D940>, 0, 0, 0)
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.get_configuration_descriptor(<usb.backend.libusb0._usb_device
> object at 0x000002073629D940>, 0)
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.get_endpoint_descriptor(<usb.backend.libusb0._usb_device
> object at 0x000002073629D940>, 1, 0, 0, 0)
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.get_interface_descriptor(<usb.backend.libusb0._usb_device
> object at 0x000002073629D940>, 0, 0, 0)
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.get_configuration_descriptor(<usb.backend.libusb0._usb_device
> object at 0x000002073629D940>, 0)
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.bulk_write(2229757821776, 1, 0,
> array('B', [164, 1, 74, 48, 223]), 2000)
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.bulk_read(2229757821776, 129, 0,
> array('B', [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]), 4000)
>
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.bulk_write(2229757821776, 1, 0,
> array('B', [164, 1, 74, 48, 223]), 2000)
> USBLoop.run: USBError e.errno: None e.backend_error_code: -5
> USBLoop.run: USBError e: [USBError(None, b'libusb0-dll:err
> [_usb_reap_async] reaping request failed, win error: A device attached to
> the system is not functioning.\r\n\n')]
>
>
--
__________O___________
_______-\<,____________
_____(_)/_(_)___________
_________________________
Stuart_Lynne____<stu...@gm...>____604-518-1749(m)__604-461-7532(h)
|
|
From: Xiaofan C. <xia...@gm...> - 2022-04-24 03:45:06
|
On Sun, Apr 24, 2022 at 8:43 AM stuart lynne <stu...@gm...> wrote: > > I am seeing a consistent issue with Garmin Ant+ dongles under Windows with libusb0. > > They work the first time my application runs, but fail on the second attempt. > > I have verified the same behaviour across three Garmin Dongles. I have verified > that the Cycplus Dongle works correctly. > > To maintain compatibility with the other applications running (Zwift and PerfPro > CT Smart) which rely on libusb0 I need to use that backend. > > Those applications do not have any problems with the Garmin (or Cycplus) > dongles, using them multiple times without a problem. > > Is it possible that I need to do something on exit that might cause this? > > Is there anything I can do to remediate this when seen? > Does it make a difference if you use the libusb-1.0 backend? This is not a solution but rather a troubleshooting step. You can keep your driver as it is, but switch to libusb-1.0 backend. You need to have libusbk.dll and libusb-1.0.dll in place to make that work. I understand that you may have to keep with the libusb0.sys based driver provided by Garmin (I used to have one such USB dongle for my old Garmin Vivofit 1). The other potential work-around is to add a device reset at exit. Usually this kind of issue is caused by device firmware bug (eg: USB data toggle issues) and the hope is that the device reset can put the firmware to a good state. -- Xiaofan |
|
From: stuart l. <stu...@gm...> - 2022-04-24 06:31:09
|
The device reset seems to help. When properly exited it went about eight restarts correctly. Interrupted (^C) exit I think misses the device reset in some cases (I can fix that) and eventually it got to the FUBAR state. Once in that state opening and closing with reset does not fix it. Physical replug necessary. I'll clean up the exception handling so that breaking to exit goes through the proper closing sequence and see if that helps. Thanks! On Sat, Apr 23, 2022 at 8:45 PM Xiaofan Chen <xia...@gm...> wrote: > On Sun, Apr 24, 2022 at 8:43 AM stuart lynne <stu...@gm...> > wrote: > > > > I am seeing a consistent issue with Garmin Ant+ dongles under Windows > with libusb0. > > > > They work the first time my application runs, but fail on the second > attempt. > > > > I have verified the same behaviour across three Garmin Dongles. I have > verified > > that the Cycplus Dongle works correctly. > > > > To maintain compatibility with the other applications running (Zwift and > PerfPro > > CT Smart) which rely on libusb0 I need to use that backend. > > > > Those applications do not have any problems with the Garmin (or Cycplus) > > dongles, using them multiple times without a problem. > > > > Is it possible that I need to do something on exit that might cause this? > > > > Is there anything I can do to remediate this when seen? > > > > Does it make a difference if you use the libusb-1.0 backend? This is not > a solution but rather a troubleshooting step. You can keep your driver > as it is, but switch to libusb-1.0 backend. You need to have libusbk.dll > and libusb-1.0.dll in place to make that work. > > I understand that you may have to keep with the libusb0.sys based > driver provided > by Garmin (I used to have one such USB dongle for my old Garmin Vivofit 1). > > The other potential work-around is to add a device reset at exit. Usually > this kind of issue is caused by device firmware bug (eg: USB data toggle > issues) and the hope is that the device reset can put the firmware to a > good > state. > > > > -- > Xiaofan > > > _______________________________________________ > pyusb-users mailing list > pyu...@li... > https://lists.sourceforge.net/lists/listinfo/pyusb-users > -- __________O___________ _______-\<,____________ _____(_)/_(_)___________ _________________________ Stuart_Lynne____<stu...@gm...>____604-518-1749(m)__604-461-7532(h) |
|
From: stuart l. <stu...@gm...> - 2022-04-27 08:50:21
|
I can confirm that doing the device reset on exit corrects this issue. One additional note, it is probably impossible to protect everything with a try: expect: for a KeyboardInterrupt. This exception can happen more or less at random anywhere or anytime in your program when the user does a ^C. The only way to have a stable solution is to install a signal handler for SIGINT. Then implement a graceful exit strategy that can do the device reset at the correct time as you bring down the program. See: https://docs.python.org/3/library/signal.html If a signal handler raises an exception, the exception will be propagated > to the main thread and may be raised after any bytecode instruction. Most > notably, a KeyboardInterrupt may appear at any point during execution. Most > Python code, including the standard library, cannot be made robust against > this, and so a KeyboardInterrupt (or any other exception resulting from a > signal handler) may on rare occasions put the program in an unexpected > state. > For many programs, especially those that merely want to exit on > KeyboardInterrupt, this is not a problem, but applications that are complex > or require high reliability should avoid raising exceptions from signal > handlers. They should also avoid catching KeyboardInterrupt as a means of > gracefully shutting down. Instead, they should install their own SIGINT > handler. On Sat, Apr 23, 2022 at 11:30 PM stuart lynne <stu...@gm...> wrote: > The device reset seems to help. > > When properly exited it went about eight restarts correctly. > > Interrupted (^C) exit I think misses the device reset in some cases (I can > fix that) and eventually it got to the FUBAR state. > > Once in that state opening and closing with reset does not fix it. > Physical replug necessary. > > I'll clean up the exception handling so that breaking to exit goes through > the proper closing sequence and see if that helps. > > > Thanks! > > > On Sat, Apr 23, 2022 at 8:45 PM Xiaofan Chen <xia...@gm...> wrote: > >> On Sun, Apr 24, 2022 at 8:43 AM stuart lynne <stu...@gm...> >> wrote: >> > >> > I am seeing a consistent issue with Garmin Ant+ dongles under Windows >> with libusb0. >> > >> > They work the first time my application runs, but fail on the second >> attempt. >> > >> > I have verified the same behaviour across three Garmin Dongles. I have >> verified >> > that the Cycplus Dongle works correctly. >> > >> > To maintain compatibility with the other applications running (Zwift >> and PerfPro >> > CT Smart) which rely on libusb0 I need to use that backend. >> > >> > Those applications do not have any problems with the Garmin (or Cycplus) >> > dongles, using them multiple times without a problem. >> > >> > Is it possible that I need to do something on exit that might cause >> this? >> > >> > Is there anything I can do to remediate this when seen? >> > >> >> Does it make a difference if you use the libusb-1.0 backend? This is not >> a solution but rather a troubleshooting step. You can keep your driver >> as it is, but switch to libusb-1.0 backend. You need to have libusbk.dll >> and libusb-1.0.dll in place to make that work. >> >> I understand that you may have to keep with the libusb0.sys based >> driver provided >> by Garmin (I used to have one such USB dongle for my old Garmin Vivofit >> 1). >> >> The other potential work-around is to add a device reset at exit. Usually >> this kind of issue is caused by device firmware bug (eg: USB data toggle >> issues) and the hope is that the device reset can put the firmware to a >> good >> state. >> >> >> >> -- >> Xiaofan >> >> >> _______________________________________________ >> pyusb-users mailing list >> pyu...@li... >> https://lists.sourceforge.net/lists/listinfo/pyusb-users >> > > > -- > __________O___________ > _______-\<,____________ > _____(_)/_(_)___________ > _________________________ > Stuart_Lynne____<stu...@gm... > >____604-518-1749(m)__604-461-7532(h) > -- __________O___________ _______-\<,____________ _____(_)/_(_)___________ _________________________ Stuart_Lynne____<stu...@gm...>____604-518-1749(m)__604-461-7532(h) |
Thanks for helping keep SourceForge clean.
X