kday

I'm running MS2Extra 2.1.0 on the bench with the JimStim. Not tested on the car yet. I have inverting optocouplers on each "CAS" signal. I only get a good tach signal in two cases:

Inverted primary, non-inverted secondary, falling edge trigger
Non-inverted primary, inverted secondary, rising edge trigger

This makes some sense from what I see on the scope:


Clearly the secondary trigger frequency needs to be 1/4 of the primary to function. What isn't clear to me is why the non-inverted primary non-inverted secondary case doesn't work with a rising edge trigger (which should result in the same pattern).

(Incidentally I am curious what the purpose of the second hole in the secondary ring is for -- it is not decoded if only one edge is looked at. If both edges are used then it does give two indexes per revolution -- but how is this useful? Slightly quicker sync at start?)

Anyway, before I dig into this further I thought I'd ask if this is normal -- does the JimStim need one of its outputs inverted to drive the dual-inverting-opto inputs on the MS2?


I haven't tested it on the car yet because I've been busy building this:

kday

In case it wasn't clear, when I wrote about trying inverted and non-inverted signals, I am referring to flipping dip switches 7 and 8 on the JimStim. The (inverting) optocouplers remained in the path at all times.

Joe Perez

iTrader: (8)

It appears from the scope trace that you are using an NA CAS. The "typical" configuration of the JimStim in that case is switches 2 & 3 on, all others off. This will faithfully simulate the action of the CAS when both lines are externally pulled up at the CAS output.

It's been a while since I played around with the stock CAS, however with the MS1 at least, my recollection is that the falling / rising settings in the software were ambiguous at best, as there didn't seem to be much consistency in how they were referred to with reference to the fact that the stock MS tach input circuit is inverting, while the usual secondary input is built to be non-inverting. Not sure how MS2 handles this.

kday

I haven't actually ran with the CAS yet. I am trying to figure out if I am simulating a good CAS signal with the JimStim or not. I will be using a NA CAS at least to start with. (Car is a 1990 with stock engine; once MS is up and running I will swap in a 1996 engine w/ the extra wheel on front to play with.)

Joe Perez

iTrader: (8)

Gotcha.

This is one of the less well-documented aspects of the MS on a Miata, however I think I can honestly say that most people have had success in simply following the directions without actually understanding what's going on, much less breaking out the scope. (I'll admit to being the guy who spent way too damn much time with the scope, which will make sense if you click the Wheel of Timing link in my sig.)

If you haven't already, I'd suggest that you take a look at the 4G63 section of the MS2Extra documentation. They give both a hardware diagram and a software configuration which ought to work. Again, with switches 2&3 on the JimStim on, and all others off, you will be properly emulating the stock CAS. Thus, set it that way, install the appropriate pullups, and make the software and input circuit work in that configuration.

When you switch to the later engine, be aware that the stock crankwheel sensor on the '96-'97 is a raw VR device, whereas the '99+ cars use an open-collector output just like the CAS. So you'll need to build the VR decoder for that, and of course you'll still need to keep the CAS for the second trigger, as the stock crankwheel is not a missing-tooth configuration, nor does it have enough teeth in the first place to make it one.


So, spill the beans on that cool-looking digital dash. I'm guessing that you're interrogating the MS over the serial port and sucking data from it, but you're clearly not using an off the shelf display device like MegaView.

kday

Hmm. In other words, the signal that is properly driving my MS2 on the bench is not the same signal as the CAS outputs, and when the JimStim is set up to accurately emulate the CAS, the MS2 is not triggering. This is odd, since my secondary input circuit is similar to the one in the page you linked in that it also inverts the signal. I will have to double check how I did the primary input but I am pretty sure I used the MS PCB 3.0 opto input.

Yup, the plan is to populate the VR input circuitry on the MS when I swap engines. If that doesn't work out I will add a wheel of some sort. (Side note: the old Motronic-based Audi turbo I have has a very overengineered but impressive system for this: a VR-sensed 135 tooth wheel machined into the flywheel for engine speed measurement, a single VR-sensed pin on the flywheel for indexing, AND a hall effect cam index. It sucks to troubleshoot, but it has rock solid timing to <3 degrees resolution...)

It's actually polling the MS2 via CANbus, which is nice since it leaves the serial port free for megatune. Plus I can use it for IO expansion (the MS2 can poll my board as well).

The best pic of the main board I have at the moment:


As you can see it also serves as my MS->Miata wiring harness. It has an Atmel at90can128 which does the display (currently 9 HCMS-2911 dot matrix LEDs) and IO and talks to the MS2. There is also an atmega168 which controls a buffer in between the MS2 ignition outputs and the coils. If it doesn't see an edge for more than a second, it tristates the buffer. (The odds of me absentmindedly frying my coils without this approach 100% )

In the cluster there is an Atmel atmega88 which sits on the same SPI bus as the displays and controls the discrete LEDs (brightness, flash rate, etc.)

There is a bunch of functionality on that big board that I haven't finished yet. It has a serial port input for a GPS receiver (semi-working; haven't finished the tedious NMEA parsing yet), lots of flash for data logging, a footprint for a TPIC8101 knock sensor, a dozen or so GPO transistors, 8 ADC inputs, thermocouple inputs, etc...

Joe Perez

iTrader: (8)

I am truly humbled. My knowledge of CANbus is basically limited to the fact that it falls into the "weird & scary" category for me.

This project is made of pure awesomeness.


Both outputs of the CAS are open-collector drivers. They conduct to ground when the sensor is not on a slot, and go hi-z when the sensor is on a slot. Thus, you should be seeing a signal that resembles the attached image. This timing diagram shows of the CMP and CKP inputs, and the resultant spark trigger outputs. CMP/CKP are measured at the output of the CAS, and assume a 5v pullup on the line. The ignition outputs are measured at the input to the igniter. Trace 1 is CMP, trace 2 is CKP, trace 3 is the brown / yellow igniter wire, and trace 4 is the brown igniter wire.



Yes, it's hand-drawn. The floppy drive on the four channel scope was broken at the time, so I used the cursor function and a ruler. Sorry.

This was taken at idle, which was about 750 RPM at the time. All times are in ms, and are approximate. The traces themselves are sort-of to scale, but I can't draw worth a **** even with a straightedge. Ignition timing was at 15°BTDC.


So, long story short: With both lines pulled up, your CMP and CKP should look like what I've drawn, measured at the input to the MS. I believe that if you set your JimStim with 2 & 3 on and set pullups, this is what you'll see. You then need to make the MS accept these signals. For what it's worth, CMP will need to be read on the rising edge, but that's the rising edge at the CAS, which will be the falling edge after you invert it. I honestly don't know whether MegaTune refers to the signal pre or post-conditioner when speaking of rising vs. falling. With the MS1, a lot of stuff is backwards in this regard.

kday

This is the first project I've done with CAN. I was expecting to spend a lot of time debugging it, but it went smoothly. The "experimental" MS2e CAN code works as documented.

Thanks very much for the drawing! I was thinking I would have to dismount the CAS from the 1.8 and spin it with a drill while scoping it. You've saved me a lot of time. I'll dig into this further and see what the deal is. Worst case I can modify the MS2 code but I'd rather not at this early stage of the game.

urgaynknowit

iTrader: (5)

this thread hurts my head, but i keep reading it because i want to knwo what the hell is going on

N3v

just came to post that I don't understand but it is pure awesome.

Joe Perez

iTrader: (8)

No problem. I just dug out my stim and took a new scope trace for you. This one shows CKP on top, CMP on bottom. Ignore the odd voltage, I only had a 3.3v pullup available. Obviously once yours is running your pullups will be inside the MS and you won't need them on the stim.



As you can see, it's pretty much the same as the drawing. On the CMP trace, the leading edge is the one that's consistent in time, so you'll want to ignore the trailing edge. This is with my stim set 2 & 3 on, all others off, which is the setting that I've used to test numerous Megasquirts, including a pair of MS2s. Make your stim output this signal, then beat the MS into submission until it accepts it.



I have to say, and hopefully nobody else is offended here, that it's a really nice change to go into a "noob pleading for help" post where the first message shows an annotated scope capture and the newb in question clearly knows how to interpret it.



This isn't rocket science. Well, the part where he's using CANbus to communicate between the MS2 and several Atmel microcontrollers is close, but what we're dealing with here is basic TTL interfacing. This is the part where most folks just dutifully follow the instructions and tack a couple of resistors on the back of the board, without knowing or caring exactly how they work.

What you're looking at is the voltage levels coming out of the CAS on the CKP (upper) and CMP (lower) lines. These are the signals that go into the CPU so that it knows where the crank is. The upper trace is the one it actually times to, the lower just serves as a reference so it knows which CKP pulse corresponds to the 1/4 cycle, and which correspond to the 2/3 cycle. The fact that the CMP pulses are oddly shaped should be ignored. Just notice that the leading edges (which are the rising edges here) are evenly spaced, and ignore the trailing edges.

