nobodypb / PiCase40-GPIO

Custom PCB for fixing the rows order of Pi Case 40
GNU General Public License v3.0
3 stars 0 forks source link

Couple of questions #1

Open ifohancroft opened 3 years ago

ifohancroft commented 3 years ago

Hey! Thanks for making this and thanks for sharing with it https://github.com/Pi-Case-40-Community/Pi-Case-40

I get your worry about the PCB height. I am also working on a PCB replacement of my own and that's my worry as well, because of the weird way to have they made the stock one.

  1. I have downloaded your PCB from here and uploaded it to the repo, however, would you mind to make your PCB use a project specific library that contains the footprints, schematic symbols and 3D shapes that the PCB uses, so people don't have to rely on having them, then fork the repo and send a PR, please?

You can check https://github.com/Pi-Case-40-Community/Pi-Case-40/blob/main/README.md for an explanation of what I mean, and my PCB at https://github.com/Pi-Case-40-Community/Pi-Case-40/tree/main/PCB/ifohancroft as an example.

  1. Who do you think about using for printing and assembly of the PCB?

  2. I see for your switch you have used one that's about 13.40mm in height from the PCB to the top of the keycap/actuator. How did you get that measurement? Did you test with existing parts? When measuring the one on the stock PCB, I got something like 10-11mm from the PCB to the top

  3. How did you come up with the thickness for your traces? I mean have you calculated them according to what the pins of the Raspberry Pi produce in terms of voltage and current or are you just using sample widths for now as a proof of concept?

  4. Discussing those stuff via issues/tickets is hard. Do you use IRC by chance? Freenode in particular?

  5. What measurements did you get for the outer sizes of the stock PCB? I mean like side lenghts, angles, etc.

nobodypb commented 3 years ago

Hello! Thanks for including it that fast. I can't wait to have a look on your PCB project.

Regarding the PCB height I see two possible issues arising. No 1 is the spacing between the male pin header and the PCB itself, which I do not consider a big problem, since they probably only added the 'CON1' PCB for stability and workflow reasons. What concerns me the most is the absolut offset added to the spacers that hold the raspi which results in added spacing to the cooler. I for myself can easily shorten the spacers to solve this but few people have this opportunity. So when handsoldering the THTs it would likely be the best to simply use a thin PCB.

  1. Sorry about that. Haven't worked with KiCAD for a while and forgot it doesn't include the used parts in the project. I've now added project specific librarys to my project. Though I didn't read your naming conventions first, so I need to rename again prior to the PR. Additionally I added the datasheets for the parts I'd use and possible alternatives if those aren't available.

  2. For my own batch of PCBs I used Aisler since I really like their service and the possibility to order a package with parts included and share that with others: https://aisler.net/p/LNAQFZOC. However for a potential community based collective order I'd use a cheaper manufacturer for large quantities like PCBWay where you also can choose PCB thickness.

  3. I also got somewhat more than 10mm on measuring the switch. However after checking a whole bunch of vendors I coudn't find a single source for such switches. So I decided to use the next closest size I could find, which is the 9.7mm of the TL1105GF160Q. The datasheet referenced in the KiCAD part is likely wrong about the total size, since button heights are typically measured from the top of the PCB. To me it looks like a slightly shorter button should work just fine, especially with a thicker PCB, but that's actually one of the things I need to test.

  4. I just used the a reasonable width that fitted between the pads of the connectors. Experience shows that the currents are negligible for such short traces. At least when it comes to anything that's possibly connected to a raspi. I may have a look if it's possible to somewhat widen the power paths but without using vias which I tend to avoid on hobby projects, there is simply no sane way to use decisive wider traces. One could argue that I may reduce width for the signal traces to reduce capacity, but I don't see any realworld advantages coming out of that. The principle here is KISS ;)

  5. I used to, but right now I have no client installed anymore and especially no BNC setup to stay online. But I may use a webclient to get in touch. On the other hand, shouldn't we keep technical discussions on a platform where everyone can read and comment them?

  6. I did not write down my measurements, but modeled them directly into the board outline with small modifications. But I've put a lot of effort in that so you can confidently asume that the resulting outline fits well. There is also enough free space around the PCB for error tolerance. Just take the physical dimensions from my project files. If you want to be on the safe side just wait some days. My PCBs are currently in production and will be shipped soon, so I'll be able to give concrete answers.

