CDI tester project

Hi, on line 98 it says FALLING. I have a tester with the code here to check the time from output trigger on pin 9 to the signal back on pin 3. I think I may be ahead of myself here but it is off by 600 uS. When delay is 0 it reports 600. Probably this is fine tuning and must wait for DAC to be working. Also I need confirmation this code would be accurate?
Here is shot of the charge pulses and the pin 6 - 12 of DAC.
Thanks, Tom

// variable delay output for testing main board Us Delay line
// with display
int pot1 = A3;            // select the input pin for the pot (changed for this version because of lcd)
int delayValue = 0;       // variable to store the value coming from the sensor
unsigned long analogReadInterval = 1000;//read pot and map
#include <Wire.h>
#include <LiquidCrystal_I2C.h>
// set the LCD address to 0x3f for a 20 chars 4 line display
// Set the pins on the I2C chip used for LCD connections:
//                    addr, en,rw,rs,d4,d5,d6,d7,bl,blpol
LiquidCrystal_I2C lcd(0x3f, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);             // Set the LCD I2C address

void setup() {
  Serial.begin(9600);
  lcd.begin(20, 4);                                                        // initialize the lcd for 20 chars 4 lines, turn on backlight
  lcd.setCursor(2, 0);                                                     // lcd display setup of unchanging headings
  lcd.print("Us Delay:");                                                  // print fixed characters
  
   attachInterrupt(digitalPinToInterrupt(3),pulse, FALLING);               //added this line to have any pulse out**********
   pinMode(7,OUTPUT);
   
}

void loop()
  {
    delayValue = analogRead(pot1);
    delayValue = map(delayValue, 0, 1023, 0, 5100);                           

    lcd.setCursor(12, 0);
    lcd.print("       ");                                                  //print blank spaces to clear old data
    lcd.setCursor(12, 0);
    lcd.print(delayValue);
    delay (500);
  }

void pulse()
{
  delayMicroseconds(delayValue);
  digitalWrite(7,HIGH);
  delayMicroseconds(200);                                                  // modify the pulse length to see what is sensed by main board*******
  digitalWrite(7,LOW);
}

I think I may be ahead of myself here but it is off by 600 uS. When delay is 0 it reports 600.

My simulated response sketch is different, and has always used a rising interrupt edge and a 10us pulse width for the response pulse.

//pin 3 interrupt as as input 
//pin 4 as pulse output
void setup() {
 pinMode(4,OUTPUT);
 attachInterrupt(digitalPinToInterrupt(3),pulse,RISING);//interrupt on pin3
}

void loop() {}

void pulse()
{
  delayMicroseconds(1000);
  //delayMicroseconds(0);
  digitalWrite(4,HIGH);
  delayMicroseconds(10);
  digitalWrite(4,LOW);
}

With delayMicroseconds(1000) I read 1008, and with delayMicroseconds(0) I see 8 or 16.

We have to figure out where the 600us in your sketch is coming from. Are the grounds connected? Try my sketch as the module response simulator and see what you get. I'm not sure why your comments say couldn't get a response with a RISING interrupt.

We can get better precision than delayMicroseconds(), but that's not the main issue at this point.

I'm a little unclear about whether the interrupt on the main sketch should be set for RISING or FALLING. As you say its currently at FALLING because the input pin is set for INPUT_PULLUP to keep if from floating. I believe that this may be a change from the original code of several years ago. I don't remember if the response from the cdi module is open collector with switch to ground or if its an active signal. We should fine tune this when we have the new hardware and an actual module.

Hi, OK got the DAC running and everything works, well mostly! First issue is that if I start it up wile set in Falling mode, the display has 2 areas that display wrong info, confused. If I start it up in Rising it is OK.

There are a couple other things that I am unsure of like the timing and computation of Advance display, it will likely be always from the end of the first sine until D3 sees a signal. The thing I don't understand right now is that the barWidth setting influences this and I don't think it should.

Also attached is the DAC output set to barWidth of 80
Tom

I start it up wile set in Falling mode, the display has 2 areas that display wrong info, confused. If I start it up in Rising it is OK.

What are the two incorrect display values/positions in the Falling mode?

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?