AINSER sampling rate

Hi All

I working since few weeks on a new project that involve midibox (to make it short a quad stereo VCA compressor with digital/midi remote)

I have most of things shorted out, and just have a new idea for it…

Using AINSER to read my DC sidechain that initially feed an analogue meter (for gain reduction monitoring)

Timing is not that critical in this area but now I’m thinking I can do some other processing depending of this input (VCA have parallels  controls from AOUT modules across the analogue time constant processing)

The question is simple what is the AINSER sapling rate if I want to proceed fast DC or rectified AC, also what is the round trip from AIN to AOUT if I want to process something in between (like midi or NG conditional)

Best

Zam

 

23 minutes ago, Zam said:

what is the AINSER sapling rate

The AINSER is usually called every ms, but! if you are using the 64 version, it’s one multiplexed line every ms then scanning the 64 inputs takes 8ms.

 

27 minutes ago, Zam said:

also what is the round trip from AIN to AOUT if I want to process something in between (like midi or NG conditional)

This is something easy to do in a regular App, using the AINSER_Handler, but in NG I don’t know.

Best
Bruno

21 minutes ago, Antichambre said:

The AINSER is usually called every ms, but! if you are using the 64 version, it’s one multiplexed line every ms then scanning the 64 inputs takes 8ms.

meaning mios can handle at least 125uS scan (8kHz sampling rate) “if” I speed up the AINSER8 scan (like a AINSER64 but with only 8 input)

this should be enough as my fastest time constant rise is 300us

39 minutes ago, Antichambre said:

This is something easy to do in a regular App, using the AINSER_Handler, but in NG I don’t know.

Ok, I’ll see

Best

Zam

 

1 minute ago, Zam said:

meaning mios can handle at least 125uS scan

You can try to call the AINSER_Handler with a Timer set at the desired rate,but usually a freertos task is used to call it, and its minimum period is 1ms( 1 / portTICK_RATE_MS )

Check tutorial#012b_ainser_muxed:

///////////////////////////////////////////////////////////////////////////// // This hook is called when an AINSER pot has been moved ///////////////////////////////////////////////////////////////////////////// static void APP\_AINSER\_NotifyChange(u32 module, u32 pin, u32 pin\_value) { // toggle Status LED on each AIN value change MIOS32\_BOARD\_LED\_Set(0x0001, ~MIOS32\_BOARD\_LED\_Get()); // convert 12bit value to 7bit value u8 value\_7bit = pin\_value \>\> 5; // send MIDI event MIOS32\_MIDI\_SendCC(DEFAULT, Chn1, pin + 0x10, value\_7bit); } ///////////////////////////////////////////////////////////////////////////// // This task scans AINSER pins and checks for updates ///////////////////////////////////////////////////////////////////////////// static void TASK\_AINSER\_Scan(void \*pvParameters) { portTickType xLastExecutionTime; // Initialise the xLastExecutionTime variable on task entry xLastExecutionTime = xTaskGetTickCount(); while( 1 ) { vTaskDelayUntil(&xLastExecutionTime, 1 / portTICK\_RATE\_MS); // scan pins AINSER\_Handler(APP\_AINSER\_NotifyChange); } }

 

Thank’s Bruno

I’ll look at soft when it’s time, for the moment I’m at the schematic, pcb not designed yet.

But this definitely make me decide to implement AINSER to scan the time constant CV, whatever happen next.

At worst it will avoid me to design an extra analogue bargraph meter driver, and I can light leds with this (I don’t need any fancy scaling it’s strait V<=>dB reading), 1ms lag is OK for gain reduction meter. I have to add a buffer anyway so again even if I don’t populate the MCP I’ll can drive an analogue meter.

At best I’ll be able to manage special time constant/condition depending on actual gain reduction… like compression amount limiting, or automatic ratio change depending of reduction amount (all time constant RC network and ratio have analogue switches/multiplexer drived by 595…)

Best

Zam