Search results

you mentioned some correction on the cycle count according to the PPS, how exactly do you do this? I see you mention an IntervalTimer, are you using this timer to increment the 1us counter? Mine also demonstrates the tendency of being behind by come CPU cycles when the 1s PPS arrives. Perhaps...

Update: think I've discovered the problem: interference. I'm not sure if all instances were cause by this, but I know this can at least be a very potential cause. While gathering some data, I noticed the alarm was spiking when a stood up, a little more investigating revealed that compressing...

UPDATE with oscilloscope. Note connections are suboptimal so additional ringing may be there. As before, logic analyzer row 1 is 200 hz, row 2 is alarm, and row 3 is row 1 analog measured. I'm using the script from p#31. The whole capture is The specific glitch I'm focused on is Zooming in...

Update, got a hold of an oscilloscope, been trying to capture this but it's difficult keeping a sufficiently large window but also sufficient resolution. So that's a work in progress. Otherwise: connecting with a USB hub and measuring analog on the logic analyzer I found the phenomenon. I used...

I wrote their support team a mail yesterday so I'll hopefully be in touch with them after the weekend. That being said I feel relatively confident this isn't aliasing in the measurement, because I've connected a sensor (the original point of the more complicated code is triggering sensors) and...

And actually ringing in general isn't a huge problem for my rising edges. I can take another picture on monday but the analog mode captures a bit of overshoot (0.2V perhaps) and that's about it. Immediately settles to 3.3 after. The glitchy region is actually quite far from the expected HIGHs...

my logic analyzer has an analog mode which caps at 50MS/s, I'll give that a try as well, but this drastically reduces the recording time. One additional point, I feel at some point there may have been a misunderstanding. Here I show two 10us wide HIGHs, these are highlighted by the yellow...

Thanks, I really appreciate the help. The peaks for me if I measure at full speed (500MHz) will come as 5 or 6 peaks with max 8ns width, something in this range. The signal itself is relatively consistent in this form. In another comparison above I attempted sampling lower (25MHz) to compare...

It happens not so often, but it's quite repetitively a burst of rising edges between two normally spaces rising edges, as in https://forum.pjrc.com/attachment.php?attachmentid=30414&d=1676654125. Honestly, I am at a loss for what's wrong with my setup. Maybe I'll try with one of the legacy...

Okay I see, thanks for the explanation. I'll try again and see what happens. Note I attached a sensor to the output and it demonstrated weird behavior in the same region as one of these pulses. So it seems as though something may actually be happening here. Not sure why it's only affecting me...

I set pin 1 to LOW with digitalWriteFast(_pin_gnd_, LOW);. Is this not sufficient as a ground source? Maybe not in the case of signal quality? Edit: Same thing happens regardless of whether I'm connected to pin 1 with digitalWriteFast(1, LOW) or connected to the pin labeled "gnd"

Not entirely sure I understand, what do you mean by real ground? Isn't digital out low connected to the USB cable ground?

How different is my physical setup from yours? I figure this has very limited possibility for interference as I've tried to route cables separately from one another, but at this point I really don't know. Note, now I've tried to switch out the cable harness, switching to the other set of...

I haven't tried grounded the unused inputs, they're just hanging. I'll give that a try though. Will be disappointing otherwise, I think this one is supposed to be relatively "fancy". Whatever that means. Would make sense if it was the logic analyzer though, can't explain whythis would happen...

@luni so perhaps it's my logic analyzer? I've tried with 2 separate teensy's so it shouldn't be a busted MCU. Which logic analyzer are you using?