Thanks for your questions, they've challenged me to think about some things closer again. Feel free to ask further.

ifohancroft commented 3 years ago

I feel like the height of the stock female header isn't even enough as if you remember, it doesn't come out exactly in the center of the cutout, but actually more to the bottom of the cutout.

  1. Sorry, I hope the rules/conventions are not too strict for the repo. I've re-did them a couple of times, trying to have some consistency and to assure the existance of things that would make it easy to use and navigate but trying to not make them too strict.

  2. Thank you! Their price doesn't seem bad for a prototype at all. I was thinking about using First PCB (now renamed to eecart) but I want to redo my footprints according to the specific components I am going to use and they haven't yet updated their website to list the components they tend to keep in-stock.

  3. I also couldn't find any exact switches but I can't believe my measurements to the last digit as my current calipers suck. I mean we will be ordering prototypes anyway, so we can change the switches later if needed.

  4. I did the same pretty much. Trying to stick to the original design and components, there is really not much wiggle room for track width anyway.

  5. Good point about keeping it in a place where anyone can catch up on the convo.

    1. Thank you! I forgot to check that. I want to confirm some of my measurements and figure out others (like the difference between the two edges at the top around the screw hole. I did look at the design and wrote down which measurements are like there are because of what (I mean for example the screw holes, their distance is what it is so it matches with the Raspberry Pi's mount holes, and their size is so the inner screw post goes through them but they lay on the outer part of it) but there are parts of it that are like they are just because that's how they've been designed and I'd like to match the original PCB's footprint.
nobodypb commented 3 years ago
  1. No problem conventions are neccessary imo. It'll just take me some extra time to make my KiCAD project comply when I change it the next time.

  2. Well I now think this will need manual assembly nevertheless. - Unless you find the exact buttons and a manufacturer that adds the spacing to the male headers - So it may be easier to buy the parts separately.

  3. I think I'll optimize the track width as much as I can, just because I can, once I adjust the button position. ;)

For the remaining points, just check out my updated readme. I recieved my PCBs today and did some tests.

ifohancroft commented 3 years ago
  1. Glad they are not an inconvenience. I came up with an idea that would make things a lot easier and less strict, while still having enough conventions to streamline everything. (It's in the next comment, to not dilute this one).

  2. I will soon contact some board houses to see if there is a way we can make the PCB so it is clear from it, that we want them to sandwitch the riser PCB between the main pcb and the male header, without the need to make separate orders or contact them about it, so people can just order it from our files and get it fully assembled. Do you happen to know if that's possible or any manifacturers that can do it?

  3. Let me know when you optimize the traces. I am curious to see how you'd do them. I have researched and experimented and made all of mine 12 mils. Probably not ideal but from what I gathered, the best possible, since we are workig with a fixed design and can't just move components as we wish.

  4. I am loving your recent update.

  5. Where did you order the components from?

  6. Why/how does the GPIO PCB affect whether the Raspberry Pi can touch the radiator?

  7. What's your hack for centering the male header to the case cutout?

  8. I have decided to follow your example of testing with manual assembly for now. Seeing how you had problems with the button being short, I decided to go with one that's longer than needed. I find the stock one harder to press through the rubber anyway. I got this one: https://www.adafruit.com/product/1490 Unfortunately, I can't find what is the manufacturer or the model number of the buttons I ordered and I can't find other with the same height. The shortest I can find, that are not shorter than those I ordered, are 13mm so I'll have to try with them in the future, perhaps. The rest of the parts I also got from Adafruit. There is I believe only a single female header that fits the Raspberry Pi and is SMD, as well as only one angled THT male header that has two rows and enough pins. Unfortunately, I don't have a Rasperry Pi yet so I can only test my PCB in-relation to the case and the stock PCB. Any Pi testing I can do is limited to physical dimensions using the Pi's mechanical drawings. Speakig of those, I ordered a PCB and only after the order was in production, I realized I made a mistake that would prevent the Pi from fitting because I didn't leave enough clearance for its PoE header.

  9. Btw do you remember the thickness of the small stock PCB? I was removing components from mine to get it flat to measure more easily and the small one broke.

  10. I have made a replacement sticker, but I have yet to order it and test. Haven't uploaded the files for it yet.

  11. I see you have put holes in the middle of the SMD Female Header Socket Footprint. Why is that? Is there any practical reason for it or did the footprint you had just have them?

ifohancroft commented 3 years ago

Here are the suggestions. Let me know what you think, and of course, if you have any other/more suggestions - let me know.

  1. In the case of a PCB, I feel like just having a project specific repo, that's included with the PCB is fine. Like in your case, people can clone the repo and open the PCB and everything is there. I don't see a reason for asking for a change. So I suggest something like the following three options. Each can be recognized valid:

1.1. Having the files directly inside of the PCB folder (like they currently are in your repo) 1.2. Having the files in a Library folder inside the PCB folder 1.3. Having the files in a Library folder outside/next to the PCB folder

I think the only thing that shouldn't be accepted is just if the files are dumped outside of the PCB folder next to the README and LICENSE, without being in a folder of their own.

  1. For the Output files, I suggest we recognize both/each of the following options as valid: 2.1. Having the files in an Output folder inside of the PCB/Design folder (by Design folder I mean the folder in the repo that holds the CAD source files) 2.2. Having the files in an Output folder outside of/next to the PCB/Design folder

  2. I think there is no reason to be very strict with the names. What I mean is, as long as the library and output folders indicate clearly enough what they are so people know what's inside of them, there's no reason to insist on a particular capitalization, or even naming in the case of PCB output files. So long story short, for the case of design, I feel like Output/output/Output Files/Output files/etc should all be accepted as valid and in the case of PCB, Output/output/Output Files/Output files/Gerbers/Gerber Files/etc should all be accepted as valid.

  3. I think this is perhaps the most important change. You are already pushing to your repo, I see no reason of making you push the same to a second repo, I suggest we should use git's submodules instead. I.e. Inside of the PCB folder, there should be a folder with your username, and inside it, your current repo should be loaded as a submodule. That way, you can push and make changes to your repo and people can still download it from the org repo. So the idea is if anyone wants their repo included or has given us permission to include it, we ask them to follow the revised rules from above (to have a readme and a license, some sort of a folder for output files, a folder with the pcb or design source files and if pcb also to have the project specific library somewhere) and either we create a folder with their username and add it as a submodule or we ask them to do it and open a PR.

Couple of problems with the submodules though:

4.1. Do we ask people to open a PR adding the submodules or do we do it? 4.2. When you add a submodule, it links to a specific commit, so while we can put the specific clone command, in the README, that people can use to clone the whole repo, with the latest versions of the submodules, while browsing the repo, and you click on a submodule, it redirects you to that repo on a specific commit. Should we explain the browsing edge case in the README? 4.3. If people are supposed to send us a PR with their submodule included, what should be the procedure? I mean, after they fork the repo, the following questions arise: 4.3.1 Should we ask them to clone just the plain repo without the submodules or with them? 4.3.2. If they clone the repo with the submodules, should they clone so they get the latest version as opposed to the version linked from in the repo?

Unless cloning the plain repo, without the submodules and adding your own, then creating a PR, removes the other submodules, I think the most straightforward way to ask them to do it is: 1. Fork the repo, do a plain clone (without the submodules), add their repo as a submodule, commit/push, then open a PR.

ifohancroft commented 3 years ago

P.S. I have updated the repo and added both our PCBs as submodules, as well as mentioned in the README how to clone to get all the latest submodules, warned about browsing and included info on how to stay up-to-date with the modules. Feel free to delete your fork as you no longer need to send a PR with your repo included.

Let me know when you are here, I will send you an invite to the org, so you can push to the repo and things like that.

I just need to add the new contributing guide.

P.S. Would you mind renaming your branch from master to main? Just let me know if/when you do that so I can update the submodule to track the new branch name.

ifohancroft commented 3 years ago

Hey! You haven't been active on GitHub in a while now. Are you alright? Is everything ok?