On Aug 11, 4:27=A0pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> > Making the tuning accuracy too fine is a waste of time.
>
> Not to an engineer ;)

I am an engineer with 22 years' experience (UMR 1986).  I also studied
piano at the UMKC Consevatory of Music for sixteen years, starting in
1972.

> > I have found
> > that a string naturally fluctuates in pitch by up to a tenth of a cent
> > or more, even if it is being resonantly sustained.
>
> but how do you know if that variation is the resonance changing, or your
> measurement noise floor ?

Believe me, I have extensively researched pitch and tuning, with help
from the Piano Technicians Guild (of which I am a member) and the ME
department of the University of Wichita.  Counting a 50 MHz clock
gives me much more accuracy than is needed.

> So that's ~477ppm, and the one tenth you mention is 47ppm - and that has
> to be close to the noise floor of sense of a single note (14+ bits),
> (expect rather worse measurement floor on 44 notes all at once!)
>
> > I have also let a string be maintained at a constant PWM for up to
> > three days with no measurable change in pitch. =A0Maintaining the strin=
g
> > at a constant temperature is basically the same as an ordinary piano
> > sitting at room temperature.
>
> Almost : It depends on your total power budget, needed for your thermal
> expansion tuning. All that 'abnormal' heat is going to spread slowly,
> and also dry things out - so you will have a lot of time constants
> in a working system.
>
> How many watts does this typically drain, when running ?

Power consumption is a function of tuning range and how far each
string is out of tune.  A study was done at the University of
Washington where it was proven that a piano varies in pitch cyclically
by less than 20 cents (total runout, worst string) throughout each
year (it was a 3-1/2-year study).  So I am aiming at a tuning range of
about 30 cents to start out with.  This would take about 750 watts if
every single string were the entire 30 cents out of tune (sharp).

Don
Kansas City

eromlignod wrote:
> On Aug 11, 1:49 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> 
>>Yes, I was thinking about running it continuously,
>>or at least close.
>>
>>
>>>On a more practical note, I can't see a stored-cal approach
>>>working very well (too much thermal drifing about..)
>>
>>I agree.
>>
>>-- glen
> 
> Making the tuning accuracy too fine is a waste of time. 

Not to an engineer ;)

> I have found
> that a string naturally fluctuates in pitch by up to a tenth of a cent
> or more, even if it is being resonantly sustained.

but how do you know if that variation is the resonance changing, or your 
measurement noise floor ?

<paste>
 > I need an accuracy of
 > less than one "cent" (1/100th of a musical semitone).  One cent sharp
 > at 27.5 Hz is
 > 27.5 * (2**(1/1200)) = 27.5159 Hz

So that's ~477ppm, and the one tenth you mention is 47ppm - and that has 
to be close to the noise floor of sense of a single note (14+ bits),
(expect rather worse measurement floor on 44 notes all at once!)


> I have also let a string be maintained at a constant PWM for up to
> three days with no measurable change in pitch.  Maintaining the string
> at a constant temperature is basically the same as an ordinary piano
> sitting at room temperature. 

Almost : It depends on your total power budget, needed for your thermal 
expansion tuning. All that 'abnormal' heat is going to spread slowly, 
and also dry things out - so you will have a lot of time constants
in a working system.

How many watts does this typically drain, when running ?

