• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 1437 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.

MSP430FR6047: USS Error 135: DToF - Shift value was greater than maxSampleShift

Lasse Lundholm
Intellectual 280 points

Part Number: MSP430FR6047
Other Parts Discussed in Thread: CC1310,

Hi TI team

I have a question about the USS error 135: DToF - Shift value was greater than maxSampleShift.

First the setup:

I have a test stand that looks like something like this:

The sensor is a clamp-on flow sensor - the black narrow thing right on top of the box. The fixture is used for debugging. My setup for this particular post is without all the debug wires attached and the sensor runs on battery.

It has a CC1310 and a MSP430FR6047 on it. The CC1310 receives the data from the MSP.

The question:

The sensor has been mounted on the box for 5 days with a measurement every 2 seconds. At day 6 the MSP all of a sudden starts to send error 135 every other measurement (every 4th second - see picture of error log below). It did so for several hours until my error handler on the CC1310 stopped the measurement request, reloaded the USS parameters to the MSP and started the data request again.

Any good explanation why this error appears all of a sudden after almost a week?

What happens inside the MSP algorithm?

I understand that the algorithm has to shift the UPS/DNS capture more than 20 (as defined in the USS_userConfig.h) samples to align the spikes. This error should be relevant under (very) high flow conditions but this is zero-flow.

Another question I would like to ask is: Under what conditions does the MSP430FR6047 return 0.0 in absolut tof and delta tof?

I have seen it lately and would have expected an error if something was wrong.

Kind regards

Lasse

  • 0
    TI__Guru 71216 points

    Hello Lasse,

    Let me check with our USS expert on this.

  • 0 in reply to Dennis Lehman
    TI__Guru 71216 points

    Hi Lasse,

    Our USS expert is a little surprised to see this at zero flow.  He thought maybe an accumulation of air bubbles may contribute to this, but unless the units under test are undergoing changes in temperature or pressure, I don't see how a bubble would form at zero flow.  And you say when you reloaded the parameters it clears the error anyway.

    Is this the only meter you have tested and seen this behavior?

    Out of curiosity, did you try increasing the max sample shift > 20 to see if any impact?

  • 0 in reply to Dennis Lehman
    Intellectual 280 points

    The answer here gets a bit more tricky.

    Its not the first time I have seen this error. But that is under other test conditions (Pipes with intermittent or constant flow). Although the flow in these pipes wasn't near to what the sensor has shown to be capable of measuring. But I cannot guarantee that random air bubbles wasn't the cause under those circumstances.

    At my table test stand (the one in the picture) I haven't conducted much long term testing. So I cannot with certainty say I have seen that behavior before.

    I can test again with another sensor and see if the error come again.

    But there must be some good explanation that's why I'm interested in understanding what happens in the algorithm for that error to be send.

    I haven't tried increasing the max sample shift either. So there is further testing to be done :-)

  • 0 in reply to Lasse Lundholm
    TI__Guru 71216 points

    Hi Lasse,

    Just curious if you found anything with a different sensor or increasing the max sample shift value?

  • 0 in reply to Dennis Lehman
    Intellectual 280 points

    I have had a different sensor mounted on the test stand since April 14th now. And the error hasn't shown itself during that time. So not sure why the error came and still curious what the reason could be???

    The new sensor, however, did another curious thing. After a week of measuring the flow "jumped" from 0.02 m/s up to around 0.05-0.055 m/s. This indicates the deltaTof also jumped. I can see the temperature also increased a bit, but it shouldn't have that kind of effect on the measurements.

    This could be related to the original problem since an increase in deltaTof must relate to increased difference between the UPS and DNS capture.

    I use the formula

    v = ( dTof * c² ) / (L * 2)

    To calculate the velocity

    The ADC capture used looks like this (From CCS graph viewer). Poor quality picture. But the capture has an amplitude of 914. I use 20 pulses. First pulse at 100 us, gap set to 96 us if i recall it correctly.

    It looks like a long 'fish' but it is because of the size of the window. If it was compressed a bit and the y-axis set to 1000 instead of 2400 it would resemble the ones usually shown in TI material.

  • 0 in reply to Lasse Lundholm
    TI__Guru 71216 points

    Hi Lasse,

    Do you have an update on your progress with this issue?

  • 0 in reply to Dennis Lehman
    Intellectual 280 points

    Hi!

    I have no answer as to why this happened. I have had a different focus for the past month, trying to get the clamp-on sensor to measure on iron pipes. This is i known tough issue, but I actually has some surprising promising results so far Nerd

    If I stumble upon it again I will try and gather as much data as possible and ask a new question.

    My original question was about what happens inside the code. What happens when the MSP has two captures and finds this particular error.

**Attention** This is a public forum