Low-cost Picaxe based scope anybody?

Hi all,

since there have been several threads from people looking for a usable low-cost oscilloscope, I thought why not design something myself. Before I fully commit I'd like to gauge the interest for such a thing.

Top-goals would be

• very low-cost - I shoot for well below US$50 for a DIY 2-channel version. Meeting that will require getting some chips as samples from the manufacturer (not too difficult).
• hobbyist-friendly, i.e. no difficult-to-get components, no surface mount parts (DIP and through-hole only), no expert tools or software required, not too complex design - yes it can be put together on a breadboard (Stan will be in heaven!) or a protoboard if you don't want to spend money on a "real" printed circuit board.
• reasonable performance (don't expect GHz, but it should handily beat soundcard based solutions)
• Picaxe based (what else! ); connection to PC through standard serial download cable. Display and control is done on the PC. Of course you could use USB with the Rev-Ed serial-to-USB converter.

In fact, I have the ADC and the sampling control breadboarded already, and I have a good idea for the analog frontend (pre-amplifier, trigger circuit).

So far it looks like it will be 1 MHz maximum sample rate (so good enough for analog signals up to >100 kHz, more if you don't care about the exact waveform; don't confuse sample rate with analog bandwidth, without interpolation the rule of thumb is that the sample rate should be about 10x the bandwidth for accurate representation of the waveform), +/-12V max. input range, record length 250 points, all driven by a Picaxe 28X1 and a few standard 74xx logic circuits. Record length and number of channels would be easy to increase. (with 250 points each on 2 channels I expect about 4-5 frames/sec screen update rate. not quite analogish feeling but still usable. With more channels or longer record length accordingly less).

I'd release the schematic, layout, parts list and the PC scope software source and executable (for display and control, yet to write) as public domain, so anybody could do his/her own scope. If interest warrants, I may offer fully assembled units at about cost.

So let me know if that sounds interesting or if I shall rather spend my time on something else!

womai said:

reasonable performance (don't expect GHz, but it should handily beat soundcard based solutions) ... So far it looks like it will be 1 MHz maximum sample rate

Click to expand...

I presume you're using some RAM chip or FIFO plus hardware to capture samples into as you'll not be able to get the PICAXE to sample every 1uS using Basic programming.

i would give some consideration to the pic18f4550
it's got a usb2.0 module built in and can run at up to 48mhz

the usb side if it isn't very hard to get going either i've managed in an afternoon

Perhaps a FT2232C or similar chip to handle USB? The FT232RL was easy to setup and use on a breadboard (using a SMD carrier board) but as far as I know, the FT2232C supports a parallel interface which potentially allows an even higher data throughput using the FTDI drivers than the FT232 series (apparently up to 1MB/s).

ylp88

ylp88 said:

Perhaps a FT2232C or similar chip to handle USB? The FT232RL was easy to setup and use on a breadboard (using a SMD carrier board) but as far as I know, the FT2232C supports a parallel interface which potentially allows an even higher data throughput using the FTDI drivers than the FT232 series (apparently up to 1MB/s).

ylp88

Click to expand...

pic18f4550 alows up to 12mb/s

How often will you be doing this 1uS sample?


DPG: Why don't you make a USB scope then? You'll probably be able to get 200ish KSpS using on-board ADC. Now you've got the USB going (easy with the right tools and other peoples sample programmes innit! CDC or HID?) , you should be able to knock one up pretty quickly.

It is less the data transfer to the PC I'm worried about right now. In any case, if I base it on a Picaxe 28X1 (or in summer - hopefully! - on a 28X2) then anybody is free to replace that by a the corresponding "regular" PIC uC programmed in C or assembler to get more speed.

As far as the sampling is concerned, Hippy is pretty close - the Picaxe does the sampling setup, level control, and data transfer to/from the PC, and provides the variable-rate sampling clock (PWM output can go up to 2 MHz when running from a 16 MHz resonator) while a couple of 74xx logic chips control the trigger acquisition, sampling, and transfer of the sample data into a garden-variety SRAM. (no fancy FIFO etc. - I promised "low-cost" and "no exotic parts"!). The Picaxe then reads the stored data from the SRAM at its leisure and sends it up to the PC.

I did quite some research as to the best method for the sampling control etc., and each has its upsides and downsides:

- using the microcontroller and built-in ADC: maxes out around typically 50 kHz bandwidth, and tight timing is difficult to achieve (it's close to impossible to sample at a high rate and at the same time look at the trigger condition, transfer data into RAM, etc., while digital logic has little issue with those parallel tasks). The fastest I have seen with an 8-bit microcontroller was around 200 kSamples/sec on an Atmel programmed in assembler.

- high-end microcontroller (e.g. dSPic or ARM) - of course much faster, but needs more complicated development tools, also most aren't available in DIP package (I want to come up with something that anybody can build himself, not just semi-professionals). Also, not low-cost.

- directly controlled by USB (e.g. by one of those USB modules) - big issues with precise timing control; also, the moment Windows comes into play, timing isn't even close to predictable anymore. Last but not least, those modules alone are usually close to my $50 limit.

- FPGA based solution - e.g. Xilinx Spartan series FPGA: could hold all the control circuitry, a microcontroller softcore (the free Picoblaze), a USB softcore, and more. Basically the whole oscilloscope in a single chip (except the analog frontend). Downside - narrow-pitch package, needs boot-load circuitry and other peripheral stuff, and most hobbyists would get the jitters at the thought of doing FPGA development (and download a 3 GB design environment). Also I freely admit that my own FPGA design skills would need to improve "somewhat" for that task. Having said that, I actually use the Xilinx design tools to design and simulate my 74xx based logic design.


I have also plans for a second, more advanced version that uses a low-end CPLD (Xilinx XL9572) for the high-speed digital part - that can be put in a DIP-pinout socket, and is nonvolatile, so does not need any bootload circuit or flash-ROM (and it would be easy to offer the pre-programmed CPLD for purchase for anybody not comfortable burning his own). Together with a faster ADC I believe I can get 10 - 20 MHz sample rate, as well as pre-trigger capability (so you can look at what happened BEFORE the trigger). The control circuit is already working in simulation. But I think starting small will provide a good learning experience, especially for the design of the analog frontend (a low-noise variable-gain signal chain that accepts input swings from 20V down to e.g. 20mV and also negative signals, while not breaking the bank cost-wise is quite a challenge).

Overall, cost is a big issue - if the total expenses go well beyond US$100 or US$150 you are better off buying one of the low-end off-the-shelf USB oscilloscopes. My target audience is more hobbyists or maybe schools/teachers who don't need multi-MHz performance and also can't afford even one of those lower-end scopes. (from what I gather from this forum the typical budget for school electronics projects per student is measured in cents rather than dollars...).

Wolfgang

As to Dippy's question:

The super-basic design will acquire 256 samples per channel in a single shot. That's enough to for a screen-filling trace. That record length allows to use a single 8-bit counter (74HC393) and sufficient screen refresh rate (assume 19200 baud and hserout - running in the background - you get a transfer rate of close to 2 KB per second, or 4 records/sec of 2 channels x 256 samples).

It would be trivial to increase the record length - just daisy-chain another 8 bit counter, the SRAM I use has already 2 KB. The price you pay is one more chip, and - more important - a slower screen update. (that's where USB and a faster microcontroller would come handy).

It's also trivial to increase the number of channels - just add another ADC, another SRAM, and one I/O expander (MAX7300 or compatible) for each 2 channels. Again, the main disadvantage will be slower screen refresh rate.

Also, the super-basic design does not have pre-trigger capability (i.e. the trigger always starts the acquisition, like on those venerable analog scopes). Adding that is possible (I have the circuit designed already) but for the price of maybe 4 - 5 additional 74xx devices.

Overall, I think it's best to start out small & simple, get some learning from the inevitable mistakes, shortcomings and overlooked issues, and then improve and extend the design. At least that's my preferred approach.

Wolfgang

One more thought: As I said, if I go forward, I will do this as an open-source project. So DPG, feel free to replace my Picaxe controller with a USB controller. There aren't any complicated hooks to the sampling circuitry or the memory, and what there is will be open and documented. Would be fun to have a collaboration project where everybody contributes parts where his/her strengths are.

Wolfgang

For avid PIC POKERs, here's a nice little prog:
http://mister-e.org/pages/utilitiespag.html

So in answer to your non-technical question, here is one party expressing interest. I've looked at this for $175US (originally $100), but it seems to have been on hold since at least November: http://www.cs.cornell.edu/Conferences/ASEE2006/ASEE Papers/Session 5/Mobile Studio Paper ASEE STLaw06_Smith.pdf Scroll down for picture.

You will have to have an accurate (and preferably ajustable) trigger threshold or else your data points displayed will be very flickery.
When I was doing mine I also included a one-shot triggered sample, very handy.

How long will it take to read data points from external RAM and send serially to PC?

Are you doing your ADC read and RAM store all hardware?

Don't forget buffering and anti-aliasing with the filtering adjustable depending on scan rate. If you were doing it all on a fast uP you can actually do a frig alias detection for lower sampling rates / lower Fs.

Don't forget the treament for genuine AC signals.

Good project, happy sampling.

PS. Let me know when nearly done as I have an FFT routine in Basic which maybe handy for you.

Electronics World magazine produced a USB scope which was nothing more than an ADC plus FTDI parallel to USB interface. That had quite an impressive spec for absolutely minimal hardware. At today's prices I'd guess $40/£20 all in.

http://www.eix.co.uk/Ethernet/USB

That's not to say don't do your proposed project; everyone should try and design a scope and CPU / Virtual machine emulator as both projects give a lot of insight into how complicated doing apparently simple things can be and both demonstrate how each design choice can have a big impact elsewhere. Of course, start either and they are never finished projects, there's always one more improvement to be had, another alternative to test

to Hippy:

thanks for the USB link - I was aware of this project. The TLC5540 the guy mentions is the ADC I plan on using for the fast (>= 10 MHz sample rate) scope. Already have them on my bench. The problem with the design is that i's nifty, cute, simple, but not very extensible. E.g. his present 2-channel version doesn't even know which channel is which. Also I don't see a good way to add pre-trigger capability, which is a must for any more advanced scope. Same for higher sample rates - no good way to expand this to e.g. 10 Msamples/sec on two channels (even with USB 2.0). And if you want to add e.g. gain control, trigger level control etc., plus higher sample rates, you quickly find yourself in need of a dedicated remote controller, hardware-implemented sampling, and many more pins - so back to where I am already.

Having said that, I will keep the USB module in mind as a possible means to increase transfer rate for the higher-end version scope (e.g. maybe implement sampling in a CPLD, use the USB module to do the data transfer, and a Picaxe for slower-speed control tasks like gain control, trigger threshold setup, pretrigger selection).


to Dippy:

The trigger level will be adjustable. Since trigger timing (external event) and sample timing (free-running PWM from Picaxe) are completely asynchronous, there will be an uncertainty of one sample interval - i.e. 1/256th screen width with the current design. That should be too small to be very noticable, and it's similar to how more advanced designs work.

ADC read and transfer to RAM are all in hardware. I'm using the MAX153 half-flash ADC and a generic 2Kx8 SRAM (45ns access time), so that is actually simpler to do than it may sound - issue a strobe (PWM from Picaxe) to the ADC, which a bit later outputs the sample to an 8bit bus connected directly to the SRAM. The SRAM address is provided by a counter, incremented by a delayed copy of the sample strobe. The only sticky issue is to get the relative timing (sample strobe vs. data valid vs. timer increment) right, but that's not too difficult if you already have a scope in your lab (and I'll make sure the design is solid so nobody else will need a scope to reproduce it). Once all samples are acquired, the counter gets stopped and the Picaxe gets a "DONE" signal.

The transfer speed depends mostly on three factors: (1) read speed from SRAM, (2) serial data rate to PC, (3) Picaxe program execution speed.

I plan to use a port expander (MAX7300 or compatible) to fetch the data from the SRAM via I2C. A single read is about 40 bits (send slave address, receive 2 data bytes in a row, plus some protocol overhead), so about 0.1ms pure communication time, plus the command execution time of the Picaxe i2cread command (guess about 0.1ms at 16 MHz).

If I use hardware serial, then the serial transfer can happen in the background while other commands are executed. One caveat, the buffer is only 1 byte, so if I send two bytes in a single hserout command the Picaxe has to wait for the first to be sent and only the second one is sent in the background. To be conservative I'd assumed 19200 baud (allows to use standard serin or serrxd for receive without a Maxim RS-232 converter) that means around 2000 hserouts per second, or 0.5ms overhead per hserout.

So total is maybe 0.2ms for I2C read, 0.5ms for serial out, and I allow another 0.3ms for additional overhead (loop), so transfer rate (SRAM --> Picaxe --> PC) is 1000 two-channel samples/sec, or 4 screen refreshs per second, with some room for improvement (by increasing the serial data rate, overclocking the I2C bus, or going to Picaxe 28X2 at 40 MHz instead of 28X1 at 16 o 20 MHz). I'd expect it should be possible to maybe double that rate, even without going to USB or a assembler-programmed PIC.

The initial software won't include fancy (sinx/x) filtering. Since I'll publish the source anyone should feel free to add this. Would be a very worthwhile endeavor since done correctly it would increase the usable analog bandwidth from about 100 kHz (sample rate/10) to max. 500 kHz (sample rate/2) (300 kHz is a more likely achievable maximum in practice). I'll make sure the bandwidth of the analog frontend is at least 300-400 kHz, and the MAX153 has 1 MHz bandwidth anyway.

Sounds good in theory. Go for it.

Where I see a picaxe-base DSO being really appropriate is in slightly SPECIALISED scope applications, for example a spectrum analyser or audio amplifier tester, where the device can generate its own signal (which will be repetitive, very important) and the flexibility of the picaxe to adapt on-the-fly to provide whatever test you need is most valuable.

The speed of a picaxe, or even a slow RS232 feed to a PC, is not likely to be a problem then. Consider a picaxe generating a square wave to test a power amplifier (which it can do really well); if a single sample-and-hold grabs the output of the amplifier 10 uSec after the edge of the pulse the first cycle, the picaxe measures and stores it, then it samples 20 uSec after another edge, and so on, you don't need to have something that can do A-to-D all that fast. Very simple hardware, because we design the input to be repetititive - we can then shoot the output off to a PC or do calculations to display rise time, overshoot, etc.

Similarly with measuring the frequency response of speakers, and many other applications - often the need for high throughput A-to-D for a DSO is a misconception because what we want to see is a static display on the screen - which could be made from even 100 cycles of a test signal and combined, so long as we control the test signal and we know we are testing something that should be the same each cycle. (in fact this is something I am working on at the moment - using a picaxe to make a specialised curve tracer and oscilloscope cheaply - was going to use a picaxe 20M until I found it had no pwm).

maitchy, I have tried to do this (the technical term is "equivalent time sampling") with a Picaxe several times in the past: just as you describe, wait for the trigger, and then each time wait for a slightly increasing delay. Sounds good in theory (2.5us delay resolution on a Picaxe running at 16 MHz), but out of some reason I could not get a stable time base. Meaning there was some more or less random variability in the actual delay that I could not get rid of. Tried many different approaches, but always with the same result. (for some signal periods it would even seem to work, but the break down for a slightly different period). So if you are more successful, please by any means post your approach.

I also built a Picaxe-controlled time domain reflectometer (to analyze cables and printed circuit boards). Picaxe PWM supplies the drive signal to a high-speed PECL gate, which converts the slow-rising signal into a sub-100ps rise time signal, launched into the cable (or other transmission path), and then I sample the response (reflections from the path) with the same "equivalent time sampling" approach. Works very well and allows me to record time-resolved signals with over 2.5 GHz bandwidth at <10ps resolution. But in this case I used external delay line chips to control the strobe delay.

Wolfgang

Hi Wolfgang,

Is your TDR a proprietry project or can you give details about it?

I have recently been thinking about desiging one for myself but thought the Picaxe wouldn't be fast enough for the job. I was thinking along the lines of an Atmel AVR or Mega chip, purely for the speed.

The fact you got one working with a Picaxe is brilliant especially considering the form of Basic Picaxe uses. If you can share details, I'm sure others will also be very interested as well.

Hi,

Awsome project. How about not going for the Serial interface at all and rather going analog... using an old CRT monitor. i guess that would take some load off the sampling speed issue and also i dont think that CRTs are that hard to buy any more... the only thing that might be a concern of is the additional inputs you'd need to put in. if you need to really view the data on the Computer you could always save it using a SD card.

It may not be the suggestion, but worth thinking of... im just excited.

P.S: If you can come up with a setup for the entire workbench including the CRO, signal gen. and an RF analyzer. i think it would make alot of people happy as trying to get hands on something like that is out of a hobbyist's and students way. I think if you have to, base it on a CPLD, FPGA or AVR or anything. Because if it can get more accurate and its possible to get all of these things, people would definitely buy it. I know i would. no offence to this forum, it doesn't have to be PICAXE based, it has to be affordable and good.

Thanx

kam said:

P.S: If you can come up with a setup for the entire workbench including the CRO, signal gen. and an RF analyzer. i think it would make alot of people happy as trying to get hands on something like that is out of a hobbyist's and students way. I think if you have to, base it on a CPLD, FPGA or AVR or anything. Because if it can get more accurate and its possible to get all of these things, people would definitely buy it. I know i would. no offence to this forum, it doesn't have to be PICAXE based, it has to be affordable and good.

Click to expand...

Kam,

Considering the complexity of the RF, IF, and instrumentation sections of a spectrum analyzer/tracking oscillator, the digital section is trivial.

There are some articles floating around the net describing the design and construction of homebrew spectrum analyzers, some surprisingly simple. I'm not sure how well they perform, though. Even for RF hobbyist use, a spectrum analyzer must be pretty good, or else it's worse than useless.

The classic homebrew spectrum analyzer design is Wes Hayward's. It's a fairly dated design now, but reading his articles will give you a pretty good idea of the design criteria (and the complexity) that must go into one of these if you want something more than just a flashy toy. You can find Part 1 of his article here, and Part 2 here.

If you'd like a commercial unit (as I would), you can occasionally find relatively good deals on HP 1.5 GHz spectrum analyzers on eBay. These are apparently now obsolete for commercial use, but are perfectly acceptable for hobbyist use (if you have the space, and can handle the weight.) It you can find one, you'll have a good, serviceable analyzer that will fill your needs for many years to come.

The bottom line is that this equipment is quite sophisticated. It's unlikely that you'll find a cheap Velleman or Ramsey kit for any of this equipment any time in the foreseeable future, and it's an ambitious project for the hobbyist.

Just one man's opinion...

Tom

RalphTeichel,

the exact design is proprietary for now, as I am still playing with the thought whether to commercialize it or not (if decide against it, I may publish it as open source). The main challenge is actually not the signal generation or the delay control, but the sampling - there just aren't any affordable multi-GHz bandwidth samplers (ADCs) available. The approach I use is limited in acquisition speed (my Picaxe based system gets close to 500 data points/sec each on two channels, that includes data transfer to the PC over RS-232. With a faster processor and some improvements in noise margins you could speed that up maybe 10x maximum before it runs into its limits), but my sampling circuitry costs next to nothing (the crucial parts are even available as free samples - no pun intended!). It also depends on the resolution that you are after - for printed circuit boards you need to resolve features of the order of 1cm at least, that is around 100ps round trip delay (and thus, around 100ps signal rise time or less), which my design just barely makes. For "cable testers" (like the Tektronix 1501) the goal is less resolution but more range (sometimes up to kilometers), in this case you get away with slower rising signals (the Picaxe outputs have around 2ns, similar to 74HCxx gates) and accordingly much less sampling bandwidth (350/2ns = 175 MHz).

Kam, the idea to make it a frontend to an analog, slow speed scope for display was actually my starting point, but I moved away from it. You can't beat the processing capabilities of a PC (which close to everybody has available by now, more than even an analog scope) - my software can automatically calculate delays, impedances, parasitic capacitances and inductances from the acquired reflection waveform, store it in numerical format, compare it to reference traces and so on. All that would be very manual tasks with a CRO. Also delay control wouldn't be the most efficient way to do it in this case, better to have two clocks slightly offset in frequency, one for signal generation and one for strobe. That way the strobe is slowly drifting across the signal, each time strobing at a slightly different place. I have some papers showing a home-brew cable tester built that way, they use the slight (and random) frequency difference between two crystals of nominally same frequency - a pretty kludgy approach that requires cherry-picking of the crystals and also isn't very temperature stable. A much better approach would be DDS (direct digital synthesis), there are complete, inespensive DDS chips on the market (but most are high pin count, fine pitch devices).

Wolfgang

Progress update - I have a single-channel version working on a breadboard! The thing does not yet have an analog frontend (amplifier, clamps, trigger pickoff), but it can sample, store and read back data at up to 1 MHz sample rate. Four 74HCxx chips, one ADC, one SRAM, one I/O-Expander and one 28X1 so far. Dual-channel would be just a question of adding another ADC and another SRAM.

Next step will be the input amplifier stage, and then writing a Visual Basic program to drive the scope and display the data (I should be able to adapt code from my reflectometer). In addition, I want to try the circuit with an AD0820 instead of the MAX153 - the former is easier to obtain but only goes to 400 kHz sample rate, while the MAX153 goes to at least 1 MHz. Will need a few jumpers since those two ADCs are almost - but only almost - pin compatible.

Sounds very promising.

How are you going to get a fast and user-adjustable trigger?
And a thing that WILL be needed is a positive-going and negative-going trigger, otherwise flickery.

Will your code for PC work on Vista? (every version of vista?)

Dippy, what you asked is already working in my design.

The basic concept is a gated counter. The trigger clocks a D-flip-flop (DFF, data input hardwired to "high") which enables the clock to the counter (which supplies the address to the SRAM), and when the counter wraps around (MSB transitioning from high to low) it triggers another DFF which in turn shuts off the clock path again. At that point it has captured 256 samples (8-bit counter). The Picaxe can then shut off the fast clock, re-enable the clock path and issue single clock pulses, each time reading back the stored data and send it up to the PC.

Trigger generation is easy - pick off the scaled signal (0..5V range, after the input amplifier) to the ADC input, feed it to a comparator (op-amp) whose other side is connected to an adjustable threshold (coming from a DAC or in my case - to keep component count minimal - from a low-pass filtered Picaxe PWM output ). The comparator output goes into the clock input of the first DFF which by design is slope sensitive (only triggers on a rising edge). A simple XOR gate before the DFF clock input is used to invert the signal when needed (by setting the second XOR input high), so you can choose to trigger on either rising or falling edges, respectively. As mentioned, all that needs just 4 logic chips (quad XOR, quad AND, dual DFF, and dual 4-bit counter).

My software is written with VB6 (Professional), so I'd hope it will run under Vista just fine, although I don't have access to a Vista PC (all computers both at home and at work run XP). I'm not using anything exotic, only standard VB6 features and GUI elements (and MSComm of course). In any case I'll probably post the source code so you can fix any incompatibilities yourself if necessary.

Wolfgang

Can you trigger a new set of ADC counts whilst sending to PC?

You WILL need to provide pos an neg going triggering.

Check out the Bitscope design:

http://www.bitscope.com/design/

PIC based scope.

Nice.
Low cost?

Dippy said:

Nice.
Low cost?

Click to expand...

Bitscope 310U: USD $575 without probes or logic analyzer cables.

Tom

I never said "low cost"/ The point was to check out the associated front end circuitry needed for the input.

Myc

Dippy,

acquisition and data transfer are mutually inclusive (they use the same counter and the same SRAM). Like pretty much all digital scopes, the time spent in acquisition will be much shorter than the time for data transfer and display.

Since you asked again, I repeat - yes, it will be possible to trigger on either rising or falling edge, and you can choose which polarity. That's something I'd consider a core feature of any scope. Details explained in my previous post.


Mycroft, I am aware of the bitscope design. Quite professional, quite complex. My intent isn't to copy their approach - that way it would end up being just another $300+ scope, there are already plenty of those around and quite frankly, if you need that level of performance and features, you're better off buying one of those. I want to produce something that fills the gap between the (IMHO) pretty much unusable sound-card based "scopes" and other "nice proof of principle" designs, and these $300+ types (very usable, but out of reach for many hobbyists). My goal is to keep the whole thing below $50 if you build it yourself - requires to get ADCs and amplifiers as free samples from the manufacturer (Maxim and Microchip). That's also the reason I restrict it to components available as through-hole DIP packages - not every hobbyist is comfortable with small-pitch SMD parts.

Wolfgang


Wolfgang

"I repeat - yes, it will be possible to trigger on either rising or falling edge, ..."
repeat.

but earlier,
"(only triggers on a rising edge). "

- sorry, I must have misread.

Anyway, good luck.

Dippy,

read my post again, it says:

- The comparator output goes into the clock input of the first DFF which by design is slope sensitive (only triggers on a rising edge).

but also:

- A simple XOR gate before the DFF clock input is used to invert the signal when needed (by setting the second XOR input high), so you can choose to trigger on either rising or falling edges, respectively.


Wolfgang

Fair enough. My Ebay spectacles had failed.
Great project.