Can a USB port passively 'listen only'?Connect to Arduino Mega serial interface by C codeIs my SparkFun RS232 Shifter SMD faulty?Firmware & Circuit of ATtiny45 direct USB 2.0 ConnectionChaining Multiple USB Hub Controllers for Serial InterfacingATMEGA328P send MIDI via USB10Mbs USB to serial communicationμC <-> USB <-> μC advice please!Serial Over USB Reading With GNU Octave ProblemsHow can I convert from 12v serial to 5v serial?

Anonymous reviewer disclosed his identity. Should I thank him by name?

SHA3-255, one bit less

My second game: War Card game V.1

Does it require less energy to reach the Sun from Pluto's orbit than from Earth's orbit?

As an interviewer, how to conduct interviews with candidates you already know will be rejected?

Non-electric Laser

Could quantum computing help resolve some computability problems like p vs np or the halting problem?

Determine the Winner of a Game of Australian Football

Maintaining distance

Can 35 mm film which went through a washing machine still be developed?

Use floats or doubles when writing mobile games

Is Zhent just the term for any member of the Zhentarim?

How come the Russian cognate for the Czech word "čerstvý" (fresh) means entirely the opposite thing (stale)?

Coffee Grounds and Gritty Butter Cream Icing

Search for something difficult to count/estimate

What benefits are there to blocking most search engines?

Would we have more than 8 minutes of light, if the sun "went out"?

How fast are we moving relative to the CMB?

The work of mathematicians outside their professional environment

Are there any tricks to pushing a grand piano?

Using the Grappler feat, can you grapple and pin (restrain) in the same action?

What kind of nut is this

Network dynamic failover does not work if IP address differs between ethernet and wifi

Should I be able to see patterns in a HS256 encoded JWT?



Can a USB port passively 'listen only'?


Connect to Arduino Mega serial interface by C codeIs my SparkFun RS232 Shifter SMD faulty?Firmware & Circuit of ATtiny45 direct USB 2.0 ConnectionChaining Multiple USB Hub Controllers for Serial InterfacingATMEGA328P send MIDI via USB10Mbs USB to serial communicationμC <-> USB <-> μC advice please!Serial Over USB Reading With GNU Octave ProblemsHow can I convert from 12v serial to 5v serial?






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty
margin-bottom:0;









6












$begingroup$


I have a small dedicated controller built around an Arduino that accepts commands from a PC over USB (serial). The communication is one-way -- the controller never sends data back to the PC.



Now I need to extend the controller to handle more duties, but there's no room physically or program-wise, so I'm adding a second box with another Arduino that will accept the extended commands.



I can't alter the controlling PC application or add another USB port to the PC. The application controls the hardware and is in turn driven by a script. It can only talk to one serial port (physical or virtual) at a time. We can alter the script but not the hardware/application. So my hope is that I can just bridge across the D+/- lines to feed the second controller.



If this were straight serial I'd have no problem, but with USB in the middle I see issues ahead, because the PC will want to enumerate both Arduino USBs, right?



Is there a solution here I'm overlooking? Can I use USB passively, as a listener only, with the second controller?










share|improve this question











$endgroup$









  • 6




    $begingroup$
    In that case how about bridging the serial lines themselves between the arduinos? Or getting one to forward unknown commands to the other? Or buying one with more program space?
    $endgroup$
    – pjc50
    Apr 16 at 16:48










  • $begingroup$
    @pjc50 - Bridging the serial lines was my second choice, primarily because layout issues in the current display make that awkward. But it's becoming obvious that it might be the only solution. Program space is only part of the issue -- physical space matters more.
    $endgroup$
    – Jim Mack
    Apr 16 at 16:52










  • $begingroup$
    use thin wires. a USB cable and a single thin wire take about as much space as a usb cable alone, the other arduino needs 5V, ground, and the single thin wire which takes less space than a USB cable.
    $endgroup$
    – Jasen
    Apr 17 at 3:58










  • $begingroup$
    Is inserting an USB-Serial converter between the PC and the device possible? It won't need an additional USB port. Just interrupt the cable and put such a converter in-between. If that's allowed, there are alternative solutions I can describe in a proper answer.
    $endgroup$
    – vsz
    Apr 18 at 4:33










  • $begingroup$
    @vsz - I'd be interested to hear what you propose, as long as it doesn't involve a second virtual serial port on the PC. Any scheme that adds a USB device seems to run afoul of this. I'm committed to combining Rx lines at this point, but I'm curious to hear your idea, as others might benefit.
    $endgroup$
    – Jim Mack
    Apr 18 at 11:38

















6












$begingroup$


I have a small dedicated controller built around an Arduino that accepts commands from a PC over USB (serial). The communication is one-way -- the controller never sends data back to the PC.



Now I need to extend the controller to handle more duties, but there's no room physically or program-wise, so I'm adding a second box with another Arduino that will accept the extended commands.



I can't alter the controlling PC application or add another USB port to the PC. The application controls the hardware and is in turn driven by a script. It can only talk to one serial port (physical or virtual) at a time. We can alter the script but not the hardware/application. So my hope is that I can just bridge across the D+/- lines to feed the second controller.



If this were straight serial I'd have no problem, but with USB in the middle I see issues ahead, because the PC will want to enumerate both Arduino USBs, right?



Is there a solution here I'm overlooking? Can I use USB passively, as a listener only, with the second controller?










share|improve this question











$endgroup$









  • 6




    $begingroup$
    In that case how about bridging the serial lines themselves between the arduinos? Or getting one to forward unknown commands to the other? Or buying one with more program space?
    $endgroup$
    – pjc50
    Apr 16 at 16:48










  • $begingroup$
    @pjc50 - Bridging the serial lines was my second choice, primarily because layout issues in the current display make that awkward. But it's becoming obvious that it might be the only solution. Program space is only part of the issue -- physical space matters more.
    $endgroup$
    – Jim Mack
    Apr 16 at 16:52










  • $begingroup$
    use thin wires. a USB cable and a single thin wire take about as much space as a usb cable alone, the other arduino needs 5V, ground, and the single thin wire which takes less space than a USB cable.
    $endgroup$
    – Jasen
    Apr 17 at 3:58










  • $begingroup$
    Is inserting an USB-Serial converter between the PC and the device possible? It won't need an additional USB port. Just interrupt the cable and put such a converter in-between. If that's allowed, there are alternative solutions I can describe in a proper answer.
    $endgroup$
    – vsz
    Apr 18 at 4:33










  • $begingroup$
    @vsz - I'd be interested to hear what you propose, as long as it doesn't involve a second virtual serial port on the PC. Any scheme that adds a USB device seems to run afoul of this. I'm committed to combining Rx lines at this point, but I'm curious to hear your idea, as others might benefit.
    $endgroup$
    – Jim Mack
    Apr 18 at 11:38













6












6








6


2



$begingroup$


I have a small dedicated controller built around an Arduino that accepts commands from a PC over USB (serial). The communication is one-way -- the controller never sends data back to the PC.



Now I need to extend the controller to handle more duties, but there's no room physically or program-wise, so I'm adding a second box with another Arduino that will accept the extended commands.



I can't alter the controlling PC application or add another USB port to the PC. The application controls the hardware and is in turn driven by a script. It can only talk to one serial port (physical or virtual) at a time. We can alter the script but not the hardware/application. So my hope is that I can just bridge across the D+/- lines to feed the second controller.



If this were straight serial I'd have no problem, but with USB in the middle I see issues ahead, because the PC will want to enumerate both Arduino USBs, right?



Is there a solution here I'm overlooking? Can I use USB passively, as a listener only, with the second controller?










share|improve this question











$endgroup$




I have a small dedicated controller built around an Arduino that accepts commands from a PC over USB (serial). The communication is one-way -- the controller never sends data back to the PC.



Now I need to extend the controller to handle more duties, but there's no room physically or program-wise, so I'm adding a second box with another Arduino that will accept the extended commands.



I can't alter the controlling PC application or add another USB port to the PC. The application controls the hardware and is in turn driven by a script. It can only talk to one serial port (physical or virtual) at a time. We can alter the script but not the hardware/application. So my hope is that I can just bridge across the D+/- lines to feed the second controller.



If this were straight serial I'd have no problem, but with USB in the middle I see issues ahead, because the PC will want to enumerate both Arduino USBs, right?



Is there a solution here I'm overlooking? Can I use USB passively, as a listener only, with the second controller?







usb serial arduino-uno






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 16 at 17:55









Dave Tweed

137k11 gold badges175 silver badges300 bronze badges




137k11 gold badges175 silver badges300 bronze badges










asked Apr 16 at 16:29









Jim MackJim Mack

1365 bronze badges




1365 bronze badges










  • 6




    $begingroup$
    In that case how about bridging the serial lines themselves between the arduinos? Or getting one to forward unknown commands to the other? Or buying one with more program space?
    $endgroup$
    – pjc50
    Apr 16 at 16:48










  • $begingroup$
    @pjc50 - Bridging the serial lines was my second choice, primarily because layout issues in the current display make that awkward. But it's becoming obvious that it might be the only solution. Program space is only part of the issue -- physical space matters more.
    $endgroup$
    – Jim Mack
    Apr 16 at 16:52










  • $begingroup$
    use thin wires. a USB cable and a single thin wire take about as much space as a usb cable alone, the other arduino needs 5V, ground, and the single thin wire which takes less space than a USB cable.
    $endgroup$
    – Jasen
    Apr 17 at 3:58










  • $begingroup$
    Is inserting an USB-Serial converter between the PC and the device possible? It won't need an additional USB port. Just interrupt the cable and put such a converter in-between. If that's allowed, there are alternative solutions I can describe in a proper answer.
    $endgroup$
    – vsz
    Apr 18 at 4:33










  • $begingroup$
    @vsz - I'd be interested to hear what you propose, as long as it doesn't involve a second virtual serial port on the PC. Any scheme that adds a USB device seems to run afoul of this. I'm committed to combining Rx lines at this point, but I'm curious to hear your idea, as others might benefit.
    $endgroup$
    – Jim Mack
    Apr 18 at 11:38












  • 6




    $begingroup$
    In that case how about bridging the serial lines themselves between the arduinos? Or getting one to forward unknown commands to the other? Or buying one with more program space?
    $endgroup$
    – pjc50
    Apr 16 at 16:48










  • $begingroup$
    @pjc50 - Bridging the serial lines was my second choice, primarily because layout issues in the current display make that awkward. But it's becoming obvious that it might be the only solution. Program space is only part of the issue -- physical space matters more.
    $endgroup$
    – Jim Mack
    Apr 16 at 16:52










  • $begingroup$
    use thin wires. a USB cable and a single thin wire take about as much space as a usb cable alone, the other arduino needs 5V, ground, and the single thin wire which takes less space than a USB cable.
    $endgroup$
    – Jasen
    Apr 17 at 3:58










  • $begingroup$
    Is inserting an USB-Serial converter between the PC and the device possible? It won't need an additional USB port. Just interrupt the cable and put such a converter in-between. If that's allowed, there are alternative solutions I can describe in a proper answer.
    $endgroup$
    – vsz
    Apr 18 at 4:33










  • $begingroup$
    @vsz - I'd be interested to hear what you propose, as long as it doesn't involve a second virtual serial port on the PC. Any scheme that adds a USB device seems to run afoul of this. I'm committed to combining Rx lines at this point, but I'm curious to hear your idea, as others might benefit.
    $endgroup$
    – Jim Mack
    Apr 18 at 11:38







6




6




$begingroup$
In that case how about bridging the serial lines themselves between the arduinos? Or getting one to forward unknown commands to the other? Or buying one with more program space?
$endgroup$
– pjc50
Apr 16 at 16:48




$begingroup$
In that case how about bridging the serial lines themselves between the arduinos? Or getting one to forward unknown commands to the other? Or buying one with more program space?
$endgroup$
– pjc50
Apr 16 at 16:48












$begingroup$
@pjc50 - Bridging the serial lines was my second choice, primarily because layout issues in the current display make that awkward. But it's becoming obvious that it might be the only solution. Program space is only part of the issue -- physical space matters more.
$endgroup$
– Jim Mack
Apr 16 at 16:52




$begingroup$
@pjc50 - Bridging the serial lines was my second choice, primarily because layout issues in the current display make that awkward. But it's becoming obvious that it might be the only solution. Program space is only part of the issue -- physical space matters more.
$endgroup$
– Jim Mack
Apr 16 at 16:52












$begingroup$
use thin wires. a USB cable and a single thin wire take about as much space as a usb cable alone, the other arduino needs 5V, ground, and the single thin wire which takes less space than a USB cable.
$endgroup$
– Jasen
Apr 17 at 3:58




$begingroup$
use thin wires. a USB cable and a single thin wire take about as much space as a usb cable alone, the other arduino needs 5V, ground, and the single thin wire which takes less space than a USB cable.
$endgroup$
– Jasen
Apr 17 at 3:58












$begingroup$
Is inserting an USB-Serial converter between the PC and the device possible? It won't need an additional USB port. Just interrupt the cable and put such a converter in-between. If that's allowed, there are alternative solutions I can describe in a proper answer.
$endgroup$
– vsz
Apr 18 at 4:33




$begingroup$
Is inserting an USB-Serial converter between the PC and the device possible? It won't need an additional USB port. Just interrupt the cable and put such a converter in-between. If that's allowed, there are alternative solutions I can describe in a proper answer.
$endgroup$
– vsz
Apr 18 at 4:33












$begingroup$
@vsz - I'd be interested to hear what you propose, as long as it doesn't involve a second virtual serial port on the PC. Any scheme that adds a USB device seems to run afoul of this. I'm committed to combining Rx lines at this point, but I'm curious to hear your idea, as others might benefit.
$endgroup$
– Jim Mack
Apr 18 at 11:38




$begingroup$
@vsz - I'd be interested to hear what you propose, as long as it doesn't involve a second virtual serial port on the PC. Any scheme that adds a USB device seems to run afoul of this. I'm committed to combining Rx lines at this point, but I'm curious to hear your idea, as others might benefit.
$endgroup$
– Jim Mack
Apr 18 at 11:38










4 Answers
4






active

oldest

votes


















12














$begingroup$

USB CDC serial is quite a complicated protocol. Even if you are only sending serial commands one way, there is USB traffic going backwards and forwards all the time. Even when the virtual serial bus is quiet, the usb host is continuously asking the usb device "do you have anything to send" and the device says "no".



Consider sending the phrase "hi" to an arduino, and getting "hello" back. On the USB bus, it will look something like this:



Host: Do you have a message?
Device: No.
Host: I have a message for you
Device: OK
Host: hin
Device: OK
Host: Do you have a message?
Device: No.
Host: Do you have a message?
Device: hel
Host: Do you have a message?
Device: llon
Host: Do you have a message?
Device: No.

etc. etc.



These messages will also be mingled in with messages sent to other devices on the same hub (even if you don't have a USB hub in the system, there may well be one inside the computer. So you could easily see messages to your mouse and keyboard mixed in).



The USB protocol is extremely complicated, so splitting it in the way you mention is not going to be practical. You can "sniff" it though. If you connect the D+ and D- lines, it is possible to see the traffic on the bus. As long as the sniffer doesn't try to manipulate the D+/D- lines, the USB bus will keep working. The sniffer would then need to identify which messages were relevant and decode them. Building a sniffer out of an arduino would be difficult but probably not impossible. It almost certainly isn't the best solution for your problem.






share|improve this answer











$endgroup$










  • 4




    $begingroup$
    Actually building a sniffer out of an Arduino would be impossible in this case. The ATmega programmatic USB hacks are USB low speed and rely on part of the USB spec not being literally enforced to work. But the existing USB CDC implementation will be USB full speed, and so too fast to sniff this way. Possibly at the extreme of loading a custom firmware on the existing 16u2 (if the existing Arduino is a true Uno) one could make that operate in semi-compliant low speed mode and thus be sniffable, but your last statement is the key one: "isn't the best solution for your problem."
    $endgroup$
    – Chris Stratton
    Apr 16 at 17:34










  • $begingroup$
    Thanks for the tutorial. It's been made abundantly clear that there's no way a simple bridging could work, so I'm off to plan B.
    $endgroup$
    – Jim Mack
    Apr 16 at 17:38






  • 1




    $begingroup$
    @ChrisStratton I was thinking of seriously abusing the USB hardware on a Leonardo. I never use the ones with a separate 16U2 as a usb/serial converter, and had kinda forgotten that most of them were like that. I believe it would be possible to bring up the USB hardware on a 32U4 in such a way that it didn't manipulate the bus but still listened. Didn't look at the datasheet to check though.
    $endgroup$
    – Jack B
    Apr 16 at 17:52










  • $begingroup$
    @JimMack Glad it was helpful.
    $endgroup$
    – Jack B
    Apr 16 at 17:56






  • 1




    $begingroup$
    @JackB - no, that would not work. To sniff, you would need something where you can get your fingers in the fine grained USB function implementation, not a fixed function peripheral block. And realistically at that point you'd be better off grabbing a dual-USB STM32F4 and making something that grabbed whatever it wanted and passed the rest of the virtual serial payload stream through to the Arduino hanging off its OTG port. But then you take a step back and realize you should just replace the Arduino with something that does everything OP needs, or add software to talk to a second device.
    $endgroup$
    – Chris Stratton
    Apr 16 at 18:02


















4














$begingroup$

No you can't split USB, but what prevents you from connecting the UART receive pins of two Arduinos together so both receive same UART data, or making the first Arduino to send commands it does not understand to the other Arduino?






share|improve this answer









$endgroup$














  • $begingroup$
    Both are possible and I'll likely bridge the Rx lines in the end, but was hoping for a simple solution that doesn't require any modification to the existing controller.
    $endgroup$
    – Jim Mack
    Apr 16 at 16:56


















2














$begingroup$


Can I use USB passively, as a listener only, with the second
controller?




Technically yes, you can build a device that is passively looking at USB traffic and be able to get information from it and take any actions. In fact, devices like that do exist. They are called "USB Protocol Analyzers".



Typical architecture of such devices consists of an non-invasive sniffer on D+/D- lines (high-impedance voltage divider plus gain compensating wideband amplifier), which feed a standard (stand-alone) USB PHY. The serial-parallel output interface from the PHY (ULPI or UTMI or PIPE3) is then watched/logged by a sizeable FPGA that has decoding tools and can trigger off USB protocol events. Examples: Teledyne-LeCroy, Ellisys.



enter image description hereenter image description here



So you can watch USB traffic and get data. To get them in real time you will need to program FPGA and run it at sufficient clock rate to implement most elements of USB Serial Interface Engine (except forming ACK/NAK replies).






share|improve this answer









$endgroup$






















    1














    $begingroup$

    One solution could be to essentially implement a daisy-chained local serial topology of Arduinos. One of these at the 'front' of the chain would expose its USB CDC interface. Then you'd wire a pair of pins configured for SoftwareSerial to the next Arduino's Serial pins (D0/D1) and so forth. Then you could echo the serial traffic received up and down the chain as necessary, with every member of the chain deciding whether it should respond as appropriate.






    share|improve this answer











    $endgroup$














    • $begingroup$
      Just read the comments, and what I propose here is pretty similar to what @pjc50 was getting at.
      $endgroup$
      – vicatcu
      Apr 16 at 21:55










    • $begingroup$
      Thanks, I've decided the only practical method is to tie the two Rx lines together. It means physically modifying the original controller, but that appears unavoidable.
      $endgroup$
      – Jim Mack
      Apr 17 at 0:56












    Your Answer






    StackExchange.ifUsing("editor", function ()
    return StackExchange.using("schematics", function ()
    StackExchange.schematics.init();
    );
    , "cicuitlab");

    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "135"
    ;
    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: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    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/4.0/"u003ecc by-sa 4.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
    );



    );














    draft saved

    draft discarded
















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f432888%2fcan-a-usb-port-passively-listen-only%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    4 Answers
    4






    active

    oldest

    votes








    4 Answers
    4






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    12














    $begingroup$

    USB CDC serial is quite a complicated protocol. Even if you are only sending serial commands one way, there is USB traffic going backwards and forwards all the time. Even when the virtual serial bus is quiet, the usb host is continuously asking the usb device "do you have anything to send" and the device says "no".



    Consider sending the phrase "hi" to an arduino, and getting "hello" back. On the USB bus, it will look something like this:



    Host: Do you have a message?
    Device: No.
    Host: I have a message for you
    Device: OK
    Host: hin
    Device: OK
    Host: Do you have a message?
    Device: No.
    Host: Do you have a message?
    Device: hel
    Host: Do you have a message?
    Device: llon
    Host: Do you have a message?
    Device: No.

    etc. etc.



    These messages will also be mingled in with messages sent to other devices on the same hub (even if you don't have a USB hub in the system, there may well be one inside the computer. So you could easily see messages to your mouse and keyboard mixed in).



    The USB protocol is extremely complicated, so splitting it in the way you mention is not going to be practical. You can "sniff" it though. If you connect the D+ and D- lines, it is possible to see the traffic on the bus. As long as the sniffer doesn't try to manipulate the D+/D- lines, the USB bus will keep working. The sniffer would then need to identify which messages were relevant and decode them. Building a sniffer out of an arduino would be difficult but probably not impossible. It almost certainly isn't the best solution for your problem.






    share|improve this answer











    $endgroup$










    • 4




      $begingroup$
      Actually building a sniffer out of an Arduino would be impossible in this case. The ATmega programmatic USB hacks are USB low speed and rely on part of the USB spec not being literally enforced to work. But the existing USB CDC implementation will be USB full speed, and so too fast to sniff this way. Possibly at the extreme of loading a custom firmware on the existing 16u2 (if the existing Arduino is a true Uno) one could make that operate in semi-compliant low speed mode and thus be sniffable, but your last statement is the key one: "isn't the best solution for your problem."
      $endgroup$
      – Chris Stratton
      Apr 16 at 17:34










    • $begingroup$
      Thanks for the tutorial. It's been made abundantly clear that there's no way a simple bridging could work, so I'm off to plan B.
      $endgroup$
      – Jim Mack
      Apr 16 at 17:38






    • 1




      $begingroup$
      @ChrisStratton I was thinking of seriously abusing the USB hardware on a Leonardo. I never use the ones with a separate 16U2 as a usb/serial converter, and had kinda forgotten that most of them were like that. I believe it would be possible to bring up the USB hardware on a 32U4 in such a way that it didn't manipulate the bus but still listened. Didn't look at the datasheet to check though.
      $endgroup$
      – Jack B
      Apr 16 at 17:52










    • $begingroup$
      @JimMack Glad it was helpful.
      $endgroup$
      – Jack B
      Apr 16 at 17:56






    • 1




      $begingroup$
      @JackB - no, that would not work. To sniff, you would need something where you can get your fingers in the fine grained USB function implementation, not a fixed function peripheral block. And realistically at that point you'd be better off grabbing a dual-USB STM32F4 and making something that grabbed whatever it wanted and passed the rest of the virtual serial payload stream through to the Arduino hanging off its OTG port. But then you take a step back and realize you should just replace the Arduino with something that does everything OP needs, or add software to talk to a second device.
      $endgroup$
      – Chris Stratton
      Apr 16 at 18:02















    12














    $begingroup$

    USB CDC serial is quite a complicated protocol. Even if you are only sending serial commands one way, there is USB traffic going backwards and forwards all the time. Even when the virtual serial bus is quiet, the usb host is continuously asking the usb device "do you have anything to send" and the device says "no".



    Consider sending the phrase "hi" to an arduino, and getting "hello" back. On the USB bus, it will look something like this:



    Host: Do you have a message?
    Device: No.
    Host: I have a message for you
    Device: OK
    Host: hin
    Device: OK
    Host: Do you have a message?
    Device: No.
    Host: Do you have a message?
    Device: hel
    Host: Do you have a message?
    Device: llon
    Host: Do you have a message?
    Device: No.

    etc. etc.



    These messages will also be mingled in with messages sent to other devices on the same hub (even if you don't have a USB hub in the system, there may well be one inside the computer. So you could easily see messages to your mouse and keyboard mixed in).



    The USB protocol is extremely complicated, so splitting it in the way you mention is not going to be practical. You can "sniff" it though. If you connect the D+ and D- lines, it is possible to see the traffic on the bus. As long as the sniffer doesn't try to manipulate the D+/D- lines, the USB bus will keep working. The sniffer would then need to identify which messages were relevant and decode them. Building a sniffer out of an arduino would be difficult but probably not impossible. It almost certainly isn't the best solution for your problem.






    share|improve this answer











    $endgroup$










    • 4




      $begingroup$
      Actually building a sniffer out of an Arduino would be impossible in this case. The ATmega programmatic USB hacks are USB low speed and rely on part of the USB spec not being literally enforced to work. But the existing USB CDC implementation will be USB full speed, and so too fast to sniff this way. Possibly at the extreme of loading a custom firmware on the existing 16u2 (if the existing Arduino is a true Uno) one could make that operate in semi-compliant low speed mode and thus be sniffable, but your last statement is the key one: "isn't the best solution for your problem."
      $endgroup$
      – Chris Stratton
      Apr 16 at 17:34










    • $begingroup$
      Thanks for the tutorial. It's been made abundantly clear that there's no way a simple bridging could work, so I'm off to plan B.
      $endgroup$
      – Jim Mack
      Apr 16 at 17:38






    • 1




      $begingroup$
      @ChrisStratton I was thinking of seriously abusing the USB hardware on a Leonardo. I never use the ones with a separate 16U2 as a usb/serial converter, and had kinda forgotten that most of them were like that. I believe it would be possible to bring up the USB hardware on a 32U4 in such a way that it didn't manipulate the bus but still listened. Didn't look at the datasheet to check though.
      $endgroup$
      – Jack B
      Apr 16 at 17:52










    • $begingroup$
      @JimMack Glad it was helpful.
      $endgroup$
      – Jack B
      Apr 16 at 17:56






    • 1




      $begingroup$
      @JackB - no, that would not work. To sniff, you would need something where you can get your fingers in the fine grained USB function implementation, not a fixed function peripheral block. And realistically at that point you'd be better off grabbing a dual-USB STM32F4 and making something that grabbed whatever it wanted and passed the rest of the virtual serial payload stream through to the Arduino hanging off its OTG port. But then you take a step back and realize you should just replace the Arduino with something that does everything OP needs, or add software to talk to a second device.
      $endgroup$
      – Chris Stratton
      Apr 16 at 18:02













    12














    12










    12







    $begingroup$

    USB CDC serial is quite a complicated protocol. Even if you are only sending serial commands one way, there is USB traffic going backwards and forwards all the time. Even when the virtual serial bus is quiet, the usb host is continuously asking the usb device "do you have anything to send" and the device says "no".



    Consider sending the phrase "hi" to an arduino, and getting "hello" back. On the USB bus, it will look something like this:



    Host: Do you have a message?
    Device: No.
    Host: I have a message for you
    Device: OK
    Host: hin
    Device: OK
    Host: Do you have a message?
    Device: No.
    Host: Do you have a message?
    Device: hel
    Host: Do you have a message?
    Device: llon
    Host: Do you have a message?
    Device: No.

    etc. etc.



    These messages will also be mingled in with messages sent to other devices on the same hub (even if you don't have a USB hub in the system, there may well be one inside the computer. So you could easily see messages to your mouse and keyboard mixed in).



    The USB protocol is extremely complicated, so splitting it in the way you mention is not going to be practical. You can "sniff" it though. If you connect the D+ and D- lines, it is possible to see the traffic on the bus. As long as the sniffer doesn't try to manipulate the D+/D- lines, the USB bus will keep working. The sniffer would then need to identify which messages were relevant and decode them. Building a sniffer out of an arduino would be difficult but probably not impossible. It almost certainly isn't the best solution for your problem.






    share|improve this answer











    $endgroup$



    USB CDC serial is quite a complicated protocol. Even if you are only sending serial commands one way, there is USB traffic going backwards and forwards all the time. Even when the virtual serial bus is quiet, the usb host is continuously asking the usb device "do you have anything to send" and the device says "no".



    Consider sending the phrase "hi" to an arduino, and getting "hello" back. On the USB bus, it will look something like this:



    Host: Do you have a message?
    Device: No.
    Host: I have a message for you
    Device: OK
    Host: hin
    Device: OK
    Host: Do you have a message?
    Device: No.
    Host: Do you have a message?
    Device: hel
    Host: Do you have a message?
    Device: llon
    Host: Do you have a message?
    Device: No.

    etc. etc.



    These messages will also be mingled in with messages sent to other devices on the same hub (even if you don't have a USB hub in the system, there may well be one inside the computer. So you could easily see messages to your mouse and keyboard mixed in).



    The USB protocol is extremely complicated, so splitting it in the way you mention is not going to be practical. You can "sniff" it though. If you connect the D+ and D- lines, it is possible to see the traffic on the bus. As long as the sniffer doesn't try to manipulate the D+/D- lines, the USB bus will keep working. The sniffer would then need to identify which messages were relevant and decode them. Building a sniffer out of an arduino would be difficult but probably not impossible. It almost certainly isn't the best solution for your problem.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Apr 16 at 19:14

























    answered Apr 16 at 17:30









    Jack BJack B

    10.5k1 gold badge22 silver badges38 bronze badges




    10.5k1 gold badge22 silver badges38 bronze badges










    • 4




      $begingroup$
      Actually building a sniffer out of an Arduino would be impossible in this case. The ATmega programmatic USB hacks are USB low speed and rely on part of the USB spec not being literally enforced to work. But the existing USB CDC implementation will be USB full speed, and so too fast to sniff this way. Possibly at the extreme of loading a custom firmware on the existing 16u2 (if the existing Arduino is a true Uno) one could make that operate in semi-compliant low speed mode and thus be sniffable, but your last statement is the key one: "isn't the best solution for your problem."
      $endgroup$
      – Chris Stratton
      Apr 16 at 17:34










    • $begingroup$
      Thanks for the tutorial. It's been made abundantly clear that there's no way a simple bridging could work, so I'm off to plan B.
      $endgroup$
      – Jim Mack
      Apr 16 at 17:38






    • 1




      $begingroup$
      @ChrisStratton I was thinking of seriously abusing the USB hardware on a Leonardo. I never use the ones with a separate 16U2 as a usb/serial converter, and had kinda forgotten that most of them were like that. I believe it would be possible to bring up the USB hardware on a 32U4 in such a way that it didn't manipulate the bus but still listened. Didn't look at the datasheet to check though.
      $endgroup$
      – Jack B
      Apr 16 at 17:52










    • $begingroup$
      @JimMack Glad it was helpful.
      $endgroup$
      – Jack B
      Apr 16 at 17:56






    • 1




      $begingroup$
      @JackB - no, that would not work. To sniff, you would need something where you can get your fingers in the fine grained USB function implementation, not a fixed function peripheral block. And realistically at that point you'd be better off grabbing a dual-USB STM32F4 and making something that grabbed whatever it wanted and passed the rest of the virtual serial payload stream through to the Arduino hanging off its OTG port. But then you take a step back and realize you should just replace the Arduino with something that does everything OP needs, or add software to talk to a second device.
      $endgroup$
      – Chris Stratton
      Apr 16 at 18:02












    • 4




      $begingroup$
      Actually building a sniffer out of an Arduino would be impossible in this case. The ATmega programmatic USB hacks are USB low speed and rely on part of the USB spec not being literally enforced to work. But the existing USB CDC implementation will be USB full speed, and so too fast to sniff this way. Possibly at the extreme of loading a custom firmware on the existing 16u2 (if the existing Arduino is a true Uno) one could make that operate in semi-compliant low speed mode and thus be sniffable, but your last statement is the key one: "isn't the best solution for your problem."
      $endgroup$
      – Chris Stratton
      Apr 16 at 17:34










    • $begingroup$
      Thanks for the tutorial. It's been made abundantly clear that there's no way a simple bridging could work, so I'm off to plan B.
      $endgroup$
      – Jim Mack
      Apr 16 at 17:38






    • 1




      $begingroup$
      @ChrisStratton I was thinking of seriously abusing the USB hardware on a Leonardo. I never use the ones with a separate 16U2 as a usb/serial converter, and had kinda forgotten that most of them were like that. I believe it would be possible to bring up the USB hardware on a 32U4 in such a way that it didn't manipulate the bus but still listened. Didn't look at the datasheet to check though.
      $endgroup$
      – Jack B
      Apr 16 at 17:52










    • $begingroup$
      @JimMack Glad it was helpful.
      $endgroup$
      – Jack B
      Apr 16 at 17:56






    • 1




      $begingroup$
      @JackB - no, that would not work. To sniff, you would need something where you can get your fingers in the fine grained USB function implementation, not a fixed function peripheral block. And realistically at that point you'd be better off grabbing a dual-USB STM32F4 and making something that grabbed whatever it wanted and passed the rest of the virtual serial payload stream through to the Arduino hanging off its OTG port. But then you take a step back and realize you should just replace the Arduino with something that does everything OP needs, or add software to talk to a second device.
      $endgroup$
      – Chris Stratton
      Apr 16 at 18:02







    4




    4




    $begingroup$
    Actually building a sniffer out of an Arduino would be impossible in this case. The ATmega programmatic USB hacks are USB low speed and rely on part of the USB spec not being literally enforced to work. But the existing USB CDC implementation will be USB full speed, and so too fast to sniff this way. Possibly at the extreme of loading a custom firmware on the existing 16u2 (if the existing Arduino is a true Uno) one could make that operate in semi-compliant low speed mode and thus be sniffable, but your last statement is the key one: "isn't the best solution for your problem."
    $endgroup$
    – Chris Stratton
    Apr 16 at 17:34




    $begingroup$
    Actually building a sniffer out of an Arduino would be impossible in this case. The ATmega programmatic USB hacks are USB low speed and rely on part of the USB spec not being literally enforced to work. But the existing USB CDC implementation will be USB full speed, and so too fast to sniff this way. Possibly at the extreme of loading a custom firmware on the existing 16u2 (if the existing Arduino is a true Uno) one could make that operate in semi-compliant low speed mode and thus be sniffable, but your last statement is the key one: "isn't the best solution for your problem."
    $endgroup$
    – Chris Stratton
    Apr 16 at 17:34












    $begingroup$
    Thanks for the tutorial. It's been made abundantly clear that there's no way a simple bridging could work, so I'm off to plan B.
    $endgroup$
    – Jim Mack
    Apr 16 at 17:38




    $begingroup$
    Thanks for the tutorial. It's been made abundantly clear that there's no way a simple bridging could work, so I'm off to plan B.
    $endgroup$
    – Jim Mack
    Apr 16 at 17:38




    1




    1




    $begingroup$
    @ChrisStratton I was thinking of seriously abusing the USB hardware on a Leonardo. I never use the ones with a separate 16U2 as a usb/serial converter, and had kinda forgotten that most of them were like that. I believe it would be possible to bring up the USB hardware on a 32U4 in such a way that it didn't manipulate the bus but still listened. Didn't look at the datasheet to check though.
    $endgroup$
    – Jack B
    Apr 16 at 17:52




    $begingroup$
    @ChrisStratton I was thinking of seriously abusing the USB hardware on a Leonardo. I never use the ones with a separate 16U2 as a usb/serial converter, and had kinda forgotten that most of them were like that. I believe it would be possible to bring up the USB hardware on a 32U4 in such a way that it didn't manipulate the bus but still listened. Didn't look at the datasheet to check though.
    $endgroup$
    – Jack B
    Apr 16 at 17:52












    $begingroup$
    @JimMack Glad it was helpful.
    $endgroup$
    – Jack B
    Apr 16 at 17:56




    $begingroup$
    @JimMack Glad it was helpful.
    $endgroup$
    – Jack B
    Apr 16 at 17:56




    1




    1




    $begingroup$
    @JackB - no, that would not work. To sniff, you would need something where you can get your fingers in the fine grained USB function implementation, not a fixed function peripheral block. And realistically at that point you'd be better off grabbing a dual-USB STM32F4 and making something that grabbed whatever it wanted and passed the rest of the virtual serial payload stream through to the Arduino hanging off its OTG port. But then you take a step back and realize you should just replace the Arduino with something that does everything OP needs, or add software to talk to a second device.
    $endgroup$
    – Chris Stratton
    Apr 16 at 18:02




    $begingroup$
    @JackB - no, that would not work. To sniff, you would need something where you can get your fingers in the fine grained USB function implementation, not a fixed function peripheral block. And realistically at that point you'd be better off grabbing a dual-USB STM32F4 and making something that grabbed whatever it wanted and passed the rest of the virtual serial payload stream through to the Arduino hanging off its OTG port. But then you take a step back and realize you should just replace the Arduino with something that does everything OP needs, or add software to talk to a second device.
    $endgroup$
    – Chris Stratton
    Apr 16 at 18:02













    4














    $begingroup$

    No you can't split USB, but what prevents you from connecting the UART receive pins of two Arduinos together so both receive same UART data, or making the first Arduino to send commands it does not understand to the other Arduino?






    share|improve this answer









    $endgroup$














    • $begingroup$
      Both are possible and I'll likely bridge the Rx lines in the end, but was hoping for a simple solution that doesn't require any modification to the existing controller.
      $endgroup$
      – Jim Mack
      Apr 16 at 16:56















    4














    $begingroup$

    No you can't split USB, but what prevents you from connecting the UART receive pins of two Arduinos together so both receive same UART data, or making the first Arduino to send commands it does not understand to the other Arduino?






    share|improve this answer









    $endgroup$














    • $begingroup$
      Both are possible and I'll likely bridge the Rx lines in the end, but was hoping for a simple solution that doesn't require any modification to the existing controller.
      $endgroup$
      – Jim Mack
      Apr 16 at 16:56













    4














    4










    4







    $begingroup$

    No you can't split USB, but what prevents you from connecting the UART receive pins of two Arduinos together so both receive same UART data, or making the first Arduino to send commands it does not understand to the other Arduino?






    share|improve this answer









    $endgroup$



    No you can't split USB, but what prevents you from connecting the UART receive pins of two Arduinos together so both receive same UART data, or making the first Arduino to send commands it does not understand to the other Arduino?







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Apr 16 at 16:50









    JustmeJustme

    7,9852 gold badges8 silver badges22 bronze badges




    7,9852 gold badges8 silver badges22 bronze badges














    • $begingroup$
      Both are possible and I'll likely bridge the Rx lines in the end, but was hoping for a simple solution that doesn't require any modification to the existing controller.
      $endgroup$
      – Jim Mack
      Apr 16 at 16:56
















    • $begingroup$
      Both are possible and I'll likely bridge the Rx lines in the end, but was hoping for a simple solution that doesn't require any modification to the existing controller.
      $endgroup$
      – Jim Mack
      Apr 16 at 16:56















    $begingroup$
    Both are possible and I'll likely bridge the Rx lines in the end, but was hoping for a simple solution that doesn't require any modification to the existing controller.
    $endgroup$
    – Jim Mack
    Apr 16 at 16:56




    $begingroup$
    Both are possible and I'll likely bridge the Rx lines in the end, but was hoping for a simple solution that doesn't require any modification to the existing controller.
    $endgroup$
    – Jim Mack
    Apr 16 at 16:56











    2














    $begingroup$


    Can I use USB passively, as a listener only, with the second
    controller?




    Technically yes, you can build a device that is passively looking at USB traffic and be able to get information from it and take any actions. In fact, devices like that do exist. They are called "USB Protocol Analyzers".



    Typical architecture of such devices consists of an non-invasive sniffer on D+/D- lines (high-impedance voltage divider plus gain compensating wideband amplifier), which feed a standard (stand-alone) USB PHY. The serial-parallel output interface from the PHY (ULPI or UTMI or PIPE3) is then watched/logged by a sizeable FPGA that has decoding tools and can trigger off USB protocol events. Examples: Teledyne-LeCroy, Ellisys.



    enter image description hereenter image description here



    So you can watch USB traffic and get data. To get them in real time you will need to program FPGA and run it at sufficient clock rate to implement most elements of USB Serial Interface Engine (except forming ACK/NAK replies).






    share|improve this answer









    $endgroup$



















      2














      $begingroup$


      Can I use USB passively, as a listener only, with the second
      controller?




      Technically yes, you can build a device that is passively looking at USB traffic and be able to get information from it and take any actions. In fact, devices like that do exist. They are called "USB Protocol Analyzers".



      Typical architecture of such devices consists of an non-invasive sniffer on D+/D- lines (high-impedance voltage divider plus gain compensating wideband amplifier), which feed a standard (stand-alone) USB PHY. The serial-parallel output interface from the PHY (ULPI or UTMI or PIPE3) is then watched/logged by a sizeable FPGA that has decoding tools and can trigger off USB protocol events. Examples: Teledyne-LeCroy, Ellisys.



      enter image description hereenter image description here



      So you can watch USB traffic and get data. To get them in real time you will need to program FPGA and run it at sufficient clock rate to implement most elements of USB Serial Interface Engine (except forming ACK/NAK replies).






      share|improve this answer









      $endgroup$

















        2














        2










        2







        $begingroup$


        Can I use USB passively, as a listener only, with the second
        controller?




        Technically yes, you can build a device that is passively looking at USB traffic and be able to get information from it and take any actions. In fact, devices like that do exist. They are called "USB Protocol Analyzers".



        Typical architecture of such devices consists of an non-invasive sniffer on D+/D- lines (high-impedance voltage divider plus gain compensating wideband amplifier), which feed a standard (stand-alone) USB PHY. The serial-parallel output interface from the PHY (ULPI or UTMI or PIPE3) is then watched/logged by a sizeable FPGA that has decoding tools and can trigger off USB protocol events. Examples: Teledyne-LeCroy, Ellisys.



        enter image description hereenter image description here



        So you can watch USB traffic and get data. To get them in real time you will need to program FPGA and run it at sufficient clock rate to implement most elements of USB Serial Interface Engine (except forming ACK/NAK replies).






        share|improve this answer









        $endgroup$




        Can I use USB passively, as a listener only, with the second
        controller?




        Technically yes, you can build a device that is passively looking at USB traffic and be able to get information from it and take any actions. In fact, devices like that do exist. They are called "USB Protocol Analyzers".



        Typical architecture of such devices consists of an non-invasive sniffer on D+/D- lines (high-impedance voltage divider plus gain compensating wideband amplifier), which feed a standard (stand-alone) USB PHY. The serial-parallel output interface from the PHY (ULPI or UTMI or PIPE3) is then watched/logged by a sizeable FPGA that has decoding tools and can trigger off USB protocol events. Examples: Teledyne-LeCroy, Ellisys.



        enter image description hereenter image description here



        So you can watch USB traffic and get data. To get them in real time you will need to program FPGA and run it at sufficient clock rate to implement most elements of USB Serial Interface Engine (except forming ACK/NAK replies).







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Apr 17 at 15:39









        Ale..chenskiAle..chenski

        31.8k1 gold badge22 silver badges73 bronze badges




        31.8k1 gold badge22 silver badges73 bronze badges
























            1














            $begingroup$

            One solution could be to essentially implement a daisy-chained local serial topology of Arduinos. One of these at the 'front' of the chain would expose its USB CDC interface. Then you'd wire a pair of pins configured for SoftwareSerial to the next Arduino's Serial pins (D0/D1) and so forth. Then you could echo the serial traffic received up and down the chain as necessary, with every member of the chain deciding whether it should respond as appropriate.






            share|improve this answer











            $endgroup$














            • $begingroup$
              Just read the comments, and what I propose here is pretty similar to what @pjc50 was getting at.
              $endgroup$
              – vicatcu
              Apr 16 at 21:55










            • $begingroup$
              Thanks, I've decided the only practical method is to tie the two Rx lines together. It means physically modifying the original controller, but that appears unavoidable.
              $endgroup$
              – Jim Mack
              Apr 17 at 0:56















            1














            $begingroup$

            One solution could be to essentially implement a daisy-chained local serial topology of Arduinos. One of these at the 'front' of the chain would expose its USB CDC interface. Then you'd wire a pair of pins configured for SoftwareSerial to the next Arduino's Serial pins (D0/D1) and so forth. Then you could echo the serial traffic received up and down the chain as necessary, with every member of the chain deciding whether it should respond as appropriate.






            share|improve this answer











            $endgroup$














            • $begingroup$
              Just read the comments, and what I propose here is pretty similar to what @pjc50 was getting at.
              $endgroup$
              – vicatcu
              Apr 16 at 21:55










            • $begingroup$
              Thanks, I've decided the only practical method is to tie the two Rx lines together. It means physically modifying the original controller, but that appears unavoidable.
              $endgroup$
              – Jim Mack
              Apr 17 at 0:56













            1














            1










            1







            $begingroup$

            One solution could be to essentially implement a daisy-chained local serial topology of Arduinos. One of these at the 'front' of the chain would expose its USB CDC interface. Then you'd wire a pair of pins configured for SoftwareSerial to the next Arduino's Serial pins (D0/D1) and so forth. Then you could echo the serial traffic received up and down the chain as necessary, with every member of the chain deciding whether it should respond as appropriate.






            share|improve this answer











            $endgroup$



            One solution could be to essentially implement a daisy-chained local serial topology of Arduinos. One of these at the 'front' of the chain would expose its USB CDC interface. Then you'd wire a pair of pins configured for SoftwareSerial to the next Arduino's Serial pins (D0/D1) and so forth. Then you could echo the serial traffic received up and down the chain as necessary, with every member of the chain deciding whether it should respond as appropriate.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Apr 16 at 22:26

























            answered Apr 16 at 21:53









            vicatcuvicatcu

            16.7k8 gold badges64 silver badges136 bronze badges




            16.7k8 gold badges64 silver badges136 bronze badges














            • $begingroup$
              Just read the comments, and what I propose here is pretty similar to what @pjc50 was getting at.
              $endgroup$
              – vicatcu
              Apr 16 at 21:55










            • $begingroup$
              Thanks, I've decided the only practical method is to tie the two Rx lines together. It means physically modifying the original controller, but that appears unavoidable.
              $endgroup$
              – Jim Mack
              Apr 17 at 0:56
















            • $begingroup$
              Just read the comments, and what I propose here is pretty similar to what @pjc50 was getting at.
              $endgroup$
              – vicatcu
              Apr 16 at 21:55










            • $begingroup$
              Thanks, I've decided the only practical method is to tie the two Rx lines together. It means physically modifying the original controller, but that appears unavoidable.
              $endgroup$
              – Jim Mack
              Apr 17 at 0:56















            $begingroup$
            Just read the comments, and what I propose here is pretty similar to what @pjc50 was getting at.
            $endgroup$
            – vicatcu
            Apr 16 at 21:55




            $begingroup$
            Just read the comments, and what I propose here is pretty similar to what @pjc50 was getting at.
            $endgroup$
            – vicatcu
            Apr 16 at 21:55












            $begingroup$
            Thanks, I've decided the only practical method is to tie the two Rx lines together. It means physically modifying the original controller, but that appears unavoidable.
            $endgroup$
            – Jim Mack
            Apr 17 at 0:56




            $begingroup$
            Thanks, I've decided the only practical method is to tie the two Rx lines together. It means physically modifying the original controller, but that appears unavoidable.
            $endgroup$
            – Jim Mack
            Apr 17 at 0:56


















            draft saved

            draft discarded















































            Thanks for contributing an answer to Electrical Engineering Stack Exchange!


            • 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.

            Use MathJax to format equations. MathJax reference.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f432888%2fcan-a-usb-port-passively-listen-only%23new-answer', 'question_page');

            );

            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







            Popular posts from this blog

            Tamil (spriik) Luke uk diar | Nawigatjuun

            Align equal signs while including text over equalitiesAMS align: left aligned text/math plus multicolumn alignmentMultiple alignmentsAligning equations in multiple placesNumbering and aligning an equation with multiple columnsHow to align one equation with another multline equationUsing \ in environments inside the begintabularxNumber equations and preserving alignment of equal signsHow can I align equations to the left and to the right?Double equation alignment problem within align enviromentAligned within align: Why are they right-aligned?

            Training a classifier when some of the features are unknownWhy does Gradient Boosting regression predict negative values when there are no negative y-values in my training set?How to improve an existing (trained) classifier?What is effect when I set up some self defined predisctor variables?Why Matlab neural network classification returns decimal values on prediction dataset?Fitting and transforming text data in training, testing, and validation setsHow to quantify the performance of the classifier (multi-class SVM) using the test data?How do I control for some patients providing multiple samples in my training data?Training and Test setTraining a convolutional neural network for image denoising in MatlabShouldn't an autoencoder with #(neurons in hidden layer) = #(neurons in input layer) be “perfect”?