Albert H wrote: ↑Sun Jan 25, 2026 11:21 pm
One design I saw recently put the Arduino into a "sleep" state once the tuning info had been loaded. Turning the rotary programmer "woke up" the Arduino. The delay before the Arduino shut off was a couple of seconds, and the receiver was relatively "deaf" until the "sleep". Unfortunately, this meant that tuning across the band would miss all but the strongest signals.....
I'm always conscious of going off topic on these but here goes. Maybe we need a "TEF" thread.
With these types of receiver I just don't think you can do without the microcontroller, full stop.
For the case with your RX with the rotary controller, scanning or anything involving evaluation of the signal metadata just isn't going to work without the microcontroller. You could put it to sleep after tuning but you're going to get no signal data and potentially no audio either depending on your implementation.
For me though, the most compelling use case for the TEF RX is running headless and being online 24/7 plus scanning, logging, recording etc. If you want to use existing applications like the fmdx webserver stuff and clients like xdr-gtk, then at the very least your RX needs to follow the "xdr protocol" to allow it to interact. This means you need a controller connected to the TEF chip which is continuously listening for commands from the client and sending back signal and system data, and audio too if you're using the I2S rather than its built-in DACs.
Even the bespoke monitor application I wrote (originally I was using a Pi model 1 which couldn't do a node.js build) which was pretty low level, was using XDR protocol to talk to the radio. This was implemented in the Arduino.
In the room where I have my prototype headless TEF running right now, there's 15dBu of crud mostly coming from the wifi extender and it makes its way close to the RX up the cables coming from the Raspberry Pi 3B I'm now using as a server. The radio has an external antenna outside so it's not too bad on VHF but if I decide to try and make it usable on HF, then there's work to do.
Surprisingly there's not much noise coming from the Pi itself - most of the HF noise seems to be coming from the external ADC I'm using which is a lash-up at the moment and can be tidied up. The crap from the Arduino is minimal, about 2dBu extra, so I'm going to keep this and concentrate on shielding and filtering and see how much this can improve matters.