bluejets

2 posts...

gr8flyer55

Yes..it only happens if the magnet is held at the sensor any longer than to make a spark. Somewhere the signal is being repeated over and over and the scr never turns off, making it a dead short load to ground, as evident by the heating of the transistor. If I take a screwdriver and short out the .47 uf cap on the bottom of the board, the same thing happens, transistor is pumping current into the transformer so hard that thermal runaway takes place. Since the boards work normally with Nyemi's software in the chip, I suspect the problem lies in a signal not being turned off in Jake's chip. If I unplug the timer board from the HV board and replace it with the sensor, it functions normally at one fire per pass, turning off solid every time, no matter how slow I move the magnet.

John

bluejets

Yes well it's not that the SCR is never turning off but rather that it is running at high hz I think you will find.

So from this I deduct that if you gave it just one pulse at the input then everthing would be fine..??

Do you see where I going...........???

jakestew

OK, I've finally run the CDI on a real engine. I used a 2-stroke Homelite 25cc engine. Normally runs about 12-13 deg. advance. My hall sensor was about 40 deg BTDC and just using the flywheel magnet.

I tried it once with John's curve and couldn't really get it to run for more than a few sec. I did a 13 deg. flat curve and it ran at about 15 deg advance. It was a little jerkier than I would have liked. It seemed to jump around a little bit within a about 3 degrees. Part of the problem was that my hall sensor was not secure and was vibrating around a little.

I tried to get the continuous spark problem to happen. I couldn't get it to happen on the bench. When I tried on the engine the first time I also couldn't make it happen. But after I hooked everything up and ran the engine for a few sec a couple times then all of a sudden it started doing the continuous spark thing.

For some reason it wanted to spark continuously only when the magnet was tripping the hall sensor. I flashed a new curve onto the chip and got the engine actually running for a bit, but now I could not get the problem to happen!


This whole thing is kind of a mystery to me! I can't tell what caused the problem and I can't easily reproduce it! Flashing the chip fixed the problem, but I have no idea why. It didn't do it at first, then started doing it until I reflashed the chip, then didn't do it any more.

I didn't get any sort of transistor heating during any of this, but I didn't run for that long either. It's possible that the two issues are related.

I'll keep working on this and try to figure it out. Now that I can test on a real engine hopefully it will be easier to catch things like this and figure them out.

For the moment I don't have any good ideas. All I can think of is that there is some sort of hardware problem. Somehow the PICs memory is getting corrupted, noise in the power supply or on the pins could be falsely triggering something, or we're getting ringing or oscillation in some part of the circuit.

I hate to point fingers at the hardware, but it seems like the program works correctly most of the time. I just don't see how it can fire thousands of times and then all of a sudden not work right until it is reflashed, unless it is suffering from some sort of electrical problem somewhere.

The program doesn't write to it's own memory or eeprom, and there's really nothing I can think of in the program that would make it do this. There shouldn't be any read-modify-write problems since I use a shadow GPIO register. If the shadow register got out of sync then a pin could be inverted, but it still shouldn't spark continuously like that. With the double check in the ISR, high frequency noise on the hall line shouldn't be a problem.

The PIC memory must be getting corrupted somehow or it's getting bad ringing on the hall line somehow, but also in a way that's cured by reflashing it. I'm pretty stumped here for the moment. Any ideas are welcome.

Maybe running this on the 12F1840 can shed some light on things. On that chip I can actually use hardware debugging and see what's going on in the chip when it's running in the circuit, otherwise I'm not sure how to figure this out.


-Jake

gr8flyer55

Yes, I see where you are going with this, modify the circuit so it can only get one pulse. Well I just soldered the additional parts in place, and guess what happened? Yup, red hot transistor, hardware doesn't fix it either. Sorry to disappoint you but I actually thought for a minute it worked, till I got against the transistor and saw the smoke. Finger will heal, transistor, well lets just say it didn't fair as well.

John

jakestew

Are you getting the continuous sparking and the transistor heating at the same time?

Have you tried reflashing? If you're using the spreadsheet hex, try compiling the code and see if it makes any difference.

