Hi again,

sorry for cluttering this forum with my "data". Forget the last two reports.

The reason for this strange behaviour is that there are CRC errors on the USB bus which are not detected in the case of high speed. In full speed they are passed to my driver and my driver takes the last valid measurement. In high speed however, my driver doesn't get the CRC error from the usb-core and therefore the sine wave looks a bit "dented". :-)

I'll look into the CRC detection in high speed.

/Bernd



Bernd Porr wrote:
Hi all, again,

some more data to add:

I've also run an acquisition with double buffering (high speed, 2.6.2-rc3). There's another pattern:

1 -0.687168
2 -0.157038
3 0.119029
4 0.401098 *
5 0.685167
6 0.401098 *
7 0.973238
8 1.255306
9 1.533374 *
10 1.801440
11 1.533374 *
12 2.059503
13 2.299561
14 2.521616 *
15 2.721664
16 2.521616 *
17 2.895707
18 3.041743
19 3.161772

Again, the input signal is a sine. Every number is a usb frame with data behind here.

My driver? The ISO patch?

/Bernd

Bernd Porr wrote:

This seems to be a new problem.

ISO transfer, quad buffering (4 URBs), high speed:

I suspect that I get old data from one of the four 4 urbs in the
completion handler. As some of you know I do data acquision via the usb.
The data is a sine wave in this case. It looks like that:

1 -0.891218
2 -1.175287
3 -0.281069
4 -1.445353 *
5 -1.691413
6 -1.913467
7 -2.111516
8 -1.445353 *
9 -2.271555 %
10 -2.403587
11 -2.499610
12 -2.561625
13 -2.271555 %
14 -2.585631 &
15 -2.577629
16 -2.531618
17 -2.453599
18 -2.585631 &

The first number is the usb frame and the second one the data. I've
marked the data which is the same. I do quad buffering and there's a
strange repetition of the data which happens every 4 ms.

The firmware code is the same for high- and full
speed. In the driver also the same code is used for high- and full speed.

In full speed it looks different:

1 2.503611
2 2.909710 *
3 2.909710 *
4 3.243792 &
5 3.243792 &
6 3.505856
7 3.505856
8 3.675897
9 3.675897
10 3.755917
11 3.755917
12 3.747915
13 3.747915
14 3.649891
15 3.649891
16 3.473848
17 3.473848
18 3.221787
19 3.221787
20 2.907710

In this case the adjacent data is doubled.

This all might be a problem of my driver but its funny that I get two different patterns of data through the same driver/firmware code.

/Bernd




------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel



------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to