ThatDamnRanga
-
Posts
10 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Blogs
Posts posted by ThatDamnRanga
-
-
Attached. This is post rebooting both ECU and PCLink
PC Datalog - 2021-07-2 8;55;24 am.llgx Subaru Impreza GD or GG H6 Turbo.pclx
-
I was doing some CAN config diagnostics and noticed something... odd. Cruise Set Speed is 40kph, from the very second CAN message after the ECU starts up.
I have validated this in PCLink
The ECU is yet to be installed in the vehicle, so cruise is definitely neither enabled, nor set. This should be a value of either 0 or 0xFF as a result.
The CAN data is reading the exact same as PCLink in this case so I haven't posted the log.
Does this have any significance (other than confusing my custom dash readout)?
Changing cruise minimum down to 10kph does not change the value.
Running latest firmware.
-
While the current set of codes is great, it'd be nice to be able to output 'standard' P codes for faults, so that when less technically savvy end users (not tuners) plug in their ebay scan box, it spits out something intelligible. Also a 'standard form' limp mode such as OE EMS implements. Certain codes just set the CEL and allow people to carry on their day, while others make driving unpleasant so you don't get 'MY CEL WAS ON AND MY ENGINE BLEW UP BUT ITS THE TUNERS FAULT' as often.
-
I know I'm a notorious moaner when it comes to CANBus, but given my frustrations I've begun development of what would effectively be a configurable translator module to allow Link ECUs to operate in vehicles that are heavily dependant on CANBUS (my GT86, the above RX8 etc)...
Unfortunately that comes with a feature request, as currently both the ECU and the translator module find themselves having to waste considerable numbers of I/O pins on functions which would ordinarily be transmitted over CAN. Note that I'm not asking for improvements in the CAN environment to enable direct OEM integration. As I appreciate that's a lot more work, and simply not on the roadmap.
What I'd like to see is a number of 'Virtual I/O' pins which can be assigned to any function as if they were physical pins. So a pin like 'CAN DI #1' would have a page like 'DI 4' does. Giving me the ability to assign a Start Switch, Traction Control Switch or GP Input for Map Switching. Virtual analogue in might be more difficult, but it would be helpful in situations where the CAN bus presents an input with a linear value (torque reduction request, etc)
And the same kinda thing for the outputs. This would save Link engineers from having to create specific code to make things like Cruise Control indicators work over CAN. You could simply assign them to a virtual output.
-
On 4/14/2019 at 8:41 PM, Adamw said:
I've done a few modern cars and havent found the 6 ID's to be much of a limitation yet. You can always connect the 2nd CAN port to the same bus to get 12 ID's. The user CAN was not really designed to allow OEM integration, even though you can usually get pretty acceptable integration in most cases. It is more designed to allow communication with other 3rd party motorsport devices. The bigger limitation that you will find when trying to achieve full OEM integration is the advanced math that is usually needed - checksums, counters or heart beats with odd increments, odometer ticks, immobiliser decryption etc. Usually to do this more advanced stuff we would have to write it into the firmware as a predefined stream.
If it is a relatively common car and you have a complete record of all messages and what is required I can probably get it added to the firmware.
The vehicle in question is a Toyota GT86 aka Subaru BRZ. I believe I have all the CAN data (6 messages) necessary for the operation of a key-start vehicle, thanks to a bunch of people including Tiz in this thread. It's the push-button start vehicles that use a couple of extra messages I have yet to decode. There's probably one or two more 'nice to have' messages that contain things like CEL, Traction Control lights and Cruise Control indicators that I also need to track down.
-
On 4/11/2019 at 2:40 PM, Adamw said:
You are describing sequential messaging which is where you assign a base ID and the following frames assume ID's incremented from that. Unfortunately there is no industry standard for that "sequential increment" so our ECU's dont do sequential in this way - to give the best compatibility with a wide range of systems we make you assign each frame its own ID for this type of message. As you say Emtron use an increment of Decimal 1, but Pectel use an increment of 0x8 or 0x10Hex, others use 0x1Hex etc. The reason our CAN setup allows multiple frames to be assigned to an ID is for compound or multiplexed messages - this is where some bits or bytes in the frame are used as an index.
Unfortunately this drastically limits the number of frames we can work with, as there are only six streams available, at one frame each. Basically meaning you have two options for vehicles which utilise more than six frames: a third party CAN-to-IO/CAN-to-CAN adapter, or go with someone else's product?
-
Not the Vehicle OEM in this case. Aftermarket ECU vendors, first one that springs to mind is Emtron, do this. After all, what other possible purpose could there be for allowing multiple frames to be defined on a single stream? Two different messages with the same message ID would be... Bad.
-
Huge thanks to Tiz for the headstart.
I've taken the data and made some corrections based on the known format of the Can messages used in these cars. Also reduced the number of needed channels to four, leaving two spare. (This is based on an untested assumption that each frame added to a stream increments the transmitted or received ID by one (so on a stream with ID 354, Frame 1 would be 354, Frame 2 would be 355, etc.) as this is how other vendors do things.
I'm left with one limitation. At present the G4+ cannot take a starter request via CAN. Am I missing something? As I can assign an attribute to a CAN DI#, but I can't then do anything with that input. I'd be super keen if I could configure CAN DI#s the same way as normal DI#s (though it would probably require an additional value to set momentary/toggle)
Cruise Set Speed - 40kph on startup
in G4x
Posted
Correct, yeah the module that will handle those signals hasn't been designed or built yet. The other thing I find kinda... strange? Is that I'm sending the lights as a single bit as per Subaru standards, but the ECM uses 0 for off, 1 for active, and >1 for fault conditions. I'm slightly concerned weirdness might happen if the state is >1 on those bits depending on how your software implements it.