Suppress UsbRequestJNI / ALOGD log messagesHow do I enable/disable log levels in Android?How to control a serial device on Android?Will an Android device with USB OTG support Infrared tranceivers?Real device produce too many logSuppress toast messages from all apps, system wideUse adb shell to disable spam logs with priority ERRORAndroid Studio on a Mac: log messages not shownSuppress androids system message while accessing USB OTG deviceDebugging React Native over adb tcpipQt Creator not showing log messages on Android 8.0 (LG G6)The usb-otg app hangs on bulktransfer call
How do we know the LHC results are robust?
Sequence of Tenses: Translating the subjunctive
Is exact Kanji stroke length important?
Applicability of Single Responsibility Principle
What is the intuitive meaning of having a linear relationship between the logs of two variables?
System.debug(JSON.Serialize(o)) Not longer shows full string
How can I get through very long and very dry, but also very useful technical documents when learning a new tool?
Are student evaluations of teaching assistants read by others in the faculty?
Anatomically Correct Strange Women In Ponds Distributing Swords
How did Doctor Strange see the winning outcome in Avengers: Infinity War?
Gears on left are inverse to gears on right?
How to check is there any negative term in a large list?
For a non-Jew, is there a punishment for not observing the 7 Noahide Laws?
Risk of infection at the gym?
Is expanding the research of a group into machine learning as a PhD student risky?
Unreliable Magic - Is it worth it?
How do I extract a value from a time formatted value in excel?
Fine Tuning of the Universe
Pole-zeros of a real-valued causal FIR system
Opposite of a diet
Pre-amplifier input protection
CREATE opcode: what does it really do?
How can we prove that any integral in the set of non-elementary integrals cannot be expressed in the form of elementary functions?
How to Reset Passwords on Multiple Websites Easily?
Suppress UsbRequestJNI / ALOGD log messages
How do I enable/disable log levels in Android?How to control a serial device on Android?Will an Android device with USB OTG support Infrared tranceivers?Real device produce too many logSuppress toast messages from all apps, system wideUse adb shell to disable spam logs with priority ERRORAndroid Studio on a Mac: log messages not shownSuppress androids system message while accessing USB OTG deviceDebugging React Native over adb tcpipQt Creator not showing log messages on Android 8.0 (LG G6)The usb-otg app hangs on bulktransfer call
I'm developing an Android app which is streaming serial data from some custom hardware. I'm using mik3y's usb-serial-for-android library to get the serial data over USB in OTG mode, which after some tweaks is working fine.
However, for every transaction over the USB interface, UsbRequestJNI is logging an init and close message. This is swamping LogCat with thousands of log messages per second (note the timestamps):
02-17 09:30:21.590 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.590 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.594 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.594 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.598 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.598 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.602 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.602 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.606 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.606 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.610 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.610 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.614 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.614 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
I know I can filter these in the IDE, but I want to stop them so they're not chewing through debugger bandwidth.
From what I can gather, UsbRequestJNI is an operating-system-provided JNI library, so I can't just edit the source. So how can I tell it to stop logging these debug messages while still running a debug build so I can see other relevant debug info?
Googling around has produced only this, which is basically the same problem but with no resolution that's applicable here.
(My development device is running Android 4.3 and I'm developing on Android Studio 1.0.1)
UPDATE: Just found the source for UsbRequest, the relevant lines being ALOGD statments (lines 45 and 71). So I guess the question becomes: how do I suppress ALOGD messages?
UPDATE 2: I've tried setprop log.tag.UsbRequestJNI SUPPRESS as per this answer, but frustratingly it has no effect on my device.
java
android usbserial android-usb edited May 23 '17 at 12:24
Community♦
11
asked Feb 17 '15 at 10:05
davidf2281davidf2281
1,1651019
add a comment |
I'm developing an Android app which is streaming serial data from some custom hardware. I'm using mik3y's usb-serial-for-android library to get the serial data over USB in OTG mode, which after some tweaks is working fine.
However, for every transaction over the USB interface, UsbRequestJNI is logging an init and close message. This is swamping LogCat with thousands of log messages per second (note the timestamps):
02-17 09:30:21.590 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.590 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.594 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.594 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.598 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.598 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.602 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.602 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.606 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.606 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.610 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.610 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.614 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.614 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
I know I can filter these in the IDE, but I want to stop them so they're not chewing through debugger bandwidth.
From what I can gather, UsbRequestJNI is an operating-system-provided JNI library, so I can't just edit the source. So how can I tell it to stop logging these debug messages while still running a debug build so I can see other relevant debug info?
Googling around has produced only this, which is basically the same problem but with no resolution that's applicable here.
(My development device is running Android 4.3 and I'm developing on Android Studio 1.0.1)
UPDATE: Just found the source for UsbRequest, the relevant lines being ALOGD statments (lines 45 and 71). So I guess the question becomes: how do I suppress ALOGD messages?
UPDATE 2: I've tried setprop log.tag.UsbRequestJNI SUPPRESS as per this answer, but frustratingly it has no effect on my device.
java
android usbserial android-usb edited May 23 '17 at 12:24
Community♦
11
asked Feb 17 '15 at 10:05
davidf2281davidf2281
1,1651019
1
After looking at your links, I began to suspect that you could likely solve this be re-using the USB requests. Further searching found a mention of doing exactly that for exactly this reason in the changelog of the phidgets driver. So if you want to pursue figuring out how to do that it seems like it has been done before and allegedly works.
– Chris Stratton
Feb 21 '15 at 5:52
Thanks for the comment @chris. In the event, it seems that in addition to the over-logging problem, the drivers (at least on my particular hardware) are just too buggy and unreliable so I've switched from Android to standard PC hardware instead. Thanks though!
– davidf2281
Feb 23 '15 at 13:55
add a comment |
I'm developing an Android app which is streaming serial data from some custom hardware. I'm using mik3y's usb-serial-for-android library to get the serial data over USB in OTG mode, which after some tweaks is working fine.
However, for every transaction over the USB interface, UsbRequestJNI is logging an init and close message. This is swamping LogCat with thousands of log messages per second (note the timestamps):
02-17 09:30:21.590 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.590 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.594 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.594 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.598 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.598 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.602 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.602 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.606 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.606 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.610 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.610 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.614 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.614 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
I know I can filter these in the IDE, but I want to stop them so they're not chewing through debugger bandwidth.
From what I can gather, UsbRequestJNI is an operating-system-provided JNI library, so I can't just edit the source. So how can I tell it to stop logging these debug messages while still running a debug build so I can see other relevant debug info?
Googling around has produced only this, which is basically the same problem but with no resolution that's applicable here.
(My development device is running Android 4.3 and I'm developing on Android Studio 1.0.1)
UPDATE: Just found the source for UsbRequest, the relevant lines being ALOGD statments (lines 45 and 71). So I guess the question becomes: how do I suppress ALOGD messages?
UPDATE 2: I've tried setprop log.tag.UsbRequestJNI SUPPRESS as per this answer, but frustratingly it has no effect on my device.
java
android usbserial android-usb edited May 23 '17 at 12:24
Community♦
11
asked Feb 17 '15 at 10:05
davidf2281davidf2281
1,1651019
I'm developing an Android app which is streaming serial data from some custom hardware. I'm using mik3y's usb-serial-for-android library to get the serial data over USB in OTG mode, which after some tweaks is working fine.
However, for every transaction over the USB interface, UsbRequestJNI is logging an init and close message. This is swamping LogCat with thousands of log messages per second (note the timestamps):
02-17 09:30:21.590 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.590 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.594 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.594 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.598 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.598 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.602 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.602 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.606 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.606 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.610 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.610 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
02-17 09:30:21.614 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ close
02-17 09:30:21.614 2332-2349/com.dummydomain.app D/UsbRequestJNI﹕ init
I know I can filter these in the IDE, but I want to stop them so they're not chewing through debugger bandwidth.
From what I can gather, UsbRequestJNI is an operating-system-provided JNI library, so I can't just edit the source. So how can I tell it to stop logging these debug messages while still running a debug build so I can see other relevant debug info?
Googling around has produced only this, which is basically the same problem but with no resolution that's applicable here.
(My development device is running Android 4.3 and I'm developing on Android Studio 1.0.1)
UPDATE: Just found the source for UsbRequest, the relevant lines being ALOGD statments (lines 45 and 71). So I guess the question becomes: how do I suppress ALOGD messages?
UPDATE 2: I've tried setprop log.tag.UsbRequestJNI SUPPRESS as per this answer, but frustratingly it has no effect on my device.
java
android usbserial android-usb java
android usbserial android-usb edited May 23 '17 at 12:24
Community♦
11
asked Feb 17 '15 at 10:05
davidf2281davidf2281
1,1651019
edited May 23 '17 at 12:24
Community♦
11
asked Feb 17 '15 at 10:05
davidf2281davidf2281
1,1651019
edited May 23 '17 at 12:24
Community♦
11
edited May 23 '17 at 12:24
Community♦
11
edited May 23 '17 at 12:24
Community♦
11
11
asked Feb 17 '15 at 10:05
davidf2281davidf2281
1,1651019
asked Feb 17 '15 at 10:05
davidf2281davidf2281
1,1651019
asked Feb 17 '15 at 10:05
davidf2281davidf2281
1,1651019
1,1651019
1
After looking at your links, I began to suspect that you could likely solve this be re-using the USB requests. Further searching found a mention of doing exactly that for exactly this reason in the changelog of the phidgets driver. So if you want to pursue figuring out how to do that it seems like it has been done before and allegedly works.
– Chris Stratton
Feb 21 '15 at 5:52
Thanks for the comment @chris. In the event, it seems that in addition to the over-logging problem, the drivers (at least on my particular hardware) are just too buggy and unreliable so I've switched from Android to standard PC hardware instead. Thanks though!
– davidf2281
Feb 23 '15 at 13:55
add a comment |
1
After looking at your links, I began to suspect that you could likely solve this be re-using the USB requests. Further searching found a mention of doing exactly that for exactly this reason in the changelog of the phidgets driver. So if you want to pursue figuring out how to do that it seems like it has been done before and allegedly works.
– Chris Stratton
Feb 21 '15 at 5:52
Thanks for the comment @chris. In the event, it seems that in addition to the over-logging problem, the drivers (at least on my particular hardware) are just too buggy and unreliable so I've switched from Android to standard PC hardware instead. Thanks though!
– davidf2281
Feb 23 '15 at 13:55
1
1
After looking at your links, I began to suspect that you could likely solve this be re-using the USB requests. Further searching found a mention of doing exactly that for exactly this reason in the changelog of the phidgets driver. So if you want to pursue figuring out how to do that it seems like it has been done before and allegedly works.
– Chris Stratton
Feb 21 '15 at 5:52
After looking at your links, I began to suspect that you could likely solve this be re-using the USB requests. Further searching found a mention of doing exactly that for exactly this reason in the changelog of the phidgets driver. So if you want to pursue figuring out how to do that it seems like it has been done before and allegedly works.
– Chris Stratton
Feb 21 '15 at 5:52
Thanks for the comment @chris. In the event, it seems that in addition to the over-logging problem, the drivers (at least on my particular hardware) are just too buggy and unreliable so I've switched from Android to standard PC hardware instead. Thanks though!
– davidf2281
Feb 23 '15 at 13:55
Thanks for the comment @chris. In the event, it seems that in addition to the over-logging problem, the drivers (at least on my particular hardware) are just too buggy and unreliable so I've switched from Android to standard PC hardware instead. Thanks though!
– davidf2281
Feb 23 '15 at 13:55
add a comment |
2 Answers
2
active
oldest
votes
Just hit this myself with mik3y's usb-serial-for-android package. I was able to workaround it by disabling async reads. Change this line:
mEnableAsyncReads = (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR1);
to read:
mEnableAsyncReads = false;
At this time there are a number of open pull requests against mik3y's code, perhaps these have been fixed in a fork? See https://github.com/mik3y/usb-serial-for-android/network
answered Aug 29 '16 at 6:46
moof2kmoof2k
758513
This worked fine, though I wonder if there are any other issues (performance wise) with using this method. +1 Thanks!
– Behr
Jan 25 '17 at 16:38
add a comment |
For posterity these messages seem to come from UsbRequest initialize() and close() methods so by reusing UsbRequest objects instead of creating new object mostly solves this issue and probably also marginally improve performance.
answered Mar 7 at 12:58
nyholkunyholku
151112
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f28559394%2fsuppress-usbrequestjni-alogd-log-messages%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Just hit this myself with mik3y's usb-serial-for-android package. I was able to workaround it by disabling async reads. Change this line:
mEnableAsyncReads = (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR1);
to read:
mEnableAsyncReads = false;
At this time there are a number of open pull requests against mik3y's code, perhaps these have been fixed in a fork? See https://github.com/mik3y/usb-serial-for-android/network
answered Aug 29 '16 at 6:46
moof2kmoof2k
758513
This worked fine, though I wonder if there are any other issues (performance wise) with using this method. +1 Thanks!
– Behr
Jan 25 '17 at 16:38
add a comment |
Just hit this myself with mik3y's usb-serial-for-android package. I was able to workaround it by disabling async reads. Change this line:
mEnableAsyncReads = (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR1);
to read:
mEnableAsyncReads = false;
At this time there are a number of open pull requests against mik3y's code, perhaps these have been fixed in a fork? See https://github.com/mik3y/usb-serial-for-android/network
answered Aug 29 '16 at 6:46
moof2kmoof2k
758513
This worked fine, though I wonder if there are any other issues (performance wise) with using this method. +1 Thanks!
– Behr
Jan 25 '17 at 16:38
add a comment |
Just hit this myself with mik3y's usb-serial-for-android package. I was able to workaround it by disabling async reads. Change this line:
mEnableAsyncReads = (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR1);
to read:
mEnableAsyncReads = false;
At this time there are a number of open pull requests against mik3y's code, perhaps these have been fixed in a fork? See https://github.com/mik3y/usb-serial-for-android/network
answered Aug 29 '16 at 6:46
moof2kmoof2k
758513
Just hit this myself with mik3y's usb-serial-for-android package. I was able to workaround it by disabling async reads. Change this line:
mEnableAsyncReads = (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR1);
to read:
mEnableAsyncReads = false;
At this time there are a number of open pull requests against mik3y's code, perhaps these have been fixed in a fork? See https://github.com/mik3y/usb-serial-for-android/network
answered Aug 29 '16 at 6:46
moof2kmoof2k
758513
answered Aug 29 '16 at 6:46
moof2kmoof2k
758513
answered Aug 29 '16 at 6:46
moof2kmoof2k
758513
answered Aug 29 '16 at 6:46
moof2kmoof2k
758513
758513
This worked fine, though I wonder if there are any other issues (performance wise) with using this method. +1 Thanks!
– Behr
Jan 25 '17 at 16:38
add a comment |
This worked fine, though I wonder if there are any other issues (performance wise) with using this method. +1 Thanks!
– Behr
Jan 25 '17 at 16:38
This worked fine, though I wonder if there are any other issues (performance wise) with using this method. +1 Thanks!
– Behr
Jan 25 '17 at 16:38
This worked fine, though I wonder if there are any other issues (performance wise) with using this method. +1 Thanks!
– Behr
Jan 25 '17 at 16:38
add a comment |
For posterity these messages seem to come from UsbRequest initialize() and close() methods so by reusing UsbRequest objects instead of creating new object mostly solves this issue and probably also marginally improve performance.
answered Mar 7 at 12:58
nyholkunyholku
151112
add a comment |
For posterity these messages seem to come from UsbRequest initialize() and close() methods so by reusing UsbRequest objects instead of creating new object mostly solves this issue and probably also marginally improve performance.
answered Mar 7 at 12:58
nyholkunyholku
151112
add a comment |
For posterity these messages seem to come from UsbRequest initialize() and close() methods so by reusing UsbRequest objects instead of creating new object mostly solves this issue and probably also marginally improve performance.
answered Mar 7 at 12:58
nyholkunyholku
151112
For posterity these messages seem to come from UsbRequest initialize() and close() methods so by reusing UsbRequest objects instead of creating new object mostly solves this issue and probably also marginally improve performance.
answered Mar 7 at 12:58
nyholkunyholku
151112
answered Mar 7 at 12:58
nyholkunyholku
151112
answered Mar 7 at 12:58
nyholkunyholku
151112
answered Mar 7 at 12:58
nyholkunyholku
151112
151112
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f28559394%2fsuppress-usbrequestjni-alogd-log-messages%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
After looking at your links, I began to suspect that you could likely solve this be re-using the USB requests. Further searching found a mention of doing exactly that for exactly this reason in the changelog of the phidgets driver. So if you want to pursue figuring out how to do that it seems like it has been done before and allegedly works.
– Chris Stratton
Feb 21 '15 at 5:52
Thanks for the comment @chris. In the event, it seems that in addition to the over-logging problem, the drivers (at least on my particular hardware) are just too buggy and unreliable so I've switched from Android to standard PC hardware instead. Thanks though!
– davidf2281
Feb 23 '15 at 13:55