Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I wanted to convert a USB differential signal into one signal, and then send it over one wire, and then restore in back to differential signals at the other end. I wanted to do this for a USB 1.1 keyboard running at Low Speed which is specified at 1.5Mbps (on my scope it looks more like 150kbps).

Obviously I want this to go in both directions, but like USB, not at the same time. Wikipedia says the USB differential signals are typically opposite like 3.3V/0V or 0V/3.3V or 0V/0V, but never 3.3V/3.3V. I thought an instrumentation amplifier to send, and an ADC to receive. Is this reasonable or am I going about it the wrong way?

share|improve this question
How would you know when to switch between sending and receiving? I have used a set that transports USB over 100m (using RS485), but I think it interprets USB at both ensds, so it operates at OSI level 2/3/4 (messages), not at 1 (electrical). – Wouter van Ooijen Mar 19 at 7:36
The short answer is no - what are you trying to achieve with this? – pjc50 Mar 19 at 12:11
" or 0V/0V" is not opposite. – Tom Carpenter Mar 19 at 14:42
What about a more ambitious project? I could use a USB to ULPI converter, (have these) and use a serdes in a fpga (I have 2 adafruit mojo boards). The keyboard is a starting project to see if this can be done. – BSEE Mar 21 at 4:57
up vote 12 down vote accepted

USB transmits data as a differential signal, but the differential rules are broken in order to create framing signals. Part of the protocol specifies what to do with those combinations of levels.

  • 3.3V/3.3V - signals the device is removed.
  • 0V/3.3V - Low speed device
  • 3.3V/0V - Full speed device
  • 0V/0V - Single ended zero, marks the end of frame, or if held long enough, a device reset.
  • 3.3V/0V and 0V/3.3V also represent "J" and "K" while transmitting actual data.

So your plan would somehow need to signal the other end when these conditions are occurring. Maybe use more than two voltage levels in your analog segment.

Get all that right, and USB's timing constraints will probably ruin it for you.

share|improve this answer

Trying to do this for USB in general is probably unwise - quite tricky, and far more complicated than necessary to accomplish your stated goal.

You'd be better off coming up with a custom scheme for transmitting keyboard data, and then turning it back into USB in a dongle that connects to the PC. (You could of course buy an off-the-shelf wireless keyboard, unless that is out for reasons of reliability, interference, or security).

It would be easiest to build the project if you get a legacy PS/2 interface keyboard as that synchronous interface can be managed from just about any microcontroller. However you can also host a USB keyboard from an MCU - I've had some luck with the KL25Z series on custom PCBs as well as that version of the Kinetis "freedom board", and also with STM32F4's on custom and Nucleo boards. While I was not able to get a K20 series MCU host my specific non-keyboard peripheral of interest, I think the tentative host mode code for that on the Teenys3.x boards may support keyboards.

For the intermediate link you probably want an asynchronous serial scheme. If you need true bidirectional communication (want to activate those keyboard LEDs?) you could consider something like typical RS845 half-duplex protocols, only with single ended signalling.

On the PC dongle end you can pick any handy micro with a USB device interface. Personally I might pick the same one I used on the transmit end, as most embedded USB hosts can also be a device. I did a KL25Z board that can be either role - install a female USB connector on the top of the board and program it as a host, or flip it over and install the male connector on that side with the device mode firmware.

share|improve this answer

It would probably be much easier to disassemble the keyboard, and replace the controller module with a multiplexer/demultiplexer that combines all the lines that connect to the keyboard switch circuitry (typically around 10-12 lines flowing out of the controller into the switches and a similar number coming back) and then reverse the process to connect back to the controller module elsewhere.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.