PCB Designs

[Ian Brech]

Attached is a revised version of the LED strip control board. There are still resistor and capacitor values that may need to be changed.

[luke.renaud]

This board controls actuation of stepper motors and pneumatics. Libraries we've created are attached.

[raygunn13]

PCB for thruster feedback.

[luke.renaud]

Attached is the current list of parts we've thus far selected for use in our PCBs. Note this is NOT A BOM! Simply a list of preferred parts with costs and digikey part numbers.

[Korey Holmstrom]

Luke, should your UART header have a GND?  Also I think the I2C needs a 3V3 and GND in the header. It looks like your image got cut off, wasn't sure if you split them out somewhere else or what.

[luke.renaud]

Attached is a new copy of the parts database. This includes most of the desecrate IC's and parts we're looking to use, as well as a collection of capacitors and resistors for our designs.

I'm still waiting on Nate to pull the Molex headers from Digi-key to fill in that part of the table. I'm going to request a brief design review tomorrow at lunch with those available to look over current PCB schematics as they stand, and ensure that we aren't missing anything yet. I'd like to get the switching board setup.

Tomorrow at Lunch I'd like to speak with anyone available about a few design constraints and decisions that will be determined by our board layout that will affect overall sub performance and operation limits. Tomorrow evening (i.e. 6 to 6:30) I'd like to meet with Nate, Ian, and possibly James or Korey to get the top layer of the PCBs schematics finished. We'll start our part annotations, with the goal of having full annotation done by Friday evening.

NOTE: I just realized we still need to select reed switches (and the parts for the switching board). This will need to be added as well, we'll have to talk with the MechE's about a few possible selections for them.

-Luke

[raygunn13]

Here's the header info. I have so far. Anything else? 

[Ian Brech]

Didn't we want mainly vertical connectors? From what I'm seeing, all of these are right angle ones.

[Ian Brech]

So apparently I didn't check the optoisolators thoroughly enough. The IXYS CPC5001G is a dual optoisolator in an 8-pin DIP, verses the Everlight 6N137S which is a single optoisolator in an 8 pin DIP. So here are the benefits of each:

6N137S: 10Mbs, $0.799 ea, 1 optoisolator per 8 pin DIP

CPC5001G: 5Mbs, $3.25 ea., 2 optoisolators per 8 pin DIP, does not appear to invert signal

If I'm looking at these datasheets right, the CPC5001G would mean that we do not need the inverter chip (it's $0.68, who cares?) but also means that we would be taking up less area on the board (4 less 8-pin DIPs and 1 less 20 pin DIP). We'd need 8 extra pull-up resistors than with the 6N137S, so would changing it really save us any board space is the question. Of course 2 resistor busses has to be less space than 5 DIPs...

If someone else wants to share their thoughts on this, I won't be looking into it more until tomorrow afternoon.

[luke.renaud]

Just a quick note, the more expensive chip does invert as far as I can tell. Personally I'd favor the more expensive chip, as it is minimizes complexity in our design and should dramatically ease the layout of the circuit. It's about twice the cost, but the ease of layout and the help in assuring that we can produce a board that will actually fit within our desired footprint makes it worth it in my mind.

[Ian Brech]

I'm definitely liking the more expensive optoisolator over the cheaper one. Would you mind clarifying what you think it does as far as inverting goes? What I'm reading and seeing is that it's a non-inverting optoisolator, so we would not need the inverter IC.

[luke.renaud]

I wasn't sure, but the first line in the data sheet description says "non-inverting" someplace.

[Ian Brech]

Here is the current design of the Primary PCB. I have left the 6N137 optoisolators and the inverter chip on a separate page for now, in case we don't want to go with the dual optoisolators for some reason. If anyone gets a chance to review this, I can make changes and start on the actual PCB layout.

[luke.renaud]

Looks good from here, I am somewhat tired though. The only remark I have, was didn't we decide we might need two 3.3v linear regulators for the FTDI chip. We can review that statement tomorrow, but I thought that might have been something we had to consider.

Other than that I've got a draft 1 layout of the actuation board (still nothing for the lockout circuit however). I have a few more parts to get onto the parts database, but I've added the extra smaller capacitors we need.

Nate, can I get the updated header information you had the other night? That just hasn't been sent my way yet.

