C programmer needs to design a complete system to process a video pulse wave.

Gentlemen,

I'm a systems programmer working with a bunch of EE guys that have
given me a task that I can solve in C but now I must move the
application to a real-time embedded system.  That's where I get lost,
and I'm hoping that someone can explain to a laymen what I need to buy,
assemble, put together to accomplish my task.  I believe some sort of
DSP is what I need, but going through the websites at TI, GE FANUC,
Curtiss Wright, they all assume a knowledge base that I don't have.
I'm hoping someone can explain a complete set of hardware, software
development kit, and assorted bling  so I can capture some analog data,
funnel it to an array of data that I can process in C, and then output
the data to an output broadcasting device.

Anyway, here is what I'm working with:

My boss hooks up a video eye to an oscilloscope and saves 10ms worth of
data sampled at 1,000,000 samples a sec (1mS/s is that the right
syntax???) giving me a data set of 10,000 data points of 2 values of
information, time index and value:

00000	0.00052
00001	0.00056
00002	0.00052
00003	0.00060
00004	0.00064
00005	0.00052
00006	0.00064
00007	0.00048
00008	0.00060
00009	0.00048
00010	0.00048
00011	0.00064
00012	0.00048
00013	0.00036
00014	0.00060
00015	0.00052
00016	0.00068
00017	0.00044
00018	0.00060
00019	0.00060
00020	0.00048
00021	0.00588
00022	0.00648
00023	0.00696
00024	0.00672
00025	0.00668
00026	0.00668
00027	0.00664
00028	0.00660
00029	0.00676
00030	0.00660
00031	0.00656
00032	0.00624
00033	0.00632
00034	0.00624
00035	0.00604
00036	0.00600
00037	0.00604
00038	0.00608
00039	0.00596
00040	0.00576
00041	0.00572
00042	0.00564
00043	0.00556
00044	0.00564
00045	0.00564
00046	0.00564
00047	0.00532
00048	0.00504
00049	0.00248
00050	0.00128
00051	0.00104
00052	0.00112
00053	0.00104
00054	0.00080
00055	0.00080
...
09999   0.xxxxx

like above in a text file.  So I write a program program that does some
number crunching, and he loves it.

Now he wants me to move this application to an imbedded processor such
that the 10,000 samples are captured in 10ms, and my crunching must
occur within 20ms.  So far so good.
if my crunching algorithm finds the widget, I'm to broadcast a signal
on an digital output board(???)
that matches the input signal in both frequency and phase lock.  This
input signal will most likely be something between 25-1000hz (thats
relatively slow yes???) After the broadcast or if no widget is found,
the entire process should continue for another 10ms sample, and
continue as such forever.

Well now I'm lost in hardware/software.  What do I need?   all I have
so far is a Windoze machine with some USB ports.  I'm assuming I have
to buy some imbedded processor with input boards and output boards,
some power supply for them, some software development kit that allows
me to program in C that targets its executable image for the imbedded
processor and then some cable connections.

Any help would be greatly appreciated, I'm hoping that what I've
described is enough to suggest a working environment.  This device
should start its functional loop on startup, and I might complicate
this simple proof-of-concept down the road, but since I can't even find
an acceptable "soup-to-nuts" solution for this simple case, I don't
want to throw out all the additional bells and whistles.

Seems to me that all you need is a PCI card with fast A/D D/A hardware on
it, including a reasonable size fifo and a software driver to perform I/0
(preferably by DMA) Your average datarate seems to be of the order of
2MB/sec, which should not stress the PCI bus too much.

A pentium processor should be fast enough to process your data, unless it
is very fancy. To aid this, I suggest you make use of optimised C/C++
vector libraries such as Intel's IPP, or the Optivec library. Google
around for more information on these.

Before you commit yourself however, I suggest you benchmark your routines
to ensure the Pentium CPU can handle them.

Other than that, you are on your own old chap - we've all been there, it's
the only way to learn your art.

Jeff

" Other than that, you are on your own old chap - we've all been there,
it's
the only way to learn your art."

Yup I'm beginning to understand that part as well.  Seems the main
reason I got the job is that I'm willing to at least try and come up
with a solution.  Everybody else is scared of the blank sheet of paper
that needs to be filled with a parts list to purchase and commitment to
finish the task.

