Does architecture of ats-mini support possibility of deliver streaming receive audio via (serial port, wifi, bluetooth)?

[wb0gaz]

Considering usability of mini-ats (with outboard UHF receive converter now begin experimental development) as "headless" device for antenna test range; delivering receive audio would be valuable feature, however, I do not know if hardware architecture can in future even support this?

[max-arnold]

The audio output from SI4732 is not connected to the CPU.

[wb0gaz]

Thank you for information. I have not reviewed the schematic nor the microcontroller datasheet ---is there free pin on the microcontroller that could serve as ADC (=would a derived version of the hardware/PCB design potentially be able provide this interface?)

[max-arnold]

The schematics is available here https://esp32-si4732.github.io/ats-mini/hardware.html

However, if you Google "ESP32 ADC WiFi", you will find numerous issues

[Rfromearth]

Even if there were connections between the audio outputs (stereo) and unused ESP's ADC-GPIOs, the S3-Version has a problem:

ESP32-S3 does not support the full bluetooth stack. So A2DP is not possible!

as Phil Schatzmann stated here.

Furthermore every integrated ADC has it's own linearity inaccuracy, so every radio had to undergo it's own calibration procedure.
Without an external ADC on the PCB all efforts - even streaming over WIFI - would certainly deliver poor sound quality.

[Hamberthm]

Even if there were connections between the audio outputs (stereo) and unused ESP's ADC-GPIOs, the S3-Version has a problem:

ESP32-S3 does not support the full bluetooth stack. So A2DP is not possible!

as Phil Schatzmann stated here.

Furthermore every integrated ADC has it's own linearity inaccuracy, so every radio had to undergo it's own calibration procedure. Without an external ADC on the PCB all efforts - even streaming over WIFI - would certainly deliver poor sound quality.

Thanks for the heads up, you saved me hours of reading!

Indeed, the newest ESP32 chips like the S3 don't have the Bluetooth Classic stack. It's still somewhat possible if some library starts support for the new generation's Bluetooth LE-Audio.

I think this will eventually come but it depends on how LE-Audio gets adopted. The market is still saturated with Classic audio devices and it will take years, who knows the state of this radio by then!

[wb0gaz]

(asking as person without ESP32 expertise, but some STM32 experience).. Setting Bluetooth (LE/Classic) aside for a moment, and accepting that ADC quality of ESP32 has known issues, would any of the remaining unassigned pins (maybe 7 when briefly counting on schematic) be capable of configuration to ADC operation (with addition of mid-point DC bias and uF block capacitor from SI4732 audio outputs)?

[Hamberthm]

@Hamberthm: Here you can find some experiments with a sample rate set to 44.1 kHz: High End Response #1198

Yeah, I know sampling up to 20khz is difficult but the thing is, other than commercial FM reception I don't think it makes sense wanting a Hi-Fi stream on the rest of the bands. Setting a lower sample rate should be fine for voice and low bandwidth stations I guess

[wb0gaz]

