Alternatives to usb male to micro usb male dongle

I am looking for a usb a male to micro usb male dongle and couldn’t find here. This is to power pizero so that I can plug it directly as a dongle into my charger brick usb socket with out the pi dangling. I looked at the usb boards for pizero, one requires soldering and the other one oddly stick out. I am after a minimal setup and I can reuse the adopter for other cases.

Can this usb a to micro usb adapter be used for power ?

Is there any way I can achieve the setup I am after ?


Hi Sreenivas,

Unfortunately, the adapter on our site you included is for the male end of a USB A cable. So it won’t work from a charger brick. Unfortunately, it looks like we are a little limited in terms of just straight adaptors such as the one you included.

Hey Sreenivas,

As Mitchell said, unfortunately, we don’t supply the exact part that you’re after. However, if you’re up for some soldering, you should be able to adapt this connection directly onto the OTG connection that you’ve listed to be able to achieve that same result. Make sure to double-check your pinouts first.

On top

Core Electronics | Support

Hey @Mitchell and @Bryce !

Thanks for the suggestion! At this point I don’t have all the equipment for soldering. I will give that a shot some other time. For now I settled for a regular usb micro to A cable. Thanks for your time! :slight_smile:


I want to do something similar with USB OTG, but a little different.

I’ve a USB Micro male to USB Type A male cable that I’ve connected a Pi-Zero to an R-Pi.

However, the Pi-Zero doesn’t have enough USB data ports for what I’d like to do,
and rather than add a USB-hub, I’d like to try OTG from R-Pi to R-Pi (currently have a couple of Model 4s)

Does the Raspbian support OTG on standard, not micro, USB ports.
Looked but haven’t seen this described.
I don’t know if the USB hardware on the standard R-Pi supports OTG or not.

I figure I need a USB Type A to USB Type A male for this.
Is it safe or do I blow something up?

The closest I’ve come, based on your Tiny OTG adapter link, is this.
But I’m a little unclear from the photos if it’s Male to Male.

SKU PRT-00437

Hi Steve,

Just so we can get the full picture, would you mind elaborating on what you need your Pis to do? (And why there needs to be 2 of them?

To my knowledge, if you set up the Zero as a USB Gadget, it should be able to be used on any standard USB port (like on a Pi 4) but it’s hard to say without a little more on what you’re using it for.

Keen to see where you’re going with this!

1 Like

A standard technique in security devices is a “protocol break”, which can be used for a number of things including “data diodes”.

This requires connecting two devices back-back, hence two R-Pi’s.
I’d like to package them as a single unit, with the user having a KVM switch to select either the “hot” or “cold” device.

One device (“hot”) connects to a network with TCP/IP, then needs to connect “via another means” to the other device (“cold” or “inside”)

I explored USB OTG to USB with “gadget” drivers and was able to effectively use (over USB) serial, ethernet and mass storage.
Can’t use TCP/IP over the USB-ethernet, because that isn’t a “protocol break”, leaving serial and mass storage. I was able to export a virtual disk, partition it with “fdisk” as two partitions and export a pair of filesystems. If the two devices co-operate, only one device writes to an individual filesystem, avoiding corruption.
Normal Linux filesystems are cached by the kernel, so this scheme requires frequent umount/mount cycles which is not particularly robust or reliable.

Which left serial-over-USB. I trialled it and transferred a 2GB file in 11 sec from memory.
Spent some time setting up uucp, but abandoned that because it’s complex overkill and is designed as a mail transport, not the simple file transfer that I need.

My intention was to use a Pi-Zero as the “hot” side, connected to the Network via TCP/IP.
The limited compute capability of the P-Zero makes it more difficult to target and encourages a minimal install, exposing a smaller attack surface.

The “cold” side would be a reasonably configured (full) R-Pi that had enough grunt and storage to operate as a normal desktop computer, though without direct Network access.

Hopefully I could figure out a means to make the “protocol break” transparent to the user, to allow them to focus on their work, not fighting the technology.

The conflict is that I need to connect the Pi-zero to both a USB keyboard/mouse and the other R-Pi for the serial over USB connection. With just one data USB port, I can’t do that.

I don’t want to use a USB hub with the Pi-Zero, leaving the only option two full R-Pi with type A USB ports, somehow connected ‘back to back’.

Perhaps you can suggest how I connect two (full) R-Pi’s together over USB to build this device.


Hey Steve,

Welcome to the forum!

Interesting application, the Raspberry Pi (at least the Zero and A/A+, not some of the newer models or B) do support USB OTG so you can use a virtual terminal over a serial connection and similar applications which you can custom design as seen in the tutorial that I’ve linked below for you:

For simple file transfer, I’d highly suggest simply looking into hosting an FTP server and client on each Pi or hosting a NAS on a different machine that both your Pi can use for filesharing. It’s a much more optimized solution to this problem and quite quick and reliable to set up:

Also, TCP/IP or Transfer Control Protocol / Internet Protocol is actually a set of standards regarding how information is broken up into packets and shared between devices on a network depending on their unique address respectively, it’s not a method of transferring information, but more of a backbone to allow for communication on various ports on different machines with various hardware standards relaibly on any network.


1 Like


Thanks for the detailed & well illustrated reply.

You don’t seem to have fully understood the security problem I’m addressing:
a higher level of protection than a standard firewall.
DSD, now ASD, used to require these - or better - for some systems I worked on.

This is an example of an open-source implementation.

I’ve worked professionally with email, file transfer & digital networks since the late 1970’s. I understand both the ISO model, TCP/IP and their differences. Thanks for the article on IP & TCP and the other protocols in the RFCs.

The “How-to-OTG” gist was useful.
I’d read it without properly understanding the differences in USB sub-system architecture.
A good summary of what I needed was in the 2nd para.

The Pi-zero is the only variant of 1, 2, 3 that is able to properly support OTG because it recognises the USB “Id” pin. The Model 1A+ may possibly work, but is limited as the Id pin is grounded.

The key piece of info is that OTG won’t over via a USB hub, R-Pi USB doco

There is an interesting tidbit in the CM4 datasheet (PDF):

The port is capable of being used as a true USB On-The-Go (OTG) port. While there is no official documentation, some users have had success making this work.
The USB_OTG pin is used to select between USB host and device that is typically wired to the ID pin of a Micro usb connector.
To use this functionality it must be enabled in the OS that is used. If using either as a fixed slave or fixed master, please tie the USB OTGID pin to ground

Having ground through another bunch of doco, I’m reasonably confident that I know the issue I’m coming up against.
The Broadcom chips used have a single USB 2.1 channel (Pi 4 has an extra PCI channel, used for USB 3 ports)

The Pi-Zero is the only R-pi on which OTG is designed in.

System Block Diagrams are hard to come by. Found one on Element-14, for the model 3.

The R-pi forums have a page which highlights missing Block Diagrams.

The Wikipedia page makes a veiled reference to the absence of Block Diagrams.
If you know the answer already, it also explains USB OTG on the Pi-zero and the hub on other devices.

Summary: If I can’t do what I want to do with a Pi-Zero, I can’t do it at all.