Test and Measurement Forum

Hi Matt, Norbert and all,

Norbert's post is very interesting. I was really excited; finally a solution to our XP problem. With much anticipation I clicked on the vmware site, read about this product and decided this was a "must have". But the price stopped me cold in my tracks. I am sure this is a very fine product and worth every penny to those who can fully utilize its capabilities. I simply cannot afford this solution. Norbert I am happy for you that your ADC-212 is working on your XP machine but I will have to wait for a more enonomical approach. I am hoping that PICO is working the problem and that a software revision will be forthcoming in the near future. In the meantime I will have to be content with using my old 90MHz P1 which in some cases means dragging it home (200 + miles) from our vacation cottage where it has been relagated to e-mail duty.

Hoping,
Rod

PS I also took the machine and scope to a computer repair shop thinking an expert could certainly make it work. After trying many configuration approaches he also gave up ($60.00 labor charges).

Hi,

After several tests the problem finally located, although the reason is very strange.

At first, it must be noted that my motherboard (P4G8X) is running in dual channel DDR configuration. This means that rising the FSB speed with standard DDR333 memories is highly possible keeping 100% stability. In addition, the AGP/PCI speed can be locked to default ratio, thus rising the FSB affects only the CPU and memory.
I've been using FSB155 instead of the standard 133MHz for months, without any problem. All benchmarks, games and application were rock stable at all time.

But, when I launch PicoScope, it reports communication failure when the FSB is set any higher than 146MHz.
This is strange, I really can't imagine how the parallel port can be affected by the FSB settings. Besides, as I mentioned earlier, other applications (such as VMware) are able to use the LPT port regardless of the FSB value.
It seems, the timings in the communication protocol of Pico sw. somehow very sensitive, would be good to check is there any way to improve this.

To test the maximum throughput of parallel port handled by Pico, I recorded 5000 samples @ 1ms, on two channels.
At FSB133 the recording time is 13790ms while at 146MHz it is 13463ms.
I've been playing with other settings as well (LPT mode is BIOS, LPT irq handling in WinXP) but they didn't make any difference.
To be honest, I expected much better throughput. This is 2x 372 samples per sec, which is 118 times slower than what a basic sound card can do!!
Because of this, I can't use PicoLog to capture and analyse longer non-periodic signals, like communication protocols.

I hope there will be an USB version of ADC, which could solve all the issues described above, and even more.

Best Regards,
/Norbert

Ps. I don't know whether Rod's system has the same problem due to overclock, but restoring the factory values in bios seems to be a good idea. Anyway, I hope that it will be ok soon.

Hi Norbert,

Thanks for the diagnostic info ... it seems like you've found the solution.

The reason we can't get very fast updates on the Pico units in Real-time mode is that we are heaviliy reliant on the kernel/windows update speed (XP can be particularly slow since it doesn't allow direct control over the parallel port, Win98/Me on the otherhand is very good with our products).

However, in fast-block mode (where the screen doesn't need to be updated regularly) we can achieve far higher sampling rates and the operating system shouldn't make much difference.

Best Regards,

Hi Matt,

Fast block mode is indeed fast, but there are two things why that can't be an option for me:
- Works only with one channel (or can it be changed?)
- Record length of samples can not exceed the buffer size, which is very limited for my application. In repetitive mode there are 'lost' samples.

So the parallel port is the limiting factor under XP. But isn't ECP+EPP mode supposed to be faster due to DMA usage (if supported by application)?

Best Regards,
/Norbert

Hi,

Fast block mode can use more than one channel, but it is limited to the buffer size or the unit ... and by the application. The ADC-2xx series are not designed as data-loggers, they are oscilloscopes - we simply extend their functionality with PicoLog for convenience.

Our hardware supports our own transfer protocol for speed optimisation, so we don't need to rely on ECP or EPP.

Best Regards,