My original post failed to mention (of course, sorry!) that the application I have in mind would accept relatively low sample rate (4 kHz maximum audio frequency for communications-type audio, not entertainment-type audio, because the associated tasks would only use the AM/SSB detection mode up to 30 MHz, not broadcast FM.

[Rfromearth]

@wb0gaz: Another idea: Connect your radio's headphones output with the mic- or ext-input of an older notebook, a RPI or a server with a virtual machine running in a proxmox or whatever environment. Install and configure Icecast. Install one of the icecast-clients on your Desktop-PC, notebook or mobile phone to receive the stream.
Instead of icecast you can also install remote-control-tools like NoMachine which delivers a very good audio quality. So you can put the radio connected to a stationary longwire or loop antenna and get the sound anywhere else.
That's it. Problem solved.
The only missing thing is a nice webgui for the internal webserver of the radio to control frequency, band, bandwidth and so on via browser.

[okutkan]

I'm not sure if its the relevant implementation use case but over his Github repo superogira provides web-based control for the ats mini
https://github.com/superogira/ats-mini

[wb0gaz]

Other (streaming audio) scenarios of interest - if hard-wire connection from SI4732 to uncommitted ESP32 pin with ADC capability is made (accepting caveats about audio quality, etc., and recognizing there is no such connection in the existing PCB design, but ESP32 does appear to have some uncommitted pins), then does the USB endpoint function in the ESP32 have ability to add UAC (usb audio class) endpoint? If not, could ADC samples from that connection be delivered via CDC endpoint (as if the audio stream were in response to a command issued from external device)?

[Hamberthm]

I continued to research this topic with no luck, sadly. My findings:

• It is theoretically possible to sample the output of the receiver on the ESP32 using one ADC module without additional chipsets, with LOW sample rate only, and then stream it over WiFi (webserver).
• No ADC1 pin is free on the ATS-MINI, so it's not possible to solder a jumper wire to one of them and sample the analog audio using Arduino Audio Tools library and ADC1.
• ADC2 is unusable for two reasons: It has conflicts with WiFi operation at the same time (critical if we want to stream over WiFi) and ESPRESSIF discontinued support for "continuous mode" on the driver due to problems with the chip design, as stated by the official errata.

There's one last hope and that is to force the continuous mode on ADC2 using the CONFIG_ADC_CONTINUOUS_FORCE_USE_ADC2_ON_C3_S3 directive. For this, the project needs to be migrated to a ESP-IDF environment, like VS Code, because the ESP Core for Arduino IDE comes already precompiled and this option cannot be dynamically enforced. Still, there's still the possibility that ADC2 continuous mode cannot coexist with WiFi and/or give unacceptable performance.

TL;DR: Analog sampling into the ESP32 is too, too far from being practical on this receiver without big modifications.

There's still one use for ADC2 and that is one-shot sampling, used for example to decode CW

[EmEiBee]

I admire your enthusiasm and optimism; no question.
But I think simply routing the audio signal to a ADC input won't be enough. As far as I know, many others have tried that and failed. As far as I know, the ESP is simply not designed for that.
The only sensible way to transfer audio data to an ESP and then stream it via Wi-Fi is likely to be via the I²S, based on the processing power alone...

Am I wrong? Then please correct me otherwise.

[Hamberthm]

Yes, that's the best way.

I don't have any experience with digital I2S signals. I did read a little, and I understand it needs three signals to work. If I'm correct, that's three jumper wires to solder at least, and it would make a mess of a mod, at least without changing the case for something with more room.

[max-arnold]

Anyone tried to ask for a source code of this firmware?

[Hamberthm]

Hi @max-arnold , I contacted him via email to ask about how he used the ADC2 pin to sample and decode CW. On his words:

"Nothing Special used. Simple analogRead at a given Samplerate and the goerzel algo as a tone detector. I did the Same on an Arduino using a Mike."

He's using very simple one-shot sampling on the ADC2, which is the only thing that can be done with it as I explained above, as he said, nothing special.

By the looks of his website and the way of sharing the firmware, it doesn't look like he's willing to release the code.

Humberto

[G8PTN]

Hi,
For information, I found the following code a few years ago for a Morse decoder. This uses the Goertzel algorithm for the tone detector.
https://www.instructables.com/Binary-Tree-Morse-Decoder/

At the time, I did some basic tests using a D1-Mini (ESP8266) module, sending the decoded Morse data via MQTT to Node-RED. The decoder seemed to work well with computer generated Morse, but was not so good for off air signals.

The results for an 858 Hz band pass filter setup on the ESP8266 are shown below.

With larger values of N, which increases the processing time, I remember having some issues with the WIFI behaviour.

The ATS-25 receivers which support the decoding features, use an external tone detector chip for Morse and RTTY. I am not sure why this is not done in DSP on the audio input, as is the case for other modes such as FT8.

With respect to options for audio input/output:
For audio output, it may be possible to use the ESP32 LEDC block in PWM mode, with a simple RC low pass filter feeding the audio amplifier.

Using I2S is likely to be the best option for audio input and output, but interference could be a problem for the SI4732, which may be reduced by careful PCB layout and screening.

73, Dave

[Hamberthm]

Hi!

I continued to explore a little more about I²S. We need to connect 3 signals from the ESP32 to the SI4732, a digital clock (DCLK), frame select (DFS), and data out (DOUT).

Sadly, in our ATS-MINI the chip is lay out in "internal oscillator" mode, which requires GPO3/DCLK to be connected to a crystal as well as RCLK.

As per AN383 design guide:

"Either crystal or digital audio operation must be selected due to the multipurpose role of GPO3/DCLK pin 17."

So, in the current configuration, extracting I²S sound from the chip is impossible.

Seems that any hope to get audio into the ESP32 is now lost... The original designer should consider changing the board design to allow digital audio routing to the ESP32 in a future V3 design.

[G8PTN]

Hi,
Yes, sorry, I did intend that the SI4732 I2S should be used, since it does not work when the SSB patch is loaded.
Possible future designs could consider the addition of an I2S codec device to allow audio in/out.
However, all of this would mean more cost/power and may result in RF noise problems.
73, Dave