My first PCB design project for Formula SAE - Page 1
Forum section: electronics / projects

author: AustinEngy
author_rank: Regular Contributor
timestamp: November 10, 2015, 07:19:31 pm
content: Greetings!I'm an EE University student who has undertaken a project for my racecar team. Our car uses a MoTeC M600 ECU and an EDL3 datalogger and was previously wired very simply. Direct connections between these components and the various sensors and actuators on the car were basically all that the electrical system consisted of. This was fine for a time but we have reached the point where there are far too many sensors to maintain a clean and easy to diagnose wiring harness. Naturally, automotive applications rely heavily on CAN bus communications to reduce wiring and increase reliability. My plan is to create four nodes that take analog and digital inputs from sensors, convert them to a CAN signal and distribute the information along the CAN bus to our datalogger so we can analyze everything. At this point, I'm considering using a PIC18F46K80 for a microcontroller since it already has CAN TX and RX outputs and there is a J1939 library available from Microchip. Additionally, I will use an MCP2561 to convert the CAN TX and RX to CANHI and LO signals.Like I said, this is my first design project and first time building something using a standalone MCU (I've used Arduino and Particle Photon to some extent) so what I'm wondering now is if I will need any sort of A/D converter or whether I can just use the analog inputs on the MCU? I've seen some similar projects where people have signal amplifiers as well as A/D converters and I'm just not sure what the best solution would be.My only other concern at this point is programming, since I have very little experience with MPLab and C in general. I've taken a course on C++ and like I said, some experience with Arduino IDE and the Photon. Has anyone here ever programmed a PIC to work with a CAN bus?Any input or suggestions to my project would be greatly appreciated! I will try to answer questions too, if I was not clear about anything.Thanks!

author: ajb
author_rank: Super Contributor
timestamp: November 10, 2015, 08:16:02 pm
content: This is a very broad topic, so if you can provide some more details on the kinds of sensors you're trying to read, that will help encourage more useful responses. In general:Whether or not you can use the internal ADCs depends principally on the resolution and sample rate you require. A big trap with built-in ADCs is that it often isn't possible to achieve the datasheet maximum sample rate and maximum resolution at the same time. I don't know if that's the case for the MCU you're looking at, or PICs in general, but something to watch out for. The other thing to remember is that unless specifically indicated otherwise, MCUs tend to have only one ADC, and the analog inputs are all multiplexed into it. That means that you cannot simultaneously sample multiple channels, which may or may not be a problem for you. In fact, many external multi-channel ADCs are the same way unless they specifically indicate that they can do simultaneous sampling. If you need to measure a lot of channels at a reasonably high sample rate, look into whether your MCU can do round-robin reads of multiple ADC channels into DMA. That frees up the MCU core from having to manage the ADC directly. There may also be options to do some filtering in hardware, which may reduce some processing overheard.DMA may also be helpful with external ADCs if the built-in ADC doesn't meet your needs.If you need more than, say 10-12 bits of resolution, things start getting increasingly tricky. You'll need to pay very close attention to your power supply design, filtering, layout, and ADC reference to ensure that any additional resolution actually provides useful information. You may be limited to only 8-bits or so of useful information from the sensor you're trying to read, so acquiring the signal at any high resolution than that may simply be a waste of bits.As far as signal conditioning between the sensors and the ADC(s), that depends a lot on what type of signal you're trying to read. In an automotive environment, you will absolutely need to pay close attention to input protection (power protection as well, there are plenty of app notes that google should turn up). Presumably any analog sensors in a car will be single ended and 0-12V, so you probably just need attenuation (to scale the signal to a level your ADC can tolerate) and protection. This could be as simple as a voltage divider and a couple of protection diodes, but a more robust solution would incorporate some series impedance, maybe some filtering, and probably a buffer. If you were trying to measure a very low level signal, like from a current shunt, you'd need some gain. Most ADCs require a low impedance input, so if you add a bunch of impedance in the form of input protection, you'll need to buffer the signal right before the ADC, otherwise your sample rate and/or accuracy will suffer. Look at appnotes for industrial sensing, as a lot of the protection techniques they show will be useful for automotive as well.Hope that helps.

author: AustinEngy
author_rank: Regular Contributor
timestamp: November 10, 2015, 09:39:00 pm
content: Since this is going to be the first implementation of this system, I think it might be best to try and implement only a few sensors per node. The most basic list I have right now would be a 0-5V analog brake temperature sensor, a digital wheel speed sensor (I believe it just outputs 12V upon each pass of the sensor ring) and a linear potentiometer for suspension position (Not sure on the model or specifics at the moment since the car is in storage). There are four of these located throughout the car and each node would have to receive the input from these. The CAN bus is being run at 1Mbitps. I do not think that sampling rate will be huge problem since the number of actual sensors on the bus are relatively small compared to what I'm aware of in real-world automotive applications. My personal car runs at 100kbps, for example.I apologize for my general ineptitude for things like input protection and signal attenuation, I just haven't taken courses yet that gloss over those sorts of things. I will try to do some more reading into these key concepts to better understand what you're suggesting. Here is a link to an old project done by another FSAE team that sort of reflects what I'm trying to do. We already have a purchased datalogger, so from this example I'm looking just to do something similar to their "cANHUB". They have a schematic of it at the end of the document.https://courses.engr.illinois.edu/ece395/projects/spring2012/project5_final_paper.pdfYou'll notice that I've selected the same MCU as they did. I looked at potentially using an Atmel MCU as well, but have never used them before so I'm nervous to go with one of those. Additionally, the one I've chosen is the only MCU Microchip has with CAN outputs and a sizable number of analog input pins. In the Illinois document, they just wire their sensors directly to the analog input pins. I don't want to just copy that design though, because I'm sure it can be improved upon. Hope I'm not rambling too much!Your help is much appreciated.

author: AustinEngy
author_rank: Regular Contributor
timestamp: November 10, 2015, 10:16:08 pm
content: I found a sheet with some information about the linear potentiometers that are on the car already, but not sure how useful it would be for this discussion:https://drive.google.com/file/d/0B73F3BPlTrM4eTVnVnBuVWFNZE0xaTJCSlFrZFJONFJDbi13/view?usp=sharingThis is the first year that we have had EE students working on the electrical system at all, so I've sort of been forced to try and learn as much stuff as quickly as possible. I've read some documentation about input protection from DigiKey and found it very helpful, so thanks for sending me down the right path! I will continue to update this thread as I make more progress.

author: ajb
author_rank: Super Contributor
timestamp: November 10, 2015, 10:34:48 pm
content: Quote from: AustinEngy on November 10, 2015, 09:39:00 pmThat design leaves a LOT to be desired. They don't even have decoupling, let alone power protection or signal protection!

author: AustinEngy
author_rank: Regular Contributor
timestamp: November 10, 2015, 11:09:33 pm
content: Quote from: ajb on November 10, 2015, 10:34:48 pmFSAE teams are notorious for not sharing documentation of designs publicly. This is the best that I could find for a similar project. I totally agree that they left a whole lot out of their actual design process, now I know that they lacked all of this stuff too.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 11, 2015, 05:57:43 pm
content: Quote from: ajb on November 10, 2015, 10:34:48 pm+1 -- seems utter catastrophe. It is very surprising if it works in an automotive environment at all. I did similar-looking and similarly lacking MCU designs as a kid, too, and almost always had problems with random resets etc.There's not much application-specific there at all, just a microcontroller powered up and connected to something external -- if you can't find a good reference design on your particular field, try looking atanymicrocontroller board design reference. It will give you a starting point.

author: Someone
author_rank: Super Contributor
timestamp: November 11, 2015, 10:15:25 pm
content: Quote from: AustinEngy on November 10, 2015, 11:09:33 pmHave fun with the project, as a student these are the experiences where you can learn all the little mistakes that cause problems and having a small part of the larger project you are responsible for all the debugging and fixing will be on you. Coming here and reading around and asking questions will help, but it will be as part of much morestudyon your part to try and deliver the best you can, its a learning experience for you and if you can produce some useful outputs from it thats a bonus for your team. If your team isn't able to transfer any knowledge from previous years to you (have you read the reports/papers from previous years?) then at least you can already see one area to improve on!

author: AustinEngy
author_rank: Regular Contributor
timestamp: November 12, 2015, 12:44:34 am
content: Thanks for the encouragement, guys. Since Formula SAE is primarily a Mechanical Engineering competition, our team hasn't really had any EE's historically, so I'm paving totally new ground for the team. I make sure to create a document each month describing what I've found out and done in terms of this project so that future members won't have the same learning curve that I'm having. I might try getting in contact with the Solar Car team here on campus since they are mostly EE's. I'm really enjoying the project and can't wait to make even more progress! I will try coming up with a schematic soon based on the info I've gotten in this thread and go on from there.

author: eneuro
author_rank: Super Contributor
timestamp: November 12, 2015, 01:16:58 am
content: Quote from: Siwastaja on November 11, 2015, 05:57:43 pmThey usedMCP2551 - Interface- Controller Area Network (CAN)which is difficult to kill and I plan use the same in my automotive project to control Peugeot 206 1.4 HDI accelerometer pedal in vehicle without builtin factory cruise controll/tempomat/speed limit function, to communicate different custom made sensors, while it might be difficult to hack oryginal Peugeot CAN/VAN bus to gather needed data from ECU and BSIWhen we replace thisLD1117V33with something more usable in automotive environment eg. LM2931AD33R for 3.3Vcc and LM2931AD50R for 5.0V (100mA which is fine for my control MPUs and sensors) which can survive +/-60V 100ms transients, than it should be rather difficult kill this circuit even when noisy automotive battery were usedHowever, maybe I will use not CAN/VAN protocol with MCP2551, but custom one and those ICs itself only to provide reliable electric circuit in automotive environment.It depends if we have to interface existing CAn bus, but to do this we need detailed CAN/VAN messages specyfication which I don't have for the moment for Peugeot 206.If Op has such datasheets for his car in dala logging mode it shouldn't be too difficult to do this with decent scope to see what happends on CAN/VAN bus to be able debug MPU code

author: filssavi
author_rank: Frequent Contributor
timestamp: November 12, 2015, 07:35:27 am
content: HiI'm a EE in a italian FSAE team, and let me tell you the thing you want to abolutely GET RIGHT is imput protection, much more than performance, 12 bits are more than enough (20/30K € systems are typically 12 bit too), since past that the sensor's supply and EMI crap from ignition sistem will be big problems...Sample rate wise it depend's om bow many sensors you want per node, again each channel hasn't got to be that fast (you are dealing with mecanical time costants after all), more critical is to ave a low enough latency so that you can multiplex more channels on a single adcInput Protection, is indeed critical, the power 12V in must be bombproof, since has you will know mech engineers will at some point reverse the battery polarity and other good things like that, depending on your system you may have to worry about load dump, and that's a beast, depending on your needs you could use STM's RBO40 if your PSU subsystem can tollerate 40V in for some hundred's of ms, or else there is linear's LTC4366 which will clamp all you can trow at itInput signals will also have to be resilient, make sure connectors cant be possibly cpnnected wrong by someone that hasn't got any idea of what a connector is (mech engineers XD) or else you wil find sparkplug connected to adc input and wheel speed sensors connectet to ECU and so on...There will be hot plugging so account for that, and also you may want some input low pass filtering (say Ft at some tenth khzs) since (depending on where the sensor is on the car you may have HF (relatively) noise coupled in (eg. Spark pulse will couple capacitively to pretty much anything simce very fast dv/dt)

author: AustinEngy
author_rank: Regular Contributor
timestamp: November 12, 2015, 02:49:01 pm
content: I think that it would be beneficial for me to take baby steps in this design, since I seem way over my head in terms of general electrical concepts that I just haven't come across in my classes yet. First, I believe that it would be best to start by looking at the power input side of things, since that is sort of critical to the functionality of the board. Our car currently has 12V and 5V power blocks, which obviously won't do since the PIC uses 3.3V. For simplicity, it makes sense to me to just have a 12V input and some sort of circuitry that can convert this input voltage to 5V to drive some of the sensors and 3.3V for the IC's on board.My first inclination is to use a pair of voltage regulators along with the correct valued resistors and capacitors to get the correct, stable outputs. Figure 12 in this MC33269 datasheet is what I'm thinking:http://www.onsemi.com/pub_link/Collateral/MC33269-D.PDFAnother option I found was this TI TPS5438x IC that does the work of both voltage regulators in one chip, if I'm understanding things correctly.http://www.ti.com/lit/ds/symlink/tps54383.pdfThe only problem I see is that this thing is $5 a piece! Not a huge cost, but the electrical team budget is pretty limited at this point.I think that for simplicity's sake, I will try and use two separate voltage regulators. I will try uploading a schematic today to get some feedback. After I finalize this design, I will move on to designing the input protection/LPF stuff.

author: AustinEngy
author_rank: Regular Contributor
timestamp: November 12, 2015, 02:55:29 pm
content: Quote from: eneuro on November 12, 2015, 01:16:58 amI 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. When I started this project I familiarized myself with CAN stuff by using an Arduino with a CAN Bus shield and trying to hack into my Mk4 VW Jetta's CAN bus. Needless to say, it was an incredibly time consuming task that ended with me being able to lock and unlock the doors, and control all the windows. So I feel your pain as far as having to interpret the innumerable amount of messages along a modern automotive CAN bus!

author: LaserSteve
author_rank: Super Contributor
timestamp: November 12, 2015, 03:33:14 pm
content: Some advice:Based on a decade and a half of helping students, may I suggest that there is a strong social component to success in your adventure? I'm a university technician, I alternate between corporate and state contracts, depending on what's available.Right now I'm back in the academic environment.Go find the EE department's technician, or some one else who does support of research on your campus at the circuit board level. Have personal design review sessions with this person, or with a professor who has commercial experience. You will know you havethe right perrson, when you have to wade through piles of dead gear to get to them. The right person may be a Post-Doc or Grad student, as well.Then find some company in town, that designs or manufactures electronics for the automotive, transportation, military, or avionics markets and get a mentor. Cold calls work, but you will have to make many of them. Showing up in person to the main office often works better. Usually your department will have an internship office, and that person may have some leads.Why? One, this is an excellent learning experience. Two, it has many pitfalls, and odds are the MEs will beat up on the gEEk if he fails. Three, Practicing Engineers like to help ambitious future engineers and it will help you make connections to get a job. Four:Join local chapter of IEEE, not just the student chapter, and take drawings to the meetings. This way you have outside peer review.Automotive and Mil-Spec electronics are very similar, and your in a high EMP environment' with a safety of life aspect. You should not be alone when you attempt this. You just signed yourself on to a task that needs a high level of professionalism, ethics, and careful selection of connectors. ;-)This is as much about systems integration as it is about board design, and that skill set is very valuable.Fear not, of requesting books on automotive electronics, via interlibrary loan.Enjoy reading MIL-STD-454, then DOD-STD-2000 and MIL-STD-2000, as well as the SAE equivalents on connectors and connections.Make sure you have a professional crimping tool, not a five Dollar model.Test, test, and re-test. Beware of starter surges and load dump. Go to a junk yard, get a few ECM and ignition modules and tear them down. Don't try to run them, but study the construction. Frame ground is important, tell the MEs to ground bond any structures that may carry starter currents back to the batteries. You will see tribo-electric and electrostatic effects and noise from the tires.You may see long dropouts in the electrical power system.I have nothing to do with our team, other then a consult a few years ago over antenna radiation patterns from horribly undersized antennas. I had the good sense to run away from their wiring scheme.I do NOT mean to discourage you at all, because when I'm wearing my corporate hat, we look for folks with more then theoretical knowledge. Don't neglect your grades. Make sure they let you drive the car in tests. Be safe.Steve

author: AustinEngy
author_rank: Regular Contributor
timestamp: November 12, 2015, 05:44:32 pm
content: Thanks for the tips, Steve! I will try working on finding an experienced individual to bounce questions off in person.I drew up a quick schematic of what I'm thinking for a voltage converting circuit. My problems are calculating the Iadj to figure out the required values for R2 and R3, as well as the value for the Cadj capacitors. The datasheet for the voltage regulators recommended these caps to prevent ripple. Please help me out by critiquing this schematic!EDIT: The link to the schematic wasn't working in my first post here, so I've attached it.

author: eneuro
author_rank: Super Contributor
timestamp: November 12, 2015, 07:07:22 pm
content: Quote from: AustinEngy on November 12, 2015, 02:55:29 pmNice-this CAN bus communication was encrypted somehow or only uknown protocol and messages?I hope Peugeot do not encrypt this CAV/VAN bus data.Hopefully, I do not need modify and create new messages-idea is was for VAN bus communication between BSI and main display panel where I'm interested in vehicle speed and engine RPM for the moment.I've RPM sensor based on... hacking alternator three phase output using fast optocoupler, so I can calculate engine speed and look for something in VAN bus data which is proportional to this RPm values.I have no idea if I will be able hack this, but it will be fun to log some real time CAN/VAN bus data to PC, than write software to find patterns and maybe findout what I needBTW: Probably I will try to make experimental automotive PSU based on my concept, where plan is use three capacitors banks and charge from automotive 12v battery one capacitor bank, while second is connected to charge third caps bank which will be voltage regulator input.When charged capacitors bank will be fully charged, than those to capacitors banks connected to automotive 12v battery will be quickly exchanged, so discharged capsitors will be charged againm, while charged capsitors from first caps bank disconnected from automotive baterry and floating like.... classic battery charging third input caps...This way my MPU circuit will never see noisy automotive car battery 12V voltage and additionally MPU output pins can be optically insulated from car electrical system.I think it might work when 500V mosfets will be used to make this disconnected capacitors bank floating with MPU control circuit.When you find some expert in the field you might ask him if such approach could work. providing efficiency is not a concern since there is a lot of KW of car engine and we do not need to much input power for control MPU, log data , connect LCD, etcThis what we want is forget about bloody automotive noisy 12V car battery and I believe my approach should work, so whatever anyone says-I will check this because of I like this idea and it is quite cheap research projectI stick with this idea for soem time and this is the way I will go in my Peugeot 206 automotive project

author: ajb
author_rank: Super Contributor
timestamp: November 12, 2015, 07:21:53 pm
content: The optimal power design really depends on the sort of power you need. Linear regulators such as you've sketched may be fine, but for anything more than a few dozen mA, switching regulators start to make more sense for thermal and efficiency reasons. Switchers have the additional advantage that you can often arrange for a much higher input voltage range than you could with an LDO, which makes input protection much easier. If you need both 3.3V and 5V, then a 12V->5V switcher with a 5V->3.3V LDO may be a good solution. If you need a really clean 5V analog rail, you might want something like a 12V->7V switcher with a 5V LDO and some heavy filtering. It all depends.If you want to get to the meat of the project a little more quickly, you could go for an off-the-shelf DC-DC converter solution to start with. They'll cost a few dollars, but they'll allow you to get a board up and running a little more easily. You'll still want to add some input protection, of course.

author: AustinEngy
author_rank: Regular Contributor
timestamp: November 12, 2015, 08:44:27 pm
content: Quote from: eneuro on November 12, 2015, 07:07:22 pmIt wasn't encrypted at all. I used an example code from the Seeedstudios CAN shield that I bought and just logged all of the CAN messages during certain events and sorted them in excel. I graphed the data that looked promising and when I found something that corresponded to the event, I would perform another test or two to be sure. It is really easy to read the data, but a lot harder to inject your own data to control things.

author: AustinEngy
author_rank: Regular Contributor
timestamp: November 17, 2015, 01:40:28 am
content: Quick update, I've decided to tackle the the project as a few separate challenges. I've sort of split it up into these categories:12V to 5V and 3.3V rails with power protection/fusingSignal attenuation for 12V analog sensors to 5V analog inputs on MCUInterfacing the MCU, CAN Transceiver, and the above systems.I was able to get a copy of Altium so I will be putting the circuit together there. I got some ideas from some other EE students about the signal attenuation and a schematic I've come up with is attached to this post. The sensor is represented by the 3pin connector on the left, and the output of the circuit to the MCU is on the right. I'm still totally new to electronics design, so I'm not sure how I would determine the values for the capacitors throughout the circuit. (It was suggested to me that I should use capacitors wherever possible to get the best signal possible.) What do people think of this?Thanks!

author: ajb
author_rank: Super Contributor
timestamp: November 17, 2015, 03:34:26 am
content: You do want some capacitors, but you want to make sure you put them in the right spots. You'll need to add a decoupling cap or two between +5V and ground as close as possible to the op-amp. Do the same for every IC on your board, and if your MCU has multiple power pin pairs, you need caps for every VCC/Gnd pair. The exact number and values of caps you should use for decoupling depend on the operating frequency of the device, board layout, and other things, but generally 100nF is in the right ballpark for low-power, low-speed, stuff.The other caps you need to add are for filtering the input signals, and some bulk capacitance in your power supply section. Generally you're going to want to add low-pass filters to your inputs to attenuate noise at higher frequencies than you're trying to measure, without overly attenuating the frequencies you're interested in. R2+C3 and R1+C5 form low pass filters with cutoff frequencies at ~7.2kHz and ~1.6kHz, respectively. There are lots of filter topologies and calculators online that you can look at, but generally the arrangements you have are fine, but you'll need to decide on a cutoff frequency. This should be somewhat above the frequency you intend to sample, and ideally below the dominant noise frequencies in your system. Note that RC filters tend to have a relatively shallow rolloff, so if you have a lot of noise at a frequency very close to the frequencies you're interested in, you may need to use a different filter topology (or several filters) to get a steeper rolloff.Note that you also have the option of doing some filtering in firmware, but of course that means processing overhead. Something to think about and maybe experiment with.There are places where capacitors will not be terribly helpful. C1 and C2 may provide some low-pass filtering, but the cutoff frequency will depend on the impedance of the sensor that drives the input, so I'd just leave them off. Or maybe add a resistor in between the input and C1/C2 and use it as an additional filter stage.Finally, there are places where capacitors are downright bad, and C4 is in just such a place. Most op amps are not stable when driving a capacitive load, so C4 is only going to cause trouble. It won't even provide much filtering because the output of the op-amp is low impedance, so skip that one. (If you really need to drive a capacitive load, some op amps are specifically designed with that in mind, but with a jelly bean op amp, a cap on the output is asking for trouble.)A few additional notes:- The op amp must have rail-to-rail input and output to be able to use the entire 0-Vcc range. There are lots of options in 5V RRIO op amps these days, so don't bother trying to use anything too crusty.- Consider incorporating some solder jumpers or footprints for additional filter components on your PCB so that you can easily change the filtering if you find that your first approach ins't optimal. That can also make it easy to adjust your attenuation so you can configure different input channels for different sensor types.- Keep up the good work!- And don't forget the protection on the analog inputs!

author: AustinEngy
author_rank: Regular Contributor
timestamp: November 17, 2015, 02:04:40 pm
content: Thanks a lot for all the help! I'll respond with a couple quick questions.Quote from: ajb on November 17, 2015, 03:34:26 amSo I basically need to hook up an oscilloscope to the 12V source I would be using on the car and try to map out at what frequencies I'm getting noise? And then figure out how frequently I want the value of the sensor to change? If I'm correct in that assumption, the cutoff frequency would probably be in the low kilohertz range? The entire CAN bus will be transmitting data at 1Mbit/s, so from intuition I would assume that this would be about right. Also, Since I'm using a voltage divider to attenuate the 12v signal voltage and using the Op Amp as a buffer, would an active LPF provide me with the same effect? If so, I could theoretically cascade two of those pretty easily to get a sharper cutoff. Then again, I'm not super worried about it, since this is only the first version of this circuit and I just need it to work somewhat reliably.Quote from: ajb on November 17, 2015, 03:34:26 amAre you just saying that If the 12V signal doesn't actually range from 0 to 12V that the output won't go all the way from 0 to 5V? After looking up what an RRIO Op amp is, I'm assuming that you're just suggesting I use a component like this:http://www.ti.com/lit/ds/symlink/lmv710-n.pdfAm I right?Quote from: ajb on November 17, 2015, 03:34:26 amThat's a great idea about having those jumpers in there! It might even make sense to make one of them through hole for each input for ease of modification if we are trying to add more sensors with different requirements.And by input protection, are you talking about having some sort of diodes to prevent the voltage from getting too high? Or perhaps some sort of fuse to prevent excess current? I found a picture from Digikey that shows some basic input protection, and I'll put it at the bottom of the post, but I notice that I already have the LPF in there. It is then a matter of putting a resistor between the 12V rail and the input to the Op Amp, and adding diodes at the output of the Op Amp before the analog input to the MCU?Thanks again for your help and encouragement. This forum has been so amazingly helpful.

author: eneuro
author_rank: Super Contributor
timestamp: November 17, 2015, 05:27:22 pm
content: Quote from: AustinEngy on November 17, 2015, 01:40:28 amI've already orderedMCP2551 - Interface- Controller Area Network (CAN)to log data and try hack Peugeot 206 HDI CAN/VANNow, working on my concept of tricky PSU mentioned above, where MPU never will see automotive battery, but charged capacitor (or ultracapacitor) instead to avoid automotive systems eelctric noise crapI'm interested, how you will deal with conversion from automotive noisy 12V to 5V, than LDO to 3.3V in my case, since I'm using 3 axis accelerometer sensor and it has builtin 3.3 (KB33 ) 16Vin max at normal conditions, so I need 3.3Vcc MPU too, while I do not like mess with voltage shifting etc on internal I2C between MPU and local sensors

author: ajb
author_rank: Super Contributor
timestamp: November 18, 2015, 06:32:40 am
content: I'm not sure what the most prominent noise in a car's electrical system looks like, but I would guess you'd have ignition noise at something like [engine rpm]*[number of cylinders]/2, and then something at some multiple of alternator RPM. So yeah, I'd think that somewhere in the low kHz range would be a good guess. You'll also have transients from load dumps and things that may show up in analog signals, so you may want to do some additional filtering/sanity checking in the digital domain as well (if you are only using this for datalogging then you can of course do this as part of your post-processing/analysis rather than in real time).As far as op-amps, many (especially older designs) aren't capable of swinging their outputs all the way to one rail or the other--they may only get within a few volts due to the way the output stage is constructed. Some designs also have trouble if the input gets too close to one rail or the other, and in some cases applying an input signal too close to one rail will cause the output to slam all the way to the opposite rail. Some op amps may be specified to operate all the way down to the negative rail, bot not to the positive rail. So if you were to use, for example, a good old TL082 in your circuit, an input signal of 0V would give you an output of 5V. So if you want to read a 0-5V signal with a 5V single ended supply, and get a 0-5V signal out, your op-amp needs to have rail-to-rail inputs (so it can tolerate the full input range) and rail-to-rail outputs (so it can output that range to the ADC). Nowadays there are lots of options in RRIO parts that will happily operate on 5V or less, that hasn't always been the case. The one you linked should work, but there are probably cheaper options if you care to spend the time looking.Regarding protection, yes, basically, all your schematic is missing is some clamping diodes. You can do steering diodes to the supply rails like the image you provided from digikey shows, or you can use a TVS aka transorb diode to clamp the signal, or you can do both. The steering diodes may allow a very energetic transient to cause a disturbance in the supply voltage, but with sufficient input impedance should provide adequate protection against damage. At least one TVS on the +5V supply is still a good idea. In any case, the filtering and protection should go as close to the input connector as possible, and the diodes should be on the input side of the op amp, not the output.

author: eneuro
author_rank: Super Contributor
timestamp: November 18, 2015, 04:23:34 pm
content: Quote from: ajb on November 18, 2015, 06:32:40 amImagine turning off different DC/BLDC motors present in cars to lock/unlock doors, etc, and voltage spikes on car battery-the worse battery (higher internal resistance) the higher voltage transient spikesI'm workin also in my project on esimating engine RPM based on alternator based voltage peak detector, so those false high voltage transients might ruin my attempt to detect alternator RPM and link it to engine RPM, so probably DSP signal processing and software analysis of car battery voltage let me make decent software filter to skip this electric noise crap preent on car battery terminals

author: Niklas
author_rank: Frequent Contributor
timestamp: November 18, 2015, 05:16:49 pm
content: I am quite sure that the switched capacitor concept is going to work:1. Switch noise from the charging of the empty capacitor. Either the capacitors must be very large or be switched very often.2. MOSFETs have internal capacitances that can couple high frequency noisePassive components (R, L and C) in combination with transient suppression devices is an easier way to go.

author: electrolust
author_rank: Unknown
timestamp: November 19, 2015, 09:48:35 am
content: Quote from: AustinEngy on November 12, 2015, 02:55:29 pmThe 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.

author: AustinEngy
author_rank: Regular Contributor
timestamp: November 19, 2015, 03:08:53 pm
content: Quote from: electrolust on November 19, 2015, 09:48:35 amYou'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!

author: AustinEngy
author_rank: Regular Contributor
timestamp: November 21, 2015, 12:01:18 am
content: 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.

author: RR
author_rank: Contributor
timestamp: November 21, 2015, 06:30:25 pm
content: 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.

author: AustinEngy
author_rank: Regular Contributor
timestamp: November 21, 2015, 08:06:47 pm
content: Quote from: RR on November 21, 2015, 06:30:25 pmI'm pretty sure I calculated that right to give a cutoff of 1.25kHz for both filters...Quote from: RR on November 21, 2015, 06:30:25 pmGood point! I will throw one in there.Quote from: RR on November 21, 2015, 06:30:25 pmI'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?Quote from: RR on November 21, 2015, 06:30:25 pmThanks 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!!

author: max_torque
author_rank: Super Contributor
timestamp: November 22, 2015, 12:12:50 am
content: 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.

author: eneuro
author_rank: Super Contributor
timestamp: November 22, 2015, 08:37:48 am
content: Quote from: max_torque on November 22, 2015, 12:12:50 amIt depends on ADC clock speed setAt 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

author: AustinEngy
author_rank: Regular Contributor
timestamp: November 25, 2015, 07:48:44 pm
content: 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 TXRequest to Sendpins? 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.

author: AustinEngy
author_rank: Regular Contributor
timestamp: November 25, 2015, 08:27:57 pm
content: 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.

author: max_torque
author_rank: Super Contributor
timestamp: November 25, 2015, 10:17:33 pm
content: 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!!

author: max_torque
author_rank: Super Contributor
timestamp: November 25, 2015, 10:20:55 pm
content: 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 controller2) 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

