Blasting Monitoring Application - Microcontroller suggestions

xavierlajoumard · ‎04-06-2018

Hello,

I am a Masters student in Embedded Systems at KTH working on a thesis to develop a blasting monitoring sensor and wanted to hear your suggestions on uCs.

My intent is to measure ground vibrations with 3 geophones and sample each signal from an external ADC at 4kHz while continuously comparing these values to a threshold value. When the threshold is passed, FFTs and post-processing still need to be performed because of the non-linear frequency response of the geophones. When the threshold is confirmed to be passed based on the frequency, it will trigger the recording of the signals on an external RAM (>10Mb).

In short, I am looking for a uC that can do 4kHz sampling of at least 3 ADC signals, comparisons, FFTs, can be easily interfaced to an external RAM, and be as low-power as possible. It will also need ≥1 SPI interface, ≥1 I2C interface, ≥2 UART interfaces and ≥6 GPIOs.

Thanks for the help!

Xavier Lajoumard de Bellabre

xldb@kth.se

xavierlajoumard · ‎04-16-2018

Hey Mark,

Thanks for the very informative answer! Lots of useful links and good advice on using uTasker, I just applied to it.

For different reasons, I have decided to move forward with my project using the K24F. That being said, I have some follow-up questions for you if you don't mind:

- You mentioned using the ADC for threshold detection which is interesting because I was actually considering using the analog comparators. Do you know the advantages/disadvantages of each solution and which one would you recommend? Can the comparators be used to trigger on negative voltages? Are they similar in terms of noise performance and resolution?

- I am considering running an external ADC to sample the signals while having the threshold detection being performed and some data continuously stored on the MCU's RAM. My first intention was to have the MCU in VLPS mode and then switch to run mode when triggered (either by comparators or ADC). Do you know if this would still be possible while running an external ADC instead of the MCU's one? The reason for that is that I need more than the maximum ENOB of ~14.5.

- I have seen that development boards such as the FRDM-K64F Freedom Module have the OpenSDAv2 adapter. Programming through USB (and powering) is something I am interested in thus I was wondering if it is possible to buy this adapter somewhere?

- Lastly, which compiler and debugger would you recommend for this MCU?

Your help is much appreciated.

Sincerely,

Xavier Lajoumard de Bellabre

mjbcswitzerland · ‎04-16-2018

Xavier

