forbiddenera
Well-known member
I just measured my shifters again but this time using my dso quad's PWM output at 2mhz and I get about ~15ns knee to knee -- will do the exact same test with the txs0108e-q1 when it arrives and see if it's any better.
I'm showing about 40ns rise/fall time from the scope and it seems to be matched from the shifter, so maybe they aren't that bad but I'm trying to find time anywhere/everywhere
These shifters seem to choke above 6mhz, not that the signal my mini scope puts out at 8mhz is that clean anyway but, it's still obviously worse through the shifter above that speed.
Really need to get these rise/fall times up if I can somehow though.. Considering making a test board soon to remove the long leads. The txs0108 can do like 100mbps push pull, so hopefully it's an improvement.
Tried also testing with just my scope triggering OE# at ~1mhz (which seems to be about the same rate as the target, as far as measured by my scope, though that signal isn't going to be purely perfectly periodic)
I see *much* (obviously) faster rise times out of the teensy when it's not loaded - maybe about 10-15ns - total from scope trigger to trigger response time, unloaded, just outputting FF's is at ~32ns right now. From trigger to knee, ~22ns.
I should maybe note that changing the baudrate of Serial doesn't affect it..and again only happens if something is connected to the port on the USB side.
I wish I had better logic analysis tools but I'm trying my best. I really only know it's glitching because the readout of the lights on my engine simulator.. would be nice to be able to graph exactly when/how often the occasional glitch is happening as well as the serial glitching.. I may try and hook my LA up as best I can but I'm not sure how accurate it is at these time scales.
At 960mhz, I'm seeing at best 22ns from OE low to data high, trigger to trigger, from trigger to knee I see a capture here that's 12ns, although, I'm wondering if my scope is off for this measurement, heh..in fact, further testing I got as low as like 5ns from trigger to knee, and it seems like a lot of the total time is coming from rise/fall, so I'm going to try and shorten the length between devices, reduce any load/resistance/capacitance on the data lines and try the txs0108..
I still need to dig into the libs code though to see about USB interrupts and see what other interrupt might be occasionally happening causing these hiccups though!
But at this point, if I'm really getting under 10ns actual trigger to knee (knee being the point where the teensy *starts* to drive the output line) latency then that's pretty damn good I think and I'm not sure that can be improved, although I'm all ears
I'm showing about 40ns rise/fall time from the scope and it seems to be matched from the shifter, so maybe they aren't that bad but I'm trying to find time anywhere/everywhere
These shifters seem to choke above 6mhz, not that the signal my mini scope puts out at 8mhz is that clean anyway but, it's still obviously worse through the shifter above that speed.
Really need to get these rise/fall times up if I can somehow though.. Considering making a test board soon to remove the long leads. The txs0108 can do like 100mbps push pull, so hopefully it's an improvement.
Tried also testing with just my scope triggering OE# at ~1mhz (which seems to be about the same rate as the target, as far as measured by my scope, though that signal isn't going to be purely perfectly periodic)
I see *much* (obviously) faster rise times out of the teensy when it's not loaded - maybe about 10-15ns - total from scope trigger to trigger response time, unloaded, just outputting FF's is at ~32ns right now. From trigger to knee, ~22ns.
I should maybe note that changing the baudrate of Serial doesn't affect it..and again only happens if something is connected to the port on the USB side.
I wish I had better logic analysis tools but I'm trying my best. I really only know it's glitching because the readout of the lights on my engine simulator.. would be nice to be able to graph exactly when/how often the occasional glitch is happening as well as the serial glitching.. I may try and hook my LA up as best I can but I'm not sure how accurate it is at these time scales.
At 960mhz, I'm seeing at best 22ns from OE low to data high, trigger to trigger, from trigger to knee I see a capture here that's 12ns, although, I'm wondering if my scope is off for this measurement, heh..in fact, further testing I got as low as like 5ns from trigger to knee, and it seems like a lot of the total time is coming from rise/fall, so I'm going to try and shorten the length between devices, reduce any load/resistance/capacitance on the data lines and try the txs0108..
I still need to dig into the libs code though to see about USB interrupts and see what other interrupt might be occasionally happening causing these hiccups though!
But at this point, if I'm really getting under 10ns actual trigger to knee (knee being the point where the teensy *starts* to drive the output line) latency then that's pretty damn good I think and I'm not sure that can be improved, although I'm all ears
Last edited: