CANBus controller?

[V8Z4]

Is there some "module" out there that can take regular automotive digital/analog signals and convert them to BMW CANBus signals?

[modular93fox]

dont think so.. simple solution is just make the BMW DME a stand alone and retrofit the requird sensors to the LS engine.
clint

[bimerok]

Is there some "module" out there that can take regular automotive digital/analog signals and convert them to BMW CANBus signals?

No. Nothing concrete that that floated through here.

dont think so.. simple solution is just make the BMW DME a stand alone and retrofit the requird sensors to the LS engine.
clint

I wouldn't call it simple solution, but more of a possible solution.

[V8Z4]

dont think so.. simple solution is just make the BMW DME a stand alone and retrofit the requird sensors to the LS engine.
clint

Yeah..... I have been working on that but it's not going to be "simple" by any means. I currently have the air pump, evap, and rear O2s worked out. The fun now comes trying to emulate the electronic TB/MAF/Cam sensors/etc.....

[Pzary3233]

Bikealarmblair got it to work with the BMW DME... check out his LSx build thread.

[James39]

I'm going to play around with one of these for can-bus hacking:

http://www.gadgetgangster.com/news/54-new-projects/556

[Tongboy]

I"ve got a number of CAN converters sitting in my garage that have analogue inputs of varying kinds. they all take actual programming (like C++ or a few microcontroller langauges) and are far from being user-friendly.

I know a few companies have showcased some CAN controllers that are semi-user friendly but as there isn't anything other than a protocol standard for CAN getting stuff to work from one manufacturer to another is difficult. Forget the fact that all the high end euro cars have gone to MOSbus or similar and we aren't too likely to see any user-friendly CAN controllers. Best to make friends with an embedded systems programmer.

[modular93fox]

Yeah..... I have been working on that but it's not going to be "simple" by any means. I currently have the air pump, evap, and rear O2s worked out. The fun now comes trying to emulate the electronic TB/MAF/Cam sensors/etc.....

why do you need all of that other non sense stuff... just use rpm sensor and temp sensor. leave the rest out. move that obd port out of the way, install new for lsx, recode lsx with new vin for bmw.. exactly what im going to do when it comes to tuning the ls1
clint

you will have a check engine light on but you can cover it up, and then run led inplace and have the ls1 pcm operate the led.

[Pzary3233]

I do not think it is that easy...

In order to get everything working in a CANBUS car you've got to simulate the BMW DME or make the LS PCM talk with the BMW stuff... That is where the converters come into play. BTW, there is no RPM sensor, the PCM uses the crank and cam position sensor to calculate RPM, in an e36 you just program the LS1 computer properly and it works, with the canbus cars you've gotta fake it somehow... RAO is the man when it comes to this stuff.

[Jesus Freak]

My e39 got its tach and temp through canbus, I was able to program the tach in the cluster to work perfect. The temp would work if I hooked it up

[James39]

The temp would work if I hooked it up

How do you know, if you haven't hooked it up?

[Jesus Freak]

How do you know, if you haven't hooked it up?

Good point... The world may never know..

[modular93fox]

BTW, there is no RPM sensor, the PCM uses the crank and cam position sensor to calculate RPM, in an e36

wow, I cant believe I typed RPM sensor.. feel retarded... I ment the crank sensor and have a sensor wheel fitted to the balancer or something of that nature..... lol.I did not know the e36 uses both cam and crank for rpm..

[V8Z4]

why do you need all of that other non sense stuff... just use rpm sensor and temp sensor. leave the rest out. move that obd port out of the way, install new for lsx, recode lsx with new vin for bmw.. exactly what im going to do when it comes to tuning the ls1
clint

you will have a check engine light on but you can cover it up, and then run led inplace and have the ls1 pcm operate the led.

I thought about that (my fall back positions). I just was not 100% sure that would work (for emissions).

wow, I cant believe I typed RPM sensor.. feel retarded... I ment the crank sensor and have a sensor wheel fitted to the balancer or something of that nature..... lol.I did not know the e36 uses both cam and crank for rpm..

Planed on either mounting a 48x crank wheel off the balancer, OR preferably make myself a simple programmable IC circuit to take the LS1 24x signal and multiply it by 2 (trying to be slick her ).

