Apparently there is a workaround to allow the UNO Q to work in host mode on Github here:
https://github.com/Psalmustrack/arduino-uno-q-usb-fix
Never having tried it myself, I can't vouch for its success of safety. He does point out that its not a supported scenario. The readme also doesn't specifically state what OS versions are considered to be "older OS versions". Seems to suggest it might be fixed in newer versions?
BitSeeker's statement that the Q does not supply power to the USB-C jack, although it does agree with my observations, does not agree with the schematic, which shows that the 5V_USB_VBUS lines I mentioned are directly connected. I will be doing some debug on the board to find out why there is a discrepancy on the schematic in this regard.
Emily's point that the Q is not capable of acting as a USB host seems to also make sense, though her clarification that "USB-C dongle with power delivery allows the Uno Q’s USB-C port to operate in a host/hub configuration" doesn't really make sense. Is the Q a USB host or not?? Is this documented somewhere that the Q can switch to host mode if it receives some specific communication from a PD hub?
And I did already try that above link about "allow the UNO Q to work in host mode" but it made no difference. It seems that older board versions may have supported that but maybe in newer versions they intentionally removed any such support.
Re. the earlier mention of RPi's, those all work perfectly fine as a USB host. You can plug in a thumb drive or sound fob into any RPi 2/3/4/5/Z2 and it works just fine. No hub needed.
Interesting to note. @ptillisch or one of the Arduino team might know or be able to confirm one way or the other.
No, by itself it is not. With the addition of the dongle it functions as one.
That was exactly the point. RPIs are USB hosts right out of the box. Uno Q's are not.
It would be nice if Arduino would document somewhere why they do not want to support basic USB host functionality that is supported by all other SBC's I know of. If a PD hub is absolutely required in order to use any USB peripheral, they should make that clear in all their documentation. For a $3 MCU board that would not be unexpected but for a Linux SBC it's kind of ridiculous. The Uno Q in fact cannot be considered an SBC if this is true. Which seems like a short-sighted design decision on the part of Arduino, as for the Uno Q to support a basic embedded application with a USB interface now requires an added PD hub which adds significant cost and size. Not really a big deal but it wouldn't be that hard for Arduino to properly support USB standards and work like a normal SBC.
I don't pretend to know what Qualcomm's intent was for this product but I would guess that they envision an end application to interface with the JMEDIA/JMISC connectors rather than a USB dongle.
Qualcomm's intent is nothing more than to increase brand awareness for their CPU chips. As a giant corporation they now focus only on the bottom line and couldn't care less about accommodating smaller use-cases, or low-cost embedded / hobbyist / DiY computing. As a result the product is fundamentally no longer what its name implies. They have turned a "Universal Serial Bus" into something that is no longer in fact universal. They have turned a "Single-Board Computer" into something that can no longer function as a single board (in any application requiring use of a USB I/O peripheral). This is the typical thinking you get from these giant corporations where all the employees are super-specialized in some narrow area and no one "gets" the bigger picture or the value of established industry standards. Qualcomm is only a couple miles from me here in San Diego and I know many people who used to work there. "Used to" being the key word because they stopped hiring American Engineers about 20 years ago. Go into any of their office buildings now and by all appearances you'll think you're in the middle of India.
I did confirm with a multimeter diode check that their posted schematic is not correct and there is in fact a diode that allows current to flow only into the USB-C jack, ie. 5V_USB_VBUS does not connect directly to the pins labeled with that net name on the schematic on the JANALOG and JSPI headers. And I tested with 2 other powered USB 2.0 hubs and confirmed that the Uno will not communicate with USB 2.0 devices. Thus the "USB" port appears to be a very Non-universal bus that violates the most basic premises of USB specifications and supports only USB 3 PD devices.
Hello.
I have the same goal as davidgsd. I was actually able to get it to operate from the 5V pin (I was able to power it when I worked on it around December last year > the board in the photo).
However, today I tried writing and configuring a different board in the same way, but it didn't power via USB. The board firmware is the same, and the post-writing command processing is the same, but I still can't achieve USB power supply. What's going on? Of course, I've also implemented the process for switching to HOST mode.
Something might have changed. I can share logs, etc. I'd like to solve this problem too.
Thanks,
Hello.
One more thing. Last year I bought three boards; two could be powered via USB, but one could not. Of the six boards I bought this year, I tried two, and neither could be powered.
I wondered if there might be a connection, so I examined the circuit boards and found a common point. The boards that could be powered via USB were manufactured on August 14th, while the ones that couldn't were manufactured on September 17th. This might be related. Just for your reference.
Thanks,
Hello.
The Arduino team has finally acknowledged the differences in the initial batch:
Please provide accurate information. And sooner. Seriously.
I suspect this power supply circuit will be changed again.
Hi. I’m also currently weighing whether or not to buy this Arduino. Here is my proposed solution. I have an astro-camera with a USB 2.0 Type-B port.
Here is how I plan to solve the problem: I’ll use a three-connector OTG adapter cable (USB 3.1 to USB 2.0). The first connector—USB-C (male)—plugs into the Arduino port. The second—USB-A (female)—connects to the camera’s standard adapter cable (USB-A to USB-B). The third is for power (USB-A); I’ll connect the Arduino’s output (IN) to this third connector (alternatively, I could use a cheap DC converter). I’ll supply 13 volts from a lithium battery to the Arduino’s VIN pin. The Arduino will detect the OTG connection, switch to Host mode, and communicate with the astro-camera via USB 2.0.
Why am I considering Arduino? It consumes two to three times less power than the Raspberry Pi 4 or 5. I have reservations about the computing power and memory capacity of the Zero 2W model, yet I’m still leaning in that direction. What’s holding me back regarding the Arduino Uno Q is the concern about potential issues.
Hi @andrey_g.
The UNO Q doesn't do this automatically. However, you can trigger USB host mode. An easy way to do that is by connecting a jumper between the VOL_DOWN and GND pins on the board's JCTL header:
I need to check which chip is installed at the VIN input; I haven't found that information yet.
I also need to see if the device heats up when using this chip to power the astro-camera (which draws 200 mA 95% of the time, and 400 mA otherwise) and determine whether a DC converter is needed.
Thanks for the information, ptillisch. It will be useful if I decide to use the device in question. I described the method for bypassing the issue above—it applies to any version of the device (new or old).
An interesting use case and the lower power requirement would make sense for long imaging sessions running on battery. Having recently acquired a decent mount, I have started setting up a Pi for astronomy (INDI+kstars, might try astroberry as well) so I find your idea of using the UNO Q instead rather interesting.
Were you thinking about installing the full suite of astronomy software such as INDI and other tools (kstars, PHD2, platesolving etc) on the UNO Q? Or just using it as a WiFi enabled pass through? Or perhaps just for guiding?
The UNO Q is fine for lightweight use (e.g. sufficient for running AppLab and running sketches) but might perhaps get a bit hot running image capture. Hopefully 2Gb is enough RAM resource. The USB2.0 camera will perhaps not place as much demand on the processor and memory as a more modern USB3.x camera and it will be interesting to see how well the UNO Q handles things. One can always put a heatsink over the QRB2210 to improve heat dissipation. The space available to store the captured images and videos is not that big either although should be sufficient for a session or two especially with a USB2.0 camera, unless, of course, you are considering storing the results on a USB3.x stick?
My plans are slightly different. I own three telescopes—with mirror diameters ranging from 360 mm to 610 mm—that I built myself. They were originally equipped with ServoCat motors, but I removed the stock ones, installed my own, and implemented a drive system using harmonic gears+servomotors. The system is still controlled via the ServoCat + Nexus DSC combination. Now, I want to add the final piece of the puzzle: precise telescope pointing using an electronic finder (possibly based on an Arduino Uno Q).
The plan involves two control buttons: the first calculates the offset between the telescope axis and the camera for the current observing session (or shuts down the Linux system if held for over 3 seconds), while the second handles precise object pointing.
Sequence: Image integration + USB transfer to RAM: ~505 ms.
Triangle calculation (D20) in RAM (Plate Solving): ~300 ms.
Wi-Fi packet transmission to the Nexus DSC.
The Nexus commands the ServoCat (add USB connection) to adjust the telescope axis position so the object is centered.
That’s the general idea.
Ah, so the UNO Q will be doing the plate solving and sending the result to the Nexus to guide the telescope. I used to own a 300mm dob, but have nothing that big now. The light pollution has made visual observing very difficult at my location now so I am looking to switch to doing some EAA and maybe a bit of imaging. I have recently upgraded my mount but unfortunately made the mistake of getting a cheap planetary camera that is not suitable for EAA as its sensor is too small. I am currently in the hunt for an IMX585 based camera.
I hope the UNO Q will handle what you are looking to achieve.
I was just wondering whether the AI element of the WRB2210 could be used to enhance the plate solving in some way? Not sure whether anyone would have looked at that kind of integration yet?
I have also been informed that EAA can be done using a single camera for both image capture and plate solving therefore avoiding the need for a second guide camera and scope, so I do have an interest in getting plate solving up and running once I get a suitable camera. In my case I am driving a HEQ5Pro so yes, different drive requirements but the idea of experimenting with a UNO Q to drive this with its lower power requirements is appealing. It also occurred to me that I might be able to drive the mount and/or ST-4 guide port from the Rx/Tx pins on the STMU585 (with suitable level shifting), although a USB-to-serial EQMOD cable plugged into a dongle might suffice.
I just received the Arduino branded dongle I purchased and am going to test the USB host mode solution provided by @ptillisch in post #35.
That’s not quite right. Tracking and GoTo are handled by Nexus and Servocat. Due to various factors and errors, a Dobsonian mount cannot always point precisely enough to place the object in the center of the eyepiece. Locating very faint objects poses a problem in about 5 percent of cases. If an object is guaranteed to be centered, it is easier to make out. Therefore, the button's function would be used relatively rarely, yet it remains important in certain situations.
Regarding post #35: that jumper alone likely won't work—at least, that is what the analysis of this forum thread suggests. You will run into issues powering the camera. You need to perform the specific steps I described earlier. That is my take on it.
