jonr
Senior Member

I've used a one byte per second serial over USB connection from a PC to discipline a teensy audio clock to the PC system clock. Works well.

Note that a GPS requires far less noise during acquisition. So in some cases, you can power up the GPS, acquire a lock and then power up the noisy circuitry. Distance (even say from 1" to 3") makes a difference. ...

The easiest way to reduce noise is to go with the trend - do everything possible in the digital domain.

Yes, marketing is critical - which is why inferior technical specs don't mean non-competitive.

Always be interested in the competition. Even if you think "that's not very competitive because ..."

Disabling interrupts around the call made it much worse. My working assumption - changing speeds simply takes too long to be useful in my use case.

I find it disappointing that while there was a pre-existing usable and popular API (Arduino), the RasPi foundation went off and created yet another API. But as I mentioned above, they didn't need yet another board to...

Looks like it doesn't disable interrupts while waiting - seems like a potential source of problems.

I could check with the scope, but does anyone know how long set_arm_clock() takes to execute? I see that it includes wait loops. Also that it's changing voltage - which might have some side effects. Right now,...

I'm using SPDIF3. It's a confusing issue because I've seen all of crashes, distorts and works fine. Distortion is the most common. I am doing a lot of processing - a simple pass-through may not trigger it. ...

Strange, that is basically the code I tested with. I just tried a different placement of the speed changes and the program locks up (switching between 816 Mhz while processing and 528 Mhz when idle and the speed at...

I would guess that there would be a lot of value in teensy wrapper libraries that are compatible with the pico libraries. Ie, an easy migration path for users who start on the low cost pico and want to upgrade to the...

A clue: my DAC sees an interruption in toslink output. Perhaps the audio PLLs get reset?

Unfortunately, it creates audio glitches if one switches back and forth.

Look at the upgrade_firmware() routine and add code to open the file and read characters from it instead of the serial port. Others can say more about how to use the SD card.

What was the conclusion on this? Is there an easy way to jump to 912 Mhz for a brief period?

You can easily write code to load a teensy .hex firmware file from an SD card (or modbus) if you use the Flasher4 library.

A claimed reason for the pico is that linux (used on their other models) isn't good at real-time I/O. But all they had to do to fix that was change the OS to leave one core completely untouched by linux and so...

Following the manufacturer recommendation sounds reasonable. Is there something that prevents the battery from being discharged to an unsafe voltage?

A differential ADC on the Teensy 3.6 (Pins A10 and A11) should work well for this application.

Don't worry about the ":02 0000 02" lines, they aren't code values. But for now, do manually combine any ":04 XXXX 00" lines.

No doubt there are some users who are able to "insert the SD card I mailed you" and not "install this software on your PC and then ....". You can start with "Flasher4" if you want to develop software to do this.

If you just want an easy low noise teensy output solution, run toslink to an off-the-shelf DAC/amp.

i2sflew: I highly recommend that you get used to typing your circuits into LTSpice. You can even add noise to the power supply or input. Not perfect, but you will learn a lot.

How does it sound when you run from batteries?

"the AD8656 can drive capacitive loads up to 500 pF ..." So if you are planning to us it there, think twice about that 33uF.

> a DSB is mandatory at the end of interrupt-code I believe it should also be used when disabling interrupts from non-interrupt code. > SCB_AIRCR = 0x05FA0004; Of course such things should be inside of a...

You might be better off just ordering this: https://www.pjrc.com/store/audio_ground_isolator.html

It would be really nice if the flasher code could directly accept any .hex lines it is likely to receive.

I would study the example below. Look closely at how/where "client" is set. https://gist.github.com/atomsfat/1813823

> A simple hardware diagnostic using patterns of red LED blinks is also planned Nice! - black boxes are hard to debug. Would be very helpful to distinguish between "loader can't talk to MCU", "crystal isn't working"...

That is my concern. Some protocols are likely to lose exactly an entire line. This could get flashed and the error might not be immediately obvious.

> you need to type in ":flash XXXX", where XXXX is the number of lines reported by the program I recommend that you don't do this. Type in ":flash XXXX", where XXXX is the number of lines you counted in your hex...

For speaker analysis and correction, this is great. https://www.roomeqwizard.com/ If you want to do convolution based correction, then just use the impulse response from REW and also use...

Yes, specifically "fast, partitioned convolution".

While it's only necessary for high resolution at low frequencies, I am able to run 12288 taps, stereo.

OK, I checked and some notes: T4 with a small heat sink attached It runs about 45C (far far different than the graph) Slowing from 600 to 528 is only a couple of degrees cooler wfi makes no difference extern...

In many cases, one could include this in their idle loop, which I understand reduces power/heat more than slowing down to 450 mhz. asm volatile("wfi");

My guess is that at 450 mhz, it will last a very long time. And most applications won't notice the slower speed.

There was some discussion of strlcpy(). IMO, don't just use it, use it and check the return value. Ie: if (strlcpy(dest, src, sizeof(dest)) > sizeof(dest)) handle_error();

3 years life at 600 mhz - that could be a problem.

Sure, you could pack four 10 bit samples into every five bytes. But consider other approaches - like a teensy 4.1 or a larger sd card.

My experience is that paste is better, even when you don't have a stencil. But I save time and frustration - unless JLCPCB puts most of the parts on, I always order a stencil. More advice - use a syringe + tubing to...

I agree with tomas. Is there a tool for predicting how many bits you need for how much distortion?

Consider either headphones (low bass with low power) or a subwoofer (which will need size and power).

For about $15, you can buy an external TOSLINK DAC box. Not the lowest cost option, but will probably outperform the PT8211.

Yes, it works on both 4.0 and 4.1.

See here for a newer, better teensy 3.x version: https://forum.pjrc.com/threads/43165-Over-the-Air-firmware-updates-changes-for-flashing-Teensy-3-5-amp-3-6

Nice work Joe.

I use the audio library with USB input and SPDIF optical output. I have no noise issues. You haven't explained what you need to do, but stay digital as much as possible and if you have to do a A/D or D/A conversion,...

Nice! Can you make a iMXRT1062 version too? :-)

