Prev: Complicated stacked Bar Charts: is this possible?
Next: debugger question
From: Stephane Beniak on 27 May 2010 15:01
Hi everyone,

I'm doing some signal processing with MATLAB, and I need to ideally receive two separate signals simultaneously. Realistically, there can be a small delay between the two, so long as I can calculate that delay and compensate accordingly.

My problem is that I'm getting data from two radically different sources. One is packets coming in over ethernet, and the other is analog voltages coming in through my sound card. By far the slower of the two is the ethernet, which runs at roughly 128 Hz. So what I'm trying to do is simultaneously read both the ethernet packet and the soundcard voltage, to get one data point from each for each unit of time. That, or simply read both buffers after a short time to get corresponding data points, but the packets are not timestamped, so this is essentially impossible.

What I have running right now is a while loop that reads ethernet packets as quickly as possible during one second, which is roughly 128 packets, and timestamps them using tic/toc. Then, I read the soundcard buffer (one second's worth) with getdata(analoginput), which returns the data with corresponding times. The tic/tocs and timestamps don't match up, though, and I can't see a way to calculate the delay, as both signals are noisy. Meanwhile, I've also tried reading one data point from the packets and the analog voltage simultaneously, but using getdata(analoginput) seems to have a roughly 3ms delay before it starts reading correctly, so the first point is always 0. I've also fooled around with peekdata, yet nothing seems to be working for me.

Does anyone have any bright ideas as to how I could pull this off?
From: Walter Roberson on 27 May 2010 18:37
Stephane Beniak wrote:

> My problem is that I'm getting data from two radically different
> sources. One is packets coming in over ethernet, and the other is analog
> voltages coming in through my sound card. By far the slower of the two
> is the ethernet, which runs at roughly 128 Hz.

What is the practical limit constraining your ethernet?

If you are using 10 megabit ethernet (the slowest available speed unless you
specialized or very old equipment), then even if you were to only send one
byte per packet (which would require 72 byte-times on the wire), the
theoretical bandwidth is 17.3 kilopackets per second, about 135 times faster
than you are seeing.

If you were somehow using 1 megabit per second ethernet (e.g., thickwire)...
I'd have to check old references about the details for that.

Scale upwards for 100 megabits/second (the most common speed these days, but
possibly not supported by older instruments.)

You should be able to get up to 16 data bytes per packet before the packet
rate is affected, with a limit of 512 data bytes per packet if you are using
first generation ethernet, and 1492 data bytes for anything in the last 15+
years, with a decrease in packet rate. Allow 80 byte-equivalent for ethernet,
IP, and UDP headers, including the intra-frame gap.
From: Stephane Beniak on 28 May 2010 10:19

> What is the practical limit constraining your ethernet?
>
> If you are using 10 megabit ethernet (the slowest available speed unless you
> specialized or very old equipment), then even if you were to only send one
> byte per packet (which would require 72 byte-times on the wire), the
> theoretical bandwidth is 17.3 kilopackets per second, about 135 times faster
> than you are seeing.

Well, actually it's a hardware constraint, so I'll give you a little background. I'm gathering data from Force Sensing Resistors (FSR) which goes through an interface box called a Gluion, and that box outputs packets at a maximum rate of about 128 Hz, I wrote a brief MATLAB script to confirm this. If I sample faster I get empty packets. If I don't sample it at maximum speed, it'll buffer up to 36 packets or so, but over time this still averages out to about 128 Hz.

The real problem, though, comes from the fact that I can't seem to instantaneously get data from my sound card's analog input, there's always some sort of delay or offset which screws everything up. So basically my question is this: Is there a way to read one single data point (or a short set of points) continuously/instantaneously using Analog Input (AI)? I've been messing around with getdata, peekdata, getsample, manual triggering, callbacks, etc., all to no avail.

I really appreciate any help you can give me.
From: Walter Roberson on 28 May 2010 11:53
Stephane Beniak wrote:
>
>> What is the practical limit constraining your ethernet?

> Well, actually it's a hardware constraint, so I'll give you a little
> background. I'm gathering data from Force Sensing Resistors (FSR) which
> goes through an interface box called a Gluion, and that box outputs
> packets at a maximum rate of about 128 Hz,

As the analog inputs are time-stamped, the accuracy of time stamping the
ethernet is going to be your limiting factor, unless the maximum sample
rate that you actually need is less than 128/2 = 64 Hz.

> The real problem, though, comes from the fact that I can't seem to
> instantaneously get data from my sound card's analog input, there's
> always some sort of delay or offset which screws everything up. So
> basically my question is this: Is there a way to read one single data
> point (or a short set of points) continuously/instantaneously using
> Analog Input (AI)?

Sorry, I do not have experience in that area.
From: Jan Houska on 29 May 2010 01:18
Hi Stephane,

Stephane Beniak wrote:
>
> The real problem, though, comes from the fact that I can't seem to
> instantaneously get data from my sound card's analog input, there's
> always some sort of delay or offset which screws everything up. So
> basically my question is this: Is there a way to read one single data
> point (or a short set of points) continuously/instantaneously using
> Analog Input (AI)? I've been messing around with getdata, peekdata,
> getsample, manual triggering, callbacks, etc., all to no avail.
> I really appreciate any help you can give me.

Soundcards are generally designed to acquire whole frames of data, not
individual data points. No particular attention is paid to the delay
between acquiring the sample and sending it to the application. This
means that you can read data continuously, but not instantaneously.

If you care about the delay between acquiring the data and processing
it, you will need to use a data acquisition board (not a soundcard) and
a real-time software. You may want to check Real-Time Windows Target
<http://www.mathworks.com/products/rtwt>.

Jan

--
Jan Houska HUMUSOFT s.r.o.
houska(a)humusoft.com Pobrezni 20
http://www.humusoft.com 186 00 Praha 8
tel: ++ 420 284 011 730 Czech Republic
fax: ++ 420 284 011 740
 | 
Pages: 1
Prev: Complicated stacked Bar Charts: is this possible?
Next: debugger question