And just to make sure, the reason the transistor is heating is because the PIC is holding the output low for too long? So pin 6 is low for too long, which is turning Q2 off, which is causing the SCR to stay on, which is allowing the capacitor to drain, which is allowing power to flow through the transformer, which makes Q3 draw too much power and over heat. Do I have that right?

If that is the case then it must be that the GPIO for pin 6 is out of sync and I guess it must be reversed from what it should be doing. It must be staying off all the time and only turning on when it should be firing the spark. If that's the case then something must be disrupting it so that it misses a change and is running opposite what it should be. I'm not sure how that could happen, I'm setting the bit rather than flipping it, so it should be fine the next time it triggers.

I'll keep looking into it. Everything always seems to run fine for me, except for that one time. I'll keep trying things and I'm sure it will happen again at some point, then I can study it further to try and get a better idea of what's happening.


-Jake

gr8flyer55

Jake, all you said in your post in the third paragraph is what is happening. The constant sparking, and transistor overheating happens at the same time. If I just start the engine, it's fine, but if I move the magnet to the hall and keep it there, it constantly sparks and heats the transistor on the hv board. At first, it was the dim led, then all this started. Maybe it is holding the pin low too long? Not sure since I have no real test equipment, just plug & play.

John

bluejets

Q2 is normally on.

When it turns off, then the pulse happens.

Q2 could stay off for a week and it would still only give the gate the one pulse.

Pulse feed the gate of the SCR and turns it on.

If SCR Anode Cathode voltage does not fall below the turn-off threshold, then SCR will remain on.

CH Ignitions

My Feedback: (11)

John, what hardware you are using...Tan or Green HV boards

Any of this should not burn out the MJE521. If it burns out you have a issue on the board. I will say throw that away and try a new one.

If any of those you use lower the 220 res. on the flyback what value resistor you haveon the base to 521. What Voltage you have on idle on the .47 after the 4007 diode.

Adrian

jakestew

Well, regardless if we figure out what is actually happening I think I can add some extra checking and reorganize the code a bit to make sure to avoid this constant sparking.

If that doesn't fix things then we'll have to look harder at the power supply and noise filtering.

nyemi

Hi Jake
Look at this picture.
What do you think?
I hope you understand what I want.



In my opinion.
The electronic interference filter out impossible.
Software should be done about it.

iura

Hi guys.
I think, that all problems is in the HV generator. Yes, self oscillator generator is a classic scheme and it works fine. Only I think we need to fulfill some conditions:
1. Stop HV generator when reaching HV tension on a cap.
2. Stop HV generator during SCR is open.
3. SCR must be open by input pulse duration during the HV cap is discharging.(about 1.5ms depends on HV tension and cpacity of HV cap.)

bluejets

I've seen that done on other systems also.

nyemi

Hi iura
OK
But I'm asking you.
Original ignition RCexl no problem.
(No high voltage off)
In my project code (ZVS DC CDI No high voltage off) with no problem.

Why does it work well?

COM

If you are talking about Q2 on the timer board then No it does not work that way. Define "on" state and "off state"

IF a NPN transistor is "on" then the transistor is fully saturated and the Collector and the Emitter are connected. With that being said if the emitter and the collector are connected this creates a low signal , which causes the .1 uf cap( in hv board) to discharge to the gate of the SCR, thus causing the 400v .47 cap to discharge through the ignition coil.

With a 680 ohm resistor feeding one side of a .1uf cap and a 220 ohm resistor on the other leg of the cap. the cap charges. a low going pulse at the 680 resistor/cap junction is what causes the 1.cap to discharge. There is no way that the SCR is "held on for too long".

Gompy

@Nyemi, but you using a "controlled" Voltgae system at the ZVS.
You can't make spikes with this kind of transformer.
A flyback act like a bobine, it generate uncontrolled spikes.
The transistor can't handle this if the spikes will be to high, it blow it selfs.

The SCR can only shutdown if the Voltage is going true zero.
If the SCR stay open it will fire if the HV will be high enough to make a spark.

BTW, (you can read it back into the other topics) all over the last 8 years we have the same problem.

bluejets

Just thinking out loud here but it may be something to do with different devices used for the SCR and Q3 and their characteristics.

