Computer based spectrum analyzer

[Always_Confused_Sudent]

computer spectrum analyzer

I have to do a computer based spectrum analyzer as a course project, I found an FFT module for visual basic , I wrote a short program to interface the parallel port with ADC , but there's some delay in recieving samples of signals with high frequency , so the samples recieved by computer are kind of random because the CPU might be "busy" for some time while recieving data from parallel port,therefore samples won't represent the real signal , so i thought it would be good if i get a 2k x 8 RAM ie. 6116 to store the samples temporarly so no samples are lost ,and then CPU could read from the RAM , a binary counter is connected to ADC and also connected to the address bus of the memory ,counter will increment at each sample read ,so, the counter output represents the current memory address.

so, does anyone have some ideas to share about this ,and i also need to know a product number of at least 11 bits binray counter.

Thanks! :spoko:

 

[FoxyRick]

vb spectrum analyzer

You are fighting against Windows here. You will certainly need to do buffering for anything fast. The maximum speeds generally quoted for PC parallel ports are 30 to 150 kbyte/s for SPP mode and 800 to 3000 kbyte/s for EPP mode. There is no way you will get this from visual basic in windows.

Two alternatives to more electronics are:

1) Write your own low-level device driver to talk to the port behind window's back

2) Don't use windows! Use DOS and code in TurboC or comething similar.

You don't say what sample rate you want, or what frequency range you want to sample - it would help...

Just my thoughts...

Cheers,
FoxyRick.

 

[Always_Confused_Sudent]

computer based spectrum analyzer

You are fighting against Windows here. You will certainly need to do buffering for anything fast. The maximum speeds generally quoted for PC parallel ports are 30 to 150 kbyte/s for SPP mode and 800 to 3000 kbyte/s for EPP mode. There is no way you will get this from visual basic in windows.

Two alternatives to more electronics are:

1) Write your own low-level device driver to talk to the port behind window's back

2) Don't use windows! Use DOS and code in TurboC or comething similar.

You don't say what sample rate you want, or what frequency range you want to sample - it would help...

Just my thoughts...

Cheers,
FoxyRick.

Yeah , but I think if I try the software methods it will still be limited with parallel port speed , there's no specific frequency range that I aim, I'm trying to get the best thing possible for now, it's a course project, I prefer the idea of buffering using external ram because there won't be limits by parallel port speed or anything else, it also seems easier (to me at least) than writing low-level drivers.

 

[nex]

arm7tdmi processor based spectrum analyzer

Hi,

Search Elektroda for "DSO", I saw there a link to a nice project, you'll find schematic, software and explanation Done thru EPP
Use USB2.0 if want more speed

Cheers !

 

[FANT]

spectrum analyzer vb

Also follow this link:

**broken link removed**

Mandi

 

[HMA]

visual basic spectrum analyzer

EPE had a nice DSO with Spectrum Analyzer ,

Check this :

**broken link removed**

 

[ScratchBuild]

computer based spectrum analyser

Hi HMA,

Do you have a schematic for this project?

Regards

Nic

 

[HMA]

vb 2008 spectrum analyzer

Hi

Here are the schematics :

 

[jhbbunch]

spectrum analyzer visual basic

Have you thought of doing your project with DirectSound (the DirectX interface to the PC soundcard)? You get a circular buffer with read and current write pointers. You can also set a callback function for when a pointer hits a certain spot in the buffer. It samples at 22 or 44 khz or even higher for newer sound cards in 8 or 16 bits, mono or stero. I rewrote a lab for a former instructor that used an ancient ISA 8255 based ADC/DAC IO board for a filter lab. I wrote a dll for getting the data from the soundcard capture, the students wrote the digital filter code in VB and the transformed data was sent out by the dll to the output buffer. Worked great, my old instructor was only too happy to throw the rickety IO antique out.