Honda Insight Forum banner

1 - 20 of 23 Posts

·
Registered
Joined
·
836 Posts
Discussion Starter #1
I want to standardize on a bus to connect my Insight projects so I can messages between them. Ideally it should be rugged, cheap and easy to interface to with a simple microcontroller, relatively high speed, and support very low power operation and waking up other devices on the bus when they are needed. Existing (newer) automotive buses would be preferred.

Has anyone put any thought into this and have any ideas? CAN? Linbus? Automotive Ethernet?
 

·
Administrator
Joined
·
12,156 Posts
I think it depends on what you want to connect and where they are in the car, so more info needed....

I suppose CAN is the current automotive standard..
I don't know much/anything about the other two.
You could use bluetooth especially if you have smartphone and an app.

The Insight uses two old standards for module comms on two lines accessible at the OBD socket.

The Standard ISO9141-2 OBDII 10,400 bps 12v KLIne used to talk with the ECM.

The ECM will respond with a limited number of standard OBDII required responses for things like scangauge/ultragauge, or in the special Honda proprietary mode with the full range of parameters for official diagnostic tools or the OBDIIC&C..

The Honda proprietary 9,600 bps 5v HLine is used by the diagnostic tools or OBDIIC&C to speak with the MCM, TCM, ABS, SRS, EPS modules

As the car itself uses old style serial comms, it makes sense to me to speak in it's language as that would make talking to modules or sharing wiring with them easier.
I use the HLine for instance which is not used during normal running by the car to send data from the OBDIIC&C to the IMAC&C slave board inside the MCM. It save adding wires from front to back and made a much neater P&P install.

My packet structure, checksum and signalling is the same as the car, so the modules on the Hline are not confused by my signals.
Simple serial data is easy to implement but of course will be more speed limited and not have lots of fancy features you mention..

The car is horribly electrically noisy especially in the IMA compartment.
The signalling you choose needs to be tough as old boots with data integrity checks.

The car itself uses rugged RS485 signaling for the six inches between the MCM and BCM for the BATTSCI line.
The METSCI line is also RS485 standard as is the ECM to TCM comms IIRC.

Lets us know more on what you are planning then we might have more ideas.
 

·
Premium Member
Southern California
Joined
·
805 Posts
If we were to make an entirely new bus, where projects would be connected point-to-point to each other for communication, I'd say we should definitely use CAN. I've been using it a lot at work and it's a great interface. Noise-resistant, automatic message arbitration, every message has a CRC for data integrity checking. It's very good.

That involves adding wires between projects. In terms of stuff that's already available to us in the car, we just have the K-Line (standard OBD-II comms line) and the H-Line (Honda's special line comms with mainly IMA information).
These are convenient because there are already wires for these two lines running to various points throughout the car. And you can transmit messages on it that the existing devices in the car will ignore. The main problem in my opinion is that this is a single-master network.

Only one device can initiate communications on the bus (in the case of this car, it's always whatever is plugged in to the OBD-II port). If we had multiple Insight projects on this bus, we now need either a way to arbitrate (make sure no two devices send a message at the same time) or designate one device as the "master device", which has to talk to all other devices. This could be a pain if the slave device needs to get data from the master, as the master would first have to poll the slave device to see if it needed data, then fetch the data and finally send it back.

I don't think using the existing K- and H-Lines are the right solution. They're also very slow. It's easy to saturate the bus just reading OBD-II data from the car (Peter would know this, the OBDIIC&C has like 80% bus utilization). Add in traffic from a couple other devices and it'll be incredibly slow overall.

I would say the right solution is probably a new communications bus. What it should be and how it should be routed, I'm not entirely sure.
 

·
Registered
Joined
·
836 Posts
Discussion Starter #4
I will write a longer post later. But I took a look at some automotive protocols. Our best bet is probably CAN bus. I was hoping Automotive Ethernet was further along - two-wire, power over ethernet... but the chipsets seemed more appropriate for embedded processors rather than microcontrollers.

I suppose a five wire bus where one wire is a "wake up!" line might work (2 can, one power, one ground). Any ideas for very low power CAN operation able to wake up a sleeping device on incoming data? (can the MCP2515 support that?)
 

·
Premium Member
Southern California
Joined
·
805 Posts
I'm just curious, why do you want low-power operation? Aren't the things that would use this bus just be powered off the car (either the 12V line or a 5V line in some spots)?
 

·
Registered
Joined
·
836 Posts
Discussion Starter #6
I'm just curious, why do you want low-power operation? Aren't the things that would use this bus just be powered off the car (either the 12V line or a 5V line in some spots)?
Ideally I want to run only two wires to some of my more remote sensors. These sensors are active when the car is off and detect certain events that need to involve processors whose continuous use would drain the battery too much over time (think BLE sensing -> door unlock; motion detection -> message sent over LTE, etc).

It looks like the MCP2515 supports a mode that lets it sleep and be woken up with bus activity. This does mean that every MCP2515 on the bus will wake up. Does the MCP2515 support waking up the host CPU only when a message addressed to it is received?

I have an inverter that connects to its control head with a four wire cable with RJ-45 connectors. It uses CAN for the interface. It does require terminators and probably will need gold plated RJ-45 contacts to be reliable. Perhaps I should buzz this out and propose it for use here. At least then I can use the same bus on both my vehicles and use the inverter's control head for Insight projects and -ooh- connect the two vehicles together!

Automotive Ethernet appears to be on a path that will provide deep sleep functionality AND power AND data AND high speeds over a single twisted pair. The two benefits over CAN would be speed and fewer wires. However, the current focus seems to be on replacing existing high speed buses for harness weight reduction between highly capable devices; the interfaces on existing chipsets appear to be variants of MII and not lightweight like SPI or I2C. I also don't know if a party-line topology is in the works, though Ethernet did start out this way.

Surely the automotive industry has been noodling on this. Maybe the equivalent of an MCP2515 or W5500 (SPI to Ethernet device used for the Arduino Ethernet shield) is just around the corner. It would probably take just a few well-placed inquiries to know for sure.
 

·
Registered
Joined
·
836 Posts
Discussion Starter #7

Attachments

·
Registered
Joined
·
836 Posts
Discussion Starter #8
My CAN bus connectors arrived

These are the four position connectors I will be using for my CAN bus-connected Insight projects, for now. Eventually I will move to RJ-45 connectors. These take healthy size wires through a terminal block that can be unplugged from the board without unscrewing the wires, thus making it easy to remove for service! These connectors come with different numbers of positions for additional input and output lines, but I will keep the CAN bus connector a separate connector. The pinout will be +12V, CAN lo, CAN hi, ground, from left to right looking into the top of the connector with the screw heads facing you.
 

Attachments

·
Registered
Joined
·
496 Posts
I won't claim to be an expert, but I do want to point you to the CIA 303-1 CAN wiring/connector specification document (free registration required, or google can get you some older versions):
https://www.can-cia.org/groups/specifications/

In my experience, DB9 connectors seem to be the most common connector by far. They're present on all the CAN devices I deal with at work. Of course this doesn't apply to OEM controller-to-controller or controller-to-device connections (they just use two pins on whatever connector is applicable). But it seems like D-Sub is used anywhere you might have a human plugging in.

If you do want to go with those phoenix terminal type connectors, there's a standard pinout for those too that you might want to follow.

Either way, there's an optional pin in the spec for supplying external power to devices on the bus. I'm not designing any devices for the Insight, but I think it makes sense to standardize now and have e.g. fused 12V available everywhere on the bus.

edit-
I like the suggestion here of all devices providing two connectors for CAN, since in our case we never know when another device might want to daisy-chain from our connector.
https://uavcan.org/Specification/8._Hardware_design_recommendations/


DE-9 pinout


phoenix terminal pinout

1 CAN_GND Ground / 0 V / V
2 CAN_L CAN_L bus line (dominant low)
3 (CAN_SHLD) Optional CAN shield
4 CAN_H CAN_H bus line (dominant high)
5 (CAN_V+) Optional CAN external positive supply

If you want to stick with 4 pins, I've seen CAN shield used as ground enough times. The spec allows you to leave off pin 1 or 5. I'm not an electrical engineer so I can't explain why you should/shouldn't use the shield as ground. If there is an EE here, I'd like to hear about grounding shields on one side only (heard this from a Lockheed F-35 engineer) and on signal "reflections" / terminating resistors.
 

·
Registered
Joined
·
836 Posts
Discussion Starter #10 (Edited)
I won't claim to be an expert, but I do want to point you to the CIA 303-1 CAN wiring/connector specification document (free registration required, or google can get you some older versions):
https://www.can-cia.org/groups/specifications/

In my experience, DB9 connectors seem to be the most common connector by far. They're present on all the CAN devices I deal with at work. Of course this doesn't apply to OEM controller-to-controller or controller-to-device connections (they just use two pins on whatever connector is applicable). But it seems like D-Sub is used anywhere you might have a human plugging in.

If you do want to go with those phoenix terminal type connectors, there's a standard pinout for those too that you might want to follow.

Either way, there's an optional pin in the spec for supplying external power to devices on the bus. I'm not designing any devices for the Insight, but I think it makes sense to standardize now and have e.g. fused 12V available everywhere on the bus.

edit-
I like the suggestion here of all devices providing two connectors for CAN, since in our case we never know when another device might want to daisy-chain from our connector.
https://uavcan.org/Specification/8._Hardware_design_recommendations/


DE-9 pinout


phoenix terminal pinout

1 CAN_GND Ground / 0 V / V
2 CAN_L CAN_L bus line (dominant low)
3 (CAN_SHLD) Optional CAN shield
4 CAN_H CAN_H bus line (dominant high)
5 (CAN_V+) Optional CAN external positive supply

If you want to stick with 4 pins, I've seen CAN shield used as ground enough times. The spec allows you to leave off pin 1 or 5. I'm not an electrical engineer so I can't explain why you should/shouldn't use the shield as ground. If there is an EE here, I'd like to hear about grounding shields on one side only (heard this from a Lockheed F-35 engineer) and on signal "reflections" / terminating resistors.
1) Thank you for the suggestion on standardization. I think the 5 pin connector is a good idea because if someone does use shielded wire, the shield connection will provide additional mechanical strength.

Having played with these screw-in terminal block connectors, I'm not sure I completely trust the wires to not come out. I've seen it happen enough times. I'm not sure how to prevent this.

Which brings us back to the DB-9 connector. I'm on the fence on this. Plus side, it is standardized! And it is going to make a good electrical connection. Minus is the need to screw them in or they will fall out and that sometimes the places it needs to fit will be quite small.

And so we do see RJ-45 connectors used all the time for serial ports. So is there a standard for CAN for RJ-45? Hooking up a shield is not going to be too practical. There is an RV inverter/charger made by Xantrex that has a remote control panel connected to the inverter via CAN bus and RJ-45. Each device has two jacks so that multiple devices can be connected; the devices at the ends have plugs with (120 ohm?) terminators. The one I have has CAN as the middle two pins and power as the next outer pins.

I am tempted to go with RJ-45 because I have a crimper and it is much easier to fix these connectors. But I think I will want to use gold-on-gold plated contacts. Should someone use DB-9 and someone else use RJ-45 this is not the end of the world. Having a standard pinout for each is far more important.

2) Shielding: Good question. Do we need shielded cable? I think not, electrically, but mechanically, maybe. For the CAN lines, they are balanced so they will not really be susceptible to noise nor will they generate much noise from the signal itself. Now they can carry and radiate digital noise that could interfere with a radio (especially AM radio, weak FM stereo, and FM traffic systems for GPS receivers that use an FM subcarrier which are easily trashed by noise generators in the vehicle). For RFI, if there is any impedance between the shield and the path to the source of the noise, the noise will just couple to the shield and the shield will be an antenna. So RFI remediation depends on how well the board is laid out and a bunch of other things.

RFI susceptibility is another issue but much less likely to be an issue for a number of reasons. If you have to fix an RFI issue by adding shielding to wires you have already lost the battle. It needs to be remediated at the source, literally....

RFI remediation is an interesting topic and perhaps it would be a good idea for me to test the noisiness of a circuit before committing it to the vehicle. LOL I actually have all the tools I need to do this... but ugh. It is keeping me from just finishing the darn thing.

On whether or not to connect one or both ends, "it depends" and I think a lot of the issue was when connecting longer runs when there might be some ground potential difference at each end. That is not a problem here.

3) Why the heck are my CAN bus devices not talking to each other? I've got two CAN bus boards connected to Arduinos - one is a shield wired to an Uno, the other an Amazon MCP2515 module connected to a Nano... and they are not talking. I've tried two different send/receive sketches from two different libraries. I can see the data on the bus and going from the receiver to the MCP2515. I can see the SPI activity on both sides. I can switch sender and receiver and it all looks the same. But neither receiver outputs data to the terminal. arrgggghhh. I need a working basic CAN bus on the bench and have a bunch of projects on hold until this is working. What is the library of choice for these for Arduino? For Pi?
 

·
Premium Member
Southern California
Joined
·
805 Posts
I would recommend using ethernet (RJ-45) cables and connectors instead of DB9.
CAN requires a 120-ohm impedance cable (twisted pair cable) to have good noise immunity and function properly, and the bus must be terminated at each physical end with 120-ohm resistors.

Ethernet cables are 100 ohm impedance, so would require 100-ohm termination resistors. This is lower than the CAN specification but still well within specification for almost all modern CAN transceivers, and I've used this setup before with good success.

Using ethernet cables makes it really easy:
1. You can buy them in any length, size, whatever you want for cheap. No need to make your own cables!
2. They have twisted pair in them already, which is necessary for CAN
3. People won't have to find/buy 120-ohm twisted cable, which can be somewhat expensive, and it ensures people won't use non-twisted cable, which would be bad

Ethernet cables have 8 wires (4 twisted pairs) in them. We could use one pair for ground, one for power, and one for CAN, leaving one pair left over for future stuff.
There are also shielded ethernet cables, though the shielding shouldn't be strictly necessary in this environment. Also, CAN isn't going to radiate enough to affect anything in the car, the much bigger concern is the car's EMI affecting the CAN.

Can't really help with the Arduino CAN problems without the code you're using and pictures of all the hardware and wiring, but if you can't get the example sketches working, likely something is wrong with your hardware setup.
You sure you have the bus terminated? If you don't have any termination resistors it won't work at all.
 

·
Administrator
Joined
·
12,156 Posts
I'll echo what Mario says. Ethernet stuff is cheap as chips.
I'm using some RJ45 cables in my BCM replacer work.

Don't underestimate the amount of horrible noise in the IMA compartment though.
If you have screened cables you may as well use them but avoid earth loops etc.
 

·
Registered
Joined
·
496 Posts
I guess I should correct what I said earlier. DB9 is great where a human is plugging in, but it's a bad recommendation for devices/controllers. I'm accustomed to having them available where devices are frequently disconnected/reconnected for development/debug purposes, but they're obviously not meant for permanent in-vehicle connections.

TBH, I have the same concern about RJ45 / cat5 as well. Aren't these cables/connectors intended for stationary installations? Or are RJ45 suitable for automotive use? The vehicles at work certainly don't have RJ45 jacks anywhere. I want to be careful that we don't go with the easiest/cheapest route and end up having reliability issues down the line.