So does the e46 use both the cam and crank sensors for RPM calculation? That seems kind of....well... retarded. Crank sensor would be the most logical solution to RPM signal for a car.

[modular93fox]

So does the e46 use both the cam and crank sensors for RPM calculation? That seems kind of....well... retarded. Crank sensor would be the most logical solution to RPM signal for a car.

theres one member here that has done it, cant remember the link or member, but it was a slick install, blue e46 and he simply made a reluctor wheel and fitted it to the balancer.
clint

edit:
found thread in which made me buy my first BMW, 2000 323 and followed by this sub forum lead me to buy my 2nd BMW 1999 528 all for swappin kick ass engines into.
http://forums.bimmerforums.com/forum....php?t=1673679

[hoveringuy]

This is on my "to do" list, maybe this winter.

-Need a CANBUS analyzer to get a good understanding of what the stock signals are that fly around.

-I have an extra cluster, I'd like to be able to drive the functions (RPM, temp, etc) based on analog inputs that I generate

-Finally, feed LS signals into converter to create the CANBUS signals.

Has anyone broken-down the signals yet?

[Thaniel]

Planed on either mounting a 48x crank wheel off the balancer, OR preferably make myself a simple programmable IC circuit to take the LS1 24x signal and multiply it by 2 (trying to be slick her ).

I've been playing with a micro controller that I programmed to take a signal similar to the LS1 Tach output and similuate the 60-2 BMW crank signal to feed the BMW ECU and therefore the BMW E46 tach. Looks like in Theory it would work. Yes mounting a crank sensor and wheel to the LS1 would do the same thing but a simple "black box" adder seemed like the win for me. While I was playing with the programming made it mimic the cam sensor output too.

Just starting to look into Can bus programming. Just recieved some hardware this week.

[Thaniel]

they all take actual programming (like C++ or a few microcontroller langauges) and are far from being user-friendly.

The programming is the fun part. I've even got my son into programing the microcontrollers we bought.

Has anyone broken-down the signals yet?

I'm going to try to get a sample of the data to try and sort it out. Some guys smarter than me have said it shouldn't be that difficult to decode. I have just puchased a board that samples the can bus signals and yet ANOTHER microcontroller that goes with it. I'll see if I can get it hooked up to the E46 and get something to look at. Not making promises as I'm not familiar with the hardware I bought yet.

[bimerok]

I like where this is going.

[Tongboy]

I have a number of different canbus samplers/analyzers and programmers i'd let go for a song compared to what I paid for them if anyone wants to tackle it, i'd like to see something come of it but I don't have the motivation/time to do it myself.

[V8Z4]

I'd be more than willing to give it a shot. I just don't know where to start (which modules to start with) as it's all so new to me.

I have done a fair bit of Java and C++ coding back in the day, so I'm not really worried about that side of it.

I've been playing with a micro controller that I programmed to take a signal similar to the LS1 Tach output and similuate the 60-2 BMW crank signal to feed the BMW ECU and therefore the BMW E46 tach. Looks like in Theory it would work. Yes mounting a crank sensor and wheel to the LS1 would do the same thing but a simple "black box" adder seemed like the win for me. While I was playing with the programming made it mimic the cam sensor output too.

Just starting to look into Can bus programming. Just recieved some hardware this week.

What micro controller did you use as your basis?

It always seemed to me that this would be a relatively simple thing to accomplish.

My thought was to take the 24x pulses in, convert to RPM, then multiply RPM by 60-2 (58 pulses and 2 "dead" pulses). Then take that same crankshaft RPM and convert to cam RPM (CrankRPM/2=CamRPM) and then pulse CamRPM once per "revolution".

Is that how you went about it?

Did you attempt to make an "adjustment" for the VANOS activation? I have been tossing this around in my head as to whether or not the computer cared about that. I could see it both ways. Certainly the computer can read TDC intake/exhaust 1 reference on cams with relationship to the crank position (by counting its way around the crank wheel. But does it care? I'd THINK it does as this would be another "error check" to ensure the VANOS are working.

[hoveringuy]

Getting the standard package format isn't too hard.

The trick is getting packet ID for the different data payloads and then deciphering the data format for each payload. It will take a small amount of clever statistical analysis to correlate things and then it's easy.

There are commercial products that already do this so I know it can be done!

[James39]

There's some interesting stuff in the source code of that project I linked to:

TempCode     BYTE $04
                        BYTE $80, $00, $BF, $19

           RPMCode      BYTE $04
                        BYTE $80, $00, $BF, $18

           OdometerReq  BYTE $44, $03, $80, $16 

PUB RPMs :RPM | i
repeat i from 1 to BYTE[@RPMCode][0]
  if (BYTE[@RPMCode][i] == inputbuffer[i-1]) OR (BYTE[@RPMCode][i] == 0)
    RPM := 1   
  else
    RPM := -1
    Return RPM 


PUB sendcode(codeptr) | i, codelen, checksum
''Send the code stored as Hex at the location given by codeptr, Checksum is automatically calculated
''

checksum := 0
codelen := byte[codeptr+1] <#  32

'Contention check
repeat until pst.rxtime(ContentionMS) == -1  
  
repeat i from 0 to codelen
  pst.tx(byte[codeptr+i])
  checksum ^= byte[codeptr+i]
pst.tx(checksum)

PUB waitforcode | inbyte, inputindex 

repeat
  inbyte := pst.rxtime(1)   'Wait for quiet on line to avoid grabbing half a code
  IF inbyte < 0            'We've found quiet
    repeat                    'Loop until we find a transmission
      inbyte := pst.rxtime(5)
      IF inbyte > -1
        inputbuffer[0] := inbyte
        inputbuffer[1] := pst.rxtime(10)  <#  32              'In case we grab a code mid-transmit, limit the length to 32 bytes
        repeat inputindex from 2 to inputbuffer[1]+1          
          inputbuffer[inputindex] := pst.rxtime(10)           'or 1.6 seconds 
        return TRUE

[Thaniel]

What micro controller did you use as your basis?

The chip I used for my "engine simulator" was a "propeller chip" from Parallax. The chips themselves are pretty cheap so thought if I could get it figured out it would be cheap to replicate (also have a basic stamp from them as well).

It always seemed to me that this would be a relatively simple thing to accomplish.

Yes the electronics behind it is pretty basic. I'm not an expert but it's not rocket science.

My thought was to take the 24x pulses in, convert to RPM, then multiply RPM by 60-2 (58 pulses and 2 "dead" pulses). Then take that same crankshaft RPM and convert to cam RPM (CrankRPM/2=CamRPM) and then pulse CamRPM once per "revolution".

Is that how you went about it?

The propeller chip is a muli core so can do more or less "multi tasking" which we found handy so that the sensing the LS1 tach input didn't slow down the RPM output. If I remember right (we tried lots of scenarios) we set it up to measure the pulse spacing of the incomming pulses. (The incoming pulses were set up to be at the same pulse rate of the LS1 tach output.) Then pass the pulse spacing to another Core which used that to caluculate the right pulse spacing output to similuate the crank sensor. That output would simply output to 58 pulses then wait two pulses then start over (2 for-next loops). To be honest I can't remember what logic I used on the Cam signals but I remember I thought it was clever. Perhaps in a few weeks when I have access to the computer with that stuff on it I could share what I've written.

Did you attempt to make an "adjustment" for the VANOS activation? I have been tossing this around in my head as to whether or not the computer cared about that. I could see it both ways. Certainly the computer can read TDC intake/exhaust 1 reference on cams with relationship to the crank position (by counting its way around the crank wheel. But does it care? I'd THINK it does as this would be another "error check" to ensure the VANOS are working.

I had started looking at it but haven't programmed anything. Just have to sense the frequency of the Vanos activation and then make adjustments to the pulse phasing. But not sure of the value. From what I understand the Crank signal is only thing needed to make the tach read. The cam signal will just throw an error in the BMW ecu along with many other things no longer in the car. Thought of mimicing them all but in reality it's diminishing returns.

I'd be happy to work with anyone on the project but I won't have access to my cars (again) between August 15th 2012 and July 1 2013 so I am stuck with bench testing and can't test real world results. So I'll also dabble with can bus a bit and see how far that goes.

[hoveringuy]

So what I'm gathering is that there's two ways to tackle this: use the stock ECU to drive the cluster, but then you need to generate the proper signals and simulate everything else to keep it from throwing a ton of codes

*OR*

delete stock ECU and drive the CANBUS directly with a standalone device.

Is that correct?

What are the downsides to driving the cluster directly? Traction? Stability? etc..