Electronic Distributor Adapter

[turbo.shaft]

Quote:

Originally Posted by nolydi86conques ok well i would like one fore my 1985 conquest 2.6 pm me if u can help

Not sure what he coupld do and what you want to adapt? This is to use crank triggers with older distributor pickup technology for TD swaps. What would you use it to adapt in a 2.6 setup, which is the stock motor?

You would be better off doing a 2.0 4G63T swap and using turbo wiring that screwing around with that 2.6 POS motor. Lots of people have done that and it is a great swap. If you want the displacement just stroke it to 2.4l with a stroker kit.

[nolydi86conques]

that is ok my conquest runs fine and i jest found an MSD6AL that will give me all the spark i need

[90TurboVan]

^
| ...?

I've narrowed the problem down to the crank trigger timing/synch area, stipped all the code except that out and I still get lost synch. I think I might write it in C and see if that makes a difference...

[cj011]

I hate to say it but stripping the code out will not solve anything. In order to do this complicated program you are going to have to do everything step by step, instead of writing 100's of lines of code. first make sure all of your variables are initialized correctly. Put test statements before and after each line of code to make sure each one is working. Make sure your variables are correct before and after. Make sure that your input and output will only deal with certain variable values. Eratic in/out data can crash any program. If you are connecting to something, make sure that the connection is working fine, and then make sure the initial variables are correct. If that is all fine, then you will have to dig down way deeper into the validity of the electronic signals and timing of them. Also, you would be better of starting with C and working your way down. Then you know for sure that logically everything is working smoothly.

[cj011]

Also it could be that your filepath for the program has been ****ed. I had that happen once to me. The program would not even print 'hello world', and everything was fine. Come to find out, that once in a blue moon a file will never work. It's a shot in the dark, but shit happens

[90TurboVan]

Stripping out code lets me find out exactly where the problem is. I've verified operation of all the bits of code, several times. It works when I connect it to either the microcontroller that I programmed to output cam/crank signals, or when I use the MCU simulator in the development environment that I'm using. Once I connect it to a car, however, it seemingly randomly loses synch. It works when it's synched, but it'll just lose it. I have it programmed now to turn an LED on when it detects the long "key" tooth on the crank, works fine on the bench but doesn't on the car. It really isn't that complex of a program, but I can't find what's wrong with it. I use the exact same method that MegaSquirt does for detecting the "key" teeth, and it doesn't work. Moving to C would get rid of any math implementation errors as well as take care of variable initialization, but leads to slower/bigger code, and speed is critical for this type of application.

I don't think that it's a noise problem, because I don't see anything on the scope, and its the same inputs that I'm using for the hybrid adapter which I know works and have driven a car that it was running.

Also, this is nothing like a computer program. Filenames don't matter because you're compiling like 1k of code and it doesn't link to anything outside of that 1k. I don't know if you've done anything in assembly/with microcontrollers, but there is no method of debugging with test statements or other outputs. The only thing you can do is put something out on LED's.

Its just really frustrating to see it work on the bench with the exact output that you get from cam/crank sensors and then it doesn't work on a car.

Off to find a C compiler for PIC's...

[turbo.shaft]

The problems discussed above is why I can't program. It drives me batty. Good luck on the debugging. The TD world and my Omni thanks you for the effort.

[90TurboVan]

It amazing how much easier it is to work with C. Then you look at how it compiles to assembly and see why it isn't good for small devices like this. I implemented a synch to #1 flashing LED, and it works fine. No lost synch that I can see on the LED or scope. I'm pretty sure the problem was in the math routines I had written; not handling >8 bit operations properly would cause that kind of a problem. Working on adding in the rest of it to test out and then migrating back to assembly...

[cj011]

Your probally dead on about the 8 bit deal. The only thing though is that are you dealing with anything greater than 8 bits? If have an open window of data going into a 8 bit field, the shit will hit the fan. If you are recieving more than 8 bits, the problem could be on that end. Another thing I will throw out there is how or what type of signed/unsigned numbers your using. It could be that your numbers are being trucinated(sp) becuase of decibels that never end. You may want to head over to the CodeGuru Forums - A Developer.com Community for C++, C#, VB, Java and .NET Solutions site. they have a pretty good assembly section, that can take alittle while to get back, but usually have good answers.

[cj011]

Is it the input going into the program what is cauing the problems or is it your program acting up? Is there anyway you can watch the data coming in to see if there are any problems on that side?

[90TurboVan]

It times the time of a high or low pulse on the crank sensor (used to detect the long "key" tooth, as well as the time between successive high->low transistions (equal to 20 crank degrees as long as its the second tooth in a series). Since those are measured in time units of 1/2000000 seconds, I need 24 bits to time the high and low pulsewidths at 300 rpm, everything else is 16 bits. Signed/unsigned don't really mean anything unless you write the code such that they do (i.e. you still use the same commands, the output just means a different thing), and the only place I used signed numbers was during the delta calculations. Everything is calculated so that I can't overflow any of the variables even at maximum period/acceleration. The synching still acted up after I removed those parts of code. The problem with debugging something like this is that it all has to happen in real time. I'd have to have a way of getting each time measurment before the next crank event, which is really fast. Even then, how do you even start analyzing the data from even a minute of running...

I'd say that since the problem seems to have gone away now that I'm in C, I'll just have to test my addition/subraction/compare routines in assembly and find out why they don't work right for 16 or 24 bits.

[90TurboVan]

Ran my Neon with it in both C and Assembly. I guess the Neon computers actually control dwell based on current through the coil, because the coil drivers got really hot during a short run time and the rev limiter cut in a 4000 rpm... I have to get the HEP outputs coded in and we should be good.

[KitCarlson]

For the Neon coil ~4.5mS of dwell charges a coil. The time varies with supply voltage. Longer than that, the VB921 will be in current limit mode and dissipate significant energy.

You will need to overlap coil drives for high rpm operation. This means coil A and B could be both charging at the same time. I found it the easiest to use two timer channels.

[turbo.shaft]

Quote:

Originally Posted by KitCarlson For the Neon coil ~4.5mS of dwell charges a coil. The time varies with supply voltage. Longer than that, the VB921 will be in current limit mode and dissipate significant energy. You will need to overlap coil drives for high rpm operation. This means coil A and B could be both charging at the same time. I found it the easiest to use two timer channels.

Is this a new problem to address?

Or will the module as configured be maxed out at 4K RPM?

[90TurboVan]

No, no, the Neon computer sensed that the coils weren't charging because they weren't hooked up to the Neon harness and rev limited at 4k.

I'm not setting dwell in the adapter, leaving that up to the stock computer. I also noticed no misfires up to 7k.