Today's Message Index:
----------------------
1. 04:40 AM - Re: Re: Engine Sensors to Arduino... (Robert L. Nuckolls, III)
2. 07:53 AM - Re: Re: Engine Sensors to Arduino... (Robert L. Nuckolls, III)
3. 01:37 PM - Re: Engine Sensors to Arduino... (andymeyer)
4. 05:20 PM - Re: Re: Engine Sensors to Arduino... (Charlie England)
Message 1
INDEX | Back to Main INDEX |
NEXT | Skip to NEXT Message |
LIST | Reply to LIST Regarding this Message |
SENDER | Reply to SENDER Regarding this Message |
|
Subject: | Re: Engine Sensors to Arduino... |
At 02:06 PM 12/23/2017, you wrote:
>
>
>alec(at)alecmyers.com wrote:
> > Why not do your 2Hz filtering in software?
> > Unless you need a quite specific frequency response you can do a
> simple but effective exponential filter, with this in your main loop:
> >
> > filteredValue = e * sample + (1-e) * filteredValue
> >
> > choose appropriate value of e to achieve the smoothing you want
> according to how often the loop cycles.
> >
>
>My only thought was that the hardware filtering will clean up noise
>that will get into the software filtering. It also slows down the
>requirements for data collection for the filter... I can sample the
>Oil press a couple of times a second and have good data. Or, am I
>over thinking this?
What is design goal for use of the data? Trend
monitoring? Failure analysis? Is there any
data being collected with greater quality than
your physiological perception latency?
In the targets world, the only high speed data
gathering and interpretation was for flight controls;
generally sampled at 100Hz and rolled off at 10Hz
in signal conditioning. All other data, engine
conditions, airspeed, altitude, temperatures, etc
were gathered and processed at 1Hz or slower.
How are you going to treat the data gathered? Writing
to Flash? How large a flash drive are you planning to
incorporate. In other words, how many hours of
flight data.
Then supposing you have, say 100 hours
of data on an SD card . . . by what process will you
interpret, display and analyze the data?
Dedicated application, EXCEL, etc. etc?
The manner in which the data is to be used
has a lot to say about the quality of the
gathering techniques.
Bob . . .
Message 2
INDEX | Back to Main INDEX |
PREVIOUS | Skip to PREVIOUS Message |
NEXT | Skip to NEXT Message |
LIST | Reply to LIST Regarding this Message |
SENDER | Reply to SENDER Regarding this Message |
|
Subject: | Re: Engine Sensors to Arduino... |
>
>My only thought was that the hardware filtering will clean up noise
>that will get into the software filtering. It also slows down the
>requirements for data collection for the filter... I can sample the
>Oil press a couple of times a second and have good data. Or, am I
>over thinking this?
I have uploaded a preliminary data package on
an Arduino based DAS that Paul and I have been
fiddling with for about a year. I'm about to
mail brass boarding hardware to Paul to debug
and marry to his software.
https://goo.gl/pGpX4i
Use any of this as it suits your purposes.
Since this was intended to be an investigative
tool, we didn't get hard-over on filter roll
offs. Those are component ratios that are easily
adapted as needs present.
We attempted to craft a 6 channel analog,
2 channel discrete DAS that could be user
configured for a range of sample rates . . .
as determined by software and configuration
jumpers. We included a gain channel with
cold-junction compensation for thermocouples,
a gain channel with high common mode capabilities
for measuring RTD, strain gages, shunts in bus
feeders, etc. A hall effect current sensor
that can be easily configured for a range
of current measurements from plus/minus 1 amp
to plus-minus hundreds of amps. The analog
inputs can be configured to directly excite
my all time favorite temperature sensor
https://goo.gl/12tB3w
Some analog inputs are easily switched between
5 and 25v full scale.
The goal is to be easily incorporated inti
bench testing, flight testing, under the hood,
etc. situations. It will run from separate
battery supply . . . or ship's bus.
It features remote control of the run/stop command
so that with a single conductor to the cockpit,
the DAS under the cowl can be started and stopped
at will thus chunking the data gathering task
so that you don't have a SD card full of insignificant
data interwoven with data of interest.
Are you deeply committed to the 3.3v Vdd product?
There are MANY more remote sensing products that work
well in the 5v world as opposed to the 3.3 volt
world. Unless you're striving for very low power ops
on self contained batteries, I suggest you re-visit
the 5.0 vs. 3.3 decision.
Bob . . .
Message 3
INDEX | Back to Main INDEX |
PREVIOUS | Skip to PREVIOUS Message |
NEXT | Skip to NEXT Message |
LIST | Reply to LIST Regarding this Message |
SENDER | Reply to SENDER Regarding this Message |
|
Subject: | Re: Engine Sensors to Arduino... |
The original intent was basic data collection for looking at performance, cooling,
drag reduction, etc... It's evolved a bit to be a full engine monitoring system
- with display. I'm seeing how easy a 2.8" (or two) displays are easy and
fast to drive.
I've had a pretty relentless (as relentless as a father of 3 can be) pursuit of
drag reduction... I'm close to 18 knots improvement on this airplane, and since
I started recording low resolution data, I can show about 13 knots of provable
gain. I've got a performance model that gets me within 1.2 knots at most normal
conditions so any change can be found utilizing some 6 sigma manipulation.
Goal is to get some of this computing ability into the engine monitor as well
as greatly improve my data collection. Altitude hold AP is going in soon, etc...
First goal is displaying the data as an engine monitor, and second will be collecting
for model improvement and tracking drag reduction. A long goal is to be
able to develop a system that can effectively back out a pilots performance handbook
based on a few flight profiles flown during their first 40 hours on a
new experimental.
I'm looking for relatively clean data for presentment on the display initially.
This first pass will be a few boards soldered up and mounted - functional for
a few months while I work on the cockpit display, etc... Then, PCBA's built (and
shared if there is other interest in this system...) I'll be writing more
as I progress. My mechanical and aerodynamics prowess is much better than my electronics...
But I'm learning.
Read this topic online here:
http://forums.matronics.com/viewtopic.php?p=476748#476748
Message 4
INDEX | Back to Main INDEX |
PREVIOUS | Skip to PREVIOUS Message |
NEXT | Skip to NEXT Message |
LIST | Reply to LIST Regarding this Message |
SENDER | Reply to SENDER Regarding this Message |
|
Subject: | Re: Engine Sensors to Arduino... |
On 12/24/2017 9:52 AM, Robert L. Nuckolls, III wrote:
>>
>> My only thought was that the hardware filtering will clean up noise
>> that will get into the software filtering. It also slows down the
>> requirements for data collection for the filter... I can sample the
>> Oil press a couple of times a second and have good data. Or, am I
>> over thinking this?
>
> I have uploaded a preliminary data package on
> an Arduino based DAS that Paul and I have been
> fiddling with for about a year. I'm about to
> mail brass boarding hardware to Paul to debug
> and marry to his software.
>
> https://goo.gl/pGpX4i
>
> Use any of this as it suits your purposes.
> Since this was intended to be an investigative
> tool, we didn't get hard-over on filter roll
> offs. Those are component ratios that are easily
> adapted as needs present.
>
> We attempted to craft a 6 channel analog,
> 2 channel discrete DAS that could be user
> configured for a range of sample rates . . .
> as determined by software and configuration
> jumpers. We included a gain channel with
> cold-junction compensation for thermocouples,
> a gain channel with high common mode capabilities
> for measuring RTD, strain gages, shunts in bus
> feeders, etc. A hall effect current sensor
> that can be easily configured for a range
> of current measurements from plus/minus 1 amp
> to plus-minus hundreds of amps. The analog
> inputs can be configured to directly excite
> my all time favorite temperature sensor
>
> https://goo.gl/12tB3w
>
> Some analog inputs are easily switched between
> 5 and 25v full scale.
>
>
> The goal is to be easily incorporated inti
> bench testing, flight testing, under the hood,
> etc. situations. It will run from separate
> battery supply . . . or ship's bus.
>
> It features remote control of the run/stop command
> so that with a single conductor to the cockpit,
> the DAS under the cowl can be started and stopped
> at will thus chunking the data gathering task
> so that you don't have a SD card full of insignificant
> data interwoven with data of interest.
>
> Are you deeply committed to the 3.3v Vdd product?
> There are MANY more remote sensing products that work
> well in the 5v world as opposed to the 3.3 volt
> world. Unless you're striving for very low power ops
> on self contained batteries, I suggest you re-visit
> the 5.0 vs. 3.3 decision.
>
>
> Bob . . .
>
What's the reason for using a degree-K sensor, instead of a degree-F
sensor (like the LM34)?
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Other Matronics Email List Services
These Email List Services are sponsored solely by Matronics and through the generous Contributions of its members.
-- Please support this service by making your Contribution today! --
|