Loop bandwidth of PLL run through USB?

Folks,

Has anyone tried this? I have to lock a PLL around 10kHz into a certain odd phase angle. No problem to do that with a bunch of hardware like usual. If one were to do that with the PC via a USB sound card, the PC could measure the phase angle and then adjust a software tone generator (output via sound card) to always match the phase angle even if stuff in the outside resonant structure changes.

I need the PLL to follow within 10msec or so. Seems like the 1msec USB latency could get in the way. Or is there a trick to circumvent that? Since sound chips have frequency responses up to 22kHZ and rarely hiccup I could imagine there is a way.

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg
Loading thread data ...

I believe usb 2.0 is 125us and usb3.0 possibly less, but I guess it would only apply to high speed and I don't know if any soundcards use that

I think windows will be more of a problem, a timeslice is something like tens of milliseconds

-Lasse

Reply to
Lasse Langwadt Christensen

I don't follow your reasoning, soundcards stream content to/from memory buffers. On USB, I think they do this using "isochronous" USB transfers.

If you can make the buffers short enough, or read/write them at the same time as the USB hardware is it may be possible, with a RTOS.

--
?? 100% natural 

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Reply to
Jasen Betts

Yeah, that's what Lasse was also hinting at. Dang. It would have been too nice ...

It would have to run on Windows because of some other stuff that has to run concurrently.

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

It has to run on Windows. I guess that could jinx the whole idea then.

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

One thing to consider is the buffer length on the PC side and the USB side. That may be well over 10ms of data. For playing and recording audio that is neat because it rarely hickups but for fast feedback its bad.

I recently had to drive a piezo buzzer (a key-beep) directly from a circuit because the audio buffers in an embedded system where so large it took the beep too long to come out of the speaker if it had to be generated by software.

--
Failure does not prove something is impossible, failure simply 
indicates you are not using the right tools... 
 Click to see the full signature
Reply to
Nico Coesel

Windows has Multimedia timers that are more accurate than the standard timers, not sure if it will help.

Cheers

Reply to
Martin Riddle

Normally 10ms for windows.

For a test setup I tried a practical solution in which I needed to test a Modbus RTU device using a Labwindows Timer to trigger a USB to serial device and I got about 1ms jitter, no loss of telegrams.

I prioritized the task for the Labwindows CVI program in the Task Sceduler, but did not test if that really made any difference.

But, for this to work you cannot lauch other programs except if they will be running on another core.

Regards

Klaus

Reply to
Klaus Kragelund

This guy apparently get sub us timing on windows even with running all sorts of heavy applications:

formatting link

Video:

formatting link

Cheers

Klaus

Reply to
Klaus Kragelund

Multimedia timers makes it possible to activate a thread at any millisecond and the activation was well within a millisecond (as measured by the TSC) with light load (no keyboard or mouse activity, blank screen saver) when I tested it on a Pentium II 167 MHz NT4.

However, timing resolution is of interest only if you have to poll inputs cyclically (since DOS style busy waiting not appropriate for multitasking operating system environments), in which the cycle time determines how often the input can be polled.

If the USB hardware generates an interrupt at the end of each USB frame and the kernel mode driver translates this to a waitable object, then the user mode thread could be activated at any time and thus the timer resolution is of no interest.

In most sound application, the sound card must be fed with 200 bytes every millisecond or 2000 bytes every 10 ms, it must be heavily buffered.

Some USB in USB out configuration might work, especially if the PLL processing is done within the USB interrupt service routine, posting the response from within the ISR. However, since the Windows USB driver source code is not generally available, adding the PLL code to the driver gets very hard. In addition the driver structure seems to change at any major version, requiring driver updates every few years.

Reply to
upsidedown

If the oscillator in the phase-locked loop were a DDS chip, where you can m anipulate both phase and frequency digitally, it could be reasonably straig htforward. The messy bit is that it is going to take your sound card an app reciable time to accumulate enough data on the oscillator to which you are locking and the oscillator that you are trying to lock, to let you calculat e your frequency correction, so you probably have to get the frequency pret ty much exactly right before you can start fiddling with the phase - as lon g as the frequencies aren't locked, the desired phase correction will drift with time, and if you don't know precisely when the USB link will dump the phase correction into the DDS chip, you won't be able to get it exactly ri ght.

But you should be able to get close enough for all practical purposes prett y rapidly. As in the old engineer/physicist joke.

--
Bill Sloman, Sydney
Reply to
Bill Sloman

It is definitely cyclical. But ...

... that would throw a major rock into the whole scheme. Maybe I'll habe to do that the old analog way after all.

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

1msec could work, gives us 1kHz update rate in the loop.

That would be no problem. We can specify multi-core processors and the other tasks are all non time-critical. More like file storage, recording, documentation and stuff.

Thanks, that looks interesting. But it seems more than one guy, they have have an ofice in Munich, Germany.

At 00:31 the work "crash" shows up in the middle of the DOS window. I hope this doesn't mean what I think :-)

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

I would do this differently, not via sound card. The oscillator can be controlled via direct register write into a FTDI-sumpthin' chip, and the phase error can be read back the same way. The plant response is a bit sluggish, a few hundred Hz bandwidth. Control response needed to get the PLL to within a few Hertz can be 10-20msec.

It's all doable, I just don't know whether the USB link will hold up.

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

Or, you could just use the +5V from the USB to power the humble CD4046, use the XOR comparator, and with an opamp difference amplifier get it to stabilize at any phase you like (except zero or 180). If you can get stereo from the PC, you could diddle the phase at the PC end digitally, as well, by phase-shifting the left channel versus the right.

Or, (again using stereo outputs) generate sin(wt), and cos(wt) and any phase you can think of is just a linear combination.

sin(wt + A) = sin(wt) cos(A) + cos(wt)sin(A)

which is a simple opamp exercise.

Reply to
whit3rd

The one with Saint Pete and a group of drop-dead-gorgeous naked women?

According to _USB Complete_ the high speed mode of USB 2 supports a maximum polling latency from 125 microseconds to 4.096 seconds.

--
Don Kuenz
Reply to
Don Kuenz

The old 4046 is a bit too noisy for this job. I can roll my own PLL and use a more fancy phase detector chip such as the AD8302. For safety reasons I wanted to avoid having to run active stuff in there. But, I may just have to.

The strange thing is that documents like the Labjack manual state

0.6msec for high-speed USB, for the command/response method of operation (not streaming). That would be enough, provided this really holds in all cases. Even for "modern" operating systems beyond the good old XP, and that's where I have my doubts.
--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

125usec would be great. 4.096sec would be disastrous. Why do they give this wide range? For polling there should be not upper time limit. You are able to poll today, and then again in January 2014.
--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

Allow me to rephrase those specs. The maximum polling latency value is set in units of 125 microseconds. (125, 250, 375, 500, ... 4 096 000 microseconds)

Unfortunately, a closer read of _USB Complete_ reveals that the maximum polling latency is a "suggested" value. Another part of the book confirms what others have already said.

Windows was never designed as a real-time operating system that could guarantee a rate of data transfer with a peripheral. ...

under Windows, no thread can be guaranteed CPU time at a defined, precise rate, such as once per millisecond.

Latencies under Windows are often well under 1 millisecond, but in some cases a thread can keep other code from executing for over 100 milliseconds.

Yet, USB VGA devices somehow squeeze microsecond timing out of Windows.

--
Don Kuenz
Reply to
Don Kuenz

Well, and then there are all the new and not so improved Windows versions. I think I rather not rely on this and put more stuff back into hardware.

We could swing the whole chebang over to QNX, that would solve all this. But that opens us to risks that some specialty app from another manufacturer won't run, just like it would be with Linux.

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.