Attainable PWM accuracy?

[Lasse Langwadt Christense]

lørdag den 12. oktober 2019 kl. 00.11.46 UTC+2 skrev John Larkin:

On Fri, 11 Oct 2019 14:15:06 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

fredag den 11. oktober 2019 kl. 22.52.50 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 16:17:51 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2019-10-11 15:54, Andy Bennet wrote:
On 11/10/2019 18:16, Phil Hobbs wrote:
Hi, all,

As part of the aforementioned cathodolumiescence system, I'm doing a
bias supply for multipixel photon counters (MPPCs).

MPPCs are extremely voltage sensitive--the gain of this one goes from
~0 to 2E6 between 52 and 55 volts' bias.  (See
https://www.hamamatsu.com/resources/pdf/ssd/e03_handbook_si_apd_mppc.pdf>.)


Sooo, there's a bit of pressure to keep the bias very stable, but it
doesn't have to change very often.  Accordingly, I'm tentatively
planning to use a 12 to 16-bit PWM with good filtering.  It'll
obviously have to be buffered with a tinylogic gate running from a
stiff reference supply, to prevent voltage sags inside the LPC845 MCU
from spoiling the accuracy.

The '845 can run its PWM clocks at 7.5 MHz, so that would be an output
frequency of 114 Hz to 1.8 kHz. I'd need about 100 dB of filtering to
get the output ripple on the MPPC supply down to a millivolt or so, so
that's 3 RC sections with 33 dB attenuation each, i.e. corner
frequencies of 2.5 Hz to 40 Hz (TCs of 4 to 60 ms).  Not
horrible--100k*0.68uF at 16 bits, 40k and 0.1 uF at 12 bits.

Anything else besides buffering and filtering that I haven't thought
of that might limit the accuracy?  How good can you make a PWM, anyway?

Thanks

Phil Hobbs


Rather than PWM, have a look at pulse density modulation which will ease
the filtering requirement. Not sure if this is do-able in software, but
I have used FPGA implementations of this with great success.

Sort of a delta-sigma thing? You can put an M-bit delta-sigma extension
on an N-bit PWM pretty easily using a timer interrupt. I don't think
we could get the required accuracy bit-banging something like that.

Cheers

Phil Hobbs

You can also delta-sigma the LSB of a PWM to effectively add more
bits. That basically interpolates between two PWM levels.

I think that may have filtering advantages. I don't know if a uP can
reasonably do that; we did it in an FPGA.

I guess you could even PWM the LSB of a PWM.

AND a fast and a slow PWM?

You could certainly analog sum two PWMs, maybe before the filter. They
could run at a much higher frequency than a single PWM of the same
resolution.

but then you get the issue of how well analog matched the two outputs are

in hardware there's also the trick of inverting some or all of the bits
in the counter

Sorry, that's too hard to think about.

by inverting I meant reversing the bit order

i.e. 50% output becomes
hi-lo-hi-lo-hi-lo-hi-lo instead of hi-hi-hi-hi-lo-lo-lo-lo

 

[John Larkin]

On Fri, 11 Oct 2019 14:15:06 -0700 (PDT), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

fredag den 11. oktober 2019 kl. 22.52.50 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 16:17:51 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2019-10-11 15:54, Andy Bennet wrote:
On 11/10/2019 18:16, Phil Hobbs wrote:
Hi, all,

As part of the aforementioned cathodolumiescence system, I'm doing a
bias supply for multipixel photon counters (MPPCs).

MPPCs are extremely voltage sensitive--the gain of this one goes from
~0 to 2E6 between 52 and 55 volts' bias.  (See
https://www.hamamatsu.com/resources/pdf/ssd/e03_handbook_si_apd_mppc.pdf>.)


Sooo, there's a bit of pressure to keep the bias very stable, but it
doesn't have to change very often.  Accordingly, I'm tentatively
planning to use a 12 to 16-bit PWM with good filtering.  It'll
obviously have to be buffered with a tinylogic gate running from a
stiff reference supply, to prevent voltage sags inside the LPC845 MCU
from spoiling the accuracy.

The '845 can run its PWM clocks at 7.5 MHz, so that would be an output
frequency of 114 Hz to 1.8 kHz. I'd need about 100 dB of filtering to
get the output ripple on the MPPC supply down to a millivolt or so, so
that's 3 RC sections with 33 dB attenuation each, i.e. corner
frequencies of 2.5 Hz to 40 Hz (TCs of 4 to 60 ms).  Not
horrible--100k*0.68uF at 16 bits, 40k and 0.1 uF at 12 bits.

Anything else besides buffering and filtering that I haven't thought
of that might limit the accuracy?  How good can you make a PWM, anyway?

Thanks

Phil Hobbs


Rather than PWM, have a look at pulse density modulation which will ease
the filtering requirement. Not sure if this is do-able in software, but
I have used FPGA implementations of this with great success.

Sort of a delta-sigma thing? You can put an M-bit delta-sigma extension
on an N-bit PWM pretty easily using a timer interrupt. I don't think
we could get the required accuracy bit-banging something like that.

Cheers

Phil Hobbs

You can also delta-sigma the LSB of a PWM to effectively add more
bits. That basically interpolates between two PWM levels.

I think that may have filtering advantages. I don't know if a uP can
reasonably do that; we did it in an FPGA.

I guess you could even PWM the LSB of a PWM.

AND a fast and a slow PWM?

You could certainly analog sum two PWMs, maybe before the filter. They
could run at a much higher frequency than a single PWM of the same
resolution.

in hardware there's also the trick of inverting some or all of the bits
in the counter

Sorry, that's too hard to think about.

 

[Rick C]

On Friday, October 11, 2019 at 4:52:50 PM UTC-4, John Larkin wrote:

On Fri, 11 Oct 2019 16:17:51 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2019-10-11 15:54, Andy Bennet wrote:
On 11/10/2019 18:16, Phil Hobbs wrote:
Hi, all,

As part of the aforementioned cathodolumiescence system, I'm doing a
bias supply for multipixel photon counters (MPPCs).

MPPCs are extremely voltage sensitive--the gain of this one goes from
~0 to 2E6 between 52 and 55 volts' bias.  (See
https://www.hamamatsu.com/resources/pdf/ssd/e03_handbook_si_apd_mppc..pdf>.)


Sooo, there's a bit of pressure to keep the bias very stable, but it
doesn't have to change very often.  Accordingly, I'm tentatively
planning to use a 12 to 16-bit PWM with good filtering.  It'll
obviously have to be buffered with a tinylogic gate running from a
stiff reference supply, to prevent voltage sags inside the LPC845 MCU
from spoiling the accuracy.

The '845 can run its PWM clocks at 7.5 MHz, so that would be an output
frequency of 114 Hz to 1.8 kHz. I'd need about 100 dB of filtering to
get the output ripple on the MPPC supply down to a millivolt or so, so
that's 3 RC sections with 33 dB attenuation each, i.e. corner
frequencies of 2.5 Hz to 40 Hz (TCs of 4 to 60 ms).  Not
horrible--100k*0.68uF at 16 bits, 40k and 0.1 uF at 12 bits.

Anything else besides buffering and filtering that I haven't thought
of that might limit the accuracy?  How good can you make a PWM, anyway?

