*If* the USB device is one that that Matlab happens to have a driver for
(which is not generally the case), the a "usb port" on the device would be an
device "endpoint" that the device reported it had along with the properties of
the endpoint. If the properties were recognized, then the Instrument Control
Toolbox might be able to find the endpoint and communicate with it.
But if you just want to plug a random USB device in to your laptop and expect
to be able to communicate with it using whatever session protocol it needs,
then you are most likely to be pretty disappointed. The Instrument Control
Toolbox does not implement a general USB framework, and only directly supports
a very small number of manufacturers, mostly for A/D cards or DIO cards.
If I recall, the Instrument Control Toolbox comes with a small number of
device frameworks to allow you to custom create drivers. I gather that
the generic USB driver is not very sophisticated, so creating your own
driver could potentially take a fair bit of work.
It might help if you described the kind of USB device you are thinking
of; someone might happen to have an idea as to what would be involved in
supporting it.
It is possible and practical for a small number of sensor models, and it
is generally impractical for anything else (unless the sensor is very
close to a supported model, or unless you are very dedicated.)
http://www.mathworks.com/help/toolbox/instrument/f22-57896.html
(Requires a device that supports VISA, Virtual Instrument Standard
Architecture; devices must fall into the class 'agilent', 'tek', or 'ni')
http://www.mathworks.com/help/toolbox/instrument/f15-5937.html
(Requires a device that supports IVI, Interchangeable Virtual Instrument)
Anything else requires writing a generic instrument driver,
http://www.mathworks.com/help/toolbox/instrument/f11-5937.html
Please, it helps a lot if you are more specific about what *kind* of
sensors you want to work with. A particular brand and model would be
great, but even if you were to describe what you needed to do, then
someone might be able to suggest a supported device that can handle
those needs. Writing in intangibles about what can be done in Matlab for
random unspecified USB devices uses up a lot of time, searching out and
enumerating all the possibilities. (I'm looking this stuff up as we go
along -- I've never *used* the Instrument Control toolbox, I've just
seen enough questions about to have some ideas of where to look in the
documentation.)
Hello Vidit,
How you get data into MATLAB depends on what you connect and how you connect to the USB port of your computer.
If you are connecting camera and want data from that, you will need Image Acquisition Toolbox. If you are using an adaptor that does USB to some standard protocol (such as: serial, GPIB, TCPIP etc.) then you need Instrument Control Toolbox. Whereas if you need data from a USB sensor that does not emulate any standard communication protocol, you might want to check out Data Acquisition Toolbox.
Having said that, can you share what exactly it is that you are trying to get data from?
-Ankit
www.desaiankit.com
thank you
Vidit,
I do not have enough insight into workings of USB, all I can point to is wiki (http://en.wikipedia.org/wiki/Universal_Serial_Bus#Data_packets). You might get answer to this question by starting a new thread.
I am aware, however, that there are many adaptors such as USB-to-Serial port and USB-to-GPIB that allows data transfer using Serial/GPIB protocols over a USB port. You will have to check if the device/instrument supports these protocols.
All the best
-Ankit
www.desaiankit.com
There is a USB controller (at the PC usually) that rules which devices get
access and for how long.
USB is a shared bus, meaning that when one device (or the controller) is
sending data, all the other devices receive it as well, and discard it if it
isn't addressed to them. It also means you can never have two devices using
the bus simultaneously: there is no way to interrupt a transfer that is taking
place, no way for a device to say "I'd like to use the bus next, please"
USB is a serial bus. One bit at a time.
USB communications are packeted: they have a distinct format of headers and
trailers and the data might be of varying length.
The USB controller sends out a command addressed to the next device on its
internal list of who needs attention next, and that device responds to the
controller, but only according to the kind of command that was sent. For
example, if the USB controller is going around asking devices to see if they
want to interrupt, it does so one by one and the response can only be "I do
not wish to interrupt" or "I do wish to interrupt, here is my interruption
data" -- and that interrupt data can only be 8 bytes long with USB 1.0 and
1024 bytes long with "high-speed" USB 2.0 connections. Interrupts are for
short exceptional conditions; for example if the device is a disk drive, the
content of the interrupt might be "I have the blocks for read request #423902
ready now", but the transfer of the actual content of the block would have to
wait until the USB controller sent a "Bulk transfer" read request to the device.
There are other kinds of busses (such as Token Ring) in which the decision is
only about which device to be granted access to the bus, and when it is the
device's turn, the device sends whatever it wants to. USB is not like that:
USB devices are restricted to replying to exactly what the controller asked of
them.
Because of the command/response nature of USB and the packetized nature of USB
communications, it is *not* as simple as a device simply waiting until it
recognizes a pulse sequence that signals for its attention, and then the
device dumping raw bits on the line for a while. It is NOT possible with USB
to (for example) negotiate a connection to a A/D converter and then have the
converter pass on data samples for the next (say) 30 minutes. I do not recall
at the moment what the maximum possible packet length is in the best case, but
I do know for example that a "serial port" is restricted to 1023 bytes of data
per packet: anything beyond that would have to be buffered and have to wait
for the next time the USB controller asked for the information.
USB is not designed for "real-time" operation, and it is not designed to
automatically time-stamp data. If the timing of a particular data sample is
important then the device (sensor) will have to provide the time stamp as part
of the data stream. If latency until a sample is received is important, then
USB might not be able to get the sample through in time because of the
structured nature of the communications.
USB has a mode of operation that corresponds roughly to UDP (try to get
packets through, but drop the packet completely if it is taking too long), and
it has a mode of operation that corresponds roughly to TCP (if a problem is
detected in transmitting the packet, drop the packet and say it failed, and
expect the same packet to be re-sent next time around, until finally it gets
through cleanly, and only _then_ go on to the next packet in the queue.)