Bringing shield up to modern standards

[VIPQualityPost]

Oops, didn't mean to add the branch on main repo.
This should address #47 , #46 , #45 , #44 .
Some open questions:

• I added ID resistor divider on an ADC pin so we can tell if board has right hand start or not... I thought this would give us the most flexibility for future revs, does everyone else think this is OK? And how should we decide the table for calculating the version number from ADC counts?
• Added two unknown signals from G carriage auto detection ayab-firmware#51 (comment) so that if we figure them out in the future we don't need to hardware hack to fix. Should we add pull-up resistors or is firmware pullup good enough?
• The barrel jack connector seems hard to source, can we switch to a more modern part? The footprint is not common. I don't know how much stock Victoria has of this part. Update: changed to a new part.
• The microblade connectors were going EOL when we did AYAB-ESP32, now they are really EOL, I could not even really find PN for some of them... should we recommend Chinese knockoff part numbers instead of Molex on the BOM? Ordering from LCSC is annoying but they have plenty of stock.
• I changed the layout pretty substantially here, would really appreciate a thorough review on it.
• +15V added to extra pin on expansion connector now for supporting color changer and other user accessories (thanks @jonathanperret )
• I moved the parts from AYAB-ESP32 project into a main library that can be shared between projects, so that it's more generally useful.
• The workflow should be updated to also check this branch and generate gerbers via artifact like we have for ESP32... I also have made some improvements to the action since the last time we were working on any of this, so an update is due anyway.
• Readme should be updated (I did not do)

[VIPQualityPost]

Weird, Carson, Chris, JP and a few others are not possible to add as reviewers.

[jonathanperret]

A lot of work, thanks @VIPQualityPost ! I'll look at this in the next few days.

[VIPQualityPost]

Last night I realized maybe there is a comfort we can add here - what do you think about adding a bridge rectifier like how we did on the ESP32 board ? This way it's no problem for people to use barrel jack with either polarity. They make them in DIP packages as well and I think with the new layout there is more than enough room- something liek this: https://www.mouser.com/datasheet/2/68/get_document-1372065.pdf
I can't find one with very small Vf (these are 1-1.2V) like we used on the other board, but that one also was SMT, the THT options are a bit more limited but I think would be useful to end users.

[VIPQualityPost]

Also- in the time since opening this PR, KiCad 9 has released, with a notable feature of JobSets which should make things like CI a bit more straightforward, I think. I'll take a look at this over the weekend and see if there is an easy way to add that to this repo.

[jonathanperret]

Last night I realized maybe there is a comfort we can add here - what do you think about adding a bridge rectifier like how we did on the ESP32 board ?

I'm not so sure about a rectifier for the shield — here's what makes me hesitate: in my mind, the shield is meant to be the minimalistic, DIY option for AYAB hardware. Adding a part that doesn't really seem essential to the BOM doesn't feel like a step in the right direction? I also have a fear of the 9/15 V DC ground "floating" over the USB ground — why isn't the use of a rectifier behind a DC connector more common than plain reverse voltage protection diodes? Although I have so little experience in circuit design I'll happily defer to yours.

But this is just my opinion of course. In any case, I suggest we should try to get this cleanup of the KiCad shield done (i.e. merge this PR) before considering other changes.

[jonathanperret]

So, I'm not sure I'm qualified to do a proper review of this PR, but I'll just note here the things I've seen on the board that I think should be probably be fixed/improved before new shields are fabricated from these files:

• For the 910 right-side sensors:
  • I'd remove R6 and use the Atmega's internal pull-ups instead — this would be consistent with the other pin which needs the internal pull-up for the 910's open collector output.
  • The TDB1 and TBD2 tracks can be removed as well, thos pins are definitely going to the Mylar reader.
• The I2C expansion connector's pins have been moved around (5V and GND flipped), is that intentional? It would be nice to keep some continuity with the previous pinout.
  • I'm having second thoughts (sorry!) about that extra power pin. With an unkeyed connector, isn't it a bit dangerous to expose a >5V voltage there? Someone is bound to plug something the wrong way and fry something. Maybe a separate GND/15V header somewhere else on the board would be enough to satisfy the power needs of an expansion?
• In general I think I liked the old silkscreen better? Specifically:
  • The I2C connector really needs its pins identified;
  • The designators for the ICs are hidden under the ICs, this is impractical when trying to point an IC on a completed shield;
  • Pin 1s should be marked more clearly on connectors;
  • The boxes around connectors create clutter with not much value it seems to me.
• The Arduino mounting holes went missing. Not sure anyone is using those but if it's not too much trouble to have them, it looks like better shield design?

That's what I got on the board, I hope this is helpful.

[t0mpr1c3]

Matei do you want me to take a look?

[VIPQualityPost]

Matei do you want me to take a look?

Of course, if you have time!

[t0mpr1c3]

The issue with Molex 53014 connectors is real. My current inventory is less than 20 and parts are unobtainable. We would need someone with a KH900 (or KH270 with similar connectors) to test possible substitutes. @Adrienne200 maybe?!

[VIPQualityPost]

The issue with Molex 51004 connectors is real. My current inventory is less than 20 and parts are unobtainable. We would need someone with a KH900 (or KH270 with similar connectors) to test possible substitutes. @Adrienne200 maybe?!

I have a 270 so I can also test, but yes, it's going to be a problem soon I think.

[t0mpr1c3]

How do you want to go about testing replacements? I am happy to fund this. It's a tax deductible expense for me.

[VIPQualityPost]

Fixed the zone fill issues as discussed in the discord, as well as clean up the DRC. I think this is OK to merge (@t0mpr1c3 @jonathanperret )

[VIPQualityPost]

The only thing I didn't do is add the pin for "HV" accessories, but I'm starting to not think this is really as important and adding it would make the already cramped board a bit more unreadable.. considering there are plenty of places to add a bodge wire I would suggest that we just skip adding it.

[jonathanperret]

I thought it might be useful to compare the final outputs between the current shield version (1.4TH, exported from Eagle) and this PR (exported from KiCad 9):

1.4TH	This PR

[jonathanperret]

Thanks @VIPQualityPost for the latest updates!

☝️ Looking at the images above, I have a few questions/remarks — hoping they're not too nitpicky:

• Silkscreen:

  • The IC designators on the silkscreen seem a bit harder to associate with their matching IC, particularly IC2 and IC3. The old design had them consistently near the IC's notch, might be worth imitating?
  • The X1 designator is upside-down 🙃
  • I feel the pin-1 designators were clearer in the old design, but critically now pin 1 becomes indistinguishable once the connectors are soldered, since it's only identified by pad shape?

• Copper

  • We discussed on Discord replacing the identifying resistor divider with a simple bridge between D7 and D8, primarily to ease the task of users updating their old shields. I see the resistor divider is gone but the bridge isn't there. I know we discussed with @jpcornil-git some firmware tricks that might obviate the need for the bridge but I'm not sure whether we eventually decided to leave it out?
  • The old design had thicker traces going out to the solenoids. But the current is only ~150mA, I don't know.
  • ⚠️ I think this is the most significant issue I've seen so far: the +5V pin from the machine's power supply is joined to the +5V pin from the Arduino i.e. the USB port. This cannot be good, surely?

[VIPQualityPost]

Okay, addressed all comments:
Not sure if I like the pin-1 markers here, feel very cluttery, not an easy way to group them better. However , all connectors for all machines are polarized, so do you need to see the pin 1 after soldering?
Also moved Brother power connector to make space for also populating the barrel jack.

[jonathanperret]

Okay, addressed all comments: Not sure if I like the pin-1 markers here, feel very cluttery, not an easy way to group them better. However , all connectors for all machines are polarized, so do you need to see the pin 1 after soldering?

That’s the thing though, on the 910 (the only machine I’m familiar with to be honest) we’re using generic 2.54mm pin headers so the markings are somewhat important.

[jonathanperret]

Okay, addressed all comments

Thanks for the updates! Btw I've slightly updated the PR description to reflect the current state.

• Track widths
  After the solenoid tracks widening, DRC reports a clearance violation here which does look problematic:

Note that if I'm using KiCad's calculator correctly, the previous track width of 0.4mm was more than sufficient to
carry the solenoid current:


So it looks like I was worrying for nothing, sorry.

• More wrong +5V connections
  I'm sorry I didn't catch those earlier, but the following Arduino pins are shorted to +5V when they shouldn't: AREF, IOREF and RESET.
  • IOREF is an input pin for the shield, supposed to let shields differentiate between 3.3V and 5V Arduino boards. The Uno shorts this to +5V already anyway, so a short on the shield is harmless but unnecessary and potentially damaging for other Arduino boards.
  • AREF is meant to be used to optionally provide an external reference voltage for the ADC. But if it is used, the documentation is very clear that firmware should call analogReference(EXTERNAL) before the first analogRead() to avoid a potentially damaging conflict between the internal reference and the external voltage — and the AYAB firmware does not (and has never) called analogReference(EXTERNAL) 😬 . This is an issue that exists on all previous versions of the shield (I went back to check version 1.0 from 2013!), and on the EMSL interface though, so I suggest leaving this as it is for this PR and looking into it further in another issue (the proper thing to do may be to update the firmware rather than the hardware since there's so much hardware out there wired that way).
    Update Here's the new firmware issue to track this Potential conflict between internal and external ADC reference voltage ayab-firmware#225
  • ⚠️ RESET is supposed to be used by shields that want to provide an additional reset button (the EMSL interface does this). It should definitely not be tied to +5V as that will conflict with both the Arduino's reset button, and more importantly the USB/Serial chip (Atmega16u2 on genuine Arduino boards) driving it low upon connection.

Once the DRC violation and RESET pin issues are fixed I think we can merge this. I have some more ideas for minor improvements but that can go into one or more followup PRs.

[VIPQualityPost]

Okay, addressed all comments: Not sure if I like the pin-1 markers here, feel very cluttery, not an easy way to group them better. However , all connectors for all machines are polarized, so do you need to see the pin 1 after soldering?

That’s the thing though, on the 910 (the only machine I’m familiar with to be honest) we’re using generic 2.54mm pin headers so the markings are somewhat important.

You are right, the connector is polarized but I forgot we don't populate it with a polarized connector !
Let me know if there's anything else I missed here.. I tried to be a bit more thorough last night 😄

[jonathanperret]

This is all looking good to me now, thanks @VIPQualityPost for all the hard work.
I see you've gone ahead and disconnected AREF from VCC, this is what we concluded should be done over in AllYarnsAreBeautiful/ayab-firmware#225 so that's good.
You may want to regenerate the files in Reference/ though as they are from an older version of the design.

[VIPQualityPost]

Ah, this should be really generated by the workflow/CI.
Should that get rolled into this PR or should we merge this and update CI for both shield/esp32 in another one?

[jonathanperret]

Ah, this should be really generated by the workflow/CI. Should that get rolled into this PR or should we merge this and update CI for both shield/esp32 in another one?

I'd rather not roll anything more into this PR if possible 😅

But if we can avoid merging outdated files it would be nice as well. Maybe just remove those files from this PR?

[VIPQualityPost]

It was a while since I actually looked at the files in the folder, there was quite a lot of cruft in there. I removed the library created from the import (as now referencing ayab-library), removed empty worksheet and imported worksheet, and the jobset files. ERC/DRC runs clean so there should not be any issues with old references - I think we are good to go!