I'm also worried about power transmission. It looks like with the power over ethernet standard, they rely on high voltage, low amperage for power transmission, which I assume isn't something we'd want to deal with (or else we could consider two-wire power over data lines "PoDL"). Ideally I'd like to find a connector that has 2 heavier power pins and 2-3 smaller pins for CAN (w/optional shield?). My FSAE team has some REALLY nice thin shielded cable for transmitting power + signal that would be a breeze to route throughout the insight. I have a personal preference towards Deutsch DT/DTM/DTP connectors but they may be overkill (they survive water jet intrusion protection tests, and we've dropped a HV battery pack and yanked on one and it held) and they may not come in a mixed config anyway (e.g. DTM + DTP in one shell). I can also understand if this group does not want to get into spending hundreds/thousands on crimp tools... but if something can be crimped with the highly affordable Engineer PA-09 or PAD series crimpers it may be worth the effort.

My last worry is shielding. With a HV motor/controller bench test setup at school, I was having troubles with the CAN network being killed every time the inverter was enabled. I was using UTP at the time. Shielding fixed the problem, but I lost a lot of time trying to figure that one out. At the same time, at work we have unshielded CAN runs that are WAAAAAY beyond what the CAN spec allows, and yet they run automated tests 24/7 without issue.

Anyway, attached is the CANOpen RJ45 pinout. And here's a link that goes into the physical bus layout / topology
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P7ikSAC
 

Attachments

·
Registered
Joined
·
836 Posts
Discussion Starter #14 (Edited)
@GuySmily,

One place we have seen RJ45 (and RJ12) used where there is cable motion is on ham radio microphones and old school phone handsets. For handsets, I recall failures due to strain on the wire at the connector, and intermittent connections. Perhaps strain relief, secured wires and contact metal selection would address these?

Maybe including power on the data connector is a bad idea for public consumption because of the bus topology. If a device with a large load is placed at the end of the chain, a weak link the middle could overheat particularly since the fuse must be rated for all devices in the chain. Perhaps it is better to fuse and power each board separately. This could be important from an EMI perspective too.

If the bus is tapped, what is the maximum run from where the bus is tapped to a properly terminated device? (probably frequency dependent)
 

·
Registered
Joined
·
496 Posts
@GuySmily,

One place we have seen RJ45 (and RJ12) used where there is cable motion is on ham radio microphones and old school phone handsets. For handsets, I recall failures due to strain on the wire at the connector, and intermittent connections. Perhaps strain relief, secured wires and contact metal selection would address these?
Maybe.

Maybe including power on the data connector is a bad idea for public consumption because of the bus topology. If a device with a large load is placed at the end of the chain, a weak link the middle could overheat particularly since the fuse must be rated for all devices in the chain. Perhaps it is better to fuse and power each board separately. This could be important from an EMI perspective too.
Maybe trying to provide power to everyone's homebrew devices is asking for too much. Or maybe it's obvious that if you're designing a high current device like an actuator or something, you won't be able to power your devices from the bus. Mario's idea of using two wires for power and two wires for ground might help, but I still wish I could think of something as convenient and cheap as cat5 but better suited to our needs.

It does sound convenient to have a the same two connectors on everyones' devices to provide all the communications + power needs. Presumably the entire power line would be fused at the source (5A, maybe 10A?). Seems like it'd be convenient to just run a bunch of cat5 cables to go from term resistor -> BCM replacer -> pegasus -> obdiic&c v2 -> other projects, etc -> term resistor

We used 4-conductor wire like this on the FSAE car, with power + ground + twisted pair for signal, all in one shielded cable. It was actually some really nice thin milspec stuff from wiremasters, but this picture better illustrates my point:

This was probably 10 times the cost of CAT5, but 100 times better for our needs.

If the bus is tapped, what is the maximum run from where the bus is tapped to a properly terminated device? (probably frequency dependent)
The complicated answer looks like this:
https://can-newsletter.org/uploads/media/raw/22e891ad081073046d760e24341c618e.pdf
In reality I see the recommendations get ignored all the time. We're practically using a 12-legged star topology in one of our testers, with termination on two random legs, and it's been perfectly reliable for a year now. That said, almost all the buses I've dealt with have been 500kbit/s, with a few 250kbps. When I tried to go 1Mbps in a noisy environment I had issues.

btw, termination only happens at the two ends of the bus, not at the stubs. Termination is another weird electrical math thing for me. All I know is CAN pretty much never works without term resistors, but I've seen them run with only one term resistor, and I've seen them run with 3 (we accidentally wired in a leg from a different bus). Definitely not ideal - causes BUS HEAVY errors usually, but the majority of messages make it somehow lol. Shows the durability of the bus, I guess.
 

·
Registered
Joined
·
836 Posts
Discussion Starter #16
We used 4-conductor wire like this on the FSAE car, with power + ground + twisted pair for signal, all in one shielded cable. It was actually some really nice thin milspec stuff from wiremasters, but this picture better illustrates my point:

This was probably 10 times the cost of CAT5, but 100 times better for our needs.
This cable looks perfect. I tried searching for this on WireMaster's site, but their advanced search requires advanced knowledge of their product line. Digikey's parametric search got me much closer but the cost and minimum quantity was a fraction of what I paid for the car (which wasn't much.)

I had originally thought it would be useful for us to agree on a particular kind of connector and pinout, but on second thought, the engineering of each installation will vary depending on each person's needs (number of nodes, current requirements, space limitations, ruggedness, budget, location of the device, etc.)

I now have some interconnect ideas for my projects and I no longer think I'm going to standardize on wiring and connectors in even my own car. For example, I'm going to head over to the thrift store to see if they have any old school USB A/B cables or Ethernet which should work great for a number of my low current modules. I'm going to have different needs in different locations in the car, and making a new custom connector when one is needed is easy and the least of my worries.

Do we want to talk about message formats or is that something that each person can adapt to in code, assuming that anyone building a module with a CAN interface is willing to publish the interface?
 

·
Registered
Joined
·
496 Posts
Funny, I was thinking USB2.0 cable seems pretty good, but I wish it could handle more current. Probably good enough for most use cases though and I know a lot of cables out there can handle 2A or more for phone charging.

For message formats.. 500kpbs, standard IDs (not extended)?

As for priorities/IDs, just be aware of how priority works. Lower ID = higher priority, 0 being highest priority and I think 0x7FF is lowest, if we don't use extended IDs.

We should also try to avoid IDs used by common aftermarket components.
Personally, I'm looking at these:
Rinehart motor controllers use 0xA0-0xAF and 0xC0-0xC2.
Elithion BMS uses 0x620-0x629
Orion BMS uses the 0x080 block I think.
Who else do we need to worry about...
 

·
Premium Member
Southern California
Joined
·
805 Posts
One place we have seen RJ45 (and RJ12) used where there is cable motion is on ham radio microphones and old school phone handsets. For handsets, I recall failures due to strain on the wire at the connector, and intermittent connections. Perhaps strain relief, secured wires and contact metal selection would address these?
In this specific case, the wear is probably caused by the constant movement and use of a handset cable. Something put in an Insight isn't going to be moving around all the time as long as the cables are tied down properly. Vibration is the bigger concern, but strain relief doesn't help as much there.

Maybe including power on the data connector is a bad idea for public consumption because of the bus topology.
Perhaps, yeah. My thinking was for small sensor-like devices, they could be powered off the bus. Anything requiring more power would have to get it from somewhere else. You could probably only draw 500mA or so.

If the bus is tapped, what is the maximum run from where the bus is tapped to a properly terminated device? (probably frequency dependent)
The general recommendation for CAN (at 1Mbps) is no more than 1ft "stub length" - the length of un-terminated wire coming off the bus. If the bus runs to each device (with two connectors on each board), then there's no issue at all.
In addition, even if you have really long stubs, it won't necessarily cause the network to stop working, just increases the chance of transmission errors due to signal reflections. And yeah, a lower transmission frequency helps, though not because it creates smaller reflections, but because the signal has more time to settle before the bit is sampled.

All I know is CAN pretty much never works without term resistors, but I've seen them run with only one term resistor, and I've seen them run with 3 (we accidentally wired in a leg from a different bus). Definitely not ideal - causes BUS HEAVY errors usually, but the majority of messages make it somehow lol. Shows the durability of the bus, I guess.
In CAN, the resistors serve double-duty - they provide the termination for the bus, and also hold the bus in the "recessive" bit state. CAN has "dominant" (0) and "recessive" (1) bit states, where the drivers drive voltage on the bus for dominant and release the bus for recessive. In recessive, the resistors pull the two lines back "together" (to the same voltage).

Funny, I was thinking USB2.0 cable seems pretty good, but I wish it could handle more current. Probably good enough for most use cases though and I know a lot of cables out there can handle 2A or more for phone charging.
USB cable is nice, though it's 90 ohms impedance rather than 100 ohm or 120 ohm. There are two important rules to follow:
1. All cable runs used in the CAN network need to have the same impedance
2. The bus needs to be terminated with resistors that are the same as the impedance of the cable

If we use USB cable, then everybody needs to use USB cable, and the bus will need to be terminated with two 90-ohm resistors, which will present a 45-ohm load to the CAN drivers. I'm not really comfortable going even lower than the 100-ohm impedance of ethernet cable, when the CAN spec calls for 120 ohm. I just worry the drivers won't be able to drive enough current across the bus.

For message formats.. 500kpbs, standard IDs (not extended)?
500k is probably a good speed, we might want to go to 250k for signal integrity reasons. 250kbps is pretty fast, I can't imagine us needing a ton of bandwidth between devices.

Definitely recommend extended IDs for two reasons - one, most aftermarket devices like you mention use 11-bit IDs, so if we choose 29-bit, then we'll be compatible with any device that uses 11-bit IDs. And two, you can open up the address space much more and even do special things with the IDs, like create messaging protocols or whatever else.
At work I made a custom CAN protocol that uses the 29-bit IDs to encode information like device addresses, multi-CAN-frame messages, etc. to send messages of up to 128 bytes by using multiple CAN messages and encoding frame-association data in the ID. Not saying we need that, but having the longer IDs keeps things flexible.


-------------------------------------------------------------------------


Here are the assumptions I've been making about this data bus:
1. Anybody developing a device for it will be fairly technically-savvy and will understand what to do and not do with it
2. There will be fewer than a dozen devices that will probably use this spec - I mean, how many individual Insight electronics projects are there even right now that would benefit from this? Not many.

For the integrity of the bus, the right cables must be used. This is why I'm going to keep pushing ethernet cable over anything else - it's already a good impedance, you can buy the cables pre-made, and you can get the required connectors easily in any style you want. You can get shielded ethernet cables, which will be important in the noisier areas of the car. Any anybody with different cable requirements can use something else (provided it's the same impedance), but the ethernet cables will probably cover everything 99% of projects would need in terms of communicating on this shared bus.

These are just my opinions of course, I'm not even sure how much use a standard like this would be used, with how few projects there are. And some projects still use other dedicated communications lines, like how Pegasus and Linsight are planned to use the METSCI RS-485 line that goes between the cluster and BCM. Or how Peter's projects talk across the K/H-lines in the car. It just makes more sense than running an external cable.
 

·
Administrator
Joined
·
12,156 Posts
I would not get hung up with cable impedance or exact termination values.
The buses that use differential signalling like CAN , RS485 etc etc are very tolerant.

In our cars runs will be very short, certainly less than a few meters, and often less than 100cm..

You could use twisted insulated barbed wire and it would likely work.
Usb cable, rj45 cable Cat e , screened, unscreened, twisted pair, bits of wet string etc.

If the spec says 75R termination it's highly likely 100R or 50R would also work.

As a standard 8 core network cable, or 4 core USB cable is very cheap as has been stated.
Take your pick depending on how many cores you want.
 

·
Registered
Joined
·
1 Posts
I just wanted to add to this post, I'm a wiresman whose been on the hunt for a DC power + data pair cable for some bespoke work, I believe the cable you found - 30-00872 Tensility International Corp | Cables, Wires | DigiKey

It is similiar, if not the same as the cable for the application I'm trying to manufacture a 20m cable for. The cable I'm trying to make a 20m version of uses the same cable in a 5m Can-bus + DC power application for some film/cinema camera motion head equipment so it's looks like a suitable choice for your application.

If you're wanting something mechanically robust look at tour grade, or field riggable Cat5/Cat6. I've used Van Damme Tourcat with Neutrik's ethercon connectors for stage/live event applications with no issues. There's general purpose outdoor cat5 cable that's much cheaper and thinner than Tourcat that might be better if you want to use Cat5 in your application. I hope this helps.
 
1 - 20 of 23 Posts
Top