Coefficent of thermal expansion of the range of strings ?
(steel is ~11-13ppm/'C)

-jg

On Aug 11, 1:49=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Yes, I was thinking about running it continuously,
> or at least close.
>
> > On a more practical note, I can't see a stored-cal approach
> > working very well (too much thermal drifing about..)
>
> I agree.
>
> -- glen

Making the tuning accuracy too fine is a waste of time.  I have found
that a string naturally fluctuates in pitch by up to a tenth of a cent
or more, even if it is being resonantly sustained.

I have also let a string be maintained at a constant PWM for up to
three days with no measurable change in pitch.  Maintaining the string
at a constant temperature is basically the same as an ordinary piano
sitting at room temperature.  Gradual changes in humidity are by far
the largest factor in causing a piano to go out of tune anyway.

Don
Kansas City

Jim Granville wrote:
(snip, I wrote)

>> Putting analog PLL frequency multipliers on each string would be
>> interesting, but take a lot of extra circuitry.  I don't know
>> DLL enough to say, but it might work.  I would read up on
>> DLL (that is, the digital version of the analog PLL).

> Why add more jitter/noise ? In my example, a low 1Mhz timebase
> reciprocal counter is 63 TIMES more accurate than the OP's
> 15.9mHz spec - so it has 6 extra bits of precision.
> (500KHz would be my trade-off target)

Yes, I was thinking about running it continuously,
or at least close.

> On a more practical note, I can't see a stored-cal approach
> working very well (too much thermal drifing about..)

I agree.

-- glen

eromlignod wrote:
> On Aug 9, 6:09 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
> 
>>Hmm... has this been proven on a working unit, in the field ?
>>
>>Better would be a system that can _prove_ what you stated, by
>>tracking the frequency even during a performance. It does not
>>have to adjust, but knowing just how many ppm the thing
>>has drifted, would seem a strong selling point
>>
>>-jg
> 
> This would be difficult since no song ever plays all 88 notes.  In
> fact the top and bottom few notes may never get played (I am a pianist
> myself and have never seen music written for A0 or C8).  And if a note
> is played too quickly, like with staccato, there may not be enough
> clean vibrations to get an average.
> 
> There is also the fact that a note's pitch changes slightly with
> volume.  A louder note sounds a little sharp since there is more
> string excursion and thus more tension.  My system magnetically
> sustains each string at a steady, repeatable volume, which is the same
> volume it is sustained at when the tuning is "recorded".
> 
> The whole idea of the system is to get a fresh tuning in a few seconds
> on a daily basis.  Every time you press that button, you could have
> spent $100 and over a hour of inconvenience.

  Understood, but I am talking about making something that is both
calibration/control system (when you push the button), and a
measuring instrument (when playing).
  Sure, playing is dynamic, but you are not making control decisions,
just checking the calibrations.
  Think of it as a seriously precise spectrum plot :)

  Is this a one-off, of do you hope to sell a number of these
commercially (or seil the one-off to someone else, who will
production-engineer it ?)

-jg

On Aug 9, 6:09=A0pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> eromlignod wrote:
> > It's a Spartan-3 and I picked it because of my large number of
> > inputs. =A0Connecting an input from each of the 88 notes lets me avoid
> > an elaborate tree of external multiplexers. =A0
>
> Done right, the external fan-in design can save a lot of bulky wiring,
> and keeps the looming in simple ribbon cable.
>
> We have done Serial/parallel chainable fan-in/fan-out systems
> in designs, and it is very expandable, and simple to loom-up.
> Also has natural cross talk advantages.
>
> You will already have 'remote PCBs' doing the front-end signal
> conditioning ?
>
> How much you 'production enginerr' this, depends on how many of these
> you hope to make.
>
> > I only sustain 44 of the
> > strings at a time (every other note) because otherwise I get
> > interference from adjacent driving magnets.
>
> > The system does not run all the time. =A0It only actively adjusts
> > pitches for the first couple of minutes after you turn it on. =A0Once
> > the strings stabilize at their in-tune pitch, all of the PWM duty
> > cycles are frozen and maintained from that point on and the magnetic
> > sustaining ceases. =A0When the musician is done playing, he switches it
> > off. =A0The next time it is turned on, you get a new tuning for that
> > day's conditions. =A0This also keeps the system simple, since there is
> > only one button.
>
> Hmm... has this been proven on a working unit, in the field ?
>
> Better would be a system that can _prove_ what you stated, by
> tracking the frequency even during a performance. It does not
> have to adjust, but knowing just how many ppm the thing
> has drifted, would seem a strong selling point
>
> -jg

