PCB Tweaks

[dmadison]

Changes + Additions:

• Changed VIN jumper from 2 position to 3 position, to allow for storing the jumper on the board
• Added an LED solder disconnect jumper (NC), in case the user wants to disable the always-on LEDs

Improvements:

• Rotated capacitor C1 so that its polarity matches C3
• Trimmed + added a notch indicator to the 74HC165 footprint's silkscreen
• Rotated all silkscreen text vertically for easier readability
• Added silkscreen outlines to Arduino ports on bottom

Bugfixes:

• Cleaned up excess / overlapping tracks (from grid / snapping issues)
• Sensor: fixed PCB edge cut continuity
• Sensor: moved commit silkscreen off of pads

There should be no changes to the core PCB functionality.

This changes the BOM ever-so-slightly, as the optional 2-pin VIN header is now 3-pin. Although per the ordering instructions it still requires a 1x40 header to be cut up.

[scottbez1]

Thanks for submitting this. Are you planning to order and test these changes? If so, I can go ahead and merge now and then can do a release once you've tested that everything works as expected. Otherwise I think I'd prefer to wait to merge if it may be a while before these changes are tested, just in the interest of avoiding untested changes sitting on master (divergent from the latest release) for too long.

[dmadison]

I'm not - unfortunately I already have my PCBs soldered up and ready to go.

If you'd like I can go back through and cherry pick the cosmetic changes for a separate PR, otherwise I'm okay with waiting.

[dmadison]

Following up on this. Is there anything I can do on my end to get these changes merged?

[scottbez1]

Hey, sorry for the radio silence here. If I'm honest, I don't plan to update the classic electronics at this point given the time and cost required to validate those changes. I've moved on to focus on the next-generation "Chainlink" electronics, which address a bunch of my annoyances with the "classic" design (components are more expensive than I'd like, it takes a long time to assemble, chaining capability is limited, and it's not well suited for use with other microcontrollers). So I'm considering the classic electronics design essentially locked at this point, even though I appreciate that you've made a lot of quality-of-life improvements here. I'm going to go ahead and close this PR instead of leaving it hanging, and can always revisit later if something comes up or plans change. Hope you understand!

[dmadison]

That's disappointing but I understand the desire to move on to bigger and better things.

Do the new chainlink drivers use a different sensor board? Would these sensor board changes still be relevant with the classic electronics deprecated?

[scottbez1]

Yeah you're absolutely right. I realized that right after closing. I'd like to incorporate the sensor changes, and then migrate to Kicad 5 and kikit (already being used for the Chainlink boards, so CI support is already set up) for panelization and gerber outputs.

[dmadison]

Okay. I'll cherry pick those commits and re-submit as another PR.

[scottbez1]

You know what, after all that I think I'll go ahead and review/merge (and then migrate to kicad 5). With the sensor being migrated to kicad 5 (dev/sensorUpdate branch), it's no longer possible to merge the BOM from the controller schematic and the sensor schematic in CI since they're built in completely different environments for kicad 4 vs 5. It's a trivial thing, but it pointed out the bigger problem of having to maintain 2 separate build environments in CI. Since I'm still selling/supporting the classic controller (and don't plan to fully end support for it any time soon, since the Chainlink boards aren't really a 1:1 replacement), it's probably best to just bite the bullet and keep the projects up to date, and if I'm doing that I might as well pull in these changes too.

[scottbez1]

Mad a few small tweaks, hope that's alright

• reverted the VIN jumper change; although I understand the desire to store the jumper when not in use, there's not much silkscreen space available to adequately explain this, and I think "on/off" is insufficiently descriptive (the jumper shouldn't be used as an on/off switch, since it would leave 12V present at the motors and MIC5842's, but all of the logic power would be left floating)
• Moved the U3 label so it's close to pin 1 at the top of the chip rather than at the bottom of the chip, to avoid potential orientation confusion since the chip is installed "upside down"

[dmadison]

I agree with you about the U3 annotation but I wonder if we can find some middle ground on the 3-pin jumper. Perhaps "MOT / NC" instead of "On/Off"? Or a 3 dot connected / no connected symbol? Personally I think the jumper's utility is significantly limited if the user has to find somewhere to store the jumper during setup or testing.

For a left field idea: how about putting both R1 and R7 in line vertically, and then moving the power indicator LEDs down (horizontal) near the EXP IN silkscreen? That would provide enough room for the jumper silkscreen, clean up the somewhat chaotic labels to the left of the expansion port, and allow you to see the state of the indicator LEDs while an IDC cable is connected.

I've pushed the LED changes onto a new branch as a proof of concept.

[scottbez1]

Hmmm, what is your use case for moving/storing the jumper frequently though? With a genuine Arduino Uno there should be no problem leaving the jumper connected all the time, even when USB is connected, so in my mind the jumper would either be always unused or permanently installed.

And if someone has an Arduino Uno knockoff that doesn't adequately protect against VIN backflow to USB vbus (I'm not sure if they actually exist, but there are stories online where people claim this has happened), then I think having jumper storage would be more dangerous; without the storage there's a very clear indicator if it's safe to plug in USB (jumper must be removed completely), whereas with the storage it's a very subtle indicator/action that's easier to forget or miss.

[dmadison]

I was thinking long term, where you may want to change from a USB driven setup over serial to a self-contained setup run on the microcontroller (or vice-versa). In that case you would need to find or store the jumper some place. In my mind because it selects between features it just makes sense to store it in place on the board itself.

Although you do make good points, and I'm okay with leaving the feature out if you think there isn't enough space.

With a genuine Arduino Uno there should be no problem leaving the jumper connected all the time, even when USB is connected, so in my mind the jumper would either be always unused or permanently installed.

If you're envisioning it as a permanent option, why have a selectable jumper? It would simplify both the PCB and the BOM to add it as an NO solder pad.

[scottbez1]

If you're envisioning it as a permanent option, why have a selectable jumper? It would simplify both the PCB and the BOM to add it as an NO solder pad.

That's a fair question, but it's not something that I really want to focus on at the moment.

Similarly, I really like your LED relocation diff, since it makes them visible when chaining boards instead of being covered by the ribbon cable, but it's also a substantial enough change that I would feel compelled to update product photos and the instructional video since those are the components with arguably the least obvious polarity for beginners, which pushes it into "good change, but costs outweigh the benefits" territory for me at the moment.

I'm going to go ahead and merge this PR for now, so the migration to Kicad 5 can continue.