Re: Request for proposals: Communications physical layer
Alex,
As an analog designer (with some full-custom Analog VLSI ICs to my name) I realized quite some time ago that if something seems easier to implement digitally then trying to do it in an analog fashion, although possible, might not be the best of choices.
Although in general I would agree with your statements (a well put KISS reminder), what seems like a simple analog implementation hides many possible difficulties and implementation costs. Additionally, it limits any future expansion capability.
For example, the scheme you propose would require for resistor measurement:
At the source level:
a) a calibrated and stable enough reference (probably free in a power source)
b) stable enough measurement circuitry (to withstand the protocol lifetime, and provide measurement resolution)
c) a method for measuring the resistor value (e.g., a current measurement or a divider voltage)
d) a method to convert such measurement to a current-limit information
e) a method to discern an erroneous condition (e.g., a short in the communication pins) from a valid one
f) a stable enough oscillator (or voltage to frequency converter) to provide the capacity information
g) a way to multiplex the resistor measurement with the provided information
e) sequencing logic to accomplish power-up and power down conditions
At the sink level:
a) stable enough resistor to withstand protocol lifetime and provide measurement resolution.
b) a precise enough and stable enough 'frequency to capability' conversion so that it would know what it is connected to
c) sequencing logic to determine the response to connection conditions
Although analog schemes are more than capable to do all of this, and asynchronous transistor logic could be used for the sequencing, I'd rather just drop a $0.05 microcontroller and a couple man-month of code development and call it a day. And once you have a microcontroller in there, what would be the point of using an analog scheme that limits any future improvements and expansibility? Using communications, and a very simple data scheme such as the one provided by the method you propose, you could reduce development time to just a man-week.
Edgar
On Mar 2, 2011, at 5:37 PM, aschneiderjr@xxxxxxxxxxxxx wrote:
> Bob,
>
> It has taken me some time on this working group to understand why any communication is
> needed, but I'm coming around. However there are a very limited vocabulary of signals which
> need to be sent. In this respect it is a little like the maritime flag signal code, where "hoists" of
> one to four flags convey most of what mariners need to tell each other. For instance, Q
> indicates "I am free from disease" and B "I am loading explosives" -- in any language. See
> http://en.wikipedia.org/wiki/International_maritime_signal_flags. The recipient is expected to
> have the intelligence to deal appropriately with this information.
>
> Perhaps a second analogy is a dating web site. The first and foremost communication is "I
> am a [male / female] looking for a [male / female]". Details later!
>
> I suggest that the messages needed by our devices are, at the first level, either
>
> -- I am a sink only, or
> -- I can function as a source
>
> At the second level, either can be refined to indicate one of several wattage levels needed or
> available.
>
> Considering only "sinks", the ultimate simplicity of communication would be a resistor
> between the two pins, with the value indicating the desired power range. Clearly polarity
> doesn't matter. Obviously if you tie two devices that are both sinks, neither can power the
> other. The essence of the communication is "no juice".
>
> A "source" could communicate its maximum capability by imposing alternating plus and
> minus voltages on the two communication pins, with the frequency determining its maximum
> output. The source could use the current thru the resistor to determine whether it has
> adequate capability, and the sink could compare the coded capability from the frequency with
> its own requirements and impose limited power operation if requred. I'm not sure if DC (zero
> Hz) should indicate the lowest recognized power level or "broken, do not use".
>
> It isn't obvious what the best approach is if you tie two "sources" of equal capability together,
> until you impose external logic which you want to power the other. Presumably in most case
> the larger of two sources (e.g., a charger plugged into the wall) is powering a smaller one,
> perhaps a battery pack. Perhaps the frequencies used could indicate not only capability but
> whether the source device has a useful sink mode.
>
> Alex Schneider
>
>
> On 2 Mar 2011 at 12:18, Bob Davis wrote:
>
>> Arjan,
>>
>> Thanks!
>>
>> A couple of issues that we will need to address with respect to the
>> LIN
>> protocol.
>>
>> 1. How much more expensive is CAN single wire than LIN? The least
>> expensive
>> NXP devices include CAN.
>> 2. Bus speed. With CAN at 500KHz, a complete message (longest) with
>> ACK is
>> ~250us which allows for two faults and still kill the power before
>> pin
>> separation in 1.87 to 3.2ms. It may be difficult to get the bus
>> power shut
>> down in time if the detection of the communications pins takes more
>> than
>> 1ms. With 40Khz LIN the equivalent detection time would be longer
>> than the
>> required shut down time.
>> 3. 1 byte checksum vs 15bit CAN checksum
>> 4. We will be connecting together devices that each thinks it is a
>> master.
>> Probably need multi-master version of LIN for successful operation.
>> CAN can
>> handle this.
>> 5. I looks like there are up to 4 different message formats from LIN
>> while
>> 32 are available in CAN with arbitration.
>>
>> This is good input.
>>
>> Bob
>>
>> -----Original Message-----
>> From: upamd@xxxxxxxx [mailto:upamd@xxxxxxxx] On Behalf Of arjan
>> strijker
>> Sent: Wednesday, March 02, 2011 2:55 AM
>> To: Edgar Brown
>> Cc: upamd-comms@xxxxxxxx; upamd@xxxxxxxx
>> Subject: RE: Request for proposals: Communications physical layer
>>
>> Dear Edgar, all,
>>
>> Sorry for the late reply, it cost some time for me to find the
>> person within
>> NXP that has experience with the CAN and LIN system (and also
>> FlexRay)
>> I talked to one of my automotive colleagues.
>>
>> Here is his comment:
>>
>> --------------------------------------------------------------------
>> --------
>> --------------------------------------------------------------------
>> --------
>> -----
>>
>> - A main difference between CAN and LIN is the communication speed.
>> CAN is
>> 1Mb/s, LIN is 20kb/s.
>> - FlexRay is introduced for even higher speeds.
>> - LIN can be driven at 40kb/s, (K-line) The low speed is only chosen
>> for low
>> emission.
>> - LIN is single wire. CAN is dual wire. Single wire CAN is possible,
>> but not
>> standardized.
>> - LIN was developed because CAN is too expensive for many
>> applications. High
>> speeds ABS etc need CAN, but for low speed like window regulators
>> LIN is
>> good enough.
>> - The CAN protocol handler much more complicated than the LIN
>> handler.
>> Silicon area is easy a factor 5 times bigger for CAN.
>> - CAN cannot be implemented in low cost (bigger feature size) IC
>> processes.
>> (The silicon would be too big to fit in a package.)
>> - CAN requires strict timing. Every device needs a crystal
>> (expensive). In
>> LIN only the master needs a crystal. The slaves synchronize on the
>> master.
>> - LIN supply voltage is much more flexible (7-18V, but typically
>> 5.5V will
>> work). CAN needs 5V.
>> - LIN communication is simple. A slave can activate the bus and the
>> master
>> will than start the communication.
>> - CAN requires a rather complex arbitration protocol.(critical
>> timing, event
>> driven)
>>
>> Bottom line: if high speed communication is not required: use LIN.
>> CAN would
>> be much too expensive.
>>
>> --------------------------------------------------------------------
>> --------
>> --------------------------------------------------------------------
>> --------
>> ------
>>
>> So I think the thing to ask ourselves is how much communication
>> speed do we
>> need?
>> If, for example, 100 bytes (incl. overhead) need to be send over
>> LIN, this
>> will take 40msec (or 20msec at 40kb/s)
>> CAN will do this in 800usec.
>>
>> Btw: I will be at the APEC next week. I hope I can meet UPAMD
>> people.
>>
>>
>> With regards,
>> $B0$M& (B Arjan Strijker
>>
>> IC architect, Business Line Power & Lighting Solutions (PLS)
>> BU High Performance Mixed Signal (HPMS)
>> NXP Semiconductors
>>
>> Gerstweg 2, Room BZ0.103, 6534AE Nijmegen, The Netherlands
>> Tel: +31 24 353 4661
>> E-mail: arjan.strijker@xxxxxxx, www.nxp.com
>>
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Edgar Brown [mailto:ebrown@xxxxxxxxxxxxxxxxxxxx] On Behalf Of
>> Edgar
>> Brown
>> Sent: Tuesday, February 22, 2011 4:33 AM
>> To: arjan strijker
>> Cc: upamd-comms@xxxxxxxx; upamd@xxxxxxxx
>> Subject: Re: Request for proposals: Communications physical layer
>>
>> Arjan,
>>
>> I don't think we (as a group) have given much thought to LIN.
>> Although LIN
>> seems to be less expensive to implement (as nearly every
>> microcontroller has
>> an UART), it requires/specifies the same physical interfaces as
>> CAN.
>>
>> The basic differences I see:
>> - LIN is strictly master-slave and requires the presence of a bus
>> master in
>> a polling round-robin. CAN is peer-to-peer broadcast only.
>> - LIN is address-based. CAN is event-based.
>> - LIN tops at ~20kb/s. CAN tops at ~1mb/s (similar speed to LIN
>> for
>> low-precision clocking).
>> - LIN uses 8-bit checksum for error detection. CAN uses 15-bit CRC
>> and ACK
>> frames for error detection.
>> - LIN requires code implementation to handle the interface (an UART
>> is only
>> the starting point). CAN peripherals handle most of the protocol
>> heavy
>> lifting.
>>
>> The main differences I see are the master-slave vs. peer-to-peer
>> design, the
>> maximum speed, and the overall safety margin improvement. For this
>> application it seems that CAN provides more flexibility and a
>> simpler
>> overall design.
>>
>> My perception is that LIN may require as much or more code to
>> support than
>> CAN does nowadays, however there should be several support libraries
>> already
>> for both. So the cost differential should be minor to inexistent;
>> but I
>> could be wrong.
>>
>> As the working documents evolve, please feel free to show how/where
>> would
>> LIN simplify the requirements.
>>
>> Edgar
>>
>>
>> On Feb 13, 2011, at 4:32 AM, arjan strijker wrote:
>>
>>> Edgar, all,
>>>
>>> I was going through my upamd mail and the mail below made me
>> rethink the
>> communication options:
>>>
>>> CAN is indeed a good protocol but is LIN assessed enough?
>>> I don't know all the pros and cons, but reading about LIN this
>> seems a
>> cheaper alternative to CAN.
>>> I understand that LIN also has a dc LIN transceiver option. Maybe
>> not
>> useful for 130W but interesting.
>>> LIN is a single master system. Could that be an issue here or
>> would LIN
>> already be good enough,
>>> making the communication not more complicated than really
>> needed?
>>>
>>>
>>> With regards,
>>> $B0$M& (B Arjan Strijker
>>>
>>>
>>> -----Original Message-----
>>> From: upamd@xxxxxxxx [mailto:upamd@xxxxxxxx] On Behalf Of Edgar
>> Brown
>>> Sent: Tuesday, November 30, 2010 10:48 PM
>>> To: upamd-comms@xxxxxxxx
>>> Cc: upamd@xxxxxxxx
>>> Subject: Request for proposals: Communications physical layer
>>>
>>> Request for proposals on physical layer definitions
>>>
>>>
>>> So far, the only viable physical layer definition proposal has
>> been the
>> CAN bus family (ISO 11898, ISO 11992, ISO 17356, EN 50325-xx,
>> etc.)
>>>
>>> Other protocols that have been mentioned are:
>>>
>>> - PMB, which is used for batteries and power systems. It relies on
>> I2C
>> which is not reliable over cables, and requires at least three
>> separate
>> wires (full implementation requires 4).
>>> - LIN, an intermediate between RS232 and CAN. Similar to I2C, but
>> designed
>> for reliability, requires only one wire (supports the same
>> hardware
>> interfaces as CAN), and is a pure master-slave architecture.
>>>
>>> However CAN (in both the single-ended or differential variant)
>> seems
>> preferable in terms of industry penetration and existing
>> infrastructure and
>> overall reliability.
>>>
>>> Please, if you have any additional proposals submit it to the
>> communication subcommittee reflector or to me. The choice of
>> physical
>> interface would enable other aspects of the protocol, so the upper
>> protocol
>> layers will be based on what this allows.
>>>
>>> Also, even within the CAN family, there are several upper-level
>> protocols
>> in use (e.g., OpenCAN). If you, or your team, have any opinion
>> regarding
>> these, please make your opinion heard in the main group and
>> subcommittees.
>>>
>>>
>>> ------
>>> Edgar Brown
>>> Subcommittee chair
>>> UPAMD Communications
########################################################################
To unsubscribe from the UPAMD-COMMS list, click the following link:
http://listserv.ieee.org/cgi-bin/wa?SUBED1=UPAMD-COMMS&A=1