Finally, I've added a secondary repo to our github account for use with the PCB layouts. The master branch currently just has our libraries (as well as some other ones from Sparkfun and Element14), and a copy of the manufacturing DRU's and CAMs. My current revision is under the branch renaud. For this repo, I'd like to request that pulls back to the master happen when we're ready to order a board. Other than that please work in your own branch.

https://github.com/PalouseRobosub/pcbs/

[raygunn13]

Here's my updated header sheet. Look it over. Still need a crimper for the K-connectors. We already have one for the Sherlock series.

[luke.renaud]

You forgot prices again, and the headers for the KK line of connecters were wrong. None the less, here is the updated sheet with the corrected parts. The crimper is now included as well. It is $350.

We'll need to select a fuse holder for the battery tube, as well as the Thompson power pole parts. Those might be worth an alternative order from Mauser, they've been cheaper there in the past.

I've put the latch out circuit PCB up on the github. It's worth noting that this time I was able to find a small relay that could handle our current and voltage without a 24V step up driver after all. It draws 100mA in the main coil, so we'll need our power up reed switch to handle something like 200mA, but that is not to tall of an order. We'll need to decide the best way to mount the relay (as it's a thru hole device but dumping up to 45A through a 1oz copper board without support is probably asking for trouble. We might be able to get away by using a stop region on the PCB to expose the copper then putting a layer of solder down on top to give us better conductivity. We'll need to come up with a way to connect the power-pole wires to it as well.

The relay in question is here: PB1319-ND http://www.digikey.com/product-search/en?x=-1198&y=-74&lang=en&site=us&KeyWords=PB1319-ND

[Ian Brech]

I've attached drafts of the LED control board schematic and PCB design. Still need to do the silk screen, but I'll worry about that once we decide the rest of the board is good. I'm still a bit unfamiliar with github, so I haven't posted anything there yet.

What exactly are we looking for as far as the Thompson power pole parts go?

[luke.renaud]

What is the head clearance on those screws?

I think we might be able to bring the board size down a half an inch on it's short edge by bringing in those headers and components a little tighter.

[raygunn13]

I'm also interested to know what type of clearance we have for the screws. I'm specced for .20in. is that not enough? I think I heard it was either .22 or .25 from someone in lab but I need confirmation. I'm working on the board layout right now.

[Ian Brech]

I'm using the 2.8mm hole from the "Holes" library. I drew out a pad with a 1/8 inch diameter inner hole and a 0.22 inch outer diameter, and it was giving me the same footprint as the 2.8mm hole. Actually now that I look at it... the 2.8mm hole has an extra 0.03 inch ring around its edge.

[luke.renaud]

Screw holes should be 0.125" diamater, while the head clearance should be 0.22" diameter.

[Ian Brech]

Ok, I can change that and shrink the board as well. How do you go about doing the silk screen for the board, or is that what all the grey text on it will be?

Also, do we want the clearance for the screw to be a pad on the board, or just a mark on the silk screen?

[luke.renaud]

The silk screen is just another layer. That's what the grey is, but you can add custom objects to it by simply drawing on that layer rather than drawing on the metal layers. We'll do a review of the screens before we order. Things like removing marks that we don't need, and moving those that aren't optimally placed.

[Ian Brech]

Alright. Here is the new draft of the LED control board. I was able to cut 0.5" off of it.

And while I think of it, we had a request for providing a way for the primary board's microcontroller to reset the I2C lines if the sensors stop being readable. James had thought of using a BJT to power on the 3v3 line to the sensors, and then de-asserting a signal to kill it. Thoughts?

[Ian Brech]

Had another thought concerning the primary PCB. Assuming we still need a 2-wire interface for a pinger, do we want to have a separate header for these signals or just designate them at a later date from the extra signals on the board?

[luke.renaud]

The pinger will just be a device we turn on and off. With that in mind, we can probably just daisy chain it off of the hydrophone I2C connection on the actuation board. So I wouldn't worry about that for now.

How hard would it be to rotate the KK style connectors on your board? Currently they have the keyed slot (the plastic bit that sticks up on the edge of the connector) facing the outer edge of the board. I don't know if this was intentional, but personally I feel it would make more sense to have that bit facing inwards.

Any other thoughts on this, particularly from James and Korey?

Other than that I'd recommend changing the polygon flood fill rectangle on the bottom of the board to have a removed rectangular region around each screw. This would simply be an extra precaution to ensure that should the solder mask become scratched, there is no way to short to the frame even if the MechE's do put in the washers I've requested for mounting. Which actually reminds me, we should probably provide an extra tenth of an inch around each hole beyond what we have right now for those washers. That doesn't need to be a hard clearance, just no parts should be mounted in that subtly larger area. If we go this route our hole would be 0.125" (3.175mm), with a 0.22" (5.588mm) hard clearance (no metal), and a 0.32" (8.128mm) soft clearance (no parts). Does that sound reasonable?

[Ian Brech]

Ok, that makes sense. I wasn't sure on either the KK or the Sherlock connector orientation. I can fix that, since I was actually thinking along the same lines as you were. Are the Sherlocks still ok?  I didn't bother rerouting flood fill on the bottom to exclude the screws since it's the one for ground, but I can change that anyway. Guess it never hurts to take that precaution.

As far as the screws go, we can go with that for now. Wouldn't be a bad idea to get in touch with the MEs to verify that they are getting those washers before we finalize the PCBs.

[raygunn13]

Alpha Prototype for the Thruster Feedback board layout. 

[Ian Brech]

For the screw clearance, we want the entire washer on the board, correct? No hanging over an edge?

[luke.renaud]

The washers can actually hang over the edge if it makes your life easier. Provided the drill bits don't come too close to the edge (if they do DRC will throw an error, so you can always test the waters if you want) you can even let the screw head overhang the edge of the board.

On another note, I've pushed my latest changes to my branch of the source control. Here are some (non cutoff) versions of the two layouts I've got. One for the battery lockout board, and another for the actuation PCB.

[luke.renaud]

A quick side note for both of you. The fonts look very clean right now, but when we manufacturer the fonts will change. To avoid this, go to your Window menu -> User Interface, and check "Always Vector Font" so you know how the final board will turn out.

[Korey Holmstrom]

So Luke, do you think that we need external crystal oscillators on the boards?  How fast of a clock cycle can we get without them?

[luke.renaud]

No. The Max32s don't need them for anything we've done, and I've never needed one. If we were worried about keeping a system clock or something then it might be an issue, but we don't need it on any of the microcontrollers.

[luke.renaud]

Updated parts DB. My current changes are in the git, and ready for final review.

[raygunn13]

An update on my next iteration of the board. This is very rough and hasn't been appropriately downsized. I was asked for an intermediate update and this is it.

Constructive feedback is encouraged as many changes have been made.

[Ian Brech]

I've attached images of the preliminary design of the Primary PCB. I have also committed the actual files to github. I still need to finish running DRC (lots of errors because of those LQFP pins). I'll need to verify the footprints for the oscillator, 3.3V power regulator, p-fets and LED strip as well. Let me know anything you like/don't like/can't stand so we can get this thing finalized. I also need to do the silkscreen. Is there any way to remove the values from the PCB without having them get deleted in the schematic as well?

[raygunn13]

Here's my next version of the Thruster Feedback controller. This passes the DRC default and is 2.6x2.4 inches. With a little work and some input from you guys it could be even smaller, but this was what I have so far. Let me know what you think. It incorporates the Sparkfun LED bars Luke told me about.

[Ian Brech]

Nate, you should move things closer together and cut down the width of the board. You can also move the 3 capacitors at the bottom closer together and place them between the screws, again to make the board smaller. We can have components nearly at the edge of the board.

[raygunn13]

Next iteration complete!

[luke.renaud]

These are the wrong files Nate. You need to post the .brd and .sch files. The .s# and .b# are previous save backups.

[raygunn13]

The real files.

[luke.renaud]

Okay, a quick update on the VUSB pins. That pin can be totally disconnected. It's a sense pin for the USB bus when in use. As we don't actually have to use it, we can disconnect it entirely to make our routing easier to work with.

[Korey Holmstrom]

Actually, the data sheet says for the V_USB3V3 pin says: USB internal transceiver supply. If the USB module is not used, this pin must be connected to VDD.  Also, we need to change which pins the UART uses.  Currently the selected pins only support U1RX and U2TX.

[luke.renaud]

Vbus is the pin I was referring too. It does not need to be tied up. USB3v3 does, but that is currently done in all boards.

[Ian Brech]

So I'm seeing on page 144:

U1RX:

RPA2

RPB6

RPA4

RPB13

RPB2

RPC6

RPC1

RPC3

And on page 146:

U1TX:

RPA0

RPB3

RPB4

RPB15

RPB7

RPC7

RPC0

RPC5

Our convention has been that we're using RPA2 for URX on our boards, and RPA3 for UTX, so you're right. We need to change our convention so that UTX is either on RPB3 (pin 7) or RPB4 (pin 11). I'd rather go for pin 11 just so we have pin 7 available for I2C if needed. I'll double check the primary board eventually, since it's the only board I know of that isn't using this convention.

Good catch. We need to double check any other pins that are being used as function-specific pins (UART, SPI, etc.). Again, I'm a little swamped til tomorrow evening, but I will get around to it.

[raygunn13]

Used a USB-mini. Will this suit our needs for debugging the cameras in the future?

[luke.renaud]

That'll work, but we want to hang the edge of the USB connector just off the edge of the board, or right on it. We have to remember the cable connector has a slight shroud, so we don't want the board edge preventing us from being able to plug into the board. The Sherlock connectors edge should be right on the board edge.

We need D+/D- labels for soldering to the header, and there should be one wire on the USB header that isn't used in a full cable, that wire doesn't need to be routed. The shield should be routed to the 5th pin on the Sherlock connector.

[Ian Brech]

So here's what I've done to the primary PCB so far. Haven't pushed this to git yet because I'm still working on it (after I finish this other homework). For some reason the thermals on the power supply still won't fill in, but we'll figure that out later. The things I'd still like us to come to a consensus on (or just clarify again for me):

1.) What circuitry to we need for the optoisolators? The datasheet is rather vague, so I'm hesitant to omit those parts yet (though extra decoupling capacitors seem redundant, and I'd be willing to get rid of those)

2.) FOr the capacitors for the FTDI chip, should I combine them into one capacitor (3.3V and 1.8V rails), or try and place the capacitors close to each of those pins (routing nightmare)?

3.) Do we care if the LED bar is on the edge of the board, or are we ok with the resistor bars being on the edge (swap positions of the LED bar and resistor bars?)

That's about all I have right now. I figured I'd double check this before I get too involved with the redesign.

[raygunn13]

I've been looking at the datasheet for the optoisolators, I can't say for certain but I think the extra decoupling capacitors aren't needed. They do require a 0.1uF bypass cap between pins 8 and 5. The 'C_L' has a test value of 15pF, so I'm fairly confident in saying it's not necessary. 

For the next point, #2, I think it's fine to just combne them to save some serious headache in trying to route them close to the FTDI pins.

For #3 I don't care, it looks totally fine to me.

[Ian Brech]

Sounds good. Except I think you may have been looking at the wrong optoisolators. The data sheet is pretty vague. Here's the link: http://www.digikey.com/product-detail/en/CPC5001G/CLA406-ND/4360774

Here's what the datasheet says about the resistor: "If different supply voltage levels are used at each side, then the part, in conjunction with its external pullup resistors will perform logic level translation for VDD between 2.7V and 5.5V at either side"

My feeling is that we can leave the space for the resistors for now, and if they're not needed we just don't solder the resistors on. They're just pull-ups, so everything would still be routed correctly if we left them off.

