Project JAGuar for FreeEMS

[DeuceEFI]

6. BOM calls out a crystal with 20pF load capacitors, but schematic and BOM indicate 18pF caps are being used (not sure of the impact).

You will probably find that you cant get a nice 16MHz crystal that requires 22pF load caps. 18pF/12pF is probably a better choice for crystal availability.

Hence the 18pF caps instead of 22pF...

Hopefully a better description of my concern -
The mfg's specifications for the crystal that is on the BOM, specifies 20pF load capacitors (which in my opinion is what should be used). The load capacitors may / will be different for other 16MHz crystals depending on the mfg, mounting type, series,... I really don't see a good reason to use anything other than what the mfg's spec for this specific crystal says to use.

I have changed the BOM and the schematic to use the 20pF load capacitor as per the manufacturer's specification after rethinking my choice of the 18pF load capacitor after Dan's recommendation. I have the same crystal installed on a prototype board with the same 112pin Freescale CPU with 22pF load capacitors and it works fine, so I see no reason to go down to 18pF, so 20pF it is.

7. 10k resistors on the VR inputs are only a 1/4W per the BOM. Your call, but they may over-dissipate (see my comments in the thread you reference in your VR note). Hmmm, I'm wondering why is there a 5k resistor on the VR inputs?

I copied the same circuit from the Ravage.PDF file and those were the values that appear. I'm not using the VR sensor input, I'm using a Hall Effect sensor for my Crank and Cam sensors, so if this needs to be changed, just let me know

There is currently only a schematic for Ravage, which specifies a 10k resistor (correct), but a BOM has not been created yet so the wattage of the part is unknown (which is why I am still on sheet 1 of my Ravage review : ) But in your case, a 1/4W resistor was called out so I am concerned that this dissipation is not enough for the application (my concerns are related in the noted thread). Since you are using Hall sensors, really doesn't apply, but may impact others who would use your board with VR type sensors. Which brings up another comment / suggestion - should there should be a way to "jumper" around the MAX9926 sub-circuit for Hall only applications so you don't have to populate the VR stuff?

A. So my 10k resistors on the VR inputs should be 1/2W instead of 1/4W?
B. Are the 5k resistors across the CRANK+/CRANK- and CAM+/CAM- even needed? I'm not sure why they are in the Ravage schematic after reading the thread where you Jared, Fred and Jean talk about the VR circuits...
C. Well, here's what Fred recommended for the Hall inputs:

Just to get this in quickly, and not having had time to reply to the previous posts, but although you CAN use a normal logic buffer for digital inputs, you're better off using a schmidtt trigger for noise immunity, consider this. Also, if you use the max9924/6 chips, you have the option of going VR later, though they are significantly more expensive than a normal IC.

I think this is a good idea to keep the MAX9926 sub-circuit even for Hall only applications, we just won't populate R20 and R23 (if they are even needed for the VR inputs) and if the user wants to use VR inputs, they don't need to populate R21 and R22. Does this sound OK?

8. The MAP sensor power supply de-coupling and output filtering doesn't seem to match what is in the datasheet for this part or the general application note referenced in the datasheet (not sure of the impact).

Here again this is the same circuit in the Ravage.PDF file...

I think that the "inputs" on Ravage are still to be reviewed by Fred (others), but either way, I am just pointing out my concern and will leave it at that.

The Ravage design and mine have more de-coupling than the MS-POO that is currently running the V6 in the Deuce now and I'm not having any issues with the MAP readings (that is one of the few things I'm not having an issue with on the MS-POO, lol). R13 (1k) and C20 (0.22uF) are the only differences between the DS and the AN, which are dependent upon the Freescale CPU input (Fred recommended these values back on page 4 of this thread). If I'm totally off base, please let me know, I want to get this right before ordering any components

9. On the power supply sheet, there are two identical regulators with different bulk capacitors.

Fred and I have discussed this in past posts and determined that having a large cap before the CPU isn't necessary since the regulator is close to the CPU.

10. The BOM seems to have at least a couple of instances in which the same type/value part is on two different rows. You also may want to see if can can substitute parts with similar values to one common value/part.

