My first PCB design project for Formula SAE

[electrolust]

I should be able to get all of the CAN bus signals generated by default from MoTeC, our ECU manufacturer.  The only reason I can see needing that information is when I'm trying to designate priorities to the signal inputs to make sure that something like brake temperature doesn't have priority over a knock sensor, for example.

The motec will be relatively quiet, and I'm pretty damn sure knock sensors (and most all sensors) will be hardwired to the ECU.

The EDL3 almost certainly has more than 1 CAN bus, so you should just run your data on a different bus than the ECU.

Have you looked at ready made products?  The low cost ones I've surveyed don't have the precision or speed needed for things like brake pressure, damper position, etc, but probably would do well for brake temp, etc.  Texense, beru, etc probably have high dollar ready made solutions that are more capable, and might be welcoming to an FSAE sponsorship proposal.

Of course, a ready made product might be besides the point of the project.

[AustinEngy]

Of course, a ready made product might be besides the point of the project.

You've hit the nail on the head with that one.  Our electrical system has lost us design points every year for the last 5 years or so.  I know that there are already solutions available, hell, MoTeC sells a module that does the same thing.  But I have found that so far working on this project has given me a whole lot of things to talk about to prospective employers, where purchasing a ready-made solution wouldn't give me that advantage.  Additionally, the points we would get in design for actually coming up with our own solution would be significantly higher, if it works well!

Thanks!

[AustinEngy]

Quick update on the project.  I've decided that it would me much easier to program and more convenient to use an Atmel MCU and an MCP2515 CAN Controller instead of the PIC18 I've been considering.  There are numerous CAN libraries available for Arduino, and pretty much everyone is at least somewhat familiar with the Arduino IDE these days.  It's not going to cost me too much time to implement, but a notable change.  I've finalized my input protection circuit based on the suggestions in this forum and I think it should work out pretty well.  I've tuned the lowpass filters to 1250kHz and added some diodes for extra protection.  Please let me know if there's anything I'm missing now, or if my passive component values are unrealistic.

One question I have, how do I know what kinds of values should I use for resistors and capacitors?  My main concern is with the voltage divider equation, since I'm not sure I'd be able to get an exact drop to 5V in this circuit using off the shelf resistors.

[RR]

1,25MHz lowpass?Thats not get much sense go much lower like few kHz max. Depends on how fast is your ADC and actual signals you want to look at.

Put resistor before that diodes protection that way there is nothing to limit current so they will blow if something happened.

That decoupling cap you have connected to 12V but op amp is powered from 5V rail. also dont forget that its not ideal op amp so something like rail to rail inputs,outputs and offset might surprise you in this configuration.

In datasheet should be specified max input impedance for ADC. With 127k ohms you killing the purpose of the buffer.

[AustinEngy]

1,25MHz lowpass?

I'm pretty sure I calculated that right to give a cutoff of 1.25kHz for both filters...

Put resistor before that diodes protection that way there is nothing to limit current so they will blow if something happened.

Good point!  I will throw one in there.

That decoupling cap you have connected to 12V but op amp is powered from 5V rail. also don't forget that its not ideal op amp so something like rail to rail inputs,outputs and offset might surprise you in this configuration.

I'll add a decoupling cap to this schematic, but I have included a few in my other schematics that have the actual MCU and CAN chips.  I'm aware that I probably will not get a perfect attenuation between the 12V signal and the 5V signal, but I'm not sure how to go about dealing with this.  Are there any suggestions you have for this sort of circuit?

In datasheet should be specified max input impedance for ADC. With 127k ohms you killing the purpose of the buffer.

Thanks for letting me know about this.  The ATmega32A has a maximum impedance of 10k?, so I can see that I will definitely have to reduce that.  Do you think that having that lowpass filter on the other side of the buffer is even necessary?

Thanks!! 

[max_torque]

The Mega series of uCs has a roughly 10kps maximum ADC sampling rate, with an 8 channel multiplexer.  Hence if you want to sample all 8 channels, your max sampling rate is 1.25Khz, and the max frequency you can measure is half that!

