Go Down

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

tom_bauer

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

tom_bauer

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

cattledog

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.


tom_bauer

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

tom_bauer

#214
Feb 10, 2019, 09:04 pm Last Edit: Feb 10, 2019, 09:15 pm by tom_bauer
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

Code: [Select]


// 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);
}


cattledog

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

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


tom_bauer

#216
Feb 16, 2019, 07:12 pm Last Edit: Feb 16, 2019, 07:33 pm by tom_bauer
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

cattledog

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

tom_bauer

DAC output at bar = 80

tom_bauer

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

tom_bauer

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

cattledog

#221
Feb 16, 2019, 10:47 pm Last Edit: Feb 16, 2019, 10:52 pm by cattledog
Quote
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.

cattledog

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

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

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


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

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

tom_bauer

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

cattledog

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


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

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


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

Go Up