I am using python sockets to connect to a bluetooth HC-05 module with my PC. I want to send music to the HC-05 by converting a wav file to a string array which will later by converted to integers ranging from 0-65535 on an arduino. The arduino and HC-05 communicate via serial at 9600 baud. Then those ints will be passed into a DAC via I2C. I am wondering if there could be a memory issue sending an enormous number of strings from my PC. Is it possible the original quality of the sound will be distorted as a result of the different rates of sending/receiving data across the devices? Or will the sound signal just be delayed on the DAC?
The arduino and HC-05 communicate via serial at 9600 baud.
This is going to be too low to be usable for audio.
9600 baud gives you 7680 bits of data per second. At 16 bits per sample, you're looking at a sample rate of 481 Hz, which is too low for intelligible audio. It's barely even high enough to reproduce sound at all.
You need to:
Increase the baud rate. Ideally you'll want at least 57600 baud, for 46 kbit/sec of data. If higher baud rates are available, use them.
Use fewer bits for each sample. Using 4 bits for each sample at 56 kbaud will give you a respectable sample rate of 11.5 kHz. The audio will sound a little tinny at 4 bits, but it'll be intelligible.
Related
I'm trying to understand how to implement audio playback from scratch on attiny85. The goal is to play a short sound (cat meows, so i want it to remain recognizable) from an array representing strength of audio signal sampled at fixed interval.
As far as i understand, signal strength is linearly mapped to voltage of analogue audio signal. As far as I know, audio cards are Digital to Analogue Converters, but attiny85 probably doesn't have that.
I'm curious if I can use pwm to play the sound back. Since pwm changes average voltage by changing duty cycle of alternating high and low phases of signal, it most likely would result in the drop of audio quality. Wav sampling rates can differ between 1 HZ and 4.3 GHz according to google. Attiny85 has internal clock with frequency up to 8MHz (which I hope is same for it's pwm generator).
Considering reconfiguring the timer and pwm settings as well as looping in the array, what is the maximum sampling rate of audio i can reliably play? And should i even try to do it with pwm, or there are better options?
Given a system clock of 8 MHz, you can use PWM to generate mono (single-channel) audio.
Consider a PWM period of 1000 clocks, giving you about 10 bit resolution. The sample rate will be 8000 Hz then, which gives you some kind of lo-fi audio.
If you reduce your signal resolution to 8 bits, you'll get 8 MHz / 28 = 31.25 kHz sample rate. This gets near hi-fi.
Synchronize your sample output with the PWM generator, and use an appropriate analogue filter.
Many years ago I built a digital door bell with a sample rate of 8 kHz and 8 bit samples. It played nice sounds in the quality of telephones. The microcontroller was a 8051 derivative and it used an R-2R ladder as DAC.
A simpel sinus can be generated by using a 50% PWM signal and varying the frequency. Given some filtering effect through the speaker, it would mimik a single tone audio signal.
Making more advanced tones (needed for natural sound) quickly gets more complicated and the duty cycle of the signal can also be used to trick the human ear into hearing harmonics. Check out the arduino function tone() for some inspiration.
Be carefull when connecting a small speaker to the Arduino, preferably a transistor/buffer/small amplifyer should be place between the Arduino and the speaker.
I'm seeing ~15ms of overhead when communicating with a microcontroller over RS-485 with a USB-to-serial converter, is there any way to minimize this overhead?
I have some debug and data collection python3.10 scripts that connect to a microcontroller via either USB or half-duplex RS-485 serial. I'm using PySerial in both cases and I am either passing it the address for the USB-to-serial converter to the controller directly (running on MacOS). Today I logged how long a command and response takes to execute at different RS485 baud rates (median of 1000 command/response cycles, min time is similar):
9600 baud - 32 ms
38400 baud - 16 ms
115200 baud - 16 ms
230400 baud - 16 ms
500000 baud - 16 ms
USB - 1 ms
I have scoped the signal # 115200 baud and the command + response takes 3ms max, so I while I would like this micro to burn in a pit I don’t think I can blame this particular problem on it. Since all my code is shared between the serial and usb tests, I'm left to believe that the majority of the overhead is coming from pyserial or my d-tech usb-to-serial converter.
From what I’ve seen a large number of the usb-to-serial adapters use the same FTDI chipset, so I’m not sure if I would actually get any improved performance by blindly choosing another converter. If someone knows better here please chime in.
I have tried to send 12-bit audio to be listened to in real time through the HC05 SPP bluetooth module hooked up to an arduino and DAC over serial with a python RFCOMM socket. I have since learned that Serial Port Protocol is not very great at all for this purpose due to its low bandwidth. I figured I could definitely send the data and then play it out through a DAC, but I doubt an arduino would hold an array the size of a WAV file and maybe not even an mp3 file, but that would defeat the purpose of controlling the audio (play,pause,rewind,etc) from my computer. Would it be more realistic and worthwhile to use an A2DP enabled bluetooth module? Or is it still possible to listen to acceptable quality 12-16 bit audio in real time with SPP? I have tried to use lower bit songs, adjusted baud rates for the arduino and HC-05 serial ports, and tried to adjust the magnitude of the values outputted by the DAC to the audio port and I still seem to get crackly audio. It seems the problem comes down to the low bitrate transfer speed of SPP, or am I wrong?
Is it realistic to stream 12-16 bit audio through SPP bluetooth in realtime?
Sure, at some awfully slow sample rate <= 8 kHz. You'd be better off sending 8-bit audio at a higher sample rate.
Would it be more realistic and worthwhile to use an A2DP enabled bluetooth module?
Yes, absolutely, without question. That's what it's designed for, as I mentioned in your other question.
Or is it still possible to listen to acceptable quality 12-16 bit audio in real time with SPP?
Acceptable is subjective. If it's just voice, you can get away with it. If you want reasonable audio quality for music, almost universally, no, it's not acceptable.
It seems the problem comes down to the low bitrate transfer speed of SPP, or am I wrong?
Without any code to inspect and debug, it's impossible to say what the specific problem is that you're referring to. Undoubtedly, the low bandwidth will not enable good quality audio anyway.
If you must continue to use SPP and simple codecs like PCM, at least use differential PCM to save a bit more bandwidth.
I have a serial device connected to USB of my Linux PC and i need constantly read data from it and process it.
When i use open(fd, xxx) while(1) {read(fd, xx)} it works but i miss more than 60% of data.
Is there a better technique to have less data loss?
Addendum
The baud rate is 115200. we must receive at least 10 packets a second, but we get barely two.. The packet size is 22 bytes. The code is exactly the code from the second comment.
I want to modulate digital data into audio. Then communicate it through any audio channel and demodulate at the destination from audio to data again. To do this I hope to use computer sound card and software modem without using any hardware implementation. In the internet, I found that this can be through the technique called Audio Frequency-Shift Keying(AFSK). I want to know that can I obtain bit rate more than 1200bps from AFSK and if it is no what the reason behind that this limitation.
Is there any technique efficient than AFSK for this purpose ?
The most common currently-used form of AFSK is the Bell202 modem at 1200 baud. There are a few other standards which also use 1200 baud, and some that run at less than 1200 bits per second, but none that I know of that run greater than 1200.
However, as far as I know, there's no reason you couldn't write a software modem to transmit and receive at a higher baud rate. Bell202 uses bit stuffing (allowing the data stream to use the same tone no more than 5 bits in a row) to help keep the transmitter and receiver from falling out of sync with each other, so a higher baud rate might require bit stuffing at a lower threshold (every 4 or 3 bits).
Another consideration is that the sound cards you're using should use a sampling rate equal to or a multiple of the baud rate you choose. This is one of the reasons 1200 baud is so common, as 1200Hz and 48000Hz are common sample rates with audio hardware.
So 1200 baud isn't a limit. It's just a standard.