Search results

It may be caused by, at an SD card write/sync delay, DMA has wrapped around the buffer of 128 bytes three times (instead of one), so 256 samples are overwritten and lost. Try increasing buffer size to e.g. 512 or more.

I stripped irrelevant code (for other functionality) and kept relevant code. Resulting pseudo-code is below. The rest is pretty much similar to input_adc.cpp. At header, add to private variables: static uint32_t recycle_samples_begin, recycle_samples_end; // offsets w.r.t. capture_buffer At...

Unfortunately, I cannot post the code here, sorry about that. But it is basically processing all buffered data since the last update(), similar to what is happening at input_adc.cpp update() method. Then it writes all the results to the file. But if needed, I may post a pseudo-code for my...

That's right, that way DMA writes to a wider buffer span. Currently DMA reads 12 bit results of ADC and then writes 16 bit items by doing 4 bit zero padding. But, if I'm not missing something, making DMA item size 32 bit will still convey one ADC measurement by doing 20 bit zero padding.

It turned out that consecutive restarts are caused by DMA config params CITER and BITER are 15 bits, hence DMA can be programmed for a max of 32767 samples [1]. To wrap up; I sample at 705600 Hz (later subsampling to 352800 Hz), 16 times faster than Audio library default 44100 Hz. Likewise, at...

Yep, I'm already doing it for its little help on reducing power consumption: // set disabled mode for 55 pins of Teensy 4.1 (https://www.pjrc.com/store/teensy41.html) for (int i = 0; i < 55; i++) pinMode(i, INPUT_DISABLE); And after this, changing modes of the pins which are going to be used as...

@kd5rxt-mark, I didn't know that, that will definitely come in handy! Thank you 😌

I tried with 128 and 2 GB SD cards, different classes, and observed different clicks. Their actual-write delays differ between 52 and 10 ms, respectively, and have different periods. Click periods alter accordingly. P.S.: I'm still trying to use bigger adc & capture buffers, but Teensy keeps...

I applied the click patch. I altered below code, at input_adc.cpp, before IIR High-Pass Filter: Changed this: int16_t *s = capture_buffer + recycle_samples; to this: bool recycle_offset = (*capture_buffer) > (int16_t)(0.024f * 32768); int16_t *s = capture_buffer + (recycle_offset ? 0 ...

Yes, it's the Teensy ADC. A choice being poor or good depends on the case. For my case, Teensy ADC is enough. I agree that I should've indicated my assessments are for my project and are not generalizable. Again, it's overkill for my case for now. This will almost definitely solve the problem...

This sentence describes the essence of the cause of this issue 😌

Hi Paul, thank you for the comments. Only a mic is connected to the Teensy, no other hardware. And mic's ground goes to Teensy's ground. I did run Teensy from a battery, its ground too is connected to Teensy, click behavior was the same. Having a completely isolated system changes nothing...

Yes, I tried writing buffered data to file by several writeOut(512) calls, waiting while the file is busy each time. All writeOuts was successful, below code never printed "writeOut not Ok", but behavior didn't changed. bool writeOutOk = true; while (rb.bytesUsed() != 0) { while...

Thank you for the responses. I tried all of them, and below is the summary of the test journey. TLDR; none of the suggestions worked, so I'll patch click spikes at the software. * Place capacitors I placed a capacitor to 3.3v line near pin 23, near pin 24 and near sd region, one at a time...

Thank you for the response Mark. To where that bulk capacitance should be added? Between any 3.3v and ground lines, or do you recommend a specific place? 🤔

Hi. On Teensy 4.1, when I acquire the audio from the ADC input, and save it to SD card, a periodic click occurs. I perform high sampling, and click period changes by sampling rate. At sampling rate 176400 Hz period is ~1.86 seconds, at 352800 Hz ~0.93 seconds. That's because click occurs at a...

I found the design parameters. When below parameters are input at the T-filter tool, the exact impulse values at the source code are calculated. sampling freq: 176400 Hz desired #taps: 45 from to gain ripple/att. 0 12000 1 2 22000 88200 0 -80 type: int, 18 bits

Hi Mark, thank you for the values and the graphs. They are good starting points for filter params, I'll play with the values and see if I can achieve the filter at the source. I don't need to find the exact filter, but a more approximate one will be enough for me to get the idea used while the...

Hi, I'm studying source of AudioInputAnalog, input_adc.cpp, and have a question about the FIR filter. For filtering, this object uses an FIR filter. I'm curious about how its parameters are calculated. The line at which the filter is defined, it's stated the filter is designed at...

At last I got this issue working, and for completeness I'm summarizing my solution here. If anyone needs the details, let me know and I'll explain. Issue's relation to bus frequency being below 100 MHz at my previous post, was actually a relation to ADC's internal clock being so slow. I studied...

So, I did some more trials regarding to this issue, and wanted to report my observation here, as short as possible, in case someone has an explanation. It seems, when bus frequency is set below 100 MHz (arm frequency is at 200-150 MHz range and below 100 MHz), AudioInputAnalog gets insufficient...

After studying set_arm_clock() at clockspeed.c file, clock trees and timers at IMXRT1060 manual, I see my lack of knowledge and some numeric coincidences had misled me. Now I have a solution, which is not nice but enough for my case. Teensy 4 starts with 600 MHz arm clock (armF) and 150 MHz bus...

Ok, while testing I've come to a weird point. I made clock speed being adjusted by a pot, and swept down from 600 MHz to 150 MHz, with 50 MHz steps. Code lights leds when available() methods return true, so that I can see. When the speed input to set_arm_clock and the speed read back from...

Hi, Audio result availabilities like peak1.available() and fft256_1.available() are working as expected from normal 600 MHz to 300 MHz clock speeds, as I set via set_arm_clock(), for power reduction purposes. But below 300 MHz (i.e. 240 MHz and below), these available() methods always return...

After writing complete code for the instructions[1], current draw has dropped 6.6 mA (109.8 -> 103.2 mA). Still not much, but worth doing for my case 😌 Powering USB2 down does nothing, as jmarsh stated above. // USB power-down sequence, with disabling auto-clearance of the CLKGATE bit to...

Hmm, thank you for these explanations 😌 Then, it seems the only way to have a significant power reduction is to play with the CPU frequency.

So, I ended up with below code to disable 2 USB ports: // clear USBPHY_CTRL_ENAUTOCLR_CLKGATE USBPHY1_CTRL &= ~USBPHY_CTRL_ENAUTOCLR_CLKGATE; USBPHY2_CTRL &= ~USBPHY_CTRL_ENAUTOCLR_CLKGATE; // set USBPHY_CTRL_CLKGATE to disable USB clock USBPHY1_CTRL |= USBPHY_CTRL_CLKGATE...

I looked that section, it mentions a low power suspend mode, which seems not a shut down/disable. I found below code in this forum, for switching off USB by disabling USB clock at Teensy 3.6. SIM_SCGC4 &= ~SIM_SCGC4_USBOTG; This is documented at MK66 processor's reference manual. I was hoping...

Hi, I want to disable both USB ports (main and host) at Teensy 4.1, at setup(), for power reduction. I checked forums/web but found answers for older Teensy boards. There is an end() method at usb_serial_class, which is not implemented. I also searched IMXRT1060 documents but cannot find...