Driver to drive?

[Joerg]

upsidedown@downunder.com wrote:

On Tue, 06 Aug 2013 17:11:26 -0700, Joerg <invalid@invalid.invalid
wrote:

1/4 cycle of 10kHz into a 1MHz DAC is only 25 samples. what size of
LUT do you need?

Since we need to do very fine phase shifts at resolutions of 16bit or so
there would have to be lots of LUT sets or 25 each. Haven't calculated
it but it'll probably be in the thousands. Phase has to be adjusted to
milli-degrees.

While you need a big phase accumulator, say 32 bits for that
resolution, however only a few of the top bits of the phase
accumulator is used to address the LUT and is used to drive the DAC.
Please remember to look at the produced sine wave _after_ the
reconstruction (low pass) filter, the truncated phase and amplitude
values will show up as increased noise levels of the output, put the
phase/frequency resolution is determined by the size of the phase
accumulator.

Noise is what we really can't have in the output.

If you need a smaller LUT, use the highest phase accumulator bits X to
address the element in the LUT and extract some fractional bits x. In
each LUT element in addition to the sin(X) value, there is also stored
one (or more) multipliers a (and b) to be multiplied with the
fractional bits. thus

sin(X.x) is approximated with sin(X) + a*x ( + b*x˛)

This of course assumes hardware single cycle multiply (at least 8x8
bits). This will reduce the LUT table required and hence store the
full cycle, avoiding the quadrant selection.

Without good hardware multiplier, the element specific multiplier a
could be replaced with a shift count, telling how many bits the
fractional bits x should be shifted to right before adding to sin(X).

These are approximate methods, but to get exact values the
trigonometric relationship

sin(X.x) = sin(X)cos(x) + cos(X)sin(x)

Requiring four LUTs, two multiplys and one addition.

Note that for small values of x, sin(x) is quite close to x when
expressed in radians and cos(x) for small values for x is quite close
to 1, some simplifications can be done.

A HW multiplier wouldn't be a big deal anymore, these days even some of
the cheaper MSP430's have it. I know one guy who had the uC calculate
most of what would normally in the LUT, on the fly, all the time.
Because memory space is the typical constraint.

So far it looks like I'll do it in an analog fashion, at least initially.

--
Regards, Joerg

http://www.analogconsultants.com/

 

[DecadentLinuxUserNumeroUn]

On Thu, 08 Aug 2013 12:34:30 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

On 08/08/2013 12:17 PM, DecadentLinuxUserNumeroUno wrote:
On Thu, 08 Aug 2013 11:43:07 GMT, Jan Panteltje
pNaonStpealmtje@yahoo.com> wrote:


On a sunny day (Thu, 08 Aug 2013 11:24:00 +0100) it happened Syd Rumpo
usenet@nononono.co.uk> wrote in <ktvrjq$i9j$1@dont-email.me>:

On 08/08/2013 10:28, DecadentLinuxUserNumeroUno wrote:
On Thu, 08 Aug 2013 08:35:19 GMT, Jan Panteltje

snipped

http://xkcd.com/1235/

Cheers

I like this too:
http://xkcd.com/1240/

Pretty much, one can safely ignore petty dipshits who spend their time
perusing xkcd. Seems you are worse than (the) dogs.

Have anything intelligent to respond with, you total fucking jackass?


Oh, dear, looks like the bar at the end of the universe opened up again.

Cheers

Phil Hobbs

Alright then... explain to me what these jackases were eluding to with
their retarded, unexplained horseshit attempts at using someone else's
humor to make a jab at me.

WTF was their pathetic goal?

I thought I was offering a reasoned response regarding *my* experience
with it, and making for discussion of the post the jaNTaRD made.
their responses were infantile, at best, when the group could be
discussing the actual topic of the tread.

So, if you are on their side, Mr. Hobbs, you can fuck off and die right
along with them.

Oh, dear indeed. somebody needs to grow the fuck up, and it isn't me.

 

[mike]

On 8/8/2013 9:57 AM, DecadentLinuxUserNumeroUno wrote:

Alright then... explain to me what these jackases were eluding to with
their retarded, unexplained horseshit attempts at using someone else's
humor to make a jab at me.

Nobody needs to take jabs at you.
You are skilled at doing that all by yourself.

Very interesting choice of words.
"(an idea or fact) Fail to be grasped or remembered by (someone)."
And spot on.
;-)

 

[Robert Baer]

Joerg wrote:

Jasen Betts wrote:
On 2013-07-16, Joerg<invalid@invalid.invalid> wrote:

