Members Login
Username 
 
Password 
    Remember Me  
Post Info TOPIC: Very simple questions, could use some help getting started


Guru

Status: Offline
Posts: 1247
Date:
RE: Very simple questions, could use some help getting started


I believe the 220 ohm resistor should be diode protected and on the ground sinking side of the switch. Typically the horn button is used to ground the shift solenoid.

It has been quite awhile since I did a gen1 shift kill setup. That said, the last one I did has been shifting for over two years without issues

__________________


Senior Member

Status: Offline
Posts: 161
Date:

So not to mislead anyone ...... blowing away the bad info.

 



-- Edited by bigtoe on Sunday 12th of January 2014 05:18:56 AM



-- Edited by bigtoe on Sunday 12th of January 2014 05:19:15 AM

__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

My mistake.    Greg at Boost by Smith stated there is a diode in the harness, so I cut the one I purchased apart.   Sure enough, there is a 68 ohm in series with a 4007 diode to prevent it from back feeding into the ECM.   Threw off the ohm meter.  

Attached is how it was made.     

 

 

 

 



Attachments
__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

 



__________________

You can lead a horse to water but you can't make it drink.  



Member

Status: Offline
Posts: 23
Date:

I'd like to share some "layman" information with you off board.  I've been using ECUEditor for several years and found some strange results that doesn't make sense on the dyno.  

 

email?



__________________


Senior Member

Status: Offline
Posts: 161
Date:

Feel free to send any offline questions / comments to:

hackmybusa@gmail.com



__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

When using ECUEDITOR, the map display never shows anything other than TPS, IDLE or IAP when I change the mode switch. If I reprogram the ECMs MS maps, I see both the fuel and ignition values change using my simulator, so it appears to be working.

Is there a way using ECUEDITOR to know if the MS map is selected?

 

Was running ECUEDITOR mapping while running a sweep and I noticed that the TPS is a log which makes sense.  I have changed my sweep to use a log as well and can now watch it select every cell in the map.   Attached are the result when looking at the timing curve.  

Spent some time on ROMRAIDER and wow...  

 

 



-- Edited by bigtoe on Tuesday 14th of January 2014 01:36:19 PM

Attachments
__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

I was interested in trying the 2-step. Used RomRaider to adjust the neutral limiter. I then set the clutch to use the neutral map. Seems to work, apply clutch and it limits to the value I set. Problem is it cuts the fuel, not the ignition. Is there a way to make it kill the ignition?

I downloaded the Renesas tools. There was nothing about it being a time restricted demo like it is for the M32. I made up a workspace then attempted to build and it shows a comment about a 60 day eval. I could not find anything on their site that talks about a purchase price. What does HEW do after the 60 days?

 

License manager shows:

Reserving key 'Renesas Opt_Linker_SH 9'
OK (trial)
License expires in 60 days


Looking at the source for ECUEDITOR, there is a directory Workspace that contains the project files for the M32. Under ecu.c, all I see is G1BusaShifter.c. What are the steps to make a project to build this into the binary?






-- Edited by bigtoe on Wednesday 15th of January 2014 02:30:26 AM

__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

Spent some time pouring over the documents for the Renesas tools. After some trial and error, I was able to correctly create a new workspace and rebuild the Gen1 shifter from scratch then load it into the ECM, AND IT WORKS!! There were just enough bread crumbs for even me to follow.

Looking under Explorer

Original file size : 1,264 bytes
Rebuilt file size: 788 bytes

I am using the latest tools, (debug is off) and suspect it may just be that the new compiler is more efficient or an optimization setting.


Still a long way to go but my questions going forward may not be so very simple.....

__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

"I was interested in trying the 2-step. Used RomRaider to adjust the neutral limiter. I then set the clutch to use the neutral map. Seems to work, apply clutch and it limits to the value I set. Problem is it cuts the fuel, not the ignition. Is there a way to make it kill the ignition?"

I found the setting in RomRaider to kill both the fuel and ignition. 

It appears there is a problem when you use the neutral for the 2-step and enable the shifter.    When the parallel resistor / diode is added to the GPS, the ECM selects the neutral limiter.    Even if you do not have the shifter enabled, the kill will happen for as long as you hold the button.  I am not sure why the ECM does not look for the ground on the GPS  blue wire rather than just the voltage on the red.   

Problem is using resistor / diode approach, I am not sure you could have a combo that would work for all conditions when you look at tolerances, switch wear, etc.   In some cases, I can believe the standard harness may even work although when I tried it with my setup, it doesn't work in the lower gears.    

If the 2-step is set higher than the shift point, it will work fine.   If you don't mind not having the one-shot for the kill time, (kills as long as you hold the button) it will work fine.  

I have it working on the bench with the shifter and 2-step (with clutch) working in all gears the way it should but  I'm not thinking its a real good solution.  I am curious if anyone else has ran across this and if you came up with a fix?    

Right thing to do may be to fix the base code.

 

 

 

 



__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

While playing with the shifter, it appears that when the horn is pressed that the fuel outputs will cut for a single pulse with roughly the correct width. However, the ignition will double pulse.

I went back to the baseline binary with the original shifter binary (not my rebuilt version). The only change I then made was to enable the shifter with a 100mS pulse, both fuel and ignition cut. I monitored the signals with a scope and it still double hits the ignition but not the fuel. Guessing this has been a problem for a while but must work alright for most people.

__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

Looking at the G1BusaShifter.c file, if I force the ECU_IgnKillFlag to be set as follows:

#pragma section IGNCODE //0x157B0
void ignmain(void)
{
// if ( killflag == ACTIVE)
// if (igncut == ACTIVE)
// {
ECU_IgnKillFlag = ECU_IgnKillFlag | IGNITIONCUTACTIVE;
// }
jump_back_ign_loop();
}

For the kill to work correctly, I would expect there to never be any ignition pulses. However, what I see is only 1 out of every 4 is dropped. This explains what happens with the original shifter.bin.  If the pulse is long enough to extend past 4 ignition pulses, you will get a double pulse on the 5th.  

 

Update................

I spent some time reading all of JaSa. PK and RR's posts and going over the disassembled K5 ECM code which was not the most fun but on the upside,  I learned enough to start making changes to the ECM.  

I put together a video showing the problems with the 2 step when used with the shifter and also how I solved them.    

With that, let the real hacking begin!

 



-- Edited by bigtoe on Tuesday 21st of January 2014 06:28:44 AM

__________________

You can lead a horse to water but you can't make it drink.  



Guru

Status: Offline
Posts: 1247
Date:

Interesting. We have a nitrous bike that uses a two step (romraider) and the shifter code. I am not aware of an extended duration shift kill. That said, I have never ridden the bike myself either.

__________________


Senior Member

Status: Offline
Posts: 161
Date:

sportbikeryder wrote:

Interesting. We have a nitrous bike that uses a two step (romraider) and the shifter code. I am not aware of an extended duration shift kill. That said, I have never ridden the bike myself either.


 

If you tested your setup and its working and you're happy with it, that's great.  I never looked into the nitrous control.  I assume they turn off the nitrous during the kill with the air valve.  Something similar could control a second set of injectors as well.   

From above:

"Problem is using resistor / diode approach, I am not sure you could have a combo that would work for all conditions when you look at tolerances, switch wear, etc.   In some cases, I can believe the standard harness may even work although when I tried it with my setup, it doesn't work in the lower gears. "

In the last video I demonstrate what I see with my test setup when using the 68 ohm in series with the 4007 diode shift harness.   The ignition kill timer does not work regardless of if the 2-step is used or not and I show that as well.    Again, even that must not cause a problem for most people or they would not be selling too many shift harnesses.   



__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

I am starting to look at adding traction control.   I looked at what was done for the Gen 2 and the basic idea seems fine.  

I don't have any data off the street tire Hayabusa yet.    The attached data is taken from my old bike showing 4 separate passes.    I circled the areas where the tire has spun.    Time is in seconds.   The tire will spin at launch most often.   Some times its just a quick slip then it grabs again.  Other times it will shake.       The other time it will normally spin is after a shift.   Rarely it will spin down track   I suspect the Hayabusa will have a similar problem.

 

 



-- Edited by bigtoe on Thursday 23rd of January 2014 04:10:06 AM

Attachments
__________________

You can lead a horse to water but you can't make it drink.  



Member

Status: Offline
Posts: 23
Date:

First, I would like to say that I am so pleased in seeing someone with your ability doing this work.

In response to traction control: with only looking at RPM rise rate, how do distinguish between tire and clutch slip? Plus, I do know with high powered Busas and high powered bikes that race what I do (LSR) tire slip is an issue at the fast end.

__________________


Senior Member

Status: Offline
Posts: 161
Date:

Well, not knowing what I am doing, my answer is that I am not sure yet.   You are absolutely correct about the clutch. There are a couple of things to keep in mind.

The clutch slip will not be a problem down track nor after the shift.  It really gets down to the launch.  In the 4 plots I showed previously, the earliest data starts 0.19 seconds after I launched.   That's a very long time.   The attached shows RPM, boost and clutch slip for this same bike.    I would not look for the tire spin until after I know the clutch has locked.   For this bike, about 0.2 seconds is plenty.

All bikes are going to be different. 

The Hayabusa also has an output shaft sensor.   While I understand it is not connected to the ECM in stock form.......



-- Edited by bigtoe on Thursday 23rd of January 2014 04:09:47 AM

Attachments
__________________

You can lead a horse to water but you can't make it drink.  



Member

Status: Offline
Posts: 23
Date:

Yes, the output sensor is the speedo sensor.  I've never looked closely at the ECU pinout to check if it is routed through before the dash.



__________________


Senior Member

Status: Offline
Posts: 161
Date:

It does not route to the ECM in stock form. I have other things I could use this data for besides traction control so I can see spending some time on it.

My plan is to feed the raw data from the other bike into some math program and try it all out on the PC (not using the ECM at all). If I can find something I am happy with, I'll roll that into the ECM and see how it works. I can play back the data collected from the other bike into the Hayabusa ECM. If this all seems to work, then I will try it out on a real bike.




__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

Top showing crank and output shaft speeds in RPM.  Middle graph shows boost pressure.   As it looses traction, no load, no heat, no boost.  

Bottom graph shows the detection.   All I am doing is looking at the current crank speed - the previous and testing that against a threshold.  The Yellow line under the Red loss of traction signal is the difference.    If the previous difference or the current difference is higher  than the threshold, I set the flag and start pulling timing.   Once it grabs, I reset the timing to the normal value.

Maybe something as simple as this would work.  Should be easy enough for the ECM to do a subtraction and compare. 

Took some time to look at simulating an injector load.   The 32-bit ECM requires and inductive load to not fault.   I had measured an injector, then made up some pot cores.  It worked alright, but the duty cycle is too high.    Figure 11,000 RPM or 183 RPS or 1 crank rotation is 5.45mS or 1 cam rotation in 10.9 mS.   Stock PW looks like 9.3 mS    or about 85.3% duty cycle.    Coil is in saturation.  DC resistance of stock is about 11 ohms.   That's 38 Watts.    Better it runs cold than cooking.     Started playing around with different loads and it looks like even at 90 ohms 170mH the ECM is fine.    At 270 mH 250 ohms, it has problems.   I now have the new loads mounted in the box.   They are powered from a controlled output so I am able to set the fault codes for testing.

Also went back and looked at the timing problems I was seeing.   I made up a crank wheel based on where I have the timing set in the map in ECUEDITOR.    These numbers are now in the ballpark of what I would expect.   However, what is being displayed in the datastream for fuel pulse width and ign deg is worthless from what I can tell.   

 



-- Edited by bigtoe on Saturday 1st of February 2014 04:07:32 AM

Attachments
__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

Spent a little time going back and looking at the bit assignments for the cluster. Bits marked as always 0 seem to have no effect on the clusters operation nor was I able to find a way to change their state.  

I made up a an RS-232 to TTLish converter using a FET and a couple of resistors.  Used the handshake pins for the power supply.  Covered it with hot glue.  Cheap, and gives me a way to sniff the bus when using the ECUEDITOR.

Looking at the the tach bits, they seem to be much more than just the RPM. Depending on the TPS, IAP, AAP, CT and IAT, these bit will change.   More work to do before I can mod the original code.

Byte Bit Description
0 7 Coolant Temp, Bit 9, MSB
6 Coolant Temp, Bit 8
5 Coolant Temp, Bit 7
4 Coolant Temp, Bit 6
3 Coolant Temp, Bit 5
2 Coolant Temp, Bit 4
1 Coolant Temp, Bit 3
0 Coolant Temp, Bit 2

1 7 Coolant Temp, Bit 1
6 Coolant Temp, Bit 0
5 1 Sets fault C43
4 Set when service switch active
3 Set when service switch inactive *****  ????  Not always true...
2 TPS B1 (1,1 - TPS inrange), 0 not in service
1 TPS B0 (1,0 high 0,1 low), 0 not in service
0 1 Sets fault C42 Ignition Switch

2 7 1 Sets fault C41 Fuel Pump Control
6 1 Sets fault C35 Cylinder 4 Fuel Inj
5 1 Sets fault C34 Cylinder 3 Fuel Inj
4 1 Sets fault C33 Cylinder 2 Fuel Inj
3 1 Sets fault C32 Cylinder 1 Fuel Inj
2 1 Sets fault C31 Gear Position Sensor
1 1 Sets fault C25 Cylinder 2 Ign coil
0 1 Sets fault C24 Cylinder 1 Ign coil

3 7 1 Sets fault C23 Tip Over Sensor
6 1 Sets fault C22 Atm Pressure
5 1 Sets fault C21 Intake Air Temp
4 1 Sets fault C15 Engine Coolant Temp
3 1 Sets fault C14 Throttle Position
2 1 Sets fault C13 Intake Air Pressure
1 1 Sets fault C12 Crankshaft Position
0 1 Sets fault C11 Camshaft Position

4 7 Always 0
6 Always 0
5 Always 0
4 Always 0
3 1 Sets fault C44 Oxygen Sensor
2 1 Sets fault C27 Cylinder 4 Ign coil
1 1 Sets fault C26 Cylinder 3 Ign coil
0 Always 0

5 7 Tachometer, Bit 15
6 Tachometer, Bit 14
5 Tachometer, Bit 13
4 Tachometer, Bit 12
3 Tachometer, Bit 11
2 Tachometer, Bit 10
1 Tachometer, Bit 9
0 Tachometer, Bit 8

6 7 Tachometer, Bit 7
6 Tachometer, Bit 6
5 Tachometer, Bit 5
4 Tachometer, Bit 4
3 Tachometer, Bit 3
2 Tachometer, Bit 2
1 Tachometer, Bit 1
0 Tachometer, Bit 0

7 Modulo 0x100 Checksum -1 and invert



-- Edited by bigtoe on Tuesday 4th of February 2014 05:10:17 AM

Attachments
__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

Now looking at the data pulled from the ECU, I can see where the timing for all four cylinders and fuel pulse times are stored. So far, it looks like everything is pretty much direct. The timing and pulse widths match with what my simulator is decoding. There is a small amount of error (again, I still do not know where TDC is), nothing like what the ECUEDITOR datastream is showing.

I have more work to do before I can make a working monitor program but so far, things are looking positive.


__________________

You can lead a horse to water but you can't make it drink.  



Guru

Status: Offline
Posts: 1247
Date:

good work. Lots of data to go through for sure.

__________________


Senior Member

Status: Offline
Posts: 161
Date:

Managed to get most of of the data logger sorted out today. There are a couple of things to sort out but I am now able to display all of the sensors live, along with the GPS, clutch switch, map select switch, air valve status, injection on time and the ignition advance. All of this data can now be plotted on a graph as well. Not to mention, it keeps the cluster refreshed.

The downside is at 7800 bps, that's 1.28 mS to send a byte (start, stop and 8-bits of data). Because you have to request every byte, then wait for the response, plus dump the data to the cluster then do the little recover command. That's a lot of data for such a slow bus. Loop time is about 0.185 seconds (about 5 times a second update rate). It's just way too slow to be of much use.

Update

Managed to shave a little time out of it.   Its down to 144 mS loop time now, just under 7 times a second.   Something goes wrong with the cluster running it this fast and it will set an FI code.   Strange as there are no codes set.

Currently I check the time from the last time I updated the cluster.  If that time is is more than 400 mS, I do a refresh.  The ECM normally sends data to the cluster at a half second rate.   I can make the refresh time longer or shorter and it has no effect.  I can hard code the data to the cluster and force it to all zeros and it has no effect (FI code will display).

More strange, if the engine speed is high enough to trigger the ECMs injector/coil outputs, the cluster clears the FI code and works correctly.     This is the older cluster that I had to rig to get working.  Maybe there is a newer version of firmware for the cluster to solve this.  

What ever the problem is, it seems to be caused by the rate that I pull the data from the ECM.  If I slow it down even 40mS or just collect more data, the cluster works correctly. 

Where's CAN when you need it.....



-- Edited by bigtoe on Sunday 2nd of February 2014 08:34:47 AM

__________________

You can lead a horse to water but you can't make it drink.  



Guru

Status: Offline
Posts: 1233
Date:

really impressive progress, i agree Can Bus would be much better to work with. i really have to pull my finger out and buy/build something similar (but more generic for different models) myself.



__________________

site_logo_small.png

www.WoolichRacing.comTune your bike to the Limit with our Advanced ECU Flashing Products



Senior Member

Status: Offline
Posts: 161
Date:

D-Space has some very nice components. I have never looked at what National Instruments offers. Would guess that the cost is going to be lower going with NI but you would need to look into it. In both cases, you may still need to come up with your interface to the ECM.

I started out using a scope to look at the waveforms, and just a signal generator hooked to an FPGA. The FPGA was nothing more than a sate machine to create the waveforms. If you wanted a cheap system, you may be able to find everything you need on eBay. Really you need an arbitrary waveform generator and logic analyzer, both with with GPIB. Obviously a GPIB controller. Power supply. Get the student version of Labview for $50 and start coding it up.

A few people were building different load boxes using a small microcontroller to synthesize the waveforms. You could use a timer, counter and ROM to do it. Very low cost. You would still need to figure out all your loads and sensors for each bike you want to support. Seems like it could be a big task. Really depends what you're after.




I have a newer cluster from a 2005 that I tried out today. Unfortunately there was no difference. The cluster is trying to decode the other packets and use that data even though these packets are not eight bytes long. This is why the error codes will set. There is no way for the cluster to know the difference from an ECM request or if the data is for the cluster other than by the length. Even if I send no 8 byte packets, the cluster still throws the code. Possibly there are ECM request packets where the cluster finds an 8 byte packet with a correct checksum.

***********************


Threw in the towel after spending too much time trying to get it to work.   The only thing I could come up with is to have allow switching from high speed (well.... that's relative) without the cluster, or slow with the cluster.     It works pretty good compared to ECUEDITOR.    At least the numbers mean something now and you don't have to select one sensor at a time to display.

It can record data to the disk drive in spreadsheet format for Excel.    With the cluster communications turned off, the loop time is about 90mS, or about 10 samples per second.   About what you may expect from a low end data logger.   Not very useful  but it could be very cheap to get working.   Thinking that if I had a low end tablet , I could mount the thing in the dash and log all day with the live graphics display.     

************************

Planning on the Lenovo IdeaTab Miix 2

http://shop.lenovo.com/us/en/tablets/ideatab/miix-series/miix-2/

 

Looks like about $300, with a flash card and a USB cable.   I will make up some sort of mount if I decide to use it.      

Tested the logger program on the oldest laptop I have with no problems.  Both of these tablets should handle it just fine.   Data will be stored to the flash card.  

Now looking to see if I can find some sort of ready made scope/logic analyzer to use for the high speed logging.   Thinking the tablet will connect to a small hub.  Will use a serial adapter to talk to the wideband (also 10 Hz).   Labview will then talk with all three devices using one program to collect all the data. 

Found one that has a Spartan 6 that would be real nice.  $200.   FPGA is programmed from the USB so I could just have a new file that would be uploaded to add the features I need.   Would make it very easy for someone to replicate. 


-- Edited by bigtoe on Monday 3rd of February 2014 02:02:53 AM



-- Edited by bigtoe on Tuesday 4th of February 2014 05:36:50 AM



-- Edited by bigtoe on Wednesday 5th of February 2014 04:00:46 AM

__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

I was asked off-line about the accuracy of the cluster and was told it reads high by 7%.  I also was told that using a healer would cause the odometer to read wrong and that the tachometer was not accurate.   With these being analog gauges, I thought it would be best to take pictures as I went through the test.  You can judge for yourself.

Let start with time measurement.  I use a special GPS receiver that you would normally find in a cell phone tower as my reference.    This reference was used to validate the quartz oscillator I am using on my simulation board.   The error is far below what we are trying to measure.    The simulator uses this clock to drive a digital synthesizer that creates the output shaft pulses and crank speed. 

To calculate MPH,  stock gearing and tire sizes taken from the service manual were used.   Obviously, this does not account for tire pressure, wear or  centrifugal forces on the tire.  It's a ball park.   I'm sure you have all ran these numbers before.   Both the 2001 and a 2005 clusters were tested.    The damaged 2001 cluster works fine as long as I do not slew the signals too fast.   For this test, we can run it as slow as we want so the problem with the cluster will not effect the results.

I started by sweeping the crank speed from 1000 to 11000 RPM.   To save space, I posted the odd speeds and only for the 2001 cluster.   The 2005 was in the same ballpark.



-- Edited by bigtoe on Saturday 8th of February 2014 03:45:17 PM



-- Edited by bigtoe on Saturday 8th of February 2014 04:05:40 PM

Attachments
__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

The attached images show the vehicle speed in MPH using the 2001 cluster.  I tested it 60 and 90 MPH.  

 



Attachments
__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

The following pictures are using the 2005 cluster. To measure the odometer, I just ran for a fixed amount of time (10.0 minutes) at a fixed speed (100 MPH) then recorded the distance.  The trip was started at 1:10.   



Attachments
__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

Attached I show vehicle speed at 20,60,120 and 180 MPH.  

At 20, the gauge reads 19.5ish, or a -2.5% error

At 60, the gauge reads around 60

At 120, the gauge reads around 121 or +0.83% error.

At 180, the gauge reads around 184 or a positive +2.2% error.  

Obviously, again this data is only for two clusters.  It does not take into account a lot of variables that will effect accuracy.   



Attachments
__________________

You can lead a horse to water but you can't make it drink.  



Member

Status: Offline
Posts: 23
Date:

Just throwing this out there for reference.  The Gen 1 Busa is notoriously off on the cluster as pertaining to RPM and Speedo.  RPM slowy starts reading high and by Engine Speed of 11,000 the cluster reads almost 11,500.  Speedo does the same thing, and by 170 actual speed reads 185 mph.



__________________


Senior Member

Status: Offline
Posts: 161
Date:

Obviously the only data I am able to present is from the two Gen 1 clusters I have. If you have specific questions about how I am testing them or the calculations I am making, feel free to ask.

__________________

You can lead a horse to water but you can't make it drink.  



Member

Status: Offline
Posts: 23
Date:

bigtoe wrote:

Obviously the only data I am able to present is from the two Gen 1 clusters I have. If you have specific questions about how I am testing them or the calculations I am making, feel free to ask.


 Just trying to help, that's all.

 Either Suzuki did it intentionally or the cluster doesn't report correctly the ECU data stream on the stock bikes.  Just don't want you to "chase your tail" on something that was wrong from the factory.



__________________


Senior Member

Status: Offline
Posts: 161
Date:

If my data doesn't match up with what you see with your bike or what is posted all over the internet, let's try and figure out why.

For the setup I am working with, the vehicle and crank speeds are not derived from the serial data bus. I doubt very much there was different firmware for the different MYs as the two clusters I have behave the same. I would also doubt that the firmware behaves in a non-linear fashion. In other words, Based on my cluster having +/- 2.5% or reading, I doubt they have a fudge factor that purposely adds error in the firmware.

It is possible I have errors in my math that make my clusters come out tighter than normal. If you like I can go over the math om detail.

If you wanted to attempt to fix your setup, I would start by trying to isolate the problem. In other words, the claim is the cluster is bad but are you sure it's not something else? I would go back to measuring the tires circumference with chalk and a tape for several turns. How does that measurement compare with the calculated value from the manual? Make sure the sprockets match what is called out in the manual.

If these seem correct, I would suspect the cluster's reference. They may have used a resonator or something very sloppy. They may have two sources, one for the data bus timing, the other for the real time clock and such. I only dug into the cluster enough to get the bad one I have working. If you have a way to measure the reference and would like to compare with mine, I can provide this data as well. Just post a picture or something that tells me where you are tapping off to get the signal.  

Also, you noted how your crank speed also reads high.  How did you measure this?  It would make sense that it is a clock problem but noise, etc could also cause problems with this signal.  

Beyond these few suggestions, there is little more I can do to help.



-- Edited by bigtoe on Saturday 8th of February 2014 06:34:38 PM

__________________

You can lead a horse to water but you can't make it drink.  



Member

Status: Offline
Posts: 23
Date:

My experiences come from a couple hundred different Gen 1s that I've tuned on the dyno.  ECUEditor, PowerCommander, Bazzaz, Woolich, all correspond to the dyno very closely.  The cluster not so much.  Couple of years ago when I wasn't spraying the house down on my Land Speed Busa, I was geared 18/39 (+1/-1) and the speedo would be dead on compared to the laser timing equipment.

At stock redline, 10,800, the tach is off a little more than 400 RPM.  The speedo with stock gearing and stock tire size, is off by 11%

What I am saying is that you are correct... The cluster reference must be off.



-- Edited by RansomT on Saturday 8th of February 2014 09:53:29 PM

__________________


Senior Member

Status: Offline
Posts: 161
Date:

Seems strange but possible that I would have two that are in the ballpark of +/-2.5% while you have had hundreds that are 11% off. I am normally not that lucky.

I have no experience with any of the items you mention beyond the little I have played with ECUEDITOR so I can not comment on them.

All of my experience with dynamometers has been with direct drive off the motor. Beyond the high dollar eddy current ones, I have helped to build a couple of smaller water brakes and designed and built a couple of toy ones a few years back as a model for a larger one. The last smaller one I helped build and my toy one both use a 100 ppm TCXO as a time reference. I have never had a motor cycle on a chassis dynamometer so you will need to excuse my ignorance on the subject.

Of course, I assume you're running some sort of chassis dyno. I assume it is not an inertia dyno but something you can run steady state on. I assume your dyno has some sort of speed sensor on the roller and this is what you use as a reference. I assume that if that is off, every bike you test will look wrong. Are you required to have the equipment calibrated annually to meet some some ISO standard? If so, how do you calibrate the speed sensor on the dyno?

I assume you strap them down. Let's forget all the ugly road-load force math. How do you compensate for the tire growth and how do you know when the tire slips? As the tire is compressed when it is strapped down, it will also change size. How is this compensated for?   To me, again very ignorant on this subject, it seems like tire pressure/temperature/growth/strap down force and slip can all be a problem when comparing the cluster to the drum speed.  

 

This is the last toy dynamometer I built (first one died an ugly death).  It can run closed loop on torque or shaft speed.  It's not very useful but helped me work out the software side of things for the larger systems I helped build. 

 

 



__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

Today I removed the cluster from my bike expecting to see 3 for 3.  I do not see how you can get MPH from the version of ECUEDITOR I am using (no place to enter gearing) so I assume on the dynamometer you're only referring to the tachometer being wrong.   We know ECUEDITOR does not have good resolution (100 RPM steps) but for now this is not a concern.

Attached picture shows my simulation software, ECUEDITOR and the cluster from my bike.     Notice that the cluster is about 9 MPH high (11.2% of reading) and the crank speed is about 500 RPM high (+4.5% of reading).   



Attachments
__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

Looking inside the cluster, under the speedometer, we can see what at a glance appears to be an quartz oscillator and a resonator.  Looking at the oscillator, it is a 32768 Hz crystal or a resonator.    This oscillator appears to be very close (32766.4 Hz).   I thought this may have been for the serial communications but pretty sure it is for the RTC.  Adjusting the 5.0 MHz resonator far enough effects the serial communications.   5.0 +/-0.5 is about the range of it.     Moving it to one side does not appear to have an effect on the RTC. 



-- Edited by bigtoe on Sunday 9th of February 2014 08:48:31 PM

Attachments
__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

I suspected the second resonator was used for the timing reference.   This part is marked 5.00 and measuring it, it is indeed a 5.0 MHz part.   The device was removed and the circuit board was driven from an external generator.    Sure enough, this second oscillator is the timing reference for the speedometer and tachometer.   It is possible that they may store a calibration in what appears to be a small EEPROM.

I suspect the loading of a 10X probe would add a lot of error and I am not sure they have a buffered output.  When driving the cluster, it appears using a 5.00MHz source is what it wants.   At 11,000 RPM,  I have to adjust the generator to 4,850000 MHz to show 11,500 on the cluster. 



-- Edited by bigtoe on Sunday 9th of February 2014 11:25:07 PM

Attachments
__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

I did not have any 5 MHz oscillators or crystals on hand to try on my bikes cluster.   I would like to use a crystal and wanted to try it out.  This is a standard AT cut quartz 4.9152MHz installed on the damaged 01 cluster (seen to the right center).   Notice the tachometer now reads just under 500 RPM high.   Go figure.   I'll go with a smaller package.

Showing suspect resonator mounted to test board.  



Attachments
__________________

You can lead a horse to water but you can't make it drink.  



Member

Status: Offline
Posts: 23
Date:

bigtoe wrote:

Today I removed the cluster from my bike expecting to see 3 for 3.  I do not see how you can get MPH from the version of ECUEDITOR I am using (no place to enter gearing) so I assume on the dynamometer you're only referring to the tachometer being wrong.   We know ECUEDITOR does not have good resolution (100 RPM steps) but for now this is not a concern.

Attached picture shows my simulation software, ECUEDITOR and the cluster from my bike.     Notice that the cluster is about 9 MPH high (11.2% of reading) and the crank speed is about 500 RPM high (+4.5% of reading).   


 Yes!  This is what I have been referring to.   My speed reference is from the cluster to the dyno, RPM reference is cluster to software.  RPM becomes more noticeable when you increase the rev limiter with ECUEditor because you just naturally focus on where it occurs.  While I am physically doing a dyno pull, I reference the clusters because, as you state, ECUEditor lags behind on the data screen.



__________________


Senior Member

Status: Offline
Posts: 161
Date:

Sorry, but I don't follow. When you make a pull, how does your dynamometer's software get the RPM to do it's calculations? Isn't there a display that shows you all the info live? Are you somehow trying to use the cluster or ECUEDITOR for this?

What you could do is get one good cluster, make an extension cable then use this for all of your testing. Another option would be to make a better program than ECUEDITOR, or just improve ECUEDITOR to get faster display rates. This week I hope to have the table in and will post a video of it running. 10Hz may be good enough. If you just wanted the tach, I am sure I could speed it up quite a bit.

Post some info about what dyno you have and the software you are using.

I'll order up some new parts today to try and improve the cluster from my bike.

__________________

You can lead a horse to water but you can't make it drink.  



Guru

Status: Offline
Posts: 1247
Date:

Most dyno's use a direct ignition signal for the engine RPM pickup. On external coil they use a high voltage inductive pickup on the sparkplug wire. On applications with COP, the pickup is amplified (still inductive) and picks up the lower voltage signal to the coil.

Since it appears the cluster is accurate based on your initial posts regarding the testing, It may be something that Suzuki intentionally programmed into the tachometer data stream at higher RPM. It appears ECU editor is also accurate when you create your own data stream. Perhaps the Suzuki data stream is not "real data" but instead, some non linear representation to provide the incorrect tacho data.

__________________


Senior Member

Status: Offline
Posts: 161
Date:

Attached is a clip of my Gen 1 data logging program running on a my oldest laptop.   This would replace ECUEDITOR's data stream feature.   The tablet I am getting has a faster CPU and should provide similar results.     The laptop is connected to the ECM using the Boost by Smith adapter.   The simulation software is still running on the desktop PC at the same time.    I walk through most of the features so you can see how it all works but no commentary.   

When showing the GPI and tachometer,  I was changing the signals very fast on the simulator to give an idea of how fast the display updates compared with ECUEDITOR.    You will also notice I have two timing curves stored and am able to switch between them.  The timing and fuel injector pulse widths are very close to the simulator (unlike ECUEDITOR).  

It's running a little faster than 10 Hz and everything can be logged to a file at this speed. 

You can see towards the end of the video that the cluster remains active while running the program (as I start setting fault codes from the simulator).   

 

Attached a couple of screen shots of it.

 



-- Edited by bigtoe on Tuesday 11th of February 2014 02:42:17 AM

Attachments
__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

Looks like the most of the parts will arrive this week. For some reason the hubs and cables I ordered are not going to be here for another month. I figured no big deal, I'll pick these up at the local Bestbuy or Staples stores. I was looking on the shelves and did not see the cable I needed. Of course a few sales people asked if they could help and so I explained how I wanted to hook a few peripherals to a tablet I was buying. The sales guy then proceeds to tell me how USB works and how there's an A and a B and how this will never work because there are no drivers....  I made one attempt to try and educate him about the new standards and how this was an Intel device but you know the old saying....   Even as I walked away, he continued to try and explain why this can't work.   

Did a quick search for home made OTG cables and came up with this as the first hit:
http://forums.androidcentral.com/google-nexus-7-2012-accessories/200856-diy-making-your-own-otg-cable-image-heavy.html

Not sure about running a hub with OTG.   The ones I bought to try have the correct connector for the table and claim OTG standard.  From what I had read,  sounds like it may not work. 



__________________

You can lead a horse to water but you can't make it drink.  



Member

Status: Offline
Posts: 23
Date:

bigtoe wrote:

Sorry, but I don't follow. When you make a pull, how does your dynamometer's software get the RPM to do it's calculations? Isn't there a display that shows you all the info live? Are you somehow trying to use the cluster or ECUEDITOR for this?

What you could do is get one good cluster, make an extension cable then use this for all of your testing. Another option would be to make a better program than ECUEDITOR, or just improve ECUEDITOR to get faster display rates. This week I hope to have the table in and will post a video of it running. 10Hz may be good enough. If you just wanted the tach, I am sure I could speed it up quite a bit.

Post some info about what dyno you have and the software you are using.

I'll order up some new parts today to try and improve the cluster from my bike.


I have a Dayton Dyno (DynoJet clone kinda) and the software it uses is called SportDyno, it's available online.  I can get the RPM reading either by sampling the coils or setting it mechanically.  Oddly, mechanical has become the method of choice because it ends up having less drama.  Of course, years of dyno work experience helps knowing about tire growth and reading the charts to see slippage.

When I am tuning part throttle, I use the computer monitors.  ECUEditor is a PITA because of the delay (both RPM and Load), piggy back systems like Power Commander or Bazzaz respond much faster to the Load (throttle position) but still the delay for RPM it too great to depend on, I rely on the dyno software results for that.  During WOT pulls, I just concentrate on the bike's cluster because it responds faster to RPM and I prefer not to smack the limiter, then I check the dyno results to tune.

Looks like your logging program is far superior.  Wonder if there will be away to capture the data without a computer so it could be used on the track/street?



__________________


Senior Member

Status: Offline
Posts: 161
Date:

RansomT wrote:
I have a Dayton Dyno (DynoJet clone kinda) and the software it uses is called SportDyno, it's available online.  I can get the RPM reading either by sampling the coils or setting it mechanically.  Oddly, mechanical has become the method of choice because it ends up having less drama.  Of course, years of dyno work experience helps knowing about tire growth and reading the charts to see slippage.

When I am tuning part throttle, I use the computer monitors.  ECUEditor is a PITA because of the delay (both RPM and Load), piggy back systems like Power Commander or Bazzaz respond much faster to the Load (throttle position) but still the delay for RPM it too great to depend on, I rely on the dyno software results for that.  During WOT pulls, I just concentrate on the bike's cluster because it responds faster to RPM and I prefer not to smack the limiter, then I check the dyno results to tune.

Looks like your logging program is far superior.  Wonder if there will be away to capture the data without a computer so it could be used on the track/street?


 

"drama" are you saying your electronic tachometer is not stable or is is just too slow? 

My plan is to mount the tablet to the bike and log all the data with it.   The tablet is pretty small, and cheap ($300).  



__________________

You can lead a horse to water but you can't make it drink.  



Member

Status: Offline
Posts: 23
Date:

bigtoe wrote:
RansomT wrote:
I have a Dayton Dyno (DynoJet clone kinda) and the software it uses is called SportDyno, it's available online.  I can get the RPM reading either by sampling the coils or setting it mechanically.  Oddly, mechanical has become the method of choice because it ends up having less drama.  Of course, years of dyno work experience helps knowing about tire growth and reading the charts to see slippage.

When I am tuning part throttle, I use the computer monitors.  ECUEditor is a PITA because of the delay (both RPM and Load), piggy back systems like Power Commander or Bazzaz respond much faster to the Load (throttle position) but still the delay for RPM it too great to depend on, I rely on the dyno software results for that.  During WOT pulls, I just concentrate on the bike's cluster because it responds faster to RPM and I prefer not to smack the limiter, then I check the dyno results to tune.

Looks like your logging program is far superior.  Wonder if there will be away to capture the data without a computer so it could be used on the track/street?


 

"drama" are you saying your electronic tachometer is not stable or is is just too slow? 

My plan is to mount the tablet to the bike and log all the data with it.   The tablet is pretty small, and cheap ($300).  


 

Stability.  You loose signal during the pulls or you get erroneous readings. 

Sounds exciting!  Especially considering there isn't any ECU data logger for the Gen 1.



__________________


Senior Member

Status: Offline
Posts: 161
Date:

RansomT wrote:
Stability.  You loose signal during the pulls or you get erroneous readings. 

Sounds exciting!  Especially considering there isn't any ECU data logger for the Gen 1.


 Dang, that's too bad.   All the dyno's except the last used an electronic tachometer.  Always off the shaft, similar to how the bike engine senses position.   The last dyno I helped build has both a mechanical and an electronic tachometer.    Owner became a believer in the electronics after the first pull we made.  Don't think he ever used the mechanical one after that.

I made my own loggers in the past.   Now days with the newer microcontrollers, this would be a snap and cheap.   The tablet  has a lot going for it as a logger.   The real trick will be getting some high speed data collected, not this 10 Hz stuff.   If the hub will work, I think I can pull it off.

 

A few pictures showing how to mod your cluster for a higher accuracy.  I DO NOT RECOMMEND ANYONE TRY THIS!!!  ESD, soldering skills, cluster is easy to damage!   If you have lived with it this long.....

I used two halves of a wooden clothes pin to pry up on the needle.  You may want to just unsolder the whole assembly!   OR JUST LEAVE IT ALONE!!!



-- Edited by bigtoe on Friday 14th of February 2014 05:10:41 AM

Attachments
__________________

You can lead a horse to water but you can't make it drink.  



Senior Member

Status: Offline
Posts: 161
Date:

These pictures are of the cluster that was taken off of my bike after making the modifications.   As you can see, even at 13,000 RPM the cluster is now within 100 RPM or so depending on your viewing angle of these analog gauges....

So it could be fixed, but again I don't recommend it.  Chances are you would do more harm than good to your cluster.  



Attachments
__________________

You can lead a horse to water but you can't make it drink.  

«First  <  1 2 3 4 5  >  Last»  | Page of 5  sorted by
 
Quick Reply

Please log in to post quick replies.

Tweet this page Post to Digg Post to Del.icio.us


Create your own FREE Forum
Report Abuse
Powered by ActiveBoard