Thanks

Phil Hobbs


Rather than PWM, have a look at pulse density modulation which will ease
the filtering requirement. Not sure if this is do-able in software, but
I have used FPGA implementations of this with great success.

Sort of a delta-sigma thing? You can put an M-bit delta-sigma extension
on an N-bit PWM pretty easily using a timer interrupt. I don't think
we could get the required accuracy bit-banging something like that.

Cheers

Phil Hobbs

You can also delta-sigma the LSB of a PWM to effectively add more
bits. That basically interpolates between two PWM levels.

I think that may have filtering advantages. I don't know if a uP can
reasonably do that; we did it in an FPGA.

I guess you could even PWM the LSB of a PWM.

This sort of stuff is easy in an FPGA, even a tiny, low power FPGA. You can also run the clock rate way above 7 MHz which makes filtering much easier..

--

Rick C.

-- Get 2,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

 

[John Larkin]

On Fri, 11 Oct 2019 15:34:20 -0700 (PDT), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

lřrdag den 12. oktober 2019 kl. 00.11.46 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 14:15:06 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

fredag den 11. oktober 2019 kl. 22.52.50 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 16:17:51 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2019-10-11 15:54, Andy Bennet wrote:
On 11/10/2019 18:16, Phil Hobbs wrote:
Hi, all,

As part of the aforementioned cathodolumiescence system, I'm doing a
bias supply for multipixel photon counters (MPPCs).

MPPCs are extremely voltage sensitive--the gain of this one goes from
~0 to 2E6 between 52 and 55 volts' bias.  (See
https://www.hamamatsu.com/resources/pdf/ssd/e03_handbook_si_apd_mppc.pdf>.)


Sooo, there's a bit of pressure to keep the bias very stable, but it
doesn't have to change very often.  Accordingly, I'm tentatively
planning to use a 12 to 16-bit PWM with good filtering.  It'll
obviously have to be buffered with a tinylogic gate running from a
stiff reference supply, to prevent voltage sags inside the LPC845 MCU
from spoiling the accuracy.

The '845 can run its PWM clocks at 7.5 MHz, so that would be an output
frequency of 114 Hz to 1.8 kHz. I'd need about 100 dB of filtering to
get the output ripple on the MPPC supply down to a millivolt or so, so
that's 3 RC sections with 33 dB attenuation each, i.e. corner
frequencies of 2.5 Hz to 40 Hz (TCs of 4 to 60 ms).  Not
horrible--100k*0.68uF at 16 bits, 40k and 0.1 uF at 12 bits.

Anything else besides buffering and filtering that I haven't thought
of that might limit the accuracy?  How good can you make a PWM, anyway?

Thanks

Phil Hobbs


Rather than PWM, have a look at pulse density modulation which will ease
the filtering requirement. Not sure if this is do-able in software, but
I have used FPGA implementations of this with great success.

Sort of a delta-sigma thing? You can put an M-bit delta-sigma extension
on an N-bit PWM pretty easily using a timer interrupt. I don't think
we could get the required accuracy bit-banging something like that.

Cheers

Phil Hobbs

You can also delta-sigma the LSB of a PWM to effectively add more
bits. That basically interpolates between two PWM levels.

I think that may have filtering advantages. I don't know if a uP can
reasonably do that; we did it in an FPGA.

I guess you could even PWM the LSB of a PWM.

AND a fast and a slow PWM?

You could certainly analog sum two PWMs, maybe before the filter. They
could run at a much higher frequency than a single PWM of the same
resolution.

but then you get the issue of how well analog matched the two outputs are



in hardware there's also the trick of inverting some or all of the bits
in the counter

Sorry, that's too hard to think about.

by inverting I meant reversing the bit order

i.e. 50% output becomes
hi-lo-hi-lo-hi-lo-hi-lo instead of hi-hi-hi-hi-lo-lo-lo-lo

That's even harder.

 

[Lasse Langwadt Christense]

lørdag den 12. oktober 2019 kl. 02.20.29 UTC+2 skrev John Larkin:

On Fri, 11 Oct 2019 15:34:20 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

lørdag den 12. oktober 2019 kl. 00.11.46 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 14:15:06 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

fredag den 11. oktober 2019 kl. 22.52.50 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 16:17:51 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2019-10-11 15:54, Andy Bennet wrote:
On 11/10/2019 18:16, Phil Hobbs wrote:
Hi, all,

As part of the aforementioned cathodolumiescence system, I'm doing a
bias supply for multipixel photon counters (MPPCs).

MPPCs are extremely voltage sensitive--the gain of this one goes from
~0 to 2E6 between 52 and 55 volts' bias.  (See
https://www.hamamatsu.com/resources/pdf/ssd/e03_handbook_si_apd_mppc.pdf>.)


Sooo, there's a bit of pressure to keep the bias very stable, but it
doesn't have to change very often.  Accordingly, I'm tentatively
planning to use a 12 to 16-bit PWM with good filtering.  It'll
obviously have to be buffered with a tinylogic gate running from a
stiff reference supply, to prevent voltage sags inside the LPC845 MCU
from spoiling the accuracy.

The '845 can run its PWM clocks at 7.5 MHz, so that would be an output
frequency of 114 Hz to 1.8 kHz. I'd need about 100 dB of filtering to
get the output ripple on the MPPC supply down to a millivolt or so, so
that's 3 RC sections with 33 dB attenuation each, i.e. corner
frequencies of 2.5 Hz to 40 Hz (TCs of 4 to 60 ms).  Not
horrible--100k*0.68uF at 16 bits, 40k and 0.1 uF at 12 bits.

Anything else besides buffering and filtering that I haven't thought
of that might limit the accuracy?  How good can you make a PWM, anyway?

Thanks

Phil Hobbs


Rather than PWM, have a look at pulse density modulation which will ease
the filtering requirement. Not sure if this is do-able in software, but
I have used FPGA implementations of this with great success.

Sort of a delta-sigma thing? You can put an M-bit delta-sigma extension
on an N-bit PWM pretty easily using a timer interrupt. I don't think
we could get the required accuracy bit-banging something like that..

Cheers

Phil Hobbs

You can also delta-sigma the LSB of a PWM to effectively add more
bits. That basically interpolates between two PWM levels.

I think that may have filtering advantages. I don't know if a uP can
reasonably do that; we did it in an FPGA.

I guess you could even PWM the LSB of a PWM.

AND a fast and a slow PWM?

You could certainly analog sum two PWMs, maybe before the filter. They
could run at a much higher frequency than a single PWM of the same
resolution.

but then you get the issue of how well analog matched the two outputs are



in hardware there's also the trick of inverting some or all of the bits
in the counter

Sorry, that's too hard to think about.

by inverting I meant reversing the bit order

i.e. 50% output becomes
hi-lo-hi-lo-hi-lo-hi-lo instead of hi-hi-hi-hi-lo-lo-lo-lo


That's even harder.

nah, swapping bits just means the counter counts in a different order

but amount of numbers larger/smaller than the set point is still
the same

i.e. it doesn't matter if you count to 1 to 256 in a random order, half
of the numbers are bigger than 128

 

[Rick C]

On Friday, October 11, 2019 at 8:38:37 PM UTC-4, Lasse Langwadt Christensen wrote:

lørdag den 12. oktober 2019 kl. 02.20.29 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 15:34:20 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

lørdag den 12. oktober 2019 kl. 00.11.46 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 14:15:06 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

fredag den 11. oktober 2019 kl. 22.52.50 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 16:17:51 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2019-10-11 15:54, Andy Bennet wrote:
On 11/10/2019 18:16, Phil Hobbs wrote:
Hi, all,

As part of the aforementioned cathodolumiescence system, I'm doing a
bias supply for multipixel photon counters (MPPCs).

MPPCs are extremely voltage sensitive--the gain of this one goes from
~0 to 2E6 between 52 and 55 volts' bias.  (See
https://www.hamamatsu.com/resources/pdf/ssd/e03_handbook_si_apd_mppc.pdf>.)


Sooo, there's a bit of pressure to keep the bias very stable, but it
doesn't have to change very often.  Accordingly, I'm tentatively
planning to use a 12 to 16-bit PWM with good filtering.  It'll
obviously have to be buffered with a tinylogic gate running from a
stiff reference supply, to prevent voltage sags inside the LPC845 MCU
from spoiling the accuracy.

The '845 can run its PWM clocks at 7.5 MHz, so that would be an output
frequency of 114 Hz to 1.8 kHz. I'd need about 100 dB of filtering to
get the output ripple on the MPPC supply down to a millivolt or so, so
that's 3 RC sections with 33 dB attenuation each, i.e. corner
frequencies of 2.5 Hz to 40 Hz (TCs of 4 to 60 ms).  Not
horrible--100k*0.68uF at 16 bits, 40k and 0.1 uF at 12 bits.

Anything else besides buffering and filtering that I haven't thought
of that might limit the accuracy?  How good can you make a PWM, anyway?

Thanks

Phil Hobbs


Rather than PWM, have a look at pulse density modulation which will ease
the filtering requirement. Not sure if this is do-able in software, but
I have used FPGA implementations of this with great success.

Sort of a delta-sigma thing? You can put an M-bit delta-sigma extension
on an N-bit PWM pretty easily using a timer interrupt. I don't think
we could get the required accuracy bit-banging something like that.

Cheers

Phil Hobbs

You can also delta-sigma the LSB of a PWM to effectively add more
bits. That basically interpolates between two PWM levels.

I think that may have filtering advantages. I don't know if a uP can
reasonably do that; we did it in an FPGA.

I guess you could even PWM the LSB of a PWM.

AND a fast and a slow PWM?

You could certainly analog sum two PWMs, maybe before the filter. They
could run at a much higher frequency than a single PWM of the same
resolution.

but then you get the issue of how well analog matched the two outputs are



in hardware there's also the trick of inverting some or all of the bits
in the counter

Sorry, that's too hard to think about.

by inverting I meant reversing the bit order

i.e. 50% output becomes
hi-lo-hi-lo-hi-lo-hi-lo instead of hi-hi-hi-hi-lo-lo-lo-lo


That's even harder.

nah, swapping bits just means the counter counts in a different order

but amount of numbers larger/smaller than the set point is still
the same

i.e. it doesn't matter if you count to 1 to 256 in a random order, half
of the numbers are bigger than 128

I'm confused. The signal being output isn't the counter bits. It's a thermometer code. Scrambling the bits would definitely improve the filtering.... for some values, but not all. For example, one bit high and the rest low.... it doesn't matter where you put that bit, it passes through the filter the same way.

Someone was trying to explain to me how Sigma-Delta coding works and I kept getting hung up on the idea that outputing one bit high would always be the same bit. With a Sigma-Delta code that bit moves around and so not always has the same impact on the filter. At least that was the picture the guy painted. The point is the signal has more high frequency content while the same average value.

So what are you talking about with the counter bits being moved?

--

Rick C.

-+ Get 2,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

 

[Lasse Langwadt Christense]

lørdag den 12. oktober 2019 kl. 04.40.09 UTC+2 skrev Clifford Heath:

On 12/10/19 1:03 pm, Lasse Langwadt Christensen wrote:
lørdag den 12. oktober 2019 kl. 03.17.29 UTC+2 skrev Rick C:
On Friday, October 11, 2019 at 8:38:37 PM UTC-4, Lasse Langwadt Christensen wrote:
lørdag den 12. oktober 2019 kl. 02.20.29 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 15:34:20 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

lørdag den 12. oktober 2019 kl. 00.11.46 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 14:15:06 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

fredag den 11. oktober 2019 kl. 22.52.50 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 16:17:51 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2019-10-11 15:54, Andy Bennet wrote:
On 11/10/2019 18:16, Phil Hobbs wrote:
Hi, all,

As part of the aforementioned cathodolumiescence system, I'm doing a
bias supply for multipixel photon counters (MPPCs).

MPPCs are extremely voltage sensitive--the gain of this one goes from
~0 to 2E6 between 52 and 55 volts' bias.  (See
https://www.hamamatsu.com/resources/pdf/ssd/e03_handbook_si_apd_mppc.pdf>.)


Sooo, there's a bit of pressure to keep the bias very stable, but it
doesn't have to change very often.  Accordingly, I'm tentatively
planning to use a 12 to 16-bit PWM with good filtering.  It'll
obviously have to be buffered with a tinylogic gate running from a
stiff reference supply, to prevent voltage sags inside the LPC845 MCU
from spoiling the accuracy.

The '845 can run its PWM clocks at 7.5 MHz, so that would be an output
frequency of 114 Hz to 1.8 kHz. I'd need about 100 dB of filtering to
get the output ripple on the MPPC supply down to a millivolt or so, so
that's 3 RC sections with 33 dB attenuation each, i.e. corner
frequencies of 2.5 Hz to 40 Hz (TCs of 4 to 60 ms).  Not
horrible--100k*0.68uF at 16 bits, 40k and 0.1 uF at 12 bits.

Anything else besides buffering and filtering that I haven't thought
of that might limit the accuracy?  How good can you make a PWM, anyway?

Thanks

Phil Hobbs


Rather than PWM, have a look at pulse density modulation which will ease
the filtering requirement. Not sure if this is do-able in software, but
I have used FPGA implementations of this with great success.

Sort of a delta-sigma thing? You can put an M-bit delta-sigma extension
on an N-bit PWM pretty easily using a timer interrupt. I don't think
we could get the required accuracy bit-banging something like that.

Cheers

Phil Hobbs

You can also delta-sigma the LSB of a PWM to effectively add more
bits. That basically interpolates between two PWM levels.

I think that may have filtering advantages. I don't know if a uP can
reasonably do that; we did it in an FPGA.

I guess you could even PWM the LSB of a PWM.

AND a fast and a slow PWM?

You could certainly analog sum two PWMs, maybe before the filter. They
could run at a much higher frequency than a single PWM of the same
resolution.

but then you get the issue of how well analog matched the two outputs are



in hardware there's also the trick of inverting some or all of the bits
in the counter

Sorry, that's too hard to think about.

by inverting I meant reversing the bit order

i.e. 50% output becomes
hi-lo-hi-lo-hi-lo-hi-lo instead of hi-hi-hi-hi-lo-lo-lo-lo


That's even harder.

nah, swapping bits just means the counter counts in a different order

but amount of numbers larger/smaller than the set point is still
the same

i.e. it doesn't matter if you count to 1 to 256 in a random order, half
of the numbers are bigger than 128

I'm confused. The signal being output isn't the counter bits. It's a thermometer code. Scrambling the bits would definitely improve the filtering... for some values, but not all. For example, one bit high and the rest low... it doesn't matter where you put that bit, it passes through the filter the same way.

Someone was trying to explain to me how Sigma-Delta coding works and I kept getting hung up on the idea that outputing one bit high would always be the same bit. With a Sigma-Delta code that bit moves around and so not always has the same impact on the filter. At least that was the picture the guy painted. The point is the signal has more high frequency content while the same average value.

So what are you talking about with the counter bits being moved?



out <= value[n:1] > counter[1:n];

Very nice, but you have to watch switching losses. Unless I'm mistaken,
this switches many times more frequently than with the bits not reversed.

yes it is a compromise

 

[Clifford Heath]

On 12/10/19 1:03 pm, Lasse Langwadt Christensen wrote:

lørdag den 12. oktober 2019 kl. 03.17.29 UTC+2 skrev Rick C:
On Friday, October 11, 2019 at 8:38:37 PM UTC-4, Lasse Langwadt Christensen wrote:
lørdag den 12. oktober 2019 kl. 02.20.29 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 15:34:20 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

lørdag den 12. oktober 2019 kl. 00.11.46 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 14:15:06 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

fredag den 11. oktober 2019 kl. 22.52.50 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 16:17:51 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2019-10-11 15:54, Andy Bennet wrote:
On 11/10/2019 18:16, Phil Hobbs wrote:
Hi, all,

As part of the aforementioned cathodolumiescence system, I'm doing a
bias supply for multipixel photon counters (MPPCs).

MPPCs are extremely voltage sensitive--the gain of this one goes from
~0 to 2E6 between 52 and 55 volts' bias.  (See
https://www.hamamatsu.com/resources/pdf/ssd/e03_handbook_si_apd_mppc.pdf>.)


Sooo, there's a bit of pressure to keep the bias very stable, but it
doesn't have to change very often.  Accordingly, I'm tentatively
planning to use a 12 to 16-bit PWM with good filtering.  It'll
obviously have to be buffered with a tinylogic gate running from a
stiff reference supply, to prevent voltage sags inside the LPC845 MCU
from spoiling the accuracy.

The '845 can run its PWM clocks at 7.5 MHz, so that would be an output
frequency of 114 Hz to 1.8 kHz. I'd need about 100 dB of filtering to
get the output ripple on the MPPC supply down to a millivolt or so, so
that's 3 RC sections with 33 dB attenuation each, i.e. corner
frequencies of 2.5 Hz to 40 Hz (TCs of 4 to 60 ms).  Not
horrible--100k*0.68uF at 16 bits, 40k and 0.1 uF at 12 bits.

Anything else besides buffering and filtering that I haven't thought
of that might limit the accuracy?  How good can you make a PWM, anyway?

Thanks

Phil Hobbs


Rather than PWM, have a look at pulse density modulation which will ease
the filtering requirement. Not sure if this is do-able in software, but
I have used FPGA implementations of this with great success.

Sort of a delta-sigma thing? You can put an M-bit delta-sigma extension
on an N-bit PWM pretty easily using a timer interrupt. I don't think
we could get the required accuracy bit-banging something like that.

Cheers

Phil Hobbs

You can also delta-sigma the LSB of a PWM to effectively add more
bits. That basically interpolates between two PWM levels.

I think that may have filtering advantages. I don't know if a uP can
reasonably do that; we did it in an FPGA.

I guess you could even PWM the LSB of a PWM.

AND a fast and a slow PWM?

You could certainly analog sum two PWMs, maybe before the filter. They
could run at a much higher frequency than a single PWM of the same
resolution.

but then you get the issue of how well analog matched the two outputs are



in hardware there's also the trick of inverting some or all of the bits
in the counter

Sorry, that's too hard to think about.

by inverting I meant reversing the bit order

i.e. 50% output becomes
hi-lo-hi-lo-hi-lo-hi-lo instead of hi-hi-hi-hi-lo-lo-lo-lo


That's even harder.

nah, swapping bits just means the counter counts in a different order

but amount of numbers larger/smaller than the set point is still
the same

i.e. it doesn't matter if you count to 1 to 256 in a random order, half
of the numbers are bigger than 128

I'm confused. The signal being output isn't the counter bits. It's a thermometer code. Scrambling the bits would definitely improve the filtering... for some values, but not all. For example, one bit high and the rest low... it doesn't matter where you put that bit, it passes through the filter the same way.

Someone was trying to explain to me how Sigma-Delta coding works and I kept getting hung up on the idea that outputing one bit high would always be the same bit. With a Sigma-Delta code that bit moves around and so not always has the same impact on the filter. At least that was the picture the guy painted. The point is the signal has more high frequency content while the same average value.

So what are you talking about with the counter bits being moved?



out <= value[n:1] > counter[1:n];

Very nice, but you have to watch switching losses. Unless I'm mistaken,
this switches many times more frequently than with the bits not reversed.

CH

 

[Lasse Langwadt Christense]

lørdag den 12. oktober 2019 kl. 04.04.55 UTC+2 skrev jla...@highlandsniptechnology.com:

On Fri, 11 Oct 2019 17:38:32 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

lørdag den 12. oktober 2019 kl. 02.20.29 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 15:34:20 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

lørdag den 12. oktober 2019 kl. 00.11.46 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 14:15:06 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

fredag den 11. oktober 2019 kl. 22.52.50 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 16:17:51 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2019-10-11 15:54, Andy Bennet wrote:
On 11/10/2019 18:16, Phil Hobbs wrote:
Hi, all,

As part of the aforementioned cathodolumiescence system, I'm doing a
bias supply for multipixel photon counters (MPPCs).

MPPCs are extremely voltage sensitive--the gain of this one goes from
~0 to 2E6 between 52 and 55 volts' bias.  (See
https://www.hamamatsu.com/resources/pdf/ssd/e03_handbook_si_apd_mppc.pdf>.)


Sooo, there's a bit of pressure to keep the bias very stable, but it
doesn't have to change very often.  Accordingly, I'm tentatively
planning to use a 12 to 16-bit PWM with good filtering.  It'll
obviously have to be buffered with a tinylogic gate running from a
stiff reference supply, to prevent voltage sags inside the LPC845 MCU
from spoiling the accuracy.

The '845 can run its PWM clocks at 7.5 MHz, so that would be an output
frequency of 114 Hz to 1.8 kHz. I'd need about 100 dB of filtering to
get the output ripple on the MPPC supply down to a millivolt or so, so
that's 3 RC sections with 33 dB attenuation each, i.e. corner
frequencies of 2.5 Hz to 40 Hz (TCs of 4 to 60 ms).  Not
horrible--100k*0.68uF at 16 bits, 40k and 0.1 uF at 12 bits.

Anything else besides buffering and filtering that I haven't thought
of that might limit the accuracy?  How good can you make a PWM, anyway?

