Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

digitalPulse() not working for very short pulse lengths #1749

MaBecker opened this issue Jan 20, 2020 · 5 comments

digitalPulse() not working for very short pulse lengths #1749

MaBecker opened this issue Jan 20, 2020 · 5 comments


Copy link

@MaBecker MaBecker commented Jan 20, 2020

see for details.

@MaBecker MaBecker added the ESP8266 label Jan 20, 2020
Copy link

@sleuthware sleuthware commented Jan 20, 2020

Sun 2020.01.19

I made a later comment post 9 at:

regarding non whole numbers within an array. I was working with the MDBT42Q breakout board and ran into a simmilar issue. While still unresolved and not fully researched at 'C' code level, I seem to run into issues when pulses got down to around the 200usec range, approx 8000Hz. The docs really don't explain the limits here, and I still can't locate (just haven't put in the time) where the under the hood timing stuff takes place.

Simple math 1 / 8000 = 125usec

As an observation, if the divisor is from a (not chceked) 16MHz clock crystal, this might explain things.

Working on a project/tutorial to replace an Arduino interrupt driven frequency counter example, but need pulses around 1usec width and detection around 10usec duration. Would this be possible?
EDIT: Roughly 100+ times faster than currently supported.

Will continue to gather test data to determine current limits with 2v04 and when sufficient data has been gathered, start a forum post.


@gfwilliams gfwilliams changed the title digitalPulse() not working as expected digitalPulse() not working for very short pulse lengths Jan 20, 2020
Copy link

@gfwilliams gfwilliams commented Jan 20, 2020

I think the issue you're hitting here is that the timings on ESP8266 are most likely done with the 32kHz RTC. Same thing happens on the NRF52, however STM32 based boards do some crazy stuff to allow them to use a much more accurate timer.

While the high speed timer used for digitalPulse is more accurate, it uses the RTC to re-sync itself, and that means that the actual pulse accuracy for long trains of pulses is pretty limited.

Basically this is the last bullet point on #1444

We could switch to not using the RTC, but that would mean that if for instance you did a 4000Hz waveform capture of 4000 samples, then a setTimeout for 1000ms, the two may not get called at quite the same time

@gfwilliams gfwilliams added high priority and removed ESP8266 labels Sep 30, 2020
gfwilliams added a commit that referenced this issue Oct 9, 2020
… from the hardware timer itself (fix #1749, ref #1444)"

This reverts commit 0c6b0c8.
Copy link

@gniezen gniezen commented Nov 2, 2020

Why was this change reverted? Should the issue maybe be re-opened?

gfwilliams added a commit that referenced this issue Nov 3, 2020
Copy link

@gfwilliams gfwilliams commented Nov 3, 2020

I forget where the discussion on this was now... It didn't seem to make things noticeably better, and was a bit too risky right before the 2v08 release. I've just re-applied it though so I'd be interested to see whether you find real improvements with it

Copy link

@gniezen gniezen commented Dec 14, 2020

I compiled and flashed the latest master branch, but it doesn't appear to have made a difference. I'm still seeing pulse trains of 30ms or more, when they should be 27.5ms (referring to

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

4 participants