My brain hurts. Nice job.

Using a logic analyzer it was determined that...

Do they have a model that will work on people too?

 

... Do they have a model that will work on people too?

"logic analyzer?"... I once hooked it up to my wife, it immediately blew the breaker. ;D

 

Wow, that's impressive. Over my head, but impressive. Awesome work, TeeRiver! A gear position indicator would be child's play for a whiz like you. (Hint, hint.....)

 

Thanks, I appreciate the kind feedback!

... A gear position indicator ... (Hint, hint.....)

Rock, one of these days I will post a thread on how to build this GPI. It's based on the same PIC chip and Radio Shack proto-board as the ECM build above, only different software and has a 7 segment LED attached.

Here is a close up photo. I tried to make the unit as small as possible so it can be mounted inside the SV gauge via a cutout through the tach face. This photo shows the entire unit, no separate power box, connects with just the three wires: Red (12v), Black(gnd), and Green(tap the SV's gear position sensor wire). At the moment, I'm searching for a 7seg LCD display instead of the power hungry LED to get the heat down. With no air circulation it gets a bit hot inside the gauge housing.

 

I don't have that kind of electronics smarts, but I find it fascinating to see what the people who do, can come up with. Nice work.

 

I vote for crafting and selling an adapter setup to hookup a second gen gauge cluster on a first gen!!!

 

Hey TeeRiver, I watched the video; yours works better than mine. :sbmfacepalm:

Mine shows false neutrals and the wrong gear, for a up to second or so, from time to time. I'm not sure what causes it. It's got an big LED display, probably too big, but it's very easy to read. An LCD would need a back light; no problem I'm sure.

About putting it in the speedo housing; that takes the mod from plug and play to a much higher level of difficulty. I would go for an outside mount, myself. Edited to add: combining this with a tre would be a good thing, IMO.

You sure seem to keep busy doing some great stuff!

 

Hey TeeRiver, I watched the video; yours works better than mine. :sbmfacepalm:

Mine shows false neutrals and the wrong gear, for a up to second or so, from time to time. I'm not sure what causes it. It's got an big LED display, probably too big, but it's very easy to read.

I had the same problems, Rock. There is a lot of noise on the signal from the gear position sensor. This makes it a challenge to accurately recognizing gear changes (and by challenge, I mean a major pain in the ass!). It took some tweaking and software tricks to get quick gear changes and make the false neutrals go away.

Do you remember the Cheap GPI Thread that never came to fruition? I believe they hit the same problems. A design can work beautifully on the bench, but once mounted on the bike, all hell may break loose. The devil is in the details!

Bighammer actually took the SV gear position sensor apart and exposed the individual gear contacts. It would use a few more wires, but a design based on that would be rock solid and fast. I think he should build it.

 

eagerly watching the results of all this

 

OK, with all of you ultra smart people on here it begs the question...

Why do I still need piggyback fuel management. Somebody needs to come up with a way to change the fuel tables in the stock ECU. Sounds like it would be an afternoon project for some of you.

 

... Why do I still need piggyback fuel management. Somebody needs to come up with a way to change the fuel tables in the stock ECU. Sounds like it would be an afternoon project for some of you.

Check this out ineedanap!
http://www.svrider.com/forum/showthread.php?t=140234

Can be purchased here. Probably pricy.
http://www.svrider.com/forum/showthread.php?t=125552

I think that you should build it ...

It's better to share; I shouldn't be the one having all the fun.

 

Regarding the GPI noise... Here's a thought:

The noise generated is most probably from the ignition coils. Have you tried enclosing your PIC within a EMC shielded casing and running the GPI switch through a Low Pass Filter (Simple LC-Filter maybe)?

I still need to test this, but it's just speculation.

 

Thanks for the input Wurmsous. The GPI is working well, no noise issues now, but it took some effort to make it function reliably.

You are right, the ignition is a major source of electrical noise and an LC filter helps knock that down to manageable level. A shielded enclosure was not necessary, but before getting things under control I was seriously thinking about it!

The biggest headache was noise from the gear position sensor itself. With the GPS mounted directly on the engine, there is a lot of physical vibration on the contacts. At high RPM the contacts spontaneously make and break causing voltage spikes. The spikes are worse in the low gears, and to compound the problem, the GPS resistor values make 1st and 2nd gear voltage thresholds very close.

It turns out there is enough nose at 1st gear position to exceed the 2nd gear threshold. The good thing though is this can be fixed in software.

 

UPDATE!

"CHEC" Eliminator now works with the GSXR gauge!

brle7817 and I were trying to get this to work with his GSXR gauge over in this thread, but ran into trouble. He was very generous and sent me a GSXR gauge to experiment with; after investigation, it turns out the data format between the SV650 and GSXR are the same, but there is a slight difference in data transmission time between the two bikes. SV650 has a message gap of 30mS, the GSXR needs the gap to be at least 60ms. Adjusting the message gap from 30mS to 60mS fixed the problem!

So with this little circuit (PIC micro-controller), anyone who want to mount a GSXR or gen2 SV650 gauge on a bike without an ECM can do so, complete with functional Temp display.

 

I was interested in this because I would like to run a GSXR gauge on my 07 SV650 to match the 08-09 GSXR 750 forks I just picked up.

Well, I was able to code up my own version of this for Arduino.

I will post the code and the info I found this weekend sometime.

Here is the temp being displayed:

I also tried out the tach:

I did have a little trouble with how to drive the tach. I wasn't exactly sure how to set up the code to drive it. So I just guessed and verified I could drive it.

 

Impressive!

Arduino never fails to surprise me.

 

I am loving seeing all of these arduino/pic projects

geeks me out. Can someone start an Arduino/RFID smart key project?

 

Didn't D'ecosse already make a smart key? Didn't use Arduino though.

 

Did he? I'll have to do a search.


Sent from my iPhone using Motorcycle.com App

 

Here is my code in case anyone wants to try it.

If anyone can suggest how to drive the Tach as far as the code portion that would help me. I am not sure if is a hardware issue or not, but I used a 200 ohm resistor between the output of the Arduino and the Tach line. I figured if I pulsed the output for 5ms on and then 5ms off it would run the Tach to 6,000 rpm, but it goes to like 6,625 and the error seems to follow RPM. So the lower the RPM the lower the error and the higher the rpm the higher the error.

int ecm_serial_byte[8];     // 8 bytes for serial data
byte check_sum;             // Check sum of bytes 0 to 6
int temp = 0;               // Temp number between 0 and 1023
int cycle_time = 5;         // Vary number to change RPM for Tach output

void setup() {
  Serial.begin(7800);       // Serial output to gauge Tech line
  pinMode(2, OUTPUT);       // For Tach output
}

void loop() {
  
  // Input various numbers to see temp output of gauge
  temp = 90;
  
  // Put temp reading into correct bytes
  ecm_serial_byte[0] = temp >> 2;
  ecm_serial_byte[1] = temp << 6;
  
  // Dealer Mode (Uncomment to turn on)
  // bitSet(ecm_serial_byte[1],4);
  
  // FI Code (Replace x with byte and y with bit interested in)
  // bitSet(ecm_serial_byte[x],y);
  
  // Calculate check sum byte  
  for(int x = 0; x < 7; x++){
    check_sum = check_sum + ecm_serial_byte[x];
  }
  
  check_sum = 256 - check_sum;
  
  // Write data bytes to serial
  for(int y = 0; y < 7; y++){
    Serial.write(ecm_serial_byte[y]);
    delay(10);
  }
  
  // Write check sum byte to serial
  Serial.write(check_sum);
  
  // Intermessage delay
  delay(30);
   
  // Tach Output Signal 50% DC
  digitalWrite(2,HIGH);
  delay(cycle_time);
  digitalWrite(2,LOW);
  delay(cycle_time);
    
}

 

That is excellent Bubba!

If anyone can suggest how to drive the Tach as far as the code portion that would help me.

The 200 ohm between Arduino output and Tach in is fine. The isolation resistor is not necessary when driving the tach on the bench, but is essential when connected to the motorcycle to keep the uC from resetting due to system noise; especially the huge spike generated when the starter solenoid is released.

The SV tach displays about 11% high, which explains why the 5mS high/5mS low code shows 6,625 rpm, so what you have is good. For fun, you might try connect a couple pots to the Arduino ADC inputs and use them to vary the tach and temp real time!

Nice job! :thumbsup:

 

I can't seem to figure out how to get the tach to vary smoothly.

I am able to get it to vary with a pot, but it jumps to values like there isn't enough resolution. And the resolution issue is worst at high rpm's.

So I scaled the whole pot movement to just try and get the upper rpms to be smooth, but it still jumps to values like my output numbers are coarse.

Tee, do you have any code I could look at for how you got the tach output to work smoothly?

 

I can't seem to figure out how to get the tach to vary smoothly.

I am able to get it to vary with a pot, but it jumps to values like there isn't enough resolution. And the resolution issue is worst at high rpm's.

So I scaled the whole pot movement to just try and get the upper rpms to be smooth, but it still jumps to values like my output numbers are coarse.

If you haven't already, try driving the tach from a dedicated Tach_drive program; don't combine with the ECM serial stream routine. Actually, I don't see how the posted code can properly drive the tach since the delay(10) and delay(30) statements will throw off the timing for the delay(cycle_time). If you can, post up just the tach drive routine and we'll take a look, whatever is wrong should be straight forward to figure out.

Tee, do you have any code I could look at for how you got the tach output to work smoothly?

My tach_drive code runs off an internal PIC hardware timer that triggers an interrupt (necessary since the FuelBot is doing several things simultaneously) so is not straight forward. I will post it if you like, but will likely confuse more than it helps...

 

Here is some updated code after playing around with it more.

I found that the "delay()" function would round whatever number it was given to an integer, which is why it was getting more coarse as the rpms went up. Because the smaller the cycle_time then the higher the rpm.

So I discovered the "delaymicroseconds()" function which allowed me get higher resolution. The only problem is that the highest number that function will work with is 16,383 so I can't get the full range of rpms.

Not sure how else to do it.

int cycle_time = 0;
const int analogPin = 0;

void setup() {
  Serial.begin(9600);
  pinMode(2, OUTPUT);
}

void loop() {
  
  // Analog input
  cycle_time = map(analogRead(analogPin), 0, 1023, 2580, 15000);
   
  //Serial.println(cycle_time); 
   
  // Tach Output Signal 50% DC
  digitalWrite(2,HIGH);
  delayMicroseconds(cycle_time);
  digitalWrite(2,LOW);
  delayMicroseconds(cycle_time);
    
}

 

You're almost there bubba. Easy way is to break the delay into two parts, Coarse and Fine. Use delayMiliseconds() for Coarse, delayMicroseconds() for Fine. The key is to use the Modulo operator "%" to get the remainder for uS resolution.

I have not compiled this, so please check the syntax, but something like this should work.

long_int cycle_time_uS = 0; //Must be long integer to fit max 500,000 size.
int cycle_time_fine_uS = 0;
int cycle_time_coarse_mS = 0;
const int analogPin = 0;

void setup() {
  Serial.begin(9600);
  pinMode(2, OUTPUT);
}
void loop() {
  //Map Analog input (0 through 1023) to (4,000uS through 500,000uS)
  //4000uS = 250Hz = 15,000 RPM, MAX
  //500,000uS = 2Hz = 120RPM, MIN
  cycle_time_uS = map(analogRead(analogPin), 0, 1023, 4000, 500000);
   
  //COARSE
  //divide by 1000; integer arithmetic converts uS to mS, remainder is discarded.
  cycle_time_coarse_mS = cycle_time_uS/1000
  
  //FINE
  //"%" is the Modulus operator, result is the uS remainder.
  cycle_time_fine_uS = cycletime_uS % 1000
   
  // Tach Output Signal 50% DC
  digitalWrite(2,HIGH);
  delay(cycle_time_mS); //COARSE delay
  delayMicroseconds(cycle_time_uS);  //FINE delay
  digitalWrite(2,LOW);
  delay(cycle_time_mS);
  delayMicroseconds(cycle_time_uS);
}

 

Thanks TeeRiver. I will be sure to try that and let you know the results and perhaps make a video if I can get it working good.

You're almost there bubba. Easy way is to break the delay into two parts, Coarse and Fine. Use delayMiliseconds() for Coarse, delayMicroseconds() for Fine. The key is to use the Modulo operator "%" to get the remainder for uS resolution.

I have not compiled this, so please check the syntax, but something like this should work.

...

 

Years ago I wired 2nd gen gauge to 1st gen bike but could not fix rpm's reading double.
You guys figured that?

 

Double/high RPM was probably due to noise. Both gen1 (wasted-spark) and gen2 (ECM driven) are 360deg based tachs.

This circuit will kill the noise and translate the voltage. :evil6:

 

Haven't paid a lot of attention, but maybe consider using an interrupt instead of a timer?

 

Just want to say thanks to everyone sharing their results! I'm working on a project to read the ECU datastream so I don't need to run the OEM dash (I have a GPX Pro I want to use), but I still wanted a way to know that the FI idiot light turned on. Based on this information, it should be pretty easy to use an Arduino to do that.

Can someone confirm that the ECU signal to the dash is 5V? I don't own a scope and just ordered a cheap logic analyzer and wasn't sure if I needed to take any precautions since the LA only supports up to 5V.

Thanks!

 

Just wanted to say thanks to everyone contributing to this thread. I'm actually interested in working on the problem from the other way- I want to remove my SV650 dash and just use a GPX Pro for my race bike. The goal is to use an Arduino board to read the ECU data stream and illuminate a light when the Check FI signal is sent... maybe I'll even hook up a couple of 7-seg displays to show the code, or just plug in the dash on an as needed basis.

Later on, I want to use the Arduino to fake the ECU into thinking the STP actuator/sensor are there so I can remove them.

One thing I was curious about was how you determined the 7800 baud rate for reading the data stream? I'm waiting for my logic analyzer to show up, so right now the only information I have about the protocol is the source code earlier in this threat.

For those interested, here's my code so far:

https://dl.dropbox.com/u/10783986/ecu-reader.ino

Thanks!

 

Just wanted to say thanks to TeeRiver and everyone else who contributed to this thread. I'm building a race bike with a 2nd gen SV motor/ECU (the frame is actually a Ducati 1098 though) and didn't want to run the stock gauges since I already have a GPX Pro dash/data logger. Problem is of course how do I know when something is wrong with the EFI system?

Anyways, I've been able to write code for a Teensy board and hook it up to the ECU signal wire and decode the data stream to know when to light a warning light. I'll then be able to plug in my computer via USB and get all the error codes as well.

Anyways, I tested this all on my work bench and it works great and just ordered a prototype PCB that I can mount on the bike. If all goes well (might be asking a lot- this is the very first PCB I've ever designed!), I'll have it ready just in time for the first AFM race this year!

https://dl.dropbox.com/u/10783986/ecu-indicator.png

 

...Anyways, I've been able to write code for a Teensy board and hook it up to the ECU signal wire and decode the data stream to know when to light a warning light.

...I tested this all on my work bench and it works great

Very cool synfinatic. :thumbsup:

How about add an LED to the PCB to have it blink out the error code(s), then no need to hookup to your computer?

Good luck on your first PCB! If by change there are any errors, you can cut bad traces with an exacto knife then add jumps with 30awg wire wrap wire, works great; not that I have much experience fixing screw-ups... :icon_biggrin:

 

Well I found some cheap (10 for $13 on ebay) 4 digit 7 segment displays with a built in SPI chip that *just* will fit in my enclosure. So that's going to be version 2.0 I don't need to decode the water temp since I have the GPX Pro, but I could easily do that too from the looks of it.

The only thing right now that's driving me nuts is I haven't been able to find the connector that Suzuki is using for the wiring harness to the dash. I know Eastern Beaver sells a lot of these Japanese connectors, but I couldn't find anything there that matches.

Anyways, boards show up in about two weeks (maybe one of these days I'll learn how to etch my own boards... the wait is killing me) so I'll keep in mind the exacto knife trick.

 

Well I found some cheap (10 for $13 on ebay) 4 digit 7 segment displays with a built in SPI chip that *just* will fit in my enclosure. So that's going to be version 2.0 I don't need to decode the water temp since I have the GPX Pro, but I could easily do that too from the looks of it.

Please post some photos!

The only thing right now that's driving me nuts is I haven't been able to find the connector that Suzuki is using for the wiring harness to the dash. I know Eastern Beaver sells a lot of these Japanese connectors, but I couldn't find anything there that matches.

Gauge/harness connector info is in this thread.

 

Oh sweet! And I don't need to buy 680 of them either like on DigiKey! Guess I need to find some other things to buy there since they have a $20 minimum though.

Here's a quick little video I did showing the decodes via the Arudino serial/USB console:

Once I get the PCB in, I'll do another showing the semi-final product.