James Newton wrote:
> I was asked to post this for a buddy, but it is serious money,

It's good to see you understand this is serious money.  Anyone that says
they'll do this for a few $K doesn't understand what they're getting into.

However, I'd still want to know how this is funded.  Is this a new project
from a existing company, or someone trying to get their own idea going and
funding it out of pocket?  While you may think the money should be the same,
this distinction makes a big difference in project management and other
expectations.

> Basically, he wants to find an ready to roll CAN bus project with
> EVERYTHING needed to read a few sensors in a car, do some processing on
> those reading with some microcontroller (PIC? MSP430? AVR? Whatever)
> and then post out messages to some device on the bus that will do
> something with the information.

On what bus?  Talk back on the CAN bus or some other private data connection
to elsewhere?  In other words, is this strictly a CAN bus device, or a
bridge between the CAN bus and some other digital system?

> Yeah... not a great spec, but the point
> is to just find a development system that already has the standard
> stuff in it for working with things you find in a car so we don't have
> to burn all the cycles required to come up to speed on it.

Does this include the mechanicals?  The mechanicals aren't trivial in a
harsh environment like a car.  "Development system" sounds more like a
working board is all you need.  It will be used to develop the real system,
which will eventually include the mechanicals once the system is shown to
work with the development board.  Is this correct?

> PROJECT #1:  Automotive Sensor System  (HOT!--RFQ response due this
> coming Monday, Product by mid-March)

That's in 3 days.  Not a lot of time for several rounds of back and forth
questions and clarification, and a few passes over the spec until everyone
agrees on exactly what they are buying and delivering.  You're asking for a
fixed price quote (at least that's what it seems), so anyone that knows what
they're doing is going to insist on a clear spec so that they know exactly
what they're promising to do for the fixed price, and just as importantly,
what they're not promising to do.  By the same token, you need to know
exactly what you're getting and not getting for your money.

The most critical part of this project is the spec.  Once you have a quality
spec, most reasonably competent engineers can implement it.  But a vague or
incomplete spec will be a endless source of problem for the duration of the
project.  The spec is also your contract that tells you exactly what you're
going to get for your money.  You don't want to skimp on this part in the
interest of the schedule.  Doing so will cost a lot more schedule slippage
in the end.  If the schedule is already so tight that development can't
possibly be finished in time if the spec is done right, then the project is
already guaranteed to slip.  Understand that now and don't make is worse by
trying to economize on the spec.

> Basic requirements are for an automotive environment (with ALL that
> implies for temperature, shock, vibration, MTBF, etc.!) sensor/signal
> conditioner/CAN transceiver module.  We already have the sensor suite
> and signal conditioners as COTS products which will require minimal
> modification.

So conditioned signals will enter the unit, or your COTS conditioners are
expected to be integrated into the unit?

> We are looking for a recommended chip set and
> benchmark design that provides the ADC and CAN interface and
> processor.  The sensor suite will provide several (typically 2, but
> potentially up to 8) analog signals which will need to be digitized,
> and processed through a 2-3 element polynomial equation to generate a
> temperature compensated and linearized output value for each
> sensor.

What is the maximum sample rate per channel?  At what rate must new fully
compensated measurement values be available per channel?

> It may also be possible to move the processing to the
> control module and merely report measured values if there are
> significant savings in cost or space.

What control module?  How does this control module relate to the unit you
are asking to have designed?  You need to clarify the overall architecture.

> Overall accuracy can be met
> with a 12-bit ADC, although higher resolution is MUCH preferred.

I assume you've thought about this, but this is rather surprising.  Without
knowing the people at the other end of this request, my first knee jerk
reaction is that someone doesn't really understand their requirements.  I'd
want to hear more about what these sensors are to do a sanity check on the
accuracy and resolution requirements, and maybe come up with other ways of
addressing the real requirements.  This and the speed requirement together
will have a major influence on the overall architecture and choice of
processor(s), and therefore cost of development.

> Power availability is not an issue, although there is an overall
> limit to about 2-5 watts, and a very clean power bus is
> anticipated.

You mean you expect the unit to generate a clean power bus internally, or
that you will provide a clean power bus.  Normally I would expect rather
dirty "12V" power in for automotive environments.  I would expect to deal
with this in the unit, but then I don't understand what you mean by a "very
clean power bus is anticipated".  What am I missing?

> HOWEVER, there is a requirement for operation in a
> Class-I, Div-1 or Div-2 explosive environment.

So is this going anywhere worse than under the hood of a car, or are you
just using these specs to ensure under-hood operation will not be a problem?
And who has the liability?  That will make a VERY big difference to the
price of the quote and whether a quote will even be offered in many cases.

> i.e. intrinsic safety
> is mandatory, which implies low voltage and low power requirements,
> along with high immunity to EMI, ESD, and gross over-voltage
> conditions.

This is more what I expect in a car.  Now I'm really confused by the "very
clean power bus anticipated" statement.

> Energy storage devices such as inductors and capacitors
> must be minimized almost to the point of non-existence compared to
> normal consumer applications, which can create issues for
> bypassing  and filtering electronic noise ;-).

I can understand certain types of capacitors, but what do you have against
small inductors?  These are very reliable and safe, since they are basically
rolled up wire and a chunk of reasonably inert magnetic material.  A well
designed switching power supply on the input seems to me the safest choice.
The reduced need for cooling alone will simplify and safefy (;-)) things
compared to alternatives.

> Full galvanic isolation of the sensors and processor from the CAN bus
> may be an additional requirement imposed by the sensors.

You need to decide the "may" part.  As I'm sure you understand, that makes
quite a difference in the design.

> There are
> several good digital isolation solutions available, and we do not
> anticipate problems here.

Not so fast.  12 bit accuracy accross galvanic isolation means shipping
power to the isolated side, converting there, and shipping digital values
back.  While this is all doable, it does take power, parts, board space, and
$$.

> Although this requirement is being driven by a specific customer, we
> want to end up with a "generic" system that can be easily adapted to
> different sensor suites and applications in the future.

That makes sense given the overall "development board" flavor.  You think
you want is a platform for testing concepts and proving viability and as a
reference design for resulting products.  This unit is not intended to be
the product?

To get to a real spec there will need to be some serious interactive
discussion with the people that truly understand the requirements and are in
a position to make tradeoffs when choices are presented.  Often these people
know that they want, but don't realize all the ways the results could be
achieved and how seemingly small changes in the requirements can make big
differences to the implementation.  A interactive discussion between those
that know what they want and a engineer that knows the implementation
tradeoffs is necessary for a good result for everyone.  You need to provide
a phone number and a good time to call.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist