logo
background
 Home and Links
 Your PC and Security
 Server NAS
 Wargames
 Astronomy
 PhotoStory
 DVD making
 Raspberry Pi
 PIC projects
 Other projects
 Next >>
[Why I needed an Oscilloscope] [What's needed] [Alternative approaches] [Front end options] [Off-the-shelf USB kits] [Other stand-alone kits] [DIY Printer Port PRN: Oscilloscope] [Analogue capture solutions] [Using the dsPIC30F2020]

Why I needed an Oscilloscope

My 5.1 Surround Sound system developed a 'buzz/hum' on the speakers, despite being fed with digital audio input via a TOSLink (optical) cable. Plainly 'something' had gone wrong !

Whilst an analogue signal input 'earth loop' (or insufficient grounding) is the 'prime suspect' when your amplifier starts humming, in this case the use of digital source and (especially) TOSLink cable eliminates all 'earth' issues.

So it has to be the other most common cause - a bad capacitor in the power supply section (especially as 'hum' was of suspiciously low frequency (50Hz perhaps ?) and second it was coming from 'all' the speakers' (so plainly something that was 'common' to all channels i.e. the power supply)

It's well known that electrolytic capacitors have a limited 'life time', especially when driven near their rated voltage (as they will be in a power supply - for example, a 24v power rail will likely have a 30v capacitor = no manufacturer is going to fit a 50v cap. that's double the size (and double the cost)).

So after a decade of absorbing spikes at 2 or 3 times their rated voltage (from mains power glitches, spikes and surges) they will start to loose their 'capacity' - and the most likely result will be a 'buzz/hum' breaking through. Depending to some extent on the design of the PSU, the hum will often be loudest at minimum load (i.e. when 'nothing' is playing).

When my first attempt to 'fix it' failed (I replaced the two physically largest capacitors with something 'equivalent' from my bits box) it was time to start some 'proper' fault finding. This required a means of tracking the buzz/hum backward (easy enough you might think) however to do this properly I needed an Oscilloscope - and that's when I discovered how much these devices are still being sold for, even second hand (on eBay), despite the advent of the 'digital everything' age

So, of course, I decided to make my own

[top]

What's needed

Tracking down a 50Hz 'hum' does not require a clever MHz bandwidth capable piece of kit - in fact 'audio' frequency kit will 'do the job' just fine. The problem is that I will be probing quite high voltages inside the amplifier (perhaps up to +/- 24v)

All PC's (and laptops) already have an 'audio frequency' sampling circuit - the MIC (microphone) input !
 
So 'all' I needed was a couple of probes and an 'input voltage divider' that could be plugged into the MIC socket.

(+) MIC in Oscilloscope

[top]

Alternative approaches

Of course once you have an audio frequency Oscilloscope, chances are, like me, you soon want something 'better' !

Plainly a PC (and not a TV screen) will be used to display the data - so the 'only' thing you need to do is 'capture' the signal i.e. build / assemble some sort of ADC 'front end'

[top]

Front end options

My 'favorite' low-cost project device, the Raspberry Pi (Zero), has no ADC (Analogue to Digital Converter) 'built-in' (although it would make a good 'data capture' device)

You can find ADC 'add on' boards for the Pi ('Pi Hats'), however these are not 'cheap'.
 
Further, Pi i/o is limited to about 4Mbits/s (which is about 500K sps (assuming 8 bit samples) and the Pi Operating System does not 'lend itself' to high speed 'real time' operation (which means that data loss is almost inevitable)
 
The Pi's i/o limitations and lack of 'real time' capability can be heard as drop-outs and jumps by those attempting to use USB audio output 'dongles'

So we have to go for something more 'stand-alone'. The 3 choices are :-

An off-the-shelf USB-dongle based 'kit'
A stand-alone DSP (Digital Signal Processor) chip (eg dsPIC), interfaces to PC LPT (printer port) or RS232 (serial port)
A discrete chip DIY ADC interfaced to PC LPT (printer port) or RS232 (serial port)

[top]

Off-the-shelf USB kits

Most USB Oscilloscope 'dongles' also cost 'an arm and a leg' (many cost more than a second hand 'scope on eBay = see, for example the well advertised 'BitScope', which starts at approx £80 without BNC sockets, probes or even a case !)

However after a bit of poking around, I found one that comes in affordable kit form, the DPScope SE kit, a real bargain at only 41 Euros (£31) with case and BNC sockets included (unlike the 'BitScope', where no case even seems to exist and the BNC sockets are a rip-off £20 "extra")

Ready built versions of the DPScope are also available, as is at least one other kit (20x higher bandwidth, but is more expensive and again lacking a case !)
 
The DPScope offers dual analogue channels (plus ext. trig), with the SE version supporting 50k samples/sec, plus a 4 channel logic analyser (supporting 1M sps), that is all software controlled from the PC. The 'standard' version supports 1M sps, the 'Mk II' 2M sps

For audio frequency work and an 'off the shelf' solution, it's hard to beat the price of the DPScope. Of course, if you want higher bandwidths (and/or relish the challenge of beating the DPScope on price) read on ...

Other stand-alone kits

There is at least one vendor that offers stand-alone LCD Oscilloscopes, both pre-built and in kit form. The main disadvantage is that they all seem to be single channel (or single channel plus trigger), which, after all the work that has gone into designing and building them, seems a real shame

[top]

DIY Printer Port PRN: Oscilloscope

For DOS software, see ScopeOnPC web page (note, in case of DLL error, copy the file inpout32.dll to your system folder for parallel port interface).

For most DIY projects, the USB port is an order of magnitude too difficult to implement and the Serial Port is too slow (but see USB Serial dongles later). The simplest approach is to use the (8 bit parallel) Printer Port. To build a PRN: Oscilloscope then requires a simple analogue DAC stage and some PC based software to capture and display the waveform. No real cleverness is required (the ADC can be clocked from the Parallel Port and input voltage levels set manually by variable resistors ('pots')

Whilst the LPT: hardware 'handshake' is real simple, getting Windows to 'suck in' the data is a little more difficult.
 
Whilst DOS allows direct access to the i/o ports, Windows does not = so you might expect that running the LPT port under Windows would be significantly slower, however that does not seem to be the case.
 
More of an issue with Windows is all the garbage 'services' that MS insists on running in the background (just waiting to 'interrupt' your 'data fetch' routine and cause dropped bytes).
 
The standard Printer Port apparently has a 16 byte pipe-line, however it's unclear how (if) this is used for data input. Also, whilst ECP mode supports DMA, how this is 'driven' is also unclear.
 
So, plainly one thing thats' going to be needed is an in-depth understanding of how to drive the printer port at maximum speeds and no data loss

A DIY analogue stage can be built using discrete chips (Op-amp, ADC's etc) or by using a DSP chip (eg dsPIC)

A separate 'front end' will need a means of transferring the data into the PC

[top]

Analogue capture solutions

The obvious approach is to use a PIC (which turns out to be surprisingly easy to program, using a low cost USB dongle or a DIY 'lash up' from a PC serial port - of which more later)

Most PIC chips come with a built-in ADC - however it's a 'serial conversion' type that 'tops out' at about 500K sps.
 
To get MHz bandwidth we either have to use discrete ADC chips or a 'dsPIC'

[top]

Using the dsPIC30F2020

The dsPIC30F2020 comes in a 28pin SPDIP (with 21 i/o lines) and contains a 2M sps 10bit ADC, thus allowing a 2 channel 1M sps system to be built. Packing 4 samples into 5 bytes means a maximum data rate of 2.5Mbytes/s, which is more or less the maximum possible via the PRN: port

The dsPIC30F2020 has a max. clock rate of 30MHz.
 
Since most instructions are 1 cycle, if we run the ADC at 2M sps we have about 15 instructions 'per sample' to 'off load' the previous sample before the next is 'ready'.
 
To make efficient use of the i/o bandwidth, 4 10bit samples would need to be 'packed' into 5 bytes (40 bits). This means we have 4*15 = 60 instructions to pick up 4 samples whilst outputting 5 bytes (an i/o rate of 2.5M bytes/s)
 
This makes it a bit complex - the 'easy' way would be to write a 120 instruction 'loop' that assembles 2 sets of 4 samples (dual channel) packing them into 2 new 'sets' of 5 bytes whilst at the same time 'unloading' the previous 2 sets of 5 = 10 bytes to the PC PRN: port.
 
To avoid wasting time working out 'which buffer set' is being used for (new) storage and (old) output, we can 'duplicate' the first set of 120 instructions with the buffer addresses 'swapped' over giving us a complete 'loop' of 240 instructions.
 
Once started, the loop would be allowed to 'run forever' (although one of the PIC inputs could be used to generate an interrupt to terminate the loop)

For actual Project designs, see below:

The pages in this topic are :-

  + ADC front end

  + LPT Parallel Port Oscilloscope

  + RS232 PC Serial Port use == Latest changes (modified 29th May 2018 14:41.)


Next page :- ADC front end

[top]