If you are phase locking to some existing sine waves, you need the
quadrature Q signal by doing 90 degree phase locking. After that, any
phase shift from the Q signal can be generated by adding the suitable
phase shift to the main phase accumulator.

The essence of the task is this: A generator sends a sine wave of around
10kHz into a reactive network. This network causes a phase shift
(current versus voltage, like a power factor) but that is not totally
known because the exact RLC values in the reactive network are not
known. I want to keep that phase shift constant.

So you need to shift it thr rest of 180 degrees and feed it back
inverted?


No, I'd have to keep the phase shift at a certain value and that phase
delta value can change at any time. So it could be 87.35 degrees one
second, 87.42 degrees the next and 92.73 degrees a minute later. All
with a spiffy clean sine wave.

Foistly, one cannot create a specific phase shift without knowing the

frequency.
Secondly, a USB channel is extremely un-reliable and unstable:
depends on CPU loading of all other USB channels, specs (1.0 thru 3.?)
and Gates knows what else.
Use two paddles and a ping-pong ball..

 

[Joerg]

Robert Baer wrote:

Joerg wrote:
Jasen Betts wrote:
On 2013-07-16, Joerg<invalid@invalid.invalid> wrote:

If you are phase locking to some existing sine waves, you need the
quadrature Q signal by doing 90 degree phase locking. After that, any
phase shift from the Q signal can be generated by adding the suitable
phase shift to the main phase accumulator.

The essence of the task is this: A generator sends a sine wave of
around
10kHz into a reactive network. This network causes a phase shift
(current versus voltage, like a power factor) but that is not totally
known because the exact RLC values in the reactive network are not
known. I want to keep that phase shift constant.

So you need to shift it thr rest of 180 degrees and feed it back
inverted?


No, I'd have to keep the phase shift at a certain value and that phase
delta value can change at any time. So it could be 87.35 degrees one
second, 87.42 degrees the next and 92.73 degrees a minute later. All
with a spiffy clean sine wave.

Foistly, one cannot create a specific phase shift without knowing the
frequency.

The base frequency is known, several keelohoitz. It is being determined
from a measurement and then either looked up in a table or (once I get
around to some serious math heavy-lifting) calculated.

Secondly, a USB channel is extremely un-reliable and unstable: depends
on CPU loading of all other USB channels, specs (1.0 thru 3.?) and Gates
knows what else.

Well, that's essentially what I wanted to find out here. How many
milliseconds max is "extremely"? Assuming that the PC does nothing else
in that time other than the usual Windows trundling. Maybe a mouse
movement once in a while.

Use two paddles and a ping-pong ball..

--
Regards, Joerg

http://www.analogconsultants.com/

 

[DecadentLinuxUserNumeroUn]

On Thu, 08 Aug 2013 14:05:29 -0700, Joerg <invalid@invalid.invalid>
wrote:

Robert Baer wrote:
Joerg wrote:
Jasen Betts wrote:
On 2013-07-16, Joerg<invalid@invalid.invalid> wrote:

If you are phase locking to some existing sine waves, you need the
quadrature Q signal by doing 90 degree phase locking. After that, any
phase shift from the Q signal can be generated by adding the suitable
phase shift to the main phase accumulator.

The essence of the task is this: A generator sends a sine wave of
around
10kHz into a reactive network. This network causes a phase shift
(current versus voltage, like a power factor) but that is not totally
known because the exact RLC values in the reactive network are not
known. I want to keep that phase shift constant.

So you need to shift it thr rest of 180 degrees and feed it back
inverted?


No, I'd have to keep the phase shift at a certain value and that phase
delta value can change at any time. So it could be 87.35 degrees one
second, 87.42 degrees the next and 92.73 degrees a minute later. All
with a spiffy clean sine wave.

Foistly, one cannot create a specific phase shift without knowing the
frequency.


The base frequency is known, several keelohoitz. It is being determined
from a measurement and then either looked up in a table or (once I get
around to some serious math heavy-lifting) calculated.


Secondly, a USB channel is extremely un-reliable and unstable: depends
on CPU loading of all other USB channels, specs (1.0 thru 3.?) and Gates
knows what else.


Well, that's essentially what I wanted to find out here. How many
milliseconds max is "extremely"? Assuming that the PC does nothing else
in that time other than the usual Windows trundling. Maybe a mouse
movement once in a while.


Use two paddles and a ping-pong ball..

Look, dingledorfs. Ha! If even USB2.0 can read hi-res mouse events
on 2400 dpi gaming mice and track well. I think it can handle some
pretty fast sample and response loop rates.

And 3.0 will only make that better, and I am sure someone will find a
way to establish a "bonded link" type USB 'hub' or 'base engine' for
which a proprietary device could hook into. Like taking over a 2.0
stylized link, but the PCIe card you plug in keeps the channel and the
polling over the bus open at all times, which most current USB setups do
not because they allow sleeping modes. Then you only plug *your* gear
into it.

I'll bet some pretty good stuff can be drummed up, if there is a
demand. Lots of more dedicated link type competition already in place
though.

 

[Joerg]

DecadentLinuxUserNumeroUno wrote:

On Thu, 08 Aug 2013 14:05:29 -0700, Joerg <invalid@invalid.invalid
wrote:

Robert Baer wrote:
Joerg wrote:
Jasen Betts wrote:
On 2013-07-16, Joerg<invalid@invalid.invalid> wrote:

If you are phase locking to some existing sine waves, you need the
quadrature Q signal by doing 90 degree phase locking. After that, any
phase shift from the Q signal can be generated by adding the suitable
phase shift to the main phase accumulator.

The essence of the task is this: A generator sends a sine wave of
around
10kHz into a reactive network. This network causes a phase shift
(current versus voltage, like a power factor) but that is not totally
known because the exact RLC values in the reactive network are not
known. I want to keep that phase shift constant.
So you need to shift it thr rest of 180 degrees and feed it back
inverted?

No, I'd have to keep the phase shift at a certain value and that phase
delta value can change at any time. So it could be 87.35 degrees one
second, 87.42 degrees the next and 92.73 degrees a minute later. All
with a spiffy clean sine wave.

Foistly, one cannot create a specific phase shift without knowing the
frequency.

The base frequency is known, several keelohoitz. It is being determined
from a measurement and then either looked up in a table or (once I get
around to some serious math heavy-lifting) calculated.


Secondly, a USB channel is extremely un-reliable and unstable: depends
on CPU loading of all other USB channels, specs (1.0 thru 3.?) and Gates
knows what else.

Well, that's essentially what I wanted to find out here. How many
milliseconds max is "extremely"? Assuming that the PC does nothing else
in that time other than the usual Windows trundling. Maybe a mouse
movement once in a while.


Use two paddles and a ping-pong ball..



Look, dingledorfs. Ha! If even USB2.0 can read hi-res mouse events
on 2400 dpi gaming mice and track well. I think it can handle some
pretty fast sample and response loop rates.

So how much is "some pretty fast"?



--
Regards, Joerg

http://www.analogconsultants.com/

 

[Syd Rumpo]

On 08/08/2013 17:57, DecadentLinuxUserNumeroUno wrote:

I thought I was offering a reasoned response regarding *my* experience
with it, and making for discussion of the post the jaNTaRD made.
their responses were infantile, at best, when the group could be
discussing the actual topic of the tread.

There, there, don't cry, Jesus loves you.

Everybody else thinks you're a prick.

Cheers
--
Syd

 

[Snackuli]

On 08/08/2013 09:57 AM, DecadentLinuxUserNumeroUno wrote:

Alright then... explain to me what these jackases were eluding to with
their

'Elude' means to escape, avoid the grasp of.
eg., like the meanings of 'allude' and 'elude' elude you.

 

[Joe Chisolm]

On Thu, 08 Aug 2013 11:59:05 -0700, DaveC wrote:

I need one of these:

http://tinyurl.com/lzvf2hw

It's a low-profile smd type DDR3 SODIMM socket for laptop use with those
little metal spring-release tabs.

I need one with 4 mm total height. All the ones I can find are 5-plus
mm. I've seen 4 mm parts in manufacturer datasheets but can't find any
US distributors.

And it needs to be standard orientation flavor (key right-of-center,
relative to user's view when inserting the SODIMM).

That last point is glossed-over pretty easily by even product drawings:
as far as I can determine these come in both orientations: the two types
are identical except that the polarity key is right- or left-of center.
I think the "standard" model is right-of-center key.

Mouser has only vertical orientation sockets (a la desktop motherboard).
Digi-Key has the correct type but wrong key location (reverse style).

Sources?

Thanks.

This might work:
http://www.digikey.com/product-detail/en/78194-0001/WM19149-ND/2046762

Digikey does not stock but they say minimum order is 1. Standard package
is 16 so you might have to buy 16. I have ordered different non-stock
connectors from Digikey with no problems. Wanted 10 for a special
project. Got it in 3 weeks.

--
Chisolm
Republic of Texas

 

[DaveC]

This might work:
http://www.digikey.com/product-detail/en/78194-0001/WM19149-ND/2046762

Digikey does not stock but they say minimum order is 1. Standard package
is 16 so you might have to buy 16. I have ordered different non-stock
connectors from Digikey with no problems. Wanted 10 for a special
project. Got it in 3 weeks.

That does look good.

It's now obsoleted by Molex but Digi-Key crossed it to this TE part:

http://www.digikey.com/product-detail/en/2-2013022-2/A111119CT-ND/4142503

and it will work for me.

Thanks for the pointer.

Have a great weekend.

 

[josephkk]

On Thu, 08 Aug 2013 15:08:11 -0700, Joerg wrote:

Look, dingledorfs. Ha! If even USB2.0 can read hi-res mouse
events
on 2400 dpi gaming mice and track well. I think it can handle some
pretty fast sample and response loop rates.


So how much is "some pretty fast"?

No guessing needed, you can get the standards for free online. That is
how i got them. Straight from the USB consortuim themselves.

?-)

 

[Jasen Betts]

On 2013-08-07, Joerg <invalid@invalid.invalid> wrote:

Jasen Betts wrote:
On 2013-07-16, Joerg <invalid@invalid.invalid> wrote:
Tim Wescott wrote:
On Mon, 15 Jul 2013 14:11:34 -0700, Joerg wrote:

Tim Wescott wrote:
On Sun, 14 Jul 2013 08:19:09 -0700, Joerg wrote:

Yeah, I've looked at the Cypress PSoC for that. The bigger ones can do
it without redlining. Probably some others as well. But I'd need someone
to do the uC coding, that's really not my turf.

Another option would be to use the 4046 as Whit3rd mentioned. But this
would need to be heavily filtered to make a nice sine, or followed by a
DDS module where the 4046 acts as a reference. Also, the XOR results in
a frequency-dependent phase error which I can't have. So I'd have to
plop a PID between that and the VCO to get rid of the phase error.
Possible, but gets busy. However, someone wrote that one don't need no
Ph.D. for a PID
Getting a clean all-analog solution certainly seems harder than a clean
solution built around a micro. It sounds like you need a fairly clean
sine wave, though, which means that any solution with a microprocessor in
the middle would have to have a nice DAC, and probably filtering and
buffering.

The uC would be breaking a sweat. In order to obtain a clean sine wave
at 10kHz it has to either pump data into a port with lots of R2R at more
than 1MHz or pump the data into a DAC at the same clip. The data could
either come from a 1/4-cycle LUT (gets pretty big) or be calculated
on-the-fly (even more sweat beads). Then it has to handle all the loop
response stuff, some USB, some housekeeping.


1/4 cycle of 10kHz into a 1MHz DAC is only 25 samples. what size of
LUT do you need?


Since we need to do very fine phase shifts at resolutions of 16bit or so
there would have to be lots of LUT sets or 25 each. Haven't calculated
it but it'll probably be in the thousands. Phase has to be adjusted to
milli-degrees.

hmm, yeah, with an 8 bit dac you can represent 25600 distict evenly spaced
phases of 10kHz square-wave on that setup. I guess the sine-wave
potential woukd be similar.

There's this guy did a Cordic DDS (on an MSP430 iirc) that might be a
better fit if you do need lots of samples

--
⚂⚃ 100% natural

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

 

[Joerg]

Jasen Betts wrote:

On 2013-08-07, Joerg <invalid@invalid.invalid> wrote:
Jasen Betts wrote:
On 2013-07-16, Joerg <invalid@invalid.invalid> wrote:
Tim Wescott wrote:
On Mon, 15 Jul 2013 14:11:34 -0700, Joerg wrote:

Tim Wescott wrote:
On Sun, 14 Jul 2013 08:19:09 -0700, Joerg wrote:

Yeah, I've looked at the Cypress PSoC for that. The bigger ones can do
it without redlining. Probably some others as well. But I'd need someone
to do the uC coding, that's really not my turf.

Another option would be to use the 4046 as Whit3rd mentioned. But this
would need to be heavily filtered to make a nice sine, or followed by a
DDS module where the 4046 acts as a reference. Also, the XOR results in
a frequency-dependent phase error which I can't have. So I'd have to
plop a PID between that and the VCO to get rid of the phase error.
Possible, but gets busy. However, someone wrote that one don't need no
Ph.D. for a PID
Getting a clean all-analog solution certainly seems harder than a clean
solution built around a micro. It sounds like you need a fairly clean
sine wave, though, which means that any solution with a microprocessor in
the middle would have to have a nice DAC, and probably filtering and
buffering.

