Это видео недоступно.
Сожалеем об этом.
🛠 Communication - Yes you CAN: What is CAN Control? | TECH TUESDAY
HTML-код
- Опубликовано: 14 авг 2024
- #can #communication #haltech #haltechTECH
Today on Tech Tuesday, we're decrypting CAN. As everyone is aware, modern cars are full of computers. Everything from the engine and gearbox to the power windows is controlled by a computer. How do all these computers talk to each other? With a Controller Area Network (Or CAN bus) - But what is it, and how CAN it benefit you?
Got a topic you'd like us to cover? Leave it in the comments section!
-----------------------------------------------------------
Liked this video? Here are more like it:
How Flex Fuel Works: • 💬 How to Flex Fuel | T...
How Dyno Tuning Works: • 💬 Dyno Tuning Basics ...
How CO2 Boost Control Works: • 💬 How CO2 Boost Contro...
------------------------------------------------------
Don't miss out on our next video - subscribe to our channel.
------------------------------------------------------
For more Haltech goodness check out our:
Website: www.haltech.com
Facebook: / haltechenginemanagement
Instagram: / haltechecu
~-~~-~~~-~~-~
WATCH NEXT: "🏅 Jason Waye's Barra Powered Fox Body | HALTECH HEROES"
• 🏅 Jason Waye's Barra P...
~-~~-~~~-~~-~
Today on Tech Tuesday, we're decrypting CAN. As everyone is aware, modern cars are full of computers. Everything from the engine and gearbox to the power windows is controlled by a computer. How do all these computers talk to each other? With a Controller Area Network (Or CAN bus) - But what is it, and how CAN it benefit you?
This went 0-60 ohm fast.
I love the simple analogies used in these videos - telephone network was on point Scotty!
This was a fantastic and easy to understand lesson. This is one of many reasons I chose Haltech! I'm also pretty fond of the Haltech USA crew after getting to know them at gridlife events.
Good, and understandable basic explanation of CAN! Can i add one important thing, that tends to catch people out, namely what the "Bus termination" does! When you send a pulse of electricity down a wire, if it reaches a sudden change in impedance (impedance being the sum of resistance and inductance), that pulse can reflect back up the wire in the opposite direction. The most likely "sudden change" in any wire is simply the end of that wire! And the CAN bus obviously has to start and end somewhere... If the electrical pulses got reflected back up and along the bus they could cause errors in the data being transmitted, depending on where the arrive and at what time. There is a lot of complicated science covering bus bit rates, physical lengths of the bus, mutual inductance and other factors, but luckily, three basic rules will cover pretty much any situation:
1) The CAN bus should be, wherever possible a "Linear" arrangement, rather than a "star" arrangement. For two devices that's easy, but for 3 or more devices, you may need to consider the routing and branching of the CAN bus to achieve a broadly linear layout. Where you have to "T" off the bus, to connect another CAN device, keep that "T" as physically short as possible. Realistically, with the T branch wires being at most 10 cm long, you are unlikely to have any problems up to a bus bit rate of 1 Megbaud. The main linear section of the CAN bus can of course easily be several meters long. For example, say you have 3 devices, one in the boot (trunk) one on the dash, and one under bonnet, you will need to run the CAN bus from the rear device through the car (likely to be a run of several meters) and pass close to the device on the dash. T off the loom with a short pair of wires (less than 10cm long) to connect to that dash device, and continue the linear main run through the bulkhead to the under bonnet device. That way you have a broadly "linear device" What you don't want to do is to say bring three 2 meter long pairs of wires to a single point at join them there (because that would be a "star" layout)
2)The main linear section must have a 120 ohm termination resistor at each end (two resistors at 120 ohms, gives an overall 60 ohm impedance as required). Most CAN hardware is actually able to handle up to around 4 or 5 termination resistors each of 120 ohm, and these additional terminators can help to fix problems with bus layouts that are non- ideal (ie more "star" shaped) but it should be avoid wherever possible. In our previous case, the device in the boot would have a termination resistor, and the device under bonnet, but the dash mounted device, with it's very short T off the main bus would not have a termination resistor.
3) Twist your CAN High and CAN Low wires together! A twisted pair of wires helps lower the characteristic impedance of the bus, and helps it reject electrical noise from external sources (like say a coil pack, or injector wiring). You can purchase specific CAN bus wiring, that has the requisite twists pre formed into it, but in most cases it's cheaper to simply twist by hand a pair of 20 gauge wires together, with around 4 twists per inch.
Hope that makes sense and helps you construct simple and robust CAN networks in your cars! :-)
Thanks for this Especially
"3 Twist your CAN High and CAN Low wires together!"
something I would usually avoid good to know its beneficial in this case!.
its also good to get technical responses of this kind,
and I thank you for your time
Many thanks
Brilliant video, thanks very much 👌
Just got my elite 2500 today and my CAN set up is next on the wishlist, not to mention all the other goodies Haltech have lol
Would love scotty to do a more in depth episode on CAN
Cheers guys!
Well.. this was pretty much it. If you need to go any further, we start getting into programming.
Hey Scotty what was your career path, did you do a mechanical or electrical engineering degree or work your way up from a mechanics apprenticeship?
great video BUT it does make you wonder how much of the car that is controlled by computers actually NEEDS to be controlled by computers and making it MORE complicated, rather than simpler!
So Can is a shared medium, like Ethernet used to be. So how are conflicts handled? What happens when two or more devices need/want to use the bus at the same time. In Ethernet this is done reactively, if a collision is detected everyone backs off for a bit, however this doesn't seem to be a good method for devices that need real time communication.
paul zapodeanu Pretty sure it is token based.
Thanks. I was wondering the other day what CAN BUS actually was. Now I know. Very well explained and easy to follow even for a drongo Pom like me.
Loving Tech Tuesday.
This may be ignorant, but is it possible to have multiple protocols on one bus?
Thanks for another awesome vid!
It's a little bit more complicated in terms of the "layers" specified by the CAN standard. The wiring for the CAN bus itself is referred to as the "Physical" layer and on top of that sit the "Transfer" layer and the "Object". These layers are actually also further broken down in the complete CAN standard! (and i'll ignore later CAN standards like CAN FD and Flexray etc, and only talk about "classic" CAN, which is really CAN 2.0b as defined in the matching standards documentation)
Broadly speaking, the Transfer layer must be the same for all CAN nodes connected to the physical layer. That means all nodes operate at a single fixed bit timing, and with a fixed packet definition. CAN 2.0b does allow the bus architect to mix and match between standard (11bit) and Extended (29 bit) addresses on the same bus (although this is generally avoided), and the actual data payload can be of a variable length between 0 and 8 bytes long (CAN was not designed to have a high data transfer rate in terms of total information exchange, but to be able to reasonably quickly transfer a lot of small packets of data). CAN uses unique message identifiers to allow individual devices on the bus to accept or ignore individual message packets, and arbitration is automatically, but not atomically, managed via the magnitude of the address. ie a message with address 100 would get priority to be transmitted on the bus over any message with a higher ID ( 101 or greater) but loose to a message with a lower ID (ie 99 or less). For example on a CAN bus, you would expect say the engine speed to be sent with a much lower ID than the status of the heated rear window, because it is important that engine speed get to the receiving device(s) in a timely manner, where as the status of the window heater is not critical if it's a bit late!
With CAN, there is no intrinsic architectural layer, ie any message that is transmitted onto the bus can be received by any other device on that bus. So the engine ECU can send out a single message with a data payload containing engine speed, and any device connected can listen out for that message, recieve it, and hence access that messages payload. Transmissions may be Broadcast (ie happen at regular timed intervals) or be Polled, where a device only sends out a packet after it receives a specific message requesting it to do so.
So, we have out packets present on the bus, and each has an ID and a data payload of up to 8 bytes, the next question is "what does each payload contain" and here is where everything is thrown wide open. An Bus architect may choose to encode any particular bit of data in any format and with any packet ID as they see fit! The different OEs all use different encodings, scaling and IDs. A digital signal, like say brake lights "on" can be a single bit (64 bits available in an 8 byte payload), and data with a higher resolution like engine speed may be scaled to use 2 bytes (16 bits) with some scaling factor and / or offset.
Finally, there are higher level protocols, such as J1939, which attempt to specify a standardised CAN protocol for commercial vehicles. The idea is that with a standard protocol, any manufacturer of any equipment can use any other manufacturers equipment and the system will still work. For example, a Truck tractor unit can be connected to any trailer, and the rear lights will work in both cases because the rear lighting module is listening out for standard messages to act upon.
Just when I start thinking about using an aftermarket dash on my build...here comes tuning fork with the answer, I think this bloody iPhone is can protocolling my brain!
THIS IS THE VIDEO I NEED RIGHT NOW!!!
Question: Do y'all have any CAN preset up for different car manufacturers? Like for my Mini Cooper, can I just hook up the wires and say here is the pin number and what CAN protocols it needs to send/receive (BMW)? Or is there much more setup than that? I wouldn't expect the CAN systems to be standardized from BMW to Toyota or Mitsubishi etc. without a partnership of some kind.
End goal for me is trying to replace the OEM Mini R56 ECU and with a Standalone that can act as a replacement with CAN communications to activate the dash, electric power steering, link OEM Mini electric throttle pedal with lancer electric throttle body, possibly ABS, CELs, maybe OBD2 and other items. And of course the OEM ECU can't work because my Mini has a 4g63 engine in it so it has completely different trigger patterns and everything else.
Thank you very much, very informative video! Could you, please, she’d some light on this on for me. If I have a x brand car (Benz) with its proprietary can bus, can I wire in standalone haltech ecu with piggyback installation to have working stock abs/esp/transmission control functionality?
Yes, a piggyback or parallel installation is a common solution where you let the Haltech ECU control the engine while the factory ECU retains control of the CAN Bus and the transmission.
ruclips.net/video/A1ePCv0Z3rE/видео.html
Can the haltech connect to the dsg gearbox via can and control the gearbox ?
So there is a CAN connection on the Dakota digital VHS series guages. Will the elite series ecu be able to work with those gauges?
What about ion-sensing ignition systems (that use the spark plug as a knock sensor)? Can they be used with a Haltech ECU or if they are a separate system can it be integrated?
Thanks for all the super informative videos!
Have you got a goto android app that will happily communicate thru the can -> obd2 adaptor-> wireless bluetooth dongle that you can reccomend? Looking to try this thru an android auto head unit for guage display with a elite 1500
So em i mate. Did you have any luck?
@@MrFlop10 i tried torque pro , it did most things but not all. Ended up buying a haltech/ guagepro guage and doing it that way.
@@wrcgt4 ok cheers mate
Very well explained and excellent tech resource. Will CANBUS change/be replaced in the near future?
It already has.... CAN was defined by Bosch, BMW and Mercedes way back in the very early 1990's Today, our cars now have data transfer requirements that outstrip the basic ability and robustness of the basic CAN standard. For example, safety critical systems like dynamic stability control need to ensure they get the latest data, up-to-date, and without any errors in order to act promptly and appropriately. And the massive infotainment data requirement for modern ICE cannot possibly be transferred across CAN either. So there are broadly 4 alternatives now fitted to most modern cars:
1) MOST - Media Oriented Systems Transport - usually an optical network over plastic optical fiber (POF) cable, designed to rapidly transfer large amounts of data at high bandwidths - used for SATNAV digital radio, internet connectivity, and ultra high performance driver assistance systems (reversing Cameras etc)
2) Automotive Ethernet - Not yet common, but starting to become popular, especially for modern internet connected systems
3) Flexray - uses the same physical layer as CAN, but is fully deterministic (unlike CAN) and so can be used for safety critical data exchange. Not suitable for high bandwith data transfer, but ideal for low bandwidth low latency robust exchange, ie a vehicles stability controller talks over Flexray to the engine controller to ensure that vital info is robustly transferred
4) CAN FD - CAN Flexible Data - Closest to 'classic' CAN, sane physical layer, broadly the same protocol in terms of packets, but uses a couple of neat tricks to increase the bandwidth available for transfer. Still not deterministic so not used for safety critical coms.
I've been considering Haltech as the ECU for my new car, however there are 2 things that are throwing me off currently:
- Almost no availability / distributors and no official support in Europe that I know of.
- Stone age software, like really, since when is it acceptable to still require DirectX 9 and .Net 2 ... come on guys, 2019 is almost over. Doesn't give me confidence on the future development of the product.
www.ecu-performance.net/ Talk to Thomas, he will tell you everything you need to know :)