author: eneuro
author_rank: Super Contributor
timestamp: November 25, 2015, 10:36:43 pm
content: Quote from: AustinEngy on November 25, 2015, 08:27:57 pmProbably good idea according toMCP2561 High-Speed CAN TransceiverdatasheetQuoteI 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

author: AustinEngy
author_rank: Regular Contributor
timestamp: November 26, 2015, 04:27:17 am
content: Quote from: max_torque on November 25, 2015, 10:20:55 pmAre you talking about putting a pullup on the SS pin for the SPI between the MCU and Controller?

author: max_torque
author_rank: Super Contributor
timestamp: November 26, 2015, 08:53:14 pm
content: Quote from: AustinEngy on November 26, 2015, 04:27:17 amYes. 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!

author: AustinEngy
author_rank: Regular Contributor
timestamp: November 27, 2015, 04:59:02 am
content: 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.

author: RR
author_rank: Contributor
timestamp: November 27, 2015, 09:40:36 am
content: -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 weakmaybe use more labels in schematic so you dont have that much crossing lines in schematic but thats just my personal opinion.

author: eneuro
author_rank: Super Contributor
timestamp: November 27, 2015, 01:37:42 pm
content: Quote from: RR on November 27, 2015, 09:40:36 amOn 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 conditionsBTW: 100k is more than internal pull up resistors in those AVR I/O circuit I guess...

author: max_torque
author_rank: Super Contributor
timestamp: November 27, 2015, 02:14:06 pm
content: 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)

author: AustinEngy
author_rank: Regular Contributor
timestamp: December 08, 2015, 02:14:56 am
content: 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!

author: AustinEngy
author_rank: Regular Contributor
timestamp: December 08, 2015, 02:27:39 am
content: Quote from: RR on November 27, 2015, 09:40:36 amI 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.pdfSo 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.

author: AustinEngy
author_rank: Regular Contributor
timestamp: December 10, 2015, 07:38:35 pm
content: 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.

author: ajb
author_rank: Super Contributor
timestamp: December 10, 2015, 08:22:44 pm
content: 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.

author: AustinEngy
author_rank: Regular Contributor
timestamp: December 10, 2015, 08:29:28 pm
content: 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.

author: RobertBG
author_rank: Regular Contributor
timestamp: December 11, 2015, 03:13:45 am
content: I had a amazing time doing Formula SAEwe 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 timeLastly 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.

author: AustinEngy
author_rank: Regular Contributor
timestamp: December 16, 2015, 02:11:17 am
content: 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 anExhibitionschematic 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.

author: ajb
author_rank: Super Contributor
timestamp: December 16, 2015, 03:52:34 am
content: Bulk capacitance goes at the input, decoupling goes next to ICs. The decoupling is there to absorb transient current demand of ICs (especially digital) during operation, the bulk capacitance is to supply larger/longer term demands, so the capacitance is much larger. Since your board doesn't supply an large loads, it doesn't need to be huge. Maybe 47uF electrolytic? Make sure the voltage rating is high, I'd probably go for ~35V. A fuse and a unipolar ~20V TVS diode would be a good idea as well (fuse, then TVS from Vin to Gnd, then electrolytic cap).But it looks good on the whole. A few minor points:- On the 12V digital input, move D45 to the +5V rail. As it is, that diode won't start conducting until the MCU pin reaches 12V, and by then it's too late.- Unless you plan to use debugWire to debug the AVR, a cap between reset and gnd is cheap insurance against spurious resets. If you plan to use debugWire during development, you can always fit the cap later.- Since you've got spare pins on the MCU, I'd recommend freeing up PD0 and PD1 (UART RX and TX) and routing them to a header--for convenience, you could use the "standard" Arduino 6 pin layout so you can plug one of those ubiquitous FTDI boards straight in. A spare UART is invaluable during debugging.- Use a couple of other spare pins to drive some LEDs. These are also invaluable for debugging and having something to indicate status is a huge timesaver when you have to troubleshoot the system in the field. So is a reset switch, for that matter.- You've got a pullup on the CAN transceiver's CS pin which is good, but personally I'd probably still put a resistor between it's SO pin and the MISO network, just in case it doesn't completely behave itself. It's cheaper and easier than blowing up the AVR.As far as making your Altium schematics look good, as far as I'm concerned that starts with throwing away the default library symbols and starting from scratch so that everything has a consistent graphical style. What that graphical style ought to look like, of course, is potential flamebaitMore practically, since you have a bunch of identical inputs, this is a great chance to learn about multi-channel design and rooms. Look those up in the docs, they're pretty great if a bit counterintuitive at times.Also, beware of 4-way junctions, such as you have between your clamping diodes. Altium historically has not always handled them well, and I've had them disappear on me. 3-way junctions are safer, if a little more cumbersome to lay out at times.

author: AustinEngy
author_rank: Regular Contributor
timestamp: December 18, 2015, 03:39:31 pm
content: I just watched the new EEVBlog #831 and after looking at my ATmega32A datasheet realize that my MCU has clamping diodes! I hadn't realized this before, so now I'm wondering if I can remove the protection diodes I have in my input filtering circuits? Honestly, I could probably reduce them down to just an RC filter and a buffer to save board space and component costs. Although the environment will be noisy, I feel that one RC filter is enough, but I would need to keep the OpAmp buffer to have a low impedance at the input pin. Any thoughts on this? I think what I really need to do is just breadboard everything (I'll be getting to that next week) to figure out what I need or don't need.

author: AustinEngy
author_rank: Regular Contributor
timestamp: January 05, 2016, 04:40:47 am
content: It's been a while since I've updated everyone, so here we go! I looked into multisheet design as suggested previously and am very pleased with my results from that technique. I'll attach a picture of my parent sheet. I built up a basic breadboard version of my circuit and after a long few days of digging for a programming error, discovered that the TOSC1 and TOSC2 pins are NOT oscillator output pins as I had mistakenly convinced myself. I hooked up the CAN Controller OSC pins directly to my 16MHz crystal and I was successfully sending and receiving messages over CAN! So I definitely learned my lesson about checking and double checking hardware connections first!I'll throw up a picture of my breadboards, I know they're super messy. I've never done a big project like this, so i underestimated how much room I would have needed to run wires between the ICs. You can see my cheapo Siglent scope and Fluke DMM in the background, too!I've had a few worries about this project recently, mainly centering around the ATmega32's 10 bit ADC's. When I looked at the MoTeC product that is similar to my project (they call it a VIM), that module uses 12 and15bit ADC's! I'm worried the resolution won't be good enough for data collection. However, since this is the first revision, I'm don't think I'm going to go back and choose a different MCU.My next step is to prototype my input protection circuits and verify that I can collect the analog values, convert them to CAN messages and transmit them in a timely manner. Simultaneously, I'm also working on doing PCB design in Altium. It feels like a totally different monster!I haven't changed many things in my schematic, save for the MCP2515 oscillator inputs, MCP2515 RESET pin circuitry (the datasheet recommended circuitry that would hold the reset pin low for a short time after the power is turned on), 12V reverse protection circuitry, adding a single clamping diode to each analog and digital inputs, adding some diagnostics LED's and an FTDI header.Special thanks to ajb for a lot of these suggested changesFinally, I found a really great document detailing protection circuits specifically in automotive environments. It even goes into detail about designing traces strategically, since apparently you can end up with some serious parasitic inductance/capacitance if you don't make them correctly! Very interesting read:http://www.st.com/web/en/resource/technical/document/application_note/CD00181783.pdfIf anyone has any PCB design suggestions or changes to make to my schematic, I'd appreciate it.

author: AustinEngy
author_rank: Regular Contributor
timestamp: January 06, 2016, 01:46:21 am
content: Could anyone clarify to me how I go about dealing with the wiring, busses and net names going between my d sub connector on the left and the repeated input protection sheets? I feel like I'm doing it wrong, but everything compiles until I try putting everything into a PCB file. The filtering doesn't seem to actually get connected to the big connector. Does anyone notice any problems with how I've done it?Thanks!

author: AustinEngy
author_rank: Regular Contributor
timestamp: January 09, 2016, 08:19:17 pm
content: I've done nothing for the last few days outside of this project and I've made some pretty good progress in the PCB design. I'm pretty sure that my schematic will work just fine, and I've decided to not worry about doing programming at this point since that's not my area of expertise. Here's a quick 3D snapshot of my board. Anyone have further suggestions? I haven't routed anything yet because I'm still not totally happy with the placement of everything. Currently, I'm considering swapping the power protection circuit in the upper left for the test LED's on the bottom right.The current dimensions are 100mm by 150mm, does this seem like a nice enough size to be able to be compatible with standard boxes and enclosures?

author: AlexDavidson
author_rank: Contributor
timestamp: January 09, 2016, 10:17:24 pm
content: It's usually better to start with the enclosure dimensions and size the board to fit. You will probably need some mounting holes on the board...

author: AustinEngy
author_rank: Regular Contributor
timestamp: January 10, 2016, 02:27:17 am
content: Quote from: AlexDavidson on January 09, 2016, 10:17:24 pmA good point. I wanted to have a rough estimate as to how much surface area I would need to fit all my components. I haven't routed anything yet. So thinking about it now it does make sense to find a good enclosure before I continue to place things.

author: ajb
author_rank: Super Contributor
timestamp: January 10, 2016, 03:53:05 am
content: You definitely want to pick out an enclosure before you start really routing the board in earnest, but roughly placing the parts as you've done to get an idea of the board size requirements is a good idea. Since you've only got one main IO connector and a handful of LEDs on the board, an extruded aluminum box like the Hammond 1455 series could be a good fit. End panels can be laser cut or CNCed (or even cut by hand) from flat plastic/aluminum pretty easily, or you can even use a PCB as an end panel.

author: AustinEngy
author_rank: Regular Contributor
timestamp: January 10, 2016, 04:16:38 am
content: Quote from: ajb on January 10, 2016, 03:53:05 amAs you can see from how I've laid it out, that's exactly the kind of enclosure I was thinking of. Something IP65 rated would be great, and I'm thinking of mounting them so that one side will have the CAN interface that will head to the datalogger in the center of the car, and all of the sensor IO on the other side so that I can minimize wiring and make everything simple. The only thing I worry about with extruded enclosures like the 1455 are the fact that they don't have ways to actually secure the board in place with screws. That means that I'm bound by the tolerances of the box and the board as to how much the board might slide around inside. Maybe I'm just being paranoid about this?

author: ajb
author_rank: Super Contributor
timestamp: January 10, 2016, 05:28:54 am
content: Engineering (of all sorts!) would be way easier if we never had to worry about tolerances! Sadly, we do, so better get used to itYou'll need to account for tolerances when you fabricate the end panels anyway, and if you leave the board ~1mm under the nominal dimensions of the enclosure you should be fine. The Hammond 1455s are usually tad on the small side, by a fraction of a mm IME. If you're really worried about the board bouncing around, leave it ~2mm short in the length dimension and put some foam tape on the inside of the end plates that will squish against the board.If you want the whole thing to actually be IP65, connectors, indicators, and switches are going to be the main challenge. Building an IP65 box is easy, maintaining IP65 after you've poked a bunch of holes in it is a little trickier. Selection of PC-mount IP65 connectors is relatively limited, so in some cases you may be forced to pigtail a panel-mount connector off of the board.

author: AustinEngy
author_rank: Regular Contributor
timestamp: January 10, 2016, 07:03:36 am
content: Quote from: ajb on January 10, 2016, 05:28:54 amWell, for this application, the worst scenario I can think of would be if we were running the car in heavy rain without any body panels on. In that case, I think it would probably be fine to just deal with the slight gaps likely left from board mount components. Your point about using pigtails is good, I was thinking of using something like this:https://www.phoenixcontact.com/online/portal/us?uri=pxc-oc-itemdetail:pid=1424234&library=usen&tab=1to get the 12V, GND, CAN HI and LOW around the car. Since I'm using a pretty standard 26 pin d sub connector for my inputs, I'm certain I can find a good rated component for that. And I think that is really all of my interfaces in the car. All the other headers are going to be for diagnostics/programming.

author: max_torque
author_rank: Super Contributor
timestamp: January 10, 2016, 01:53:14 pm
content: as someone who designs and develops electronic products for Automotive, Motorsport and Military customers, i can tell you that enclosures and connectors are the bane of my life!The following are my suggestions:1) despite the cost, only use automotive rated connectors. Anything else is NOT a long term solution. You don't have to go full MIL spec, as there are plenty of plastic rated connector systems. In ALL cases, make sure you use a direct to pcb connector system to avoid having to do interboard point to point wiring (JAE do a range of low cost connectors that are suitable)2) In most cases, a fully potted system is the only way to GUARANTEE environmental protection3) try to use off the shelf enclosures with integral connectors. Deutsch, Cinch and the like all do off the shelf enclousures designed for automotive and industrial purposes, and these make ones life a LOT easier. ie:https://www.google.co.uk/search?q=deutsch+enclosure&num=30&source=lnms&tbm=isch&sa=X&ved=0ahUKEwim4PuwsZ_KAhVFTBQKHchyAK0Q_AUICCgC&biw=1368&bih=7864) if you want the smallest possible form factor, you'll HAVE to machine your own enclosure! For critical low volume projects, it's now just about as cheap to CNC an enclosure from solid as it is to buy one!!5) if you are potting your devices, break the programming / debug pins out to the header (or a seperate one) even if you use CAN bootloader etc

author: AustinEngy
author_rank: Regular Contributor
timestamp: January 10, 2016, 06:09:39 pm
content: Quote from: max_torque link=topic=58200.msg839421#msg839421 date=I had noticed the Deutsch enclosures, like this one:https://www.phoenixcontact.com/online/portal/us?uri=pxc-oc-itemdetail:pid=1424234&library=usen&tab=1We use Deutsch connectors throughout our car, so it might make sense to pursue this as an option.We don't absolutely need to have guaranteed complete water protection, but it wouldn't hurt at all. I think I'll investigate Deutsch boxes further. I'd still like to use Devicenet connectors for the CAN signals. Hopefully I can implement some sort of connector into whatever enclosure I pick out.Any other tips for this design? Your experience seems really valuable for this project!

author: AustinEngy
author_rank: Regular Contributor
timestamp: January 11, 2016, 07:19:35 pm
content: I'm back again, I've spend probably 15 hours in the last day working on redoing the board to fit within the Deutsch enclosure! I've gotta say, it didn't look like I'd be able to fit all of my components in that space and still be able to hand solder everything, but enough persistence and I was able to do it! I also went through some of my footprints and realized that I could probably size a few things down, I.E. my LED resistors has 2010 footprints, I swapped those out for 0603's. I was using the basic altium polarized cap footprint, that was HUGE. I measured my own 47uF caps and made my own footprint for it. I could probably size things down further if I want, but I think this is a good resting point. The datasheet for the enclosure:http://www.farnell.com/cad/1635140.pdfhas a keepout zone that I indicated in my design with the DeutchConnectors room, around the edge of the board.As far as routing goes, I just did auto route for the whole board, and I'm sure this isn't recommended, but I wanted to get a sense for how the program would do it. Are there any glaring issues with the traces as they are? I imagine that the traces in the power protection circuitry should be a little more beefy.With the keepout zone around the edge, should I also make an effort to keep traces and via out of that region? The case is plastic, so I'm not too worried about the mask getting scraped off and having things short out.

author: max_torque
author_rank: Super Contributor
timestamp: January 11, 2016, 08:14:37 pm
content: Just so you know what's possible, with just a 2 layer pcb, i have the following in the Deutsch enclosure:5A wide input range (12-50V) DC:DC convertor5V 1A linear regulatorPTC fuse, reverse battery connection protection and Load Dump Protection2x 5A Smart Output Power switchLots of smoothing / ride through capacitanceMega644 and 16Mhz Xtal oscilator2x CAN buses uses Mcp2515/2151FTDI USB-> serial bridge1 H bridge driver (5A peak, 3A continuous)2x 1A Differential line driversSPI temperature sensor IC6 analogue inputs (fully protected)3 digital inputs (fully protected)Generally nothing smaller than an 0805 resistor (although a some of the input protection is via 0603 ARC resistor arrays)One great advantage is that they also do a "see through" enclosure, so dev units have a load of leds on the pcb, indicating CAN status (for both buses) Serial data flow, leds for various power line states, and a MIL. These are not populated for proddy devices, but make basic fault finding a lot easier during development!

author: AustinEngy
author_rank: Regular Contributor
timestamp: January 11, 2016, 09:49:55 pm
content: Those are really impressive looking!I just don't understand how you manage to fit that much stuff on your board! I had to remove all of my debugging LED's to fit the small profile of this enclosure, but I figured since I have my FTDI header I could just use serial output in my programming to debug things.Are my room arrangements in order? Like, do their positions make sense?Are there any quick suggestions you could make to me so I can fit more things in?I guess I could reduce the footprint of all of my SMB diodes by making an SMA footprint and substituting that in... Darned Altium doesn't have SMA in the default libraries. Those SMB diodes seem to be taking up a lot of space.

author: ajb
author_rank: Super Contributor
timestamp: January 11, 2016, 11:25:02 pm
content: Are you doing TVS diodes instead of clamping to the rails? I only see what looks like one diode per channel.Optimizing placement of components will be a big help in tightening up a layout. The nice thing about doing multi-channel with rooms in Altium is you can take the time to get one instance nicely placed and laid out and then apply the same placement and layout to all of the other identical channels. Take a look at the ridiculous spaghetti the autorouter did on your LEDs. That's the kind of thing that a human designer would look at and say 'gee, I could really simplify the layout if I move this resistor to there and. . .' whereas the autorouter just brute force figures it out. If you really want to maximize density without sacrificing signal quality you'll need to be fairly hands on with the routing.

author: AustinEngy
author_rank: Regular Contributor
timestamp: January 12, 2016, 12:43:39 am
content: Quote from: ajb on January 11, 2016, 11:25:02 pmThat's correct. I was looking at a document about designing input protection circuitry for automotive applications:http://www.st.com/web/en/resource/technical/document/application_note/CD00181783.pdfAnd they suggested just using aTransildiode between the signal and ground, as opposed to using clamping diodes like the diodes already contained within the Mega32. I figured that would save me some space.Quote from: ajb on January 11, 2016, 11:25:02 pmI'll consider trying it by hand sometime soon. I think it's pretty clear form the autoroute that it shouldn't be too hard to wire everything up with the component spacing as it is.

author: max_torque
author_rank: Super Contributor
timestamp: January 12, 2016, 08:01:18 am
content: Take a look at the multi element diode arrays intended for line protection, which package lots of protection devices into one package. They are much more expensive than single descrete diodes, but for low volume stuff, the extra cost is negligible compared to the space and build time you save.

author: AustinEngy
author_rank: Regular Contributor
timestamp: January 16, 2016, 02:32:46 am
content: Some updates:Our team is going to be sponsored by Advanced Circuits for all of our team's PCB needs, so props to them for making my budget much easier to work with!I've rearranged some components, added an SP720 input protection package (This really saves me space!) and hand routed everything. It's definitely messy, but way better than the autorouted version I'd had before. I ran a DRC and it found no errors, but I will be sending it off to AC and they will run a DRC for their equipment (I wasn't given specifications for what they require.) This board seemed quite difficult to arrange components on because all of the inputs/outputs are on one side of the board, so the density was lacking on the far end.The next step is to get this thing ready for some prototype boards. Once I get those and all of my components, I'll fire it up and test it out. Updates will continue!

author: AustinEngy
author_rank: Regular Contributor
timestamp: February 12, 2016, 01:46:00 am
content: Good news, everyone!After going back and forth with Advanced Circuits trying to figure out why my board outline file was looking all messed up, I figured out it was that one line had endpoints that were specified by three integers ahead of the decimal point (101.6mm) and the output was simply truncating the hundreds place. About a week later, my boards showed up and I couldn't have been more excited. It's really something special to see something you've poured lots and lots of time in to finally fabricated and in your hands.The next step is to start soldering on components and test things out. I'm waiting on our order to get approved, but I will continue to update here as I progress. Let me know what you all think.Again, thanks to AC for supplying our team with these boards free of charge!

author: AustinEngy
author_rank: Regular Contributor
timestamp: February 19, 2016, 05:54:21 pm
content: So I've found a few problems with my layout, the first being that my hole diameter for the interface with the Deutch headers is the exact width of the pins themselvesI'm probably going to get out a dremel and try and bring the pin size down. Another is that my RECOM 12V to 5V converter was negligently inserted wrong in the schematic, (I.E., the Vin was connected to 5V and the Vout was connected to 12V. So, I'll simply need to flip the component 180 degrees, but it will come really close to contacting the TVS and Schottky diodes. Other than that, I think it is all good to go.I tried hooking up my Pocket AVR programmer to the SPI 2x3 header on my board, and didn't see my Power LED come on at all. I tried powering the LED directly from my power supply (bad idea) and magic smoke was released with a nice flash from that LED.That's where I'm at now.

author: AustinEngy
author_rank: Regular Contributor
timestamp: April 26, 2016, 02:26:19 am
content: Well, the car is finally together and I've wired up my PCB with a single Honeywell mlh500psb06a brake pressure sensor. I'm having a very weird issue, which is similar to something I was seeing when I was initially testing the boards. Previously, if I had left an input pin floating, the output would slowly rise without stopping. Now, I'm having the same issue but the input pin isn't floating. I have a capture from the datalogger software showing the problem. Has anyone encountered this issue with boards doing analog reads?When I turn the car off and on again, the output reads nicely at zero and continues to do so until I press on the brake pedal, at which point the output begins to rise linearly.

author: max_torque
author_rank: Super Contributor
timestamp: April 26, 2016, 12:29:17 pm
content: I assume you are measuring the output voltage of the sensor with the ADC on the microcontroller? If so, it looks like the ADC ref voltage is not stable. Discharging the ref voltage every time the ADC is read, and hence resulting in a reasonably linear increase in ADC counts vs time??

author: ajb
author_rank: Super Contributor
timestamp: April 26, 2016, 01:56:37 pm
content: Have you properly selected/enabled the reference when configuring the ADC?A good first step is to check whether or not the ADC readings match reality. If I'm reading your graph right, the rise happens over 20 seconds, so a multimeter at the brake sensor output and then at your ADC input will quickly isolate the problem to the sensor, the on-board filters, or the ADC/firmware. If the signal looks right at the ADC input, a good next step might be to implement a bare-bones firmware that does nothing but continuously read the ADC and spit the value out of the serial port.

author: AustinEngy
author_rank: Regular Contributor
timestamp: April 26, 2016, 08:16:11 pm
content: I will try to isolate the problem this evening. I found some information that might be helpful and seems to make sense.http://digital.ni.com/public.nsf/websearch/4E9B8B3F8FD3A31B862562B5004EA1D9?OpenDocumentAt the moment, I only have one analog sensor hooked up, so there are 5 floating ADC pins that are being read. The article says that charge can be introduced when a multiplexer switches states leading to a float to rail. Since in my program it samples each ADC pin with filtering circuitry attached (If you look at board layouts, they're all of the 5V analog signals). I'm going to try modifying the program so that it is only taking analog voltage readings from the pin that has the sensor connected to it to see if that will remedy the problem.

author: AustinEngy
author_rank: Regular Contributor
timestamp: April 26, 2016, 09:33:23 pm
content: I realized that I forgot to throw a picture of the assembled board up! Just for kicks, here it is:

author: AustinEngy
author_rank: Regular Contributor
timestamp: April 27, 2016, 01:47:56 am
content: Update!It looks like everything from the software side is okay, I tested the voltages and it appears that the voltage at the output of my RRIO op amp reflects the digital output seen in my datalogging software. When I look closer at the digital oscilloscope, it almost seems like there's interference. It almost looks like a CAN message, but I think it's just a coincidence. I'll attach the new images I took of the problem. I'm wondering if having the op amp so close to the crystal is causing some sort of problem, or if the routing is poor, or whatever. I will try switching to the 5VA3 input and see if the issue changes at all.

author: max_torque
author_rank: Super Contributor
timestamp: April 27, 2016, 06:28:20 pm
content: That "interference" looks awfully like an ADC with low resolution having it's input slowly (ie voltage rise < (resolution / samples)) swept across a bit descretisation boundary, with about 10% white noise on top of the signal (noise Vpkp = 1~0% of resolution)!I.E. at first, only a few of the noise peaks push the ADC up to the "next" bit, then as the mean signal level rises, the the white noise results in more and more of the noise peaks being high enough to reach the next bit, eventually, even the mean is about the next bit! As a result you get a "duty cycle" effect on the output bit level (and more advanced readers will spot the ability for some over-sampling theorem here!)The effectively resolution of your system is quite clear to see in the data plot, at a little more than 2 Psi if I've read your graph axis correctly.You need to measure analogue voltages on your board, with a meter or scope. Have you ended up integrating the input signal of something silly like that, instead of purely buffering it??

author: AustinEngy
author_rank: Regular Contributor
timestamp: April 27, 2016, 09:52:33 pm
content: Quote from: max_torque on April 27, 2016, 06:28:20 pmLast night I scoped out the board and found that the output on my op amp buffers had risen in value to about what was being shown on the datalogger while the non-inverting pin on the op amps showed the correct value of the sensor. I was thinking that since there is effectively zero output resistance on the analog input pin due to the buffer, there might have been charge injection because my program was sampling most of the other ADC pins. I reprogrammed it so that it would only read the value on the input pin actually connected to the sensor.It all seems to be working properly now. I worry that adding another sensor and switching the ADC multiplexer will cause the same problems with charge injection. But, I'll get to that bridge when I cross it.

author: max_torque
author_rank: Super Contributor
timestamp: April 28, 2016, 07:09:33 pm
content: Are you sure you amplifier circuit(s) provide a suitable path for the amplifiers bias currents to escape? Op-amps with outputs that chase off to their rails often indicates a mis-matched (or completely un-handled) input impedance issue!

author: AustinEngy
author_rank: Regular Contributor
timestamp: April 30, 2016, 04:51:48 pm
content: Quote from: max_torque on April 28, 2016, 07:09:33 pmI'll throw in the filter circuit as I have it on my boards. I didn't know that input impedance really mattered with regard to Op amps because they already have a virtually infinite input impedance? I was wondering if adding a resistor from the output to ground would be necessary to allow the output current to go somewhere, but when I switched the program to only sample at the one input actually connected to a sensor it all seemed to work find and didn't drift at all.

author: max_torque
author_rank: Super Contributor
timestamp: May 02, 2016, 10:27:19 am
content: Whilst in theory, a perfect op-amp has infinite input impedance, zero output impedance, and no leakage currents or offset voltages, in practice, we can't make such a device (we can get close, but it starts to get complex/expensive) Practical op-amps have a lot of subtle parameters that can vary significantly between different types (architectures) and brands of op-amps.I'd suggest spending half an hour watching some of Daves previous videos on op-amps:EP:600EP:479