Do the .netmf devices do auto retransmission of faulty can messages?
Yes as this is part of the CAN specifications and done by the hardware, not the software
Can is so cool. Pity I need external components with it.
External components are needed because of 2 reasons:
- You Need different parts for different CAN Speeds (at least we do so)
- Nobody knows what your requirements are: Galvanic decoupling, …
Just have a look at the wide range piggies, … Vector electronics offers for their CAN Hardware.
@ Mr. John Smith - If you are using it for additional displays or info from your car and your car is supported of course you only need a bluetooth module (and some knowledge of the protocol of course) to be able to talk to an ELM327 OBDII Mini adapter. And as far as I know, you’ll get galvanic seperation by design …
@ PiWi - galvanic seperation? like optical isolation. Is this standard on the CAN specification? (I should read more, but I just don’t have the research time). The system is a robot not automotive btw.
CAN specifications excluded the PHY. You can use fiber optic if you want, with the proper phy.
There are today three different transceivers (phy) used in automotive, the one we all use, the single wire one and the fault tolerant one.
PS: ages ago, I used to design CAN tools for the automotive industry. After all, I am in Detroit!
@ Gus - The one we all use is the 2 wire differential half duplex right?
P.S. How long is ages ago?
Yes we use high speed dual differential wire. There is no full or half duplex on CAN. This is not how CAN works.
Ages was about 15 years ago!
You must be a youngster Gus? I just realised that the ROV (remote underwater submersible) I was recently consulting on was one with my old control system installed on that I started developing back in 1993. We worked out that the ROV is over 20 years old and still working. That was an old DOS application written in Borland Turbo C.
@ MrJohnSmith. Think of CAN bus as multi-master with a priority based messaging system. Remember that there is no destination ID in the message, just an ID to identify the sender. Each ID has to be unique and each device on the network only listens for ID’s it is interested in. That’s the beauty of the controller though, you can setup filters so you processor only deals with the ones it wants to. With a very busy bus, this offloads a lot of the processing to the controller. As an aside to the above ROV mention, our latest ROV control system is CAN bus based and super reliable. It allows us to drop in additional devices onto the ROV bus without any need to re-programme the existing modules. It reduces the wiring of the interconnects down to 4 wires. An example is the 12 function hydraulic valve pack. Normally is requires a 16 way connector. The 4 way is considerable cheaper and you need less spares stock too.
The galvanic seperation comes of course due to the bluetooth interface, but since you are using a none automotive standard protocol the forementioned ELM327 will probably not work …
However, sometime ago I made a CAN based model railroad control using Panda-II/Cobra and CAN bus together with MCP2551 (CAN Bus transceiver) and two 6N137 optocouplers.
Hereby a schema of a possible implementation.
If you have a need for galvanic separation you can just use a transceiver like: