Trigger decoding, a few thoughts...

[turbotuner]

HI all,

I'm new here, but very much enjoy playing around with both cars and embedded controllers. I am by no means an 'expert' in either, but by day am a .NET developer, so as you can imagine, I am used to having to come up with new solutions for common problems!

Anyway, I'll try not to swear too often, but I have been using a *megasquirt* for the past couple of years as a rough protoyping board for my antics. I have it installed on my track day/weekend fun Impreza STi, and by no means was this an easy feat (back in the day when we could only run 36-1 etc), rather than the MS2 supporting the standard triggers as it does now.

I'll get to the point..

Making a board suit all vehicles is fine, and on the outer shell of it, not that hard if you consider all engines have pretty much the same operation and sensors, with usually only the triggering system varying from engine to engine.

So far we use a preset selection system (as with *ahem* megasquirt), but would it not be better if we could simply crank the engine, and 'record' the outputs from the VR sensor, plot a nice colourful graph, and say to the ECU: 'hey, at that point there [clicks on the waveform] we are at TDC' We then click and drag to indicate a 360* worth of signal, and there we go, a define it yourself triggering system.

I for one am up for working on the front end!

Any thoughts, or has this been done to death and I am rehashing a failed dream?

Adam

[GartnerProspect]

I like the concept.

But I'm not sure how easy it would be to implement. Some triggers, like the subaru 6/7 arrangement aren't as obvious as a single missing tooth wheel or a basic dual trigger. Though I can kinda visualize what it would take to make it work now that I sit on it a while.

[slacker.cam]

Hmmm that could be pretty handy for first time user but I'm not sure how much help that this would be for a advanced user (like what we are aiming this at) as you should know what kind of triggering system you have. The time and effort required to put this in to practise may be better spent elsewhere when a simple dialog box where one can enter the amount of triggers, location of triggers, etc will work fine. I invision a drop down menu with the standard tigger types and a option for custom where the user can enter the specifics if they dont fall into a 'standard' category (which most people will).

Im not trying to turn away anyone who's keen to get involved, quite to opposite. I would hate for someone to devote a lot of work to something like this and then have it not end up being used because its to hard to use/non-intuitive/doesnt get finished. What do others think of this? Would it help you to set up your triggering setup?

One idea that i do really like the idea of is having a visual graph of the trigger setup that you select. It would have 2 graphs (one for cam, one for crank) and each graph has a trace showing where the trigger events will occur wrt TDC and if the triggers are accepted on the rising or falling edge. This way the user can get a visual indication straight away as to wether their settings are correct or not. The Autronic software has this functionality although it is pretty badly written, I think we could take the idea and improve on it.

Cam

[slacker.cam]

Acutally, what i just suggested is pretty much what you said but a little less easy for the user. The more i think about it the more i like your idea. This would account for small variations in the machining and alignment in the trigger wheels. Maybe you could have an 'expected' and an 'actual' graph allowing the user to confirm the settings he has chosen.

[turbotuner]

Cam, brad,

Yes I understand what you mean about the system being aimed for the advanced user, but in some respects, to have LOADS of development, we need loads of users, and if most can't get the car started, then not much will happen interms of active development by members of the group?

I know from MS'ing my car, that a few times I thought, hell, MoTeC.. off the rollers let someone else do it for me, (purely from the agro the triggering caused and base mapping etc) and if that had happened, then I most probably wouldn't be here now...

Theres two options with regards to triggering etc (from what I believe a novices point of view who may want to develp things such as anti-lag or other 'post getting it running' projects). Either, we have numoruous, as you suggested base trigger settings, or we let the system be wholly configurable down to what happens at each degree in an engine cycle. Ouch to the latter!

Adam

[thebigmacd]

I like this idea. Actually I had a related idea as far as trigger decoding...

What if the trigger inputs were sampled in pure form (with voltage clamping of course) by an ADC, and through digital filtering and comparison to a stored sample of an entire engine cycle, the precise position, speed, and acceleration of the wheel could be determined.

I am drawn to the concept of isolating the engine position decoding from the calculation section in hardware, so that the trigger processor could be burned with firmware related specifically to the trigger type, and a standardized signal generated on the "trigger bus" which the main processor then uses to time the events.

In this manner, the entire power of the trigger decoding microprocessor can be devoted to a single wheel type at a time, so that samples of multiple revolutions could be compared to determine misfire events etc. Completely separate code forks could be maintained for each type of trigger setup.

It would also allow development of code features in the main processor to be unaffected by changes/improvements in the trigger decoding routines. It would possibly free up some hardware timers in the main microprocessor as well.

trigger signal -> ADC -> Trigger Processor -> (trigger bus) -> Main Processor -> spark and fuel events

An extension to this idea is having dedicated event processors to independently drive spark and fuel events. In this configuration, the trigger processor would generate the timing signals on the trigger bus as in my first idea, but these signals would be instead read by the injection and ignition timing processors, which would grab their respective pw and advance values from the main processor via CAN or I2C and fire the outputs based on the trigger bus.

Timing Portion
trigger signal -> ADC -> Trigger Processor -> (trigger bus) -> Event Processors

Calculation Portion
trigger signal -> ADC -> Trigger Processor -> (rpm via CAN or I2C) -> Main Processor -> (pw and advance via CAN or I2C) -> Event Processors

This method would entirely remove ALL timing requirements from the main processor, so that it would be concerned only with reading rpm, tps, etc, calculating fuel requirements, and writing these values to a databus.

I know with this method we end up with having to run at least 4 separate processors, but realistically the event processors would just be cheap PICs with as little I/O as possible (just need (CAN or I2C, 2 digital inputs for reading the trigger bus, and 1 digital output per driver channel).

Also, consider the possibility of having the trigger and main processor on a main board, and simply connecting fuel and spark daughter-boards as required. Having a standard trigger bus signal would allow development of these independent applications as completely separate codebase from the main system.

Sorry for rambling, I am actually planning on testing this concept with a couple of propeller processors in the future. I welcome advice and suggestions on this matter.

[Fred]

Hi guys

Sorry for the delay responding, I was doing some "durability" testing on a toyota in the Irish hills ;-)

Where to start... hmm

Firstly, megasquirt and vems and anything else that springs up are not swear words here. Feel free to mention both positive and negative aspects of them here where appropriate without breaching copyright etc and causing trouble.

In terms of reading the wheels, I strongly believe that it is desirable to have separate code for each pattern. This ensures a few things, namely A the code is as efficient and optimised as possible without being obscure B the code is personally taken care of by a particular user of it and maintained/released with proper testing.

This is very un-ms in that a firmware revision that you upload will run only your trigger setup and nothing else. What this means is that you will have no config in that regard to get wrong or fiddle with. You just setup the basics and other stuff and go. Hopefully because it's a special release, it is well tested and changes to other modes do not affect it at all.

As cam pointed out, the aim of this site isn't to have as many users as possible :-) It's to have a viable option for users that want a pure diy solution to running their engine. This is not going to be a free megasquirt, it's going to be something different :-)

As for ADC sampling... hmmm. First of all, by far most RPM signals are digital in nature. Secondly, sampling ADC channels is not instant. Thirdly, trying to interpret the signals that way would take a LOT of cpu power for a conventional core. A DSP could do it, have a read of this thread to see that being discussed. I'm not a fan of it though. I agree with what Keith has to say. Bruces A - B comparison is somewhat valid, and he is right that it is mostly users stuffing it up, but that is what you get when you sell a cheap commercial product. The wrong people will buy it :-)

For us, the ONLY analog rpm input is VR stuff, and the lm1815 is the way forward in that respect IMO.

I'm all for being able to view a graphical version of the signal though. This is a huge aid in trying to diagnose no start conditions. I just thought of a way to add that to the code without much change at all, so I'll do that now. (support for it from the outside at lower rpms anyway :-)

Fred.

[thebigmacd]

Back from the dead I know, but I just came across this video of Motec M400. At 2:31 it shows a screenshot of a triggerwheel diagnosis screen showing the actual waveform from the VR sensors and the theoretical waveform. It even shows the zero-crossing delay in reference to the tooth edge.

http://hk.youtube.com/watch?v=5JxMl5oMr ... re=related

[Fred]

Back from the dead I know

Never worry about that, I prefer it! Having 30 threads that say something like "why only 6 cylinders" or similar is non-optimal :-)

http://www.youtube.com/watch?v=5JxMl5oM ... re=related

How do you know that is a motec screen shot and not some other system in parallel? Is it listed in the motec feature list?

That signal is noisy as hell :-/ I'd be wanting to fix that before I went any further anyway.

Fred.

[thebigmacd]

Back from the dead I know

Never worry about that, I prefer it! Having 30 threads that say something like "why only 6 cylinders" or similar is non-optimal

http://www.youtube.com/watch?v=5JxMl5oM ... re=related

How do you know that is a motec screen shot and not some other system in parallel? Is it listed in the motec feature list?

I don't. But it does say Motec and ADL2 in the title.
Whatever it is, it shows an overlayed tooth edge and trigger point plot.

That signal is noisy as hell :-/ I'd be wanting to fix that before I went any further anyway.

Fred.

It might be just their sampling method and/or display control doing that.