CDI tester project

DAC output at bar = 80

The word RPM changes to something else, the us: gets changed to a bunch of numbers.
Tom

After consulting and thinking about this new system of triggering the CDI I realize that it will likely be timed from the rising edge of the first sine even if that sine is negative or positive first, still first edge.
The bar length should have no effect on the readings, it is just there to trigger the CDI in another way that has no real relation to the tester.

With those settings everything seems to work, but the delay is shown as about 864 when I am giving no delay. That generates the error in the degree advance that I see.
Thanks, Tom

The word RPM changes to something else, the us: gets changed to a bunch of numbers.
Tom

Tom I can not confirm the Falling mode startup screen issue. I do not see this

but rather this

If you still have this problem, please post the code you are using. We may have gotten out of synch.

DAC output at bar = 80

Excellent. Looks to be positioned at 80/360. I think we have got the trigger pulses and the charge pulses looking good. Do these pulses go into/through some high voltage section, or do they go directly to the module under test?

After consulting and thinking about this new system of triggering the CDI I realize that it will likely be timed from the rising edge of the first sine even if that sine is negative or positive first, still first edge.

OK. I think the current code already does that. It always uses the first pulse. Rising is from the lead edge whether its positive or negative. The difference between R and F is that it just adds in the 10 degree pulse width into the timing when it is set to Falling. The start of timing is independent of the first pulse positive or first pulse negative settings.

//set timing start at lead edge of first pulse
    if (risefall == 'R')
    {
      delayPeriodStart = micros();//start looking for response as pulse rises
      trigger = true;
    }
    else //risefall == 'F' set timing at trailing edge of first pulse
    {
      //convert pulseWidthTime in timer ticks to microseconds
      //prescaler 8 = 4us/timer tick
      delayPeriodStart = micros() + pulseWidthTime * 4;//start looking for response as pulse falls
      trigger = true;
    }

The bar length should have no effect on the readings, it is just there to trigger the CDI in another way that has no real relation to the tester.

Correct, bar length does not figure into any of the calculations other than to set the timing between the first and second pulse.

With those settings everything seems to work, but the delay is shown as about 864 when I am giving no delay. That generates the error in the degree advance that I see.

I think we are back to where we were a few posts ago with the simulated response. Did you ever try the test routine I supplied and saw very small delay values?

The gremlins in the display went away mysteriously.

The trigger pulses go right to the input of a CDI, the charge pulses will be used for the primary of a HV transformer to make around 150 vac. I will send you a capture of the charge pulses with the trigger pulses, at max bar length there is some overlap. The idea was to not have a HV charge pulse when the SCR was firing as this was in effect a short but the HV source is high impedance so it may not matter.

The difference between R and F is that it just adds in the 10 degree pulse width into the timing when it is set to Falling.< If I set the pulseWidth from 10 to 5 will this be read correctly?

I am having a problem programming a arduino I have to run your code, have forgotten what model it is!! I will get it done tomorrow.
Thanks, Tom

The idea was to not have a HV charge pulse when the SCR was firing as this was in effect a short but the HV source is high impedance so it may not matter.

Yes, I remember this from the initial project. If its important, we can make the barwidth a factor in the timing of the charge pulses and delay the first one. There seems to be plenty of room.

//5 pulses of 30 degrees starting at 60 degrees
//ON at 60,120,180,240,300 = 2,4,6,8,10
//OFF at 90,150,210,270,330 = 3,5,7,9,11

If I set the pulseWidth from 10 to 5 will this be read correctly?

Yes. The pulse width in degrees gets converted to timerTicks and then to an actual time based on rpm.

timerTopValue = 15000000UL / RPM;
  timerTicksPerDegree = timerTopValue / 360;
  pulseWidthTime = pulseWidth * timerTicksPerDegree;


  //convert pulseWidthTime in timer ticks to microseconds
  //prescaler 8 = 4us/timer tick
  delayPeriodStart = micros() + pulseWidthTime * 4;

I am having a problem programming a arduino I have to run your code, have forgotten what model it is!!

I sometimes don't know what day it is, so don't feel bad. :wink:

Hi, well after an hour of trying, I give up. I have a Pro Mini and a FTDI. The com port is right, it just won't upload anything. I was going to try your test code but no go. Very frustrated!
Tom

Sorry to hear about the balky mini. Do you have the correct board and port selected. Do you have the FTDI driver on your computer? I remember several years ago that there was a problem with counterfeit FTDI chips being bricked by the manufacturer, but I think the last project when it worked was after that time.

What error message do you see?

To keep moving forward before you get a replacement, I have two thoughts. If you have a UNO with a removable DIP processor, you can remove it and use the board as a ust to ttl converter to program the mini.

