On Tuesday 06 November 2007, Mario. wrote: >Now you speak my language! >In PAL and SECAM it was 64us exactly and it is a quartz delay line, >not glass,
Corning glass made the first ones for us never twice the same color folks, microphonic was a gross understatement though, and was the major failure mechanism. The other was poor acoustic contacts at the peizo stuffs, so gain wasn't wholly predictable, often picking up the speakers vibrations. >and it was in every color TV since there was no other way >how to do it in the early days. (the little box had a whole TV line in >sonic transit! :D) - so it was not only delay, it was a FIFO with >resolution of about 1000-2000 entries, what we would call it in the >digital plane. > >But doing a simple "comb" FIR filter as you propose is a good idea >anyway and very, very easy to implement in few lines of asm or C. Were I doing it, I'd probably do it in 6x09 assembly, I wrote quite a bit of utility stuff for the Color Computer back up the log 20 to 10 years ago, some of which is still used by that group. However, that would be about an order too slow for this, and not more than 16 bits wide if running on a 6809, and 32 but slightly slower since memory access is only 8 bits wide on both chips, on a 6309. The Hitachi 6309 was the 8 bit industries best kept secret for many years as Hitachi was contractually required to market it as a direct 6809 replacement only. But the C version (HD63C09E) can run at 4mhz too in addition to having more functions and registers the 6809 never had! >Only >thing we really need is to supply exact schematic drawings, exact >coefficients to multiply to counteract the errorneous output. We do >not want do only do 'some' filtering, ideally we want exact >counterfilter for our aches. And we need someone with good math skills >to show us precisely how. Which leaves me out based on educational level alone. I may be a well regarded tv broadcast engineer, but I leave the math stuff to an sci calculator as I have only a GED, having quit school back in the first year of high school to go fix tv's for cigarette money in about '48. Nasty habit, quit cold turkey 19+ years ago. But as I see it, a broadside shift register of sufficient width, say 32 bits, with the contents of the first register to be the sample from the encoder in real time, but this is actually the last register loaded, the 2nd register is copied to the third as the first step, then the 2nd register is loaded with the old contents of the first register, then the first register is updated with the current input data. Then the bit twiddling begins. Then the first and third are added & that result bit shifted two bits toward the LSB to scale it. Probably shifted first for overflow reasons in 2-comp math, then added. Then the 2nd register is bit shifted one bit toward the LSB and added to the output of the combined 1st & third data to get the remains of the sample frequency out, or subtracted to give a sample frequency out whose average value would be zero. I think. I'd have to write and test it, but I know zip about amd-intel (x86) assembly. This should work quite well as a 'counter filter for our aches' if driven by the same clock (I'd assume a hardware timer IRQ for that) that drives the sampling process. And yes, it would result in a one sample period delay up front, plus a 3 sample stabilization time at start or stop. >On 11/6/07, Gene Heskett <[EMAIL PROTECTED]> wrote: >> On Monday 05 November 2007, Jon Elson wrote: >> >Kenneth Lerman wrote: >> >> Steve, >> >> >> >> The problem with a filter is that it introduces a delay. So a two-tap >> >> filter would introduce a delay of at least one servo cycle. Is that >> >> better or worse than just halving the servo cycle? Could feedforward >> >> compensate for that? >> > >> >No, if you set up the order of the processes correctly in the >> >script that installs the hal components, there is actually NOT a >> >total delay of all frequency components. You would set it up so >> >that the servo thread reads the encoders, then does the PID, >> >then the filter, then the selected servo output. This is in the >> >addf commands in ..../configs/univpwm/univpwm_load.hal, for >> >instance. >> > >> >The filter takes the current input times a coefficient, then >> >adds several previous samples times their coefficients. >> >Depending on how much each sample is weighted, there would be >> >more delay on the lower frequency components with a low-pass >> >filter. I'll have to see how this works. Since it is filtering >> >the command OUTPUT of the PID, it shouldn't increase error that >> >much, IF you can make the loop stable. >> > >> >I'll have to think about the notch filter vs. low-pass filter >> >thing. Maybe I really want a notch filter at 1/2 the sample rate. >> > >> >Jon >> >> Some food for thought Jon, although I don't expect it to be called new. >> >> In tv, we use, in the better tv's, a 'comb' filter to separate the >> luminance from the chroma. It works as a 3 tap delay line where the first >> and last tap each supply 25% of the output signal, and the center tap >> supplies 50%. The two mixed signals are then obtained by adding the first >> and last tap, and subtracting the center tap to recover the 3.58mhz chroma >> signal, and adding the center tap to recover the luminance signal. >> >> There are two ways to do this in a tv. If the delay is 63.333 u-secs for >> each delay, then a very good vertical resolution enhancement can also be >> done, but if the delays are only 135ns, or half a color subcarrier cycle, >> only the horizontal resolution is enhanced. The longer delay was at one >> time done in very expensive glass acoustic delay lines, so that was only >> available in high end studio monitors. I believe that may be available in >> silicon now but have no actual knowledge to back that up. >> >> This same idea done digitally by a parallel transfer between 3 8 bit >> latches, clocking it by the same clock as the sample clock, could do a >> very good job of removing the 1/2 sample noise if the output was from an 8 >> bit digital adder. Much faster that way than in cpu cycles although it >> could be done if the sample rate was low enough. 1khz at 32 bits >> resolution is certainly doable by the cpu, maybe 10khz with good coding. >> >> Just throwing the idea out there as its easier to code than hack a board >> full of TTL stuff. >> >> -- >> Cheers, Gene >> "There are four boxes to be used in defense of liberty: >> soap, ballot, jury, and ammo. Please use in that order." >> -Ed Howdershelt (Author) >> You will be run over by a bus. >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers > >------------------------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. >Still grepping through log files to find problems? Stop. >Now Search log events and configuration files using AJAX and a browser. >Download your FREE copy of Splunk now >> http://get.splunk.com/ >_______________________________________________ >Emc-developers mailing list >Emc-developers@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/emc-developers -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) No sooner said than done -- so acts your man of worth. -- Quintus Ennius ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