Thanks

Phil Hobbs


Rather than PWM, have a look at pulse density modulation which will ease
the filtering requirement. Not sure if this is do-able in software, but
I have used FPGA implementations of this with great success.

Sort of a delta-sigma thing? You can put an M-bit delta-sigma extension
on an N-bit PWM pretty easily using a timer interrupt. I don't think
we could get the required accuracy bit-banging something like that.

Cheers

Phil Hobbs

You can also delta-sigma the LSB of a PWM to effectively add more
bits. That basically interpolates between two PWM levels.

I think that may have filtering advantages. I don't know if a uP can
reasonably do that; we did it in an FPGA.

I guess you could even PWM the LSB of a PWM.

AND a fast and a slow PWM?

You could certainly analog sum two PWMs, maybe before the filter. They
could run at a much higher frequency than a single PWM of the same
resolution.

but then you get the issue of how well analog matched the two outputs are



in hardware there's also the trick of inverting some or all of the bits
in the counter

Sorry, that's too hard to think about.

by inverting I meant reversing the bit order

i.e. 50% output becomes
hi-lo-hi-lo-hi-lo-hi-lo instead of hi-hi-hi-hi-lo-lo-lo-lo


That's even harder.

nah, swapping bits just means the counter counts in a different order

but amount of numbers larger/smaller than the set point is still
the same

i.e. it doesn't matter if you count to 1 to 256 in a random order, half
of the numbers are bigger than 128

So does that become a sort of poor man's delta-sigma? Same duty cycle
but better spectrum?

yes

here's an example from google:

https://zipcpu.com/dsp/2017/09/04/pwm-reinvention.html

 

[Bill Sloman]

On Saturday, October 12, 2019 at 4:16:18 AM UTC+11, Phil Hobbs wrote:

Hi, all,

As part of the aforementioned cathodolumiescence system, I'm doing a
bias supply for multipixel photon counters (MPPCs).

MPPCs are extremely voltage sensitive--the gain of this one goes from ~0
to 2E6 between 52 and 55 volts' bias. (See
https://www.hamamatsu.com/resources/pdf/ssd/e03_handbook_si_apd_mppc.pdf>.)


Sooo, there's a bit of pressure to keep the bias very stable, but it
doesn't have to change very often. Accordingly, I'm tentatively
planning to use a 12 to 16-bit PWM with good filtering. It'll obviously
have to be buffered with a tinylogic gate running from a stiff reference
supply, to prevent voltage sags inside the LPC845 MCU from spoiling the
accuracy.

The '845 can run its PWM clocks at 7.5 MHz, so that would be an output
frequency of 114 Hz to 1.8 kHz. I'd need about 100 dB of filtering to
get the output ripple on the MPPC supply down to a millivolt or so, so
that's 3 RC sections with 33 dB attenuation each, i.e. corner
frequencies of 2.5 Hz to 40 Hz (TCs of 4 to 60 ms). Not
horrible--100k*0.68uF at 16 bits, 40k and 0.1 uF at 12 bits.

Anything else besides buffering and filtering that I haven't thought of
that might limit the accuracy? How good can you make a PWM, anyway?

As has been pointed out, sigma-delta DACs get 20-bit accuracy (and can do better) out of pulse width modulation. The process of scrambling the pulse outputs to push the noise into the high frequency end of the spectrum is complicated.

As Lasse Langwadt Christensen has pointed out, there are easier way of scrambling the bits. I spelled out one in my 1996 paper

Sloman A.W., Buggs P., Molloy J., and Stewart D. “A microcontroller-based driver to stabilise the temperature of an optical stage to 1mK in the range 4C to 38C, using a Peltier heat pump and a thermistor sensor” Measurement Science and Technology, 7 1653-64 (1996).

I limited the maximum switching rate to about 200kHz - to minimise switching losses in the power MOSFETs which were switching currents that could get up to three amps.

If you can live with a minimum pulse width of 133nsec, your worst cases are the single on or off pulses at 114Hz, and the next worst is the same single pulse at 228Hz.

--
Bill Sloman, Sydney

 

[Lasse Langwadt Christense]

lørdag den 12. oktober 2019 kl. 03.17.29 UTC+2 skrev Rick C:

On Friday, October 11, 2019 at 8:38:37 PM UTC-4, Lasse Langwadt Christensen wrote:
lørdag den 12. oktober 2019 kl. 02.20.29 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 15:34:20 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

lørdag den 12. oktober 2019 kl. 00.11.46 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 14:15:06 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

fredag den 11. oktober 2019 kl. 22.52.50 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 16:17:51 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2019-10-11 15:54, Andy Bennet wrote:
On 11/10/2019 18:16, Phil Hobbs wrote:
Hi, all,

As part of the aforementioned cathodolumiescence system, I'm doing a
bias supply for multipixel photon counters (MPPCs).

MPPCs are extremely voltage sensitive--the gain of this one goes from
~0 to 2E6 between 52 and 55 volts' bias.  (See
https://www.hamamatsu.com/resources/pdf/ssd/e03_handbook_si_apd_mppc.pdf>.)


Sooo, there's a bit of pressure to keep the bias very stable, but it
doesn't have to change very often.  Accordingly, I'm tentatively
planning to use a 12 to 16-bit PWM with good filtering.  It'll
obviously have to be buffered with a tinylogic gate running from a
stiff reference supply, to prevent voltage sags inside the LPC845 MCU
from spoiling the accuracy.

The '845 can run its PWM clocks at 7.5 MHz, so that would be an output
frequency of 114 Hz to 1.8 kHz. I'd need about 100 dB of filtering to
get the output ripple on the MPPC supply down to a millivolt or so, so
that's 3 RC sections with 33 dB attenuation each, i.e. corner
frequencies of 2.5 Hz to 40 Hz (TCs of 4 to 60 ms).  Not
horrible--100k*0.68uF at 16 bits, 40k and 0.1 uF at 12 bits..

Anything else besides buffering and filtering that I haven't thought
of that might limit the accuracy?  How good can you make a PWM, anyway?

Thanks

Phil Hobbs


Rather than PWM, have a look at pulse density modulation which will ease
the filtering requirement. Not sure if this is do-able in software, but
I have used FPGA implementations of this with great success.

Sort of a delta-sigma thing? You can put an M-bit delta-sigma extension
on an N-bit PWM pretty easily using a timer interrupt. I don't think
we could get the required accuracy bit-banging something like that.

Cheers

Phil Hobbs

You can also delta-sigma the LSB of a PWM to effectively add more
bits. That basically interpolates between two PWM levels.

I think that may have filtering advantages. I don't know if a uP can
reasonably do that; we did it in an FPGA.

I guess you could even PWM the LSB of a PWM.

AND a fast and a slow PWM?

You could certainly analog sum two PWMs, maybe before the filter. They
could run at a much higher frequency than a single PWM of the same
resolution.

but then you get the issue of how well analog matched the two outputs are



in hardware there's also the trick of inverting some or all of the bits
in the counter

Sorry, that's too hard to think about.

by inverting I meant reversing the bit order

i.e. 50% output becomes
hi-lo-hi-lo-hi-lo-hi-lo instead of hi-hi-hi-hi-lo-lo-lo-lo


