I'm trying to do target recognition using the target acoustic signal. I tested my code in matlab, however, i'm trying to simulate that in C to test it in tinyOS using sensor simulator.
In matlab, i used wav records (16 bits per sample, 44.1 sample rate), so for example, i have a record for a certain object, lets say cat sound which of 0:01 duration, in matlab that will give me a total of 36864 samples of type int16 ,and size 73728 bytes.
In sensor, if i have [Mica2 sensor: 10 bits ADC (but i'll use 8 bits ADC), 8 MHz microprocessor, and 4 Kb RAM. This means that when i detect an object, i'll fill the buffer with 4000 samples of type uint8_t (if i used 8 KHz sample rate and 8 bits ADC).
So, my question is that:
In matlab i used a large number of samples to represent the target audio signal(36864 samples), but in the sensor i'm limited to only 4000 samples, would that be enough to record the whole target sound?
Thank you very much, highly appreciate your advice
Related
I got a question about the data rate of the ethernet interface and hope someone can give me some hints on that.
I know the calculation method of the PCIe interface, for example, PCIe Gen3 X1 lane:
The data rate of single-lane should be
8 Gb/s (Gen3 line rate) * 2 (TX/RX, full-duplex) / 8 (to Byte) = 2 GB/s
(128/130 encoding is ignored)
So, how do we calculate the data rate of an ethernet interface?
Take 1000base-T for example, we have 4 twisted pairs, to sum up to 1Gb data rate.
So one pair should provide a 250Mb data rate. It’s full-duplex so TX/RX provides 125Mb each at the same time. With that being said, the “line rate” of a 1000base-T interface is 125MHz (125Mb).
Do I understand it correctly about the speedrunning on the ethernet interface?
how do we calculate the data rate of an ethernet interface?
Ethernet's nominal bit rate is generally defined at the top of the physical layer (L1). It includes preamble, SOF and IPG, but excludes all PHY-specific line encoding (PCS and PMA).
This is done to make all PHY variants of the same speed 100% compatible with each other. You can convert 1000BASE-T to 1000BASE-LX to 1000BASE-SX and back to 1000BASE-T without any buffer drops.
It’s full-duplex so TX/RX provides 125Mb each at the same time.
No - the nominal bitrate runs each direction, simultaneously for full duplex links. Each 1000BASE-T lane transports 250 Mbit/s worth of "user" data.
With that being said, the “line rate” of a 1000base-T interface is 125MHz (125Mb).
Since the line rate is (usually) the PHY rate it's 1000 MBit/s, four lanes of 250 Mbit/s each.
1000BASE-T does use a symbol rate of 125 MBaud since its PAM-5 modulation transports more than two bits per symbol. You might think that PAM-4 with exactly two bits would be sufficient, but the line code overhead eats up the rest. 1000BASE-T is already quite complex, it uses two-dimensional Trellis modulation plus scrambling to get across the wire (to produce a self-clocking signal, improve the signal/noise ratio and eliminate excess DC).
The 1000BASE-X PHYs for fiber are much simpler. The PCS uses 8b10b to produce a binary stream of 1.25 GBd that can be directly used to modulate the laser.
I'm trying to convert the accelerometer values provided by the following dataset to train the intel curie KNN chip of an Arduino 101 to recognize walking and running actions:
https://github.com/mmalekzadeh/motion-sense
This dataset is collected by using an Iphone 6s accelerometer. Since I want the arduino to be able to recognize walking and running by using its own accelerometer (not the iphone one), I need to convert the dataset to the same data rapresentation used by arduino 101 (bytes). How this can be done?
This is what I did:
1) Found Iphone 6s accelerometer datasheet. The Iphone 6s (just like the Iphone 6) has two different chips, but probably this is the one used in the dataset.
2) Found Curie chip acceletometer datasheet. Available here
3) Iphone data is expressed in both gravity and userAcceleration per axis, while Curie chip only return a 4 bytes values per axis. Here is written that Iphone total acceleration is the sum of gravity and userAcceleration...but which is the unit used to represent this value? I think G units...but I'm not sure...
Update: The dataset is expressed in G units with sensitivity range of ±8g. To convert data from Gs, the formula below posted by L. Putvin can be used.
If you want to recognize walking and running you will need to use the 8g or 16g range if you want to be safe (the max needed will also depend on where the sensor is worn, as the accelerations are greater for certain parts of the body than others). You must decide which one first, and then you will multiply the G rating from the phone by the LSB number.
Sensitivity (calibrated)
— (A): ±2g: 16384 LSB/g
— ±4g: 8192 LSB/g
— ±8g: 4096 LSB/g
— ±16g: 2048 LSB/g
When you setup the arduino you will need to change the sensitivity from the default value when you switch to the internal sensor.
I am currently reading Fundamentals of Multimedia by Ze-Nian Li
In the book there is a sample problem which I can't quiet solve, even though I seem to understand entropy and arithmetic encoding/decoding.
Given a data stream that has been compressed to a length of 100,000 bits, and told that it is the result of running an “ideal” entropy coder on a sequence of data. You are also told that the
original data consists of samples of a continuous waveform, quantized to 2 bits per sample. The probabilities of the uncompressed values are as follows:
00 - 8/16
01 - 6/16
10 - 1/16
11 - 1/16
How would I figure out the approximate length of the uncompressed signal?
Since you "seem to understand entropy", you can simply use the formula for entropy to do your homework. Here is a hint from Boltzmann's tombstone:
I've implemented a PIC32 as a USB sound card, using USB Audio Class 1. I'm sending a sawtooth signal from the microcontroller to the PC(windows 7, 64 bit), as 16-bit samples:
in decimal:
000
800
1600
2400
.. so on
then i try recording the received audio using Audacity, with MME -driver, as .wav or .raw.
I use MATLAB to open and inspect the data, and there i see data like:
000
799
1599
2400
..
The distortion varies from -1 to +1 bit pr sample..
Anyone have any idea where the problem might be.?
Windows-audio drivers.?
Since you receive the audio signal on PC, playback it, and record it using SW, the audio signal is converted from digital to analog, and to digital again. These introduce quantization error and noise, and you see the little difference between two signals.
I solved my problem..
The problem was caused by the application i used to record the data, and the method i used.. I used Audacity, which supports the old windows MME audio API, and the DirectSound API. These are relatively high-level API's apparently, and are the cause of the distortion.
About the Windows Core Audio APIs
Instead i used another program, called Reaper, it has an option to record using ASIO og WASAPI. This solves my problem. I've checked every sample in an 2 hour .wav file, using MATLAB, and it is completely bit-perfect.
I was probably some quantization error, but it was caused by the API.
ASIO and WASAPI gave me bit-perfect sound, MME and DirectSound gave me a distorted signal.
I have been controlling Arduino from Matlab using ArduinoIO-Matlab interface. My current setup is I have 3 EMG Muscle Sensors (from Advancer Technologies) are connected to the Arduino at analog pin 1,2, and 3. Arduino is connected to Matlab. I am trying to collect data from these three pins simultaneously and store them in an matrix size 1000x3. My issue is the rate at which Matlab is sampling from the analog pin. It takes about 25 seconds to collect 1000 readings from the 3 pins simultaneously. I know arduino itself samples at a higher rate. Below is my code. How do I alter this to get a sampling rate of about like 1000 samples in 10 seconds ?
ar = arduino('COM3');
ax = zeros(1000,3);
for ai = 1:1000
ax(ai,:) = [ar.analogRead(1) ar.analogRead(2) ar.analogRead(3)];
end
delete(ar);
This is the time taken by the above code (profile viewer):
time calls line
< 0.01 1 3 ax = zeros(1000,3);
4
< 0.01 1 5 for ai = 1:1000
25.07 1000 6 ax(ai,:) = [ar.analogRead(1) ar.analogRead(2) ar.analogRead(3)];
1000 7 end
8
1.24 1 9 delete(ar);
Please let me know if there is something else that I need to clarify.
Thanks :Denter code here
You need to modify the arduino c++ code (.pde file).
In this code you should sample the signal as you prefer (1000 for example) and then transfer the sampled data to matlab using serial.writeln() method.
This will give you a sampling rate of ~3KHz (depending on alot of factors)...
The following very probably explains the result that you are seeing and why you need to do something like what Muhammad's answer suggests. While this reason was implied by his answer it was not spelt out so that others can avoid the 'trap'.
I do not have access to the underlying code and systems needed to check this answer with certainty. This answer is based on "typical methods" and has a modest chance of being sheer poppycock [tm], but the exact fit between observation and standard methods suggests this is what is happening. A very little delving by someone with the requisite system to hand will demonstrate if this is correct.
When data is sent one data sample at a time you incur a per-sample overhead significantly in excess of the time taken to just transfer the raw data.
You say it takes 25 seconds to transfer 3000 samples.
The time per sample = 25/3000 = 8.333 ms per sample.
Assume a 9600 baud data transfer rate.
The default communications speed is liable to but 9600 baud. This can be checked but the result suggests that this may be correct and making slightly different assumptions provides an equally good explanation.
Serial coms usually uses N81 format = 1 start bit, 8 data bits, 1 stop bit per 8 bit byte.
So 1 bit takes 1/9600 s
and 10 bits take 10/9600 = 1.042 mS
And sample time / byte time
= 8.333 / 1.042 = 7.997 word times.
In fact if you do the calculations without rounding or truncation, ie
25 / 3000 x 9600/10 = 8.000.... .
ie your transfer is taking EXACTLY 8 x 9600 baud word times per sample.
Equally, this is exactly 4 x 4800 baud or 2 x 2400 baud transfer times.
I have not examined the format used but imagine that to work with the PC monitor program the basic serial routine may use
2 x data bytes + CR + LF = 4 bytes.
That assumes a 16 bit variable sent as 2 x 8 bit binary words.
More likely = either
- 16 bits sent as 4 x ASCII characters or
- 24 bits sent as 6 x ASCII characters.
In the absence of suitably deep delving, the use of 6 ASCII words and a CR + LF at 9600 baud provides such a good fit using typical parameters that Occam probably opines that this is the best starting point. Regardless of whether the total requirement is 8 or 4 or 2 bytes, the somewhat serendipitous exact match between your observed data rate and standard baud rates suggests that this provides the basic reason for what you see.
Looking at the code will rapidly show what baud rate, data length and packing is used.