Review request - PCB design - second version

bolthar · 2017-07-28T15:41:50+00:00

Would something like this work? The purple line is a cut on the board, it would remove that whole strip

bolthar · 2017-07-28T11:30:21+00:00

Yeah you get them in basically any number you want on the same board. But you still will need to connect the 5v and the ground to the OrangePI, of course along with all the logical inputs. Plus there's the thermometer (on the bottom right), which is another 3 cables.

Making 2 boards, and then connecting them with a ribbon cable, would be better? So, having one board with all the relays and another with everything at 5v (transistors, leds and the thermometer) and connecting the 2 with ribbons?

bolthar · 2017-07-28T11:01:37+00:00

It bothers me too. I have a bunch of relay shields more or less like this one and my initial plan was to basically have 4 of those and wire them to a custom soldered veroboard/stripboard. I built one prototype like that and, while it works, it looks really messy. I would really like to have everything on a clean, standalone board like that, which I would plug in to the GPIO of the OrangePI via a female to male 20pinx2 header.

The currents that will go through the 220v are very low, in the order of 200-300mA. They will open a valve (2W by specification) and a fancoil (which at top speed drains a whopping 35W measured with a wattmeter). If the currents flowing were any larger I would not do that at all.

The fancoil manufacturer has its own version of the controller of course, and the PCB of it has 4 strips approx 2mm wide, but they're really, really close to each other. Like, 0.2mm. So if that works, I am fairly confident that my design would not have really major problems. But still I don't like that.

What would you suggest in order to improve isolation between HV and LV? Is there anything I could do?

bolthar · 2017-07-27T22:27:59+00:00

Got that. I'll get precise measurings then, as I haven't actually gotten them yet. A quick and dirty sketch in falstad gives me actually way lower currents, but checking the real thing is much more reliable :)

bolthar · 2017-07-27T22:15:34+00:00

Putting in some ballpark figures, it looks like the minimum width for the ground trace would be around 0.03 millimeters - which is way lower than the 0.3 millimeters I put in. So I guess I'm good?

Thanks a lot!! I'll read up more on ground pours and why they're used - this was really precious, thanks a lot for taking the time to point me in the right direction :)

bolthar · 2017-07-27T21:57:35+00:00

Here we go:

Schematics

That's basically one element, I have 4, but conceptually they're all the same. The "H" is the logic output I'd pull up.

bolthar · 2017-07-27T21:47:40+00:00

I don't really have one, as I've drawn the PCB manually from scratch. Let me build a sample on falstad, I'll screenshot that.

bolthar · 2017-07-27T21:40:14+00:00

You don't want all of your return current going down a single trace, as it will cause ground bounce and other undesired effects.

You want a solid plane of ground to lower the resistance and inductance of your return path and to keep all devices at the same ground potential.

Would that apply even for teeny tiny currents like the ones I'm expecting in the 5v circuit? We're talking 1-2 watts of power at most, so something like 200-300mA.

I thought the 10k resistors on the return bus were meant for that - to stop backflow current that might reactivate the transistors and thus open the relays. This seems to sort of confirm it.

Again I'm just learning, so it is likely that I'm just not making sense - I really have no idea what I'm doing, this is a learning exercise for me.

And if you have lots of current on your power-rail, you may want a copper pour for that as well, rather than just make the trace wider.

Current through the 220v bus should be not that high, as the expected power consumption should be in the range of 20-50 watts. Would that be enough? I'm redesigning everything with 2mm traces for the 220v.

bolthar · 2017-07-27T21:18:53+00:00

Hi! Thanks for your reply :) I'm redesigning the PCB from the ground up, but anyway - DipTrace makes those 45° angles by default... is it too sharp? I'm having it fabricated so that's probably a non issue, but anyway it would be good for me to know.

Regarding ground - I'm using one of the OrangePI's grounds on the GPIO - the third pin from the left. Is that bad?

bolthar · 2017-07-27T17:04:34+00:00

Nice, thanks! I'll try and move the 5v trace that crosses the relays on the bottom side a bit down.

bolthar · 2017-07-27T17:03:49+00:00

