Claimed OU circuit of Rosemary Ainslie

[TinselKoala]

And for those innocent spectators out there who may be tempted to believe the lies coming from Rosemary and Aaron:

The LeCroy does indeed have ONE CHANNEL unusable. That's the only reason I haven't used it to do REALTIME power measurements that would blow Rosemary's claims out of the water instantly (as if they already haven't been).

That's why ALL of the LECROY work that I have shown, AS I CLEARLY STATE SEVERAL TIMES IN ENGLISH, all of the LeCroy work that I have shown has been done on the  FULLY FUNCTIONAL CHANNEL of the oscilloscope. The math functions are NOT AFFECTED by the non-functioning input channel. ALL TRACES of the scope are operational.

The math that I show is on STORED TRACES that were both taken from the FULLY FUNCTIONING channel of the scope, and are FULLY VALID AND ACCURATE, they just are not simultaneous and so a nit-picker could legitimately complain about their accuracy for that reason.

It's pretty clear that Rosemary does not understand the difference between a "channel", a "trace", and a "beam" on an oscilloscope. Does Aaron, I wonder?

Rosemary's complaint is like saying I can't drive my car to the grocery store because the spare tire in the trunk is flat. In other words, it's either a willful misundertanding or a lie.

(And as far as the number of samples goes--what part of 500,000,000 sample per second do you not understand? The math on stored traces uses ALL of those samples, so at 2.4 kiloHertz...or even 1.6 MegaHertz for the ring oscillations...well, some of us can follow the math, I hope.  Each single cycle of the ring oscillation is covered by hundreds of samples. At least. Compare this to Rosemary telling MH that 5 or even 6 samples per cycle should be used for accuracy.)

[TinselKoala]

Looks like headers are missing or can't be located or some necessary #define isn't defined. The compiler is complaining about some references to things it doesn't grok. In the second case, the compiler is trying to use an intuitive internal definition and is warning you that what it is doing has a high risk of being wrong (they usually are wrong).

I'll have to bring up my SuSE system again and see where those calls are defined. I don't know whether they come from that libusb or whether they are system calls into the driver. I'll try to look at it in the morning.

You did the "make install" for libusb, right?

Yes, I did and it seemed to work OK--no complaints from compiler-- but I don't know how to tell for sure.

mount says:
null@gershwin:~$ mount | grep usb
procbususb on /proc/bus/usb type usbfs (rw)
usbfs on /dev/bus/usb/.usbfs type usbfs (rw,relatime,devmode=600,busmode=700,listmode=644)
usbfs on /proc/bus/usb/.usbfs type usbfs (rw,relatime,devmode=600,busmode=700,listmode=644)

On plugging in the 8055 usb card, dmesg says:

null@gershwin:~$ dmesg | grep usb
[    0.079588] usbcore: registered new interface driver usbfs
[    0.079611] usbcore: registered new interface driver hub
[    0.079641] usbcore: registered new device driver usb
[    0.877119] usb usb1: configuration #1 chosen from 1 choice
[    0.877917] usb usb2: configuration #1 chosen from 1 choice
[    0.879236] usb usb3: configuration #1 chosen from 1 choice
[    0.879531] usb usb4: configuration #1 chosen from 1 choice
[ 2351.676062] usb 3-2: new low speed USB device using uhci_hcd and address 2
[ 2351.839330] usb 3-2: configuration #1 chosen from 1 choice
[ 2351.948922] usbcore: registered new interface driver hiddev
[ 2351.979215] generic-usb 0003:10CF:5500.0001: hiddev96,hidraw0: USB HID v1.00 Device [Velleman  USB K8055] on usb-0000:00:1d.1-2/input0
[ 2351.979241] usbcore: registered new interface driver usbhid
[ 2351.979246] usbhid: v2.6:USB HID core driver
null@gershwin:~$

I don't know if that's helpful. But at least we know the cable works!

[0c]

Yes, I did and it seemed to work OK--no complaints from compiler-- but I don't know how to tell for sure.

  .
  .
  .
I don't know if that's helpful. But at least we know the cable works!

I've never worked with any USB devices so I'm afraid I won't be much help there. The mount mossages look promising. You will need to install or write an application or test program to determine how well things are actually working. Did the 8055 code come with some sort of test driver?

[fuzzytomcat]

Hi everyone,

Here are some possible suitable substitutions for the MOSFET .....

PDF - International Rectifier - IRFPG50

PDF - Fairchild Semiconductor - FQH8N100C
PDF - Fairchild Semiconductor - FQAF11N90C
PDF - ST Microelectronics - STW9N150

Regards,
Fuzzy

[TinselKoala]

I've never worked with any USB devices so I'm afraid I won't be much help there. The mount mossages look promising. You will need to install or write an application or test program to determine how well things are actually working. Did the 8055 code come with some sort of test driver?

When you say "8055 code" do you mean the stuff that came with the card? Only windblows programs and drivers in there.

The 8055 package that's in the tarball from sourceforge contains a Python directory (Pyk8055) which contains some python GUI apps and example screenshots therefrom. Getting these to work would be considered "success beyond wildest dreams".
The "lib" package is supposed to have the command line tool, and there's a "gui" package in k8055gui_v0.1.tar.gz that is supposed to duplicate the Windows demo GUI which operates all the card's functions.
But of course the command line tool and the GUI both depend on the k8055lib thing to compile and install.

And when you say "You will have to write a program..." surely you are referring to the Papal "you"... My memory is getting to be like Frank's...I can remember FORTRAN IV syntax better than I can c++...but it looks like I actually have a FORTRAN compiler installed so maybe we aren't completely in the twentyfirst century yet...