Engine monitoring methods

[Guest]

[rodekyll]

My right ear listens to the right side, and left listens to the left side.   I look at the rpms and speedo on occasion too

Kidding aside, this is a cool idea.

You're just bragging on having two ears.  I don't.   :

No, this doesn't mean you have to use caps to write to me.   

[Atavar]

Now if you really wanted to make it cool run it to a bright high contrast display, mirror image the video and point it at the windscreen like a HUD.

[rodekyll]

Now if you really wanted to make it cool run it to a bright high contrast display, mirror image the video and point it at the windscreen like a HUD.

That would be major cool.  I worked on a citroen once that had HUD.

The screen on my tablet flips every way but mirrored though.   

[Atavar]

Just do the software so the gauges move from right to left and spell everything backwards.. 

[rboe]

I'm pretty sure there is software out there to mirror the video display. Just make sure you have an equally cool screen saver.

While getting my bike run on the dyno I noticed all the cool info displayed by the dyno software. Seems to me that would provide a good deal of what you want (at a price you wouldn't want to pay...     ) but maybe something is available along those lines used or perhaps an old version that would be cheap.

Your laptop should have a video out so the laptop could reside in a tank bag or saddle bag while a remote screen can be used out in the elements. If you are going for ugly the monitor (flat screen for sure) could be encased in a large ziplock freezer bag or those cool underwater bags for cameras.

[charlie b]

For those who want a system made for this sort of thing:

http://www.bankspower.com/banksiq

There are also a couple of tuners out there that are interfaced with an iPod.  Most are simple data logging, but, some can give real time instrument displays.  Others are dedicated processors like the Banks setup.  Things are changing fast tho.  As soon as one offers a function (like GPS) the others will come out with an upgrade.  

Automotive units almost all interface through the OBDII so compatibility would be an issue.

You're on the right track RK.  The nice thing is A-D chip prices are very low (even fast ones) and you can buy ready made multiplexers and A-D processors that are plugnplay.  It is better to offload as much of the signal processing as you can, ie, pulse counting, A-D conversion, etc.  Leave the PC for logging and display functions.  The last time I messed with PC data acq the A-D chip cost me almost $100.  Had to hand wire a 64 to 1 multiplexer.

Look at places like Omega and National Instruments for some interface stuff.

charlie

[afbarr]

It is better to offload as much of the signal processing as you can, ie, pulse counting, A-D conversion, etc.  Leave the PC for logging and display functions.

I respectfully disagree on this point.  There is little point paying for extra hardware just for the sake of offloading processing if what you already have has the idle processing power "lying around" to easily handle these functions.  I believe you said you are using a laptop which has more than enough power to do the "pulse counting, A-D conversion etc." using software.  But hardware IS fun to play around with and if you are out to have fun then yeah, I would throw in some hardware just to learn how to do it.

[rodekyll]

The trick is finding the software.

[charlie b]

The reason I go to offloaded stuff is because of the non-real time function of the typical PC.  Really difficult to get proper timing unless you go to a real time operating system.  The Windows versions were expensive (haven't priced one for a while).  RTLinux is one I've used for this kind of stuff. 

If timing isn't critical, like reading a temp sensor, then using the PC directly is fine.  You still have to have an interface board of some kind (unless you already have a computer interface like on a car), so, having A-D, multiplexing and such on the board isn't that big a deal.

RK, I used to program my own stuff.  There were some for automotive use out there, at least a few years ago.  Have to find one that is flexible enough to reprogram the inputs.  I found a freeware program that was a "glass dashboard" but that was 6 yrs ago.  Am sure there are others out there these days.

[BillinAbilene]

Charlie is absolutely right, you have to have an interface board of some sort between the sensors and the PC.  The interface must have as many analog-to-digital converters as you have sensors (your voltage measurement is included in that count because it is done through an ADC input).

The tach input is different; it is not done through an ADC input.  Instead, it has to be done with a pin or device that is set up to count pulses compared to time.  On a Microchip PIC it is done using the ECCP feature (a "capture-compare" kind of input that can be linked to a timer built in to the PIC).

Many Microchip PICs have as many as 6 ADC inputs.  Many of those include an ECCP module.  Some can run as fast as 40MHZ, allowing them to process as many as 10,000,000 instructions per second (I don't think my Guzzi will go that fast, will it? ).

Many Microchip PICs in the above group also have built-in flash memory, allowing them to "store", say, 8,000 bytes of data.  (Do you see where I'm going with this?)

Now, let's consider this display thing everyone's been talking about (spoken with a cocky smirk).  With the exception of the tach, the sensors data coming from the wiring harness demonstrate a significant lag.  Not because the sensors don't have the data available in real time.  Instead, it's because the sensors “change” very slowly (the temperature sensor, for example).  And that’s okay, because the temperature of the engine changes rather slowly as well.  The oil pressure sensor is a different animal and it can “change” quicker, but is still not “lightning fast”.  So the sensors generally demonstrate some “lag.”

The next issue with the display is this, how fast can a human being perceive and process information?  We have all seen poorly-designed digital displays where the “units” digit (and maybe the “tens” digit) constantly changes – it’s almost a blur!  The problem with those displays is the programmer set them up to “refresh” too quickly.

Humans demonstrate a “psychological moment” of about 100 milliseconds.  That means that a stimulus has to persist for at least 100 milliseconds before it is perceived.  But, to be “processed,” the stimulus has to remain “constant” for around 750 milliseconds.  To me, readouts don’t need to “refresh” any faster than that.

Here’s the final issue I want to bring up.  Just how much information can a person “monitor” when involved in an activity (we’re talking “multitasking”, here).  Related to that issue is the “strategy” that humans use to find a “target” when searching a complex visual stimulus (like a “crowded” computer monitor).  The short version of this discussion is this, if there are more than three stimuli on the screen, the search to perceive and “acquire” the “target” will require a lot longer than a full second!  How long can you afford to keep your eyes off the road ahead when you’re riding your scooter?   And how much “distraction” can you handle before you’re at risk?  Personally, in this regard I don’t feel comfortable where this “onboard” PC thing is headed.  Can you say, “MOOSE!!!!!!!!!”

Here is my suggestion (I haven’t thought this through completely so take it with a grain of salt).  I can pretty easily build a PIC-based interface with 6 ADC inputs and a tach input that has the ability to capture 8,000 bytes of data; that’s easily 4,000 data points.  If need be, extra memory could be added to the circuit board to store more data points.  The unit would be “plugged in” to the “extra” sensors harness and, with the press of a button, would sample the sensors at a rate of about once per second.  It would stop sampling when the button was pressed again.

Once the desired data were gathered the unit would be removed from the harness and connected to the PC (using either the USB port or the serial port).  The stored data could then be uploaded to a Microsoft Excel file and analyzed and/or graphed using the tools in that software.

Parts would cost less than $100.

Just a thought.

Bill

[afbarr]

The trick is finding the software.

Same could be said for hardware.  Have you ever tried to find "the right" something as simple as a voltage regulator?  There are literally thousands of them that can be found on a website like digikey.com (try it).  At least it's not easy for me.  I write software for a living so I guess I'm inclined to say finding/writing/hacking software is easier than finding/soldering/interfacing hardware is harder.

[Wayne Orwig]

It you want to use a PC to do all of the work, you may as well plan on doing your own OS in order to make real time measurements. I have done a couple of such programs over the years in assembly language (a dead art). It is very time consuming. And you lose the graphical user interface and even things like USB ports and network protocols become worthless. If you want to sell/give this to someone else, they need the exact same hardware. I did this once with a NiCad battery tester/fast charger. My goal was minimal external hardware on the PC, and it worked. But I found it was not easy to transfer it to any other computers.

I would use separate hardware to do the initial acquisition and timing, then let a PC or PDA collect that data to display and store it. Not really that hard to do.

Many Microchip PICs in the above group also have built-in flash memory, allowing them to "store", say, 8,000 bytes of data.  (Do you see where I'm going with this?)

I've done a couple of programs now on the smaller PIC chips. They are as cheap as dirt. With the right chip you have all of the I/O, A/D and such in one chip. A small bit of signal conditioning, a program to collect data and upload it to a PC, and you are good to do.

[Wayne Orwig]

The trick is finding the software.

Same could be said for hardware.  Have you ever tried to find "the right" something as simple as a voltage regulator?  There are literally thousands of them that can be found on a website like digikey.com (try it).  At least it's not easy for me.  I write software for a living so I guess I'm inclined to say finding/writing/hacking software is easier than finding/soldering/interfacing hardware is harder.

But no matter what, you absolutely need hardware to do this. There is no plug in port for temperature, voltage, Lambda probes, etc., on a PC.

[afbarr]

Duh

[rodekyll]

I don't write code anymore and I don't want to relearn this modern tinkertoy approach to programming.  It's no longer my thing.  I'd be willing to pay a reasonable fee for help making the following happen.  And before you get all over me about wanting to monitor too much, consider the basic aircraft or marine pilot -- he's got more clutter than this to monitor.  Also, I don't need most of this stuff for driving the bike.  Things like head and pipe temps would be logged constantly, but only shown on-screen when I'm interested in what they say.  Things like the speed, tach, and oil pressure/temp I'd like constantly displayed.

     A/D Interface device to collect
     oil pressure x2
     oil temp x2
     head temp x2
     pipe temp x2
     air temp
     tach
     speed
     gps position
     volts

Optional sensors
     throttle position (tps angle)
     ignition timing
     inductive amp

Software to monitor, display, and log data
     update display 3xsec
     log data every 5sec
     export to excel
     finger/stylus touch capable
     'borderless' display (indicators float on a black background)
     meters can be shown/hidden with a finger tap to clear clutter
    

Display bar graphs, 'analog meters' and x/y
Display simple digit readout

Work with serial?  I know serial ports are getting harder to come by, but my current compter has one.  Maybe jumping straight into USB is the way to go . . .

The computer is a Panasonic Toughbook CF-19 (10.5" 1024x768 VGA display; 9.75 x 10.5 x 2.5"); 1.5Gb RAM; 1.1Ghz processor; will have WINDOWS 7 with tablet PC extensions and solid state hard drive.  It will live in a docking station between my fairing and the steering head.  The docking station will do the black box interface and will be permanently mounted to the bike.

Anyone interested in helping with development?

[afbarr]

In response to Wayne Orwig (since my post ended up coming after another):

My point wasn't that you don't need hardware to interface with the "real world", my point was that you don't need more processing power than what you already have on a laptop.  And *certain* (as opposed to *all*) functionality can be done via software.  Take music for instance, very few people use modular syntehesizers anymore.  Why?  Becuase doing sound sythesis on a computer (I'm talking designing the sound as opposed to playing on the speaker via a soundcard) is more flexible than using a dedicated hardware synth.  It's cheaper too -- alot cheaper.  You don't have to maintain the phyiscal synth, use patch chords, etc.  But of course we are talking two different things so take that anlalogy with a grain of salt.  So yes, you will need an ADC somewhere bewteen the computer and the sensor. I guess I wasn't clear on that.  Programming a chip is easy but not easier than programming a computer.  You can use a general chip's adc ports for converting the sensor signals from analog to digital if you want (as oppsoed to a dedicated adc) but you don't need a general chip for adc.  and just because you did decide to use a generla chip that has adc doesn't mean you should do any prgoramming in it *IF* you are already using a laptop for display purposes.  Why?  Because (as previsouly stated) it *easier* to program on a computer than it is on a chip.  Appologies for not being more specific about what I meant.  

This talk of needing to write you own mutlitaksing, real-time, blah blah blah OS is a little over the top -- geez  

Use RTOS (it's open source) for crying out loud  

[rodekyll]

My GPS/NAV software runs over WINDOWS, so I'm married to that operating system.  I don't want to turn this into an evil empire v opensource debate.  So let's just make WINDOWS a given.

If I do not use some type of hardware interface between my sensors and the computer, how do I attach 10 sensors via 1 serial port or 2 usb ports?

Can CAN be adapted to a guzzi?

[afbarr]

My guess (and it sounds like Wayne -- or some of the others -- could answer this better than I can) is that you could get away with one usb.  you would want to use a general programming chip with at least 10 analogue pins such as by Atmel (I am familiar with atmel chips because they are used in the arduino project -- http://www.arduino.cc/).  the atmel chip has a serial out pin where you could "multiplex" via "packetizing" the 10 (now digital) streams to the PC via a USB.  You could multiplex/packetize the 10 asynchronous sensor signals (inputs) by (essentially) "polling" each sensor signal one at a time in succession to generate a single output stream that goes to the PC via USB.  Your PC reads the stream by basically deserilaizes it into the individual sensor readings.  the "only" tricky part is packetizing it in a way that lets the PC know what reading belongs to what signal.  the polling/serializing/packetizing code will have to be written on the atmel (or pic or what have you) chip.  on the PC you write the deserializing/unpacketizing code (plus all the other logic related to analysing/display/recording, etc.)

[BillinAbilene]

We're recreating a CAN here.  How 'bout each packet is four bytes long.  The first byte is empty (a "null" byte) indicating new information is on the way.  The second byte is the unique address of the sensor (these addresses are based on some arbitrary list assigned by whomever).  The third and fourth bytes are the sensor/tach reading associated with that address.

I don't know from GPS input.  RK, does your GPS program have its own GPS sensor, like an EarthMate, that plugs into a USB port?

Bill

[afbarr]

We're recreating a CAN here.  How 'bout each packet is four bytes long.  The first byte is empty (a "null" byte) indicating new information is on the way.  The second byte is the unique address of the sensor (these addresses are based on some arbitrary list assigned by whomever).  The third and fourth bytes are the sensor/tach reading associated with that address.

I don't know from GPS input.  RK, does your GPS program have its own GPS sensor, like an EarthMate, that plugs into a USB port?

Bill

I had to look up CAN  which stands for "controller area network" (to save others the trouble).  Yes, that should do it (assuming you are using 16 bit ADC).  the null byte isn't so much for "new" as for delineating different "packets" (to think aloud and be semantically anal on my part and clarify for anyone else).  So you are looking at 40 bytes per unit time... i'm not sure what the baud rate of the serial out pin is but you can divide it by the 40 bytes to find out how often you can sample the sensors (it should be pretty fast though as you can guess).

Now the display.  I guess you could feed it into a Excel spreadsheet but that is klunky.  Someone mentioned a VB app.  That will work.  Personally, I would use Qt and then you have something that could display on Windows, Linux or a Mac (you never know where this would ultimately end up if it works and works well -- you may have fellow Guzzisti or motorcyclists wanting it too).

[afbarr]

The more I think about this, the easier it seems to do.  Programming the CAN algorithm would be fairly easy I think.  You could develop the algorithm and program the chip without having any of the sensors available (except 10 dirt-cheap (pennies apiece if I recall) thermistors to test with).  The CAN algorithm can and should be sensor agnostic (i.e., any sensor can at any time be added, removed, swapped, etc. without having to reprogram the chip).  It can and should not care how many sensors are attached, etc. (up to the chip's physical max analog pins).  It's really a super generic interface.  Adding, removing, swapping, etc. sensors will have to be taken into account on the PC-side of the equation but that can be done using an XML-based configuration file (for simplicity -- you could get fancy and be able to specify what pin is associated with what sensor via the graphical user interface which you already are using for display purposes).  The xml file would include info on how to convert the two byte reading into a range of human meaningful values (i.e., 93 mph as opposed to hex "34fe").

Well, the complicated part will be the GUI that displays the real-time info (and reads configuration files).  I suspect developing the PC-side GUI would consume 95% of the total time of this project.

[BillinAbilene]

I had to look up CAN  which stands for "controller area network" (to save others the trouble).  Yes, that should do it (assuming you are using 16 bit ADC).

Afbarr,

your programming class instructors are stamping their feet and yelling, "Noooooo...."  The reason to use two data bytes is the limitations of binary.  The highest number you can send with a byte of data is "255".  With two bytes of data you can send "65535".  My scooter can rev higher than 255 RPM.  I don't think it will make it to 65535 RPM, but you get my drift.

Microcontrollers have ADCs that vary in sensitivity.  Some have 8 bit ADCs, some have 10 bit ADCs, and some have higher (12 and 16 bit, but 16 bit is really mental masturbation).  10 bit ADCs allow some real flexibility.  You have to have two bytes available to capture and use/send their data.

Bill

[afbarr]

I'm not sure why you think I don't know that 2 bytes = 16 bits = 2^16 = 65536 combinations.   If you have a bike than can do 200 mph, you can measure to within 16.11 feet per hour accuracy

[afbarr]

10 bit DAC will allow you accuracy of 1031.25 feet/hour or 3.4375 inches per second  I think you get my drift

If you are happy with 10 bit DAC, then you can use the remaining bits it 2 bytes (6 bits = 2^6 to "address" the sensors).  You'll only need to use up 4 of those 6 "extra" bits to address 10 sensors.  You can use one of those 2 remaining bits to indicate a different packet so that really all you need are two bytes per sensor reading to make a CAN.  So that would be 20 bytes for 10 sensor readings.  But then you are reading bits not bytes and that complicates things.  Since you are not bandwidth constrained for this application i would stick to using 4 bytes for sheer simplicity.

[BillinAbilene]

I'm sorry if I upset you, Afbarr.  I was trying to kid with you about the reason to use two bytes for data.  Please acccept my apology.

Bill

[afbarr]

No worries, Bill, I wasn't offended   just making sure nobody else believed you about my profs

rodekyll, i don't think you would have a hard time with this project.  if you need help you can bounce ideas off me if you want (caveat emptor!).  i'd offer to develop the CAN algorithm and program a chip or help write the pc app (for no compensation) but I have too many other things going on at the moment (and would not feel good about committing to something I may not be able to finish).

[rodekyll]

I'm just soaking up the data points right now.  

The GPS is built in to to the computer as a card.  Think Wireless Internet SIMM.  It works with streets & tips and some other fairly basic gps software.  I'll know a little better about the specs and interface next week.

The excel file (or whatever we decide to graph with) is used forensically to analyse and plot curves.  I don't see it as being useful in real time unless I'm in 'tuning' mode and the bike is on the centerstand.  While on the road it would be dangerous.

Here's some sample gps signal:


Name = VESSEL TRACK - Created 4/19/2008
Type = Track
CreateTime = 2008-04-19 16:55:12Z
Hidden = FALSE
Locked = FALSE
Desc =
Color = 0x0000ff
ActiveVesselObjRef = 58ab88f0-41e1-41b9-8b3a-e1fc96c1335f
IsTracking = FALSE
ActiveVesselObjRef = 58ab88f0-41e1-41b9-8b3a-e1fc96c1335f
TrackingByTimeInterval = TRUE
TrackingTimeIntervalSeconds = 300
TrackingByDistanceInterval = TRUE
TrackingDistanceInterval = 0.540 nm
TrackingByCourseChange = TRUE
TrackingCourseChangeDegrees = 15.000000
TrackingWakeEnabled = FALSE
TrackingWakeTimeoutSeconds = 600
NumberOfTrackMarks = 126
ColoringValueType = -1
TrackShowDirectionArrows = FALSE
ColoringValueThresholds = 0,
TrackMarks = {{
56 36.84840 N 134 58.92870 W 2008-04-19 16:55:12Z
56 36.91290 N 134 59.23960 W 2008-04-19 17:00:12Z
56 36.91330 N 134 59.25230 W 2008-04-19 17:00:24Z
56 36.91080 N 134 59.26280 W 2008-04-19 17:00:31Z
56 36.90710 N 134 59.27010 W 2008-04-19 17:00:36Z
56 36.90200 N 134 59.27530 W 2008-04-19 17:00:41Z
56 36.89380 N 134 59.28040 W 2008-04-19 17:00:48Z
56 36.86130 N 134 59.30650 W 2008-04-19 17:01:31Z
56 36.83080 N 134 59.35830 W 2008-04-19 17:02:34Z
56 36.82640 N 134 59.37330 W 2008-04-19 17:02:48Z
56 36.82320 N 134 59.39870 W 2008-04-19 17:03:12Z
56 36.82390 N 134 59.42060 W 2008-04-19 17:03:34Z
56 36.82670 N 134 59.43590 W 2008-04-19 17:03:50Z
56 36.83230 N 134 59.45170 W 2008-04-19 17:04:08Z
56 36.83950 N 134 59.46390 W 2008-04-19 17:04:25Z
56 36.85640 N 134 59.47970 W 2008-04-19 17:04:54Z
56 36.89510 N 134 59.49870 W 2008-04-19 17:05:58Z
56 36.92550 N 134 59.49720 W 2008-04-19 17:06:49Z
56 36.95130 N 134 59.48150 W 2008-04-19 17:07:36Z
56 36.95710 N 134 59.47340 W 2008-04-19 17:07:48Z
56 36.96930 N 134 59.44750 W 2008-04-19 17:08:18Z
56 36.97610 N 134 59.43370 W 2008-04-19 17:08:34Z
56 36.98160 N 134 59.43000 W 2008-04-19 17:08:44Z
56 37.03950 N 134 59.39800 W 2008-04-19 17:10:18Z
56 37.05090 N 134 59.37520 W 2008-04-19 17:10:45Z
56 37.13820 N 134 59.12830 W 2008-04-19 17:15:02Z
56 37.16480 N 134 59.10530 W 2008-04-19 17:15:53Z
56 37.18780 N 134 59.09850 W 2008-04-19 17:16:33Z
56 37.26240 N 134 59.08890 W 2008-04-19 17:18:42Z
56 37.28810 N 134 59.06190 W 2008-04-19 17:19:39Z
56 37.31850 N 134 59.00850 W 2008-04-19 17:20:52Z
56 37.38880 N 134 58.85270 W 2008-04-19 17:24:07Z
56 37.39420 N 134 58.84890 W 2008-04-19 17:24:19Z
56 37.40290 N 134 58.84660 W 2008-04-19 17:24:36Z
56 37.43520 N 134 58.85310 W 2008-04-19 17:25:28Z
56 37.44010 N 134 58.85900 W 2008-04-19 17:25:38Z
56 37.44600 N 134 58.87060 W 2008-04-19 17:25:52Z
56 37.46160 N 134 58.91330 W 2008-04-19 17:26:35Z
56 37.49010 N 134 59.03160 W 2008-04-19 17:28:20Z
56 37.49880 N 134 59.04420 W 2008-04-19 17:28:39Z
56 37.52080 N 134 59.06300 W 2008-04-19 17:29:20Z
56 37.57160 N 134 59.07960 W 2008-04-19 17:30:42Z
56 37.60020 N 134 59.07770 W 2008-04-19 17:31:29Z
56 37.60760 N 134 59.07170 W 2008-04-19 17:31:45Z
56 37.61400 N 134 59.06220 W 2008-04-19 17:32:01Z
56 37.61820 N 134 59.05070 W 2008-04-19 17:32:17Z
56 37.61990 N 134 59.04020 W 2008-04-19 17:32:29Z
56 37.62100 N 134 59.01870 W 2008-04-19 17:32:51Z
56 37.61920 N 134 59.00870 W 2008-04-19 17:33:02Z
56 37.61150 N 134 58.98720 W 2008-04-19 17:33:26Z
56 37.59630 N 134 58.96270 W 2008-04-19 17:33:59Z
56 37.58220 N 134 58.93630 W 2008-04-19 17:34:32Z
56 37.56360 N 134 58.90050 W 2008-04-19 17:35:15Z
56 37.55290 N 134 58.89070 W 2008-04-19 17:35:34Z
56 37.54330 N 134 58.88740 W 2008-04-19 17:35:56Z
56 37.53030 N 134 58.88770 W 2008-04-19 17:36:10Z
56 37.52480 N 134 58.89210 W 2008-04-19 17:36:20Z
56 37.51860 N 134 58.90140 W 2008-04-19 17:36:31Z
56 37.51160 N 134 58.91900 W 2008-04-19 17:36:43Z
56 37.47630 N 134 59.03200 W 2008-04-19 17:38:13Z
56 37.46700 N 134 59.04170 W 2008-04-19 17:38:31Z
56 37.45090 N 134 59.05030 W 2008-04-19 17:38:58Z
56 37.40950 N 134 59.05770 W 2008-04-19 17:40:03Z
56 37.27590 N 134 59.03920 W 2008-04-19 17:43:34Z
56 37.25750 N 134 59.05160 W 2008-04-19 17:44:04Z
56 37.08250 N 134 59.20320 W 2008-04-19 17:49:04Z
56 37.05970 N 134 59.23040 W 2008-04-19 17:49:47Z
56 36.99780 N 134 59.33250 W 2008-04-19 17:51:58Z
56 36.99620 N 134 59.34200 W 2008-04-19 17:52:05Z
56 36.99650 N 134 59.35330 W 2008-04-19 17:52:12Z
56 36.99600 N 134 59.40140 W 2008-04-19 17:52:50Z
56 36.99160 N 134 59.42090 W 2008-04-19 17:53:09Z
56 36.98590 N 134 59.43290 W 2008-04-19 17:53:24Z
56 36.95380 N 134 59.47830 W 2008-04-19 17:54:28Z
56 36.94040 N 134 59.48760 W 2008-04-19 17:54:50Z
56 36.92770 N 134 59.48900 W 2008-04-19 17:55:14Z
56 36.91550 N 134 59.48460 W 2008-04-19 17:55:35Z
56 36.87190 N 134 59.44630 W 2008-04-19 17:56:49Z
56 36.86130 N 134 59.43090 W 2008-04-19 17:57:11Z
56 36.85360 N 134 59.41020 W 2008-04-19 17:57:35Z
56 36.84780 N 134 59.38360 W 2008-04-19 17:58:03Z
56 36.84390 N 134 59.30670 W 2008-04-19 17:59:19Z
56 36.85540 N 134 59.21170 W 2008-04-19 18:00:46Z
56 36.86570 N 134 59.14840 W 2008-04-19 18:01:47Z
56 36.86440 N 134 59.13760 W 2008-04-19 18:01:58Z
56 36.85970 N 134 59.12020 W 2008-04-19 18:02:16Z
56 36.83940 N 134 59.06000 W 2008-04-19 18:03:17Z
56 36.83940 N 134 59.04790 W 2008-04-19 18:03:29Z
56 36.84420 N 134 58.95910 W 2008-04-19 18:04:49Z
56 36.83880 N 134 58.93530 W 2008-04-19 18:05:16Z
56 36.83270 N 134 58.92320 W 2008-04-19 18:05:34Z
56 36.82600 N 134 58.91500 W 2008-04-19 18:05:49Z
56 36.72260 N 134 58.82460 W 2008-04-19 18:08:57Z
56 36.58050 N 134 58.76880 W 2008-04-19 18:12:57Z
56 36.51860 N 134 58.70630 W 2008-04-19 18:14:53Z
56 36.47330 N 134 58.69770 W 2008-04-19 18:16:05Z
56 36.43660 N 134 58.70600 W 2008-04-19 18:17:03Z
56 36.30660 N 134 58.75530 W 2008-04-19 18:20:39Z
56 36.30120 N 134 58.76480 W 2008-04-19 18:20:51Z
56 36.29310 N 134 58.78710 W 2008-04-19 18:21:15Z
56 36.28850 N 134 58.81250 W 2008-04-19 18:21:39Z
56 36.28480 N 134 58.89330 W 2008-04-19 18:22:49Z
56 36.29470 N 134 59.00050 W 2008-04-19 18:24:24Z
56 36.30760 N 134 59.05620 W 2008-04-19 18:25:20Z
56 36.31520 N 134 59.07160 W 2008-04-19 18:25:41Z

[rodekyll]

I'm not asking for something for nothing.  If someone wants to help me, I'll help them.  If it works good, we might have something others might want (and pay for).  It should be a win situation for everyone.

[afbarr]

you can probably easily take that gpa time series and use Google Maps API (http://code.google.com/apis/maps/) to plot the long lats you have (in real time or from a file) on a google map on a local (to your computer) webpage.

[rodekyll]

The gps data is already being shown as a plot on a rolling map.  The example above is a marine location, but the gps doesn't care where it is.

[BillinAbilene]

Okay, off-list Rodekyll and I exchanged emails and it was agreed I would build the interface to “prove concept” of what I propose we call the “Rodekyll-HavinsDesigns CAN”.  I will begin development of the circuit design and interface software (not the PC-based software).

The proof-of-concept goal is to demonstrate the ability to continuously gather sensors data and communicate those data to a PC in “data sets” that can be analyzed in software and/or displayed in a PC-based GUI (graphic user interface – that’s “pictures” to some ).

I propose that this proof-of-concept circuit include inputs for three sensors and one pulse-based input (the tachometer input).  The three sensor inputs will be configured “generically”; any analog sensor can be connected to any of the three inputs.

The proof-of-concept circuit will include a Microchip PIC microcontroller adequate for those tasks implied in this posting.  The circuit will also include a MAX-232 chip or similar and a DB-9 connector that will allow the PIC to communicate with the PC via standard RS-232 voltage levels over a “serial cable”.  The circuit will also include all voltage regulator(s) and passive components necessary to achieve the proof-of-concept goal.

Software written and “loaded” in the PIC will gather data from the sensors and pulse-based input, and communicate those data in formatted “packets” to the PC via the RS-232 link (above).  (The term “formatted packets” is used her consistent with typical CAN terminology but does not imply that the format of the packets is consistent with other implementations of CAN).

If anyone has any objections to the above post them now or ….whatever….

(See, that's what you get when you wish for something boring to read that will put you to sleep....What do you mean all you got out of this was heartburn?)

Bill

[afbarr]

rs-232? ughhh   i think using a usb protocol would be better if for no other reason that rs-232 is effectively "deprecated".  newer platforms don't even have rs-232 (i don't recall the old mac we have at home having an rs-232).  but since i'm not programming the chip, soldering the components, building the interface, etc. i really should keep my mouth shut shouldn't I 

[charlie b]

And I was thinking Bluetooth since USB is old and outdated

But, I am in the same boat, if not contributing keep quiet

You guys do know that you could create a new 'standard' in motorcycle interfaces, like the automotive OBDII?

Those PIC controllers are really cool aren't they?  Used one a while ago for a robot project.

Have fun guys and good luck.  Will be watching with great interest.

charlie

PS if you want someone to test on a different bike will be willing to help debug it.  Will even buy my own hardware (or from you guys).

[BillinAbilene]

"Proof-of-concept" = do-it-cheap (and with parts on hand that will likely never be used otherwise).  Bells-and-whistles come much later.

Bill

[BillinAbilene]

Continuing with the "proof-of-concept" interface, I intend to include voltage (from the charging system), pressure and temperature.  The  latter two will be connected to VDO sending units (duplicates of exisitng sending units; see descriptions, in an earlier RK post).

The tach signal will come from the available tach wire in the wiring harness (thanks, EV L!)

Adding to the bells-and-whistles wish list, I have been able to get my electronic vacuum gauge to work quite nicely on the bench.  (It compares the vacuum at the left and right carburetor inlet manifolds, identifying which cylinder is "pulling" harder - an indication of carburetor synchronization).  I don't know if it is a "bell" or a "whistle" - probably a whistle....

Bill

[rodekyll]

rs-232? ughhh   i think using a usb protocol would be better if for no other reason that rs-232 is effectively "deprecated".  newer platforms don't even have rs-232 (i don't recall the old mac we have at home having an rs-232).  but since i'm not programming the chip, soldering the components, building the interface, etc. i really should keep my mouth shut shouldn't I 

Afbarr -- we didn't mean to upset you.  You're invited to join.  We still need someone to build the UI.  We could sure use your help.

The rs232 part is just for the proof of concept.  I agree that with the increasing scarcity of traditional serial ports on computers the USB option is the better one.  My particular computer has a 9-pin serial port, so we're starting with that 'just because'.  In the big picture it should work either way.

I have a personal bias against bluetooth.  Aside from the utterly stupid name, I find it to be slow, clunky, unreliable, and fickle.  Kind of like wireless communications if they were built by the OCC crew.  Naturally, if we were to market this as a product, we'd need to develop it in the directions that the money comes from.  If that's bluetooth, then we build for it.

Ideally this setup should work on almost any gas vehicle that has or can be fitted with analog sensors, and it should be able to work with a wide range of computers, dataloggers, and PDA's.  It would be able to replace a dashboard entirely, if we added 'indicator bulbs' to the UI.  So a guy could either use it in the shop to tune and tweak, on the road as a real-time dashboard replacement, or connect it to the sensors and have a scenic while collecting engine data under various loads and speeds.  "The World is your Dyno"

[Wayne Orwig]

The proof-of-concept circuit will include a Microchip PIC microcontroller adequate for those tasks implied in this posting.  The circuit will also include a MAX-232 chip or similar and a DB-9 connector that will allow the PIC to communicate with the PC via standard RS-232 voltage levels over a “serial cable”.  The circuit will also include all voltage regulator(s) and passive components necessary to achieve the proof-of-concept goal.

I would go with simple TTL level 232 serial. It isn't 'true' RS232 and won't be able to drive a serial line 4000 feet, or whatever the spec calls for, but will be fine for a local run. I've done this on a number of projects and it is reliable.

[Wayne Orwig]

rs-232? ughhh   i think using a usb protocol would be better if for no other reason that rs-232 is effectively "deprecated".  newer platforms don't even have rs-232 (i don't recall the old mac we have at home having an rs-232).  but since i'm not programming the chip, soldering the components, building the interface, etc. i really should keep my mouth shut shouldn't I 

The issue with USB is that you need to develop a driver for the PC end, or limit yourself to the generic HID interface. Then you need the driver and full USB stack on the remote data collection end. That may require licensing expensive software, or finding a chip that manages it internally. Then your controller would be spending time handling USB polls, like enumeration packets and such, instead of doing the job of data collecting.

I would put a USB / 232 adapter in the box and tell people it is USB.. 

[afbarr]

Afbarr -- we didn't mean to upset you.  You're invited to join.  We still need someone to build the UI.  We could sure use your help.

No worries!  (I must come across as a sensitive guy)  I think you guys are going to have fun with this.  Bill, writing the CAN algoithm will be fun since it seems amenable to a very elegant algorithm.  Any wireless can be flaky becasue of interference so going "wirefull" is a good first step.  The CAN algorithm is independent of all that anyway so swapping out a different chip-to-pc communication protocol is not going to be problematic later on down the road.  The pia (assuming you want something "modern" (i.e., slick and intutive)) will be the display gui.

Good luck guys -- this will be interesting to follow!

[charlie b]

I wish I still had the code from my glass dashboard project.  It was for a Linux box, but, was in C++ so would have been portable.  Oh well.  The indicators are pretty simple to program for what you want.  I decided on a light bar for digital output (green/red/yellow) and two instruments that were selectable for function.  It worked really well.  But, was not one of those slick windows things with buttons and sliders.