At Last......

[hughgilhespie]

I have been struggling since the middle of December with my Arduino powered observatory controller. The heart of the dome rotation positioning system is an Arduino Nano that counts the pulses sent to the step motor that in turn rotates the dome. The Nano also senses the pulses from a rotary encoder. The RE is there for two reasons. One is because my controller is basically a Lesvedomenet controller and this needs/uses a rotary encoder to measure the dome position. The second reason is that by counting how many motor pulses are needed to give one pulse from the rotary encoder, it is possible to tell if the dome has jammed.

In principle, it is a fairly easy task for a Nano with a 16MHz clock. The motor pulse rate is about 1600 pps and the pulses from the RE are about 55 pps. These pulse rates are readily handled using interrupts. A fast, External interrupt for the motor pulses and a couple of Pin Change interrupts for the RE. That at least is the theory. My first design - known for obscure reasons as ABoard3 - produced RE pulses in the 100's pulses per second range. Hmmm - obviously not right, it will all be due to RFI from the step motor and driver.

So, a major redesign later and the step motor driver and it's own Nano for pulse generation are living in a nice shielded enclosure. There are 10uH chokes in the lines to the motor itself and a proper EMI filter in the driver power supply line.

And, yes, it's a bit better but not quite right. So, let's now design a shielded enclosure for the rotary enclosure and use decent quality shielded cables with drain wires to keep everything nice and quiet.

Now this is looking better. In fact almost perfect until I switch on the step motor. Then - well pretty much as before - quite a lot of spurious interrupts from the RE.

Next stroke of genius. My design, as a Lesvedomenet adaption, includes a Vellman VM110 USB breakout board. This board also receives the RE pulses and treats them properly as a quadrature signal. And lo and behold, this board doesn't have any problems - so -

Next design revision is to pull apart my Aboard3 and incorporate a daughter board using a hex buffer. Why? Well this is a direct crib from the Velleman board, same hex buffer, same pull-up resistors. This will definitely solve it.

Except it doesn't. I am now at a loss to know where to go next. Then the penny finally drops. All along I have been assuming that because the rotary encoder is a nice Bourns optical encoder I don't have to worry about debouncing the output do I?

Actually I do!

So, my trusty copy of The Art of Designing Embedded Systems by Jack Ganssle has a circuit for a hardware debouncer that actually works. Based on a hex inverting Schmitt trigger buffer and some Excel calculations for component values and here you have it, a two channel debouncer that fits inside the shielded box for the rotary encoder and

IT WORKS!!

So, lessons learnt -

1: Never trust assumptions

2: Persevere - hats off to Gina for inspiration in this department.

Regards, Hugh

[Steve 1962]

Great read Hugh! Pleased you got it sorted!

Steve

[Gina]

Well done from me too