Alternatively, can you read the outgoing pulse and the return from the cdi on your scope to confirm the 800+ microsecond delay is real. If so, can you think of anything on the cdi side which could create the delay. I'm pretty confident in the code.

OK, to keep moving, I just set up a PIC that I use for new CDIs and I can just compare the readings with what I know is right. What I would like to do now is set the refresh rate slower as it is hard to read.
Especially the delay display scrolls all the time.
Tom

What I would like to do now is set the refresh rate slower as it is hard to read.

I'm not sure where the change happened, but the display update was pulled out of the analogRead timer section and is updates every pass.

The first thing to try is to place the display update in the analog read timer section. There is one bracket which has to be commented out, and another which needs to be added. If this does not fix the issue, we can create a separate timer for the display. The analogRead() timer can be increased from the 250 ms is well.

If this simple change does not work, I'll separate the display from the adjutments.

Especially the delay display scrolls all the time.

What do you mean by this '"scrolling". Vertically or horizontally?

  if (millis() - lastAnalogRead >= analogReadInterval)
  {
    //add other potentiometer adjustments here
    lastAnalogRead += analogReadInterval;
    if (chargePulse) //lowest rpm with charge pulse is 615
      RPM = map(analogRead(pot1), 0, 1023, 615, 4000);
    else
      RPM = map(analogRead(pot1), 0, 1023, 500, 4000);
      
    pickupValue = map(analogRead(pot2), 0, 1023, 10, 90);
    barWidth = map(analogRead(pot3), 0, 1023, 20, 80);
   
    //RPM = 1200;
    
 // }//remove this bracket to add display to analogRead() timer 
  
  //adjust timer values for RPM
  timerTopValue = 15000000UL / RPM;
  timerTicksPerDegree = timerTopValue / 360;
  pulseWidthTime = pulseWidth * timerTicksPerDegree;
  OCR1B = pulseWidthTime;

  setupSwitchPresets();//enable toggle switch adjustments in loop

  lcd.setCursor(4, 0);
  lcd.print("     "); // print blank spaces to clear old data
  lcd.setCursor(4, 0);
  lcd.print(RPM);

  lcd.setCursor(14, 0);
  lcd.print("  ");
  lcd.setCursor(14, 0);
  lcd.print(risefall); //print R or F at upper right side

  lcd.setCursor(16, 0);
  if (firstPulsePos)
    lcd.print("+");
  else
    lcd.print("-");

  lcd.setCursor(18, 0);
  if (chargePulse)
    lcd.print("AC");
  else
    lcd.print("DC");

  lcd.setCursor(6, 1);
  lcd.print("   ");
  lcd.setCursor(6, 1);
  lcd.print(pickupValue);//should this be pickupValue??

  lcd.setCursor(16, 1);
  lcd.print("   ");
  lcd.setCursor(16, 1);
  lcd.print(barWidth); //maybe pulse width??

  lcd.setCursor(11, 2);
  lcd.print("       ");
  lcd.setCursor(11, 2);
  lcd.print(copy_delayPeriod);

  lcd.setCursor(14, 3);
  lcd.print("      ");
  lcd.setCursor(14, 3);
  lcd.print(degreesAdvance, 1);

}//add bracket to put display within analogRead() timer

Hi, apparently my computer had decided to add something else to com3 that I was using creating a conflict. Now resolved I hope.
OK I made read interval 500 and included display in the interval so it is much better to read now. I had meant refreshing when I said scrolling. I will try the Uno again for checking delay.
Tom

Hi, I have tested as far as I can without creating some more circuits and for that I want to have a few boards made. I have a error or about 40us which gives an error of +-2° at higher rpms. I think that may go away with the final circuit. I have my old tester to compare to and actual engines with timing light for final check of my PIC programming. The simulated sine out works well so that is an accomplishment!
So, I will say Thank you many times and I will go work on learning KiCad! I just use Eagle now but it is the small version.
Very Best, Tom

Great progress. :slight_smile:

I learned a few things from playing around with the simulated response the other day.

  1. Depending on the output from the CDI the return pulse interrupt on the tester will need to be either RISING or FALLING. Currently he interrupt pin is set as INPUT_PULLUP and the interrupt FALLING so the pin will respond to a grounding signal from the module. If the module puts out a high pulse, I think the interrupt will need to be changed. The interrupt pin might need an external pull down resistor.

2). When using FALLING mode for the trigger pulse, the time delay of the response pulse needs to be longer the trigger pulse width or else you see strange results as you are getting a negative value from the subtraction of start time from end time.

3).When using first pulse negative, the delayed response simulator needs to see a pulse from pin 8 and not pin 9.

  1. When the charge pulses are active, I see some additional delay (approx 30us) at 0 delay which I don't understand. The charge pulses should not be interactive with the trigger pulse or the return pulse interrupt but I see something. At longer delays, the effect seems reduced. I would keep my eye on the AC mode.

Good luck going forward. Please report back with how this project turns out.

OK
re #1, the spark generated by the CDI will always produce a grounding signal to the tester. I use a small SCR to do this and that is triggered by an inductive pickup. This keeps annoying rfi from getting back to the Arduino, they hate that stuff!

re #2, it is VERY likely that I will always use the rising edge of the first sine and will call that point rising whether that first sine is pos or neg. That is where the CDI starts its timing to create a pulse to trigger the SCR for the spark.

re #3, this may not apply? I am using the output after the op-amp that is driven by the DAC.

re #4, I have long been looking for a good way to simulate the HV from the magneto and the 5 pulses per rev seemed to be a workable solution. I have some small transformers with powdered iron pole pieces so frequency response should be much better that the lines transformer I had been using. I needed a transformer with a fairly low primary resistance and now have a few to try. I also have a DC - DC converter that is adjustable and can output 100 to 300 vdc. It may be a viable choice and that would allow the charge pulses to be completely removed. This is after all just for testing and measurement and not long term operation.

Best, Tom

Also I can code the Arduino to drive more bits of the DAC to make a better sine wave.
The simulated sine out works well so that is an accomplishment!

I don't understand the hardware and how the two A/B pulses (00,11,01) to the DAC creating -12, +12, and 0 volts generate a sine wave to the cdi. Is it created by the op amp and RC after the DAC?

Are you planning to separate some the the tied inputs on PinA to generate something different from the DAC?

Well I call it a sine wave, it is really just the most basic of such, a pos followed by a neg, really all I need to make a CDI see for triggering purposes.
Tom

Cattledog,
Hi, I am now making circuit board as I think I have everything else worked out. Have adjustable HV output switchable to 2 levels so once I get everything on one board I can see how the timing and such works. Seems to be good.
Again many thanks for your help, Tom

Cattledog, Hi, I find that I need to be able to have just the pos or just the neg pulse from the DAC and I don't understand where in the code that control is done. Ideally there would be 2 digital pins that one or the other pulled low would control this.
Thanks, Tom

Welcome back.

I find that I need to be able to have just the pos or just the neg pulse from the DAC

Do you need to have two modes--one where the two pulses pos/neg follow each other, and another with just one pulse or do you want the program to now only have the single pulse mode?

The selection of polarity switch will continue to control whether or not the single pulse is pos or neg, and we can treat the single pulse as the first pulse.

If you only want the one pulse mode, the code can be simplified to remove the bits needed to calculate the interpulse separation and the division of the timing cycle into two piece.

For now, here is quick revision which leaves the code pretty much intact, maintains the two pulse structure, but removes the second pulse. See if this gives the one pulse you want.

ISR(TIMER1_OVF_vect)
{
  //alternate ICR1 values to generate two outputs over 360 degrees
  //360 degree cycle time broken into two pieces
  //timerTopValue adjusted with RPM pot
  //timerTicksPerDegree = timerTopValue / 360; //gets new value to update ICR1
  static byte pulse = firstPulse;
  if (pulse == firstPulse)
  {
    ICR1 = timerTicksPerDegree * (pulseWidth + barWidth); //first pulse and bar width
    digitalWrite(13, HIGH);
    digitalWrite(chargePin, LOW); //guarantee charge pin off at trigger
    if (firstPulsePos == true)
      setPulse(positive);
    else
      setPulse(negative);
    //set timing start at lead edge of first pulse
    if (risefall == 'R')
    {
      delayPeriodStart = micros();//start looking for response as pulse rises
      trigger = true;
    }
    else //risefall == 'F' set timing at trailing edge of first pulse
    {
      //convert pulseWidthTime in timer ticks to microseconds
      //prescaler 8 = 4us/timer tick
      delayPeriodStart = micros() + pulseWidthTime * 4;//start looking for response as pulse falls
      trigger = true;
    }
    //start Timer 2 for charge pulses
    if (chargePulse)
    {
      timeSliceCount = 0;
      TCNT2 = 0;
      OCR2A = timerTopValue / 96; //set 12 periods
      //start timer running
      TCCR2B |=  1 << CS22 | 1 << CS21; //prescaleer 256 16us/tick
    }

    pulse = secondPulse; //next pulse
  }
  else //second pulse
  {
    ICR1 = timerTicksPerDegree * (360 - (pulseWidth + barWidth)); //second pulse and dead band
    digitalWrite(13, HIGH);

    //block the second pulse
    //if (firstPulsePos)
      //setPulse(negative);
    //else
      //setPulse(positive);

    pulse = firstPulse; //next pulse
  }
}