jakestew

All the important links and info will be updated in this first post as they are posted or found...
http://www.electronics.gompy.net/ - Gompy's main electronics page, seems to have 3 CDI designs.
http://www.electronics.gompy.net/cdi/ - Gompy's CDI (Programmable CDI / TCI)
http://www.modelbouw.gompy.net/newcdi/index.htm-Opensource CDI Project of JMJ (Norway) and Gompy
http://ot40.com/cdi_ignition.htm- JMJ CDI

http://www.rcuniverse.com/forum/m_10662258/tm.htm- Thread for John's CDI (John = gr8flyer55)
^- This seems to be the place for current CDI discussion!

Schematic and Layout for John's CDI(Images may take time to load)





"Nyemi ZVS CDI" Schematics

bluejets

John's system along with Nyemi's code seems to be working quite well with a 12F683 Pic micro.

It's a simple system without any bells and whistles but ok just the same.

There were some settings within the program that may want to be altered to suit the individual, and since the program is written in assembly, changes are made, then recompiled and shoved into the chip.

Nyemi has shown where and how to make the changes for those of us in the know about program changes, other than that, he was offering to make the changes and then send back the new asm code by email to the individual.

I can't see where adding other sensors and programming to this chip would be a good idea. Probably better to let it do it's job and set up another micro with whatever.

John will no doubt read this and reply as to just where all the up-to-date latest details are. I am presently away from home and not able to access the info for you. Last time I spoke with John, he was trying a new "output section" to see if he could get the spark a bit hotter. Previous one worked ok for me, perhaps he had a special application in mind.

Gompy's system using a 16F628A was very good as far as ideas went, but unfortunately it suffered in many instances, from run-away sparking at a moments notice and so severe at times that the program would be lost from the micro. I had one that became unusable after one of these sessions. With the others, I was able to re-program. Never did sort out the reason why it was defective, the code was never released (just the hex)so no one was able to examine the former either.
Many built the system as described so no fault there as far as we could see.
Gompy's system had a monitoring program, in which curves could be changed via a graph and then the new curve downloaded via in circuit programming.
A lot of time and effort on his part and many appreciate his input.

jakestew

I certainly appreciate your post and all the effort put in by the people here. I'll keep updating the top post to include links and summary so that this thread stays readable.

I'd like to keep the design as simple as possible. I don't think it's unreasonable to run a GPIO at 8-166 hz (500-10,000 RPM) for the ignition trigger and also send out RPM reports at 1-5hz (= 16-80 bps) on a serial or I2C connection. And it shouldn't be too difficult to squeeze an A/D reading from the temp sensor in every few secconds.

The best place to start sounds like John's system. I've seen it mentioned in the other CDI threads, but couldn't seem to nail down for sure which one it is.

Some extra design goals that don't seem to be implemented yet in most of the projects I've seen here... Eagle board files, high level language support, off-the-shelf components, and perhaps a more modern processor. I want to make this something that your average highschool electonics project kit builder could do. Winding cores, scraping around for oddball components, and trying to make boards from jpeg images just don't cut it.

Most of the RC CDI systems out there seem to be around $50 for a very basic setup, and I think $50 is a pretty decent budget for this size project. I'm no expert in high voltage so that's the main design challenge for me and why I need a good working design to work from.

gr8flyer55

Jake, I'll be able to send you one of my new ignitions if you PM me with your mailing address. I know how frustrating the forums searches can be. I myself , have trouble finding certain things referenced by others in the posts. We now use a simple voltage doubler circuit to increase output and it is excellent with no extra currnt draw. The timer board I am using now is about the simpleat design possible, still giving great performance levels. When you receive it, you'll agree I think.
At one time, I anticipated adding so many features, but right now, there is one additional output I use for triggering a LED, which if you are clever enough, could be used for telemetry readings of rpms. I saw you mentioned doing many things, that included temps and possibly others. The simple pic chip used right now does have 6 useable outputs. Configuring them from the ASM program is possible for inputs and outputs, so it can multitasking easily, which was what you want to do, getting readings from other inputs and processing the outputs with success. If you take a look at the ASM file, maybe you cad find more ways to add routines and not degrade performance. I've taken the simple approach with it, and it functions very well.

I welcome any new ideas from programmers to make improvements.

John

bluejets

Things are not always as simple as they may first appear.

Not having seen the asm yet i think it's a bit presumptuous to assume you can make sparkling changes to a program that has been worked on and refined over a long period.

Having said that, you can find the start of the 12F683 discussions here. It's all open to changes for the better so good luck.

http://www.rcuniverse.com/forum/m_10662258/tm.htm

jakestew

I don't doubt that it will be a challenge to get things working perfectly. However, I do have a few programming tricks up my sleve. The microcontroller is probably the easiest thing to change and I have a variety on hand to play with. If it's a problem I'll cheat and just use a more powerful processor. They're so cheap nowdays that it shouldn't really impact the budget to use a significantly more powerfull processor. That is to say that I don't see a problem switching from a $1.75 processor to a $2-4 processor.

I'm not too concerned about adding the features on the processor side. What I really need is a reliable spark circuit.

It might take a bit to find the right processor that can get the right timings and latencies on the serial, interrupts, A/D conversion, hardware timers, or whatever. I don't think processing power will be an issue though, there should be plenty of spare instruction cycles per spark and we don't have to do anything math intensive.

The fact is that there's nothing out there that has these features, and I'm confident I can do everything I need for cheaper than the basic commercial CDI modules out there. I've got plenty of components laying around to tune the circuit up in a brute force experimentation manner, but more than once I've banged my head against the wall unnecessarily because I missed something basic or didn't understand what I was doing.

Because I really need to have something like this personally for my own projects, and the autopilot market also needs something like this as well, it will get done. I'm working with $70 Chinese GX35 clone engines, so spending $50 on a CDI module that doesn't do what I need is not an option.

They say that, "Necessity is the mother of invention," and that is the case for me. I figured out that the only way to get what I want is to create it myself. Even if some company eventually decides to make a product like this, it will certainly be way too expensive.

If we can put together a design that works well, I think there will be enough demand to put together a kit version. That's what I was hoping would be available when I started looking in to this, and I don't think it would really be all that difficult to do. It kind of pissed me off to find out how expensive commercial CDI ignition modules were and how basic they are, so hopefully we can change all that with a buildable kit!

bluejets

Yes, well, the system with the 12F683 works just fine now. It doesn't really need any refinement.

It could be a different story though to try to change the existing program and this was my point.

It would be quite easy to just add another micro to do the Tx of any peripherals without trying to add on to an existing program that is not fully understood except by the original programmer.

As you say, micros are cheap.

gr8flyer55

Hi Jeff!!
Been awhile since we last communicated. Alot has taken place in the interim. The new high voltage doubler has been perfected and ready to market. The implementation of telemetry for rpm detection is already established thru my led output. Picking that as a signal source from the timer board I designed will work as Jake is expecting it to. On the existing chip, there are a total of 6 input-outputs which are configurable within the existing ASM file as additional instruction for data acquisition. Jake needed an output to tell if the engine was running or not, and also at what part of the rpm range it is operating. All of this is already there from that single output. I have been using it as both a tach signal output and a timing light function with absolute success. A temp sensor can be added thru the unused programmable pins. So it was do-able all along, but I chose to keep it very simple. Next thing is the additional program loop space required in the chip memory since it currently is a 2024k memory space. Again, compacting the code for additional space available would be the project. Picking up the signals from unused outputs just means adding a multiple-lead cable to another board for processing which Jake has established. So long story made short, yes it is possible and quite easy to do.
I am supplying Jake with a highly reliable cdi unit and timer from which he can begin to build his system. I would like to see what he develops the project into. RPV or UA programs are looking for just such a system, and here we have the basic building blocks. I say let's give it a run for the money!