The uC would be breaking a sweat. In order to obtain a clean sine wave
at 10kHz it has to either pump data into a port with lots of R2R at more
than 1MHz or pump the data into a DAC at the same clip. The data could
either come from a 1/4-cycle LUT (gets pretty big) or be calculated
on-the-fly (even more sweat beads). Then it has to handle all the loop
response stuff, some USB, some housekeeping.

1/4 cycle of 10kHz into a 1MHz DAC is only 25 samples. what size of
LUT do you need?

Since we need to do very fine phase shifts at resolutions of 16bit or so
there would have to be lots of LUT sets or 25 each. Haven't calculated
it but it'll probably be in the thousands. Phase has to be adjusted to
milli-degrees.

hmm, yeah, with an 8 bit dac you can represent 25600 distict evenly spaced
phases of 10kHz square-wave on that setup. I guess the sine-wave
potential woukd be similar.

There's this guy did a Cordic DDS (on an MSP430 iirc) that might be a
better fit if you do need lots of samples

You can do it even without Cordic, one guy always calculated all this
stuff anew, on the fly. Luckily ALU cores do not suffer from
perspiration and muscle cramps. But that can easily interfere with other
realtime routines that have to run.

Luckily, there's also an analog way

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Joerg]

josephkk wrote:

On Thu, 08 Aug 2013 15:08:11 -0700, Joerg wrote:


Look, dingledorfs. Ha! If even USB2.0 can read hi-res mouse
events
on 2400 dpi gaming mice and track well. I think it can handle some
pretty fast sample and response loop rates.


So how much is "some pretty fast"?



No guessing needed, you can get the standards for free online. That is
how i got them. Straight from the USB consortuim themselves.

I have the 2.0 standard. Says on page 21, quote "Although an explicit
timing rate is not required, interactive data may have response time
bounds that the USB must support" and later "The USB is also designed
for minimal delay of isochronous data transfers".

So how many milliseconds is "may have" and "minimal"?

--
Regards, Joerg

http://www.analogconsultants.com/

 

[DecadentLinuxUserNumeroUn]

On Sat, 10 Aug 2013 08:06:18 -0700, Joerg <invalid@invalid.invalid>
wrote:

josephkk wrote:
On Thu, 08 Aug 2013 15:08:11 -0700, Joerg wrote:


Look, dingledorfs. Ha! If even USB2.0 can read hi-res mouse
events
on 2400 dpi gaming mice and track well. I think it can handle some
pretty fast sample and response loop rates.


So how much is "some pretty fast"?



No guessing needed, you can get the standards for free online. That is
how i got them. Straight from the USB consortuim themselves.


I have the 2.0 standard. Says on page 21, quote "Although an explicit
timing rate is not required, interactive data may have response time
bounds that the USB must support" and later "The USB is also designed
for minimal delay of isochronous data transfers".

So how many milliseconds is "may have" and "minimal"?

Add up the knowns and add some expected overhead amount.

The PCI bus is what the USB hub is tertiary to. I don't see many
delays being instilled there.

Install a USB 3.0 PCI card and design around the new spec, not the
dying, being abandoned by designers as we speak old 2.0 spec.

Find a way to hack and use an old video card to do the task. it would
likely be ideal, considering the way GPUs process, and access the
extremely fast video RAM. That would be what I would want to do. Design
such a test tool/device around the NVIDA GPU core. It would be perfect
for a lot of applications. One could even hack and use the HDMI port for
the bench level test probes, etc.

 

[Joerg]

DecadentLinuxUserNumeroUno wrote:

On Sat, 10 Aug 2013 08:06:18 -0700, Joerg <invalid@invalid.invalid
wrote:

josephkk wrote:
On Thu, 08 Aug 2013 15:08:11 -0700, Joerg wrote:


Look, dingledorfs. Ha! If even USB2.0 can read hi-res mouse
events
on 2400 dpi gaming mice and track well. I think it can handle some
pretty fast sample and response loop rates.


So how much is "some pretty fast"?


No guessing needed, you can get the standards for free online. That is
how i got them. Straight from the USB consortuim themselves.

I have the 2.0 standard. Says on page 21, quote "Although an explicit
timing rate is not required, interactive data may have response time
bounds that the USB must support" and later "The USB is also designed
for minimal delay of isochronous data transfers".

So how many milliseconds is "may have" and "minimal"?


Add up the knowns and add some expected overhead amount.

<nitpick_mode>

How many msec is "some"?

</nitpick_mode>

The PCI bus is what the USB hub is tertiary to. I don't see many
delays being instilled there.

Install a USB 3.0 PCI card and design around the new spec, not the
dying, being abandoned by designers as we speak old 2.0 spec.

It may also have to work on laptops but those come with USB 3.0 these
days as well. Still, I'd need to know the worst case response delay. If
the routine fails once in a blue moon it'll be a nuisance, if it would
fail for a few seconds that could be major.

The devices (uC and such) to be connected would likely run in a slow USB
2.0 mode, they can't do 3.0. The data rates are very low and only the
round-trip response latency counts.

Find a way to hack and use an old video card to do the task. it would
likely be ideal, considering the way GPUs process, and access the
extremely fast video RAM. That would be what I would want to do. Design
such a test tool/device around the NVIDA GPU core. It would be perfect
for a lot of applications. One could even hack and use the HDMI port for
the bench level test probes, etc.

Hacks won't fly in the product. I'd like to go straight towards the product.

--
Regards, Joerg

http://www.analogconsultants.com/

 

[DecadentLinuxUserNumeroUn]

On Sat, 10 Aug 2013 09:14:00 -0700, Joerg <invalid@invalid.invalid>
wrote:

The devices (uC and such) to be connected would likely run in a slow USB
2.0 mode, they can't do 3.0. The data rates are very low and only the
round-trip response latency counts.

Then make the actual loop response circuit remain outside the PC, with
the probes, and make the USB part simply a monitoring and control
interface for the fast response, locally attached loop control circuits.

Pretty much making the PC no more than a KVM device, as it were. which
is how this should be approached anyway.

I see some very fast, accurate devices attached and controlled by slow,
*very old* GPIB interfaces all the time. Because they do not rely on the
GPIB bus being *in* the control loop. It is merely for the monitoring,
control, and oversight interface, and the slow port speed does not affect
the speed at which the device control processes its received data
stream(s).

 

[DecadentLinuxUserNumeroUn]

On Sat, 10 Aug 2013 09:14:00 -0700, Joerg <invalid@invalid.invalid>
wrote:

Find a way to hack and use an old video card to do the task. it would
likely be ideal, considering the way GPUs process, and access the
extremely fast video RAM. That would be what I would want to do. Design
such a test tool/device around the NVIDA GPU core. It would be perfect
for a lot of applications. One could even hack and use the HDMI port for
the bench level test probes, etc.


Hacks won't fly in the product. I'd like to go straight towards the product.

A hack is a development tool. the proto. the actual design would be
in concert with the boys at NVidia.

 

[Joerg]

DecadentLinuxUserNumeroUno wrote:

On Sat, 10 Aug 2013 09:14:00 -0700, Joerg <invalid@invalid.invalid
wrote:

The devices (uC and such) to be connected would likely run in a slow USB
2.0 mode, they can't do 3.0. The data rates are very low and only the
round-trip response latency counts.


Then make the actual loop response circuit remain outside the PC, with
the probes, and make the USB part simply a monitoring and control
interface for the fast response, locally attached loop control circuits.

Sure, that's the old-fashioned way. But the reason for posting my
question was to find out how far one can reassonably push USB latency.

Pretty much making the PC no more than a KVM device, as it were. which
is how this should be approached anyway.

Not necessarily. There is a surprising trend towards moving more and
more of the signal processing and interactive stuff into the PC.
Software-defined radios and so on. They aren't there yet but have come a
long way since the days when the PC was merely a glorified speaker and
display.

I see some very fast, accurate devices attached and controlled by slow,
*very old* GPIB interfaces all the time. Because they do not rely on the
GPIB bus being *in* the control loop. It is merely for the monitoring,
control, and oversight interface, and the slow port speed does not affect
the speed at which the device control processes its received data
stream(s).

That's how we did it in the 80's

Seriously, in the 90's we already did ultrasound machine designs where
the PC became an integral part of the engine. However, that went
directly via the PC bus and we re-wrote some parts of the OS kernel.

This time it should be USB because it makes us hardware-independent. The
NVidia avenue or similar custom designs would not be so great for us
because then some smaller netbooks would no longer be feasible.

--
Regards, Joerg

http://www.analogconsultants.com/