[Ian Brech]

Current revision of the Primary Board. I'll push it to git. I think the flood fills are good, but better check.

[luke.renaud]

I'll have to look at it again, but every non-localized cap is redundant. So a bunch of these we can remove. Also the footprints on some of the caps still need to be changed to reflect the other capacitor outline. When I get back to my desktop I'll find the number and post it.

It looks like a few things got missed, but they should only make your life easier as we go. Did we ever hear back from James and Korey about what they wanted us to change the UART pins too?
-Luke

[Ian Brech]

I didn't here back from them, but I made a post a couple days ago that should outline it. U1RX is fine on pin 9 (RPA2), but U1TX needs to move to either pin 7 (RPB3) or pin 11 (RPB4). I'm in favor of using RPB4 for U1TX, just because it's one pin closer to where it is now. We could use other pins, but I figure these ones are close to what we have now, so let's not overhaul our designs more than we need to.

So looking for capacitors for the FTDI chip, the closest we can get to 300nF and 400nF with a single FK series capacitor is 0.33uF and 0.47uF. I can get to 0.30uF using two 0.15F capacitors, and to 0.40uF using two 0.15F capacitors and a 0.1uF cap. The only other capacitors I've found that are 0.3uF and 0.4uF are film capacitors, and they are generally much larger and more expensive. I'll take a look, but does anyone know exactly how precise these capacitances need to be?

