rallyduino - Project Hosting on Google Code

Older Dec 28, 2009 issue 2 (Slow User Input Response) commented on by bkuhns - This is a decent idea, but it might be a bit more work than it's worth. A simpler solution, at least in my mind, would be to run the pulse to a simple counting circuit. Once the counter hits it's max value (do an AND on all the output pins, or use its carry-out pin if it has one), use THAT as the interrupt to the Arduino. On a 4-bit counter, each interrupt is 16 pulses, effectively dividing the number of interrupts by 16. Get a larger counter and you reduce the number of pulses even further. This technique will affect accuracy, but only if done to an extreme. Even with 32 or 64 counts, it would take a significant change in speed to make the error noticeable. This is a decent idea, but it might be a bit more work than it's worth. A simpler solution, at least in my mind, would be to run the pulse to a simple counting circuit. Once the counter hits it's max value (do an AND on all the output pins, or use its carry-out pin if it has one), use THAT as the interrupt to the Arduino. On a 4-bit counter, each interrupt is 16 pulses, effectively dividing the number of interrupts by 16. Get a larger counter and you reduce the number of pulses even further. This technique will affect accuracy, but only if done to an extreme. Even with 32 or 64 counts, it would take a significant change in speed to make the error noticeable. May 06, 2009 r11 (* Fixed multiple regressions introduced in the display drive...) committed by noisymime - * Fixed multiple regressions introduced in the display driver changes * Fixed multiple regressions introduced in the display driver changes Apr 26, 2009 r10 (- Full rewrite of the LCD display system - Addition of LCD '...) committed by noisymime - - Full rewrite of the LCD display system - Addition of LCD 'driver' for web4robot i2c lcd controller - Now compatible with arduino-0015 - Full rewrite of the LCD display system - Addition of LCD 'driver' for web4robot i2c lcd controller - Now compatible with arduino-0015 Jan 20, 2009 r9 (Made the simulation a boot time option ) committed by noisymime - Made the simulation a boot time option Made the simulation a boot time option Jan 15, 2009 issue 2 (Slow User Input Response) reported by gpatr...@wordenmartin.com - I stumbled across your project when my search for the "perfect" out-of-the- box rally computer failed and I was trying to find what home-built computers others had conceived. I'm really excited with the foundation you have created and am considering diving into my own project (despite my rather limited programing experience) using your code as a starting point. You mentioned that the response to nunchuck inputs is slow because the input pulses from the hall effect sensor consume much of the processing power at high wheel speeds. My thought is to put two processors in series with one dedicated to processing the input pulses and one used for calculations and user interface. To keep the response time snappy on calcuation/interface unit you can limit the updates from the input unit to one every 1/100th of a minute which is the finest resolution for rally scoring that I am aware of. I stumbled across your project when my search for the "perfect" out-of-the- box rally computer failed and I was trying to find what home-built computers others had conceived. I'm really excited with the foundation you have created and am considering diving into my own project (despite my rather limited programing experience) using your code as a starting point. You mentioned that the response to nunchuck inputs is slow because the input pulses from the hall effect sensor consume much of the processing power at high wheel speeds. My thought is to put two processors in series with one dedicated to processing the input pulses and one used for calculations and user interface. To keep the response time snappy on calcuation/interface unit you can limit the updates from the input unit to one every 1/100th of a minute which is the finest resolution for rally scoring that I am aware of. Nov 23, 2008 r8 (- Fixed startup calibration button combo. Now enters calibra...) committed by noisymime - - Fixed startup calibration button combo. Now enters calibration mode if the unit it booted with the C button held down. - Fixed startup calibration button combo. Now enters calibration mode if the unit it booted with the C button held down. Sep 11, 2008 issue 1 (cool!) commented on by carl.heaton - oops, no defect to see here :) oops, no defect to see here :) Sep 11, 2008 issue 1 (cool!) reported by carl.heaton - Like the video, looking forward to seeing how you've gone about it (for replication in a similar project). Seems like you're pretty far along with it too. Like the video, looking forward to seeing how you've gone about it (for replication in a similar project). Seems like you're pretty far along with it too. Aug 31, 2008 r7 (Further work on the calibration routine More response improv...) committed by noisymime - Further work on the calibration routine More response improvements Further work on the calibration routine More response improvements Aug 26, 2008 r6 (Abstraction of LCD interface Huge size and performance impro...) committed by noisymime - Abstraction of LCD interface Huge size and performance improvements Abstraction of LCD interface Huge size and performance improvements Aug 25, 2008 r5 (Final fixes for first commit) committed by noisymime - Final fixes for first commit Final fixes for first commit Aug 25, 2008 r4 committed by noisymime Aug 25, 2008 r3 committed by noisymime Aug 25, 2008 r2 committed by noisymime Aug 25, 2008 Project rallyduino created by noisymime - An Open Source rally computer An Open Source rally computer

issue 2 (Slow User Input Response) reported by gpatr...@wordenmartin.com - I stumbled across your project when my search for the "perfect" out-of-the- box rally computer failed and I was trying to find what home-built computers others had conceived. I'm really excited with the foundation you have created and am considering diving into my own project (despite my rather limited programing experience) using your code as a starting point. You mentioned that the response to nunchuck inputs is slow because the input pulses from the hall effect sensor consume much of the processing power at high wheel speeds. My thought is to put two processors in series with one dedicated to processing the input pulses and one used for calculations and user interface. To keep the response time snappy on calcuation/interface unit you can limit the updates from the input unit to one every 1/100th of a minute which is the finest resolution for rally scoring that I am aware of.

I stumbled across your project when my search for the "perfect" out-of-the- box rally computer failed and I was trying to find what home-built computers others had conceived. I'm really excited with the foundation you have created and am considering diving into my own project (despite my rather limited programing experience) using your code as a starting point. You mentioned that the response to nunchuck inputs is slow because the input pulses from the hall effect sensor consume much of the processing power at high wheel speeds. My thought is to put two processors in series with one dedicated to processing the input pulses and one used for calculations and user interface. To keep the response time snappy on calcuation/interface unit you can limit the updates from the input unit to one every 1/100th of a minute which is the finest resolution for rally scoring that I am aware of.

Older