Teletype Timing Issues, CV Edition :-)

[rikrak]

the handler now checks the pin state to decide whether or not to fire the script depending on your configured $.POL . If the input is low again by the time that check happens it might not fire the script.

This would tally with my experience above.

[jnoble]

I also noticed that sending a clock of certain speeds to trigger a TR.P from script 1 caused the length of Gates out of 1 to be (cyclically) variable. I wonder whether incoming triggers of certain speeds can cause dropped triggers - eg when they are spaced as a certain division/multiple of TR.TIME.

If that makes little sense, I’ll make a video later to illustrate.

Check above for a discussion of this issue.

[sliderule]

FYI, I have been working on a new scheduler core that uses custom timer adjustments with CPU cycle count feedback adjustment that does everything on a single timer. It would be millisecond accurate for all DEL, TR.P and METRO, and could guarantee execution priority and predictable timing, even with triggers (the trigger ISR flips a bit and the trigger is processed only when it wouldn’t interrupt the timing of M, DEL, etc).

CV slew update throttling is a current bugbear, insofar as producing predictable results in busy patches.

I had previously shelved the design as I read that timers were adjusted in a subsequent release and thought they might have been good enough for most applications.

If a millisecond-accurate Metro is still desirable, I could try to finish up work on it. It would have to be experimental for some time as it is a significant departure from the current scheduler.

Let me know.

[jnoble]

20 characters of

Edit: I am also signing up for detailed testing with my recently upgraded Rigol scope.

[jnoble]

Asking here since someone here likely knows the answer:

Where in the H - E - double chopsticks is INIT_SCRIPT set!!! ??? No luck with grepping around at all …

[csboling]

Strangely, it is in turtle.h, accompanied by a comment on the misplacedness of this enum: https://github.com/monome/teletype/blob/38668cacaf64d696023430250339c936df6b2653/src/turtle.h#L43

[jnoble]

Hah, I was looking right at it but only saw the single line that grep matched–I was looking for a #define!

Adding A, B, and C scripts (and making them callable with $/SCRIPT) was pretty easy once I found that. Thanks so much!!

[csboling]

You may have already found this, but while you’re modding firmware it should be straightforward to change the behavior of P.RM and P.POP to do what you want.

[jnoble]

Thanks! I just spent a few minutes getting USB disk mode to save the new scripts, though reading them back in is proving to be a little fussy.

After that I think I’ll stick to the mainline code for the time being, it’s not that fun to be off in the wilderness when so many smart people are adding cool stuff.

[ether]

What’s the current status on this @sliderule (or other TT devs) ? I’m starting to want to use TT for more master trigger / clock divider duties, and would like it to thwack tightly.

[a773]

I would love to try any improved TT firmware, I’m still bitten occasionally, and trying various work-arounds…

[jnoble]

If you need really tight timing, I don’t think Teletype’s metro is going to work as a master clock. The inherent jitter isn’t too bad according to some tests: about +/- 1ms. But activity like scrolling around in pattern mode and interacting with the grid sim/preview screen introduces hiccups that will cause havoc with things like clocked delays. I use external clocks: TXo is very stable.

Teletype’s responsiveness to trigger inputs and overall speed is quite good! I’d put it up against a 4ms RCD, which I measured at ~130us latency with about 50us of jitter.

@a773, what kinds of workarounds are you having to use?

[a773]

My issues are related to i2c triggers being transmitted on later M cycles. I believe this post came just after my post (hence the title), I’m replying here because in my naive book, everything that improves timing might affect/improve/fix my problem…

Haven’t been able to make it work reliably, currently I’m testing clocking $1 from an external source and triggering $2-7 from $1, no conclusion yet. Other workarounds include abandoning completely or partially i2c and resorting to cables (major bummer)…

The problem takes a while (about an hour) to build, making it hard to troubleshoot.

[ether]

I use external clocks: TXo is very stable.

Thx. I have a TXo so will give that a spin.

EDIT : This works a treat! TXo for 4 separate sync’d clocks, with TT as various clock div / mult / etc. utils. Fun times

[jngpng]

Do you have this code living anywhere online @sliderule? I’ve been thinking about Teletype timing a lot lately, and I’d love to see what you did before I start my own experiments in the area. Maybe I can even attempt to pick the fork up and run with it?