Although Atmel recommend a max input impedance of 10k to minimise ADC errors (from the sample and hold capacitors), you can just put a small capacitor on the input line and retain most of the 10b accuracy of the ADC (because that capacitor supples the current to charge the ADC sample caps without the voltage changing significantly.


For most projects, that have a slow sampling rate, using something like 33k input R, and a suitable cap (to form an anti alias filter) works well for most automotive signals that have a low output impedance (ie active sensors)  If you want to use passive, high resistance sensors (for example high resistance thermistors) you will need to buffer the inputs.

[eneuro]

The Mega series of uCs has a roughly 10kps maximum ADC sampling rate, with an 8 channel multiplexer.  Hence if you want to sample all 8 channels, your max sampling rate is 1.25Khz, and the max frequency you can measure is half that!

It depends on ADC clock speed set At 250kHz ADC clock and 13 clock cycles per ADC sample we have 19kHz sampling rate and a lot of MPU time between measurements eg. to respond for I2C request from another (master) MPU to gather information from many such sensors running not on one MPU but in parallel. I use many cheap small SO-8 ATMEL AVR ATTiny85 in sensor modules which during measurement does no I/O only senses ADC and whole processing and communication is made during ADC conversion, so there is nothing which disturbs MPU when taking ADC sample 

[AustinEngy]

Okay, so I've finally got a schematic for the MCU, Controller and Transceiver that I'm comfortable posting.  I haven't finalized the values for resistors and capacitors, but I know where they are needed.  On the left are the inputs to the MCU and to the right is the CANHI and CANLO outputs.  An interesting thing here that I haven't really seen in commercial CAN bus shields is the use of the MCP2561 that has SPLIT and Standby pins.  I'm not sure how I could make use of the Standby pin, but clearly the SPLIT is an easy way to have a more reliable bus.  I'll attach a snippet from a datasheet about the SPLIT pin and what it is used for.  I have a couple questions that I haven't really been able to find answers to in datasheets or online.

First off, on the MCP2515 CAN Controller, what's up with the three TX Request to Send pins?  In all the schematics and implementations of this chip I've seen commercially they are just left untouched, just like the two RX buffer pins.  Does anyone know what use these pins serve, or are they just meant for diagnostics?  Finally, there is the Interrupt output pin on the MCP2515, and again, I have no idea how this would be used.  I'm assuming that it would be important if I had another chip that needed an interrupt output, or is it actually meant to plug into the MCU to act as the interrupt to let the MCU know there is another, higher priority signal on the bus?

That's all I have for now.  Thank you to all who are helping me out on this project!  I'm having a lot of fun learning all this stuff.

[AustinEngy]

Forget what I said about the STBY pin, I'm just going to ground it permanently because the idea of these nodes is that they are always transmitting the sensor data.

[max_torque]

On the MPC CAN controller chip:

The TxB pins are to allow you to load the controller with CAN data, and send those values repeatedly by pulling those physical lines low.  For some applications, which repeat the same messages lots of times, this limits the amount of work the host uC has to do over the SPi bus.  However, generally, these are not used, and you simply load the data over SPi, and then trigger the controller to send the data by setting a bit in that controllers register, again, over SPi. 

The "interrupt" pin is much more useful and should be used!  When a message arrives that matches the internal message mask/filter register values in the controller (loaded from the host uC at initialization), the INT pin goes low to signal a valid message has been received.  You then use that interrupt to call a function to unload that message from the controller.  If you don't use this pin, then you must continuously POLL the controller to see if a valid message has arrived, which takes up a lot of your host uC time!

It's also important that you promptly unload the CAN controllers Rx buffers when a valid message arrives, otherwise you can miss messages if another one arrives and overflows that buffer (various buffer modes are available, and you can trigger fault flags on overflow etc)


You can use the RxB pins to drive RX / TX leds, which is really useful to show CAN bus activity!!

[max_torque]

Some other suggestions:

1) don't "share" the Xtal across two devices, use the AVRs "Clock out" pin to buffer the clock out to the CAN controller
2) Put a 100K pull up on the chip select line for the CAN controller, to ensure it stays un-selected when the AVR is in RESET

[eneuro]

Forget what I said about the STBY pin, I'm just going to ground it permanently ...

Probably good idea according to MCP2561 High-Speed CAN Transceiver datasheet 

Normal mode is selected by applying a low-level to the STBY pin. The driver block is operational and can drive
the bus pins. The slopes of the output signals on CANH and CANL are optimized to produce minimal electromagnetic emissions (EME).

I was looking for what to do with Rs 8 pin of similar MCP2551 CAN Transceiver, so I've quickly looked to MCP2561 what is going on on this STBY pin, since I might want use it in another too, instead of MCP2551 

[AustinEngy]

2) Put a 100K pull up on the chip select line for the CAN controller, to ensure it stays un-selected when the AVR is in RESET

Are you talking about putting a pullup on the SS pin for the SPI between the MCU and Controller?

[max_torque]

2) Put a 100K pull up on the chip select line for the CAN controller, to ensure it stays un-selected when the AVR is in RESET

Are you talking about putting a pullup on the SS pin for the SPI between the MCU and Controller?

Yes.  The AVRs In System programming is done on the SPi bus pins (SCK, MOSI,MISO) whilst the micros reset pin is held low.  As the AVR puts all it's I/O into high impedance mode when in reset, it's important to ensure any Chip Select lines are held high be external means, otherwise all sorts of strangeness can occur when you accidentally send wads of bytes down the SPI bus to re-program the micro!

[AustinEngy]

Awesome, guys.  Here is what I've gotten after your suggestions and some more working around.  Hopefully I'm getting pretty close to a final schematic for this thing!  The next step will be to make sure that my component values are okay and to adjust them if necessary.  Then I'll move on to getting the input circuitry looking good.

[RR]

-no big caps around 7805?
-why you have osc2 clock from mcp2515 go back to mcu?
-rule of thumb - one decoupling cap per power pin so if you have room around mcu add more on pcb. if you will not need them later you just dont populate them.
-100k ohm pull ups are probably too weak

maybe use more labels in schematic so you dont have that much crossing lines in schematic but thats just my personal opinion.

[eneuro]

-100k ohm pull ups are probably too weak

On Reset pin with BOD enabled we might want low power detection and MPU restart as quickly as possible, so 1N4148 diode in Vcc direction might help protect MPU from running code at undervoltage conditions 

BTW: 100k is more than internal pull up resistors in those AVR I/O circuit I guess...

[max_torque]

I usually link the reset line of the can controller and the uC.  That way the CAN controller will be pulled to an inactive state when the uC is.  if you are using a specific reset controller chip for BOD, then the CAN controller gets the benefit of that too.


You need to use the CLKO pin from the AVR (PB1) and set the "Clock out" fuse when programming.  That should be connected to OCS1 on the CAN Controller (you can leave OSC2 unconnected)

[AustinEngy]

Alright, so I've been very busy with coursework and internship related things for the last week, but I've had some time here and there to modify my chip circuit.  I've fixed the values for the resistors throughout, and also added labels to the SPI bus instead of wires to simplify things a little bit.  I could take it a step further and do the same for the inputs if I want.  I haven't put a whole lot of though into specific values for capacitors, but I'm also not that concerned at this point.  Another thing I've been thinking about is how to have circuitry that would allow me to have digital inputs as well as outputs without having to take up two pins.  Since I have input filtering for digital inputs, I don't want to have this same filtering if I decide to use an output.  Would putting a diode around the protection/filtering circuit do the job?  I know I would have to account for the 0.7V drop across the diode, but what other ways are there around this?

Would it just be easier to use the remaining pins as dedicated outputs?  I want to have flexibility so these modules can be used with inputs and outputs and I wouldn't have to make different boards for different parts of the car.  The front module would need digital output because of the driver feedback dash, for example, but the rear mounted module wouldn't need this feature.  Would it be best to just leave the components off of the desired outputs and do solder jumps between the pads?  Or is there a legitimate way to have protection circuits function for both input and output?  I'll attach my most recent chip schematic and an idea for a 5V digital input/output filtering schematic.

