• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 79 subscribers
  • Views 336 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430FR50431: possible bug while developing our own frequency sweep function similar to the one in Ultrasonic Sensing Design Center software

Marvin Cantos
Expert 3515 points
Part Number: MSP430FR50431
Other Parts Discussed in Thread: EVM430-FR6043

Hi Team, 

Good day. I am posting this inquiry on behalf of our customer.

We're developing a water flowmeter using MSP430FR50431 and USS library supplied by you. We have managed to create a USS configuration and firmware suitable for our application, but we have encountered a possible bug while developing our own frequency sweep function similar to the one in Ultrasonic Sensing Design Center software.

Our goal is to create a function inside the firmware, which will tune the frequency to the best value for transducers attached to it, however, from our observation the data don't form a smooth curve, but rather something resembling "steps" (axis captions are switched by accident, X-axis is in fact frequency, Y-axis is signal amplitude).

Frequency sweep was performed on 900kHz - 1100kHz range with 1kHz step:

Thinking this was a bug on our side, we have performed a similar frequency sweep using EVM430-FR6043 development kit modified for water applications and Ultrasonic Sensing Design Center software. Test was performed on 950kHz - 1050kHz range with 1kHz step. Transducers weren't the same as during the first test, but were from the same batch. Software has returned following result:

From our point of view, this seems like some problem with frequency multipliers/dividers inside the peripheral causing it not to switch the excitation frequency by 1kHz, but rather by 5-7kHz.

In our software we have tested various ways to overcome this problem, like giving the USS library more dummy USS flowrate readouts to stabilize the frequency or setting the frequency in pseudo-random order, however, nothing seems to fix this issue. We have run this frequency sweep on more than 100 devices and the behavior is the same on all of them.

We're using an 8MHz crystal oscillator as a source for USS peripheral.

Can you please give us some advice on how to force the peripheral to properly switch the transducer excitation frequency according to configuration?

Please help to advise. Thank you for extending your support.

Kind regards, 

Marvin

  • 0
    TI__Mastermind 28286 points

    Hi Marvin,

    One question for this description:

    Marvin Cantos said:
    From our point of view, this seems like some problem with frequency multipliers/dividers inside the peripheral causing it not to switch the excitation frequency by 1kHz, but rather by 5-7kHz.

    You means that USS module can't generate this frequency pulse, thus you got this error data in Frequency sweep function, correct?

    Have you try to use oscilloscope capture those pulse?

    Thanks!

    Best Regards

    Johnson

  • 0 in reply to Johnson He
    Prodigy 50 points

    Hello,

    not exactly, the drop in amplitude you highlighted is a standard characteristic of our transducer - major amplitude peak is around 980-990 kHz, second smaller peak is around 1040-1050 kHz. Our problem is coarseness of the entire plot, like the frequency wasn't adjusted according to value set in USS_userConfig.h file.

    Nevertheless, I have searched Reference manual for our MCU and discovered in chapter 21.2.6 Excitation Pulse Frequency on PPG or PPG_A, that excitation frequency is calculated as HSPLL frequency / ( SAPHPGHPER.HPER + SAPHPGLPER.LPER), so 80 MHz (our setting) divided by an integer value. To test this I have gradually configured our flowmeter to frequencies 992, 993, 994 and 995 kHz, because by formula defined above the real excitation frequency should be:

    992kHz -> 987kHz (80Mhz / 992kHz = 80.86, rounded to 81, therefore 80Mhz / 81 = 987kHz)
    993kHz -> 987kHz (80Mhz / 993kHz = 80.56, rounded to 81, therefore 80Mhz / 81 = 987kHz)
    994kHz -> 1000kHz (80Mhz / 994kHz = 80.48, rounded to 80, therefore 80Mhz / 80 = 1000kHz)
    995kHz -> 1000kHz (80Mhz / 995kHz = 80.40, rounded to 80, therefore 80Mhz / 80 = 1000kHz)

    I've then connected an oscilloscope to one transducer mounted to our flowmeter and let USS run. For each tested frequency I've measured real excitation frequency:

    Configured 992kHz, measured 986kHz
    Configured 993kHz, measured 986kHz
    Configured 994kHz, measured 1002kHz
    Configured 995kHz, measured 1004kHz

    Although my measurements weren't completely precise (could be +- 2 kHz), I'm positive that during none of these measurements I could find anything close to 992-995 kHz values.

    My idea was to manipulate with HSPLL frequency to find the best f_HSPLL and f_Transducer combination, but since we are modifying these parameters at runtime and not during compilation, it would require further on-the-fly modifications, because many more parameters rely on HSPLL frequency value as well.

    Is there any way how to overcome this problem, or is formula mentioned above the only way how to configure excitaion frequency?

    Thank you, best regards

    Antonin Stepan

  • 0 in reply to Antonin Stepan
    TI__Mastermind 28286 points

    Hi Antonin,

    Looks weird, I agree with you, the measurement error should not be particularly large.

    Just would like to double check if you used the below example code for your test? Or use USS library directly?

    https://dev.ti.com/tirex/explore/node?node=A__ALaFXQVGDJ7i2O.OmmB66w__msp430ware__IOGqZri__LATEST&placeholder=true

    And have you check if other frequency is correct, like 500KHz?

    I can run some test in my side.

    Thanks!

    Best Regards

    Johnson

  • 0 in reply to Johnson He
    Prodigy 50 points

    Hello Johnson,

    I used USS library directly, our entire application is built around it, so register-based tests can be done, but in the end I would need a solution compatible with the library, if there is any.

    I've tested a few values around 500kHz, but they don't present such a problem, as is demonstrated by following calculations:

    500kHz -> 500.00kHz (80Mhz / 500kHz = 160.00, rounded to 160, therefore 80Mhz / 160 = 500.00kHz)
    505kHz -> 506.32kHz (80Mhz / 505kHz = 158.41, rounded to 158, therefore 80Mhz / 158 = 506.32kHz)
    507kHz -> 506.32kHz (80Mhz / 507kHz = 157.79, rounded to 158, therefore 80Mhz / 158 = 506.32kHz)
    508kHz -> 509.55kHz (80Mhz / 507kHz = 157.48, rounded to 157, therefore 80Mhz / 157 = 509.55kHz)

    Difference of 1kHz can be observed on an oscilloscope only with difficulties.

    If you could run some tests at frequencies around 1000kHz, it would be very helpful.

    Thank you, best regards

    Antonin

  • 0 in reply to Antonin Stepan
    TI__Mastermind 28286 points

    Hi Antion,

    I will run 1000KHz test then get back.

    Thanks!

    Best Regards

    Johnson

**Attention** This is a public forum