lookup filter index

Hello Paul,

You have a great start here! You got very close to a working schematic. There are just two small details I would like to point out:

1. The Pulse Counter algorithm counts the number of cycles when the input is high, not the number of edges. Since the duty cycle is not 1 sample long, the counter is incrementing many times per audio sample, causing the Index Selectable Filter to jump to the last entry right away.
2. The Index Selectable Filter algorithm expects a 32.0 entry on its selection input. That is, to select the second filter, you should input 0x00 00 00 01. The 8.24 switches would input 0x01 00 00 00. I think this is why your second schematic didn't work.

With that in mind, here is a revised schematic. The readbacks are really useful for debugging this sort of thing.

The One Shot Rise w/Reset ensures that we only toggle the Pulse Counter once per cycle. We can see this on the readback. The level detector is a quick and dirty way for us to tell which filter is selected. With this setup, the level detector jumps up by 5dB once per second, so we know the proper filter is being selected.

I am attaching the project.

I hope this is helpful. Please reply if you have any further questions.

Joshua

IndexSelectableFilter.zip

This is very helpfull Joshua, thanks!. I would not have been able to deduct that from the wiki help.

In my system I want to write a pulse train from a raspberry to the DSP. Different number of pulses to identify a different sound index. Now the program works thanks to your input, but when I add a GPIO as input instead of the pulse source, the DSP does not respond.

I use the 1466EVAL board which has MP13 available. I set the GPIO register for that pin, basially no changes to the defaults except turning on the MP13 ( it indeed writes a 1 to the LSB of that register which fits the datasheet). And I put the i2S with which this pin is shared to slave, else I had the LRClock on the pin as well.

As first test I applied a pulse from a capacitive switch which produces a clean "pulse", no debounce needed. But the DSP does not respond. Again sort of stuck. I tried looking at the signal with the "real time display" connected to the GPIO, but nothing. Tried different number formats as well. Any new pointers perhaps?

Paul

Hi Paul,

Since you mentioned that LRCLK was still appearing on the pin after you set the GPIO register, I suspect there is something suspicious about the pin configuration. The LRCLK signal should have disappeared as soon as the pin control register was set.

Does your pin configuration look like this? The "Enable MP function of the pin" setting should be set to MP function.

If your schematic still doesn't work, can you zip it up and attach it to your response so I can take a look?

Joshua

Hi Joshua,

It also puzzled me that had to go into the serial port register as well. I am not at the same computer now so I can not check the exact settings, but I used the default. Do you also use the 1466? I remember that the enable MP was not the last field but separate red/green buttons below all the 13 port settings.

Paul

And another thought - is it actually possible to write the index number to the MP pin and connect that to the filter index directly? What would be the format? That way I can select the filter index directly on the pi instead of having to step through all filters during selection (because pulsecount would be sequential)?

Paul

Hello Paul,

If you look at the parameter list. You will see that Pulsecount does show up as a parameter. This can be read by your controller or your controller can write in a new value. This will immediately update the counter. You can actually do this right from SigmaStudio by clicking on one of the number fields and typing in a new value. This is exactly how your controller would do it.

Dave T

Hi Paul,

I am also using ADAU1466. The MP page has two sections where MP13 appears. I am highlighting them in green.

When the Mode Setting for MP13 is "Input from Pin", the output toggle button should have no effect. And when the Enable MP Function of the pin is set to "MP Function", LRCLK should disappear from the pin.

Are you able to duplicate these results?

Joshua

This is a great way to do it if you have SPI or I2C control of the DSP. 

If not, we can use the MP13 pin as you have been doing and invent a simple signaling scheme. For example, we could create a schematic which assigns different pulse widths to each filter. Then, your device could send a pulse of certain length to directly trigger a certain filter. We could build in tolerance to account for clock mismatch too.

This is a great way to do it if you have SPI or I2C control of the DSP. 

If not, we can use the MP13 pin as you have been doing and invent a simple signaling scheme. For example, we could create a schematic which assigns different pulse widths to each filter. Then, your device could send a pulse of certain length to directly trigger a certain filter. We could build in tolerance to account for clock mismatch too.

I2C/ SPI control is tempting but perhaps a bit complicated for a first project. In the case of I2C: connect my uC pins to the DSP slave port. But this is also used by sigmastudio for SPI programming. Not possible I guess due to the fixed I2C adress bits, so then sigmastudio should program in I2C as well? If so, then selfboot / sigmastudio all still works as usual but with "I2C READ" sigmastudio can read the input?

Some hints for the pulsewidth design would be great :-)

And ideally without pulsecount because that requires 3 pins with the reset and on/off included. A pulswidth scenario sounds like it could do with 1 pin.

Hi Paul,

Here is my idea for extracting pulse width and decoding it to a filter index. 

For this schematic, your Raspberry Pi would send out pulses with widths of 0.5ms, 1.5ms, 2.5ms.... to select the filter at index 0, 1, 2...

There is 0.5ms of tolerance to account for clock mismatch between Raspberry Pi and SigmaDSP.

Let me know if this solution works for you. I am attaching the project below.

Joshua

IndexSelectableFilter_Pulse_Width.zip

Excellent Joshua, thanks. The tolerance comes from the index being an integer?

I also want to be able to switch between FIR filters. They are not index selectable it looks like so I used the index selectable audio signal router. It works, but perhaps there is a more elegant method? Attached example was made with cross overs instead of FIR for simple testing. This is attached to your schematic above.

.

Hi Paul,

The tolerance comes from our use of the multiply block. When we multiply the current pulse count (a large 32.0 integer) by 1/48, any fractional part of the result is truncated. So it is like performing a floor() operation.

Then, by having the Raspberry Pi send pulses which are (filter index + 0.5) milliseconds long, there are 24 sample periods of wiggle room before the value would toggle to the next selection. This is summarized in the table. I may be one counter value off, but hopefully you see the idea.

etc.

For the FIR filters, you may want to look at the "FIR Filter Pool" block. Its GUI takes some time to understand but I think it will do exactly what you need without needing the separate multiplexer and mixer blocks.

If you start running out of MP pins you may want to start looking into I2C or SPI control. This would provide a lot of freedom as you move forward.

Regards,

Joshua

Hi Joshua

It works like a charm :-). I would like the DSP to make a chime sound each time a new filter is selected, see bottom left. I figured using the onrise and then feedback with a delay to reset it after the (fixed) duration of the chime would work. But the delays seem to be made for short audio delays, not duration of chime sounds. Any good idea's? The shown switch was just for testing.

Thanks as always, Paul

Hi Paul,

Sorry for the delay.

For the Chime, if you click on the blue square, it should allow you to customize the length of the chime. Is there enough granularity there for what you need?

Joshua