That's even harder.

nah, swapping bits just means the counter counts in a different order

but amount of numbers larger/smaller than the set point is still
the same

i.e. it doesn't matter if you count to 1 to 256 in a random order, half
of the numbers are bigger than 128

I'm confused. The signal being output isn't the counter bits. It's a thermometer code. Scrambling the bits would definitely improve the filtering.... for some values, but not all. For example, one bit high and the rest low... it doesn't matter where you put that bit, it passes through the filter the same way.

Someone was trying to explain to me how Sigma-Delta coding works and I kept getting hung up on the idea that outputing one bit high would always be the same bit. With a Sigma-Delta code that bit moves around and so not always has the same impact on the filter. At least that was the picture the guy painted. The point is the signal has more high frequency content while the same average value.

So what are you talking about with the counter bits being moved?

out <= value[n:1] > counter[1:n];

 

On Fri, 11 Oct 2019 17:38:32 -0700 (PDT), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

lřrdag den 12. oktober 2019 kl. 02.20.29 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 15:34:20 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

lřrdag den 12. oktober 2019 kl. 00.11.46 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 14:15:06 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

fredag den 11. oktober 2019 kl. 22.52.50 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 16:17:51 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2019-10-11 15:54, Andy Bennet wrote:
On 11/10/2019 18:16, Phil Hobbs wrote:
Hi, all,

As part of the aforementioned cathodolumiescence system, I'm doing a
bias supply for multipixel photon counters (MPPCs).

MPPCs are extremely voltage sensitive--the gain of this one goes from
~0 to 2E6 between 52 and 55 volts' bias.  (See
https://www.hamamatsu.com/resources/pdf/ssd/e03_handbook_si_apd_mppc.pdf>.)


Sooo, there's a bit of pressure to keep the bias very stable, but it
doesn't have to change very often.  Accordingly, I'm tentatively
planning to use a 12 to 16-bit PWM with good filtering.  It'll
obviously have to be buffered with a tinylogic gate running from a
stiff reference supply, to prevent voltage sags inside the LPC845 MCU
from spoiling the accuracy.

The '845 can run its PWM clocks at 7.5 MHz, so that would be an output
frequency of 114 Hz to 1.8 kHz. I'd need about 100 dB of filtering to
get the output ripple on the MPPC supply down to a millivolt or so, so
that's 3 RC sections with 33 dB attenuation each, i.e. corner
frequencies of 2.5 Hz to 40 Hz (TCs of 4 to 60 ms).  Not
horrible--100k*0.68uF at 16 bits, 40k and 0.1 uF at 12 bits.

Anything else besides buffering and filtering that I haven't thought
of that might limit the accuracy?  How good can you make a PWM, anyway?

Thanks

Phil Hobbs


Rather than PWM, have a look at pulse density modulation which will ease
the filtering requirement. Not sure if this is do-able in software, but
I have used FPGA implementations of this with great success.

Sort of a delta-sigma thing? You can put an M-bit delta-sigma extension
on an N-bit PWM pretty easily using a timer interrupt. I don't think
we could get the required accuracy bit-banging something like that.

Cheers

Phil Hobbs

You can also delta-sigma the LSB of a PWM to effectively add more
bits. That basically interpolates between two PWM levels.

I think that may have filtering advantages. I don't know if a uP can
reasonably do that; we did it in an FPGA.

I guess you could even PWM the LSB of a PWM.

AND a fast and a slow PWM?

You could certainly analog sum two PWMs, maybe before the filter. They
could run at a much higher frequency than a single PWM of the same
resolution.

but then you get the issue of how well analog matched the two outputs are



in hardware there's also the trick of inverting some or all of the bits
in the counter

Sorry, that's too hard to think about.

by inverting I meant reversing the bit order

i.e. 50% output becomes
hi-lo-hi-lo-hi-lo-hi-lo instead of hi-hi-hi-hi-lo-lo-lo-lo


That's even harder.

nah, swapping bits just means the counter counts in a different order

but amount of numbers larger/smaller than the set point is still
the same

i.e. it doesn't matter if you count to 1 to 256 in a random order, half
of the numbers are bigger than 128

So does that become a sort of poor man's delta-sigma? Same duty cycle
but better spectrum?





--

John Larkin Highland Technology, Inc

lunatic fringe electronics

 

[Clifford Heath]

On 12/10/19 1:43 pm, Lasse Langwadt Christensen wrote:

lørdag den 12. oktober 2019 kl. 04.40.09 UTC+2 skrev Clifford Heath:
On 12/10/19 1:03 pm, Lasse Langwadt Christensen wrote:
lørdag den 12. oktober 2019 kl. 03.17.29 UTC+2 skrev Rick C:
On Friday, October 11, 2019 at 8:38:37 PM UTC-4, Lasse Langwadt Christensen wrote:
lørdag den 12. oktober 2019 kl. 02.20.29 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 15:34:20 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

lørdag den 12. oktober 2019 kl. 00.11.46 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 14:15:06 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

fredag den 11. oktober 2019 kl. 22.52.50 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 16:17:51 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2019-10-11 15:54, Andy Bennet wrote:
On 11/10/2019 18:16, Phil Hobbs wrote:
Hi, all,

As part of the aforementioned cathodolumiescence system, I'm doing a
bias supply for multipixel photon counters (MPPCs).

MPPCs are extremely voltage sensitive--the gain of this one goes from
~0 to 2E6 between 52 and 55 volts' bias.  (See
https://www.hamamatsu.com/resources/pdf/ssd/e03_handbook_si_apd_mppc.pdf>.)


Sooo, there's a bit of pressure to keep the bias very stable, but it
doesn't have to change very often.  Accordingly, I'm tentatively
planning to use a 12 to 16-bit PWM with good filtering.  It'll
obviously have to be buffered with a tinylogic gate running from a
stiff reference supply, to prevent voltage sags inside the LPC845 MCU
from spoiling the accuracy.

The '845 can run its PWM clocks at 7.5 MHz, so that would be an output
frequency of 114 Hz to 1.8 kHz. I'd need about 100 dB of filtering to
get the output ripple on the MPPC supply down to a millivolt or so, so
that's 3 RC sections with 33 dB attenuation each, i.e. corner
frequencies of 2.5 Hz to 40 Hz (TCs of 4 to 60 ms).  Not
horrible--100k*0.68uF at 16 bits, 40k and 0.1 uF at 12 bits.

Anything else besides buffering and filtering that I haven't thought
of that might limit the accuracy?  How good can you make a PWM, anyway?

Thanks

Phil Hobbs


Rather than PWM, have a look at pulse density modulation which will ease
the filtering requirement. Not sure if this is do-able in software, but
I have used FPGA implementations of this with great success.

Sort of a delta-sigma thing? You can put an M-bit delta-sigma extension
on an N-bit PWM pretty easily using a timer interrupt. I don't think
we could get the required accuracy bit-banging something like that.

Cheers

Phil Hobbs

You can also delta-sigma the LSB of a PWM to effectively add more
bits. That basically interpolates between two PWM levels.

I think that may have filtering advantages. I don't know if a uP can
reasonably do that; we did it in an FPGA.

I guess you could even PWM the LSB of a PWM.

AND a fast and a slow PWM?

You could certainly analog sum two PWMs, maybe before the filter. They
could run at a much higher frequency than a single PWM of the same
resolution.

but then you get the issue of how well analog matched the two outputs are



in hardware there's also the trick of inverting some or all of the bits
in the counter

Sorry, that's too hard to think about.

by inverting I meant reversing the bit order

i.e. 50% output becomes
hi-lo-hi-lo-hi-lo-hi-lo instead of hi-hi-hi-hi-lo-lo-lo-lo


That's even harder.

nah, swapping bits just means the counter counts in a different order

but amount of numbers larger/smaller than the set point is still
the same

i.e. it doesn't matter if you count to 1 to 256 in a random order, half
of the numbers are bigger than 128

I'm confused. The signal being output isn't the counter bits. It's a thermometer code. Scrambling the bits would definitely improve the filtering... for some values, but not all. For example, one bit high and the rest low... it doesn't matter where you put that bit, it passes through the filter the same way.

Someone was trying to explain to me how Sigma-Delta coding works and I kept getting hung up on the idea that outputing one bit high would always be the same bit. With a Sigma-Delta code that bit moves around and so not always has the same impact on the filter. At least that was the picture the guy painted. The point is the signal has more high frequency content while the same average value.

So what are you talking about with the counter bits being moved?



out <= value[n:1] > counter[1:n];

Very nice, but you have to watch switching losses. Unless I'm mistaken,
this switches many times more frequently than with the bits not reversed.

yes it is a compromise

You could leave some low-order bits un-reversed, which would give you a
bit each way.

 

[Rick C]

On Friday, October 11, 2019 at 10:04:01 PM UTC-4, Lasse Langwadt Christensen wrote:

lørdag den 12. oktober 2019 kl. 03.17.29 UTC+2 skrev Rick C:
On Friday, October 11, 2019 at 8:38:37 PM UTC-4, Lasse Langwadt Christensen wrote:
lørdag den 12. oktober 2019 kl. 02.20.29 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 15:34:20 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

lørdag den 12. oktober 2019 kl. 00.11.46 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 14:15:06 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

fredag den 11. oktober 2019 kl. 22.52.50 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 16:17:51 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2019-10-11 15:54, Andy Bennet wrote:
On 11/10/2019 18:16, Phil Hobbs wrote:
Hi, all,

As part of the aforementioned cathodolumiescence system, I'm doing a
bias supply for multipixel photon counters (MPPCs).

MPPCs are extremely voltage sensitive--the gain of this one goes from
~0 to 2E6 between 52 and 55 volts' bias.  (See
https://www.hamamatsu.com/resources/pdf/ssd/e03_handbook_si_apd_mppc.pdf>.)


Sooo, there's a bit of pressure to keep the bias very stable, but it
doesn't have to change very often.  Accordingly, I'm tentatively
planning to use a 12 to 16-bit PWM with good filtering.  It'll
obviously have to be buffered with a tinylogic gate running from a
stiff reference supply, to prevent voltage sags inside the LPC845 MCU
from spoiling the accuracy.

The '845 can run its PWM clocks at 7.5 MHz, so that would be an output
frequency of 114 Hz to 1.8 kHz. I'd need about 100 dB of filtering to
get the output ripple on the MPPC supply down to a millivolt or so, so
that's 3 RC sections with 33 dB attenuation each, i.e. corner
frequencies of 2.5 Hz to 40 Hz (TCs of 4 to 60 ms).  Not
horrible--100k*0.68uF at 16 bits, 40k and 0.1 uF at 12 bits.

Anything else besides buffering and filtering that I haven't thought
of that might limit the accuracy?  How good can you make a PWM, anyway?

Thanks

Phil Hobbs


Rather than PWM, have a look at pulse density modulation which will ease
the filtering requirement. Not sure if this is do-able in software, but
I have used FPGA implementations of this with great success.

Sort of a delta-sigma thing? You can put an M-bit delta-sigma extension
on an N-bit PWM pretty easily using a timer interrupt. I don't think
we could get the required accuracy bit-banging something like that.

Cheers

Phil Hobbs

You can also delta-sigma the LSB of a PWM to effectively add more
bits. That basically interpolates between two PWM levels.

I think that may have filtering advantages. I don't know if a uP can
reasonably do that; we did it in an FPGA.

I guess you could even PWM the LSB of a PWM.

AND a fast and a slow PWM?

You could certainly analog sum two PWMs, maybe before the filter.. They
could run at a much higher frequency than a single PWM of the same
resolution.

but then you get the issue of how well analog matched the two outputs are



in hardware there's also the trick of inverting some or all of the bits
in the counter

Sorry, that's too hard to think about.

by inverting I meant reversing the bit order

i.e. 50% output becomes
hi-lo-hi-lo-hi-lo-hi-lo instead of hi-hi-hi-hi-lo-lo-lo-lo


That's even harder.

nah, swapping bits just means the counter counts in a different order

but amount of numbers larger/smaller than the set point is still
the same

i.e. it doesn't matter if you count to 1 to 256 in a random order, half
of the numbers are bigger than 128

I'm confused. The signal being output isn't the counter bits. It's a thermometer code. Scrambling the bits would definitely improve the filtering... for some values, but not all. For example, one bit high and the rest low... it doesn't matter where you put that bit, it passes through the filter the same way.

Someone was trying to explain to me how Sigma-Delta coding works and I kept getting hung up on the idea that outputing one bit high would always be the same bit. With a Sigma-Delta code that bit moves around and so not always has the same impact on the filter. At least that was the picture the guy painted. The point is the signal has more high frequency content while the same average value.

So what are you talking about with the counter bits being moved?



out <= value[n:1] > counter[1:n];

Not sure that explains anything. But some of the other posts made me realize what you are talking about. As long as the modulus of the PWM counter is 2^N then the counter runs through all possible codes. So any combination of bits can be used to generate the thermometer code and it will produce the same number of 1 bits, but with a different pattern of higher frequency content.

The counter length is not always 2^N since that with the clock frequency determines the sample rate and that is often set by controlling the modulus of the counter.

--

Rick C.

+- Get 2,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209

 

[Mikko OH2HVJ]

Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> writes:

Sort of a delta-sigma thing? You can put an M-bit delta-sigma
extension on an N-bit PWM pretty easily using a timer interrupt. I
don't think we could get the required accuracy bit-banging something
like that.

If there's memory, SPI+DMA does the bitbanging by itself.

--
mikko

 

[Rick C]

On Saturday, October 12, 2019 at 2:21:26 AM UTC-4, Mikko OH2HVJ wrote:

Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> writes:

Sort of a delta-sigma thing? You can put an M-bit delta-sigma
extension on an N-bit PWM pretty easily using a timer interrupt. I
don't think we could get the required accuracy bit-banging something
like that.

If there's memory, SPI+DMA does the bitbanging by itself.

This is why I don't like MCUs for most projects. It's so hard to get a single tasking processor to do real time stuff. It's just so much easier to do it in an FPGA where you just do what you need and don't have to worry about twisting the durn thing into the shape required.

It would be so nice if they just included a thousand or so LUTs in with every MCU. Then you could design the hardware you need rather than trying to fit the design into the limited hardware available.