As always, thanks for any help!

[AustinEngy]

-no big caps around 7805?

I was totally confused about what you were trying to say because I don't actually have a voltage regulator in my circuit but was initially planning on doing something like that.  I came across a product by RECOM that takes a given input voltage and converts it to a steady desired voltage.  http://www.recom-power.com/pdf/Innoline/R-78Bxx-1.0_L.pdf  So it looks like on my schematic it says 7805, but it actually says 78-B5.  I know that I could make my own circuit to do this exact thing, but in the interest of saving time and board space, an off the shelf solution should work just fine.  After taking a closer look at that datasheet though, some of their examples do show an output capacitor, so I might include one just to be on the safe side.

[AustinEngy]

So, another idea I've had with regard to setting the pins as inputs or outputs, is to use a MOSFET with the drain at the digital pin, source at the output pin and have the gate connected to a DIP switch array with a pull up resistor.  Is this a reasonable solution?  Of course, it would require changing the programming on the MCU, but it would be far easier than having to depopulate the input filters to change to an output. 

I could come up with a quick schematic in Altium, but figure it'd be better to see what problems I might encounter first.

[ajb]

I wouldn't try to make switchable inputs/outputs, the sorts of protective measures you need for the two functions are sufficiently different that it gets really messy to try to combine them, and then you have the problem of making sure that the firmware matches the external connections in each of your different installations, and so on. 

If you really want the option of adding on some outputs later on, you could just put a connector on the board with Gnd, Vcc, and I2C (and maybe an #INT line or three), and later on design a simple PCB with an I2C output expander and whatever protection/interface circuitry you need.  That gives you the option of connecting all sorts of different expansions boards that you can design as needed, with logic outputs, relay drivers, or whatever--even additional analog IO. 

Another option would be to go with a larger MCU, and route the extra GPIOs to a header.  This could be useful if you might need to directly interface MCU peripherals (timer channels, UARTS, or whatever) to an expansion board or external peripheral.  It takes more pins than just an I2C interface would, but is more flexible.  And of course you could include an I2C interface and have the best of both worlds.

The dashboard frankly sounds like it ought to be a separate project, since presumably you'll want to install that in a different spot than the sensor interface unit and the hardware needs are going to be different.

[AustinEngy]

Thanks for the suggestions.  I think I might just leave it alone for now, then, since I'd like to just get it up and running for this year's competition and just design it exactly how we need for our current sensors.  On a side note, the dash is incredibly simple, just four 12V high brightness LEDs to let the driver know critical information.  I will just focus on prototyping what I have and get that working.

[RobertBG]

I had a amazing time doing Formula SAE    we could have really used a EE at the time.

I skimmed over the details after the first page but I highly recommend trying to find a copy of the book titled  Automotive Embedded Systems Handbook.It isn't cheap but there's probably a few free copies floating around the net.

Also it is quite easy to put together a simulator to bench test your designs and there's also a few programs floating around the net to help with this.It would save you a lot of time and headaches fighting over the car for testing time.Being able to test your work in a running car's noisy environment will really help you.Also having everything ready to install means more fun with the car when it is your time Lastly while I'm not a EE,with cars a lot of noise can be introduced into wiring from things you'd never imagine and where you run your wires can make or break things no matter how well engineered the electronics are.

[AustinEngy]

Okie dokie!  I'm in the final stretch here of schematic design, I've decided to redo a lot of it to make it look better.  I'll share an Exhibition schematic I put together that has all major parts of the whole schematic (Each input will have its own protection circuit).  A new component I've added is a polarized cap at the 12V input header for decoupling, but what value should I choose for this cap?  How would I go about determining the value here?  It's just for decoupling to my knowledge, but does it solve any other potential problems?  Regardless, if there's anything I'm really missing, or some clever Altium tips that would make my schematics loo better, please let me know.  I think I have enough of an idea of what it's going to look like, so I should be able to button it up when I breadboard it.