You can lead a horse to water but you can't make it drink.
Started with a couple of transistors for the shifter. This gave a nice constant voltage when the kill was active to fix the problem when using the 2-step. Used the ground of the GPS as the reference. This worked fine seemed a bit too complex. I later just ditched the resistor. This is what I have used for the last several months. Kept the thresholds in the software the same.
The one-shot circuit has an open drain FET that is in parallel with the horn button to run the auto-shift. One-shot is about a 300mS pulse. I set the delay on the shift so it tags the air ram then blips the kill. Very smooth.
You had asked about logging the speed with a separate logger. Hope you got that all working. The Lenovo MIIX 2 has a built-in GPS sensor. I have been playing around with it while driving the car and it appears very reliable. Signal and communications appear solid. It is sort of hard to tell but the GPS seems to report the MPH dead on with the cluster. I am not sure if the update rates are programmable and it currently only outputs data every second. I am thinking to just add support for this sensor to my logger program. I have been looking at some third party software from Centrafuse that will allow the MIIX 2 to mimic the older type NMEA messages. If I support this message format, it would allow my program to use a different GPS when not running on the MIIX.
Don't think it's going to be very helpful for me anyway. I have not been able to find any data on the chipset they use. The 1 second update rate is just too slow for what I want it for. On the plus side, it does work pretty good and didn't cost anything to add. I compared it's output with my HP GPS and they read pretty close.
Have it now logging the speed with the other data.
Was looking at the 638FLPx GPS for about $60. This part can run up to 20Hz and would just be a plug and play with my software. Maybe this winter I'll play with it. Updated the logger to add a little more info from the GPS. Altitude for some reason is not stable, but the lon and lat look real good.
Mentioned I wanted to add support for a separate logger to get the clutch info. The China spider USB hub was only a 2 port where I had thought it was a 3. I also was running the two USB serial adapters for the wideband and ECM data link from the tablets battery. I never made a charger for the bike to power the tablet and peripherals.
Picked up a cheap 4-port hub and added the DC-DC for the charger. Also added transient and reverse battery protection to it. Just shrink wrapped it with some hot glue to seal it up. Gives me a spare port if I decide to add something else like an external GPS.
After playing with the bike for the summer, it's been real helpful having a way to log the data and test some of my changes out not using the bike. A few times it would have been very nice to have a closed loop simulation running. I had everything done, just no software. Didn't think it would be helpful and ran out of time.
Spent some time today making what I would call the worst engine model ever. Right now just using the injection duty cycle to directly control the pressure and crank speed. A couple of gains, limiters and done. Tried it out and the simulator went right to 1150 RPM. Snap open the throttle and up it goes. Start it cold and it will run on the 3000ish high idle. Kinda cool to see it run but not real useful. There is no friction, inertia, external load, nothing about the bike itself.
Now have most of the parameters in the software now to support a more complex engine model. Plan to add some sort of model for the clutch and bike as well.
Did look at some of the modern simulators available. National Instruments requires their hardware to run their simulator. Maplesoft supports Matlab and Labview but the toolbox to run it is way outside my budget. Didn't look at the cost of Maplesim. I doubt I will do anything so complex the model could not be run on the PC. I plan to just code things in Labview for now even though I wrote all of the interface to the hardware in C. If timing becomes a problem, I'll port it to C.
Should be an interesting winter.
Created a new Youtube account and uploaded some of the older videos.
Sort of a crappy video showing where the table mounts along with the auto shift.
Attached picture showing my simulator running closed loop. Clutch is pulled in, put into 1st, ping the throttle. It hits the low limiter. Release the clutch and the auto shift takes over with an 8,000 RPM shift point (same program in the bikes ECM). Appears to start cutting back the fuel as the speeds come up.
Needs a little trimming, but all in all functional.
If the max crank speed were 12,000 RPM, or 200 RPS the cam rotates every 10mS. The model will run about 1mS now, so should be fine for what I want to use it for.
Tire slip is next.
The new cheap logger came in today. I spent some time writing some code to talk to it. Attached picture shows a 0 to 10Volt 1KHz sinusoid being captured with it. Its a 12-bit converter running at 20KHz. A little concerned about using it to look at the clutch. On my other logger it's all done in hardware where this thing does it in firmware. May not be fast enough. Then again, I did say it was cheap!
The attached ROMRaider screen shot shows how I have been running the autoshift.
The On_High is the RPM that the output will first turn on at. If the RPM falls below On_Low or goes above Off_High, the output will turn back off. The output will remain off until the RPM reaches On_High. Note that Off_Low and On_High are set to the same value. Off_Low turns the solenoid back on after reaching Off_High. I doubt the 200 RPM is critical.
The 2-step is controlled by the Neutral limiters and using them with the clutch pulled.
The autoshift C file I posted is not exactly what I have been using on my bike last summer. I adjusted the values to prevent the auto from shifting once it reaches fifth. Also the the trip point for detecting the shift was adjusted to compensate for the changes I made to the shifter harness.
I have been shifting at 8,000 with about 10 PSI boost. Been real pleased with the results. The Microtech continues to dump fuel, and when it comes off kill, there is a bit of a crack when the ignition lights all that fuel. It's real smooth.
The attached video shows the latest simulator. I now have a basic model for the bike, transmission and engine. Needs some work but making good progress. The ECM attached to the simulator is running the same load that is in my bike. You will notice that there is no kill after fifth and the bike does not shift into 6th. The video shows a small step about halfway into 2nd. This is the first attempt at modeling some sort of tire spin. The video also shows the current version of the data logger running on the same PC.
The price of the tablets has really dropped. About $200 now for a tablet. $150 for the LC2 wideband. $100 for a hub and two serial USB cables to tie to the wideband and the ECM. One problem is that it looks like Innovate are dropping the 8" tablet.
Added support for the Labjack into my logger software tonight. Like with my old logger, I am using the pulse counter to measure distance. The busa puts out the same number of pulses per shaft rotation as what I had done with my other bikes. So clutch data is not going to be any better or worse than what I had by just using the shaft and crank speeds.
Hooking it to the simulator was easy enough. MPH and tach are dead on as expected. Need to come up with a model for the clutch.
Hope to hook it up this weekend and try it out.
The data logger code was getting too hard to make changes to. After starting with just the ECM, then adding the wide band, then the GPS, now the Labjack, it was time to start over. Also made some changes to the simulator's hardware so the clutch can now be set to what ever sensors I end up using.
In the attached plots, the orange is the RPM reported from the ECM. The white is from the Labjack. The three pulls are identical except for how the data is being sampled. Each pull is roughly 8 seconds of data. On the left, data is being collected at 20Hz and the gauge cluster is being refreshed.
The attached is a zoomed in view of the left most pull.
Zooming in even further, it is easy to see the affects of refreshing the gauge cluster.
Zooming into the plot on the far right, the gauge cluster is no longer being refreshed and the ECM is putting out data about 15 times a second. The white graph is also showing the far right pull from the Labjack, sampled 100 times a second.
Video showing Labjack being used to look at simulated clutch data. Pretty long (10min).
Looking at some open source tools to make the model.