Threshold detection can also be performed with comparators - there are advantages and disadvantages in each case. You may be able to get lower power operation with comparators since the ADCs then don't need to run all the time. The ADCs can however do more powerful threshold detection in some cases (within or without range bands for example). You can get details about noise and resolution in the processor's data sheets (not user's manuals) but beware that HW design is also important so the chip's values alone are not necessarily the only factors.

If you need > about 14 bit resolution you can't use the internal ADCs. The processor can operate in VLPS to save power but you will need to ensure that its wake up time (each ADC sample, for example) is short and so an external oscillator may be the best clocking method - see this report on VLPS and continuous UART operation as reference.
Low power with UARTs: https://community.nxp.com/message/421247#421247

SPI connected ADC with an interrupt on conversion ready is probably most suitable (interrupt to wake the processor and SPI for fast read with easiest connection).

I don't know whether you are referring to integrating the OpenSDA chip into your HW: NXP advises against this since it is intended for development and not for production. also it will increase your power supply requirements.
If you want to be able to program in the field via USB you can simply use the uTasker USB-MSD loader together with the application [http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.pdf] and you can always use the K24F's USB adapter to power your board.

NXP will probably advice MCUXpressor for development and programming but also KDS is fine. You can also use Codewarrior, Atollic or CooCox if you like Eclipse based tools. For most efficient work (if your University has an agreement) use IAR as it has slicker debugging and builds faster to tighter code. Rowley Associate's Crossoworks is also an interesting one between the two which also has a student's edition.
Since the uTasker project is flexible as to which tools it can be used with you have freedom of choice - these are the ones that it contains targets for:

    NXP's MCUXpresso
    NXP's Kinetis Design Studio (KDS)
    Freescale's CodeWarrior 10.x
    S32 Design Studio for ARM
    Rowley Associate's Crossworks
    CooCox CoIDE
    IAR Embedded Workbench
    Keil µVision
    Green Hills
    Atollic TrueSTUDIO for ARM
    Standalone GCC from Makefile
    VisualStudio for Kinetis simulation

Regards

Mark

xavierlajoumard · ‎04-17-2018

Mark,

Once again, thanks for all the useful information! I got a bit confused by your answer regarding the external ADC triggering so I want to make sure I understand your proposal here:

- Are you saying that with an external ADC, the only way to do threshold detection would be to interrupt the MCU at every sample, triggering the change from one of the low power modes to the run mode, and then do the comparison? And in that case, how would you suggest doing the comparison?

- Also, this might very obvious but I'm confused whether or not the MCU needs to be in run mode to access the SRAM? The reference manual says that the SRAM is retained down to VLSS3 mode but it doesn't say down to which mode we can write to it. For example, can I still write to the SRAM while in VLSS3 mode with the external ADCs through the backdoor using the crossbar switch?

- Regarding the external oscillator, you did mean to use it for the MCU correct?

Thanks for the help.

Sincerely,

Xavier Lajoumard de Bellabre

mjbcswitzerland · ‎04-17-2018

Xavier

I suggest that you look for an ADC that includes threshold detection built in since this may allow it to operate continuously when the processor sleeps. Then it would wake the processor when it detects something needing recording. You may also find one with a FIFO/internal SRAM so that it saves a certain number of samples.

Alternatively a comparator system that does something similar, which may allow lower power since the ADC then doesn't have to run either.

I was assuming originally that you may want to wake the processor every sample so that it can store and make decisions before sleeping again until the next sample. In this case it is important to sleep as long as possible between samples and wake up as fast as possible - this is why I suggested an external oscillator of the processor since internal oscillator stabilisation timer in each mode transition is quite long.

I don't know details of using the processor's internal SRAM to store directly to from an external device when the processor is sleeping (or if it is possible at all). There may be limits here since there may also be internal clocks needed for the access which may not always be present. You will need to contact NXP specialists for such question or better give it a quick try.

Personally I would try to use an external integrated solution for this part if possible.

What I also don't know is whether you need to just record "after" a trigger event or also need to record a certain amount of time before it takes place. In the first case just waking the processor from a comparator would be the simplest with the lowest power consumption.

Regards

Mark

xavierlajoumard · ‎04-24-2018

Hello Mark,

As always, thanks for your answer. It is helping me a lot narrow down my implementation solution.

I do need to record continuously yes because I need a second pre-trigger worth of data. I also realized that the 16-bit ADC of the K24F wouldn't be enough for my application which means I will be needing an external ADC with ENOB ≥ 16 bits. That being said, I have two options remaining:

1. Wake-up the MCU at every sample and compare.

2. Use an external ADC with built-in FIFO and threshold detection and wake-up the MCU either when FIFO is full or when threshold is passed.

Solution 1 is definitely feasible but solution 2 I am not sure. I have not found any ADC with built-in FIFO and threshold detection that have ENOB ≥ 16 bits. Do you know any ADCs that satisfy these criteria?

Even though I wouldn't be doing that, I am still curious to know if it is possible to store on the internal RAM of the MCU when in VLPS? I understand this cannot be done, to the best of your knowledge, from an external device, but could it be done from the internal ADC?

Thanks for all your help.

Sincerely,

Xavier Lajoumard de Bellabre

mjbcswitzerland · ‎04-24-2018

Hi Xavier

I think that what is mainly driving your design is the power consumption and if there does exist a low power integrated solution which can sample and store automomously for a couple of seconds you would only need to check the data occasionally to search for triggers. Since this requirement is quite common I expect that something exists but I don't know of a particular solution - having programmable thresholds to wake only when of interest would be perfect.

I have used AD7770s with Kinetis for multiple 24 bit inputs via SPI and personally I would be tempted to use something like this - sleep as long as possible between interrupts, get the data, check levels and store as quickly as possible and sleep as soon as possible again. There are various factors affecting current consumption including of course the run speed which can also be fairly slow to do the work, until triggered, after which it can switch to full speed.

Here is a recording of the SPI bus to an 8 channel 24 bit AD7770 reading via SPI, whereby in this case it is one of two such buses being read in parallel. It is not super- efficient since during the actual SPI transfers the processor is also doing some floating point scaling and other processing on-the-fly (in parallel) which doesn't merit fastest possible transfers but is can be seen that you are looking at maybe 3..6us of activity (with tighter SPI timing) each sample and the rest of the time the processor will (depending on exactly which low power mode is most suitable) be consuming hopefully little current.

Since the FlexBus of the K24 is a bus slave I doubt that it is possible to write to SRAM (which is also a bus slave in the K24) from an external device.
The internal ADCs can't write to SRAM themselves, they either need the CPU to do the transfer or DMA, whereby in low leakage modes such activity is generally not possible since they are also sleeping.

Regards

Mark

uTasker developer and supporter (+5'000 hours experience on +60 Kinetis derivatives in +80 product developments)
Kinetis: http://www.utasker.com/kinetis.html

mjbcswitzerland · ‎04-06-2018

Hi Xavier

There are a number of processors that you can use (just check that the chosen one has FlexBus for the external SRAM or a DRAM controller) - for example K22F, K60F, K61F, K64F, K66F with floating point unit. The other peripheral requirements are easy for these chips.

Apply for a free uTasker professional license since it contains immediate solutions for such things including optimised CMSIS FFT or variable length FFT which have been developed for vibration analysis so you will be able to concentrate on the application rather than the libraries - it will also enable you to simulate the complete chip and allow easier verification of the algorithms.

DSP document: http://www.utasker.com/docs/uTasker/uTasker_DSP.pdf
Real-time FFT reference: https://www.youtube.com/watch?v=n-GABeILGV8&feature=youtu.be

Regards

Mark

P.S. The ADCs include automatic threshold detection which may be useful since the processor can also sleep (to save power) when there is no signal requiring analysis.
This is also discussed in http://www.utasker.com/docs/uTasker/uTaskerADC.pdf

Free Open Source solution: https://github.com/uTasker/uTasker-Kinetis
Working project in 15 minutes video: https://youtu.be/K8ScSgpgQ6M

For better, faster, cheaper product developments consider the uTasker developer's version, professional Kinetis support, one-on-one training and complete fast-track project solutions to set you apart from the herd : http://www.utasker.com/support.html