Thread: Return of the onboard wooly computer

Originally Posted by seamus

It's a connector EE's use to connect Waldoms.

Or, they are the connectors at the ends of those flat, ribbon like cables in computers.

The correct answer is they are like Molex connectors

That's what I said.




Pay no attention to the last edited line. The site's having some technical issues with it's Waldom connectors.

Now that that's out of the way. What problem are you having with the Waldom/Molex connectors? When I installed my aftermarket turnsignals, I bought connectors and such to make them pop on and off for track days. Getting them apart was a PITA but I figured out some tricks.

So I had the computer hooked up in the car running off the lighter. The GPS was hooked to the internal power supply so every thing is contained as on bike. I also logged some data to play with and ran a lap timer to compare to later.

I still have an occasional problem getting the GPS sentences to sync but I think this is a serial port setup issue.

Next I will be working on adding to the computer
A) getting wireless connectivity setup
B) using the GPS to calculate a laptime
C) getting the Gyro and Accelerometer sensors connected
D) improving the case
E) connect to my LCD

On the s/w front
A) fix my port issue
B) create coordinate transformation formulas
C) create formulas to detect start of session and end of session (likely triggered on speed threshholds)

What you're not going to measure chain speed, or spark voltage, or valve stem torque, or seat load, forget that last one, or coolant viscosity, or oil particulates. SLACKER !

intake air velocity, exhaust pressure, brake pad friction, fuel vaporization rate, (sorry that should be atomization), make that fuel tank vaporization and fuel injection atomization.

Add that all up and you get pancakes on the gas tank.

Uhm, RAHVFR ... that last post is as disturbing as your avatar. You need to get out of the office more, and no, your personal engineering library does not constitute getting out of the office, just exchanging offices.

In the meantime, Frenchie gets faster and faster....

Originally Posted by CBRVFR

In the meantime, Frenchie gets faster and faster....

Yes but I will be able to document it

Originally Posted by SheepOfBlue

Yes but I will be able to document it

[quote=Shenders1;49704]

Originally Posted by RAH-VFR

Piston-to-bore clearance, conn rod stretch, effective C/R, main journal oil film thickness, cylinder power balance, individual injector pulse widths...

So many metrics, so little time.
.

I agree its a great project.

Conn rod stretch vs Sheep's corner speed anxiety.

a log scale plot for sure.

next project will be to measure his own physical going ons. such as heart rate, brain wave activity, oxygen intake, and don't forget all that stuff gets translated into "sphincter pucker factor"

Originally Posted by Shenders1

...If you can make this thing work and be small enough to actually fit on a bike, someone will want to buy it. Of course you'll have to write a Windows interface for it at that point.

If it's the device I saw sitting on his desk in his mainframe room, it's definitely something that will fetch some pretty pennies in the near future.

Originally Posted by seamus

If it's the device I saw sitting on his desk in his mainframe room, it's definitely something that will fetch some pretty pennies in the near future.

Yep it was the pile of wires in Command Central

Shenders1 I really have no plans on marketing this beast. Though I am debating on what to write the post processing s/w in. Certainly it will be Mac as that is my main computer but I am considering something like Python or wxWindows so it runs on both. The runs on both is a bit relative in that Windows uses a different thread and communications model than everything else so there would be some custom code to accomodate it. If I use Python or wxWindows the port to Linux would take longer to test than code (maybe no changes at all)

Originally Posted by Shenders1

Remember that Far Side cartoon where the master speaks to his dog and the dog hears "blah-blah-blah Fido! Blah-blah-blah-blah Good Dog!" ?

Well, now I know how that dog feels.

My programing expertise peaked with QuickBasic 4.5.

Anyhow - This project really has my interest. As an Engineer by training, I feel a deep need for huge amounts of data, even if it's not entirely useful. I suspect a couple of you may empathize.

Gonna bring your prototype to Grattan?

I doubt it will be ready to be in the bike yet but I can bring the pieces

I would be interested in duplicating your project for my own bike...would you have a parts list and cost...are you willing to build another one and sell it?

Originally Posted by smoothrideronli

I would be interested in duplicating your project for my own bike...would you have a parts list and cost...are you willing to build another one and sell it?

I would share. Most is in the thread, the issue will be s/w and the host computer for post processing. But as I have said this is not a project I recommend for nontech person. There is some slick systems out there but I wanted total control and the ability to add stuff and as Shenders said there is no such thing as to much data Also being a BSEE by training and programmer by trade this has been a knowledge expander for me

I think I would be ok with the hardware part...its the programming part that I would probrably need help with.

The s/w and setup for Linux (the board OS)

Originally Posted by smoothrideronli

I think I would be ok with the hardware part...its the programming part that I would probrably need help with.

Even a caveman can do it!

So I have checked out the GPS data I collected and have a basic laptimer algorithm:
1) receive the GPS sentence
2) filter everything except $GPRMC
3) if laptiming is not on check speed, if it is above 50 knots for 5 sentences start counting at that sentence
4) if laptiming is on check speed, if it is below 5 knots terminate laptiming
5) if laptiming is on pause for 30 seconds after first point.
6) if laptiming is on check (lat1 - lat0) or (lon1 - lon0) to see if the sign has changed (this will occur when you cross the parallel or horizontal to the original point). If it has calculate the distance between the point and the saved point. If it is within 10 meters interpolate to calculate lap time. Write to log and LCD display.

The first check is used to reduce computational load as the distance calculation involves floating point and trig functions.

Next I plan on starting the application as I need the control code (on/off) in a main thread with the GPS code in a seperate thread. As I add the Gyro and Accelerometer sensors they will have an independant thread also.

Originally Posted by SheepOfBlue

As I add the Gyro and Accelerometer sensors they will have an independant thread also.

Make sure if you sense any gyros that you give me a call. I like the ones with just lamb.

Also, if you end up in the swampland around turn 5 to have the gizmo send up a flare.

Originally Posted by CBRVFR

Make sure if you sense any gyros that you give me a call. I like the ones with just lamb.

Also, if you end up in the swampland around turn 5 to have the gizmo send up a flare.

Bah! you have a laptimer now

Originally Posted by CBRVFR

Make sure if you sense any gyros that you give me a call. I like the ones with just lamb.

Also, if you end up in the swampland around turn 5 to have the gizmo send up a flare.

2 flares, the first one to cook the lamb the second to tell us when its ready.

No progress as I am setting up a new computer

But this is COOL and I have access to an SPI interface