I am trying to stream sampled values from 8 bit ADC through UART on the STM32 nucleo board.
I use ADC with DMA. Sample rate is around 6kHz to fill a buffer with 100 converted values takes me around 17 ms.
After that I want to send those values through UART with baudrate 115200. Since the ADC converted value is HALF_WORD for 100 converted values I have to send 1600 bits. That means I can send them for 14 ms without overwritting data.
This is my attempt in code:
/* Private variables*/
#define ADC_BUF_LEN 100
uint16_t adc_buf[ADC_BUF_LEN];
uint8_t flag = 0;
/* USER CODE BEGIN 2 */
HAL_ADC_Start_DMA(&hadc, (uint32_t*)adc_buf, ADC_BUF_LEN);
HAL_TIM_Base_Start(&htim2);
while (1)
{
if (flag==1)
{
HAL_UART_Transmit(&huart4,(uint8_t*)adc_buf,100,1);
flag = 0;
HAL_GPIO_TogglePin(GPIOA,GPIO_PIN_9);
}
else
{}
}
void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef* hadc)
{
HAL_GPIO_TogglePin(GPIOA,LED_GREEN_Pin);
flag = 1;
}
I have attached picture with the transmitted data to the terminal.
For input the ADC meet 1 kHz sine wave 2 V p-pk.
I can see with naked eye that my system is not working.
If i plot that data it wont be sine wave.
The project is for EMG signal processing: I need to sample the signal and then process it in Python.
Setting the Timeout parameter of HAL_UART_Transmit to 1 is not correct. You have already calculated it is going to take 14 ms! This means the function will give up and return after only a small proportion of the data has transmitted.
To do this more than once without gaps in the data you are going to need to use DMA on both the ADC and UART at the same time.
Enable the half-transfer interrupt for the ADC DMA, or poll for the half-transfer flag. When you receive it start the UART in DMA mode on the first half of the buffer. It should complete in 7ms, which is 1.5ms before the ADC DMA starts overwriting the data it contains. When you get the ADC DMA complete interrupt or flag, start the UART DMA on the second half of the buffer.
Alternatively, the DMA on most STM32 also support "double-buffer" mode which works more-or-less the same but you only use the complete interrupt and you have two separate data pointers rather than calculating the offset of half a buffer.
Related
İ need to record pcmaudio per 10 milisecond without playback in swift.
I have tried this code but i can't find how can i stop playback while recording.
RecordAudio Github Repo
and second question: How can i get PCM data from circular buffer for encode-decode process properly. When I convert recorded audio data to signed byte or unsigned byte or anything else the converted data sometimes will corrupt. What is the best practice for this kind of process
In the RecordAudio sample code, the audio format is specified as Float (32-bit floats). When doing a float to integer conversion, you have to make sure your scale and offset results in a value in legal range for the destination type. e.g. check that -1.0 to 1.0 results in 0 to 256 (unsigned byte), and out-of-range values are clipped to legal values. Also pay attention to the number of samples you convert, as an Audio Unit callback can vary the frameCount sent (number of samples returned). You most likely won't get exactly 10 mS in any single RemoteIO callback, but may have to observe a circular buffer filled by multiple callbacks, or a larger buffer that you will have to split.
When RemoteIO is running in play-and-record mode, you can usually silence playback by zeroing the bufferList buffers (after copying, analyzing, or otherwise using the data in the buffers) before returning from the Audio Unit callback.
I'm using an ESP8266 NodeMCU 12-E development board to capture audio from a pre-amplified electret microphone, then I upload it to the web where it will be converted to a wav file. My first thought was to cast the integer values of analogRead(A0) on the ESP8266 as String type, then concatenate them into a longer string payload which I can publish to an MQTT broker.
My MQTT client subscribers didn't seem to be getting proper sound files, because all I heard were series of rhythmic pops.
I decided to investigate if my code on the ESP8266 board was even capturing things properly. I stripped the code down to these few lines which seem to cause problems:
#include <ESP8266WiFi.h>
const char *ssid = "____"; // Change it
const char *pass = "____"; // Change it
void setup()
{
Serial.begin(115200);
Serial.println(0); //start
WiFi.mode(WIFI_STA);
WiFi.begin(ssid, pass);
}
void loop()
{
int analog = analogRead(A0);
if (analog > 255) {
analog = 255;
}
else if (analog < 0){
analog = 0;
}
Serial.print(String(analog));
Serial.print(" ");
}
Here's how I use the code above to produce a wav file to check if the sound is what I expect:
- I start up the ESP8266 development board
- I turn on the Serial Monitor and clear all previous output
- I power up my electret microphone and speak into it
- I power down my electret microphone
- I copy the contents of the Serial Monitor (which is a series of integers) into a text file called `audio.raw`
- I copy `audio.raw` to a linux machine that has ffmpeg installed
- I issue the command `ffmpeg -f u8 -ar 11111 -ac 1 -i audio.raw -y audio.wav` on the linux machine
When I listen to the audio.raw file, I hear my voice, but the speed is maybe 5-10 times faster than normal. (I also get a lot of noise and distortion, but that might be a separate issue with the input signal quality.)
I then tried changing this one line of code Serial.print(String(analog)) to Serial.print(analog). Then I repeated the steps above. But this time, my voice sounds like it is about 2 times faster than normal.
Why does changing this one line from Serial.print(String(analog)) to Serial.print(analog) make such a big difference?
Is it because the String() function is a very expensive operation that takes up a lot of time? And when the script needs more time to process each line of code, the script then has less time to capture enough analogRead(A0) data points? And if I run the same ffmpeg command using all the same flags, then ffmpeg will try to meet the -ar 11111 requirement by speeding up the audio play? Which would imply that my sampling rate is dependent on execution speed of my script? Which means I have to consider variable execution speeds across other boards of the same model due to variability in manufacturing precision, environmental temperature, etc...?
Your sampling rate is coupled to your loop implementation (as you have discovered). This will also cause jitter in your sampling rate as different code paths will take different amounts of time and interrupt service routines will also steal CPU cycles.
This jitter will be one of the causes of distortion in your output.
When I listen to the audio.raw file, I hear my voice, but the speed is maybe 5-10 times faster than normal.
The ESP8266 has a hardware UART so the code can potentially load the UART's FIFO buffer faster than it can output. This would be a source of the perceived faster sampling rate but also cause jitter or data loss when the buffer fills up. Depending on the implementation, when the buffer fills it will drop data or alternatively block (causing jitter).
Why does changing this one line from Serial.print(String(analog)) to Serial.print(analog) make such a big difference?
Is it because the String() function is a very expensive operation that takes up a lot of time? And when the script needs more time to process each line of code, the script then has less time to capture enough analogRead(A0) data points?
Yes, yes and yes.
One of the reasons for the performance difference is that String() involves allocating and managing memory on the heap to store the characters.
Serial.print(analog) uses a fixed size buffer on the stack as the code knows the maximum number of characters required to display an int.
And if I run the same ffmpeg command using all the same flags, then ffmpeg will try to meet the -ar 11111 requirement by speeding up the audio play?
Yes. ffmpeg assumes that the samples have a fixed sampling rate but this does not match the samples that are being printed out.
Which would imply that my sampling rate is dependent on execution speed of my script?
Yes!
Which means I have to consider variable execution speeds across other boards of the same model due to variability in manufacturing precision, environmental temperature, etc...?
Yes. There will be a multitude of variables that affect execution speeds.
What can you do?
Decouple the sampling of data from the code execution.
This can be done by implementing an Interrupt Service Routine. Tie the ISR to a hardware timer so it executes at a fixed sampling rate and avoiding jitter.
The ISR can write to a buffer which the code in loop() transmits over the serial connection. The ISR and serial transmission code need to manage the buffer to ensure that neither overrun the other. One means of doing this is to use alternate buffers that the ISR and transmission code use.
Since you use Serial.begin(115200) ESP8266 Microcontroller will transfer 115200 bits per second through serial port. Which is 115200 / 8 = 14400 bytes per second and that means since you use u8 (unsigned 8 bit) format for audio, each sample consists of a single byte. Just change the ffmpeg -ar parameter to 14400.
I don't any have microphones which i can connect to MCU for testing but it should work properly this way. The other -ac parameter is correct since it is mono channel audio.
Edit : Also don't use String() constructor while printing out to Serial.
While using Serial() constructor sound speeds up about 5 times because String converts your 1 byte value to 3 bytes, example ; byte : 255 -> String : "2", "5", "5" , you don't have to consider execution speed of Microcontroller, it will output 115200 bits per second as if you defined. You just need to consider it's output.
Finally delete the line
Serial.print(" ");
Also change
int analog = analogRead(A0);
to
byte analog = (byte)analogRead(A0);
since int consists of 4 bytes, you would not want to send extra 3 bytes to serial.
And after changing int to byte you can get rid this code block
if (analog > 255) {
analog = 255;
}
else if (analog < 0){
analog = 0;
}
If you connect ESP8266 to linux device through usb which has ffmpeg on it you can use
ttylog -b 115200 -d /dev/ttyUSB0 | ffmpeg -f u8 -ar 14400 -ac 1 -i - -y audio.wav
to capture audio data in realtime from ESP8266.
I use an ESP8266 dev board from NodeMCU with Lua. I power my chip with two AA batteries, which gives me 3V. See this:
https://www.hackster.io/noelportugal/ifttt-smart-button-e11841
How do I check the battery status using NodeMCU?
With a recent firmware you can use adc.readvdd33(). That should be enough for your case
I read somewhere that adc.readvdd33() was deprecated? Effectively it is for many of the ESP8266 modules available, the docs say, "If the ESP8266 has been configured to use the ADC for sampling the external pin, this function will always return 65535". So that means that any ESP8266 that has an ADC pin (like ESP8266-07 or -12, etc.) has this shunted in firmware.
But by adding a couple of resistors to make a voltage divider, you can still use the ADC pin for this.
[![schematics][1]][1]
[1]: http://i.stack.imgur.com/FEILF.png
Those resistor values will allow it to read 0-12V, as a value between 0-1024. (The voltage at the ADC pin must be less than 1V.)
val = adc.read(0)
Addendum: Adding this to your circuit incurs a power draw of approx. 0.01 milliamps, small but more than nothing. Multiply the values by 1000 to reduce it to infinitesimal. Or use 18 megaohm for r1 and 2 megaohm for r2, which divides the voltage by 10, and (wild guess) drains less current than most if not all batteries will attenuate when disconnected.
I want to send signal with data rate (3.84 M) using USRP1, but when I transmit the signal it tells me some thing like this in the terminal :
WARNING
Target data rate: 3840000 bps
Actual data rate: 4000000 bps
but I'm trying to implement TX working with the UMTS air interface and I don't want this error in the data rate,
anyone can help?????
Your sample rate is dependent on the master clock rate you are using with your USRP. Your USRP1 has a master clock rate of 64 MHz, and you can only sample at integer decimations of that value, by default, which is why you cannot sample at 3.84 MSps.
UHD is auto-correcting your requested sample rate to a rate that is supported by your USRP, for you. This is actually desirable behavior.
You have two options:
Replace the clock on the USRP1 that will divide down to the rate you want.
Use a rational re-sampler. GNURadio provides this block for you, if you want to use it.
I would suggest using a rational resampler before attempting a hardware mod, which may permanently destroy your USRP if you do it incorrectly.
I have a Delphi 6 Pro app that uses the DSPACK component library to send audio to Skype from the system's preferred audio input device. I am using a TSampleGrabber component to tap into the Filter Graph chain and then send the audio buffers to Skype. The problem is that I am only getting audio once a second. In other words, the OnBuffer() event for the TSampleGrabber instance only fires once a second with a full second's worth of data in the Buffer parameter. I need to know how to modify my Filter Graph chain so it grabs data from the input device at a faster interval than once a second. If possible, I'd like to do it as fast as every 50 ms or at least every 100ms.
My Filter Graph chain consists of a TFilter that is mapped to the system's preferred audio input device at the top. I attach the output pins of that filter to the input pins of a 'WAV Dest' assigned TFilter so I can get the samples in PCM WAV format. I then attach the output pins of the 'WAV Dest' filter to the input pins of the TSampleGrabber instance. What do I need to change to get the TSampleGrabber OnBuffer() event to fire at a faster interval?
UPDATE: Based on Roman R's answer I was able to implement a solution that I am showing below. One note. His link led me to the following blog post that was helpful in solution:
http://sid6581.wordpress.com/2006/10/09/minimizing-audio-capture-latency-in-directshow/
// Variable declaration for output pin to manipulate.
var
intfCapturePin: IPin;
...............
// Put this code after you have initialized your audio capture device
// TFilter instance *and* set it's wave audio format. My variable for
// this is FFiltAudCap. I believe you need to set the buffer size before
// connecting up the pins of the Filters. The media type was
// retrieved earlier (theMediaType) when I initialized the audio
// input device Filter so you will need to do similarly.
// Get a reference to the desired output pin for the audio capture device.
with FFiltAudCap as IBaseFilter do
CheckDSError(findPin(StringToOleStr('Capture'), intfCapturePin));
if not Assigned(intfCapturePin) then
raise Exception.Create('Unable to find the audio input device''s Capture output pin.');
// Set the capture device buffer to 50 ms worth of audio data to
// reduce latency. NOTE: This will fail if the device does not
// support the latency you desire so make sure you watch out for that.
setBufferLatency(intfCapturePin as IAMBufferNegotiation, 50, theMediaType);
..................
// The setBufferLatency() procedure.
procedure setBufferLatency(
// A buffer negotiation interface pointer.
intfBufNegotiate: IAMBufferNegotiation;
// The desired latency in milliseconds.
bufLatencyMS: WORD;
// The media type the audio stream is set to.
theMediaType: TMediaType);
var
allocProp: _AllocatorProperties;
wfex: TWaveFormatEx;
begin
if not Assigned(intfBufNegotiate) then
raise Exception.Create('The buffer negotiation interface object is unassigned.');
// Calculate the number of bytes per second using the wave
// format belonging to the given Media Type.
wfex := getWaveFormat(theMediaType);
if wfex.nAvgBytesPerSec = 0 then
raise Exception.Create('The average bytes per second value for the given Media Type is 0.');
allocProp.cbAlign := -1; // -1 means "no preference".
// Calculate the size of the buffer needed to get the desired
// latency in milliseconds given the average bytes per second
// of the Media Type's audio format.
allocProp.cbBuffer := Trunc(wfex.nAvgBytesPerSec * (bufLatencyMS / 1000));
allocProp.cbPrefix := -1;
allocProp.cBuffers := -1;
// Try to set the buffer size to the desired.
CheckDSError(intfBufNegotiate.SuggestAllocatorProperties(allocProp));
end;
I suppose you need to fine tune Audio Capture filter to capture in buffers of the size you want, i.e. short enough to make overall latency small.
Audio capture filters expose IAMBufferNegotiation interface on output pins and SuggestAllocatorProperties lets you specify buffer configuration.
See for more info: Configuring Windows Media Audio Encoder DMO to reduce delay.