Design: High-Speed, High-Volume Digital Input

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I need a build or buy a system that can record digital transmissions on
a 4-bit proprietary bus.  The bus transmissions occur roughly every
300us, and the transmissions are short 10MHz bursts.  Through whatever
means necessary, I need to store a minute's worth of this data to a
file that I can access from a PC.  Of course, this would require lower
data storage volume if the device is able to sense transitions on the
bus, instead of just storing regular, time-sampled data.

I've considered buying National Instruments' High Speed Digital I/O
boards, but -- I figured I should ask around to see if there are
better, more turn-key solutions available.  Maybe something like a
specialized logic analyzer?

Any help will be greatly appreciated.  -Zach


Re: Design: High-Speed, High-Volume Digital Input
OK so you are trying to store bursts of data from a 4 bit bus that occur
every 300us.

1)When you say "short 10MHz bursts" do you mean that the data rate is 10
Mega nibbles per second?
2)How long is the burst length?
3)Is the burst length a constant?
4)What is the static condition of the bus in-between bursts?
5)Does the leading nibble of every burst always differ from the static
condition of the bus?
6)Is the solution meant for production or just a one time thing?

Thomas

Quoted text here. Click to load it



Re: Design: High-Speed, High-Volume Digital Input
"Off-the-shelf" will save you a lot of time and money when trying to solve
this particular problem.

This first link is over-kill.
http://www.innovative-dsp.com/products/lobo.htm
This one would be a lot cheaper.
http://www.innovative-dsp.com/products/lobo.htm

In fact just give the requirements to the engineers over at innovative-dsp
and they will tell you exactly what hardware you will need and how to
implement it.

Thomas


Quoted text here. Click to load it



Re: Design: High-Speed, High-Volume Digital Input
Quoted text here. Click to load it

The first thing to characterize is throughput, in bits (or bytes)
per second.  The second thing is the maximum burst data rate.  How
much total data (max) is appearing in that 300 uS period.  10 Mhz
burst means very little, is that 10 M bits/second, nibbles (4bits)
per second, or what.  Depending on these you can calculate the
storage and data rates needed.  Another thing is the 'dead'
periods.  Can the system accumulate the one minutes worth, and then
just devote itself to unloading for a period?

For example, if the 10 Mhz is bits/second, appearing 4 bits
parallel, you have 250 nS in which to grab and store them.  If you
make some hardware (a PLA for instance) you might collect two
nibbles into an octet, and store that every 500 nS for the bursts.
You have to include the time for testing burst completion, etc. in
the loop.  But you can't even start without proper specifications.

You may or may not find you can handle it with just a simple
processor.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Design: High-Speed, High-Volume Digital Input
Quoted text here. Click to load it

Look here  http://www.tech-tools.com/dv_main.htm under hardware compression
- they have innovative approach allowing high volume of data with 10nS
resolution...

- Dejan



Re: Design: High-Speed, High-Volume Digital Input
Quoted text here. Click to load it

See my sig below for the proper use of google groups.  Lack of
quoting makes articles almost useless.

Your plan sounds reasonable.  You don't say how the data is
clocked.  You will need timing diagrams, specifying hold times
etc.  I would expect a PLA to suffice for the gathering and
packing, but overspecification for a one-off (or even a ten-off)
can't hurt.  It will not hurt if the front end device can capture
the full burst and allow the remainder of the 300 uS for the
software to transfer it.  The total storage is only 3.5 MB
according to me, and the Ethernet connection may not be able to
keep up, depending on other users, business, etc.  If you can you
would be better off planning to store the whole burst on the
interface, and unloading it at leisure.  Memory is pretty cheap
these days.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on
We've slightly trimmed the long signature. Click to see the full one.
Re: Design: High-Speed, High-Volume Digital Input
Thanks, all.  I really appreciate your input.  It will take me a little
while to investigate all of these great suggestions.  I'll post a
summary of my findings in a few weeks.

-Zach


Re: Design: High-Speed, High-Volume Digital Input
Dear Zach.

I saw many posts here with solutions, but all of them are too complicated! I
think your solution is:

Part1-A XILINX CPLD like coolrunner II has dual edge flipflops, so everytime
a bit change to low or hi, you'll have and event or you can use a 95XL
family that's 2.5 to 5volt tolerant and program it for dual edge feeding a 8
bit communication channel to a PC.

Part2-A experimental board (very cheap!!!) for USB connection with fifo and
windows drivers that simulate a serial port up to 921kbps like this here:
http://www.dlpdesign.com/usb/usb245.html
NOTE:Power supply comes from the usb port using a 3.3v regulator.

Part3-An off the shelf serial port logging software or your own with VB, VC,
or whatever you are confortable!

Part4-(Optional)A bare bone PCB made in 24h from www.pcbexpress.com

Part5-Done in 12h for less than $120!!!!!!!!


Quoted text here. Click to load it



Site Timeline