The point I was trying to make is that you might want to review the BOM, and make changes to the schematic design to minimize the number of unique part types on the BOM. For example, do you want to have one 22uF and one 47uF cap on your design/BOM or two 47uF (you also might want to consider 10V parts as they appear to be considerably cheaper). Why specify a single 2k resistor (R55) whose only function appears to be a pull-up (can't you just use another 2.4k?). Are three different de-bug LED colors needed if you are going to put the board in a case? Can you substitute another 10uF/35V cap for the single 4.7uF/10V?
Also, note that C23 and C42 are the same part, but on two different rows

Ok, I see where you are coming from, LOL, some times I can be a little dense... I have changed the schematic and the BOM from using a 22uF/16v and a 47uF/16v to using 2x 47uF/10v on the outputs of the regulators after giving your comment more thought and re-reading Fred's post about caps on the outputs of my regulators.

I also changed R55 to a 2.4k resistor since you made a valid point, there was no good design reason why R55 needed to be exactly 2k.

As for the 3 different color LEDs, I wasn't going to include them at first (and will probably only put them on the first prototype board for bench testing), but they are there if someone wants to populate them. I figured, if they wanted to populate them, they have the option of different colors and I give them the part numbers for the different colors so they can mix and match. I thought the CEL LED should be a different color than the I/O LEDs since it was supposed to be an Error Light... just my $0.02

The 4.7uF/10v cap is recommended on the VCC input to the FT232RL chip per the manufacturer's AN146, page 6-7.
Here's a link to the AN:
http://www.ftdichip.com/Support/Documen ... DI_ICs.pdf

I corrected the C23/C42 being on different rows, you are correct, they are indeed the same value and part number...

Please don't interpret my comments as being written in a negative way, I think you are doing a GREAT job but unfortunately I write my comments after a long day at work and after a few (quite a few : ) beverages.

No worries, this is an open discussion and I welcome any feedback

It's about time for some beverages for me as well...

Haven't passed out yet so -

Me either, so I'll keep typing... lol

11. You may want to consider connecting VDDA on the uC to VCC instead of VDD.

Freescale recommends that VDDA go to VDD (VDD is 5vdc-cpu on my schematics and VCC is the 5vdc-analog supply), see page 1297 of the Freescale MC9S12XDP512 Data Sheet, Rev 2.21... But I would like to know why you think it should go to VCC (5vdc-analog supply)

12. You may want to consider connecting the Check Engine Light sub-circuit to VDD instead of VCC (it really doesn't have much to do with the analog stuff).

My reason for this was to keep the CPU power supply separate from the I/O ports, which PA6 is an I/O port not a CPU power supply pin, here again, just my $0.02...

13. Can you use a single 5V regulator instead of two since you aren't planning on using the "always on" topology?

Technically yes, I could, but I would rather not power the TPS from the CPU regulator. My MS-POO does it with one, but I don't personally like that approach. However, we can leave it to the end user to choose one regulator or two, the would just need to run one jumper wire from the output of one regulator to the output of the other regulator to connect VCC (5vdc-analog) to VDD (5vdc-cpu). This would cut the CTM by $5.54 USD...

I've committed/pushed my KiCAD schematics and the Jaguar.ods (BOM) to my repository, I will update the PDF's in the morning...

[Fred]

Man, lots of posts, shoulda got in sooner. This will be incomplete, I'll get back to it later.

The point I was trying to make is that you might want to review the BOM, and make changes to the schematic design to minimize the number of unique part types on the BOM. For example

See how much better results you get when you actually use specifics? :-p I mean, in terms of your point being made, or not :-)

Huff, SUPER surprised to hear a man of your experience saying "blindly use manu recommended crystal load caps" - you should know that they are A) usually lower than specified B) that the correct value can only be found in circuit due to parasitic capacitances (why it's usually lower) and C) a fairly wide range of values usually work anyway.

The MAP sensor output filter IS correct (It's the only filter that is correct in MS schematics, btw) and the decoupling is adequate.

Agree with two reg approach for external influence over supply reasons.

MAX chips, though pricey, offer better noise rejection for hall applications too. Not quite as good as a schmidt trigger, but better than a normal IC.

VR sensor input resistors can be derated in the same fashion that you derate the transformer in an amplifier. IE, worst case heat is from a 60 tooth VR wheel spinning 10k continuously. Just like you don't listen to sine waves at maximum volume, real music has lower average power when the peaks are nearly clipping. Chances of that are something like this:

(5% of cars have 60-2) * (fred driving, not anyone else) = 0.00000000000000000000001% :-)

Reality is that average power dissipation matters and if you're thrashing it, that's the point half way between post shift and rev limit. Even then it depends on the particular setup, how tight the tolerance is, the type of steel used, the size of the magnet, etc etc. Reality is that people get away with a lot less using SMD resistors with zero reliability concerns.

The 5k decreases the input impedance to high impedance noise sources without affecting the low impedance signal source much. This is a toyota design feature, right out of an OEM ECU. It's a nice touch.

Enough for now. I feel like I've forgotten to argue about some key things. Hopefully the latest schems haven't regressed!!! :-/

Fred.

[lumpensack2003]

The 5k decreases the input impedance to high impedance noise sources without affecting the low impedance signal source much. This is a toyota design feature, right out of an OEM ECU. It's a nice touch.

Recently I quickly built a signal conditioner for a Moto Guzzi bike.
Without a 2K2 shunt outside the 10K in-lines the bike won't run throughout the whole rpm range.
Was a LM1815 chip, though.
Even if not needed - the option to stuff this resistor should stay.

[Fred]

Recently I quickly built a signal conditioner for a Moto Guzzi bike.
Without a 2K2 shunt outside the 10K in-lines the bike won't run throughout the whole rpm range.
Was a LM1815 chip, though.
Even if not needed - the option to stuff this resistor should stay.

<3 :-)

