We are all in the same Universe...right!
If this is your first visit, please click the Sign Up now button to begin the process of creating your account so you can begin posting on our forums! The Sign Up process will only take up about a minute of two of your time.
This project will probably be abandoned as an orphan without anymore support from the programmer in about 2 weeks.
I still have kits and boards available for anyone interested.
PM me if you are interested.
There are still private developments taking place, but limited access to it seems the only way for it to survive since there have been comments made to stop our progress. It is a shame but it does happen. I have my end of this project working flawlessly, and will continue to keep making them for local club members and inquiries only.
The completed project is going commercial in a few months. Dates and availability will be posted.
I appreciate the help of everyone who participated in the project, whether it was information gathering, testing, or fresh new ideas for circuit changes or software implementation. You are all a really great group of people! Thank you for your support.
How can I compile a picf1840 version into hex?
Send your source code to me in email and I will compile it for you.
The information for downloading the software is at this link.
Follow the instructions to get everything working. Remember to change your device to the 12F1840 in the setup to compile the source code.
v1.0 is now up on the website.
-Added Nyemi's code to turn interrupts on and off in a smarter way. This may reduce false interrupts which could cause the program to recalculate the delay multiple times if you have a dirty signal from your hall sensor.
-Put the code for both the 12F693 and 12F1840 in the same spreadsheet.
-Added buttons to copy the compiler command lines so that people don't have to install the IDE.
-Added instructions to help get people get things compiled.
I have been busy the last few weeks with school and work. The new changes are pretty minor, but hopefully everything is simplified a bit.
I can't find anything more to do to the program without getting into more advanced features. It runs very well and there seem to be no problems that I can find. I have plenty of ideas for more advanced features, but this seems to make a great v1.0 release point.
The code is as stable and accurate as it can be with the current table-driven system. There could possibly be some adjustments left to do in the table generation by the spreadsheet, but it already works as expected and I can only see the most minor gains being had.
I'm working on getting a video of the actual operation finished, and should have that added to the website soon. I've got good video captured of all the functions, but just need to edit, compress, and upload it.
Hopefully people will be willing to test all the various methods of compiling the code on the two processors. I wrote the instructions as I was upgrading my MPLAB and compiler, then I tested it on my engine for the video. Everything seems to work right, but I only tested the 1840 version on an actual engine, the 683 version was only tested in the simulator.
Be sure to let me know if you find any problems in the instructions or code. Email me first with problems, unless you think it's helpful for the thread.
Here's a video of v1.0 running on a Homelite 25cc engine...
Hi JakeORIGINAL: jakestew
-Added Nyemi's code to turn interrupts on and off in a smarter way.
I magnanimously helped you.
But I did not breach you. Please.
You do not do it to me. Thank you.
I am who I am just a simple manipulator hardware.
Congrats on your first official release !ORIGINAL: jakestew
v1.0 is now up on the website.
Currently the server seems to be down tho.
> Currently the server seems to be down tho.
Seems to work for me. Maybe it's just having intermittent problems, or only certain locations? Anyone who's having problems can email me and I'll send you the file.
Someone mentioned to me that the kill switch doesn't seem to work well in the video. That's because I was pushing it and letting off very quickly just to show that it was kicking in right. If you want to kill the engine you have to hold the kill switch until the engine stops. If you let off of it while the engine is still spinning the spark will return and it can start back up again.
It kills the spark in less than 1/4 sec, but only kills the spark while it is closed. If you don't like this behavior I suggest putting a toggle type switch on the kill switch. You could also use a normally closed momentary switch, which would work like a "deadman" switch.
Right now the kill switch is just an extra feature. You should not rely on it completely, and should always have another way to kill your engine. If the switch becomes disconnected it will NOT work and the engine will NOT stop. For that reason alone it is not suitable for being your primary kill method. It is very easy for a wire to break or the switch connection vibrate off, or even for your switch to malfunction.
I take no responsibility for any injuries! The code is open source, so you are fully empowered to study it and decide if it is suitable for your application. You have full knowledge of ALL the workings of the code, so you take ALL responsibility for deciding weather or not it is safe to use, and anything that results from that use.
I should also point out that open source software is legally considered to be constitutionally protected free speech. Unless you can prove I intentionally incited a riot or somehow equate this to yelling "fire" in a movie theater... I have no liability for what I put in the code or how it gets used.
I got this message, but when I hit BLUE BUTTON, it started downloading ....
Any restriction of access from Japan, or my browser is a problem?
Anyway I got your file.
That's strange... I tried adding that Cloudflare thing since it was free and my host was pushing it. It's supposed to make things faster and MORE reliable! Guess it's just a bunch of crap.
I'm not aware of any location restrictions, except for India. I banned their country because they hacked me not too long ago. It's possible that some of the banned India IPs are blocking some people. If this happens you'll just have to email me for the file, I'm not going to let Indians hack me again.
If anyone else has trouble with it please email or PM me. If it causes more problems I'll have to get rid of Cloudflare or look over the banned IPs again.
Thanks Jake !!
As I am going thru the testing phase of editing curves and installing the new MPlab files, everything is working great.
I particularly like the link buttons added to copy command lines etc. Makes things much simpler.
The instruction readme file is a big help for those with limited experience also.
A big thanks also to Nyemi for researching the trouble spots in the source code. Without guys like you Nyemi, some of us would be lost!!
Job well done!
It's been pointed out to me several times that the kill switch feature needs to be better. The kill switch should kill the engine if it becomes disconnected.
The reason I implemented it the current way is that not everyone has switches hooked up, and the switch I used for testing is a normally open, momentary type.
In the next version the polarity of the switch will be reversed so that the switch circuit will have to be closed for the engine to run. This way if the switch wires break or come off the engine will stop. If you don't want to use the kill switch feature you'll have to ground the kill switch pin with a jumper or solder bridge.
Just thought I'd let people know so they don't waste time hooking up switches that won't work in the next version. If you're looking to hook up a switch now, I suggest using a toggle switch.
I'm working on some pretty fancy new features for the next version, so it will take awhile for the next release.
Notes on the video...
The switch labeled "M" is a Momentary switch tied between the ground and the kill switch pin. The "T" switch is a Toggle switch connected between ground and the table switch pin. The grounds for both switches are tied together. I hooked them up by soldering a servo connector to pins 2, 3, and 4. Pin 4 is grounded in the current design, so I used it as the ground.
I forgot to mention, but the v1.0 release puts your settings and table into the code. There's no need to separately cut-and-paste in the table data.
Target features for the next major release...
-Learning mode - the processor will learn the hall pulse and store it in EEPROM so that it can do instantaneous RPM calculation based on the pulse length. This will be used for starting since it will solve the first spark timing problem. No more estimating the starting speed.
-Rising edge hall pulse timing (magnet leaving sensor). I liked timing the pulse as soon as possible, but in order to do instantaneous speed measurement we'll have to wait for the end of the pulse. I've also come to the conclusion that it's easier to just move the sensor forward or the magnet back in order to give the processor enough time to do the calculations.
This may cause some problems if we have dirty sensor input. Using the first pulse edge like I'm currently doing is pretty safe, but with switching to the trailing edge it's possible that noise at any point during the pulse could generate a false interrupt and start the spark timing at the wrong point. We need some basic filtering on the sensor input. I don't think it will be a problem for most people, but if even some setups have this problem it will cause some jitter in the timing and make the project look bad.
-Better kill switch setup. A normally closed switch will make it so that the engine dies if the switch comes off. This will also let the switch have a deadman function, since if something happens to you you'll pull the switch loose and the engine will stop.
That's all I can think of to make the 683 do. v2.0 will be the last joint 683/1840 release.
Target features for the 1840...
-On-the-fly calculation. This will replace the precalculated table with a smaller table of just the advance values and allow more precision of the spark timing. This will also let us change the table values easier, so I'll write an app to allow on-the-fly table changes without reflashing the firmware.
-Telemetry. The processor will send out RPM speeds and possibly processor temp readings. I've ordered a Frsky DJT TX module and RX unit with serial telemetry (~$53 at hobbyking). So telemetry options will be using wires, bluetooth, or through the Frsky module.
I use a Turnigy 9X type transmitter since it's amazingly cheap and powerful. It's the only one out there that I can work with the firmware to add cool stuff like this. I'll be working to get RPM displayed on the TX LCD. I've already got the serial port working on the 1840, but still need to work out how to display the data. I'd like to write a PC and Android phone app to display the data and figure out the best way to display things on the 9X screen. I also need to figure out the best protocol for the telemetry data. I had wanted the display app to do most of the calculations, but this would probably force the burden onto the 9X processor and we can't really risk bogging down the 9X.
If anyone knows about the Frsky system or wants to help writing the apps, please let me know.
Well, that's my roadmap for the software side of the project. If anyone has any other ideas please let me know.
That sounds like a better way to have the switch work. I'd probably use one of RadioShack's normally closed pushbutton switches. That way it only requires you to push and hold till the engine quits. With the safety feature implemented, it solves the broken wire problem.
By the way, if you are changing curves in the Excel sheet, please don't forget to change the hall sensor position to match what you physically have it set at on your engine !!!!
The default in the Excel sheet is set at 49 degrees!!! This will never work for an engine with the hall sensor set to 28 degrees which is a normal setting for MOST engines in use today. I tried that default of 49 degrees and trust me, you will never get your engine started with that setting without losing a finger or two.
That sounds really interesting. I look forward to the 1840s features that you will implement. Thanks.
Jake, can we use Rob's suggested filtering on the sensor input on the current timer board?
Rob, can you post that filter schematic so we can see where to add the parts?
I can change my etch pattern to accommodate a few parts if needed.
Dang forum lost my post...
That sounds good. While you're at it... the 1840 can put serial on pins 2/3 or 6/7. To have serial and table/kill switches you should pin out 2, 3, 6, and 7. For the switches we need ground and pins 2+3. The serial also needs ground and pins 6+7. If you can pin things out in this fashion it will make it easy to connect the switches and serial. I use regular 3-pin RC connectors for most things.
Jake, pins 2 and 3 for the switches are absolutely fine. However, for the serial port, pin 6 is our signal output to the ignition board for spark trigger. Pin 7 was the output to the led, which we can relinquish since I have a new more direct link to the signal input from the hall sensor. It is pin 6 that is the problem, without that one as ignition trigger, Houston , we have a problem!
The only other solution would require a satellite board , linking signals for the data. Getting complicated, but maybe using a different higher pin count chip with dedicated serial comunnications like we once had with the 16F628a. Food for thought here, I am not a programmer and haven't much insight as to what you have in mind. Split signals on pin 6 ?
Maybe a better way to use pin 3 would be to eliminate the kill switch connection and move that switch to the ignition board itself with the deadman switch. I have a way that works to kill the signal to the SCR by opening the trigger connection for a positive kill of the spark output. That gives you back pin 3 for serial connections. Pin 2- table switch. Pin 3- and 7- and ground for serial dedicated communications. There you have it all. Just my thoughts but a solution to the missing signal output pin.
John, you need ONE TX and ONE RX......It doesn't work with two TX or two RX
Not too hard to figure out Rob. Pin 6 and 7 become tx and rx , change old kill pin3 to signal out to SCR trigger on ignition board, problem solved. Didn't look at the pinouts to see 6 & 7 were paired tx and rx pins. Most likely requires many source code lines changed but possible. I guess it makes it easier to place a 3 pin header also on the board layout great idea I think. Jake probably already has that location for connections figured out on his timer board to link up his serial connections.
Pin 3 is input only.....
EDit....... sorry....are you referring to the physical pin or the port number.???
Not used to having it referred to as the physical pin....
Forget it....too early in the morning here I think...
Just looked at data sheet ..RA0/tx (pin7) RA1/rx (pin6) RA4/tx (pin3) RA5/rx(pin2)
First of all, why don't we use LiPo batteries ?
They are light in weight, small, can be reloaded, more Voltage, more current and cheap.
It's also easyer to make more power if the Voltage will be higher.
Also the electronics is easyer to make if there is enough power.
Second, don't try to use the same board for two differend types of CDI.
One of them or both don't work well with the same components.
Don't forget, it's high tech wat we are using and dangerous if it fails.
Third, first finish version 1 with the 12F683 befor start version 1 with a 12F1840.
I think a lot of people don't understand anymore wat we are doing or to use.
Wait for some time, atleast until some of us have test the version 1 of the 12F683 software.
Fourth, relase version 1 for the 12F1840 within a few months and not at the same time with the 12F683.
Lot of people don't undertsand wat they have to use or the possibillity of both PIC's.
Fifth, we need layouts and schematics to make it easy to the people who want build the CDI.
Jack was saying he will invert the killswitch and the table switch, but thats only possible if the PCB's are ready for this change.
If above isn't clear, we lost on all fronts.
Witch PIC software belongs to witch PCB and wat Exelsheet to use for witch version and ware can I find the hardware.....Even I'm lost sometimes
BTW Jack, you can write your new version for the 1840 but please lanuch it into a new topic - CDI 12F1840 ?
Now the differend versions are walking around into one topic and make it hard to know where people are talking about of.
If the topic will be longer it's also hard to find the sollutions for common errors of one version.