Many devices (cars, TVs, iPod Docks, AVR receivers etc) have the facility to access class compliant USB Mass Storage Devices and play wav files etc. stored upon them.
I understand I can use a small linux system with appropriate bi-mode USB host/ receiver ports (e.g. a Beagleboard black) to emulate a FAT32 mass storage device (a linux 'gadget') that can be plugged into a car and used as if it were a dumb memory stick - 'g_mass_storage'
http://www.linux-usb.org/gadget/file_storage.html
For static files this works fine. However, I would like to have the beagle board run a bluetooth receiver, decode the stream into PCM and then pipe this into a dummy.wav file that could be read (indefinitely) by the car (ipod Dock etc.)
E.g.
[Android or iPhone] --> [bluetooth a2dp] --> [beagleboard/ small linux system] --> [PCM audio]* --> [ g_mass_storage].'dummy.wav' --> [car's USB host]
The steps up to the * are trivial, but I can't work-out how to pipe data into a dummy.wav file as FAT32 doesn't support pipes and yet this is typically the only format supported by cars etc.
It seems something like this is at least conceptually possible:
http://www.dension.com/products/dbu
and 'cubund' on indigogo seems to be following the same principle (sorry can't paste second link as stackexchange won't let me)
I would have bought one if it had got-off the ground!
Any ideas?
Thanks,
Thomas
P.S. the first part of the chain (i.e. the phone via bluetooth) could be any mechanism and isn't particularly interesting. The challenge is to provide a virtual file that would enable 'streaming' of Google Music/ web radio etc. to devices only capable of reading files from a mass storage device.
It is already on the market for bluetooth. Check on ebay for bluetooth audio receiver. Is a little dongle that you can put in usb port and you may use it like regular usb drive.
Best regards,
Romeo
Related
As far as I understand the USB devices introduce themselves by sending a device descriptor to the host which uses the information embedded in the descriptor to find and load the right driver/drivers. What I don't understand is why the drivers need the configuration, interface, endpoint and string descriptors from the device. I know the descriptors describe the device as a whole e.g. number of configurations, interfaces, endpoints, types, the size of the packets, the purpose of each byte in the packet etc. Why can't the drivers include this information from the start? Why does the USB device hold this information?
I guess the main reason is because it was designed that way. The designers could just as easily have gone the other way as you say.
Possibly more helpfully, I can think of a few reasons why they did decide on it this way:
Consider the context in which USB came about. PC peripheral connectivity was a mess. You had serial (UART) ports, PS/2 keyboard & mouse, parallel ports in various modes (e.g. ECP and EPP), game port & MIDI, the various SCSI variants, etc. Most of these did not allow for self-describing devices in a standardised way, demanding custom drivers for each type of device, and mostly manual driver loading. Device descriptors alone would mostly solve the problem of selecting the correct driver, but not necessarily the issue of needing a custom driver for each device.
Various standard device class specifications (e.g. HID, audio) define their own class-specific descriptors for communicating device variations to the standard driver. For this reason alone the generalised descriptor mechanism is useful.
Composite devices in their present form would effectively not be possible without standardised interface descriptors. You'd presumably have to make each composite device act as a hub with multiple devices attached.
Many (most?) standard device class specifications mandate a certain minimum number of endpoints where the standardised protocol is implemented, (e.g. bulk-only USB mass storage defines 1 bulk input and 1 bulk output endpoint) while devices are free to add more for vendor-specific extensions, or…
…future expansion of the standard device class or USB standard itself while maintaining backwards compatibility both ways (old driver/new device, new driver/old device). Think of UASP devices that fall back to regular bulk-only mass storage transport.
While not strictly necessary for making all those things happen, making devices self-describing in this way does seem to have been a success overall.
Are there any USB devices that can be connected with a Linux Softphone?
These USB phones are enumerating as USB composite device: sound device and some control device, usually custom HID.
Audio part should work with virtually any softphone (e.g. command line baresip or pjsua). One I have (EX-03) has not the best sound quality as it supports only 8kHz sampling, but in general they should be fine for telephone calls.
Control part (receiving events from keybord, using ring speaker or display if present) may be tricky to handle as it may be impossible to find any documentation. If you are lucky you may find other software (e.g. skype control software included on CD) that works with this particular USB phone and then use USB sniffer to analyze packets / protocol.
I am trying to transfer the file via libusb to the USB device (pendrive). I have seen submit_bulk_transfer function in libusb-1.0.6 package. If there is a way to transfer the file then can you please suggest me. I want to transfer the file not as raw data.
It is possible, but you will need to implement Mass Storage, SCSI, and the file system that is used on the device in order to do so, which is a lot of work, and it is already done by the USB and FS drivers of all desktop (and many other) OSs.
See libusb FAQ.
BTW submit_bulk_transfer is a very low level functionality of USB, related to many device classes, not only Mass Storage.
Is it feasibly (by feasible, I mean would apple allow) To create a piece of hardware that would allow the USB cable to act as a video input. I have not been able to find anything like this on the market. I know that it's possible to stream video through WIFI locally, but from what I have read it's quite laggy. I also know that in order to create hardware you need a MFi membership, but I'm note even sure if apple would allow this sort of functionality.
Technically, yes it is possible, but in this case for Apple iPhone and iPad is not. USB protocol has a master/slave architecture, for example a Windows PC is the host, while the USB device is the slave. When the USB device is plugged in, the host is informed about the capabilities of the device through the USB descriptor, later the host will request/send abstract USB packets that may be audio, video, files, whatever.
In your case, for iPhone and iPad the host feature is disabled, they may be only clients for other hosts - a PC for instance. It's a marketing decision, because people would be able to buy cheap external storage, instead of more expensive devices or cloud storage. As a consequence your video streaming device which would be a client will not work.
There are two workarounds: one would be to crack Apple iPhone, iPad software, so you cannot build a business on top of it. The second one, would be that your USB video cable to be smart enough (through an embedded controller) to act as a host with the iPhone, iPad, and would a second software on the Apple device to talk with your hardware. It's not so easy, but maybe it worth the effort, who knows...
I know it is the old thread but my answer can be usefull for someone to make further investigation...eventually to provide some schematic, etc. Definitely IT IS POSSIBLE and I have already tried it. The DJI Lightbridge device used mainly for the UAV cameras and video transmission has an USB port and their own aplication for Android/iOS (iPhone) that can transmit the video and to view/record pictures from camera on tablets or phones. The phone acts as FPV monitor in that case. I have used it with the Android tablet and also with the iPhone 5s and it works great!
I have an external device that we manufacture that basically monitors 4 voltages, converts them to a 16 bit digital number then streams this info back to a PC every 100mS or so, using a serial over USB style chip. Basically a data logging system.
We would now like to collect this information on an iPhone and I am wondering what is the best way to get the data into the iPhone?
I am assuming there is no way we can physically connect directly to the iPhone dock connector as the protocol to do this is not available to iOS developers?
Obviously we could do it over a WiFi network but there will not always be one and we want to keep the external hardware fairly simple, i.e. no need for a computer or Wireless router etc.
If we add Bluetooth connectivity to our hardware would this work? I read that only 'Made for iPod' type Bluetooth devices will connect, in which case how can we achieve 'made for iPod' status? It would be relatively easy to add the necessary Bluetooth chips to get the system up and running.
In an ideal world we would like to do this without having to use a 3rd party interface.
I have been thinking about trying to digitise data as an audio signal – like a modem, and send it into the line input jack, but I don’t think it will be fast enough – this would be new territory for me.
Anyway all suggestions gratefully received!
Thanks!