As a follow-up I had a chance to look at my frequency signal with a digital scope and found that it was indeed unstable to the tune of 20%. I had not expected that as I used an LM331 chip with seemingly appropriate components. Hooking a real function generator to the input worked great, with the expected ~2% fluctuation (20,000 ns base thread sampling a 1kHz signal).
I'm now looking closer at my circuit and supply voltages to determine where the variances are coming from. Very glad this is not a problem in the parallel port hardware nor LinuxCNC, and glad to see with the function generator I should be able to get a usable input once I am generating a frequency appropriately. Thanks everyone for their insight on this issue. Scott On Mon, Jul 2, 2012 at 9:01 AM, Jon Elson <el...@pico-systems.com> wrote: > Scott Hasse wrote: > > John is correct. My logging could be more clear. The "time between" is > > the since the last rising edge of the input pulse as detected by the > update > > function of the encoder running in the base thread. The "counts between" > > is the number of base thread runs since the last rising edge input pulse. > > The time goes with the count of runs directly below it. For the sample > Jon > > referenced, I believe the the two data points are: > > > > 40 runs in 796760 ns = 19919 ns/run > > 60 runs in 1195140 ns = 19919 ns/run > > > > The 1035788 ns time is actually from 52 runs, also = 19919 ns/run > > > OK, I admit I didn't read the code, so I made wrong assumptions. Well, > then, if this isn't > thread jitter, then the pulse source must be quite irregular. Or else, > the device reading > the input signal is pretty imprecise in detecting it. > > Granted, this is the time passed into the update function as the period, > > not an actual system time, but I think that shows there is very little > (if > > any) thread timing jitter. There is absolutely variance there, but the > > data I have would seem to point toward an unstable input signal (or > somehow > > a significant amount of random variance being introduced somewhere > between, > > which would be very odd), but it would also be odd for my input signal to > > vary based on the way I am generating the signal. I can confirm all that > > once I get back in a week or so. > > > It will be interesting to find out what the cause of this is, but if the > test signal is no good, then > the test doesn't answer any questions. > > Jon > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
