Pages: 1 [2]   Go Down
Author Topic: Programmable Ignition  (Read 4327 times)
0 Members and 1 Guest are viewing this topic.
Western Australia
Offline Offline
Newbie
*
Karma: 0
Posts: 15
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Calculated that wrong 2760 loops a second is good up to 41000rpm

As for the power supply circuit, I hadnt put much thought into it yet, other than a 7805 and a snubbing diode because that work the last time i put an embedded pc in a car. But it dose definetly need to be engineer o handle everything. When I was installing car alarms Ive seen the back emf from the cars horn kock out the alarm module, and imobilise the car.
Logged

Anchorage, AK
Offline Offline
Edison Member
*
Karma: 37
Posts: 1147
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I started a thread for a community PSU design:

http://arduino.cc/forum/index.php/topic,106068.0.html

If I don't any more input on this soon, I'm just going to order the parts, build it, and strap it to my Ninja.  The bike has a pulsed DC system that has got to be the worst electrical system one could ever find.  So, if an AVR can survive that, a car should be cake.
Logged

Western Australia
Offline Offline
Newbie
*
Karma: 0
Posts: 15
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Cool. Will be keeping an eye on that.

Have been contemplating using my laptops sound card as a pulse generator. Cant find any thing on what circuit is needed, everything ive found about using it as an audio input. what is the voltage level needed to switch a digital input? 5V? Im thinking I need a DC offset circuit too. Or is it easier just to buy a signal generator off ebay?
Logged

UK
Offline Offline
Shannon Member
****
Karma: 184
Posts: 11195
-
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Well, if you happened to have a spare microcontroller lying around I suppose you *could* use that as a programmable signal generator.  smiley-wink
Logged

I only provide help via the forum - please do not contact me for private consultancy.

Western Australia
Offline Offline
Newbie
*
Karma: 0
Posts: 15
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Haha yes, that was my first thought. but I dont have one so, I thought how could I improvise till I get one
Logged

Dallas, Texas
Offline Offline
Sr. Member
****
Karma: 3
Posts: 267
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Just as a heads up, you are accessing variables in your ISR and main loop without any regard for their volatile nature. Yes, you have them declared volatile, but you have a race condition. Technically, the 'pulseTimex' variables can change midway through their use in the loop. This is especially true since these are long values and not likely to be anywhere near atomic operations.

I would suggest you create a new variable which signals the ISR has run. In the main loop, test if the variable indicates the ISR has fired. If so, do the calculations there and then. That way, your ISR only looks something like:

Code:
volatile bool fired = false ;
volatile unsigned long errorCount = 0UL ;
.
.
.
void halltrigger()
{
  HallTimeOld = HallTimeNew;
  HallTimeNew = micros();
   if( !fired )
   {
      fired = true ;
   } else {
      errorCount++ ;
   }
}

Then the loop can have the following, whereby 'pulseTimex' no longer needs to be volatile.

Code:
void loop()
{
.
.
.
   if( fired )
   {
        pulseTime4 = pulseTime3; //keeping track of last 4 signal times
        pulseTime3 = pulseTime2;
        pulseTime2 = pulseTime1;

        // Make sure we don't have a race condition - disable interrupts while
        // accessing our shared variables.
        cli() ;
        pulseTime1 = HallTimeNew - HallTimeOld;
        fired = false ;
        sei() ;
   }
.
.
.
}

Also, since you're CPU constrained right now, you're obviously going to need some serious optimization. For starters, add to your loop:

Code:
void loop()
{
   while( true )
   {
      // Place your existing loop here
   }
}

As for the pulseTime value shifts, you might consider using an array and using memcpy. I've been meaning to test performance to see which is faster. As such, I'm not sure it will be faster but it would be worth a try. The code would look something like this:

Code:
volatile unsigned long pulseTime[4] ;
.
.
.
if( fired )
{
   memcpy( &pulseTime[0], &pulseTime[1], 3*sizeof(unsigned long) ) ;
   // Make sure we don't have a race condition - disable interrupts while
   .
   .
   .
}

Now that you have an 'errorCount' variable, wouldn't hurt to periodically test to see if any errors have occurred. If you're seeing a lot of them, meaning past some threshold, to shut things down because time is off and undefined. Having any type of delay in your main loop should give you pause. But at least you can now detect some timing errors.

Lastly, as for a signal generator, would this be a good use for something like a 555 tied to a pot?

Edits: Fixed potential race condition. Optimized ISR. Realized much later I used memcpy to shift the wrong direction. Fixed.
« Last Edit: May 18, 2012, 12:55:08 pm by gerg » Logged


Western Australia
Offline Offline
Newbie
*
Karma: 0
Posts: 15
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thanks for the tips! I didnt think about variables changing half way through. and testing for it is a bloody good idea too  smiley
Logged

Dallas, Texas
Offline Offline
Sr. Member
****
Karma: 3
Posts: 267
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Keep in mind the errorCount detects a timing issue, not that the values were changed half way through. In fact, that race condition should never happen now. If it does, its a bug. Please note the use of the sei() and cli() functions. Those respectively enable and disable interrupts, thereby avoiding the race condition.

What it attempts to detect is that an interrupt has been missed/serviced, meaning its taking longer to service an interrupt than the rate at which they are occurring. Which is why, should you begin to detect errors, more than likely something has gone horribly wrong with the timing.
Logged


Offline Offline
Newbie
*
Karma: 0
Posts: 21
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Meant to post this here but it went to another thread accidentally, this file has pickup and driver circuits + a whole pic biased controller for a distributor type ignition.  You might be interested in the coil drivers unless you intend to drive CDI coils. http://www.vespalabs.org/@api/deki/files/479/=kc5442_Programmable_High_Energy_Ignition_System.pdf

LoL 3rd time the charm.
Logged

Western Australia
Offline Offline
Newbie
*
Karma: 0
Posts: 15
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I thought about buying that kit from Jaycar years ago, but have never been able to find this info. I'll definetly be using this coil driver circuit. Thanks a lot!!!
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 21
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Look at the Silicon Chip site they have the files for the circuit boards in the downloads. The also have the early version of the software but they do not have the software for the more advanced unit for some reason. Possibly so you buy the jaycar kits?
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 21
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Just thought thought I would share I put together a hall pickup and coil driver from the plans I linked to and it works just great. Next I guess is to figure out the programming for my application.
I am doing a test here dropping the ground to the light.

http://www.flickr.com/photos/novegetablesnodessert/7550236592/in/photostream

Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 21
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Just want to give you a heads up to an issue I ran into with the electronics. It seems that in bench testing I was getting enough self induced noise  in the circuit "Rx Tx LEDs would start flashing and zap" was crashing the arduino. This was at higher RPM 5000rpm to 10000rpm. I decided that I should have the system mounted to a larger ground chassis "Motorcycle Frame"  to dissipate the negative flow of electrons "dump them into the big pool of the frame", this seems to have resolved my issue. Now to producing the hall pickup mount + mag-rotor for the motor before I attempt to program.

Update/Correction
Set up an RPM readout and thought the code was wrong than looked closer at the dremel rpm range 3500rpm to 28000rpm and the code is correct, so no proto-board crashes unless I over-rev the bike by at least 10000rpm. Hopefully this will be good.
« Last Edit: July 15, 2012, 02:33:36 pm by nic579 » Logged

0
Offline Offline
Newbie
*
Karma: 0
Posts: 6
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi!

I could not saw any picture of wip, sorry.

I am onto CDI with VR input sensor, but I will be watching this project too.
Logged

Pages: 1 [2]   Go Up
Jump to: