CDI tester project

Hi, I was adding the pots and changed a couple variable names and now it won't compile!! I must have done something dumb!
Tom

tester_revision_2019.ino (9.88 KB)

Ok, Here's your version which now compiles. Tere was a misplaced bracket and an undefined variable.
I now have my 20x4 online so I can follow your work more closely,

I see a couple of problems with the code as provided.

You are mapping two values from the same pot. Is that correct?

pickupValue = map(analogRead(pot2), 0, 1023, 10, 90);
    barWidth = map(analogRead(pot2), 0, 1023, 20, 80);

I think this should be pickupValue if you want the pot controlled variable and not the fixed one I had.

lcd.print(pickup);

I leave you to make these changes to the code if I'm correct.

Have you had the charge pulses on the scope? If so, do they look correct in relationship to the trigger pulse?

tester_revision_2019.ino (9.86 KB)

I just noted another error in the analogRead() pot mapping section. The placement of the new readings had broken the if/else construction of the rpm mapping with and without the charge pulses. That section should look like this.

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);//two variables on same pot
    barWidth = map(analogRead(pot2), 0, 1023, 20, 80);//two variables on same pot

  }

EDIT:

With the new adjustable variable pickupValue the code for degreesAdvance should change.

//degreesAdvance = pickup - delayDegrees;
    degreesAdvance = pickupValue - delayDegrees;

Hi, OK I will work with this for a while. Yes there are 3 pots so should be 1 is rpm, 2 is pickup, 3 is bar width.
Many thanks, Tom

Hi, OK with just the rpm pot it works. With the installation of either of the other 2 it crashes.
Tom

tester_revision_2019_A.ino (9.99 KB)

You can not use A4 and A5 for the new adjustment pots. They are common with the SDA and SCL pins for the i2c lcd.
I have changed them to A2 and A1 and the code does not crash. One other correction is that pulseWidth needs a non zero value, and I have set it to 10 degrees. There was also an incorrect arrangement of the if/else on the rpm mapping with the charge pulses which I have corrected.

tester_revision_2019_B.ino (9.94 KB)

OK, thanks. I will do some more testing and see it the DAC will work! But waiting on the dc-dc converter from China.
Tom

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.