Form factor: Raspberry Pi HAT

[SpeakingOfBrad]

The Raspberry Pi Foundation has a specification for Raspberry Pi add-on boards called HAT (Hardware Attached on Top).

I think the v2 PCB should have this form factor.

To be an official HAT, you need some EEPROM on the board that contains a unique identifier (so that the Raspberry Pi can automatically detect what HAT is attached, and possibly auto-configure for it).
But I think using the form factor, even without the EEPROM, would be a great fit for the new PCB.

I've recently been trying to teach myself KiCAD, and I challenged myself to recreate the PCB v1 schematic in the HAT form factor.
Here's a picture of what I came up with.

It has all of the same features as the v1 PCB, but it's in the HAT form factor. I did make a couple of minor component changes (mainly just using some right angle connectors/switch in place of regular vertical ones), just to account for the way the HAT fits onto the Raspberry Pi as well as taking into consideration how the components would fit into a 3D printed case.
I've also attached the ringlight PCB as a breakaway addon to the HAT. This also functions exactly the same as v1, just some minor component changes and repositioning.

[sokol07]

I agree with you that the new PCB should have HAT form factor. I don't know about the EEPROM (I have no experience with implementing the RPi Foundation rules and developing a full-featured official HAT but if it wouldn't be too much work - I think it'd be great to go fully compatible with the foundation specs).

In your design I see only one thing I'd change for now - I think the power connector should be perpendicular to the 40 pins so that the plug could be easily placed in the side of the device. I'd also move the power switch so that it could be easily fitted and accessed when the HAT and RPi are placed in the case.
Of course, this are things which should be adjusted after we make decisions about possible modifications in the mechanical design of the electronics cover.

Just out of curiosity - did you add paths in the PCB to power off the steppers when they're not active?

[SpeakingOfBrad]

I have not yet. But I figured it would be best to redesign this to fit the new orientation.
Is there something else I should be looking into?

[sokol07]

I think that's makes sense - @OpenScanEu mentioned about redesigning the Classic anyway, I guess the electronics mount would be updated to.
The only thing I see for now is the fact that your and @probably-Erwins-Cat designs are different (the location of the switch and connectors on the board) - I think we should decide to one design not to do the same work a few times (for example, if you will redesign the mechanics now, than we will decide to @probably-Erwins-Cat PCB layout and the result will be wires going not in the direction we want them to).

[SpeakingOfBrad]

I don't plan on redesigning the electronics case/mount yet. You're right that it doesn't make sense to do until a new PCB design is finalized.
My PCB redesign was/is mostly just an exercise for me to improve my KiCAD skills (although I do quite like the design I came up with). @probably-Erwins-Cat's design is better than mine as theirs has more/better features.

[SpeakingOfBrad]

I did not add the ability to power off the stepper motors.

So I did some looking to see what it would take to be able to turn off the stepper motors, and it turns out that you can control it with just a simple GPIO pin to one of the A4988 pins. So I took GPIO 8 and connected it to the sleep pin on the A4988s.
So I have now added that feature to my PCB redesign. It would just take a small amount of code to make a button in the OpenScan GUI to set the GPIO to high or low to enable or disable the steppers.

[SpeakingOfBrad]

[probably-Erwins-Cat]

Currently, I re-design the PCBs in KiCAD to include more safety features and to stick closer to the usual design principles of PCB design to make future changes and additions easier to integrate. A 'Disable Motor' pin is included but also requires some coding to be activated in the OpenScan software.

I personally like the HAT design, however, the official HAT design guide about EEPROM might collide with the current philosophy of OpenScan. You see, the current PCBs can easily be soldered by hand and are intentionally kept as low-level component PCBs. Flashing EEPROM is something that is usually not part of the repertoire of the common tinkerer and requires additional tools. Without the EEPROM following the HAT guide, we wouldn't be allowed to call it "HAT".

That leaves practically two paths. Either designing and manufacturing the complete HAT including EEPROM so you can buy it off the shelf (slightly opposing the open idea of the project), or not including EEPROM at all, thereby creating a HAT-like/HAT-compatible/HAT-esque PCB without calling it "HAT".

[sokol07]

I agree, I think it depends on what we want to achieve - do we want a full-featured HAT (with EEPROM and in such case the manufacturing process will be more complicated and most likely the only way to sell the boards would be as assembled units) or just a breakout board with HAT footprint.
On the other hand, the EEPROM and HAT-compliance would be a first step for developing a more complicated board with more advanced features, which probably would be beneficial in future when the project will be growing.
The question is - how much additional work does the EEPROM implementation require on stage of PCB design? Maybe it would be possible to develop an OpenScan PCB Standard (simple breakout for own assembly) and Pro (with EEPROM, meant to be bought assembled)?
Of course, this requires more work to keep both version maintained (on the other hand, I hope there won't be many changes in the PCB) but it doesn't close any door for us.

[probably-Erwins-Cat]

That is the current version of the RPi-compatible PCB that will be manufactured for testing.

[probably-Erwins-Cat]

If testing turns out great, then this will be likely v2.0:

I rearranged the components so that designing a 3d-printed shield should be easier afterwards. that is basically all changes from the upper version

[SpeakingOfBrad]

@probably-Erwins-Cat It looks like you have the Raspberry Pi pin layout flipped in your schematic. Pin 1 (3.3v) should be the bottom left-most pin, and pin 2 (5v) should be the top left-most pin. The pins in your schematic need a horizontal flip/mirror.

[probably-Erwins-Cat]

you are absolutely right. I completely missed that despite having the pinout and raspberry in front of me...
Well... for the testing purposes the board will still work but it will not look aesthetically pleasing. I already corrected that in a newer version.

[SpeakingOfBrad]

I don't think the EEPROM should be included. Maybe in future iteration of the PCB (like a "Pro" version).
But for now I think it should try to remain as accessible as possible, which means having a kit version available.

[sokol07]

Agreed!

[OpenScanEu]

@sokol07 @SpeakingOfBrad @probably-Erwins-Cat You are amazing!
I just had to spend a few days mostly online and when I finally came back today, I found so much great knowledge and discussion! Thank you!

I want to add some (not-so-technical) thoughts to the discussion:

• As far as I know, many people really like the solder-yourself idea, and this is by far the most requested part/design so far. BUT it also hinders a broader adoption
• I would assume, that almost anyone, who got the current PCB has access to a 3d printer and thus making changes to the scanners design should not be an issue, as long as it is printing only the PCB mount (classic) or Front Plate (mini)

What I envision (but please feel free to correct me and add your thoughts):
(1) a re-design of the current PCB fixing my design decisions/errors (missing ground plane, pull-down resistors, enable pin ...). The form factor should be similar enough, so that the 3d print modifications are minor.
(2) a completely new design approach. Let's call it OpenScanBox (for now). So basically a controller box with a very compact form factor, which contains the Raspberry Pi + HAT + fan (?). The HAT uses standard connectors and is capable of controlling up to three stepper motors, two/three limit switches, camera triggering via optocoupler, camera triggering via USB. The Box could serve as a universal controller for many camera/motion related projects. The compact box design should make it very easy to add the Box to existing projects (e.g. a turntable + camera). On the software side, it should already be relatively easy to add new operational modes.

But, I don't know whether this is overkill. Please let me know what you think.

And concerning the other ongoing discussions, please let me know if I somehow should restructure the various openscan GitHub repositories.

[SpeakingOfBrad]

Hi @OpenScanEu! I'm glad you like what you see here!

Both @probably-Erwins-Cat and I started developing a new version of the Raspberry Pi shield independently of each other (and without know the other was doing so). So we each made some design decisions differently than each other. But we both did decide to go with the Raspberry Pi HAT form-factor standard, so that's cool.

When I designed my board, I designed it with 3D printing a case in mind. Specifically I kept the OpenScan Mini in mind as it has a smaller area to work with. Luckily by using the Raspberry Pi HAT form-factor, the Raspberry Pi + shield combo takes up only a tiny bit more space than the Raspberry Pi itself takes up, so it's all very compact.
Originally I was planning to redesign the OpenScan Mini to fit the new Pi+shield, and then also redesign this to fit the new Pi+shield. But after reading your message, I came up with a new idea.

I can design a simple case for the Pi+shield that has all of the various plugs/connectors exposed. This can be used by itself for people who want to use it with their own scanner device/setup and camera (using the optocoupler or USB). (Note, my design of the shield has all of the unused GPIO available to solder, so somebody could use these to control a motor/stepper/servo/switch/button/etc.)

Then I can create a Raspberry Pi camera + Ringlight mount that can attach directly on top of that Pi+shield case. This would fill the same use-case as this (people who want to use their own scanner setup but with the Raspberry Pi camera).

And then I can also redesign the OpenScan Mini so that the Pi+shield case can attach to the rest of the components (basically just replacing the frontplate with the new Pi+shield case).

[sokol07]

@SpeakingOfBrad The solution you described makes the most sense for me but... that's quite some work! Maybe we could collaborate on that somehow? Or do you really want to do it all by yourself? ;)

@OpenScanEu I think we should not restrict ourselves in the PCB modifications not to modify the 3d print - I believe that we should go full ahead with the modifications, and redesign both the PCB and the 3D files to fit to make space for everything future could bring. Speaking of the future - I believe that the "OpenScanBox" and separate "Camera&LightStand" are the best solution because if we want to switch from tiny scanner to medium or huge one we don't change the electronics Box. Moreover, maybe the Box could be designed in a way that it would be a part of the Mini version (for example, be the base of the scanner, onto which all other parts are mounted, if you're using a Classic version - you just don't use the mounting points).

I know that's not the right place for that but as the topic of the 3D prints showed up I wanted to suggest one thing - I see growing popularity of smaller printers like Prusa Mini, I think we should design the mechanical parts so that they could be fitted in an 18x18x18cm space, maybe even with some safety margin. That's just an idea to discuss in a separate discussion.

Aaaand back to the PCBs topic (sorry, I'm a bit chaotic) - if you noticed that the DIY PCBs are popular I think we shouldn't develop a fully-specified HAT (with EEPROM) and focus on a DIY version. Maybe, in future, if we will have some spare time and will we could develop a "Pro" version with the EEPROM and introduce it as a fully-featured HAT.

[SpeakingOfBrad]

@sokol07 I think I'd like to get started on the 3D design myself first, but after I get to a good point where I have the basics there then I'll probably reach out for help (I'll definitely be seeking advice on how to attach the different components to the Pi+shield case).

Speaking of 3D design, @OpenScanEu I see you made a github repository for the discussion and development of the 3D models, but I don't see a discussion area on that one. Is there something you can do to open up that discussion area? And maybe we should move this discussion over to that repository.

And as far as the idea of designing the parts so that they could print on a Prusa Mini, I like that idea. I have more detailed thoughts, but I'll discuss those when we open up that later discussion on it.

[probably-Erwins-Cat]

This will be very likely the future pinout and circuit of the A4988 of the PCB. The enable/disable feature is integrated, pull-downs are integrated, and the motor is running in full steps. Microstepping is currently not needed but can easily be changed if required.

Some design decisions: I consciously placed the traces so that changing the design to integrate microstepping takes less than 5 minutes. All components are top-mounted only to allow for (small) heatsinks for the RPi.

[SpeakingOfBrad]

I don't necessarily stand one way or another. (I don't know enough about steppers and stepper drivers to know which would be best.) I just think we should do it in the "best" possible way. Which in our case may very well be to use the enable pin.
But I think that if one of them one of the is the "proper" or standard way of doing it, and it's only a little bit of work to do it that way (and doesn't cause any other problems) then we should do that little bit of work.

[probably-Erwins-Cat]

the ENABLE pin is in principle the gateway pin for 1A, 2A, 1B and 2B. While it is true that you could save more power with SLEEP, this is not a good idea since the whole IC shuts off. In our use case, this is not a huge issue but considering other stepper drivers with more functionality, this is can cause troubles. In any case, the most power-hungry thing in idle is the RPi anyway.

[probably-Erwins-Cat]

I do see there's a PWR_FLAG on the sleep pin, but I'm not sure what that's connected to.

That is a quirk of the A4988. It has an on-board pull-up on SLEEP to 5V so the sleep pin carries "power" behind a 100k ohms resistor, so practically no real usable power. Without this PWR flag KiCad is complaining that it doesn't know what pin is input and what is output. I am using the on-board pull-up to also pull RESET up to 5V.

[SpeakingOfBrad]

Thanks @sokol07 and @probably-Erwins-Cat for explaining that to me. I appreciate the knowledge.

[sokol07]

@SpeakingOfBrad no problem with that - I spend some time myself trying to understand and estimate the difference between these options just a few month ago when I was trying to integrate one of the stepper drivers into my project! ;)

[probably-Erwins-Cat]

Small update:

Buddy manufactured them (well, actually his trainee) for free from some left-overs as an exercise for the trainee/calibration of the (old) machine. Not premium quality but it will work more than fine for testing purposes. I will bring them to @OpenScanEu and have a look into their functionality.

[wicigee]

Are the printable schematics available for download

[wicigee]

As is on the pictures? For top and bottom

[MichaelTimmermans]

Would it be possible to design the board with the EEPROM pads added, but not yet used?

That way you can sell the not-hats as diy solder and the pro-hats as presoldered with EEPROM installed. No need to have seperate pcb's.

[probably-Erwins-Cat]

Pre-soldering and pre-programming takes takes some labour time or we have to order a large quantity from a manufacturer. Currently, we want to introduce features on the pcb for functionality of the OpenScan such as enable/disable. The first release will likely be without the footprint for the EEPROM but future releases may include the footprint and possibly the EEPROM.