[luke.renaud]

Okay, first the LED board. There is a slight angle on the left hand top metal polygon that needs to be simply sheered up, it's literally a two click fix. Other than that there is some silk screen stuff I'd personally like to tidy up ever so slightly. I've branched your tree and made those changes. If you approve of them you can pull the changes back into your branch. With regard to naming headers, we should always use descriptive name when possible. I've done this with the headers I feel should be renamed on the LED PCB. I DID NOT MAKE THE UART CHANGE ON THIS BOARD YET! So once that's done a few things will need to be selected. It's also worth noting that the silk screen canc ross any boundary you want on the copper without causing issue. Only places where metal is exposed (i.e. pads/drills) all the silk screen be removed.

With regard to the main board, the capacitors we need to swap to for the nF sized caps should have a footprint C025-025X050. This puts the solder pads inside of the part outline. If C11, C7, C30, C29, and C28 can't be localized any better, remove them one by one, look to see if you think we can localize any better, and if we can't drop the extra caps. The other thing to remember about sizing, is we don't have to hit the value exactly, we can overshoot. A decoupling cap prevents voltage droop, so a larger cap in general only improves performance. If we can't get exactly 400nF, that's fine, 1uF is even better, it's just not always quite as cheap or as small in footprint, particularly if we were using SMD caps. I'll go through and do silkscreen cleanup after we do rerouting for this board. There are a few clearance errors in the DRC that need to be cleaned up. Running a library->update on the RS-molex-sherlock library will clear the layer abuse errors you've been getting.

I the regulator footprint DRC problem is because the library hasn't been "updated" for the schematic. Library->update on the rd-parts library you've created will clear the drill errors on the regulator. There are a few other small errors we can clear up. I can run through them with you sometime a little later if you'd like a hand.

Finally, I'd personally prefer to swap the TX pin to RB4 if there isn't any other preference. This avoids putting it on the far side of a power pin to minimize the need for rerouting of higher power traces. I'm open to alternatives, that's just my initial thought.

[Ian Brech]

Ok, that looks good. I've already made the UART change, so that should work. I'm just not quite sure how to do the merge using git for windows. Because you can merge the branches and accept changes from both, correct?

Updating the libraries fixed the DRC problems, so the LED board I was working on passed the DRC. The primary board is still going through some significant rerouting. I've localized almost all of those capacitors, and will make sure they're updated to the correct footprint. I'm also using different UART RX/TX pins on the primary board for the sake of routing.

There were a couple parts that I needed as well that we didn't have on the parts sheet, like a couple resistors and capacitors. Also the resistor busses I'm using. I'm not sure what exactly happened, but the excel sheet I have doesn't have any discrete LEDs, so I'll have to have you or Nate add them to the actual parts list.

Update: I've finished my rework of the Primary Board, though there is still a bit to be done with the silk screen. It passes the DRC (it's amazing the things you missed looking at it.). I updated the capacitor footprints and localized them around the FTDI chip. I'd like someone to double-check the UART signals, make sure that I'm not crazy and that they do work with their assigned pins. There's still some room to move some components around and maybe save a little space (or add some prototyping area, or throw our club logo on, whatever we want). Anything else I should change with it?

[James Irwin]

Normally, yes, you an merge changes from both branches. However, it usually involves manually selecting which things you want from each branch, which is easy for a code file, I don't really think it's possible for a eagleCAD file. I think Luke was expecting you to merge and then apply your changes on top of his.

[luke.renaud]

If you can merge an XML file you can merge an Eagle file.

Your current commit hasn't modified the LED board, so if you fetch the changes and are okay with them, you can just pull the LED branch into your's and it won't cause any conflicts. From there you can make any needed modifications. I can do the merge manually if you don't want to deal with it, but then you have to do a fetch from the main branch before you do any more modifications. If you're fine with that just let me know.