This would be difficult since no song ever plays all 88 notes.  In
fact the top and bottom few notes may never get played (I am a pianist
myself and have never seen music written for A0 or C8).  And if a note
is played too quickly, like with staccato, there may not be enough
clean vibrations to get an average.

There is also the fact that a note's pitch changes slightly with
volume.  A louder note sounds a little sharp since there is more
string excursion and thus more tension.  My system magnetically
sustains each string at a steady, repeatable volume, which is the same
volume it is sustained at when the tuning is "recorded".

The whole idea of the system is to get a fresh tuning in a few seconds
on a daily basis.  Every time you press that button, you could have
spent $100 and over a hour of inconvenience.

Don
Kansas City

John_H wrote:

> The octave counter only needs to be used for the 3 LSbits and a single 
> BlockRAM used to coordinate the counts and accumulate the 44 channels by 
> adding the LSbits.  Two BlockRAMs would make the whole configuration 
> easier to allow a dual-port for the accumulator on one and the full 
> count (plus scaling?) into one port of the 2nd BlockRAM while the 
> processor side has full access to the other port of the 2nd BlockRAM.

With counters, normally you have a capture register, so that gives
the processor something relatively static to read,

> In the period counter arrangement, the largest error would be on the 
> high frequency side so a 1/100 semitone error on C8 gives a 138ns error 
> for a single cycle.  The "every other clock" at 50MHz for this highest 
> octave easily gives a single-cycle measurement that would give the 
> accuracy you need (80ns error from both sides of a single count); 

Correct. What you describe, with variable capture cycles, is a 
reciprocal frequecny counter.

There are three choices for the Cycles-to-time-over count
determination in a reciprocal frequecny counter.

a) it can be hard coded. (which I think is what you describe)

b) it can be preloaded via SW, which allows elasticity in the gate 
times. (one might try varying times to reduce beat effects)

c) It is Auto-Set by a desired gate time, and smarter logic
takes the first whole cycle number larger than the gate time.

Option c) is the full benchtop reciprocal Counter, and b) is the variant 
I'd suggest for this project. Lets SW have full control, without 
recompile of FPGA, but saves some logic & data bandwidth from c)

> As pointed out by someone earlier, counting multiple consecutive periods 
> rather than averaging multiple counts gives you a much higher precision, 
> spreading the 80ns error I mentioned above over multiple periods rather 
> than just one for a per-period error of 80ns/N for an N period count. 
> Using BlockRAMs to hold the main part of the counters, you have 36 bits 
> to play with for free.  Since the octave counter scales by a factor of 2 
> for each octave, all the counts are the same relative size.

Yes, with a little design care, on a reciprocal counter you can extend 
the precision across multiple readings.

The trick to to not lose time-counts, or edge-counts - If your HE does 
that, then [Cycles/Time] can be added downstream for very high precisions.

This would enable research into the milli-kelvin thermal shifts
going down, long before they became audible

Perhaps a variant of this capture-pathway, could be a 'wide tuner' for
general piano use - more sales ?
Would slash the skill and time needed to tune manually a piano

eromlignod wrote:
> It's a Spartan-3 and I picked it because of my large number of
> inputs.  Connecting an input from each of the 88 notes lets me avoid
> an elaborate tree of external multiplexers.  

Done right, the external fan-in design can save a lot of bulky wiring,
and keeps the looming in simple ribbon cable.

We have done Serial/parallel chainable fan-in/fan-out systems
in designs, and it is very expandable, and simple to loom-up.
Also has natural cross talk advantages.

You will already have 'remote PCBs' doing the front-end signal 
conditioning ?

How much you 'production enginerr' this, depends on how many of these 
you hope to make.

> I only sustain 44 of the
> strings at a time (every other note) because otherwise I get
> interference from adjacent driving magnets.
> 
> The system does not run all the time.  It only actively adjusts
> pitches for the first couple of minutes after you turn it on.  Once
> the strings stabilize at their in-tune pitch, all of the PWM duty
> cycles are frozen and maintained from that point on and the magnetic
> sustaining ceases.  When the musician is done playing, he switches it
> off.  The next time it is turned on, you get a new tuning for that
> day's conditions.  This also keeps the system simple, since there is
> only one button.

