DRAFT: Use AudioTools #89
Conversation
wsciaroni
force-pushed
the
SimplifyRefactor
branch
from
5760106 to
e24a1c5
Compare
wsciaroni
force-pushed
the
SimplifyRefactor
branch
from
e24a1c5 to
a10a7bd
Compare
|
Is TuneCmdMsg in your diagram missing tone int and squelch int? |
|
What do you think about adding an ack response back to the host over serial whenever a command is processed? Maybe something like a MsgType of ACK = 0x55 |
|
Would you also consider GetFrequency, GetFilterSettings, etc commands? |
That sounds great, but I'm worried about what that looks like in |
That sounds good to me. |
I will need to review code more thoroughly Maybe the expanded proposal could be additional MsgTypes 0x0F is command from host |
|
The RX audio is just a byte stream. This allows us to just use the
AudioTools library to put raw data into serial without having to interact
with it.
We could use a custom audio encoding to hold the commands as metadata as
suggested by the author of AudioTools.
…On Fri, Nov 8, 2024, 1:19 PM gx1400 ***@***.***> wrote:
What do you think about adding an ack response back to the host over
serial whenever a command is processed?
Maybe something like a MsgType of ACK = 0x55
That sounds great, but I'm worried about what that looks like in RX_MODE
I will need to review code more thoroughly
Maybe the expanded proposal could be additional MsgTypes
0x0F is command from host
0xF0 is audio data
0x55 is command acknowledge
0x01 is GetVersion response
0x02 is GetTuningParams response
0x03 is GetFilterSettings response
Etc
—
Reply to this email directly, view it on GitHub
<#89 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGK2CWWB4HL6CY6WHEZ7XL3Z7UFE7AVCNFSM6AAAAABRMO5YWCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRVGU4DEMBSGY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Do you have any wisdom that would help me get the AudioTools portion of this PR configured? It looks like you've got a really cool SDR Transceiver project working with that already |
|
DRAFT: NOTE
This Pull Request currently exists for visibility so that other developers will see this is being worked if they would like to contribute to it. This is very much a work in progress.
Background
There are several variants of KV4P-HT that have varying requirements for audio flow. For instance, some want to allow the audio to flow via Bluetooth to and from the ESP32. In order to accommodate these future improvements, this MR aims to change the ESP32's code design. There are some notable changes in the Pull Request that each need to be considered carefully should they be accepted.
Notable Changes
1. Serial Protocol
The following lightweight protocol has been designed to meet our current needs.
2. ESP32 v3.0.5
This change was recommended by pschatzmann. This upgrade to v3 of the ESP32 bring along with it v5 of the ESP IDF. This includes a re-write of the I2S and an implementation of ADC/DAC Continuous mode.
Using the Audio-Tools library, I experimentally determined that the sampling rate needs to be
53904Hz. I setup a python script to read the samples from the ESP32's serial from my desktop. I set it up to count the number of characters received over a period of 120seconds. Based on our target sample rate of 44100Hz, we were looking for 5292000 samples / 120 seconds. Based on the requested sample rate of the adc_continuous driver via Audio-Tools of53904I received ~5291470samples. This is an error of about%0.01.3. Dependency on Audio-Tools
I believe the flexibility of using Audio-Tools outweighs the downside of adding one library dependency. This is of course up for discussion.
Outstanding Issues
The following things have not been completed, but must be completed before this is ready