You mention a pentium processor which leads me to believe that you
think I can run this in a pc environment.  This is not the case, This
entire process must occur within 30ms, and exactly timed at that. As
any PC or Unix environment I know will have an unknown timing factor of
data transfer I believe no time sharing OS can be in the equation.
Are you talking about a pentium based imbedded processor? I will be
processing a 10ms sample and have 20ms to process and make a decision
about the sample as to whether or not to re-broadcast the determined
signal. I'll need to know how much time I've spent of the 20ms so I can
re-broadcast with a phase-lock.  - Gee I've never had to worry about
this kind of stuff on Wall st, my last programming gig.

I'm leaning towards TMS320C6455 DSP Starter Kit (DSK) from TI.COM with
a code composer SDK.  This seems to have all the pieces for this task,
and the speed capabilities.

Thanks for your input.

Sincerely,

Jonathan Leslie




Jeff Caunter wrote:
> Seems to me that all you need is a PCI card with fast A/D D/A hardware on
> it, including a reasonable size fifo and a software driver to perform I/0
> (preferably by DMA) Your average datarate seems to be of the order of
> 2MB/sec, which should not stress the PCI bus too much.
>
> A pentium processor should be fast enough to process your data, unless it
> is very fancy. To aid this, I suggest you make use of optimised C/C++
> vector libraries such as Intel's IPP, or the Optivec library. Google
> around for more information on these.
>
> Before you commit yourself however, I suggest you benchmark your routines
> to ensure the Pentium CPU can handle them.
>
> Other than that, you are on your own old chap - we've all been there, it's
> the only way to learn your art.
> 
> Jeff

Hard Real-Time *is* possible on a desktop PC. Take a look at
http://www.windowsfordevices.com/articles/AT5376962137.html There are lots
more articles on the net if you Google for them.

My experience has been that a current Pentium PC will peform well against
a single fast DSP chip, especially if fast vector libraries are used.

At work, we no longer procure expensive DSP COTS equipment, preferring to
use Pentium processors - networking them with GbEthernet if necessary. The
cost savings are substantial both in hardware and development time.

Where extreme speed and very low latency is required however, we still use
FPGAs.

Can you give some hint as to the type and extent of processing that you
are intending to perform?

Jeff

"Jeff Caunter" <jeffcaunter@sparkysworld.co.uk> writes:

> My experience has been that a current Pentium PC will peform well against
> a single fast DSP chip, especially if fast vector libraries are used.

So you mean that a chip that requires megabytes of main memory, sucks
about 1000 times the current, is 10 times larger, and 10 times more
expensive performs about the same as a fast DSP?
-- 
%  Randy Yates                  % "I met someone who looks alot like you,
%% Fuquay-Varina, NC            %             she does the things you do, 
%%% 919-577-9882                %                     but she is an IBM."
%%%% <yates@ieee.org>           %        'Yours Truly, 2095', *Time*, ELO   
http://home.earthlink.net/~yatescr

Randy Yates skrev:
> "Jeff Caunter" <jeffcaunter@sparkysworld.co.uk> writes:
>
> > My experience has been that a current Pentium PC will peform well against
> > a single fast DSP chip, especially if fast vector libraries are used.
>
> So you mean that a chip that requires megabytes of main memory, sucks
> about 1000 times the current, is 10 times larger, and 10 times more
> expensive performs about the same as a fast DSP?

I didn't read that. I interpreted Jeff to say that pentiums are
*sufficiently* fast and drain *acceptable* power, they are
not "best" in any of these respects. The main benefit seems
to be on unit cost and development time.

Once the minimum requirements are met, factors like cost
and development time etc become very relevant.

Rune

"Can you give some hint as to the type and extent of processing that
you
are intending to perform?"

It won't be anything anything too intense, I need to pick out the
signal pulses and pulse width  out of a carrier wave, so it will be
some variation of a FFT.  The signal pulse cycle will be somewhere
between 25-1000hz, The big trick is the timing, hence the need for
imbedded processor (and possibly FPGA although I'm hoping to avoid
FPGA, I understand its a bear to work with). I'll sample for 10mS, and
process for as much as 20ms to determine if the pulses are there.  If I
find them, I want to transmit the found signal, for X seconds, but I
need to be phase locked with the original signal so I don't mess it up
(I'm just boosting the signal sort of selective
repeater/re-transmitter.)