Hmm... has this been proven on a working unit, in the field ?

Better would be a system that can _prove_ what you stated, by
tracking the frequency even during a performance. It does not
have to adjust, but knowing just how many ppm the thing
has drifted, would seem a strong selling point

-jg

eromlignod wrote:
> It's a Spartan-3 and I picked it because of my large number of
> inputs.  Connecting an input from each of the 88 notes lets me avoid
> an elaborate tree of external multiplexers.  I only sustain 44 of the
> strings at a time (every other note) because otherwise I get
> interference from adjacent driving magnets.
> 
> The system does not run all the time.  It only actively adjusts
> pitches for the first couple of minutes after you turn it on.  Once
> the strings stabilize at their in-tune pitch, all of the PWM duty
> cycles are frozen and maintained from that point on and the magnetic
> sustaining ceases.  When the musician is done playing, he switches it
> off.  The next time it is turned on, you get a new tuning for that
> day's conditions.  This also keeps the system simple, since there is
> only one button.
> 
> Don
> Kansas City

So the tuning mode results in a constant square wave for each of the 44 
channels?  I was wondering how the system would decide when the square 
wave was "stable enough" to have reliable measurements.  The continuous 
feed simplifies many decisions.

The "Spartan-3" mention supplies a family, but the curiosity was more 
around the size of the part for the number of BlockRAMs and LUT 
resources (which is also different for S3, S3E, and S3A).

If you have a table full of count values, do you then just want to read 
these with an external processor?  Do you want to have processing done 
on the signals inside the FPGA?

Personally, I liked the earlier suggestion of defining the target period 
count and just measuring the delta value: the period error.

The approach I'd enjoy coding up would use the distributed SelectRAM 
memories as counters and use an "octave counter" configuration (my 
concept for the unique requirements of your project) which would count 
the C8 period every 2 clocks, C7 every 4, C6 every 8, all the way down 
to C1 and C2 each counted only every 128 clocks.  All eight octaves 
count with the same percent resolution relative to the period and use 
significantly less logic than one counter per key.  6 channels of the 
octave counter then give you the 44 channels at a time with a 2:1 mux to 
select odd or even keys.

The octave counter only needs to be used for the 3 LSbits and a single 
BlockRAM used to coordinate the counts and accumulate the 44 channels by 
adding the LSbits.  Two BlockRAMs would make the whole configuration 
easier to allow a dual-port for the accumulator on one and the full 
count (plus scaling?) into one port of the 2nd BlockRAM while the 
processor side has full access to the other port of the 2nd BlockRAM.

In the period counter arrangement, the largest error would be on the 
high frequency side so a 1/100 semitone error on C8 gives a 138ns error 
for a single cycle.  The "every other clock" at 50MHz for this highest 
octave easily gives a single-cycle measurement that would give the 
accuracy you need (80ns error from both sides of a single count); at 
this point your system error is probably much more an issue of the noise 
(measurement jitter) in the square waves from the sensors.  The octave 
counter approach give you the same percentage error on all octaves for a 
single key.

As pointed out by someone earlier, counting multiple consecutive periods 
rather than averaging multiple counts gives you a much higher precision, 
spreading the 80ns error I mentioned above over multiple periods rather 
than just one for a per-period error of 80ns/N for an N period count. 
Using BlockRAMs to hold the main part of the counters, you have 36 bits 
to play with for free.  Since the octave counter scales by a factor of 2 
for each octave, all the counts are the same relative size.

If you wanted to pursue the error count rather than the raw count values 
for each period, you could even multiply the errors by a defined 
constant for each key to give you a scaled error that's appropriate to 
feed your system adjustments and have all your processing easily handled 
within the single FPGA.

This kind of stuff is just fun.