[Korey Holmstrom]

Just a note, I did reply to your post a few days ago regarding the UART pin.  I agreed that pin 11 would work.

[raygunn13]

For debugging.

[Ian Brech]

Well that's a tiny board. Ok, I made a few more revisions to the Primary board and did a bit of work on the silk screen. I'm still trying to double check that there aren't any flood filled areas that get too narrow.

[luke.renaud]

Looks good. As a secondary measure, fill the entire underside of the board with the SHEILD signal, and be sure to put a name on the board (e.g. RS14-USB-BRKOUT or something) on the bottom, along with your name. When you're set, commit and push the changes to your branch.

[luke.renaud]

Looking very nice. I'd like to try pushing some of the traces underneath the optoisolators further to the upper edge, so we can expand the blue flood fill to the bottom side of the optoisolators a bit more to shore up the ground connection for the Motor, LED, and Actuation headers. C8 still has the wrong footprint. If it makes layout easier, you could rotate C11 or C7 and drop one the other cap. The other thing I'll note is you've got a good bit of free area above the FTDI chip. I'd try pushing C28, C29 further to the right (only the VDD side of the capacitor needs to be close to the chip, the other side can be spaced as needed), then push C4 and C26 out of the way to bring the crystal closer into the main chip if at all possible.I don't know how much closer we can make it, but the closer it is the better noise immunity we have. It's not something I'm super worked about, but if we have time it might be worth trying.

[Ian Brech]

Good call on the capacitors. I moved some things around, and the  oscillator is now closer to the FTDI chip. I'm having a hard time moving those signals around under the optoisolators though, and I'm sill a little worried about how restricted the ground signal is near the LED strip. Through in all reality, ground will not be going to any of the other microcontroller boards through the UART headers so we don't need to worry about that quite as much.

Any thoughts on how it stands now?

[luke.renaud]

I'd make two changes to ease this problem. The first is I'd take the labels for R9, R15, and R17 and put them next to the ends of the resistors to reduce their effective height including silkscreen. Then I'd move each resistor up a tad to close up that spacing a little bit, and similarly move the headers for all three boards up a bit as well.

This opens up the 3v3 and GND path quite a bit for both the LED and Actuation boards. Next I note that the primary source of ground cuts in that area is the QOUT signal (the motor kill) from routed on the right of the motor header. Rather than routing it through both top and bottom metal, I'd simply cut it through the top metal only to avoid cutting the ground path. This will cut the 3v3 path in half, but there are two major feed paths into that area for 3v3, and they still wouldnt be totally isolated, they would have a moderately strong connection using top metal routing for this signal.'t still face the long feed path through the board, but it's pretty wide overall. If we really wanted to avoid more cuts we could use a jumper to route it through the top metal and weave it around the signals above the motor connector and bellow R9 to maximize the width of the 3v3 path and gnu path bellow the motor connector.

The final note I'd make, is that we can shift the FTDI block upwards a tad to increase the clearance on the bottom edge. By dropping C7 and squeezing the VREG (IC3) and C6 in a bit we open up an area to put a swath of bottom metal along the lower edge of the board to feed ground. Then what we do is reroute the VDD feed path from the USB header via a metal jumper wire over the signal pins, to free up bottom metal to the left of the USB header. Then we can route a main ground path to it's left as a left side feed into the headers.

I realize that's a bit of convolute explanation, so I'm in the lab tonight if you want me to simply point it out visually. I've tried to express it generally with the attached picture. Pink arrows indicate the general flow of moving parts to irk out a bit of room, while the green arrows indicate the flow of the ground path I'd recommend creating on bottom metal. The leftward motion of pink arrows is only a recommendation for the bottom metal movement.

Finally as an aside, with the current layout routing, C1, C3, and C4 can all be removed and simply be incorporated into C2. I'd also rotate C2 180º in place to simply bring it's positive terminal a tad closer to the pin it's connected to.

[Ian Brech]

Alright, I see what you mean. Actually, I messed up on C1, C2, C3 and C4. C1 and C3 should be localized to pin 9 on the FTDI chip, and C2 and C4 should be localized to pin 4. I can localize them if we want, or I can do as you suggested and combine them all. So if we localize, should we overspec for 6.8uF, since we can't get a 4.8uF capacitor? And if we combine, should we just go with a 10uF cap (instead of 9.6uF).