--

Rick C.

++ Get 2,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209

 

[Piglet]

On 11/10/2019 20:00, Winfield Hill wrote:

Phil Hobbs wrote...

The '845 can run its PWM clocks ... I'd need about
100 dB of filtering to get the output ripple ...

You could take a look at the x-Chapters section,
4x.25 Ripple Reduction in PWM, where we explore
Stephen Woodward's clever ripple-reduction trick.

https://www.dropbox.com/s/ir4k21hibg7a8z0/4x.25_PWM_ripple.pdf?dl=1

I concluded for my project, that a 16-bit DAC
made more sense, in terms of minimum PCB space.

Here's an earlier incarnation of Woodward's idea:

<https://www.dropbox.com/s/997fixfek6afwga/woodward_dac_precision_ifd.pdf?raw=1>

piglet

 

[Bill Sloman]

On Saturday, October 12, 2019 at 2:22:09 PM UTC+11, Clifford Heath wrote:

On 12/10/19 1:43 pm, Lasse Langwadt Christensen wrote:
lørdag den 12. oktober 2019 kl. 04.40.09 UTC+2 skrev Clifford Heath:
On 12/10/19 1:03 pm, Lasse Langwadt Christensen wrote:
lørdag den 12. oktober 2019 kl. 03.17.29 UTC+2 skrev Rick C:
On Friday, October 11, 2019 at 8:38:37 PM UTC-4, Lasse Langwadt Christensen wrote:
lørdag den 12. oktober 2019 kl. 02.20.29 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 15:34:20 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

lørdag den 12. oktober 2019 kl. 00.11.46 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 14:15:06 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

fredag den 11. oktober 2019 kl. 22.52.50 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 16:17:51 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2019-10-11 15:54, Andy Bennet wrote:
On 11/10/2019 18:16, Phil Hobbs wrote:

<snip>

Very nice, but you have to watch switching losses. Unless I'm mistaken,
this switches many times more frequently than with the bits not reversed.

yes it is a compromise

You could leave some low-order bits un-reversed, which would give you a
bit each way.

Published that back in 1996.

Sloman A.W., Buggs P., Molloy J., and Stewart D. “A microcontroller-based driver to stabilise the temperature of an optical stage to 1mK in the range 4C to 38C, using a Peltier heat pump and a thermistor sensor” Measurement Science and Technology, 7 1653-64 (1996)

I thought it up in around 1975 but didn't get around to using it for another twenty years.

--
Bill Sloman, Sydney

 

On Sat, 12 Oct 2019 13:40:03 +1100, Clifford Heath
<no.spam@please.net> wrote:

On 12/10/19 1:03 pm, Lasse Langwadt Christensen wrote:
lřrdag den 12. oktober 2019 kl. 03.17.29 UTC+2 skrev Rick C:
On Friday, October 11, 2019 at 8:38:37 PM UTC-4, Lasse Langwadt Christensen wrote:
lřrdag den 12. oktober 2019 kl. 02.20.29 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 15:34:20 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

lřrdag den 12. oktober 2019 kl. 00.11.46 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 14:15:06 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

fredag den 11. oktober 2019 kl. 22.52.50 UTC+2 skrev John Larkin:
On Fri, 11 Oct 2019 16:17:51 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 2019-10-11 15:54, Andy Bennet wrote:
On 11/10/2019 18:16, Phil Hobbs wrote:
Hi, all,

As part of the aforementioned cathodolumiescence system, I'm doing a
bias supply for multipixel photon counters (MPPCs).

MPPCs are extremely voltage sensitive--the gain of this one goes from
~0 to 2E6 between 52 and 55 volts' bias.  (See
https://www.hamamatsu.com/resources/pdf/ssd/e03_handbook_si_apd_mppc.pdf>.)


Sooo, there's a bit of pressure to keep the bias very stable, but it
doesn't have to change very often.  Accordingly, I'm tentatively
planning to use a 12 to 16-bit PWM with good filtering.  It'll
obviously have to be buffered with a tinylogic gate running from a
stiff reference supply, to prevent voltage sags inside the LPC845 MCU
from spoiling the accuracy.

The '845 can run its PWM clocks at 7.5 MHz, so that would be an output
frequency of 114 Hz to 1.8 kHz. I'd need about 100 dB of filtering to
get the output ripple on the MPPC supply down to a millivolt or so, so
that's 3 RC sections with 33 dB attenuation each, i.e. corner
frequencies of 2.5 Hz to 40 Hz (TCs of 4 to 60 ms).  Not
horrible--100k*0.68uF at 16 bits, 40k and 0.1 uF at 12 bits.

Anything else besides buffering and filtering that I haven't thought
of that might limit the accuracy?  How good can you make a PWM, anyway?

Thanks

Phil Hobbs


Rather than PWM, have a look at pulse density modulation which will ease
the filtering requirement. Not sure if this is do-able in software, but
I have used FPGA implementations of this with great success.

Sort of a delta-sigma thing? You can put an M-bit delta-sigma extension
on an N-bit PWM pretty easily using a timer interrupt. I don't think
we could get the required accuracy bit-banging something like that.

Cheers

Phil Hobbs

You can also delta-sigma the LSB of a PWM to effectively add more
bits. That basically interpolates between two PWM levels.

I think that may have filtering advantages. I don't know if a uP can
reasonably do that; we did it in an FPGA.

I guess you could even PWM the LSB of a PWM.

AND a fast and a slow PWM?

You could certainly analog sum two PWMs, maybe before the filter. They
could run at a much higher frequency than a single PWM of the same
resolution.

but then you get the issue of how well analog matched the two outputs are



in hardware there's also the trick of inverting some or all of the bits
in the counter

Sorry, that's too hard to think about.

by inverting I meant reversing the bit order

i.e. 50% output becomes
hi-lo-hi-lo-hi-lo-hi-lo instead of hi-hi-hi-hi-lo-lo-lo-lo


That's even harder.

nah, swapping bits just means the counter counts in a different order

but amount of numbers larger/smaller than the set point is still
the same

i.e. it doesn't matter if you count to 1 to 256 in a random order, half
of the numbers are bigger than 128

I'm confused. The signal being output isn't the counter bits. It's a thermometer code. Scrambling the bits would definitely improve the filtering... for some values, but not all. For example, one bit high and the rest low... it doesn't matter where you put that bit, it passes through the filter the same way.

Someone was trying to explain to me how Sigma-Delta coding works and I kept getting hung up on the idea that outputing one bit high would always be the same bit. With a Sigma-Delta code that bit moves around and so not always has the same impact on the filter. At least that was the picture the guy painted. The point is the signal has more high frequency content while the same average value.

So what are you talking about with the counter bits being moved?



out <= value[n:1] > counter[1:n];

Very nice, but you have to watch switching losses. Unless I'm mistaken,
this switches many times more frequently than with the bits not reversed.

CH

I don't like using busses on schematics, but some people do.

One of my guys named a uP address bus A[15:0] and connected the
program eprom A[0:15}. The board didn't work. I wrote the eprom image
builder program, so I had to add a switch to shuffle all the
instructions around in the eprom programming file.




--

John Larkin Highland Technology, Inc

lunatic fringe electronics