SparkFun Forums 

Where electronics enthusiasts find answers.

All things pertaining to wireless and RF links
By Gutierrez
#7129
I have a sinking feeling I'm violating some simple rules here, but if you hooked up a usb device (not the usb port on a computer, dongles are for that) to a USB to UART adapter, then wired that to the UART in of a BlueSmirf, got a good regulated power input (say some nice rechargable batteries and a regulator) would this constitute a USB to Bluetooth radio module?

You know, cram a dongle in your USB drive, connect up to the radio unit and you're talking sweet wireless gratification? I would assume there would at least be some concerns over data transfer rates depending upon your input device at least and maybe the need for some logic to control the Blutooth Module (Resetting, connecting, setting transfer rate), but is this feasible?
By MGP
#7130
You can't do that -- the USB-to-UART adapter needs a host connection, not a device connection. Bottom line, you need a host port to talk to your USB drive.

I bet I've seen a variation of this question at least 100 times.
By Gutierrez
#7131
MGP wrote:You can't do that -- the USB-to-UART adapter needs a host connection, not a device connection. Bottom line, you need a host port to talk to your USB drive.
I figured I was missing a point somewhere.
I bet I've seen a variation of this question at least 100 times.
Apparently this means it's something that piques a lot of interest. Ignorance aside, anyone working on any projects that tackle this solution?
By MGP
#7136
The problem with the host controller is that it takes a relatively massive amount of firmware and a lot of CPU horsepower -- something that isn't easy to do with a small microcontroller (almost impossible). There is also the issue of drivers for the host side -- you need a specific driver for every client device. You might get lucky and be able to implement a Windows-like HID or mass storage class driver. Most manufactureres provide drivers for Windows, OS-X and maybe Linux but they won't give you enough details to write your own proprietary driver.

There are a few manufacturers that make host controller chips for embedded applications (Cypress, TransDimension are a couple that come to mind). They offload a lot of the USB stack to hardware but it still takes a lot of CPU horsepower to keep up with USB packets. They are made more for applications like embedded Linux where you have a real OS but no chipsets with USB controller hardware.

Sadly, the developers of USB really made the assumption that any device on the bus would be connected to a PC host. As much as they'd like to sell it as a replacment for RS-232, it's not since it's a host-client arrangement and RS-232 isn't.
By Gutierrez
#7162
[exposition]

So if anyone's willing to stay with me on this? I'm trying to brainstorm all possible methods to actually produce this capability. It would greatly help in completing my Master's thesis. I want to be able to send and interpret the USB signals wirelessly from a Canon Digital Rebel camera. I'm building a portable image capturing system to gather data as part of a system. Currently I'm just using a cheap wired webcam, but the use of a professional camera lends more credibility to the experiment, if I'm just SOL, oh well.

[/exposition]
MGP wrote: There are a few manufacturers that make host controller chips for embedded applications (Cypress, TransDimension are a couple that come to mind). They offload a lot of the USB stack to hardware but it still takes a lot of CPU horsepower to keep up with USB packets. They are made more for applications like embedded Linux where you have a real OS but no chipsets with USB controller hardware.
I have a platform I could develop on (an ARM chip running uClinux.) I'd have to add USB drivers to the device, though, but maybe there's a direction...
MGP wrote: There is also the issue of drivers for the host side -- you need a specific driver for every client device.
Alright, let's narrow the field to my very specific device, a digital camera with USB interface. I have the SDK for the camera including all drivers and libraries for accessing information on the camera (C++ code, ect.) But yeah, it's still aimed at USB communication, I'll look into the comm libraires for the device, though... Maybe there is room for other protocols. Then again I'd rather not crack the case on my expensive camera to get to the data lines.
MGP wrote: Sadly, the developers of USB really made the assumption that any device on the bus would be connected to a PC host. As much as they'd like to sell it as a replacment for RS-232, it's not since it's a host-client arrangement and RS-232 isn't.
It figures. So there are USB controller, trancievers and other devices, but they are meant to back up to a processor with a driver, and all conversions to other protocols require driver policing because it's host/clent and has a packet structure.

Right, more googling and forumn searching for me.

Thanks for at least humoring me so far. If anyone does contribute information that moves me significantly forward, they will recieve credit in all publications for the project. (ooh! ahh!)
By NleahciM
#7166
If you just need a wireless camera I see two solid options: there is a new camera coming out that has built in wifi - can't remember the manufacturer, but it was one of the big ones. Another solid option I see is that there are many network connected video cameras that have pretty decent resolution and framerate - I'm not sure what kind of res you need though - but couple one of those with a wifi ethernet bridge and you'd be good to go. Trying to get USB wireless is going to be really nasty - the only way I can imagine doing it is to have a host device connected to the remote device - that device would handle all the usb host functions, as well as whatever wireless communication method you were using. Could be handled by an ARM - but it'd be a decent amount of work.