I think I'll stop by so you can go over anything that I don't end up getting. Any time that works best for you?

[luke.renaud]

Nate I just looked over your PCB. A few quick things. The traces on the right side of the PCB have a few odd angles. The connection between R6 and the PIC, the connection between C3V3 and the pic near the middle f the LED bar, and the connection between C3 and the pic further down are at odd angles that the manufacturer will complain about. Aside from that the board itself should have  a name. If you don't have one yet, I favor RS14-MotorDBG or something similar.

The only other thing I'll note about this board is the drill holes aren't all aligned. Simply tweak these as you see fit.

On the sherlock-usb eager, we still need the board name and the flood fill on bottom metal to shield.

[Ian Brech]

Korey just pointed out that there is a problem with the SPI signals on the LED slave board. RPA0 cannot be remapped for an SDO signal, so I have to change that to RPB13. I was about to use RPA4, but RPB13 is more conveniently placed.

[Nathan Ray]

Updated Prices on the part list, pushing my annotated PCB to github.

[Ian Brech]

I've pushed the modifications to the primary board to my branch on git. Let me know if there's anything that doesn't look good now or if there's anything I forgot to do.

[luke.renaud]

@Nate, what exactly did you add to the sheet? I'd like to know so I can update the master sheet locally.

@Ian, don't forget to rename QOUT to TKILL. It couldn't hurt to put the bar over the name to indicate active low as well. Or at the very least a note on the schematic.

One bigger problem that I thought was fixed, currently the LEDs are being powered by 3v3 and ground on the PIC side of the optoisolators, but the transistors controlling them are still being driven by the FTDI chip's side signals.

[Nathan Ray]

I specifically filled in the prices for the Molex and sherlock connectors which I had missed and you had kindly pointed out so.

[Ian Brech]

Well crap. I didn't see that. Just finished making the changes and pushing it to git again. A few more vias and some different routes, but should still have solid flood fills.

[luke.renaud]

Looks good to me. I'd like Final approval from James then I'll file the order for all of our boards.

Tentatively, quantities in sets:

1 set Main board

1 set AcutationPCB

1 set ThrusterFeedback

1 set LEDDriver

1 set Power12V

1 set Power5V

2 set USBBreakout

If I go off of current sizes, total cost should be roughly $140 (looks like I WAY overestimated, sorry about that James.)

I'm going to ask that someone else handle the Digikey orders. I can give more information on how to do that for whoever steps up to attack it.

Parts will include:

1. BOM parts
   
2. PowerPole connectors (from Mouser not Digikey)
   
3. The female headers and plugs for all of our equipment
   
4. Crimper for KK connectors
   
5. Fuses/fuse holder for inside battery tube
   
6. Heatshrink of sizes and lengths
7. The proper firewire connectors for the Firewire board
8. Anything else I'm forgetting (?)

-Luke

[Ian Brech]

I can help with some of that, but not until Tuesday at earliest. I'll also get the forms filled out for the thrusters and H-bridges.

Also, have we selected or ordered wires?

[James Irwin]

I don't think we will need to order wire. We have confirmation that we can use all the wire and cabling from the old robotics lab.

[James Irwin]

Luke, 

On the actuation board, the SEN lines need to be redone, the connections are not proper, a few things are even unconnected. Also, what do those connectors that go to the switches look like? Do they plug in horizontally or vertically? If they're horizontal, they need to be rotated 90 degrees. If you're busy, I can take a crack at fixing it, but somebody else should review it.

[luke.renaud]

I redid the connections, and verified that there are no air wires. Are you looking at the correct board? Those are vertical connectors.

[James Irwin]

Have you pushed to the server? I just fetched, and I'm looking at the master branch. It looks like SEN3 should actually be SEN1, and P1 of both of the switch connectors are connected to the 12V plane, instead of SEN1 and SEN2.

[luke.renaud]

Good catch. Check my branch to verify fixes.

-Luke

[James Irwin]

Alright, looks good now.

[James Irwin]

Nate, I thickened the ground trace that's going to resistor array 1. It was going from thick to thin to thick again. I don't know how much current was flowing through that trace, but I thickened it up just in case.