Data Acq. Concept Help

Hi,

I've got ~220 low-freq. (0 to 4V max) signals to measure and send to another computer (over ethernet).

This group of signals will be handled by a single data acq. module physically separate (20 meters) from identical others, all connected by an ethernet bus.

Module Concept & Reqmts:

--PC-104 CPU board with USB and Ethernet interfaces. Ethernet to other modules, USB to custom DAQ boards, described below.

--Want to divide-up the 220 inputs into ~50 per board, -> ~ 5 boards, spare channels good.

--High Common-Mode voltage (< 200VDC) on some inputs, -> difference amp front end on some channels. (LTC1990)

--Digitize signals (12-bit) with I2C ADC's (thinking MAX1238)

--Offload data from boards to local PC via USB. Would like to use the Cypress EZ-USB or the Cypress PSoC with USB onboard (CY8C24794). This would be the I2C to USB bridge. I want to keep the USB interface and not use only I2C controlled by PC-104 board.

Questions:

--How do I buffer the data on the DAQ boards until I can read it off with the USB interface? Will the CY8C24794 PSoC with an M8 =B5C or the

8051 =B5C on the EZ-USB interface with external memory (onboard flash on the PSoC has too few read cycles to use continuously). Perhaps the 8051 is more suitable than the M8 for interfacing with external memory.

Any PSoC experts that wouldn't mind some additional questions down the road if I go that route?

Thanks for sharing your insights! Omar

Reply to
schmoester
Loading thread data ...

Seems an utterly horribly complicated method for getting a slow speed DAQ system into an ethernet connection.

Ignoring the input conditioning, I'd start with say 64 NS's adcs7478 spi adcs per board. Poll them with a 8051, (since I never did get around to learning the msp430) That 64*2 bytes per board times your sample rate, say 50s/sec. A massive 6.4KB/sec. Might have to put 8K of external ram on the 8051, dammit

Feed them into a Lantronix Xport or eqiuvalent, and give them individual IP addresses

Whats the software budget for this? Or am I missing something?

martin

Reply to
martin griffith

Hi Martin,

Thanks for the reply. That's a great concept.

I have just a couple issues: I've got nine of these modules, each of which have to send their data to a central computer. To have each board have it's own ip address (5 bds x 9 modules =3D 45) seems like too many for the central computer to talk to, versus say nine. I'm sure it can be done, but what do i use for a hub? One per module and another to collect the modules I guess.

If I were to use an single Xport per module, how would I get the data to it from the 5 daq boards in each module? I was thinking USB--maybe just replace my PC-104 board with a custom board with an XPort on it?

You're right, there's a lot of software to be done. I'm very much interested in simpifying, and I agree, my concept seems overly complicated. I also thought USB on the cards would also facilitate bench testing them.

Thanks aga> >

Reply to
schmoester

Please don not top post a reply, it annoys many people, and wars start!

The limit seems to be the size of the board. The data rate is slow enough that a single 8051 micro could handle the complete number ADC channels. I'm confused between by what you mean by modules. But having an 8051 board with 64 ADCs would mean only 4 boards to give 255 ADCs and would only use 4 web servers like the lantronixs, that is one per board. That is 4 ip adresses.

This USB stuff. Just another layer of confusion for me. Many micros already have a UART internally, I'd just put on a max232 driver and talk to it via an old fashioned terminal program. I still use procomm from 20 years ago on occasion, or window$ terminal. I avoid hyperterminal. This makes debugging very easy.

If you put a double pole change over switch between the microprocessor TX and RX uart lines that switches between RS232 and the lantronixs xport, you can bypass all the ethernet "layer of confusion" for testing.

I suggested SPI over I2C, for 2 reasons

1) you may run out of I2C adresses 2) SPI is easier to write code for (my opinion),

martin

Reply to
martin griffith

by

amp

memory.

Hello all,

This doesn't need zillions of boards or 64ADCs.

Try 8 x ADG731 or ADG732 multiplexers (32 in 1 out, 7mm square package) and

1 Silabs 8051F005 (8051 core, 12 bit, 100kHz ADC with 8 channel mpx).

Talk to the Lantronix thingy using the uart on the 8051 and you have the whole shooting match in 10 chips and it will all fit on a 100mm square board quite easily.

Dont forget to protect the silicon with resistors and transient stoppers of some kind. You can get these in 4 wide arrays in 0805 size packages so the

64 - 128 you are going to need will still fit on the board. RC filters are a good idea as well.

