Showing results for 
Search instead for 
Did you mean: 

Corrections on my VI concept?


So for my final project for a class, I decided that I wanted to use LabVIEW to control two functions on my motorcycle:


1.  When I click the lock button on my wireless remote control (which causes my bike to emit ONE short beep and the hazard lights to flash ONCE), I want my MyDAQ to use the frequency from the hazard light wires to allow power from the battery to flow to the ignition relay and start up the motorcycle.  Alternatively, when I click the unlock button on my remote (my bike will emit TWO short beeps and the hazard lights flash TWICE), I want my MyDAQ to use that change in frequency from the hazard light wires to allow power to the kill switch and turn off the motorcycle.


2.  I want my MyDAQ to comprehend the voltage difference in the engine thermostat to allow voltage from the battery to turn on the radiator fan when the engine temperature is between 150 and 182 degrees Fahrenheit.  The ECU threshold is 177 to 182 degrees Fahrenheit.  I want the fan to stay on even if the engine is not running (in which case, I want to make an indicator or boolean on LabVIEW say: "Override engine cooling" to show that the fan should be running if the engine is still too hot. 


Here are my understandings and research. Does anyone have any information, suggestions, corrections, comments, etc.?  Anything would help, I kind of struggled with this class though I love every minute of learning about controls and automation.  Thank you in advance!unnamed.jpg 

Message 1 of 9

Many things are unclear about your "project".

  • What is "real" and what is metaphor?  For instancce, do you really have a myDAQ?  Are you talking about a real Motorcycle?  What is this "Wireless Remote Control"?  Are you hoping to "sense" the "short beeps" (not defined) and hazard light "flash" (how sensed?).
  • I noticed you didn't post any LabVIEW code.  Instead of scribbles on a piece of paper, a VI showing (some of) what you are considering would tell us a lot.  We could see how you plan to use the myDAQ, whether you are using Analog or Digital I/O (or both), how you are incorporating the concept of "time", etc.
  • What are you using to measure temperature (or is this being simulated)?  How are you planning to interface this sensor with the myDAQ?

Bob Schor

0 Kudos
Message 2 of 9

A few more thoughts in no particular order (Assuming we are talking about a real motorbike:

  • It is worth considering the safety implications of you motorbike starting automatically
  • Why do you want to change the temperature that the fan turns on
  • The MyDAQ has a max analogue voltage of ±10V and a digital voltage of 5V. Most vehicles and bikes as far as I know work on 12V. You will therefore need to make sure that you shift the voltage down to a safe level for you hardware

Answers to a couple of comments on your page:

  • You will only need one MyDAQ to control both aspects of your project 
  • I doubt Kawasaki will give you any information on the ECU. Depending upon what bike you have (And don't know alot about bikes anyway) you may be better off bypassing the ECU entirely for both of these functions. The ECU will just be providing a low current signal to a relay to turn on both the starter motor and fan. Having said that when starting the engine there may be other things that the ECU does simultaneously (Regarding fuel supply etc) so you may be better off simulating someone turning the key.
  • You are probably better off trying to find a wiring and matenance manual for your bike

I'll be honest though there are so many safety implications of this I really would think carefully about what you are trying to achieve.

0 Kudos
Message 3 of 9

Okay, to clear some things up:


I do have a MyDAQ.

Yes, this is including a real motorcycle.

The wireless remote control is just the same as a fob for a car. 


The short beeps are loud and much like ones when locking/unlocking a car, but I don't want the MyDAQ to sense the beeps (audibly), but the frequency of the beeps from the voltage that goes to the horn.


The lights that fash are just the turn signals. They are just a physically visual indicator to the user that the vehicle is being locked/ unlocked (as a car would).


I have not written the code yet because I am still trying to visualize how this will be set up physically.


The temperature is being taken from the engine thermostat that is already on the motorcycle.


I plan to interface the thermostat with the MyDAQ by probing the wires connected to the thermostat and connecting them to the AI channel of the DAQ


Thank you for the feedback.

Will Price

0 Kudos
Message 4 of 9

Thank you for your feedback!


The first consideration when I thought of this project was safety. My professor wanted our final to be something complex (with no sort of rubric handed out or ideas of what to include). Everyone decided to go all the way in complexity in hopes that he would at least say that our final project concepts were "good enough". Now he says that most of us have bitten off more than we can chew, but with no other corrections or guidance we are unsure of what to subtract or completely discard from our projects. Maybe I'm just looking to change my project entirely to something I can handle, but also include at least one of my passions. 

0 Kudos
Message 5 of 9


     Thank you for your responses.  I'm also glad that you've thought about how you might implement this Project with a "real motorcycle", and are also cognizant of some of the "problems" with poking around with The Real Thing.

     Putting on my Professor Hat (funny shape, about 30 cm square cardboard glued to a beanie, with a silly tassel hanging down), I'd ask "What's the Point of this Project?", or, alternatively, "What is the Title of this Project?".  You aren't attempting to make a Controller for your motorcycle, nor are you attempting to create a system to "Monitor Motorcycle Systems during Real-World Driving Conditions", or something like that.  If I had to come up with such a title, it might be "myDAQ and the Kawasaki XXXX".

     Not to say that wouldn't be a valid Project, but what would be the point?  Well, for one thing, you are proposing monitoring several different sensors and actuators, all running in parallel, and "doing various things" based on the readings you get.  You've connected "real" sensors and actuators, have a "real" instrument (the myDAQ) that could take the readings, and have "real" problems in actualizing your concept (including such things as matching the signals to and from the myDAQ and the signals to and from the components of the motorcycle (including its key fob).

     As a First Step, I'd leave the actual motorcycle out of the proposal, but would leave its "components" (the signal generators and actuators, for which you might not yet have actual knowledge of voltages, currents, frequencies, etc. involved) in place.  In place of the physical bike, create a simulated bike, with simulated components. 

     An exception could be the key fob -- how were you planning to intercept and decode its signals?  Are you building a little radio (or whatever it uses -- ultrasound?) receiver that you'd interface to the myDAQ?

     As an exercise in LabVIEW, this isn't a bad Project.  You have multiple independent, asynchronous Loops, multiple sensors, multiple actuators, multiple decision points.  You have the myDAQ that expects (and generates) analog and digital signals of specific ranges and frequencies, and you have the Bike where the signals may need "conditioning" or "modifications" to interface properly with your LabVIEW Hardware.  You want something that is modular, parallel, where components can be added or subtracted (why not allow, for example, the easy addition of a temperature sensor on the Brake Pads to warn you if you are braking too hard, or a "Cruise Control" setting to keep the speed constant?).


Bob Schor


Message 6 of 9

I would begin by studying the aftermarket remote starter add-ons to get a firm understanding on how they do it and why they do it the way the do. As I am sure there are some safety concerns none of us have thought of that need to be considered. 

Unfortunately, most readers of this Forum, including some real Experts, have not mastered the skill of being able to read the code that Posters fail to post. If we cannot see "what you did wrong", we are unable to tell you how to fix it. (Bob Schor 28 August 2018)
0 Kudos
Message 7 of 9

Thank you for replying and with much information!


The point of this project, in general, was to show that we know how to create systems and circuits using the software and hardware that we purchased from my school.  I like the idea of simulating a virtual motorcycle, but I believe one of the components of the project was to sort of control a physical component using the software. He did give us a rubric (I misspoke), it just seems very abstract and vague.

0 Kudos
Message 8 of 9

For fun, I developed an NTP server monitor for my Raspberry PI which drove real LEDs to give status, not unlike a cable modem.  Blinking yellow = PI has booted, NTP daemon not started.  Solid yellow = NTP daemon started.  Blinking blue = syncing.  Solid blue = NTP running, sync'd with server(s).  Solid red = an error occurred.


I guess something like that would check all the boxes.  I guess as a bonus, it would show that you can deploy LabVIEW code to a target.  I made my code run on both the PI with real LEDs and on Windows, with fake LEDs, just for an extra challenge.


The reason I mentioned it was because it's a lot cheaper to blow up a PI than a moterbike.  😉

(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 9 of 9