1. Home
  2. Electronics Design
  3. REQ: major electronics analysis project help needed TIA

REQ: major electronics analysis project help needed TIA

currents. I plan on using simple inductive pickups and voltage probe points.

How many sample points will you need per effective sample? A-Ds have many subtle errors, and taking multiple samples can help around that. There are a number of algorithms available to give a more accurate result, even in the presence of noise. That brings up how fast the effective sample must be taken, which will help you decide what type of converter to use.

How simultaneous is 'same time' ? Can some systems be treated in relative isolation, (for instance, can 20 or so [or whatever] of the inputs be dealt with as a separate / independent set) or must all the inputs be sampled at the same time?

Do you need RMS measurements only, or must you detect variations in the cycle? Again, this helps determine the speed of the acquisition, and the dynamic range it requires.

There are premade ADC modules you can use (and probably should as it means you won't have to build them yourself unless you need ultra fast sampling). There are tradeoffs in terms of accuracy, linearity, acquisition speed and input signal requirements.

LOL yea right. in house resources avalablity of equipment., Nextweek I can check whats avalable, for now, I'm simply attempting to get a solid foundation for a POA.

channel more than once every several seconds, go buy a data logger like a Fluke Hydra. This is essentially a good auto-ranging multimeter with a DP21T switch on the input leads. Some models can only output the data immediately over a serial port, while some can store data in an internal memory. The potential problem here is that it costs US$2,000-$3,000 for 20 channels, and you need to do that seven and a half times. You might be able to buy one data logger and multiplex the inputs to it with external silicon, switches, or relays. You need a 40P8T contact arrangement...

Outstanding suggestion

I agree - but see my caveats about acquisition speed above.

to select smaller boards with 10 or 20 inputs and let each board log to local memory, then download all the boards at the end of the flight. This may also tend to reduce the number of wires strung around the aircraft, if you can locate the boards near the measurement points. You need some kind of sync between the boards... they all have to start their clocks at the same time, or get individually synchronized to GPS or WWV, or you need to string a wire between them. You may also have to be careful where you put the boards physically... if they make the aircraft radios go screwy the pilot will not be happy with you.

I do have GPS signals available

If you can separate various measurements (i.e. a snapshot of everything is not required to be synchronised) this is a good idea. If everything has to be synchronised to an event, then you'll need some method of communicating that between measurement nodes. If not, then GPS time is a good solution.

This may be obvious, but it's probably a bad idea for there to be just one person trying to fly the plane and operate the data logging at the same time. If one-man operation is required, the interface to the data logging has to be very simple, or even something that can be started before takeoff by someone else and stopped after landing.

I have a crew on board, flight crew, trechnicians, engineers (me) 707 A/C

do something like this probably work for an aircraft manufacturer and in that case I would think they'd just buy off-the-shelf stuff. But hey, maybe you're building an experimental jet in your garage. :)

I wish LOL no.... DOD trying to avoid using $$$$$ contractors, We have the resources, but money is limited and this is my 1st project of this magnitude that I'm heading up.

state your requirements more clearly - you may want to cross-post or post to sci.electronics.design for more good input.

thanks Matt

The basic questions I would have before suggesting a specific solution are noted above, summarised here:

  1. Do all the inputs have to have synchronised samping?
  2. Can a window be established for samples to enable sample multiplexing?
  3. Should you oversample to overcome errors?
  4. How fast must the samples be when an 'event' occurs?
  5. You may need to buffer the source transducers to minimise common mode noise.
  6. What sampling error is acceptable and relative to what?

Not noted: Are any of the sampled sources outside of the cabin? If so, you'll have to be careful about temperature depencies on the transducer / amp / connectors.

Cheers

PeteS

Reply to
PeteS
Loading thread data ...

JB2 wrote:

>>I have to log 150 discrete inputs, some AC and others DC, voltages and >>currents. I plan on using simple inductive pickups and voltage probe >>points. > >How often do you need to log each input?

Still to be determined, but preliminary data acquisition will need to be during major changes in flight profiles, such that sample rates may only be required when user selects the need and not a continuous sampling.

Do some inputs need to be logged more often than others?