John

bluejets

Hi John,
Yes. been a while now. Due to go back to Aus and my workshop which I miss very much, about 4 weeks from now.
Only thinking the other day about dropping you an email.

Fine to make a Tx from your led output, already there. My concern would be that making changes to the program with additional outputs looking at program parameters or any interrupts may well interfere with the primary objective of the program which is to monitor the speed, do the look-up and fire the plug at the correct time.

As he said, chips are cheap so I'd be setting up a second micro to do any Tx'ing.

gr8flyer55

I agree with the second micro to handle the parameters. It could be linked with an optocoupler to isolate it. Any info then if needed to be altered during a run, could be setup to feed back to one of the inputs on the 12F683 to jump to the table for lookup values and make decisions like more or less advance, similar to a governor on a heli's constant rotor speed. It' been done before this way. All that's needed is the link between the two micros and a feed into the throttle servo. Fast response is needed to make small adjustments. The electric powered quad copters use a similar setup of feedback and speed response for vectoring the thrust equally. Linking all four throttles to the governor is the hard part. Temp readings and timing adjustments to change engine speed is tricky to say the least. He's already got most of that figured out so it's half way there I think. When I send Jake the first ignition, he will have some work to do. I used the new voltage doubler, with 2 more caps and got rid of the 4 diode bridge rectifier using 2 1000 volt fast diodes. Works nice and same current draw.
Don't worry, you're getting some new boards too when you get back home. Also sending extra bare etched boards so you can experiment too. A transistor change was also made with current draw as low as 250 mah. All working great now, with the toroids.

John

jakestew

Timing precision has to always be the number one priority. A two processor solution should work just fine. It should be pretty easy to read the RPM by monitoring the ignition led. The 2nd processor can also read the temp and transmit the RPM to the OSD or autopilot.

One of the main things is that the autopilot doesn't have any gas engine logic. It just puts out a PWM throttle signal and expects things work. Having the CDI handle the logic should work great. It can read the PWM signal, then use the RPM reading to output another PWM to actually control the throttle signal. A setup like this should work great because you'll get the target RPM all the time. If the engine starts to sputter at idle it will know to goose the throttle a bit.

We could have all sorts of handy features also. Like raising the idle speed until the engine hits a set temperature, kind of like the throttle kickdown on a car engine. I think it will also help with tuning since you can check the ignition timing against the throttle position and RPM. The CDI could then autolearn the ignition curve by setting the throttle and advancing the ignition until it achieves the highest RPM, then repeating until it learns the best performing ignition curve. I'm hoping that performance can be increased by having a totally custom ignition curve tuned for your particular engine/carb and prop load. I realize the performance gains would be pretty small, but every bit helps.

I'll be setting up a two processor solution right off the bat, but I'll also see what I can do with a single, faster, processor. So if there's any ideas out there on handy features or interesting ways to relate ignition timing, RC RX/autopilot type throttle input, and acutal throttle servo position using knowledge of the temperature and RPM... please post them here!

Once I get going I'll have a lot better idea how much processor time is available to spare, but I have some ideas how to spread the load out so that advanced features can be added.

jakestew

Just a note... I'm looking at using an ATtiny167 or ATtiny87 as the processor.
http://www.atmel.com/Images/doc8265.pdf
It costs $1.94 from digikey.

I know it's surface mount with 20 pins, but it is in the SOIC package which isn't all that difficult to solder. We also won't be using all that many pins, so you'll be able to bend the unused ones up and solder it pretty easy.
Unfortunately, you just can find many through hole processors with low pin counts anymore and I think going with a larger package with more pins for a socketed setup would be more trouble that it's worth.

I don't know how much it matters to people to use a through-hole design, or if they're OK with a fairly easy SMD package. But I also ordered a couple ATtiny4313. It uses a PDIP package which we can socket or solder right to the board through-hole style. The down side is that it only has 4k of flash.

jakestew

I was weed whipping my yard today and was just thinking how much more reliabe a 2-stroke would be if the throttle and RPM sensor were linked so that the throttle could be goosed or increased a little when they start to suptter. I've always found small 2-strokes to be terribly unreliable.

jakestew

I just ordered a couple PIC16F721 and PIC16F88.

jpanhalt

I am curious, why did you rule out the 12F(L)1840? It seems to have everything you want in a smaller package, and the programs for the 12F683 family won't need much modification, if any, to run on it.

Is this thread for a summary of the other projects or for development of a new project?

John

bluejets

John,
I think it started out as a summary of links and a proposal to change the existing chip program to accomodate some telemetry system this bloke has come up with.

I believe he decided to make changes first and read the existing program second, which is why I said the program from Nymie needed close scrutiny and full understanding before any changes were made.

The point from me was, the ignition is working fine now on a 12F683 so if telemetry is required it could be tagged on with another chip and an additional pc board if one requires telemetry. However, i think there will be a determined effort to try to modify this working program and make additions to fit everything into one chip. Beats me why. Alter the program, change the chip, change the layout,new pc board = new project.

As I said. chips are cheap, system from John already works fine ( and we know how difficult it has been to achieve this)

So, as to your question, I believe it will be a completely new system.

jakestew

I think I must have bumped the pin count over 8 on the parametric search for some reason. Good advice on the processor though. I've burned up my free samples for the month though, so I'll have to wait for my next component order to grab a couple. Looks great for a dual processor design though.

This thread is a summary thread that's kinda branched out a bit. I guess it's open for any and all CDI discussion. I'll keep updating the first post so that it remains a good resource.

jakestew

Bluejets, I'm first going to just add a processor on top of the current system. It should be easy to tap the LED output to get a RPM reading. Nothing should need to be changed in the current system, I'll just tap the power and LED output from the current board. All new features can be added to the new chip.

The reason I'm looking at all options though is that I'd like to have several CDI systems for my own use and I'd like to make it easy for others to build the system. To that end I'd like to do the board in Eagle so that I can have them made. I haven't etched a board myself in years, and the cost has come down so much that I'm not eager to go back to making them by hand. So, to some extent, there's no getting around the work of laying out the board.

The actual task of the microprocessor is not complicated, so I'm not worried about the programming. If two chips are needed then that's fine. If all the features can be fit on one chip then that's even better, but it won't be the current PIC as it is lacking in a few areas.

The biggest issue I see with the current CDI projects is that they're just too difficult for most people. If we want to get people on board and make something that is truly more useful and more suited to our applications than the current commercial systems things need to be made easier for people to build, understand, and modify. For that I think we need a source for pre-fab boards, a good BOM that can be ordered from a single supplier, and a well commented program written in C.

Gompy

Good luck !

jakestew

Thanks for the encouragement!
Could you post a few words about the current status of your designs?

Gompy

Ask Howie, http://www.rcuniverse.com/community/...=1&memid=41842

jakestew

I've got a few PIC 12F1840s on the way, as jpanhalt suggested. Compared to the current12F683, it has twice the memory, almost twice the processing power (8 MIPS), and has the UART, SPI, and I2Cperipherals needed for telemetry. It comes in the same package and should be pin compatible with the current chip. It will need some timing modifications to the current code due to the increased speed (or simply be run slower), but otherwise should be fairly easy to port the assembly.

jakestew

Just tried out the CDI John sent me!  Wow!  Nice long sparks and great operation.  So the current design works great!  I couldn't be more impressed with the spark power and length.

COM

Hi Jake,

What flavor of C will you be using? Thanks for taking the time to do so.

regards

Chrlie

jakestew

I've been working with the HI-TECH compiler, which is now called XC8.  It's Microchip's (makers of the PIC) compiler.