-
There were many reasons for the change of the site software, the biggest was security. The age of the old software also meant no server updates for certain programs. There are many benefits to the new software, one of the biggest is the mobile functionality. Ill fix up some stuff in the coming days, we'll also try to get some of the old addons back or the data imported back into the site like the garage. To create a thread or to reply with a post is basically the same as it was in the prior software. The default style of the site is light colored, but i temporarily added a darker colored style, to change you can find a link at the bottom of the site.
A little Can Bus tutorial
- Thread starter IdahoMtnSpyder
- Start date
robmorg
New member
One would think so. Thanks, Billy.
The reason I thought of this, in connection with this can-bus thread, was this statement made by IdahoMtnSpyder in the OP...
... and the Load Shedding Relay is on the same fuse as the horn. But after reading it again, I see your point.
kml354
New member
BertRemington
New member
CAN-BUS clarification
Clarification on CAN-BUS.
The CAN-BUS protocol is about messages not devices.
That is, every device on the bus broadcasts it's messages with specific identifiers and every device listens to all messages ignoring all but those having the specific identifiers of interest.
There is no device identifier in the protocol just message identifier.
Even the Remote Transmission Request (Remote Frame) message does not specify a device identifier. Rather it specifies the message identifier of interest to which none, one or more devices may respond (the protocol includes prioritization and deconfliction).
We see this behavior as part of our Spyder's Key-On initialization. The console sends out radio-related RTRs and if the appropriate messages are not received in response then disables radio-related functions from the console configuration.
==========
CAN-BUS is designed to be electrically robust but electrical interference can occur. Typically there are two causes: (1) poor grounding of an electrical device that may or may not be on the bus; and (2) coupling (most likely inductive) to nearby circuitry. Proper device selection and care with its installation prevents interference. For instance, my right-side HID electronics are next to the Spyder Diagnostic Link Connector without interference.
==========
Conceptual explanation of the relationship between CAN-BUS and OBD-II.
CAN-BUS is how the Spyder talks* to itself.
OBD-II is how the Spyder talks* to us.
* talks using CAN-BUS messages.
Clarification on CAN-BUS.
The CAN-BUS protocol is about messages not devices.
That is, every device on the bus broadcasts it's messages with specific identifiers and every device listens to all messages ignoring all but those having the specific identifiers of interest.
There is no device identifier in the protocol just message identifier.
Even the Remote Transmission Request (Remote Frame) message does not specify a device identifier. Rather it specifies the message identifier of interest to which none, one or more devices may respond (the protocol includes prioritization and deconfliction).
We see this behavior as part of our Spyder's Key-On initialization. The console sends out radio-related RTRs and if the appropriate messages are not received in response then disables radio-related functions from the console configuration.
==========
CAN-BUS is designed to be electrically robust but electrical interference can occur. Typically there are two causes: (1) poor grounding of an electrical device that may or may not be on the bus; and (2) coupling (most likely inductive) to nearby circuitry. Proper device selection and care with its installation prevents interference. For instance, my right-side HID electronics are next to the Spyder Diagnostic Link Connector without interference.
==========
Conceptual explanation of the relationship between CAN-BUS and OBD-II.
CAN-BUS is how the Spyder talks* to itself.
OBD-II is how the Spyder talks* to us.
* talks using CAN-BUS messages.
Last edited:
I must be CAN-BUS because after reading this you have me " Talking to MYSELF ", I'm a bit hard of hearing, but the OBD-II must not be working because I haven't heard a word out of my Spyder! Thanks for the info though. :thumbup: Bill
That helps.
BertRemington
New member
CAN-BUS is not a LAN
I was trying be careful in not saying it but now I must: CAN-BUS is not a LAN.
Without over-simplifying too much:
* CAN-BUS carries complete messages; LAN carries packets with complete, incomplete and multiple contents (messages)
* CAN-BUS "addresses" are device-independent message identifiers; LAN "addresses" are content-independent device identifiers (multicast is special "device" address)
* CAN-BUS uses a robust two-wire signalling protocol with simple message prioritization, deconfliction and filtering rules implemented with cheap chips (eg MCP2515 and MCP2551); automotive LAN 10xxBASE-T1 uses a single twisted pair which provides inter-device packet exchange using a variety of line codes (and chip families) and requiring additional chips for device-unique higher-level content (message) processing.
As our vehicles evolve to "software carriers" and MCUs are replaced with CPUs, CAN-BUS will likely remain for "transport-critical" functions while LAN is introduced for non-critical functions. I doubt the Spyder radio will ever move from CAN-BUS to LAN but I'm pretty sure your Mercedes radio already has.
==========
Adding a note about OBD-II and Spyders. OBD-II requires certain standard messages for specific emission certifications. Spyders aren't required to meet those certifications (note the lack on your under-seat stickers) and therefore is using manufacturer-unique OBD-II messages (allowed by the standard). Which I learned at the cost of $100 in hardware and software.
I was trying be careful in not saying it but now I must: CAN-BUS is not a LAN.
Without over-simplifying too much:
* CAN-BUS carries complete messages; LAN carries packets with complete, incomplete and multiple contents (messages)
* CAN-BUS "addresses" are device-independent message identifiers; LAN "addresses" are content-independent device identifiers (multicast is special "device" address)
* CAN-BUS uses a robust two-wire signalling protocol with simple message prioritization, deconfliction and filtering rules implemented with cheap chips (eg MCP2515 and MCP2551); automotive LAN 10xxBASE-T1 uses a single twisted pair which provides inter-device packet exchange using a variety of line codes (and chip families) and requiring additional chips for device-unique higher-level content (message) processing.
As our vehicles evolve to "software carriers" and MCUs are replaced with CPUs, CAN-BUS will likely remain for "transport-critical" functions while LAN is introduced for non-critical functions. I doubt the Spyder radio will ever move from CAN-BUS to LAN but I'm pretty sure your Mercedes radio already has.
==========
Adding a note about OBD-II and Spyders. OBD-II requires certain standard messages for specific emission certifications. Spyders aren't required to meet those certifications (note the lack on your under-seat stickers) and therefore is using manufacturer-unique OBD-II messages (allowed by the standard). Which I learned at the cost of $100 in hardware and software.
IdahoMtnSpyder
Active member
Thanks for the clarification about the "how" of the network messages. It looks like I did have the "what" reasonably correct. I had completely forgotten I made this post nearly 7 years ago!
Adding a note about OBD-II and Spyders. OBD-II requires certain standard messages for specific emission certifications. Spyders aren't required to meet those certifications (note the lack on your under-seat stickers) and therefore is using manufacturer-unique OBD-II messages (allowed by the standard). Which I learned at the cost of $100 in hardware and software.
When I've looked for additional info on Spyder Error Codes I've noticed that many of them are in fact the same ID and explanation as automotive codes, particularly those related to engine operations that affect emissions.
The Spyder CanBus system is much the same as industrial control systems, right? And there are a bunch of them! https://en.wikipedia.org/wiki/List_of_automation_protocols
CloverHillCrawler
Active member
I don't know this "update" has me asking questions as this is the first time of me hearing OBDII in relation to the Spyder.
Are you saying that BUDS is using OBD-II as its communication protocol?
BertRemington
New member
I ain't chasing that OBD rabbit
When gkamer asked about CAN-BUS for Ryker and SportsterDoc cited your 2016 tutorial I took the opportunity to update the community with what I've learned in the last year or so.
Yes the Spyder OBD PIDs match the standard PIDs except ... extracting them using off-the-shelf hardware (OBDlink) and software (OBDwiz) in KWP2000 and CAN-BUS 2.0a (11-bit) message formats didn't work. There is a Service 01 PID 1C - OBD standards this vehicle conforms to but OBDwiz didn't display any helpful information whatsoever. OBDwiz does have a direct command interface to the OBDlink (based on the Hayes AT command set if you can imagine that) but I'm really not that interested* in chasing that rabbit, a chase that began when wlinn1 asked about a HUD and I foolishly thought I can do that. NOT!
I know the PIDs are in there, you just need to know how to ask the Spyder for them. The best approach would be to have a CAN-BUS sniffer listening while a BUDS is requesting and receiving them. And a pre-BUDS2 Spyder (pre-2017) will probably be easier to decode than later Spyders.
If someone wants to use the AT command capability of OBDwiz to decode the OBD PIDs the Spyder is generating, I'll loan them my OBDlink, OBDwiz (I have an unused activation) and the 6-pin Deutsch DT connector. Start by researching the software here https://www.scantool.net/obdwiz and the forum here https://www.scantool.net/forum/index.php
* My interest is specific device-level messages such as LT button pressed, RT button pressed, etc and I've decoded those.
When gkamer asked about CAN-BUS for Ryker and SportsterDoc cited your 2016 tutorial I took the opportunity to update the community with what I've learned in the last year or so.
Yes the Spyder OBD PIDs match the standard PIDs except ... extracting them using off-the-shelf hardware (OBDlink) and software (OBDwiz) in KWP2000 and CAN-BUS 2.0a (11-bit) message formats didn't work. There is a Service 01 PID 1C - OBD standards this vehicle conforms to but OBDwiz didn't display any helpful information whatsoever. OBDwiz does have a direct command interface to the OBDlink (based on the Hayes AT command set if you can imagine that) but I'm really not that interested* in chasing that rabbit, a chase that began when wlinn1 asked about a HUD and I foolishly thought I can do that. NOT!
I know the PIDs are in there, you just need to know how to ask the Spyder for them. The best approach would be to have a CAN-BUS sniffer listening while a BUDS is requesting and receiving them. And a pre-BUDS2 Spyder (pre-2017) will probably be easier to decode than later Spyders.
If someone wants to use the AT command capability of OBDwiz to decode the OBD PIDs the Spyder is generating, I'll loan them my OBDlink, OBDwiz (I have an unused activation) and the 6-pin Deutsch DT connector. Start by researching the software here https://www.scantool.net/obdwiz and the forum here https://www.scantool.net/forum/index.php
* My interest is specific device-level messages such as LT button pressed, RT button pressed, etc and I've decoded those.
BertRemington
New member
CloverHill -- explaining something conceptually is tricky so here's some additional information.
In both cases the "communications protocol" is CAN-BUS.
When talking to itself, the messages are "internal use only" specific to the Spyder.
When talking to us via the BUDS laptop and Spyder console, the messages are defined by the OBD-II standard.
Special qualification: while the BUDS laptop and Spyder console display "OBD-style" B/C/P/U codes, I don't know for sure the messages themselves are in OBD-II format. It just seems to me with an ECM, TCM, etc designed and built by Bosch who is the standard-setter that the messages would be in OBD-II format, just not in the emissions certification OBD-II format off-the-shelf OBD-II software (eg, my OBDwiz) recognizes. But that's a hypothesis not a certainty that I will continue with.
Only the BUDS laptop, Spyder console and certain top-line diagnostic equipment know how to request and decode Spyder OBD-II messages.
The BUDS laptop and the Spyder console are using the Spyder CAN-BUS (accessed by the laptop at the 6-pin Deutsch Data Link Connector) to transmit OBD messages and receive the responses.
For the B/C/P/U DTCs, the Service 03 - Show stored Diagnostic Trouble Codes message is broadcast that when recognized by specific Spyder devices (eg, ECM TCM*) broadcast in response DTC messages that are decoded and presented to us on the laptop and console as B/C/P/U codes.
* I believe each device responds with its own DTCs but there's a possibility the console serves as the central collection and response interface.
Real-time data is requested and returned using the Service 01 - Show current data PID. It was this information I hoped could feed a HUD but I couldn't request/decode it with OBDwiz.
It's easier to understand these interactions by examining CAN-BUS and OBD-II separately. That is, don't think about CAN-BUS when figuring out how OBD-II works and vice versa.
In both cases the "communications protocol" is CAN-BUS.
When talking to itself, the messages are "internal use only" specific to the Spyder.
When talking to us via the BUDS laptop and Spyder console, the messages are defined by the OBD-II standard.
Special qualification: while the BUDS laptop and Spyder console display "OBD-style" B/C/P/U codes, I don't know for sure the messages themselves are in OBD-II format. It just seems to me with an ECM, TCM, etc designed and built by Bosch who is the standard-setter that the messages would be in OBD-II format, just not in the emissions certification OBD-II format off-the-shelf OBD-II software (eg, my OBDwiz) recognizes. But that's a hypothesis not a certainty that I will continue with.
Only the BUDS laptop, Spyder console and certain top-line diagnostic equipment know how to request and decode Spyder OBD-II messages.
The BUDS laptop and the Spyder console are using the Spyder CAN-BUS (accessed by the laptop at the 6-pin Deutsch Data Link Connector) to transmit OBD messages and receive the responses.
For the B/C/P/U DTCs, the Service 03 - Show stored Diagnostic Trouble Codes message is broadcast that when recognized by specific Spyder devices (eg, ECM TCM*) broadcast in response DTC messages that are decoded and presented to us on the laptop and console as B/C/P/U codes.
* I believe each device responds with its own DTCs but there's a possibility the console serves as the central collection and response interface.
Real-time data is requested and returned using the Service 01 - Show current data PID. It was this information I hoped could feed a HUD but I couldn't request/decode it with OBDwiz.
It's easier to understand these interactions by examining CAN-BUS and OBD-II separately. That is, don't think about CAN-BUS when figuring out how OBD-II works and vice versa.
BertRemington
New member
IdahoMtnSpyder
That is a fun list. I bookmarked it. Thanks.
Yep CAN (BUS) is on that list. Although I'm pretty sure my and earlier Spyders use KWP2000 which is also on the list. I surmised this from this service manual picture.
And the CAN-BUS does run at 500kbps.
PS I said CAN-BUS was cheap and Wikipedia agreed with me.
That is a fun list. I bookmarked it. Thanks.
Yep CAN (BUS) is on that list. Although I'm pretty sure my and earlier Spyders use KWP2000 which is also on the list. I surmised this from this service manual picture.
And the CAN-BUS does run at 500kbps.
PS I said CAN-BUS was cheap and Wikipedia agreed with me.
Last edited:
BoatFixx
Member
I hope this link works.
https://www.roadrunner.travel/artic...can-bus-can/?ref=roadrunner-weekly-newsletter
https://www.roadrunner.travel/artic...can-bus-can/?ref=roadrunner-weekly-newsletter
Last edited by a moderator:
Similar threads