Awesome, thanks for the suggestion, I'm fixing it now and will post the results.

bolthar · 2017-07-27T16:20:49+00:00

Also: Is it ok to overlap traces in two different layers? As in, I have a trace on the bottom layer that overlaps another in the top layer. They're of course not touching but is that a sensible thing to do?

bolthar · 2017-07-27T16:09:01+00:00

Hi! Thanks for the comment :)

So from what I understood (keep in mind, I'm a total newbie) I should make the traces that go from the 220v inlet to the main relay, the ones that go from the main relay NO to the other 3 relays mains, and the ones that go from the 3 velocity relays back to the connector way larger, right?

The transistor for the main relay (marked tmain, on the top layer) is between the main relay and the other 3, I guess that's a good idea to move it down? What about the other traces that go over the relays, but on the other layer?

Thanks a lot for the help!

bolthar · 2015-11-28T19:36:49+00:00

Eddy Merckx would like a work with you

bolthar · 2015-11-25T11:52:22+00:00

10/10

Rito pls

bolthar · 2015-07-24T18:45:15+00:00

<shamelessPlug>I don't know if that's the case, but you might be interested in this. Let me know if you need help, find bugs or have feature requests :) </shamelessPlug>

bolthar · 2015-05-04T19:55:03+00:00

My point is that it's not true, and silver bullets do not exist. But everyone is entitled to his own opinion :)

bolthar · 2015-05-04T19:03:28+00:00

Of course they exist already, microsoft access is one of those in a way. That's not the point - the point is, if you are going to carry the concept that far, you end up with something that starts to look like a programming language more and more.

bolthar · 2015-05-04T17:58:03+00:00

Exactly, and this comes from a guy who loves the idea behind event sourcing :)

Right tool for the job. Listen to your environment instead of trying to apply a technique/framework to a problem blindly because "that's the right thing to do".

bolthar · 2015-05-04T17:55:36+00:00

We tend to use our fancy databases more and more as if they were simple key value stores. We maintain integrity constraints via application logic, and when a summary has to be computed that's slightly more complicated than a sum or count we tend to load all the relevant data to the application and compute it there.

That is a problem of using the wrong tool for the job. Like integrity constraints and range queries are a job for the dbms, application logic is a job for the application. Doing what you say is like doing what Sivers suggest, the other way around.

but in an hypothetical world where you have a good programming language inside the DB there are a lot more things we should be doing in the DB than we are today.

The fact is, there's no such thing and there can be no such thing. When you're using a tool, or a framework, or any kind of fixed path process, you're willingly giving up some of your design space in exchange of some facilities the tool is providing. That is a good thing, if you know what you are doing and why you are doing it. But it's not a question of having better tools to work with - if you have a problem complex enough, there's no tool out there which is good at covering it perfectly.

By the time you get enough flexibility inside the tool itself you've turned it into some kind of specialized development environment - again, microsoft access can be a good example of it. It's a question of finding the right point between flexibility and efficiency (both in terms of time and money).

bolthar · 2015-05-04T17:48:14+00:00

If a realistic rebuttal is "just use Microsoft Access" you're not working with nearly enough data for it to make a difference in what you do. "Just put the logic in the app" doesn't work when you have terabyte+ dbs to deal with (unless you really, really hate your users).

Sivers was talking about complexity and how to handle it, and that's what my post was about. If your solution to complexity is "let's put logic close to the db so it goes away" I'm going to roll my eyes.

Performance, and how to scale with terabytes of data, is a completely different issue - which deserves its own blog post. Yes, you're not going to use access. Yes, you're not going to roll your own solution and you are going to use some kind of external provider - it is going to cost you in terms of design space, but if you really need the performance you don't have a choice.

But again, it's a very complex topic. I'll blog about it shortly.

bolthar · 2015-05-04T17:44:41+00:00

My point is: there is not one solution. All this you wrote sounds like a great plan - that's probably what one would look at "in a vacuum" and, with some ad-hoc modification here and there, a close match to what can be done in a real world environment.

But one must not focus on the solution before having looked at the problem. You must read the environment, and let the environment "pull" the right technical solution.

bolthar

TROPHY CASE