[DeuceEFI]

Ok, I don't mind keeping the 5k resistor across the VR input as an option, no problem

From the MAX9926UEVKIT.pdf for the evaluation kit, the 4.99k resistors are 1/4W each in series (2 on IN+, 2 on IN-) and it states it is for 50mV to 300V pk-pk VR inputs, so my 10k should be 1/2W each if VR inputs are used, correct? Or should I specify 1W resistors?

[DeuceEFI]

Back to the crystal load capacitor question...

Ok, I checked the DS for the crystal I chose and it looks like Dan is correct (when he stated to use an 18pF or a 12pF based on the available crystals) the manufacturer recommends between a 10pF and 20pF capacitor, so I changed my crystal load capacitor to 12pF as the Freescale CPU states in its DS that the input capacitance of the XTAL and EXTAL pins is 7pF, so adding the two together (12pF + 7pF) would give us 19pF which would be close to the crystal manufacturer specification for load capacitance.

Any thoughts about my logic on this one?

I have included a screen capture of the part of the DS showing the load capacitor spec, along with a capture of the Freescale input capacitance spec for the XTAL and EXTAL input pins.

[DeuceEFI]

I have updated my schematics, BOM file and the schematic PDF file to show the 12pF crystal load capacitors in my repository.

Please review when you get a chance

[Fred]

My thoughts are the same as for RavAGE and Puma and the only reasonable thoughts for something of that nature: Order multiple values ;-) Sure, bang in 12 and see what happens. If it works well, oscillates at the right frequency and is stable, leave them in there.

[TonyS]

Freescale recommends that VDDA go to VDD (VDD is 5vdc-cpu on my schematics and VCC is the 5vdc-analog supply), see page 1297 of the Freescale MC9S12XDP512 Data Sheet, Rev 2.21... But I would like to know why you think it should go to VCC (5vdc-analog supply)

Ding Dong, I'm Wrong (Assumed that since it is the supply to the A/D section of the uC that it should be tied to the "analog" regulator).
Everything else is your (reasonable) call, and I appreciate that you (and Fred) have taken the time to explain your reasoning.

Only other thing that I can see right now, is that the crystal is spec'd for 70C max. and I am not sure if you have a higher operating temperature environment spec as a target (85C?).

Thanks,
Huff

[TonyS]

One more little thing -
The schematic shows 22uF caps on the outputs of the regulator and the BOM calls out 47uF.