No, in fact would rather have all samples at the same time for comparative analysis.

What kind of voltage and current ranges do you need?

Gen output is 40kVA three total & One 1kVA

115v 1 phase 400Hz 650 amps 115v 3phase 400 Hz 220v 2Phase 400Hz 28 vDC 200 amps max. There are two TRs tied together in parallel, EA max 100 amps. Loss of various equipment will be executed and data sampled for future capabilities and emergency procedures. The main concern is the capability of the TRs to handle various loading configurations but data for all sources is required.

Do you need analog measurements for everything, or is

>digital OK for some of the inputs?

Data will be used for reporting purposes, future calculations and modeling. I will probably end up building a more accurate model then currently exists (current model is solely analytical, no hard data available) All the sources are analog, but how those samples are obtained, I don't think will make a difference. I thought simple inductive pickups that feed analog to dig conv for recording.

How accurate does each analog reading need to be?

Big question! I would want at most _+2%. I suspect any more deviation may make modeling too inaccurate.

>>Any suggestions? > >The 150 channel requirement is a biggie. If you don't need to log each >input that often, it's not as big of a deal, but if you need high data >rates, it may get a little expensive. > >>I know I'll need a DAC, just not sure which would work best. > >Budget?

LOL yea right. in house resources avalablity of equipment., Next week I can check whats avalable, for now, I'm simply attempting to get a solid foundation for a POA.

If you have plenty of somebody else's money, and you don't need >to log each channel more than once every several seconds, go buy a data >logger like a Fluke Hydra. This is essentially a good auto-ranging >multimeter with a DP21T switch on the input leads. Some models can only >output the data immediately over a serial port, while some can store data >in an internal memory. The potential problem here is that it costs >US$2,000-$3,000 for 20 channels, and you need to do that seven and a >half times. You might be able to buy one data logger and multiplex the >inputs to it with external silicon, switches, or relays. You need a >40P8T contact arrangement...

Outstanding suggestion

>Instead of trying to log everything at once on a laptop, it might work >better to select smaller boards with 10 or 20 inputs and let each board >log to local memory, then download all the boards at the end of the >flight. This may also tend to reduce the number of wires strung around >the aircraft, if you can locate the boards near the measurement points. >You need some kind of sync between the boards... they all have to start >their clocks at the same time, or get individually synchronized to GPS >or WWV, or you need to string a wire between them. You may also have to >be careful where you put the boards physically... if they make the >aircraft radios go screwy the pilot will not be happy with you.

I do have GPS signals available

>This may be obvious, but it's probably a bad idea for there to be just >one person trying to fly the plane and operate the data logging at the >same time. If one-man operation is required, the interface to the data >logging has to be very simple, or even something that can be started >before takeoff by someone else and stopped after landing.

I have a crew on board, flight crew, trechnicians, engineers (me) 707 A/C

I'm somewhat curious as to what you're doing... most of the people that >want to do something like this probably work for an aircraft >manufacturer and in that case I would think they'd just buy >off-the-shelf stuff. But hey, maybe you're building an experimental >jet in your garage. :)

I wish LOL no.... DOD trying to avoid using $$$$$ contractors, We have the resources, but money is limited and this is my 1st project of this magnitude that I'm heading up.

>Once you can answer most of the questions above - in other words, when >you can state your requirements more clearly - you may want to >cross-post or post to sci.electronics.design for more good input. > >Matt Roberds

thanks Matt

Reply to
JB2

My customers (biggish aerospace folks) tend to use VME systems for this sort of thing. Your choices are

  1. Log the raw data (waveforms) with ADC boards. This is simple but would produce huge heaps of data that would have to be reduced into things like RMS voltages, currents, RPMs, etc. This may require signal conditioning ahead of the ADC channels. At high channel counts, acquiring raw data can run out of system bandwidth.
  2. Use signal conditioner boards that measure RPM, voltage, current, power, whatever, and log their output. More expensive per channel, but much less data and data reduction, and little or no outboard signal conditioning.

Both require an infrastructure (VME crate, controller or embedded CPU) and acquisition boards. Figure $4k or so for the baseline stuff, plus $100-$500 per channel, roughly, depending on how you do it.

My company makes VME boards that acquire AC power, RPMs, load cells, thermocouples, stuff like that. In something like jet engine testing, it's common for hundreds of channels to be acquired at hit rates down to a few milliseconds. See VITA.COM for most of what's available in VME.

John

Reply to
John Larkin

I did a similar data acquisition system for the 757 about 3 years ago. If you email directly with a good email return address then I will gladly share my experiences and the approach we used.

Don

Reply to
Don Baker

RGR that Pete, thanks!!!! I will be working on answering theses questions next week. When I come up with a more comprehensive battle plan, I'll post some further defined criteria, but what's been brought up thus far give me some good starting points and things to think about. (nothing outside the cabin, but I will be doing an unpressurized test to conclude the systems do not fail at altitude in the event of uncommanded depressurization)

JB2 (Jeff)

currents. I plan on using simple inductive pickups and voltage probe points.

that often, it's not as big of a deal, but if you need high data rates, it may get a little expensive.

channel more than once every several seconds, go buy a data logger like a Fluke Hydra. This is essentially a good auto-ranging multimeter with a DP21T switch on the input leads. Some models can only

to select smaller boards with 10 or 20 inputs and let each board log to local memory, then download all the boards at the end of the flight. This may also tend to reduce the number of wires strung around the aircraft, if you can locate the boards near the measurement points.

person trying to fly the plane and operate the data logging at the same time. If one-man operation is required, the interface to the data logging has to be very simple, or even something that can be started before takeoff by someone else and stopped after landing.

to do something like this probably work for an aircraft manufacturer and in that case I would think they'd just buy off-the-shelf stuff. But hey, maybe you're building an experimental jet in your garage. :)

state your requirements more clearly - you may want to cross-post or post to sci.electronics.design for more good input.

Reply to
JB2

AC voltage/current/power acquisition is shockingly neglected. When I went to engineering school last century, the freshmen took classes together but later on the class split up into electronics and power factions, and we barely socialized after that. The result is that 60 Hz is the most neglected frequency in electronics.

Here's one of our AC acquisition modules...

formatting link

and we're planning a couple more, hence my "Hilbert" post. Several outfits already use this one for analysis of aircraft power systems.

John

Reply to
John Larkin

thanks John, I'm simply doing an electrical load analysis of the aircraft. All the sources and how they handle the various loads. ( I know, sounds easy) that's probably why I was given the project and no one else has touched it.

Reply to
JB2

PF = TruePower / (RMSamps * RMSvolts)

This loses the leading/lagging angle info, which is one reason to do a next-generation product, all dsp-ish and stuff.

John

Reply to
John Larkin

For voltage, we have an external potential acquisition box that has resistor strings and transzorbs and stuff. For current, we use a "current sensor" (which is a CT with a built-in burden resistor) or a regular 5-amp CT with an external 0.05 ohm load resistor. Either way, no serious power gets to the VME card.

John

Reply to
John Larkin

I don't know of any competitor for this module - do you? - much less one that publishes his algorithms. I just sat down and wrote the code. I've been doing AC power meters for almost 20 years, and things have just sort of evolved. I did a few thousand end-use survey meters (back when that sort of thing was popular+funded) and over 1700 apartment submeters for Battery Park City, right across the street from the ex-World Trade Center buildings.

Well, you did ask.

John

Reply to
John Larkin
[...]

Just out of curiosity, how are you measuring power factor?

Mike Monett

Reply to
Mike Monett

Well, this is a discussion group.

John

Reply to
John Larkin

Yeah, Ethernet - especially PoE - is the ultimate expansion bus. I can't see why anybody would want to use IEEE-488 or RS-232 for instrumentation any more.

John

Reply to
John Larkin

And just exactly what do you have in the way of providing for protection from catastrophic sensor failure on those HV circuits, dopey?

Reply to
Fred Bloggs

And from which competitor did you illegally pirate the algorithms?

Reply to
Fred Bloggs

Neat cheat! Thanks.

Mike Monett

Reply to
Mike Monett

All those applications have been converted to smart networked nodes-

Reply to
Fred Bloggs

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.