Simulink has bandwidth?

I interest video processing in Simulink. This is my project: http://www.youtube.com/watch?v=g7wffTa6jyw

I bought a new camera Philips SPC900NC to enhance my project cause of lagging. This camera gives me 640x480@60 FPS or 320x240@90 FPS. I tried VirtualDub video capture program it gives me normal values. But in Simulink; I am editing the camera 640x480@60, 320x240@90, so it gives me 640x480@ 30 FPS or 320x240@60 FPS from Frame Rate Display block at no load. At load decreased more 10-15 FPS.

What is that all about, is that Simulink has bandwidth, how will i solve this?

Regards...

Answer 1

[Walter Roberson]

Simulink doesn't have bandwidth in the way you are thinking.

Simulink accesses devices at normal priority using standard device drivers, and works on the assumption that there are many different things that it might need to do. Programs such as VirtualDub use whatever tricks and advanced features they can, knowing that their only task is to work with one device.

With Simulink acting as a normal program handling multiple tasks, it is subject to standard operating system scheduling rules and to general-purpose interface procedures. Those scheduling rules allow Simulink to be interrupted by (e.g.) anti-virus programs and whatever else is happening, and the interfaces take their time about getting data back and returning control to Simulink. Simulink probably just can't keep up. VirtualDub knows how to hog the system however it can in order to improve performance.

There might be ways to improve the performance you are getting, but you should expect to get rates notably lower than you get with VirtualDub.

[Erçin]

Yes you are right, device has USB 1.1 interface and it is impossible that 1 GB real-time data transfer in 30 seconds. As if it running at USB 2.0 mode, interesting =) I think VirtualDub changes USB Hub bandwidth in a dynamic way. I must find how to change USB Hub's bandwitdh manually. Thank you...

[Walter Roberson]

There isn't any way to change a USB Hub's bandwidth manually, other than perhaps to interfere and force it to go _slower_. USB auto-negotiates the fastest mutually-supported speed.

What _can_ potentially be changed in software is the time-slice reservations. USB is asynchronous but operates in a round-robin fashion, and allows fractions of bandwidth to be reserved. If USB receives a request to transfer that would interfere with a reservation, it turns it down.

There is a possibility that the device is ready to transfer data faster than MATLAB can receive it; there is some buffering that can be done, but if MATLAB is just not able to read the data quickly enough, buffers are going to fill up. If I recall correctly, time-slice reservations have the implicit implication that data that cannot be transfered to the host on the first try is to be dropped; my memory is that reliable data transport is not eligible for time reservations (my memory could be wrong; it has been a while since I read through the documentation.)