Thanks for the Teensy series of boards, I've had lots of success incorporating them into various projects. About a year ago I started an ambitious data capture project with a Teensy 3.2, then upgraded to a Teensy4.0 and finally to a Teensy 4.1 so I could use the SD card features to store results and dispense with carrying around a laptop.

  1. Alternative 24MHz clock input
    It would be great if a future Teensy had the ability to use an external TCXO or GPS locked source as an alternative to the on-board 24MHz oscillator module. I'm not keen to carry out surgery on the T4.1 to provide an alternative input as (a) there are too many to do and (b) I'm pushing 80 and not as dexterous as I was.
    (Could this be a possible software only tweak on the current hardware? Something like: useExternalClock(pin#, Freq) )

    Amongst many other things my project measures RF signals up to the limit imposed by the FreqCount() library with gate periods from 1uSec through to 10Sec. For the longer gate periods I derive a gate period correction factor using a precision oscillator to overcome the frequency error of the on-board crystal, but the temperature co-efficient still causes me problems. Yes, I know microprocessor crystals were never intended to be high precision items but that never stops us nerds from wanting them better! I'm more than happy to sacrifice a pin for an input.
  2. Teensy 4.1 SD Card Software Release date?
    Is there a probable release date for a version of Teensyduino and a library that has a set of 'standard' SD commands that work? If not a firm date an estimate would be useful.

    My project would benefit hugely from using the Teensy4.1 SD card to store data, not least because the end users would not need to buy laptops to store captured data, remember to charge them and carry them around! It is neat that you can plug a T4.1 into a 4.0 socket provided of course you do not need the extra connections and the mother board and case have space. I have all my beta project hardware with T4.1 boards installed. (Sorry, project details are under wraps at present.)
  3. FreqCount() Library. Beware delay()!
    The Example code ran OK on the T4.1 until I put a delay(10) into the loop() at which point the gate period seemed to be set by the delay() period. The delay(10) was to simulate the other functions in the main project code. (I guess it clashes with other things) I worked around this but it would be great if there were comments in the example code to warn intended users.
  4. FreqCount() Library. Pipeline is a big nuisance.
    I would prefer a non-cycling method of measuring frequency so the gate period could be specified and the gate then opened by a software command. Measurement completion would being indicated on a flag that could be polled.

    My main project code needs to measure frequencies in the range of 100KHz to 50 MHz with various gating periods (depending on required precision). The current library requires some redundant measurement cycles each time the gate period is changed and there seems to be a pipeline delay before a frequency change emerges. This all gets very tardy with gate periods of one second and above! I would prefer a maximum of one gate period between the decision to measure the frequency of the input to the start of the gate period and also the ability to abort a long gate measurement would be good.

    (A colleague is working on another project for which the Teensy 4 / 4.1 is the candidate processor and is very happy to have a 1MHz resolution and a 1uSec or 10uSec gate period, but he also needs to make the measurement with a decision latency of a few milliseconds. (To switch RF low pass filters.) )

    In both cases we are using a pre-scaler ahead of the Teensy; the real input frequency may be in the hundreds of MHz.

Apologies for the long post.