Jump to content
Sign in to follow this  
abecedarian

I've a motorcycle I want to build a "custom" dashboard for.

Recommended Posts

Is a single MSP430 up to sampling RPM's (up to 22,000) and vehicle speed (using a hall-effect sensor) simultaneously?

Maybe I should specify that the RPM would be sampled from one coil which fires every revolution of the engine.

I assume I would have the tach sensor output would be connected to one MSP input and the speed sensor to another.

They could be single-bit digital inputs, as the board would be counting pulses and not doing any ADC, correct?

 

 

Any thoughts on using this display?

 

http://www.ebay.com/itm/2002-LCD-Module ... 3378a37208

 

I may also consider using a bar-graph LED display in addition to alpha-numeric for the tach, probably 40 LED.

Any thoughts on that?

Share this post


Link to post
Share on other sites

To read rpm,the easy way is to use an external interrupt, and count how many pulses the micro receives in a know time base(this requires a timer) and then divide the pulses number by the time base, for example, set a timer to overflow every 100ms, the code in the timer ISR would be something like this:

rpmVal = intCount *600;
intCount = 0;

 

The intCount var is the variable that stores how many interrupts have passed, and as the time base is 100ms to have rpm you just need to multiply by 600 ( 0.1s * 600 = 60s).

Share this post


Link to post
Share on other sites

Thanks for that.

So something like a timer set to fire an interrupt every 1/4 second, and its ISR does the math, display update and clears the rpm and speed counters, and an interrupt for each speed and rpm which each increment the respective counter? Or maybe the timer interrupt should copy the rpm & speed counters then clear them, then do the math and display update to minimize the chance of a speed interrupt incrementing the value while its being worked with?

 

Bear with me, I'm new at this. ;) Basically would be needing 7 variables (not including the display side of things)?

I could set the timer to interrupt more often and use that to "smooth" or average the working variables for display purposes?

Say:

timerTicks = integer representing the number of timer interrupts within the chosen "sample" time

ignitionCount = integer representing the number of ignition triggers since last count reset

wheelCount = integer representing the number of wheel rotations since last count reset

tempIgnitionCount = integer mirroring the value of ignitionCount when the timer interrupt occurred, used to calc for display

tempWheelCount = integer mirroring the value of wheelCount when the timer interrupt occurred, used to calc for display

avgIgnitionCount = integer used to smooth / average ignition events over multiple events (oversampling) for a stable display

avgWheelCount = integer used to smooth / average wheel rotations over multiple events (oversampling?)

 

 

I'm thinking of updating the bar-graph side of the tach display ever 1/4 second or maybe more often to mimic the typical analog tach, and updating the numeric side every 1/2 second... and maybe some fuzzy logic where if the rpm's haven't changed more than +/- 50 from the last calculation, keep the existing value on the display, but if it's changed more than that anticipate what the next display should be based on the current rate of acceleration / deceleration.

 

The speed display should be okay updating every 1/2 second, and maybe similar logic as the ignition where if it hasn't increased +/- 2 from the last display update, don't change it but if it is changing rapidly anticipate what the next reading should be.

 

So, more variables to represent rate-of-change.

 

 

 

This is an ambitious project for a noob, isn't it? :)

Share this post


Link to post
Share on other sites

Two LaunchPads decided to move in with me today. (Thanks 43oh!)

 

I think I'll set one up to simulate the engine and speed triggers: have it simulate increasing engine speed from 300 to 10000 rpm's, calculate vehicle speed based rpm's and gear ratios, then convert that to one pulse output per revolution of the front wheel. The second will take the outputs from the first and convert those to display... I just have to work out a display now. :)

 

In the mean time I suppose I could set a breakpoint when the display code is supposed to be called and check the variables in the debugger.

Share this post


Link to post
Share on other sites

I figure if I have to answer to my username, I should behave accordingly....

 

As mentioned before, I have two MSP430 LaunchPads now (supplied by ... shameless plug: 43oh.com!) I opened a box, connected it to my USB hub and everything was fine- lights-be-der-blinken and we rejoiced- "yay". Played a bit in CCS and had more of dem blinken lights. Decided to follow the user guide and such so re-loaded the temp-gui stuff, reset, and the GUI on the computer held around 248 or so, with intermittent dips to 128 and 0. I made sure the port was set to correctly and still nothing.

 

Swapped one board out for the other and the same thing: it was 248* and spurious dips.

 

I thought about things and realized I had the LPad plugged in to a USB-hub so I bypassed the hub and now have consistant, and more importantly accurate temperature readings.

 

But I'm not sure why that would happen.... Any suggestions?

 

I work with cellular (GMS/UMTS/LTE) equipment and have downloaded things from test equipment through the same hub without issue, so why would this act up?

 

The baud on the MSP is 2400, (the 2553 is capable of faster but the demo is limited for compatibility), correct?

And the test equipment I offload from is 38.4K and higher.

Share this post


Link to post
Share on other sites

From what I've heard the baud on the MSP430 should be set to 9600, as that's the hardcoded data rate on the "Emulation" layer chips at the top of the launchpad board. (A pity, really, that you can't set the baudrate to anything you want--like an Arduino can... but I guess that's the cost of having a $4.30 dev board.)

Share this post


Link to post
Share on other sites

Correct - it's not the LP itself, the emulation/debug side of the board is hardcoded to 9600. As far as I know, 2400 shouldn't even be working. It may be because the initial V4 release of the board had chips that only supported software serial - not hardware like the 2553. Or possibly because faster serial is unstable without the aid of a crystal?

 

You could certainly use a faster serial -> PC connection with an FTDI chip. I've seen projects on the forum where one was used to offload a lot of ADC data from the chip (I think it was oPossum or SA's project)

Share this post


Link to post
Share on other sites

The user guide pdf states, on page 8, "The serial communication port on the PC must be configured with 2400 bps, one stop bit...."

I don't know- I'm new at this and figured I'd start out like any joe plumber: square one.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...