I set my logic analyzer to 25 MS/s (I couldn't choose 24MS/s) and got this If I zoom in it's 40ns this time, but still happening Note this happened after recording for approximately 3s. It continues happening sporadically for the remainder (recorded 30 mins by accident) and the 4 I've...

Debugging this has been troubling me a great deal now at this point. I've written a very basic script which polls in `loop()` to create a 200Hz square wave with 10us high time. My logic analyzer (saleae logic pro 8) reports f_mean 200.000503 Hz with 3.27ns standard deviation for the first 40...

To be honest, not sure if it's actually fixed, I'm still seeing some occasional rippling on the digital output from the teensy. I'm not 100% convinced it's the logic analyzer, this ripple is happening here in the middle where the widest HIGH is 6ns. Logic analyzer is set to 3.3V logic level...

sending rtc.enablePeriodicUpdateInterrupt(true, false); causes the rtc to make a 1hz interrupt on the INT pin. Not sure why yours does this, weak signal so suffering from long cables perhaps? I know the INT pin triggers a falling edge, not rising. Maybe CLKOUT is the same?

My additions to the mentioned sketch were essentially RV3028 rtc; bool connectToRTC() { // RTC power and ground pinMode(17, OUTPUT); pinMode(21, OUTPUT); digitalWriteFast(17, HIGH); digitalWriteFast(21, LOW); bool success; Wire.begin(); const bool set_24_hour = false; const...

@defragster I just tried your script from #23 and I'm not seeing the same bounce, at least for this short time period: Waiting for PPS toggle ... us 2389086 cyc diff 1537 err= 2.56 us us 3389086 cyc diff 950 err= 1.58 us us 4389084 cyc diff -626 err=-1.04 us us...

At least I think that's the case, hard to say whether the logic analyzer is wrong when I base my "correct-ness" on the logic analyzer output :) I'm not sure before/after would show much, my cable length isn't extreme anyway. The main debugging came from gathering analog simultaneously and...

So then if we assume that the teensy has no room for improvement (10 bytes at 200 hz with Serial.send_now()) then is there really anything possible to do on the linux machine, aside from switching to a real-time OS? Regarding the previous comments I've attached the source code.

Is it expected that there's enough overhead on either side such that 8.5 us becomes >5ms? That seems like a drastic step.

I think this was the misunderstanding, what you quote is some silly python script I found to "estimate" the latency. The code to demonstrate what I'm trying to troubleshoot is the first code block, which starts with #include <Arduino.h> #include <TeensyTimerTool.h> const uint8_t _pin_ = 1; //...

I'm not flushing on the PC side, except for immediately after making the connection. I can try flushing on the teensy side, but from what I read on https://www.pjrc.com/teensy/td_serial.html it sounds like it does the same as Serial.send_now(). Is there a meaningful difference? Edit: some...

The python script is a one-time dummy thing I had on me at the moment. The actual PC interface is in C++ and looks more like this code snippet from the original post while(True){ if (serial_conn_->available()) { if (first_iteration) { first_iteration = false...

So I've done everything possible on the teensy side of things. I know it's not a general PC forum but what about on the computer side? Are there settings for usb interfaces which can be tweaked? I wish I could ask more specifically but I'm not extremely aware of how usb comms work This was...

When you say do you mean the latency suffered when using an OutputFlush() on a non FTDI device, or that latency in general suffered with non FTDI devices? Please correct me if I'm wrong, but the teensy 4.1 (and teensys in general) are non FTDI devices, right? I figure this is the case because...

I am working on a sensor triggering project with a teensy and am nearing the end, but have stumbled upon some very haphazard latency in the serial communication to the computer. The code is relatively long at this point so I won't post everything but the basic gist is #include <Arduino.h>...

regarding the original thread, after some inspection of both analog and digital channels in my logic analyzer, it seems likely that this was noise in the digital measurements. Very anticlimactic

micros overflows after 71 minutes right? Or am I remembering incorrectly. I had a couple questions to this, I know there's the systick interrupt which goes at 1 ms. So I figure millis uses this in part for timekeeping. I was curious do micros and ARM_DWT_CYCCNT suffer from the same drift? Or is...

@luni, okay yes I see. Thanks for walking me through the troubleshooting.

Yeah you're right I didn't see it This shouldn't make a difference here though right? The problem is the first iteration is too long, which means the if statement if (g_is_high && (g_falling_edge_timer >= g_width)) is happening relatively late. The g_falling_edge_timer is zeroed when the...

Cheaper than GPT? Probably no right? Because GPT uses hardware right? Anyway, the main question was more about understanding than fixing, I couldn't really find a reason for this to be happening so consistently, because it happens extremely consistently.

I'm using this teensy for a larger project, but one problem I noticed is that when I use elapsedMicro to create square pulses, the very first one is always longer. Can't really figure out why, this is for simple baseline so a solution like "use IntervalTimers instead" doesn't really make sense...

From what I've read the teensy's inbuilt RTC crystal is rated worse (20ppm I think), though I've read of people demonstrating as low as 8ppm performance, think that was a post from you actually. Ok cool sounds, interesting. A little off-topic for the post but I'm interested to see how this...

micros_from_second is only accessed in the callback and the ISR, but actually it's not so important because the described behavior happens when I comment it out as well, still working on the up-to-date minimal example to demonstrate the behavior. All ISRs are on the default priority, both that...

i think you misunderstand me, it's less for never-ending optimization and more for learning good practices, particularly regarding ARM_DWT_CYCCNT. I feel I've seen this mentioned but without a rationale for when it makes sense to use. Edit: also the led intention was as a heartbeat, so it's...

I have a need for timing things in general, sometime particularly short durations. To this extent I have a couple of questions on best practices in this context Suppose that I have something like the following void loop(){ if (event1_timer >= THRESHOLD1){ // do some stuff...

What's going on in line 463 of your csv? Formatting of the time[s] becomes a bit interesting. Otherwise mine uses more or less the same format, so the python script should be usable. 0.997303625000000,;0;0;0 1.002.293.875.000.000,00;1;0;0 1.002.304.375.000.000,00;0;0;0 I agree this looks...

Fair enough, I'm lucky enough mine can take measurement over a range, so it calculates all of these metrics for me. I have a python script for the same, but I'm not sure how much use it will be if our data isn't of the same format.

I thought I posted a response to KurtE but I see it didn't go through. The response was that I had tried commenting out the Serial.write line and that the error was still happening after approx 100s of capturing. Trying to progressively cut down on the minimal example to isolate the cause, sorry...

My reading side is typically a c++ program which, should, read everything as it comes. At least it looks that way. But when i was capturing the data which I used for the plots above and to check the minimal test case fails, I'm pretty sure I just let it go to monitor. I can verify this and try...

Sorry for spamming this thread. I've managed to create a test case which fails the same way, first run was successful, second run resulted in 200Hz f_max over 1kHz and the 10Hz signal having a std deviation of >1ms Here are the files for the test case, I hope it's simple enough. Tried to keep...

It's one of three periodic callbacks (each associated with an intervaltimer) which has these delays. It happens in larger degree to the low frequency ones, but all three suffer (almost simultaneously) as you can see from the plots in my previous post. So I'm not sure if changing the priority...

Here are some figures I made illustrating all sampling times > 1 std deviation from the mean Note these are all grouped, and many of them happen when all three triggers fire on the same timestamp (as observed by logic analyzer) Edit: Correction to what I said. Actually every time the logic...

I'll try and get back to you with a simple example, as I said it's not necessarily extremely regular. For example, for the 10Hz timer I processed the data in python and the following is the first 10 entries of sampling time, where I've sorted from low to high. # row nr sampling time [s]...

Following https://forum.pjrc.com/threads/71506-Time-synchronization-and-triggering-sensors https://forum.pjrc.com/threads/71671-Augmenting-Teensy-millis-timing-with-external-RTC I am working on a sensor timing project, I'm nearing the end now however I still have a couple of minor problems I...

Great, thanks! And yes of course, I think my current intention would be something along the lines of set(){ // initialize second_counter to RTC unixtime, i.e. seconds since 1 Jan 1970 // ensures timestamp is, more or less, date accurate. Assuming RTC has been updated recently }...