Go Down

Topic: CDI tester project (Read 13016 times) previous topic - next topic

tom_bauer

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

cattledog

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.

tom_bauer

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

cattledog

#228
Feb 17, 2019, 06:09 pm Last Edit: Feb 17, 2019, 06:11 pm by cattledog
Quote
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.

Quote
Especially the delay display scrolls all the time.
What do you mean by this '"scrolling". Vertically or horizontally?

Code: [Select]
  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
 



tom_bauer

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

tom_bauer

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

cattledog

Great progress. :-)

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. 

4) 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.



tom_bauer

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

cattledog

#233
Feb 19, 2019, 04:32 am Last Edit: Feb 19, 2019, 06:10 am by cattledog
Quote
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?


tom_bauer

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

tom_bauer

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

tom_bauer

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


cattledog

Welcome back.

Quote
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.

Code: [Select]
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
  }
}

tom_bauer

OK, thanks, at first I thought it did not work but it is fine! I have an issue with the neg pulse triggering the CDI and have not found it yet. This is my first time using a DAC for this so I don't know if the pulse is to short. More later!
Best, Tom

tom_bauer

Cattledog,
Hi my friend, well sometimes the best laid plans just are not the best! I had thought that using a DAC was a good way to have neg pulse from Arduino. It is for some uses perhaps but the CDI input circuit draws much more current that can be supplied.
So a change of plans is sadly in order. I find that I just need 1 pulse for the trigger plus the 5 pulses for the HV supply. The circuit can just sample from the Rise of the trigger pulse by default and the bar width and position can remain with the rpm pot. Also the D6 to turn on the output at D7 can stay.
Much like the one you did a couple of years ago but I am going to finally add the pots and make a proper circuit board. I feel like it was a good idea and was suggested to me by a EE friend. But it works better to keep it simple!
Again, many thanks, Tom

Go Up