Data acquisition

Data acquisition

Post by John Bens » Sat, 20 Jul 1996 04:00:00



     I need to acquire a 2million bit per second serial data
stream continuously into an Intel based platform.  My
engineers have found at least one card which is a FIFO which
takes clock and data, but the only drivers the company
sells with the card are for Win95 and NT.  All of our
products use UNIX or os/2, so it would be desirable for this
one to do it also.

    Is there a card we have overlooked which has a Solaris x86
driver, or if not, how hard is it to write a Solaris driver
if one has access to the source code of an MT driver?  After
all, the device is very simple.  The only problem is that
we have to not drop any bits, and the FIFO only holds 2 milliseconds
worth of data, so dispatching latency of the application
could become very important.


    John M. Benson
    Space Science and Engineering Center
    University of Wisconsin, Madison

 
 
 

Data acquisition

Post by John Bens » Sat, 20 Jul 1996 04:00:00


     I need to acquire a 2million bit per second serial data
stream continuously into an Intel based platform.  My
engineers have found at least one card which is a FIFO which
takes clock and data, but the only drivers the company
sells with the card are for Win95 and NT.  All of our
products use UNIX or os/2, so it would be desirable for this
one to do it also.

    Is there a card we have overlooked which has a Solaris x86
driver, or if not, how hard is it to write a Solaris driver
if one has access to the source code of an MT driver?  After
all, the device is very simple.  The only problem is that
we have to not drop any bits, and the FIFO only holds 2 milliseconds
worth of data, so dispatching latency of the application
could become very important.


    John M. Benson
    Space Science and Engineering Center
    University of Wisconsin, Madison

 
 
 

Data acquisition

Post by Guy Rixo » Sat, 20 Jul 1996 04:00:00



>      I need to acquire a 2million bit per second serial data
> stream continuously into an Intel based platform.  My
> engineers have found at least one card which is a FIFO which
> takes clock and data, but the only drivers the company
> sells with the card are for Win95 and NT.  All of our
> products use UNIX or os/2, so it would be desirable for this
> one to do it also.

>     Is there a card we have overlooked which has a Solaris x86
> driver, or if not, how hard is it to write a Solaris driver
> if one has access to the source code of an MT driver?  After
> all, the device is very simple.  The only problem is that
> we have to not drop any bits, and the FIFO only holds 2 milliseconds
> worth of data, so dispatching latency of the application
> could become very important.

We have a similar sort of rig for set up for Solaris on SPARC.  The
buffering is more like 80ms in our system and we still have a MTTF of
only a few hours when the driver is called from an `ordinary' program in
the time-sharing class.

The problem seems to be mainly due to occasional long latencies when
waiting for an I/O iterrupt to be scheduled.  The typical latency is
<1ms but the peak can be quite high.  Sun have made a number of
improvements in this area since Solaris 2.3 but it is not (and may never
be) deterministic like dedicated RT kernels.

Our suppliers say that it all works much better when the calling program
has high priority in the real-time scheduling class.  This implies that
the part of the kernel (a kernel thread? LWP?) servicing the interrupt
somehow inherits priority from the user-mode thread that set up the
interrupt handler.  I don't know if this is a known or documented
feature of Solaris.

Other things that may help or hinder: if there is only one data stream
and the data volume is known and finite, you can maybe do the
acqusiition as one giant DMA.  This, with appropriate H/W support,
should remove the need to service a sequence of I/O interrupts.  If you
have to page a buffer that's used by the driver you'll probably miss
your timing (driver will block until the paging is complete which may be

Quote:>>1ms).  The latencies _may_ be made worse if the machine in question is

an NFS server.

--

Software Engineering Group,             Tel: +44-1223-374000
Royal Greenwich Observatory             Fax: +44-1223-374700

 
 
 

Data acquisition

Post by Jim Stephe » Sun, 21 Jul 1996 04:00:00



>     I need to acquire a 2million bit per second serial data
>stream continuously into an Intel based platform.  My
>engineers have found at least one card which is a FIFO which
>takes clock and data, but the only drivers the company
>sells with the card are for Win95 and NT.  All of our
>products use UNIX or os/2, so it would be desirable for this
>one to do it also.
>    Is there a card we have overlooked which has a Solaris x86
>driver, or if not, how hard is it to write a Solaris driver
>if one has access to the source code of an MT driver?

It should be of some help since the way to access the controller would
be there, and a sane way to check out comparisons between platforms
with the same hardware would be there.

The structure of Solaris is much the same as on any platform, but you
have the added plus of not having to load them when you boot.  You can
load drivers and unload them (with care) multiple times after booting.
The kadb is sufficient to do the low level debug, and if you are
careful, you can possibly get away with very little of it being
necessary in the kernel.  One thing you give up without some inside
knowlege of the system is that you will have to have the system
console in character mode to use kadb, and you can't run openwin to
have access to your listings, etc, so an additional platform is
necessary when doing the development.

Quote:> After
>all, the device is very simple.  The only problem is that
>we have to not drop any bits, and the FIFO only holds 2 milliseconds
>worth of data, so dispatching latency of the application
>could become very important.

You can use realtime scheduling in both the kernel threads and user
threads to control this.  I am more curious how you will find disks
that don't go away unless you write to a raw disk continuously, and
even then unless you use high capacity (and dollar) "av" drives that
suppress thermal recals, you will be bit the periodic recals that all
modern drives have to do, which are longer than 2ms.  Hope you can
catch a few more ms in memory to extend your down time.

Is this to be processed and stored, or stores raw?  There are some
inline compression products that would have the effect of shrinking
how much data you have to ship if you must ship it somewhere.


>    John M. Benson
>    Space Science and Engineering Center
>    University of Wisconsin, Madison

JIm
 
 
 

Data acquisition

Post by c.. » Sun, 28 Jul 1996 04:00:00


:
:      I need to acquire a 2million bit per second serial data
: stream continuously into an Intel based platform.  My
: engineers have found at least one card which is a FIFO which
: takes clock and data, but the only drivers the company
: sells with the card are for Win95 and NT.  All of our
: products use UNIX or os/2, so it would be desirable for this
: one to do it also.
:
:     Is there a card we have overlooked which has a Solaris x86
: driver, or if not, how hard is it to write a Solaris driver
: if one has access to the source code of an MT driver?  After
: all, the device is very simple.  The only problem is that
: we have to not drop any bits, and the FIFO only holds 2 milliseconds
: worth of data, so dispatching latency of the application
: could become very important.
:

Hi -- well first off I'd like to suggest that any solution that
provides less than ten seconds of buffering should probably not
be considered favorably.

For less than $300 you can buy a VRAM based SVGA card which
outputs > 2.4 gigabits per second (24 bits / pixel at > 100 MHz)
synchronously, and has 16 megabits ( eight seconds for your rate )
of data buffering, and a fast PCI interface. :-)

The reason I bring this up is just to make the point that the
technology is out there to solve your problem in a much
nicer manner than a small FIFO card.

As others have pointed out, time sharing latencies and storage
medium latencies will be a serious risk to your data integrity
with less than a couple of seconds of buffering.

Another consideration might well be that the acquisition / storage
system might be a lot more reliable if it didn't have a PC
involved.  The more components (hardware and software) that are
involved in a system, the more likely it is to fail.

I know there are data recorders on the market that can acquire at those
speeds directly to their own storage medium (tape / disk / RAM / etc.),
and can be used for retrieval once the event is over.
(When you say "continuously" I'm presume that you mean for a finite
amount of time, but long in duration to the bit rate).

I believe that you may be able to find devices which can interface the
incoming data to a high performance interface such as a SCSI bus,
ATM network, P1394 "Fire Wire" bus, etc.  If you did have to customize
a driver for your data acquisition needs you'd probably be much better
off starting with such an ordinary type of interface.

Another option (which might be the least expensive and least
complex to configure) would be to use ordinary high performance
serial interface adapters with built in buffering.  (When
you say "serial data" I presume you mean one-bit serial + clock)

I'm not an expert on the various manufacturers' products, but
between MAGMA, CHASE RESEARCH, COMPUTONE, DIGI-BOARD, and other serial
interface manufacturers you should be ablt to find a solution.
Better still -- they should already have SOLARIS X86 drivers!

Look for a board with synchronous serial support that'll handle
your 2 Mb/s data rate capability, a megabyte or two of buffering,
and a fast host interface (SCSI, PCI, ISA/DMA, etc.).

Then presumably all you'll need to do is convert the logic level
of your input / clock signals to the appropriate serial interface
standard (RS422, RS423, V.35, whatever) and you'll be set.
I suppose you may need to switch the clock polarity too if you're
particularly unlucky.  But none if this is complicated, and should
be something your engineers can do -- or you could have customized
for you quickly / inexpensively.

Two megabits per second is well within the reception rate of most of
the serial data communications chips out there (8530, 2661, 2400 series,
68302, 68360) that these manufacturers are using in their products.

A common "T1" frame relay link to the internet runs one of these
boards at 1.544 Mb/s on a V.35 type interface.  RS422 communication
is specified to to operable for over 10 Mb/s synchronously, and
there are lots of RS422 interface adapters out there.

Good luck!

 
 
 

Data acquisition

Post by c.. » Mon, 29 Jul 1996 04:00:00


Just from a bit of looking around on the WWW:

1) I wonder if you're doing the same thing that the folks at
   http://kurp-www.hut.fi/ams-docs/
   ...are, a 2Mb/s HRDL telemetry acquisition system.

2) http://www.formation.com/VME.html/fpc360-1
   ("4-Port PCI WAN server"; four ports to 2Mb/s)

3) http://www.technobox.com/catalog.html
   http://www.technobox.com/p1371.html
   http://www.technobox.com/p1447.html

   (4 Port RS422 Synchronous Communications Adapter
   provides to 10 Mb/s per channel -- PMC PCI format,
   use the [1477] adapter for PCI card slot use)

4) http://www.gocct.com/sheets/ccpmc004.htm
   (four channels up to 2.048 Mb/s; PMC PCI format, use
   PCI slot adapter for PCI card slot use)

5) http://www.value.net/~tec/ccp.html
   (only an AT ISA interface, but still it ought
   to do the trick.  Sounds like it is pretty flexible for
   customization of firmware, etc. for your special requirements)

6) http://www.tripleis.com/datapipe.html
   (PCI card; seems nice / flexible)

7) http://www.cerfnet.com/~gmmres/
   (looks like they've got a few card models
   which would work; intended for diverse applications
   PCI, ISA, etc.)

8) http://www.erinc.com/dnx.htm
   (not an interface card, but an interface bridge;
   looks like you might be able to go from
   your data stream to ATM, E1, etc.)

The PCI interface products are nice because in addition to whatever
buffering is provided on the interface board, one could presumably
set up aribitrarily large "DMA" buffers in the main system's memory.
Not having to deal with ISA's limitations so much is usually a good move.

I'm sure there are many more such interfaces out there other than these.

I'd talk to the vendors about your application and make sure that

1) their firmware / software will permit the kind of raw (unframed)
   data stream access you need synchronously.

2) What kind of buffering arrangements are configurable on their
   card, and through their PCI (et.al.) controller into host memory.

3) What drivers may be available for their products already, and
   if one isn't available are the interface register specifications
   available so you can write one.

   (this shouldn't be hard, really, given a nice PCI interface controller
   on the card, and maybe the Solaris DDK).

Of course there are S-bus products out there for SPARC systems that
do similar things, and have Solaris drivers already of course.

The E.D.T. Products SCD-20 came up in this category; it is probably
overkill for your application.  http://www.edt.com/scd20.html
There are others, I'm sure.


 
 
 

Data acquisition

Post by c.. » Mon, 29 Jul 1996 04:00:00


Just from a bit of looking around on the WWW:

1) I wonder if you're doing the same thing that the folks at
   http://kurp-www.hut.fi/ams-docs/
   ...are, a 2Mb/s HRDL telemetry acquisition system.

2) http://www.formation.com/VME.html/fpc360-1
   ("4-Port PCI WAN server"; four ports to 2Mb/s)

3) http://www.technobox.com/catalog.html
   http://www.technobox.com/p1371.html
   http://www.technobox.com/p1447.html

   (4 Port RS422 Synchronous Communications Adapter
   provides to 10 Mb/s per channel -- PMC PCI format,
   use the [1477] adapter for PCI card slot use)

4) http://www.gocct.com/sheets/ccpmc004.htm
   (four channels up to 2.048 Mb/s; PMC PCI format, use
   PCI slot adapter for PCI card slot use)

5) http://www.value.net/~tec/ccp.html
   (only an AT ISA interface, but still it ought
   to do the trick.  Sounds like it is pretty flexible for
   customization of firmware, etc. for your special requirements)

6) http://www.tripleis.com/datapipe.html
   (PCI card; seems nice / flexible)

7) http://www.cerfnet.com/~gmmres/
   (looks like they've got a few card models
   which would work; intended for diverse applications
   PCI, ISA, etc.)

8) http://www.erinc.com/dnx.htm
   (not an interface card, but an interface bridge;
   looks like you might be able to go from
   your data stream to ATM, E1, etc.)

The PCI interface products are nice because in addition to whatever
buffering is provided on the interface board, one could presumably
set up aribitrarily large "DMA" buffers in the main system's memory.
Not having to deal with ISA's limitations so much is usually a good move.

I'm sure there are many more such interfaces out there other than these.

I'd talk to the vendors about your application and make sure that

1) their firmware / software will permit the kind of raw (unframed)
   data stream access you need synchronously.

2) What kind of buffering arrangements are configurable on their
   card, and through their PCI (et.al.) controller into host memory.

3) What drivers may be available for their products already, and
   if one isn't available are the interface register specifications
   available so you can write one.

   (this shouldn't be hard, really, given a nice PCI interface controller
   on the card, and maybe the Solaris DDK).

Of course there are S-bus products out there for SPARC systems that
do similar things, and have Solaris drivers already of course.

The E.D.T. Products SCD-20 came up in this category; it is probably
overkill for your application.  http://www.edt.com/scd20.html
There are others, I'm sure.


 
 
 

1. Data Acquisition using linux with [Data Acquisition Processor] DAP

Hi
Can Anybody Suggest me how to start off with  data acquisition
progamming in c on linux ,using the DAP card ....it would be kind if
someone let me know some websites which guides how to start
programming or some sites where examples are there .........i have
done  data acquisition using Graphical Language and i want to try in
linux using "C" ........i also want to know how to interact with the
DAP card

can any body please give some guide lines

thnax
james

2. DPT Raid Hardware

3. serial port data acquisition without data loss?

4. Command history of Korn Shell

5. PC104-DAS16Jr/16 data acquisition card

6. Problem installing RedHat 4.0 on Thinkpad 760ED

7. Data Acquisition

8. AGP card CL-GD5465 and other AGP cards

9. Data Acquisition Help

10. Data acquisition with Linux?

11. data acquisition hardware

12. Data Acquisition Card + Counter

13. Data acquisition device drivers