I don't believe I will be able to phase lock with the original signal
if I don't have an accurate measurement of how long its been since I
got the original signal.

For example, I've got a 10ms sample at 1MS/sec giving me 10,000
samples.  Say my sample detector algorithm detects the cycle starting
at the 1000 sample, and ending at the 3500 sample.  I will need to
broadcast that signal every 3500-1000== 2500Ms (microseconds) but
starting 1000Ms after some multiple of 10ms sample. I'll need to know
exactly how much time I've spent of the 20ms, to figure out when to
start transmitting the signal. I hope I explained that correctly.





Jeff Caunter wrote:
> Hard Real-Time *is* possible on a desktop PC. Take a look at
> http://www.windowsfordevices.com/articles/AT5376962137.html There are lots
> more articles on the net if you Google for them.
>
> My experience has been that a current Pentium PC will peform well against
> a single fast DSP chip, especially if fast vector libraries are used.
>
> At work, we no longer procure expensive DSP COTS equipment, preferring to
> use Pentium processors - networking them with GbEthernet if necessary. The
> cost savings are substantial both in hardware and development time.
>
> Where extreme speed and very low latency is required however, we still use
> FPGAs.
>
> Can you give some hint as to the type and extent of processing that you
> are intending to perform?
> 
> Jeff

"Rune Allnor" <allnor@tele.ntnu.no> writes:
> [...]
> The main benefit seems to be on unit cost [...]

Huh? Let's see: $5-10 versus $150...

Perhaps my original comment did carry too much sarcasm. Modern-day PCs
can approach or match the computational power of all but the most
powerful DSPs (e.g., the GMACS/second that the TI 64x series is
capable of).  They also are much, much easier to obtain, learn, and
program. That makes them nice environments for developing algorithms. 

However, if one is required to deliver a hardware product, it is
usually not feasible (cost, space, power, etc.) to use that platform.
-- 
%  Randy Yates                  % "Maybe one day I'll feel her cold embrace,
%% Fuquay-Varina, NC            %                    and kiss her interface, 
%%% 919-577-9882                %            til then, I'll leave her alone."
%%%% <yates@ieee.org>           %        'Yours Truly, 2095', *Time*, ELO   
http://home.earthlink.net/~yatescr

Randy Yates skrev:
> "Rune Allnor" <allnor@tele.ntnu.no> writes:
> > [...]
> > The main benefit seems to be on unit cost [...]
>
> Huh? Let's see: $5-10 versus $150...

How many man-hours do you get for $140? How many more
man-hours do you need to get that one-of-a-kind $5 chip to
work properly? How many units do you need to produce
to make up for the extra effort on getting the thing to work?

Pure economy. Volume. Development cost. Cost per
prodiced unit.

> Perhaps my original comment did carry too much sarcasm. Modern-day PCs
> can approach or match the computational power of all but the most
> powerful DSPs (e.g., the GMACS/second that the TI 64x series is
> capable of).  They also are much, much easier to obtain, learn, and
> program. That makes them nice environments for developing algorithms.

Exactly. And if you only need a couple of units, this may be
the cost-effective solution.

> However, if one is required to deliver a hardware product, it is
> usually not feasible (cost, space, power, etc.) to use that platform.

It depends. You may be right if we are talking about consumer
electronics. In industrial plants, on th eother hand, size and power
consumption needs not be an issue at all.

Rune

"Rune Allnor" <allnor@tele.ntnu.no> writes:
> [...]
> Pure economy. Volume. Development cost. Cost per prodiced unit.

You misunderstood me and I misunderstood you. My "unit"
was the computing device; your "unit" was the end product. 
-- 
%  Randy Yates                  % "Watching all the days go by...    
%% Fuquay-Varina, NC            %  Who are you and who am I?"
%%% 919-577-9882                % 'Mission (A World Record)', 
%%%% <yates@ieee.org>           % *A New World Record*, ELO
http://home.earthlink.net/~yatescr