Matronics Email Lists :: View topic - motorcycle coolant sensor question

Matronics Email Lists
Web Forum Interface to the Matronics Email Lists

Get Email Distribution Too! FAQ Search Memberlist Usergroups Register

Profile Log in to check your private messages Log in

motorcycle coolant sensor question

Matronics Email Lists Forum Index -> AeroElectric-List

View previous topic :: View next topic

Author Message

saolesen(at)sirentel.net
Guest

Posted: Sat Mar 31, 2012 10:30 am Post subject: motorcycle coolant sensor question

Can a single coolant temperature sensor be used to send temp data to two different units, an engine control unit and display unit?  My son is building a self designed racing bike and I have been placed in charge the electrical system.



Sheldon Olesen

N475PV  RV-10

Sent from my iPad

- The Matronics AeroElectric-List Email Forum -

Use the List Feature Navigator to browse the many List utilities available such as the Email Subscriptions page, Archive Search & Download, 7-Day Browse, Chat, FAQ, Photoshare, and much more:

http://www.matronics.com/Navigator?AeroElectric-List

nuckolls.bob(at)aeroelect
Guest

Posted: Sat Mar 31, 2012 11:10 am Post subject: motorcycle coolant sensor question

At 01:25 PM 3/31/2012, you wrote:

 	  Quote: 	
		  

<saolesen(at)sirentel.net>



Can a single coolant temperature sensor be used to send temp data to 

two different units, an engine control unit and display unit?  My 

son is building a self designed racing bike and I have been placed 

in charge the electrical system.


	


   It depends. To find the answer you need to know

   what the characteristics are for the sensor -AND-

   the circuitry that watches it. Legacy temperature

   sensors are thermistors . . . a resistor that changes

   value in a predictable and repeatable way depending

   on surrounding temperature. A newer device is an

   integrated circuit which generally offers more user

   friendly, linear signals.



   How are these two temperature inputs to be used?

   Is the 'sensor' already part of the suite of

   components for one of the data users . . . and

   you have a second user that wants to eavesdrop

   on the data?



   Sensing temperature in a meaningful way is really

   easy. It might be better that each system have its

   own sensor tailored to its technology.



   Have you crafted a power/data distribution diagram?

   Suggest you start with emulating one of the z-figures

   and do a pen-to-paper actualization of your design

   goals. Then do a similar drawing that speaks to control

   and signal lines while identifying the systems and

   parts KNOWN to be compatible with their function.



   At Beech this was called a system interface document.

   It was a drawing of wire bundles PLUS a table of inputs

   and outputs from each device along with gains, offsets,

   and scale factors for signals expected and offered.



   If you had such a set of documents to share, I and

   others here on the List can be more specific in our

   advice. Bur right now, there's not enough data in

   your question to give a reliable answer.

   Bob . . .

- The Matronics AeroElectric-List Email Forum -

Use the List Feature Navigator to browse the many List utilities available such as the Email Subscriptions page, Archive Search & Download, 7-Day Browse, Chat, FAQ, Photoshare, and much more:

http://www.matronics.com/Navigator?AeroElectric-List

raymondj(at)frontiernet.n
Guest

Posted: Sat Mar 31, 2012 12:00 pm Post subject: motorcycle coolant sensor question

Greetings Bob,

Could you point to a simple example of the document you recommend?  To 

provide some idea how others have done it.

do not archive

Thanks,

Raymond Julian

Kettle River, MN

"And you know that I could have me a million more friends,

and all I'd have to lose is my point of view." - John Prine

On 03/31/2012 02:05 PM, Robert L. Nuckolls, III wrote:

 	  Quote: 	

 <nuckolls.bob(at)aeroelectric.com>

 At 01:25 PM 3/31/2012, you wrote:

> 

> <saolesen(at)sirentel.net>

snip

 	  Quote: 	

 At Beech this was called a system interface document.

 It was a drawing of wire bundles PLUS a table of inputs

 and outputs from each device along with gains, offsets,

 and scale factors for signals expected and offered.

snip

- The Matronics AeroElectric-List Email Forum -

Use the List Feature Navigator to browse the many List utilities available such as the Email Subscriptions page, Archive Search & Download, 7-Day Browse, Chat, FAQ, Photoshare, and much more:

http://www.matronics.com/Navigator?AeroElectric-List

nuckolls.bob(at)aeroelect
Guest

Posted: Sat Mar 31, 2012 5:31 pm Post subject: motorcycle coolant sensor question

At 02:57 PM 3/31/2012, you wrote:

 	  Quote: 	
		  



Greetings Bob,



Could you point to a simple example of the document you 

recommend?  To provide some idea how others have done it.



do not archive


	


   Sure, check the Z-figures . . . in particular one

   that uses a PM alternator. Z-16 is probably good



http://tinyurl.com/7vp9g4e



   You wont need an e-bus but if you have electronic

   ignition, then you'll need to accommodate that.



   The system interface document is simply a schematic

   of all the black boxes, sensors and how they connect

   to each other. But in particular, you need to KNOW

   the nature of the sensor data and whether or not

   two different client systems can listen to the

   same sensor. That will take some detective work

   on your part.



   Do you have installation diagrams for the proposed

   clients?

   Bob . . .

- The Matronics AeroElectric-List Email Forum -

