Author Topic: Automotive data network - your thoughts please.  (Read 2812 times)

0 Members and 1 Guest are viewing this topic.

Offline elcomtelTopic starter

  • Regular Contributor
  • *
  • Posts: 52
  • Country: au
    • ELCOMTEL
Automotive data network - your thoughts please.
« on: October 10, 2013, 12:11:38 pm »
I wanted to thank everyone who contributed to my earlier posting as follows:

Microcontroller newbie needs some advice re. PICs and AVRs.
https://www.eevblog.com/forum/microcontrollers/microcontroller-newbie-needs-some-advice-re-pics-and-avrs/

Building on from this I have decided that a good place to start developing my AVR, PIC, ARM expertise would be to 'enhance' my very average car which is a Holden Commodore 1995 VS Wagon 'Executive' 5-speed manual.

For the benefit of the international audience....this is what I drive.
http://en.wikipedia.org/wiki/Holden_VS_Commodore

My car is the 'budget version'. No airbags, no power windows, no car alarm, no fancy suspension or brakes. It's the best damn car that I have ever owned. It is so reliable and very good value for money.

Now being a 'tech head' with a ham radio licence (ok...I'm not registered, but I have the certificate, so I can register a call sign any time). There's some nice HF, VHF, UHF gear that own I would like to install, not to mention a swag of other enhancements, such as power windows, a power aerial (sorry Yankees, I know I should say 'antenna', but you'll never force me to say 'soddering'. I refuse to stoop so low. Dyslexia should be treated and not encouraged.) better interior lighting, a GSM signalling alarm system, a GPS module, temp sensors and so on.

With the 'enhancements' comes a lot of 'electronics' infrastructure to control all of this. The idea is to create NODES around places of interest such as a NODE inside the front right door, the left front door, the rear right door, the rear left door, the tail gate (I have a wagon), under the bonnet, behind the dash board and so on.

The idea would be to use an appropriate heavy gauge single power supply that goes to each NODE and an automotive data network that connects all the NODES together.

Now before you get excited and start suggesting that I should use CAN (http://en.wikipedia.org/wiki/Controller_area_network) because CAN is used by the automotive  industry in today's modern motor vehicle there is the following to consider.

1. The vehicle already has an existing ECM that looks after the running of the engine. In no way am I interested in interfering with this side of the car. My enhancements will simply monitor what is going on. So I might 'sniff' the 8192 baud ALDL OBD-I interface to monitor what the engine is doing.

2. The CAN standard is a 'full on' synchronous data communication protocol with very close similarities to IEEE-802 (Ethernet). A research of the internet reveals that a relatively significant investment (compared to an ATMEL ATTINY13) in hardware (such as AT90CAN32, AT90CAN64, AT90CAN128) or quite a bit of clever programming (if no CAN H/W support) if we are going to attempt to 'bit bash' a synchronous data communications protocol such as CAN.

My concept is to use an ATMEL ATTINY13 if the NODE (see defn. above) has only one 'parameter' (a parameter is 'is there water in the radiator' or 'is it dark' or 'did my microphone register a BANG' to register at what time someone crashed into my car). As you know there are all these wonderful modules (aimed at the art of Mechatronics) that you can buy on eBay or Aliexpress. I don't want to have a mix of I2C, 1-Wire, SPI, etc signals running around the car, so I am looking to standardise the data communications interface that I use.

While the CAN implementation appears to be impossible with an ATTINY13 it would appear RS485 is quite doable or perhaps RS422 with my own in house protocol. The idea is to use the ATTINY13 as a 'gateway device' that provides a unified standard where there is variance in transducer interfaces.

Therefore I would develop the following gateway devices based around a ATTINY13.

RS485 <------> I2C
RS485 <------> SPI
RS485 <------> 1-Wire
RS485 <------> DIO

As some NODES might be more complex than simple RS485 gateways than I describe above consideration would be given to more capable AVR devices, but using the same RS485 interface.

One RS485 network supports 32 devices, so this will need to be taken into consideration.

This would mean that all I need to do is distribute a 'power rail' (a heavy duty cable) and a simple twisted pair for the RS485 data comms around the car. This would allow for expandability, so that if I later wanted to add a feature such as 'monitor if the petrol cap is open' (sorry Yanks...I mean gas....What logic is there to calling a liquid fuel 'gas'? If it was propane I could understand. I don't get it.), I would simply add a node to the RS485 lines and the power for the NODE device from the distributed power rail.

This idea is to remove the complexity of automotive wiring. To avoid things such as complex wiring looms.

What do you think about my idea of running RS485 in an automotive environment? I know that for automotive applications CAN is the 'bees knees', but because I want to distribute (deploy) lots of various distributed simple inputs and outputs (such as power relays inside the door that control the power windows).

Has anyone ever dabbled with this kind of automotive after market application?

-----------------------------------------------------------------------------------------------------------
On a similar subject....not that I would try and connect the following to the above system.

Does anyone know of any after market airbag crash safety equipment that could be installed into a vehicle that does not have this feature? Granted that there is probably government regulation  in most civilized countries that prohibits the installation of aftermarket airbags.

It is physically so easy to install a steering wheel (acquired from a motor vehicle wrecker) fitted with an airbag into a car that doesn't have one. Building a controller based on a ADXL345 accelerometer (see attached ADXL345 datasheet for details) or similar it should be possible. Given the importance of the controllers responibility and the consequences of a system failure I would envisage that a design having an enormous amount of fault tolerance and system redundancy to avoid 'system failure'.

A very unacceptable (if not fatal) mode of failure would be that of a 'false trigger' caused by hitting a pot hole. My survival instincts tell me to not even attempt something as idiotic as installing an airbag in my car and designing a controller for the airbag, but perhaps someone out there has some experience with and might be able to shine more light.

To my American friends please don't take my jovial banter too seriously. As I was writing this several times it occurred to me that I could write words one way or another. So I added some light humor and there was no intention to offend anyone. If anyone took offense I apologise (damn Yankie spelling checker is trying to force me to spell the word as 'apologize'. ) unreservedly in advance if anyone took any offence to what was written.
http://www.elcomtel.com.au/
There's no place like 127.0.0.1
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: Automotive data network - your thoughts please.
« Reply #1 on: October 10, 2013, 12:35:51 pm »
RS485 with your own protocol seems a very viable option to me. You could make a hub to connect several RS485 busses together. IIRC you could go well beyond 32 devices if the data rate isn't very high and the wiring is not longer than a few meters. Be sure to use shielded twisted pair wiring and assume the 12V bus in a car can have 48V spikes on it.

You shouldn't attempt to mess with airbags. They are explosive devices. AFAIK the accelleration sensor in an airbag module is a steel ball under a spring.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline TheDirty

  • Frequent Contributor
  • **
  • Posts: 440
  • Country: ca
Re: Automotive data network - your thoughts please.
« Reply #2 on: October 10, 2013, 01:15:35 pm »
The little brother to CAN is LIN.  I think most PICs have some LIN support, I seem to remember that.  I had to kludge it when I did LIN about 6 years back.
Mark Higgins
 

Offline kphannan

  • Supporter
  • ****
  • Posts: 11
Re: Automotive data network - your thoughts please.
« Reply #3 on: October 10, 2013, 01:23:07 pm »
Use of CAN may not be as difficult as you think, if you use a CAN controller rather than attempting to Bit-Bang the protocol.  It is designed to be very tolerant of a noisy environment, which automotive systems are.  TI and NXP have some ARM based micros that have the CAN controller built in.  All you need is a transceiver, which you would also need for RS-485.
Take a look at the Open LCB open source project http://openlcb.org  There are links to hardware designs and software.  Most is based on the Arduino.  Open LCB has been adopted as NMRAnet by the standards organization for Model railroads.  There are also some alternate implementations of OpenLCB for TI, NXP ARM processors as well as for AT90xxxxx devices.  Hopefully that could give you a big boost in the right direction.
 

Offline elcomtelTopic starter

  • Regular Contributor
  • *
  • Posts: 52
  • Country: au
    • ELCOMTEL
Re: Automotive data network - your thoughts please.
« Reply #4 on: October 11, 2013, 12:15:43 pm »
Take a look at the Open LCB open source project http://openlcb.org  There are links to hardware designs and software.  Most is based on the Arduino.  Open LCB has been adopted as NMRAnet by the standards organization for Model railroads.

Thanks for the tip on Open LCB. Quite a useful regarding CAN.   :-+
http://www.elcomtel.com.au/
There's no place like 127.0.0.1
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8275
Re: Automotive data network - your thoughts please.
« Reply #5 on: October 11, 2013, 01:14:32 pm »
Dave tore down an airbag controller a short while ago. You should go watch the video and read the associated thread.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf