Announcement

Collapse
No announcement yet.

where to steal CANBUS signal from ??

Collapse
X
Collapse
 
  • Filter
  • Time
  • Show
Clear All
new posts

    where to steal CANBUS signal from ??

    wiring-retard reporting in again...

    quick question on CANBUS stuff: I've got an aftermarket data logger here (racecapture pro3) and aside from logging from its internal sensors, it can take a hardwired CANBUS input and log some standard engine parameters.

    now there's 2 input options - a) buy their OBD-RJ45 adapter cable, and plug said cable into the RJ45 port on the back of the RC control box, or b) source the CAN high and low signals yourself and hardwire them to a molex connector also on the back of the RC control box.

    now from what i can see a standard OBD socket should have the CAN hi and low (pins 6 and 14) so can i just hack into the back of the OBD socket and splice off 2 wires from here and feed the racecapture the input (leaves the socket free to stick other things into)? the internet goes into meltdown about cutting and splicing into CANBUS harnesses, so im little concerned ill fuck something.

    alternatively, i could just buy an OBD plug and wire those 2 pins to the racecapture? theres nothing special about the CANBUS pins at the OBD socket, right?

    and as a related side question, reading CAN data "over OBD" refers to a communication protocol yeah? a slowish request-and-receive type of data flow? whereas if you know the data CAN protocols you can plug into the OBD socket and read the CANBUS stream directly?

    gets a little confusing for amateurs like me, where 'OBD' refers to both a plug/physical location (which contains CANBUS wires) but can also (i think) refer to a communications protocol (which is slower than actually just reading the CANBUS stream) - do i have that about right??

    cheers
    ed
    Last edited by doctor ed; 15-05-20, 10:36 AM.
    Mit freundlichen Gre

    Originally posted by Keith Duckworth
    "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

    #2
    CANbus you can just listen in for random stuff getting sent around like speed, coolant temp, engine rpm etc. They're short packets so it's really just a case of understanding who's sending it and what it is. There you're just limited to what the other devices are sending.

    OBD would generally refer to talking to modules and requesting fault logs etc. But this can go over CANbus too. Or you might be able to read gear box temp but only if you request it from the gearbox ECU as it's probable nothing else cares about gearbox temp.

    I wouldn't have a real problem going on the back of the OBD socket. It's not really any different to buying a plug and wiring from the "outside". Either way though you should keep your Hi/Lo wiring twisted and in the interests of not buggering things up I'd try and keep my CANbus interface as close as possible i.e. keep those wires short.

    Comment


      #3
      Its not actually the physical splice causing damage or anything, its not causing interference or signal loss. So cut in anywhere you need. The problem with splicing into canbus can come when you try to connect another device at the same time. Can get weird things happening, corrupted data, drop outs, etc.

      So if you arent going to log with your spliced connection and have something plugged into the obd port broadcasting to a display or something at the same time, you shouldnt have issue.
      Originally posted by Buford T. Justice
      This happens every time one of these floozies starts poontangin' around with those show folk fags.

      Comment


        #4
        ok, got it thanks guys.

        ive found an old OBD reader lying around so brutalised it for its plug and a length of cable. i can use this to non-invasively test the setup, then ill look at splicing into the CANbus behind the plug.

        interestingly the multicore cable in the old OBD reader (cable prob about 1.5m long) isnt twisted pairs, and the Hi/Lo are just in there gently wound with the rest of the bundle
        Mit freundlichen Gre

        Originally posted by Keith Duckworth
        "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

        Comment


          #5
          Probably not as big an issue on a diagnostic cable as in an electrically noisy vehicle running in parallel with lots of other wires. The twist is to ensure the differential pair works best as well as having some impedance. CANbus cable should be around 120 ohm impedance.

          Stubs (well longer than a meter or so) are generally a bit of a no-no but probably won't cause too much issue.

          Comment


            #6
            well i got a data feed, and all is kindve working. but i now realise im peering over the edge of a very deep dark hole of proprietary canbus ultra nerdy shit, and think i might just step back a little and just try and stick with standard obd protocols. it seems to be getting a reliable 25Hz of data over OBD, and for stuff like TPS and RPM thats more than enough (i honestly thought obd was going to be slower, but this works just fine)
            Mit freundlichen Gre

            Originally posted by Keith Duckworth
            "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

            Comment


              #7
              OBD2 on Canbus is slow. But the stack of other protocols that manufacturers use are quite quick and the wiring is far less finicky than it was 25 years ago.

              Don’t drop in a bunch of extra trailer wire type of patching and you can pretty much do anything, But if you’re going permanent install a shielded twisted pair won’t hurt and is able to be neatly piggy backed from the factory diagnostic connector. You can of course just do a twist of regally light gauge auto cable but that tends to be shit looking unless tied in with other wires in a neat loom or only going a very short distance.
              ---
              Shed Project: 1994 Laser Lynx with BP-T

              Comment


                #8
                Originally posted by Aaron View Post
                OBD2 on Canbus is slow.
                im surprised how quick it is. im logging TPS and RPM at 25Hz, and relaying this simultaneously over bluetooth to a dash, and there's no perceptible lag at the dash. it works very well.

                id like to nerd up and get into the proprietary obd pids, or better would be figuring out the canbus, but number of fucks is low, and the sae obd data i think will be sufficient

                Mit freundlichen Gre

                Originally posted by Keith Duckworth
                "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

                Comment


                  #9
                  From the sounds of things you're just snooping CANbus. That stuff has to be fast. That's not OBD2 when you're doing that. You're just listening in on one module talking to others.

                  Comment


                    #10
                    the setup manual and software options certainly make it sound like its obd

                    i couldn't get anything sensible working when playing directly with the canbus, so switched it over to OBD, clicked some default PIDs and away we go

                    from the site:

                    --------------------
                    OBDII Performance

                    You will notice that OBDII performance may drop as you add more channels. OBDII was never meant to be a high performance data-logging interface, but rather intended for periodic use with a scan tool.

                    What makes it slow? The request / reply protocol OBDII prescribes. The behavior is universal, and every OBDII-compliant ECU operates in this manner. So, while OBDII requests channels one at a time, direct CAN bus streaming can data (typically available on modern and aftermarket ECUs) acts like a one-way firehose of broadcasted data. RaceCapture supports this mode as well, see our CAN bus integration guide

                    Given those limitations, we have a few things that make our OBDII interface as fast as possible:

                    We use a powerful 32 bit ARM processor in RaceCapture that interacts with your car’s ECU directly, minimizing the lag between querying for an OBDII channel and processing the reply. Indeed – our code is running right down at the metal, and is much higher performance compared to your typical OBDII dongle.

                    RaceCapture also uses a priority scheduler that optimizes all of your OBDII channels. Here’s how it works:
                    Prioritizing OBDII queries

                    Let’s say there’s 3 channels you want from OBDII: RPM, TPS and EngineTemp. Since RPM and TPS are fast-changing channels, you set their rate to 25Hz. EngineTemp changes much more slowly, so you set that to 1Hz.

                    RaceCapture will now automatically schedule OBDII channels based on their configured rate – optimizing the OBDII schedule so the higher rate channels are queried more often than slower channels. In the above example:
                    • RPM and TPS are queried at the same rate (round-robin querying)
                    • EngineTemp is queried at 1/25 the rate as RPM and TPS.


                    This way we maximize the update rate we can get for RPM and TPS at 25Hz, minimizing the lag on the RaceCapture dashboard as well as in your data stream.
                    Mit freundlichen Gre

                    Originally posted by Keith Duckworth
                    "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

                    Comment


                      #11
                      Right well if your RaceCapture thing is making requests, then yes that's not snooping the CANbus as I theorised.

                      There is certainly potential to be faster than your average OBD dongle - what they say sort of makes sense it would be faster compared with say an application on a PC requesting data through a dongle. The priority schedular is obviously added for better performance and a good idea.

                      Comment


                        #12
                        Your device will be processing OBD2 PID data over canbus just like it was recalling diagnostic information, but it won't be using canbus frames. You'd have to load CAN ID values for each parameter you want to capture over canbus otherwise. To do that, you'll either need a list of ID's, along with control field identifiers and the hex data for the message. When you connect to canbus all the data is available real time, it's not a simple message request like OBD2 pid's. So you have to narrow down the fields you are looking for. When logging canbus data to reverse engineer a parameter normally you look for changes in hex values when you perform a function in the vehicle to narrow down the CAN ID and capture the data from the stream. I see there are a few pre-programmed vehicle options there on the website, someone has literally done this for that particular vehicle/ecu and made it available already, otherwise you're on your own.

                        As far as all the other stuff, Think of it this way. OBD2 is an entire vehicle communication standard. How we communicate, protocols, the interface, the datasets, it is all standardised as OBD2. CANBUS is a protocol and bus standard functioning under OBD2. Make sense now? a lot of people think of OBD2 as just a port or a specific bus and that's where they get confused.

                        In more detail, OBD2 is a communication standard for on vehicle communication and diagnostics. It was originally made up of 4 different protocols used by manufacturers for sending vehicle data for diagnostics and emissions control . None of these protocols were meant to function as anything more than a serial bus with the intent of vehicle diagnostics. As car systems became more complex and the data requirements kept growing, the 5th protocol, the one for canbus was fully incorporated in the early 2000's. Given OBD2 was adopted back in 1996, this is why there are a lot of vehicles made before the mid 2000's that have no canbus functionality at all.

                        CANBUS is a communication protocol developed by bosch to transmit more than just diagnostic data. It was originally designed to communicate with multiple control modules, servos, solenoids, sensors, etc across multiple networks. It provides a network where vehicle control modules function as nodes on the network with a central gateway controlling communications and working as a bridge to these systems. This means you can have multiple canbuses operating within the vehicle, and these can function on their own with their own gateway and no integration, or they can communicate with other buses too. Run out of bandwidth? utilise another bus. There are multiple bitrates available too as not all canbuses are the same, so it usually depends on refresh rates and data size. Typically you have low speed can which is up to 125 kbps and high speed can which is up to 1 Mbps (there are new even higher speeds which have just been developed and are making it into vehicles reducing the need for multiple buses) . Depending on what that particular bus is doing, the rates can vary, but the "generic" canbus is usually 500kbps.

                        The diagnostic connector itself is part of the OBD2 standard. CAN high and low lines were incorporated into the pinouts as part of the standard for ease of communication, but they are NOT mutually exclusive for all canbuses used in vehicles. Think of the canbus high/low lines made available in all OBD2 connectors as "generic" intended for providing diagnostic information, but canbus was intended to be greater than that. Manufacturers have additional proprietary pins within the OBD2 connector they can utilise to connect to other canbus systems not functioning on the "generic" high speed bus. Think more control systems, like lighting, immobilisation, incar entertainment, door and window controls, etc, plus anything they want to keep to themselves, often including safety data, abs, etc. If you look up the pin outs of an OBD2 connector you'll usually see a bunch of pins not used/included. These are the proprietary channels manufacturers may utilise to connect to their own systems.

                        Since the late 2000's canbus has been adopted as the standard for OBD2 communications on all vehicles, so the older protocols used by different manufacturers as part of the original standard have been phased out and data is most widely transmitted over canbus now. Hope the above helps a little to work out where you stand with OBD2 and canbus.


                        Originally posted by Aaron View Post
                        OBD2 on Canbus is slow. But the stack of other protocols that manufacturers use are quite quick and the wiring is far less finicky than it was 25 years ago.

                        Don’t drop in a bunch of extra trailer wire type of patching and you can pretty much do anything, But if you’re going permanent install a shielded twisted pair won’t hurt and is able to be neatly piggy backed from the factory diagnostic connector. You can of course just do a twist of regally light gauge auto cable but that tends to be shit looking unless tied in with other wires in a neat loom or only going a very short distance.
                        The other protocols you are talking about are actually slower than high speed canbus and are virtually redundant on anything made after about 2005. What do you think is making canbus communication via an OBD2 port slow though? You're connecting direct to a high speed canbus. The problem can come when you use common bluetooth devices to connect to canbus on high speed networks like what is typically used for broadcasting things like critical safety systems, engine values, instruments, etc. Lots of frequent, high speed data being sent.

                        The problem isn't specifically with bluetooth, but more the device connected to it and what controller it uses. A whole heap of dongles use ELM327 controllers, or chinese copies anyway, and they aren't all equal in how powerful they are. They are functioning as a node to sniff data. More data being sent, more values they are reading, the latency goes up for each parameter you request and you may see some lag appearing when monitoring things like engine speeds. This is largely due to the sheer amount of data being sent along the bus even when a node isn't actually sending or receiving data. All nodes connected to the bus continue to send out status information even if the module is effectively doing nothing. They read each packet and check the frame ID and request information and either accept the data or ignore it too, so your connected device is doing the same thing and some external devices are just too slow to keep up properly. Better, known genuine brands, the less problems you tend to have.

                        As far as the data, OBD2 data is pretty simple because it was intended for diagnostics. You have an identifier and the data in every message. The ID is just a simple request / respond tag. The message of each frame is made up of packet information, mode value to indicate what type of request, along with these things you have already found called PID's. The PID's are standardised ID values for a host of outputs, like, there is literally a defined table full of them as part of the standard. So if your device is displaying information via OBD2 data, it'll be broadcasting request messages and receiving data packets where it is reading these stored PID's and converting the hex data in the message part of the frame into the value to display on the device. You may be using canbus instead of one of the other protocols to request PID information on your device, but it has to request each one of those parameters one at a time, then process the hex data to display, this is why they are warning you about the refresh rate. Set it too high and all the processing power of the device will be used up on that one parameter and you'll experience lag processing the other requests as it can't generate request messages and process the data quick enough.

                        Part of the problem also comes from the devices programming, it's configured with delay value between message requests to allow the device to process the data without being overloaded, but they also usually have a timeout value before receiving new data. Kinda works like bandwidth control, the lower the value the quicker it communicates with the gateway, but it can result in bit errors and packet loss. Higher the value, the slower the communication, but more stable. In external readers these values are adjustable and you can perform some tweaking to help any lag. Something like a dash, you may be at the mercy of their programmed firmware.
                        Last edited by Madhatr; 18-05-20, 01:30 AM.
                        Originally posted by Buford T. Justice
                        This happens every time one of these floozies starts poontangin' around with those show folk fags.

                        Comment


                          #13
                          and ^^^^^ that i why i love this place
                          Mit freundlichen Gre

                          Originally posted by Keith Duckworth
                          "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

                          Comment


                            #14
                            Originally posted by Madhatr View Post
                            Depending on what that particular bus is doing, the rates can vary, but the "generic" canbus is usually 500kbps.

                            Part of the problem also comes from the devices programming, it's configured with delay value between message requests to allow the device to process the data without being overloaded, but they also usually have a timeout value before receiving new data. Kinda works like bandwidth control,.
                            I finished a project last month getting air compressors and dryers using CANBUS, encapsulated into Modbus so it can talk to a WinCC HMI in a control room. Timing, as mentioned by MadHatr is critically important.

                            I swear the last thing I was expecting was to see CANBUS on a PCN.

                            Comment


                              #15
                              It's only control system data the hmi is processing isn't it? On/off, maybe a few sensor values? was it a cheaper way to get around updating a PLC, was it ancient or something?
                              Last edited by Madhatr; 25-05-20, 10:43 PM.
                              Originally posted by Buford T. Justice
                              This happens every time one of these floozies starts poontangin' around with those show folk fags.

                              Comment

                              Working...
                              X