Sanity check: inverted primary trigger required for JimStim?
#1
Sanity check: inverted primary trigger required for JimStim?
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:
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:
#3
Boost Pope
iTrader: (8)
Join Date: Sep 2005
Location: Chicago. (The less-murder part.)
Posts: 33,020
Total Cats: 6,588
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.
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.
#4
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.)
#5
Boost Pope
iTrader: (8)
Join Date: Sep 2005
Location: Chicago. (The less-murder part.)
Posts: 33,020
Total Cats: 6,588
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.
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.
#6
Gotcha.
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.
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.
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...
#7
Boost Pope
iTrader: (8)
Join Date: Sep 2005
Location: Chicago. (The less-murder part.)
Posts: 33,020
Total Cats: 6,588
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.
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.
#8
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.
#11
Boost Pope
iTrader: (8)
Join Date: Sep 2005
Location: Chicago. (The less-murder part.)
Posts: 33,020
Total Cats: 6,588
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.
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.
#12
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...
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.
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...
#14
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.
Oh well, at least I got to debug this on the bench and not on the car Thanks for your help, Joe.
#15
Boost Pope
iTrader: (8)
Join Date: Sep 2005
Location: Chicago. (The less-murder part.)
Posts: 33,020
Total Cats: 6,588
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.
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.
#16
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.
#17
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.
#20
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)