I think you may need 6 layers and 0.006" design rules to cope with the 7mm chip scale packages on the multiplexors but one high tech board is much easier to deal with than loads of bits all trying to talk to each other.

Michael Kellett

formatting link

Reply to
MK

On Thu, 21 Jul 2005 08:02:51 +0100, in sci.electronics.design "MK" snip

Thats very true, I was very slow in thinking, thanks for waking me up!

martin

Reply to
martin griffith

Hi Michael,

Gentlemen, thanks for the ideas! I'm a EE that's been doing software for the past 10+ years so I really appreciate the advice. If I do a good job with this I may get more HW projects :-)

I was thinking 8 to 12 ch. ADC chips I2C or SPI controlled. The larger mux/single ADC might be easier, but possibly less reliable; if it fails I'll loose a larger group of channels. That's probably why you elaborated on the protection required, which I will surely provide regardless. Maybe the more stringent pcb requirements for the ADG731 mux would make a stronger case for the 8 to 12 channel devices as well? I will think further on the tradeoffs--I think it's a good idea.

I don't believe I can combine all signals on a single board for the following reason. The signals into the module are from a string of 2+ VDC battery cells so I have a high common mode issue that requires some isolation so not all channels be on the same board. For e.g. 64ch per board (64 x 2.75 V = 175 V), which I will handle by using difference amp front end and isolating between boards. (210 x 2.75 V = 578 V) This was probably overlooked from my original post.

The Lantronix XPorts are ~ $50 each so for 4 boards is 200.00 bucks. I don't think I can get away with 1 board. Not to mention the required hubs for the network.

On the other hand, Cypress USB on the PSoC is ~ $2.00/chip, or the EZ-USB (8051 on board) probably similar price. I'll still need a PC-104 board to interface with the USB based boards, and ethernet interface to a central data collection computer. USB enables easy bench tests of the boards with LabView and any PC, and seems to provide quite a flexible product. I'm seeing advantages with my original concept.

I would like to avoid the PC-104 boards: Maybe one XPort put somewhere in a module could take it's place and provide the ethernet interface to a central computer, but then how do I collect the data off the boards via USB? PC-104 does seem like overkill, but would enable data formatting and preprocessing i.e. averaging (not required) and possibly diagnostic functions (are required).

All in all, I'll have 9 modules (to clarify, each module acquires data from 210 high common-mode inputs, some temperature measurements, etc.

225 signals, plus a few spares) into the 4? boards we're discussing, with some type of ethernet access to a central computer that collects all the measured data from each of the modules (9 x 225+ signals total)
Reply to
schmoester

Hello,

You never told us about the hard bit !

(I remember an earlier thread about this and I think the suggestions were relay multiplexors).

You'll have trouble if you try and float the boards at different DC voltages - just imagine trying to debug some 3.3V logic with 500V DC on top.

I don't think that any of the difference amplifiers like TI INA117 (only

200V) can cope with 600V common mode so you end up with an isolation amplifier, which is expensive or making your own difference amps (with precision resistor issues like drift and trimming).

If you can steal power from the cells you are measuring then there are little AVR processors which will run from 2V and have built in voltage references and 10 bit A-D converters. You could use one per cell and let them talk to a central processor via an opto-coupler. You would have to expect to steal an average current of perhaps 50uA from the cell which may not be possible.

Michael Kellett

Reply to
MK

Thanks Michael,

I plan to use linear optocouplers for the isolation, and need to figure out how to use the difference amp to linearize them with the feedback output from the optocoupler. There are app notes on this.

I want to minimize load on the batteries. Also, some inputs to the daq module are from sensors other than the batteries, but output a similar voltage level. If I avoid dependence on the battery voltages, I can put any input on any channel for flexibility.

Ideally, I'd like to disconnect inputs from the unit when it's not in use, but don't want to use (many!) mechanical relays. The spec sheets on the difference amps show a resistor network from the inputs to ground, lowering the input impedance from whats seen on a typical opamp, so there will be current draw. I guess we're stuck with manually removing the connectors from the module chassis to disconnect the inputs, unless I can think of something clever to do this.

I noticed on your web site you've worked alot with USB. Is it difficult to write driver code on the embedded side? I'd like mine to conform to the test and measurement class standard. Could you offer any advice? Have you worked with the Cypress chips? I'm still not clear on how the data from the ADC's will be accumulated and then read off the board from the USB port. I believe I need to interface external memory to some MCU device. Maybe the USB fifo memory will suffice? This is all new to me. The Cypress EZ-USB has an 8051, I'm thinking I can use this.

Much thanks!

Reply to
schmoester

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.