Use the List Feature Navigator to browse the many List utilities available such as the Email Subscriptions page, Archive Search & Download, 7-Day Browse, Chat, FAQ, Photoshare, and much more:

http://www.matronics.com/Navigator?AeroElectric-List

raymondj(at)frontiernet.n
Guest

Posted: Sat Mar 31, 2012 7:13 pm Post subject: motorcycle coolant sensor question

A little mix up perhaps.  I was just asking for an example of an

interface document for my own information.  Sometimes organizing the

info. is half the battle.  I like to see how others have solved a 

problem. I guess I was expecting something with:"a table of inputs and 

outputs from each device along with gains, offsets,

and scale factors for signals expected and offered."

Sorry about the mix up.

do not archive

Raymond Julian

Kettle River, MN

"And you know that I could have me a million more friends,

and all I'd have to lose is my point of view." - John Prine

On 03/31/2012 08:29 PM, Robert L. Nuckolls, III wrote:

 	  Quote: 	

 <nuckolls.bob(at)aeroelectric.com>

 At 02:57 PM 3/31/2012, you wrote:

> 

> <raymondj(at)frontiernet.net>

>

> Greetings Bob,

>

> Could you point to a simple example of the document you recommend?

> To provide some idea how others have done it.

>

> do not archive

 Sure, check the Z-figures . . . in particular one that uses a PM

 alternator. Z-16 is probably good

 http://tinyurl.com/7vp9g4e

 You wont need an e-bus but if you have electronic ignition, then

 you'll need to accommodate that.

 The system interface document is simply a schematic of all the black

 boxes, sensors and how they connect to each other. But in particular,

 you need to KNOW the nature of the sensor data and whether or not two

 different client systems can listen to the same sensor. That will

 take some detective work on your part.

 Do you have installation diagrams for the proposed clients?

 Bob . . .

 http://www.matronics.com/contribution

- The Matronics AeroElectric-List Email Forum -

Use the List Feature Navigator to browse the many List utilities available such as the Email Subscriptions page, Archive Search & Download, 7-Day Browse, Chat, FAQ, Photoshare, and much more:

http://www.matronics.com/Navigator?AeroElectric-List

nuckolls.bob(at)aeroelect
Guest

Posted: Sun Apr 01, 2012 10:10 am Post subject: motorcycle coolant sensor question

At 10:11 PM 3/31/2012, you wrote:

 	  Quote: 	
		  



A little mix up perhaps.  I was just asking for an example of an

interface document for my own information.  Sometimes organizing the

info. is half the battle.  I like to see how others have solved a 

problem. I guess I was expecting something with:"a table of inputs 

and outputs from each device along with gains, offsets,

and scale factors for signals expected and offered."


	




   No mixup. I understood what you were requesting.

   Problem is that the few dozens of documents I've

   had any contact with or input to are Hawker-Beechcraft

   documents and not part of my library for sharing.



   I understand what you're experiencing when trying to visualize

   the expected work-product as described verbally. It's

   especially bad when the document description is part

   of a "policies and procedures manual" crafted by

   English majors and publications 'experts'. At HBD

   we had rows of P&P Manuals with requirements written

   so badly as to defy understanding.



   The first time I was confronted with the ISO9000

   approved policy and procedure for writing a report,

   I was pretty much adrift for direction. I'd been

   writing technical documents to Mil-Std-490 for decades.

   They seemed to have satisfied the needs of thousands

   of readers of technical documents since WWII. I could

   outline and draft one in my sleep.



   Now comes the 'better' way with a description that

   might just as well be written in Swahili. Grammatically

   correct, perfectly formatted, picturesque fonts . . . but

   for the most part vacuous. The problem with such instructions

   is two-fold. The understanding  by which a writer produces

   produces a document probably differs from understanding

   possessed by the readers, not the least of which is some individual

   who has to 'approve' the document . . . not understand

   it but approve it.



   I abandoned the rows of books on the shelf. When tasked

   with production of some document described therein, I

   asked, "please provide me with a published document

   of this type that meets with your approval." Only then

   did I have half a chance of delivering to the customer's

   desires. It's a certainty that the P&P manual bordered

   on useless.



   Let's start with your proposed wiring diagrams. You're

   right . . . the planning is the hard part. When I did

   my first brain-child to TC aviation in '75 I found

   that making it work was 20% of the effort. Packaging it

   for environmental concerns was 40%, documenting for

   design review, qualification and production was 40%.

   Nowadays, making it work is 10%, packaging is 30% and

   generating the required piles of paper is 70% . . . with

   the risk that no two people agree on what the piles

   should look like. This guarantees cost overruns when

   the paper effort going into paper piles busts the

   statement of work.



   Let's keep your paperwork at no more than 40%. Further,

   doing it right will make the rest fun instead of vexing.



   Bob . . .

- The Matronics AeroElectric-List Email Forum -

Use the List Feature Navigator to browse the many List utilities available such as the Email Subscriptions page, Archive Search & Download, 7-Day Browse, Chat, FAQ, Photoshare, and much more:

http://www.matronics.com/Navigator?AeroElectric-List

Display posts from previous:

	Matronics Email Lists Forum Index -> AeroElectric-List	All times are GMT - 8 Hours
Page 1 of 1

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum