When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
I can't keep track, do either of you have the yaw sensor working? And do you have an active error for the pressure imbalance? I'm trying to narrow down on what helps avoid the situation and deicide if I'm going to maintain the Miata brake balance or recreate the BMW brake balance to avoid the error code that doesn't seem to affect anything.
i have the yaw sensor hooked up and i believe the mk60 sees it based on checking it in the software. i will have to check for pressure errors. on a side note, do you think it's possible to get the yaw data from the mk60 via canbus? i want to do some active aero and that would keep me from having to have a redundant sensor.
My yaw sensor works and I do not have the pressure imbalance error any longer after setting the F/R bias within the pressure window mentioned earlier in the thread as observed in INPA. The system has been flawless for me so far.
I saw above mentioned using the wheel speeds over the CAN bus for traction control instead of the hardware outputs at the connector. Keep in mind the outputs at the connector are 10 times faster than the CAN bus wheel speed rate, Thus the hardware output is the preferred method for traction control.
I saw above mentioned using the wheel speeds over the CAN bus for traction control instead of the hardware outputs at the connector. Keep in mind the outputs at the connector are 10 times faster than the CAN bus wheel speed rate, Thus the hardware output is the preferred method for traction control.
Do you know what the data rate is exactly? I ask because I'm pretty sure BMW used the wheel speeds via can for TC
I saw above mentioned using the wheel speeds over the CAN bus for traction control instead of the hardware outputs at the connector. Keep in mind the outputs at the connector are 10 times faster than the CAN bus wheel speed rate, Thus the hardware output is the preferred method for traction control.
When you say 10 times faster, are you saying that the sample rate eventually can’t keep up at a certain speed, or the data transmission would lag and the speed output wouldnt represent the current speed? Do you know what speed it would be good to in the first case? Sorry if I’m not wording this right, I’m not good with serial stuff. I only need traction control up to about 70-80mph in most cases so I can just simply shut it off after that.
Less than a millisecond response time on the output at the connector. So it is probably even more than 10 times faster. IIRC those channels on the CAN bus are at 100Hz on the Mk60E5 and probably (not 100% sure) 50Hz on the Mk60
Less than a millisecond response time on the output at the connector. So it is probably even more than 10 times faster. IIRC those channels on the CAN bus are at 100Hz on the Mk60E5 and probably (not 100% sure) 50Hz on the Mk60
I ask because I'm pretty sure BMW used the wheel speeds via can for TC
The firmware (i.e. what you have flashed in) of some of these Teves ABS units does the traction control for acceleration itself. What the ABS unit does over the CAN bus is to tell the ECU how much torque it wants from the engine at every moment it is running TC.
The wheel speeds outputs over the CAN bus are mostly for logging/display. That's how it is in the race cars. It is probably the same with all BMW TC.
that's pretty easy; in the onTick() you would do an rxCAN() and when the ID matches, then branch to do the rest of the things
[7:01 PM]
what ID is the RTR?
Xzelicon — 11/13/2021
Also 0x610
brentpicasso — 11/13/2021
and the message contents don't matter?
Xzelicon — 11/13/2021
The reply needs to be the correct vin on 0x610
[7:02 PM]
And some basic info on the other channels as described
[7:02 PM]
Basic info is the same for all units
brentpicasso — 11/13/2021
I mean the message from the MK60 - the payload doesn't matter?
[7:06 PM]
The next thing to check is if just bogus data (e.g. 0's ) can be sent just one time on 0x316,0x329, 0x613 and 0x615
Xzelicon — 11/13/2021
No I don't think so, my canbus software identifies it as an RTR message so I can't see the content. Its a few days ago I was busy with this so I need to fact check but I think the RTR message was sent 5 times on 1hz and after that 0x610 goes inactive if not received the handshake
@brentpicasso
The next thing to check is if just bogus data (e.g. 0's ) can be sent just one time on 0x316,0x329, 0x613 and 0x615
Xzelicon — 11/13/2021
I can check that out, but I'm almost sure it can be sent just one time
brentpicasso — 11/13/2021
Confirming that would make for an exceedingly simple Lua script to activate the module
[7:07 PM]
Are there commercial products that do this same thing?
@brentpicasso
Are there commercial products that do this same thing?
Xzelicon — 11/13/2021
Nope
brentpicasso — 11/13/2021
Ah. in any case, RC would provide it for free
Xzelicon — 11/13/2021
There are emulators but they require the steering angle sensor so for sure they just figured out how to transmit a reset message
[7:08 PM]
Since the unit also starts streaming after a fault reset, without needing any more data
[7:09 PM]
But you would need to do that every ignition cycle
@brentpicasso
Confirming that would make for an exceedingly simple Lua script to activate the module
Xzelicon — 11/13/2021
I will confirm this later next week
[7:15 PM]
Off to bed now, 1AM here. If you have any questions just shoot and I will.reply later
@Xzelicon
I will confirm this later next week
brentpicasso — 11/13/2021
Here's a script I wrote blindly (no RC nearby) that might do the init:
Code:
function txCANBlank(bus, id)
txCAN(bus, id, 0, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00})
sleep(5)
end
function checkMK60Init()
local canId, ext, data = rxCAN(0)
-- exit early if not an RTR message
if canId ~= 0x610 then return end
-- replace with the last 7 digits of the VIN (where does it show up in the 8 byte CAN frame?)
txCAN(0, 0x610, 0, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00})
-- might need to wait some time for the MK60 to receive the init msg
sleep(10)
-- one time send of dummy ECU data
txCANBlank(0, 0x316)
txCANBlank(0, 0x329)
txCANBlank(0, 0x613)
txCANBlank(0, 0x615)
end
function onTick()
checkMK60Init()
end
(edited)
@brentpicasso
Here's a script I wrote blindly (no RC nearby) that might do the init:
Code:
function txCANBlank(bus, id) txCAN(bus, id, 0, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}) sleep(5) end function checkMK60Init() local canId, ext, data = rxCAN(0) -- exit early if not an RTR message if canId ~= 0x610 then return end -- replace with the last 7 digits of the VIN (where does it show up in the 8 byte CAN frame?) txCAN(0, 0x610, 0, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}) -- might need to wait some time for the MK60 to receive the init msg sleep(10) -- one time send of dummy ECU data txCANBlank(0, 0x316) txCANBlank(0, 0x329) txCANBlank(0, 0x613) txCANBlank(0, 0x615) end function onTick() checkMK60Init() end
(edited)
Xzelicon — Yesterday at 3:46 AM
No it needs some specific bytes in the dummy channels. Blank messages / giving them all the same data won't be sufficient
Xzelicon
0x610 contains the last 7 digits of the vin number in the ECU. -B0 as is but drop the last zero and it is the last number in the vin -B1 as is (in hex) the 3rd and 2nd number from the end in the vin -B2 as is (in hex) the 5th and 4th number from the end in the vin -B3 in ASCII the 6th from the end in the vin -B4 in ASCII the 7th from the end in the vin -B5 0 -B6 0 -B7 0 As in the screenshot B4 = 50 = P B3 = 50 = P B2 = 87 = 87 B1 = 58 = 58 B0 = 80 Drop zero = 8 Vin = PP87588
Xzelicon — Yesterday at 3:46 AM
Vin data is here
@Xzelicon
Vin data is here
brentpicasso — Yesterday at 3:12 PM
Feel free to use the script as a starting point
I was finally able to get the canbus to start sending out. Using all zeros in the dummy data only kept it running for about 20ms. I found that discord page, found the dummy data in that picture posted. It all seems to be working. I also did a test and changed some values in the vin on 610h and it still worked fine so exact vin is not neccessary. The dummy data on 316h, 329h, 613h, and 615h is all that mattered with some vinlike number on 610h. I did the dummy data at 10ms/100hz and the 610h at 1000ms/1hz. Not sure how important it was but it worked.
I was finally able to get the canbus to start sending out. Using all zeros in the dummy data only kept it running for about 20ms. I found that discord page, found the dummy data in that picture posted. It all seems to be working. I also did a test and changed some values in the vin on 610h and it still worked fine so exact vin is not neccessary. The dummy data on 316h, 329h, 613h, and 615h is all that mattered with some vinlike number on 610h. I did the dummy data at 10ms/100hz and the 610h at 1000ms/1hz. Not sure how important it was but it worked.
That's great, I guess you can confirm the data update frequency is still too low to do anything like TC right?
That's great, I guess you can confirm the data update frequency is still too low to do anything like TC right?
The data comes in on the bus at 7ms which is the fastest I've seen any data come through a canbus in my Nissan/BMW experience. That isn't to say that the wheel speeds are being output at that speed, but I can't see any reason it wouldn't be. I don't know what would be required from a system to have a quality TC, but I do know 350z/370z only source of wheel speed, the address is broadcasted at 20ms. I wouldn't necessarily call Nissan traction control anything to brag about though for any performance orientated help.
The data comes in on the bus at 7ms which is the fastest I've seen any data come through a canbus in my Nissan/BMW experience. That isn't to say that the wheel speeds are being output at that speed, but I can't see any reason it wouldn't be. I don't know what would be required from a system to have a quality TC, but I do know 350z/370z only source of wheel speed, the address is broadcasted at 20ms. I wouldn't necessarily call Nissan traction control anything to brag about though for any performance orientated help.
OEM TC is generally designed to be safe, not to maximize performance, so I don't know that the 20ms is the limiting factor here.
At 7200 RPM a 4-stroke 4-cylinder will see an ignition event every 4ms. To be as good as possible, you'd probably want to see 2 or 3 wheel speeds inside that interval, so getting them at 10ms is probably not quite as fast as you'd like. How much that actually matters though, I don't know.
Dumb question.......does the unit require two 30 amp feeds for a total of 60amps or is there just two wires ran to a single fuse?
IIRC from my look at the OE wiring diagrams, it actually goes to two 30A fuses. I’m not sure if it’d ever draw 60A, that’s a hell of a lot, but my install was with two wires and two 30A fuses.
I was finally able to get the canbus to start sending out. Using all zeros in the dummy data only kept it running for about 20ms. I found that discord page, found the dummy data in that picture posted. It all seems to be working. I also did a test and changed some values in the vin on 610h and it still worked fine so exact vin is not neccessary. The dummy data on 316h, 329h, 613h, and 615h is all that mattered with some vinlike number on 610h. I did the dummy data at 10ms/100hz and the 610h at 1000ms/1hz. Not sure how important it was but it worked.
Do you still have the usual fault codes if you do this? Specifically the one related to steering angle sensor/LWS? If not, I would be concerned about potentially getting unintended stability control/ESC activations.
The spacers let the pump clear the shock tower and no welding required. The plate could use some refinement as I spun it up quickly, but the above is functional/i can upload the STL if someone wishes to do similar.
I thought it would be nice to tuck mine up under the dash out of the way...... except you have to run all the lines under the dash so it's a royal pain in the ***
11-15-2021, 01:38 PM
0
@brentpicasso
