Streeter, Samuel S ERDC-RDE-CRREL-NH CIV
2017-02-23 12:18:11 UTC
Hi all,
I am using the PyUSB 1.0 module with libusb 1.0 for a backend, Python 2.7,
on an embedded Linux system running Debian 7.0 (Wheezy). To describe my
issue, I think that I must provide a little background about my project. I
am using PyUSB to facilitate USB control of a spectrum analyzer (i.e., a
Spectran HF-60105 V4 X) using the device's API. The embedded computer and
spectrum analyzer are a part of a field deployable system, and as such, the
system must be able to operate at temperatures below freezing (but of
course, above the documented temperature specifications for all hardware).
This is where I run into problems. Specifically, my code works without a
hitch when it is warm outside, but it seems to run into an issue when it's
operating in cooler temperatures (i.e., around freezing). Below is a snippet
of command line output from the Python script when it is warm outside (i.e.,
room temperature), and all is working fine. The hex that follows each API
command is the device's response. The "verify" response is unique, but the
response to all other commands is a generic "/x31/x60/x21/x00", which
confirms reception by the device.
Verify.....................SUCCESSFUL. /x31/x60/x01/x51/x1a/xf5/xaf
Initial boot calib.........SUCCESSFUL. /x31/x60/x21/x00
Preamplifier...............ON. /x31/x60/x21/x00
Attenuation................OFF. /x31/x60/x21/x00
Start frequency........... 99.5 MHz. /x31/x60/x21/x00
Stop frequency............ 101.5 MHz. /x31/x60/x21/x00
RBW....................... 1000 Hz. /x31/x60/x21/x00
Sweep delay accuracy.......ON. /x31/x60/x21/x00
Sweep reset................SUCCESSFUL. /x31/x60/x21/x00
However, when the system is operating in cooler temperatures, near freezing,
the device's responses appear to be delayed. Basically, it appears that the
device.read() commands are timing out without a response at first, but the
device's responses seem to be queued up in a buffer, because eventually
multiple "OK" responses are received by the computer. In the example shown
below, all ends up just fine, because the commands eventually are received
by the analyzer. However, this doesn't always happen, so this glitch is
currently a showstopper for my system. Here's output from the system when
it's around freezing:
Verify.....................FAILED. /x31/x60
Verify.....................SUCCESSFUL.
/x31/x60/x01/x51/x1a/xf5/xaf/x01/x51/x1a/xf5/xaf
Initial boot calib.........FAILED. /x31/x60
Initial boot calib.........FAILED. /x31/x60
Initial boot calib.........FAILED. /x31/x60
Initial boot calib.........SUCCESSFUL.
/x31/x60/x21/x00/x21/x00/x21/x00/x21/x00
Preamplifier set...........FAILED. /x31/x60
Preamplifier set...........FAILED. /x31/x60
Preamplifier set...........FAILED. /x31/x60
Preamplifier...............ON. /x31/x60/x21/x00/x21/x00/x21/x00/x21/x00
Attenuator set.............FAILED. /x31/x60
Attenuator set.............FAILED. /x31/x60
Attenuator set.............FAILED. /x31/x60
Attenuation................OFF. /x31/x60/x21/x00/x21/x00/x21/x00/x21/x00
Start frequency set.......FAILED. /x31/x60
Start frequency set.......FAILED. /x31/x60
Start frequency set.......FAILED. /x31/x60
Start frequency........... 99.5 MHz.
/x31/x60/x21/x00/x21/x00/x21/x00/x21/x00
Stop frequency set........FAILED. /x31/x60
Stop frequency set........FAILED. /x31/x60
Stop frequency............ 101.5 MHz. /x31/x60/x21/x00/x21/x00/x21/x00
RBW set...................FAILED. /x31/x60
RBW set...................FAILED. /x31/x60
RBW set...................FAILED. /x31/x60
RBW....................... 1000 Hz. /x31/x60/x21/x00/x21/x00/x21/x00/x21/x00
Sweep delay accuracy.......FAILED. /x31/x60
Sweep delay accuracy.......FAILED. /x31/x60
Sweep delay accuracy.......FAILED. /x31/x60
Sweep delay accuracy.......ON. /x31/x60/x21/x00/x21/x00/x21/x00/x21/x00
Sweep reset................FAILED. /x31/x60
Sweep reset................FAILED. /x31/x60
Sweep reset................FAILED. /x31/x60
Sweep reset................SUCCESSFUL.
/x31/x60/x21/x00/x21/x00/x21/x00/x21/x00
I'm at a complete loss as to why I'm observing this trend, which is very
repeatable. I've isolated the embedded board and tested its functionality in
the cold; it's just fine. I've communicated with the manufacturers of the
spectrum analyzer, and they do not report any issues with the device at
these "near freezing" temperatures, being well above the analyzer's lowest
operational temperature of -20 C. Furthermore, when I use the manufacturer's
proprietary software to interface with the analyzer, it behaves just fine
even at the cooler temperatures in question.
Tying this back into PyUSB, I'm curious if anyone out there has dealt with
something like this and might have recommendations for USB communication
parameters to adjust or specific PyUSB functions or objects that might help
me diagnose my issue.
Thanks in advance for your time!
Best,
Sam
I am using the PyUSB 1.0 module with libusb 1.0 for a backend, Python 2.7,
on an embedded Linux system running Debian 7.0 (Wheezy). To describe my
issue, I think that I must provide a little background about my project. I
am using PyUSB to facilitate USB control of a spectrum analyzer (i.e., a
Spectran HF-60105 V4 X) using the device's API. The embedded computer and
spectrum analyzer are a part of a field deployable system, and as such, the
system must be able to operate at temperatures below freezing (but of
course, above the documented temperature specifications for all hardware).
This is where I run into problems. Specifically, my code works without a
hitch when it is warm outside, but it seems to run into an issue when it's
operating in cooler temperatures (i.e., around freezing). Below is a snippet
of command line output from the Python script when it is warm outside (i.e.,
room temperature), and all is working fine. The hex that follows each API
command is the device's response. The "verify" response is unique, but the
response to all other commands is a generic "/x31/x60/x21/x00", which
confirms reception by the device.
Verify.....................SUCCESSFUL. /x31/x60/x01/x51/x1a/xf5/xaf
Initial boot calib.........SUCCESSFUL. /x31/x60/x21/x00
Preamplifier...............ON. /x31/x60/x21/x00
Attenuation................OFF. /x31/x60/x21/x00
Start frequency........... 99.5 MHz. /x31/x60/x21/x00
Stop frequency............ 101.5 MHz. /x31/x60/x21/x00
RBW....................... 1000 Hz. /x31/x60/x21/x00
Sweep delay accuracy.......ON. /x31/x60/x21/x00
Sweep reset................SUCCESSFUL. /x31/x60/x21/x00
However, when the system is operating in cooler temperatures, near freezing,
the device's responses appear to be delayed. Basically, it appears that the
device.read() commands are timing out without a response at first, but the
device's responses seem to be queued up in a buffer, because eventually
multiple "OK" responses are received by the computer. In the example shown
below, all ends up just fine, because the commands eventually are received
by the analyzer. However, this doesn't always happen, so this glitch is
currently a showstopper for my system. Here's output from the system when
it's around freezing:
Verify.....................FAILED. /x31/x60
Verify.....................SUCCESSFUL.
/x31/x60/x01/x51/x1a/xf5/xaf/x01/x51/x1a/xf5/xaf
Initial boot calib.........FAILED. /x31/x60
Initial boot calib.........FAILED. /x31/x60
Initial boot calib.........FAILED. /x31/x60
Initial boot calib.........SUCCESSFUL.
/x31/x60/x21/x00/x21/x00/x21/x00/x21/x00
Preamplifier set...........FAILED. /x31/x60
Preamplifier set...........FAILED. /x31/x60
Preamplifier set...........FAILED. /x31/x60
Preamplifier...............ON. /x31/x60/x21/x00/x21/x00/x21/x00/x21/x00
Attenuator set.............FAILED. /x31/x60
Attenuator set.............FAILED. /x31/x60
Attenuator set.............FAILED. /x31/x60
Attenuation................OFF. /x31/x60/x21/x00/x21/x00/x21/x00/x21/x00
Start frequency set.......FAILED. /x31/x60
Start frequency set.......FAILED. /x31/x60
Start frequency set.......FAILED. /x31/x60
Start frequency........... 99.5 MHz.
/x31/x60/x21/x00/x21/x00/x21/x00/x21/x00
Stop frequency set........FAILED. /x31/x60
Stop frequency set........FAILED. /x31/x60
Stop frequency............ 101.5 MHz. /x31/x60/x21/x00/x21/x00/x21/x00
RBW set...................FAILED. /x31/x60
RBW set...................FAILED. /x31/x60
RBW set...................FAILED. /x31/x60
RBW....................... 1000 Hz. /x31/x60/x21/x00/x21/x00/x21/x00/x21/x00
Sweep delay accuracy.......FAILED. /x31/x60
Sweep delay accuracy.......FAILED. /x31/x60
Sweep delay accuracy.......FAILED. /x31/x60
Sweep delay accuracy.......ON. /x31/x60/x21/x00/x21/x00/x21/x00/x21/x00
Sweep reset................FAILED. /x31/x60
Sweep reset................FAILED. /x31/x60
Sweep reset................FAILED. /x31/x60
Sweep reset................SUCCESSFUL.
/x31/x60/x21/x00/x21/x00/x21/x00/x21/x00
I'm at a complete loss as to why I'm observing this trend, which is very
repeatable. I've isolated the embedded board and tested its functionality in
the cold; it's just fine. I've communicated with the manufacturers of the
spectrum analyzer, and they do not report any issues with the device at
these "near freezing" temperatures, being well above the analyzer's lowest
operational temperature of -20 C. Furthermore, when I use the manufacturer's
proprietary software to interface with the analyzer, it behaves just fine
even at the cooler temperatures in question.
Tying this back into PyUSB, I'm curious if anyone out there has dealt with
something like this and might have recommendations for USB communication
parameters to adjust or specific PyUSB functions or objects that might help
me diagnose my issue.
Thanks in advance for your time!
Best,
Sam