Jump to content

Goingnowherefast

Members
  • Posts

    6
  • Joined

  • Last visited

Everything posted by Goingnowherefast

  1. Epic stuff. Thanks for the reply. All makes perfect sense, and I think I have both multiplexers set up now. However, I don't have an ECU on-hand yet so I'm working to acquire one so I can actually take some CAN logs to ensure it's outputting what I want. Thanks again for the help.
  2. Not sure if this is a hardware limitation or a somewhere limitation, but I would really like to see more than 8 GP Outputs in the future as well as increased virtual channels.
  3. Absolutely. Here's what I'm envisioning for the inclusion and overall enhancement of .DBC integration and CAN transmit/receive streams. In my project, I'm effectively integrating all the OEM controls into Link. I've created a basic example where I'm sending engine speed to the OEM gauge cluster. To do this under the current setup, you have to create a stream, create a frame, manually select the parameter tied to it, then add all the scaling, factor, offset, position etc. Obviously, all this information is embedded in the .dbc's format and can be found (for example) by opening a .dbc in Notepad++ or a legitimate .dbc editor like Vector's CANdb++ editor (example below): In my eyes, it'd be great if we could import a .dbc and have each message & signal go to a folder under CAN in the "ECU Settings" menu. Then, using the existing CAN setup we'd select the Message ID which would import all the relevant signals into a CAN stream. Then you'd parameterize "DME_RPM" (in this example) with the PCLink's "Engine Speed" parameter. Done. That would definitely make a huge difference in the level of work I'm trying to accomplish with Link (basically a full ECU replacement w/ OE CANbus functionality). Another great feature would be the easy ability to inject CAN messages with user supplied "raw" data. I know this is possible through the use of math blocks, but it's very clunky. Something like this, would be an epic feature: Basically, you choose the message ID, when it would send (so on ignition on etc.), the cycle time, and than you'd choose the raw data to send in hex format for each byte.
  4. Wow, Thanks Adam. This is honestly epic feedback. Having dealt with ~5+ other standalones at this point I can say that at least anecdotally, Link's support has been absolutely top notch. Answers/details in red. 1. Yep, in this case it's just a frame counter. I thought there was a CRC in another message, but upon further review of the CAN trace it looks like it's just a counter also. I've attached the CAN trace of both "Count1" and "Mux1" which will paint a better picture of how the two interact and what I'm looking to emulate. To recap: When "Count1" = 0, "Mux1" = 0 When "Count1" = 1, "Mux1" = 0 When "Count1" = 2, "Mux1" = 0 When "Count1" = 0, "Mux1" = 0x25 (37 in decimal) 2. Hopefully this was answered in #1. To expand a bit more on this platform, Porsche shares the controls and most modules between the 987 Boxster/987 Cayman/997 911/997 Turbo S etc. In order for PSM to function correctly (as well as mitigate any CANbus errors from each module) the values sent on "Mux2" must match what the controllers are looking for as far as model code, transmission code, engine code etc. Mux2 is a bit more complex, so maybe it's better to talk about that over email or the phone. There's also a good bit of proprietary information concerning the table I've created with all the models/transmissions/options etc.
  5. The latter would be a complete game-changer. This would really enhance Links capabilities above many others.
  6. Hey guys, As this is my first post I'll do a brief introduction. My name is Will and I'm doing a complete reverse engineering and CAN controls integration on the Porsche 987/997 platform. We're actually sponsored by Link and most of the controls are already sorted and working like OEM. There's two signals that I want to send out that change depending on the cycle. Those are: 1. CRC Rolling counter - this counter goes from 1 -> 2 -> 3 at a rate of 25 Hz while the actual CAN message refreshes at 100 Hz. Meaning, I have to update the counter once every 4 messages cycles. 2. Mux (Multiplexer) - this is a bit more complex. However, I'm lucky enough to have access to a standalone car that is already running an OE aftermarket ECU and everything works (mostly). This has to cycle from 0 -> 37 (physical). 0 when CRC is 1 or 2, 37 when counter is 3. Has anyone accomplished something similar? Let me know how you did it. Otherwise, I'll keep digging and update the post if I figure it out. Thanks, -Will
×
×
  • Create New...