Teensy 3.2 for BLE project reading fast pulses at 15-20ns periods?

Status
Not open for further replies.

fe7565

Member
I am working on a project that currently works with Adafruit's 32u4 Bluefruit BLE (using the onboard Nrf51822 via hardware SPI). The problem is that the 32u4 MCU is only 8Mhz and I am trying to expand the capability to read 70-100us pulses on rare occasions vs the designed 800us pulses. That requires around a 80 Mhz MCU like the Teensy 3.2.

My limitations:
I mainly familiar with Arduino IDE only (your product line seems to have some great Arduino support/examples)
I need to interface (ex.) Nrf 51-52 BLE 5.0 (possibly 4.2) with the Teensy, so has to have Arduino-friendly BLE code\examples out there (UART or SPI)
Hoping to use around 10ma for the MCU, but the MCU should be able to go sleep below 2mA and respond to external interrupts
Ability to surge to 90Mhz for short durations, but also able to operate between 8-20 MHz for low power use near 10mA.
Will add LiPo charging (I see there are 3rd party solutions for Teensy)
I think that the Teensy 3.2 would work. The faster Teensy MCUs would use too much power for the simple task of reading one-shot pulses and sending the data to BLE.

Would you have any different recommendations? I wish there would be a Teensy with BLE built-in to make it easier 🙂
 
I am working on a project that currently works with Adafruit's 32u4 Bluefruit BLE (using the onboard Nrf51822 via hardware SPI). The problem is that the 32u4 MCU is only 8Mhz and I am trying to expand the capability to read 70-100us pulses

Does "read" mean "detect" or "measure the duration of" or what? A simple pulse stretcher using a monostable might be enough.
 
Thank you for the reply. It's for measuring the pulse duration, a one-shot pulse. I will look into that option, and learn about it.
 
A pulse stretcher won't measure anything, it just makes pulses long so they are easier to detect. You need
a very high speed counter I think, or an analog circuit to integrate charge during the pulse, and a means to
sense this and reset it for the next pulse.
 
You use both nano-seconds and micro-seconds, so I guess the former is the resolution you need. Consider using a teensy 4.0.
 
I agree that the Teensy 4.0 would be superior to the Teensy 3.2 as far as MCU speed and time resolution, but I am concerned about the power use. For a battery application, I hope to keep it at around 10mA, with occasional higher MCU speeds at 20-30mA.
 
I started to look into this one-shot pulse stretcher... Very very interesting! This is a fairly old IC from around 2006, so I am sure there are faster ones out there now.

LTC6752 LTC6752-1 LTC6752-2 LTC6752-3 LTC6752-4 - 280MHz, 2.9ns Comparator Family with Rail-to-R.png
 

Attachments

  • LTC6752 LTC6752-1 LTC6752-2 LTC6752-3 LTC6752-4 - 280MHz, 2.9ns Comparator Family with Rail-to-R.png
    LTC6752 LTC6752-1 LTC6752-2 LTC6752-3 LTC6752-4 - 280MHz, 2.9ns Comparator Family with Rail-to-R.png
    94.1 KB · Views: 71
Last edited:
While it's great for detecting the occurrence of very short pulses, note that it's not what you want to measure a 100 usec wide pulse accurate to 20ns.

As Mark said, you could use a fast timer interval counter that is switched on/off and then read.
 
The shortest expected pulse would be about 70us which needs to be measured at (around) a resolution of 18ns for the accuracy I need. So I went with 10ns for design to allow for some accuracy "overhead". That is between 4000-7000 counts/ticks (18ns-10ns ticks) for the 70us signal. If I stretch the 70us signal to be measured to 700us and use the currently available 125ns tick interval of the ATM32u4, I get about the same accuracy as using an 18ns tick for a 70us signal to be measured.
 
Last edited:
A pulse stretcher won't measure anything, it just makes pulses long so they are easier to detect. You need
a very high speed counter I think, or an analog circuit to integrate charge during the pulse, and a means to
sense this and reset it for the next pulse.

I thought that once the 70us one-shot pulse I need to measure is "lengthened" to say 700us, I can measure it with good accuracy using the currently available 125ns tick I have in my old ATM32u4?
 
> You mean the MCU's timer or a dedicated IC?

Either one. The MCU's is better if it can do it.
 
Not sure what a fast "timer interval counter" is. You mean the MCU's timer or a dedicated IC?

Just any fast-enough timer/counter hardware - various ways that could be implemented, but 18ns resolution means hardware
only implementation (whether that's a peripheral inside an MCU or separate chip or whatever).
 
If you're worried about power consumption, the Teensy 4.x has several "low power" modes, as detailed here: https://www.nxp.com/docs/en/application-note/AN12085.pdf

It can wake on interrupt or timer events. Whether it will wake up fast enough to do what you need is specific to your application, and how frequently it needs to do this will influence battery usage.

We're talking about 20ns resolution for upto 100µs pulses, I think custom fast counter hardware is the only way, the more I think about it,
and there's probably a chip designed to do this - probably quite costly though.
 
With enough time, oversampling and possibly repetition you might get the results you need from analog integration and then reading with an ADC. A known calibrating pulse just before a real pulse would help accuracy. Can you tell us more about the application?
 
I think you need somewhere around 100MHz for this. TI has one that will do up to 70MHz and it's less than a buck.
 
i am surprised that there has been no discussion of the FreqMeasureMulti library. The code is there and simple to test, so why not give it a try.
 
Status
Not open for further replies.
Back
Top