• State
  • Locked Locked
  • Replies 29 replies
  • Subscribers 32 subscribers
  • Views 3107 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Tiva TM4C123 missing QEI counts

Gorkem Secer
Prodigy 150 points


Hello,

I'm using HEDS 9040 incremental encoder of Avago. 
its datasheet is here : 

the encoder requires 2.7k ohm pull-up resistors, which I connect to +3.3 V.
The sensor is guaranteed to operate up to 100 kHz count frequency.
my application requires at most 60 kHz frequency.
When I go up to speeds corresponding 60 kHz frequency, the microprocessor starts missing counts.

my qei configuration of the processor uses the internal debounce filter. 

After doing some research, I have seen in an application note of tiva the following:
"A series resistor followed by a capacitor to digital ground should be placed on each QEI input to filter the
inputs from noise that would violate the input electrical specifications of the device. A common value for
the series resistor is 100Ω and for the capacitor is 1nF. The electrical specifications of the quadrature
encoder being attached and the system environment determine the optimum resistor and capacitor values
for the system"

Is such input filter necessary? may it be the thing behind the problem I'm having?


I couldn't give it a try yet because I'm not sure what will be the optimum values for my encoder?
it already requires a pull-up resistor. So, I suppose connecting a 100 ohm input resistor will act like voltage divider
causing the inputs drop below logical high voltage levels?

  • 0
    TI__Guru**** 244400 points
    Hello Gorkem

    When connected to the TM4C device, first check the quality of the signal being seen as close as possible to the TM4C pin on a scope and preferably with an active probe. If there is significant overshoot and undershoot, then an external low pass filter would be required.
  • 0 in reply to Amit Ashara
    Prodigy 150 points
    Hello Amit,

    I don't see any overshoot at the TM4C QEI pins.
    Do you have any idea what might cause the problem I'm having?
  • 0
    Guru 27665 points

    Gorkem Secer said:
    the encoder requires 2.7k ohm pull-up resistors, which I connect to +3.3 V.

    It's a 5V device, it may require a 5V pull-up. You will need to take care that the inputs to the micro are kept within range. A level translator would be a good idea for a number of reasons.

    Also are you using a 5V supply to power it?

    Gorkem Secer said:
    When I go up to speeds corresponding 60 kHz frequency, the microprocessor starts missing counts.

    What's the 'scope show at full speed? With a weak pull-up it's possible that your inputs are malformed.

    Robert

  • 0 in reply to Robert Adsett
    Prodigy 150 points

    Thanks for the comments, Robert.

    I supply it a 5V, but I don't connect pull-ups to the sensor's supply voltage.
    Instead, I connect pull-ups to Tiva board's +3.3 V to make sure that inputs to the micro are in the range.

    Last night, I experimented that different pull-up values give different performance results.
    I tried using pull-ups between 1k to 8k ohm and finally disconnected pull-ups as part of the debugging experiment.
    I observed that higher pull-up values are better and among them no pull-up was the best case.
    That wasn't what I expected.

    I don't have the circuit right now.
    I will take a screenshot of the scope tonight.

    Btw, I use the TM4C launchpad as the board.

  • 0 in reply to Gorkem Secer
    TI__Guru**** 244400 points
    Hello Gorkem,

    What is the system clock for the TM4C123 and value of the debounce filter? Looking at the datasheet of the device, it seems that the pull up's are not required as the output is comparator driven.

    Also the snapshot of the output waveform with both pull up and no pull -up may also be useful information.
  • 0 in reply to Gorkem Secer
    Guru 27665 points

    Gorkem Secer said:
    I supply it a 5V, but I don't connect pull-ups to the sensor's supply voltage.
    Instead, I connect pull-ups to Tiva board's +3.3 V to make sure that inputs to the micro are in the range.

    That's a somewhat chancy approach. It might work for an open collector output with my caveats on speed, for a driven output it could fail quite badly since you are pulling the output to mid range. A level translator would be a far more sure approach.

    Robert

  • 0 in reply to Robert Adsett
    Guru 117855 points
    And - may I add - as poster is using a "hacked" LPad his location of the QEI's input filter components is SURELY sub-optimal. (such filter components must be located as close to their target MCU pins as possible.)

    A proper level translator - as poster Robert suggested - remains your best bet. (and just may escape its enforced separation distance)

    Scope traces - directly at the MCU QEI pins - prove NECESSARY here - as does the use of a proper scope probe and extremely short scope ground connection. Ideally you'd supply the scope traces at 90% of the "highest working speed" and then the identical traces at 110%. (the failure zone)
    Measurement here is CRITICAL - and the "cobble" of the LPad to a high-frequency device (forcing added signal travel) is far from ideal...
  • 0 in reply to cb1_mobile
    Prodigy 150 points
    What do you mean by hacked LPAD?
    you call it that way because I connect pull-ups to LPad's +3.3 V?
    I don't use any input filter yet. the MCU is configured to use its internal debounce filter currently.
  • 0 in reply to Robert Adsett
    Prodigy 150 points
    The encoder datasheet says:
    "To insure reliable encoding performance, the HEDS-9040
    and 9140 three channel encoder modules require 2.7
    kΩ (±10%) pull-up resistors on output pins 2, 3, and 5
    (Channels I, A and B) as shown in Figure 1. These pull-up
    resistors should be located as close to the encoder module
    as possible (within 4 feet). Each of the three encoder
    module outputs can drive a single TTL load in this configuration"

    I first thought the outputs are open collector. Does this statement mean outputs are driven?
  • 0 in reply to Amit Ashara
    Prodigy 150 points

    Hello Amit,

    This is the code configuring the system :
    SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN); // pll(16 Mhz) = 400 Mhz -> 400 Mhz divided (natural clock division) by 2 = 200 Mhz -> 200 Mhz / 2.5 = 80 mhz

    So I use 80 MHz as the system clock.

    I tried different values for the debounce filter.
    Currently, I configured it to be 16.
    So, as far as I understand, the MCU waits for 1+16 clock cycles to accept a change in the channel signals 

  • 0 in reply to Gorkem Secer
    TI__Guru**** 244400 points
    Hello Gorkem,

    Yes that is correct. I wanted to check if the time period of the incoming signal and the filter is not the issue.
  • 0 in reply to Amit Ashara
    Prodigy 150 points

    The block diagram Amit's referring to is here

  • 0 in reply to Gorkem Secer
    Guru 27665 points

    Gorkem Secer said:
    . Does this statement mean outputs are driven?

    The statement is less than clear. However, since it only refers to the resistors being necessary for reliability (rather than for any operation) my assumption would be that the output is driven. The resistor is probably recommended for noise immunity.

    Pulling the output to midscale could destroy the chip (thermal overload). It certainly won't help your frequency response.

    Personally, unless I was building a lot of these I'd use an isolated level translator. Level translators are not expensive, even isolated ones are cheap compared to the risks for small numbers.

    Robert

  • 0 in reply to Gorkem Secer
    Guru 117855 points
    By "hacked" is meant that you've ADDED components to the LPad. While the encoder vendor mentions four FEET - that length is absurd - invites all kinds of stray signals - instead your interconnects should be as short and direct as possible.
  • 0 in reply to Robert Adsett
    Prodigy 150 points

    I found one of these www.sparkfun.com/.../12009.
    I will try tonight and share the results

    Looking at the datasheet of the mosfet on this break-out, I'm afraid that I run into same issues.
    it has some pull-up resistors as well.

    http://cdn.sparkfun.com/datasheets/BreakoutBoards/Logic_Level_Bidirectional.pdf

  • 0 in reply to Gorkem Secer
    Prodigy 150 points
    Robert,

    Could you name a few isolated level shifters?
    When I google it, all I found is some optocouplers
  • 0 in reply to Gorkem Secer
    Guru 27665 points
    Try

    www.digikey.com/.../3736104

    Check that the power inputs meet your output ranges from each power supply. There are other manufacturers of similar devices.

    Robert
  • 0 in reply to Robert Adsett
    Prodigy 150 points

    Well, here's the thing.

    I tested both with an isolator and a simple non-isolated logic level shifter.
    The problem still persists.

    A friend of mine said that there were problems with the qei peripheral of stellaris MCUs at quadrature counting.
    Is there any known bug with QEI of Tiva MCUs?
    I checked the errata but only saw that there are problems related to index signal.
    I don't use index signal. Maybe, there are some bugs that weren't documented in an errata yet?

  • 0 in reply to Gorkem Secer
    TI__Guru**** 244400 points
    Hello Gorkem,

    None that i can recollect on speed of input signals, were ever found on the QEI module
  • 0 in reply to Amit Ashara
    Prodigy 150 points
    It doesn't have to be related to input signal speed.
    The encoder measures the position of a robot moving backwards and forward.
    This moving back and forth thing repeats.
    At high speeds, frequency of this repetitive motion increases.

    Having explained my application, could you reconsider my earlier question?
  • 0 in reply to Gorkem Secer
    TI__Guru**** 244400 points
    Hello Gorkem

    That is where the filter comes into picture. Now in the original post it was mentioned that the pulses are being missed at 60KHz and above frequency but nothing was mentioned of the to-fro direction. At that point I would make an assumption that the pulses could be malformed at the source itself.

    One way to check would be to connect the scope in persistence capture mode and run the encoder at 60KHz. If there are pulses not coming in correctly, they would come up as a smear on the scope screen.

    Now if that is not the case and the pulses are being generated at 60KHz with to-fro motion, that would be some serious movement of the robot to-fro to generate such high frequency pulses considering the inertia of the mechanical system.
  • 0 in reply to Amit Ashara
    Prodigy 150 points

    Let me give a more clear picture of the situation.

    The robot definitely moves at that frequency.
    It is a jumping robot.
    Vertical velocity of the robot during a complete stride takes values between +- 2 m/s.
    This velocity corresponds to 60 kHz for my encoder. It is a really simple calculation.;
    I checked with the us digital to find out if the encoder bandwidth is sufficient for those speeds.
    They guaranteed that their encoder works up to 100 kHz.


    Now the problem appears exactly as follows:
    Let's say at initial position, the encoder counter is zero.
    After some jumping, the robot turns back to its initial position.
    Having turned back to its initial position, everyone expects encoder is back to zero as well.
    But my encoder counter tells me that the robot is some inches below the ground.

    An update to architecture of the encoder. The manufacturer told me its output is push-pull

  • 0 in reply to Gorkem Secer
    Guru 27665 points
    Do you have an independent measure of the counts? With those kinds of accelerations and perhaps as bad rates of change of acceleration (jerk) you might have mechanical issues with the encoder.

    Robert
  • 0 in reply to Robert Adsett
    Prodigy 150 points

    yes, there's a motion tracking system at the lab. I can confirm that robot moves at that range of velocities.
    There is no mechanical failure.
    I checked if there is a mechanical failure but none I discover yet.

    see the video : 

    this is a cropped video. Originally, the robots starts its operation on the ground. After some jumps, it is back on the ground.
    but the encoder does not tell so...

  • 0 in reply to Gorkem Secer
    Guru 27665 points
    It wouldn't have to be an outright failure.

    Also, how do you get that 2 m/s? Hopefully that's peak rather than average. IE d/t would be potentially an issue.

    Robert
  • 0 in reply to Robert Adsett
    Prodigy 150 points
    You're right Robert. I forgot to say that.
    Absolute average is about 1 m/s
  • 0 in reply to Gorkem Secer
    TI__Guru**** 244400 points

    Hello Gorkem,

    Gorkem Secer said:
    An update to architecture of the encoder. The manufacturer told me its output is push-pull

    Then why recommend pull up's as per the datasheet?

    Also, if it is possible, I would like to see the persistence capture of the scope. That would at least clear the issue/doubt if the input itself has an anomaly.

  • 0 in reply to Amit Ashara
    Prodigy 150 points
    They said pull-ups are for improved noise immunity.

    I don't have a flash drive to plug into my scope yet.
    I hope to take snapshots tomorrow.
  • 0 in reply to Gorkem Secer
    TI__Guru**** 244400 points
    Hello Gorkem

    You can still check on the scope for any smearing.