Just as the oscillator circuit provides induction to a high voltage through the HV transformer, so transient voltages from the HV discharge can pass back the other way. This may have a beneficial or a degrading effect depending on when this occurs. i.e. if the phasing is correct it could tend to turn the Q3 transistor off for a short period during firing. If not, it might be possible to turn Q3 on harder.

SCR's are also susceptible to "rate of voltage rise". This can actually turn them on if excessive. Usually selecting a higher voltage SCR can be beneficial.

gr8flyer55

I have done this test over and over here but I know it's not the hardware. What I have in the chip now is Nyemi's software, and it works perfectly every time, no matter what I do. I pull that chip, plug Jake's in and immediately it malfunctions. Plug Nyemi's back in and it will run perfectly again. That test, to me, points to a software problem fellows, no matter how you look at it. I've tried it on every commercially manufactured ignition I have sitting here, DLE, Rcexl, DA, 3W, CH, and even mine which is actually a CH board and components. Tests are all the same, overheats the output transistor in the hv oscillator section on every one of these brands.
So you see, it isn't just my hardware, but a software signal problem causing this condition!!!!! Nothing more.

John

Gompy

John, we don't say it's your hardware, it's a combination of hard and software.
The hardware is a little critical and the software will do the rest.
Thats why I want to redesigne with the MC34063 a new hardwareboard.
It have the options to stop the HV if there is no spark needed.
It also controles the HV-Voltage and there are no components who can overheated.

We can try, if it is not a good designe we stop to find a other good HV-board.

You have also mention, I need the CDI for my bike so I need a secure CDI.
You can make your plane (..) plug and play, but I need more then 1 hour to replace the CDI if it fails.
Beside the road, into the rain or snow I don't think I can handle this......I think I leave the bike.

gr8flyer55

I'm ok with a redesign of the hv board. I have about 150 of my boards and timers that customers are using perfectly in their planes and helicopters at this time, so I know I have a good product out there. I would just like to see this new software work as good as what I am now using, just like everyone else. By the way, comparing jake's first beta version, that one did not have this problem at all, only the latest 2 versions. Something has changed, and it is not good.

John

Gompy

I don't say your HV isn't good, but for this designe it have a problem.

I try to make a flash / strobelight from a disposal camera, I use the hardware for a long time.
On boats and planes for navigationlights and also lost plane lights.
It works perfect, but wanted the tube flash at the same time with the spark is a problem.
The last couple of days I distroy at least 10 SCR's and I don't know why.
I use allmost the same schematic like we do to fire the SCR into the HV-board.

BTW, maybe the HEX will be mess up into the EXEL-sheet ?
Do you have to compare the HEX files from a good and a bad PIC ?

bluejets

Com,
SCR requires a positive pulse to turn on, so I still regard your opinion as incorrect.
Below are some supporting images and a web site where you can check if you want.

web site..... http://www.electronics-tutorials.ws/rc/rc_3.html

iura

May be one of the possible scheme?
Needs only HF generator implement in the chip (if it not too hard).

COM

Blue jets you correct in that the scr needs a positive pulse.
But the transistor in the timer board does NOT supply the positive signal.

jakestew

Nyemi, thanks for your help.

If the hall input is really as dirty as the trace Nyemi posted then I think that is a problem. It would be good to put some low pass filtering on the hall input. Perhaps someone can do some calculations to find the proper cutoff and values.

Maybe some experimentation with the pull-up resistor on the hall line could also help with this.

One thing I can try is turning off the INTE in the GP2 ISR and then turning it back on after the spark fires. That should make sure that no interrupts are generated from random noise while the hall is on (low).


I've got some time today and the engine is here with me for testing. As soon as the locktite on the hall sensor mount dries I'll start testing things out. Should have done it last night, but didn't think of it.

It won't hurt to think of ways to possibly make the hardware setup a little smoother. A wee bit of analysis and tweaking might make things more reliable as far as the signals that the PIC sees. I really should have scoped things out better, but now that I have the engine running I'll have a better idea of the actual signal environment. If the hall signal really is that dirty then I think the falling edge is the way to go since it seems like a dirty signal when it's activated (low), but clean when it's off (high).

In any case stay tuned to the thread, the problem will be solved today.


-Jake