For less noise, you should be doing a differential read on two analog inputs.

What options are available on a teensy to do bounds checking? Ie, what's the easiest way to find the above error?

IMO, the memory allocation details should be abstracted away for the typical use case. Ie, a single mallocX() call where you optionally pass it a hint as to the speed desired (or other requirements like DMA...

I'd use the existing routine for writing blocks. Specifically: void eeprom_write_block(const void *buf, void *addr, uint32_t len)

I'm curious, is there any reason that the library shouldn't have an empty constructor and do the initialization in begin()? In any case, just crashing is poor design.

My understanding is that if you omit the stop, then the bus isn't released and, with your slave chip/application, the following start isn't needed/tolerated. But the libraries don't provide a way to do this.

Good that you found something that works. As I see it, your application could use less buffer space if it had something like this for all but the first and last portions: endTransmission(omitStart, omitStop);

You should post your actual code. I don't know much about it, but possibly use wait_idle() between partial writes.

Can you do many smaller writes? What is the target chip and software running on it?

There is a nice spreadsheet coefficient calculator/visualizer here: https://www.minidsp.com/applications/advanced-tools/advanced-biquad-programming +1 on using the teensy code (see...

> The geometric mean gives 965Hz, i.e. 35Hz bellow the 1000Hz I get: sqrt(1390*720) = 1000.4 Hz

If you really need a custom iMXRT1062 design now, then I'd design it for both a MKL02 and a jtag connector.

>but not symmetrical around 1000Hz. You should use the geometric mean and with that, it is symmetrical.

You might as well get used to the teensy way of debugging. Lots of print statements, sometimes with a Serial.flush() followed by a delay.

Two questions: I use partitioned fast convolution to greatly reduce filtering delays. Can't partitioning be used for this application? If one does use 96 biquad bandpass filters (which seems feasible), does the...

I only looked at it briefly, but that code appears to be doing a FFT and then combining bins. Not clear why so many people write code without comments.

Agreed, the typical person watching is likely to prefer larger bins and less delay. You can still use the same number of lights, probably most people won't notice the lack of accuracy on the low end.

+1 on combining bins. Say you down sample to 11K sps, then run a 22,000 sample FFT. Each bin would represent .5 hz. The DD4WH code is an example of large FFTs.

If one is going to mix digital circuitry with analog audio, better to use differential/balanced for the audio. Or stick with digital audio (eg, an i2s microphone).

Is the teensy loaded with code that emulates a serial port?

With com0com, you would just have to write the code to move bytes over TCP. http://com0com.sourceforge.net/ Or possibly this: https://tibbo.com/support/downloads/tdst.html

Very minor change - leave interrupts off when done flashing.

With interrupts, it's critical to be clear about during which stage. The first when data is being moved from input to upper flash and the second when upper flash is being moved down to lower flash. There were some...

The ESP-01 seems like a good fit.

I didn't look closely at what you are doing, but in general, for low jitter input, you can disable interrupts while waiting for the next pulse. Or use an interrupt of the highest priority to capture pulses.

I would have some use for a teensy version of OpenLog that uses MTP over usb. But would have to have similarly low power consumption.

A fine but important point. When you use the teensy clock to measure a ratio between two external clocks, drift in the teensy clock is mostly irrelevant. Because it effects both measurements equally. Jitter goes...

When you talk about "ground", you need to specify which ground. For example, the teensy could have one ground and your other equipment could have a different ground. Don't connect these grounds together and the teensy...

Note that if your teensy and the other equipment don't share a ground, then the ground of the other equipment can be at the teensy VGND level. Ie, it can work, even without balanced inputs on the other equipment. ...

Depending on volume, I'd try hard to have all parts on the same side (which appears to be possible in this case). After being fooled too many times about solder bridges, I stopped connecting adjacent pads directly...

Has anyone verified that grounding PTA1 (or more likely PTA3) on the MKL02 disables it properly?

The ADC makes sense if the audio signal will always be in the 0-3.3V range.

What is the voltage range of these "audio signals for timing"?

To reduce confusion about which serial port is which, I've added the SYMLINK option to the teensy udev rules. IMO, something like this should be standard. KERNEL=="ttyACM*", ATTRS{idVendor}=="16c0",...

> Actual result: Just the i2c address is written. The clock only transmits 8 pulses. i2c on t4 works fine. Here is a relevant quote from a description of the protocol: "Each byte of data (including the...

> T4's USB data stream is too fast for some interfaces sounds plausible.

Absolute max on the input voltage to the T4's TLV75733P regulator is 6V. So 5.5V max is recommended.

I recently wrote some quite similar code (for exact audio clock matching). When you are ready, send me a message if you want the code. Basic technique is to measure clock A with the teensy clock and clock B with...

I'd feed a GPS 1 PPS into a teensy 4 and not use an external oscillator. The teensy will be able to measure the 1 PPS and pendulum signals with its 600 mhz clock.