Those damned encoders

[SwingeyP]

Hello again,

Things have been moving steadily with my 40 meter transceiver project but I am back at a stumbling block which has been present throughout.

As Eric suggested in the beginning of this project the ENCODER routines just aren't cutting it.
I have moved away from the birds nest now and have some homebrew PCB's in a nice enclosure but this encoder thing sis just driving me nuts.

I made a vero board version of this :

http://letsmakerobots.com/content/how-use-quadrature-encoder?page=2

and it appears to work as expected. I get a pulse (checked with logic probe) every time the encoder turns (which triggers the interrupt). The A and B lines are toggling as the encoder is turned.

The problem is no matter what I always seem to count down. I added a debug line t display the value of direction (which is a bit) hence the << and >>. These ARE changing so the value must change. However I always seem to count down :-(

In simulation if you set the values of the encoder inputs high and low accordingly the code counts up and down as expected.

I'm guessing this is a timing issue in the time it takes the interrupt to run and update the LCD but I may (and probably am) wrong.

Can someone take a look please.

The Interrupt

'----------------------------------------------------------------
'ON INTERRUPT
'----------------------------------------------------------------
On Interrupt
Save System

PIR1.TMR1IF = 0  'clear the overflow
INTCON.INTF = 0  'clear interrupt on RB0.
INTCON.RBIF = 0

intrcnt = intrcnt + 1
intflag = 1

'old = new;
'New = digitalRead (inputA) * 2 + digitalRead (inputB);           // Convert binary Input To decimal value
'out = qem [old * 4 + new];

direction = encodera Xor encoderb
Lcdcmdout LcdLine3Pos(1)
If direction = 1 Then
    Lcdout "Direction  >>"
Else
    Lcdout "Direction  <<"
Endif


Resume

The count up / down

'----------------------------------------------------------------
'Sub Routines
'----------------------------------------------------------------
check_inband:
Select Case freq_step
    Case 1  'step = 1
        If direction = 1 Then  'increment
            hz = hz + 1
            If hz > 9 Then
                hz = 0
                khz = khz + 1
                If khz >= bandwidth_upper Then
                    khz = bandwidth_upper
                Endif
            Endif
        Else  'decrement
            hz = hz - 1
            If hz < 0 Or hz > 9 Then  '>9 trap for -1 overflow as using byte variable
                hz = 9
                khz = khz - 1
                If khz <= bandwidth_lower Then
                    khz = bandwidth_lower
                Endif
                Endif
        Endif
        Case 10  'step = 10
            hz = 0  'set this to zero as it looks nicer
            If direction = 1 Then  'increment
                khz = khz + 10
                If khz >= bandwidth_upper Then
                    khz = bandwidth_upper
                Endif
            Else  'decrement
                khz = khz - 10
                If khz <= bandwidth_lower Then
                    khz = bandwidth_lower
                Endif
            Endif
EndSelect
Return

Many thanks - Paul

 

[Ian Rogers]

I have my own encode system... It works on a state machine rather than interrupts.... I use a pic12f675 to poll continuously the inputs A and B then only act on change....

I then pass the clock and relevant direction to another pic to process.... If you need to have a look see PM me and I'll post you the code I use.... If you can't afford the polling time this may not be the resolution you are after, but I faced similar issues and found that a separate 8 pin pic to encode the signal first, a boon!!

 

[Pommie]

A very simple way is to interrupt on encoderA going high and then encoderB is the direction to move. This wouldn't be accurate for CNC stuff but works fine for simple up/down encoders.

Give it a try, it can't take more than 10 mins to write the code.

Mike.

 

[jjw]

The problem is probably the slow Lcd functions inside the interrupt.
This might help:http://digital-diy.com/swordfish-ex...rrupts-interfacing-a-scroll-wheel-switch.html

 

[SwingeyP]

Hi guys I took the LCD routines out of the ISR and did what Mike suggested. It works but isn't really fantastic. I think the encoder (being a cheap one) may well be part of the problem (debounce). I have ordered a better one i'll let you know how it goes.

Cheers - Paul

 

[Ian Rogers]

The system I use doesn't care for the bounce... As it is polled extremely quickly, the bounce isn't counted... You get a clean count!

 

[SwingeyP]

Hello Ian, I did break the code into two pics and got that sort of working but i've since found this which may be useful.

**broken link removed**

Cheers - Paul

 

[JimB]

Paul

I have had a few problems with rotary encoders during my various adventures with tuning synthesisers. These can be summarised as follows.

The output of the encoder to the PIC should be from a schmidt trigger to ensure a sharp edge to the waveform. If the rise/fall time is slow, the PIC will read multiple transitions due to the low level noise on the signal.

The basic encoder shown in your link (the part without the PCB) nearly drove me mad. I could not get them to work in a satisfactory manner and I abandoned them and never looked back.
The output is not a true quadrature output, the thing uses "switches" which bounce like crazy. At the detent positions both switches are open circuit and close in the appropriate order for the the direction of rotation as the shaft is turned between detent positions.
How the one in your link works, I do not know but to me that basic mechanism is suspect.

JimB

 

[SwingeyP]

Hi Jim,

I put the outputs of the encoder on the scope today and confirm what your saying. I get some VERY weird readings when in a 'in between - detent? ' state. As you say I think this is what is happening here. I'll scan ebay for a good quality one from an old Yaesu radio or something.

Regards - Paul

 

[JimB]

I have used these:
https://uk.farnell.com/grayhill/62p22-l6s/encoder-optical/dp/1005754?Ntt=1005754
and I am very happy with them.
I would prefer ones with a metal body and nut fixing like the "funny" ones, but at least you keep your sanity!

JimB

 

[Ian Rogers]

My encoder reads the raw quadrature signal and gives a clean pulse and direction... I guess my ouput would be the same as the one you linked...

 

[SwingeyP]

This is the link of that encoder directly from the supplier to spiratronics.

**broken link removed**

Just posted it as if the video lives up to reality that kind of turn speed would do me fine. - I'll get one as soon as they are in stock and report back my findings.

Regards - Paul

 

[JimB]

The performance shown in the video is far better than I was able to achieve with the basic encoder.
Using variations of the PIC routines which work well with other true quad encoders, I was left with the feeling "how could a company like Bourns make and sell this junk?"

Do let us know how you get on when you have tried it.

JimB

 

[SwingeyP]

A quick video of the symptoms I am seeing so far.

 

[SwingeyP]

As promised a video of the new encoder. This one works MUCH better and the quality is far superior to those cheap ebay ones.