kday is doing things a bit differently, inventing his own input circuits rather than following the book, so predictably there is some confusion. I expect now that he knows exactly what the signal coming out of the CAS looks like, he'll have it working in short order.

kday

Hey, somebody made me an avatar.

Thanks. So it looks like what I measured at the HC12 pins with an inverted primary signal is what you see on your stim with no inversion. Which means mine is wrong, since there is an inverting stage between the MS input and the HC12 tach pin.

This makes sense if the usual way to wire up the MS in a Miata is to use a non-inverting secondary trigger input, which I just found a few references to. (Though personally I would not be tempted to run any signal from the engine bay directly to a CPU pin, resistor or no resistor...) Apparently because my secondary _from the jimstim_ is inverted as well, the MS2 code needs to see the primary inverted to make up for it.

So the question is why in order for the MS2 to sync to the JimStim, the _primary_ signal needs to be inverted. I can think of a few reasons, but the one I think is most likely is that the invert DIP switch on the JimStim firmware does not invert the secondary waveform the way an actual inverter would, or maybe I just have the DIP switches backwards. I will look into this more tonight...

hustler

iTrader: (6)

whoa, big brain crew is

kday

Ahh, never mind the above. Not paying attention. Neither my secondary opto input nor the recommended MS2e secondary input opto circuit inverts the signal. The primary MS input circuit DOES invert (OptoIn goes to the LED anode). I didn't notice until now that the instructions for CAS 4/2 reverse that, so the LED cathode is driven by the CAS sensor. D'oh!

Oh well, at least I got to debug this on the bench and not on the car Thanks for your help, Joe.

Joe Perez

iTrader: (8)

You'll find that a lot of things on MS2 are the way they are because that's how they were on MS1, and a lot of those things are the way they are because, well, nobody is really sure.

On the MS1, the primary input goes to the hardware IRQ line on the processor. This line is falling edge triggered. I can only speculate that some sensors must have provided a reliable (consistent) edge only on the rising side, hence the need for inversion. This was certainly the case with VR sensors when connected in the "correct" polarity, though of course those had their own decoder circuit, where inversion is selectable and, somewhat puzzlingly, incorrectly annotated. Check out grid E4 on page 3 of the schematic. The output labeled "VrOutInv" is in fact non-inverting, and the one labeled "VrOut" is inverting.

The secondary input on the MS1 feeds a GPIO line, and the rising/falling polarity of this input is software-selectable. Thus, we can get away with a non-inverting input and use a simpler circuit. The typical secondary input circuit for the MS1 does not involve an opto at all, just a 5v pullup on the CPU pin, and a direct connection out to the sensor.

I honestly don't know why they recommend an opto for the MS2 secondary, nor why they recommend different configurations for the primary vs. secondary inputs on the MS1. I am reminded of the story of Magic vs. More Magic in that some things are meant to be done but not understood.

kday

Heh, yeah, I'm getting that impression.

Probably something to do with running MS on antique engines with points and one coil

I prefer having the opto there. Without it you'd really want a large value resistor in series, to keep any voltage spikes at a current below what the clamp diodes on the MCU can handle. That large resistance might make the edges a bit sloppy.

Matt Cramer

That's exactly where it came from. The first version of the MS was not intended to control ignition timing, and triggered off the negative terminal of the coil. The optoisolator was for protecting against high voltage spikes, and the fact that it inverted the signal was of no importance.

The optoisolator on the second trigger input is not important in and of itself, but the MS2/Extra code doesn't like it if the signals are inverted with respect to each other. It evidently confuses the way the code is meant to trigger off both edges in the case of the Miata CAS.

Newbsauce

iTrader: (2)

Why can't all our newbies be like this guy?

AbeFM

iTrader: (3)

I really think you don't need to worry about the opto... They are logic level signals coming out - there's circuitry between you and the raw sensor. And if there wasn't, it'd be VR sensors anyway, not exactly going to start any fires with that.

kday

I thought the CAS output was just the collector of a phototransistor... that was what I guessed from the descriptions I've read anyway.

It's not that I expect the CAS itself to output dangerous voltage -- but by default I tend to assume that any signal can have an unexpected voltage on it eventually, especially one that comes from the engine bay and passes near the spark plug wires. Not to mention the non-zero probability of accidentally hooking anything up to 12V... (BTDT)