[Ground-station] Ground-Station Digest, Vol 28, Issue 31

[Thomas Parry]

"Who has available time and willingness in the coming months
(and reasonable skill) for building parts in X, or Y, or X and Z
including Footprints, Symbols (not just big squares), and 3D models and/or
verifying same keeping in mind that it's usually best for building and
verifying to be done by different persons. What tools would be needed to
take advantage of those skills."

I agree that it's worth now reframing the question. It makes sense to
define the tasks that need to be done, who can help and then approach what
tools to use.

Would it make sense to make a spreadsheet (or other format) of the PCB
tasks that need performed and then people can pitch in and say if they can
help? It will be easier to evaluate tools and processes when talking about
the specific task at hand. I think it would also be good to get a firmer
view of how many people are available to work on it.

Thomas



On Tue, 28 Jul 2020 at 06:00,
<ground-station-request at lists.openresearch.institute> wrote:

> Send Ground-Station mailing list submissions to
>         ground-station at lists.openresearch.institute
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> http://lists.openresearch.institute/listinfo.cgi/ground-station-openresearch.institute
>
> or, via email, send a message with subject or body 'help' to
>         ground-station-request at lists.openresearch.institute
>
> You can reach the person managing the list at
>         ground-station-owner at lists.openresearch.institute
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ground-Station digest..."
>
>
> Today's Topics:
>
>    1. Re: How are we set for layout tools? (Keith Wheeler)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 27 Jul 2020 20:59:46 -0700
> From: Keith Wheeler <keith.m.wheeler at gmail.com>
> To: wally.ritchie at gmail.com
> Cc: John Ackermann <jra at febo.com>,  Bruce Perens via Ground-Station
>         <ground-station at lists.openresearch.institute>
> Subject: Re: [Ground-station] How are we set for layout tools?
> Message-ID:
>         <CACXKgh=
> 6vVVbcHW1QW80SFXyGDK0sryoE5Lyr6Og1S84Z56jwQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> My apologies to everyone; re-reading that it comes off much harsher than I
> intended.
>
> My points were simply:
>
> 1) I was merely answering Michelle's questions about what tools the team
> had access to, not trying to state we should use one tool over another
> 2) Some prefer and have great success with Kicad; that's fantastic, use the
> tools that work for you, that's what I do
> 3) As Bruce pointed out, Kicad continues to evolve and from what I've heard
> has the ability to import Altium documents now, on top of the many other
> importable formats
>
> Again, my apologies for coming off harsh, long hot day here in the PNW.
>
> -Keith
>
> On Mon, Jul 27, 2020 at 7:49 PM Keith Wheeler <keith.m.wheeler at gmail.com>
> wrote:
>
> > An amazing amount of discussion (and some latent feelings) brought up by
> > me merely answering the "what layout tools do we have" question.
> >
> > Next time I'll be sure to make a disclaimer that my professional day to
> > day use of a proprietary tool isn't meant to upset the open source gods.
> > Circuit Studio natively uses my nearly two decades worth of Altium
> > libraries and previous designs and costs $495 for a perpetual license,
> plus
> > an annual fee if you want updates. I try Kicad every year or two but find
> > it odd and counter-intuitive, and having the overall feel of software
> > people saying "wouldn't it be cool to do open source hardware tools"
> rather
> > than hardware people saying "here's what we need in open source tools".
> The
> > switching costs of learning a new (counter-intuitive to me) tool along
> with
> > importing many years of work are just too high for me. Obviously not for
> > everyone nor necessarily for the work ahead of us.
> >
> > I'm not a retired pundit so I apologize for not having the time to play
> > with a tool when I have to work for a living.
> >
> > I don't apologize for having volunteered my time and shameful tool skills
> > to do layout for an ORI fundraiser as well as other work for "the
> > community".  It's what we do. Even without much in the way of
> appreciation.
> >
> > I will clarify the following:
> >
> > On source files: there is an opensource altium2kicad tool for the source
> > files (schematic and pcb source) so any work done in this tool is not
> > trapped in proprietary files. And apparently early this year an Altium
> > importer was added to Kicad project. Additionally PCB "manufacturing"
> only
> > requires gerbers RS274x/gcode output text files, not proprietary.
> >
> > All that said I really have no dog in this fight and will let you return
> > to your philosophical debates, I've got boards to design.
> >
> > On Mon, Jul 27, 2020 at 7:47 PM Wally Ritchie via Ground-Station
> > <ground-station at lists.openresearch.institute> wrote:
> >
> >> Yes snapeda is a great resource. I've been using it for the past 2
> years.
> >> It often has a part I need - sometimes with the 3d model as well.
> >> Generally, it's a reliable shortcut. I too have sometimes has to tweak
> the
> >> part but it's usually far less effort than building from scratch. I
> don't
> >> recall any serious errors in their parts.
> >>
> >> I wouldn't bet against autodesk and eagle. Eagle is part of their cloud
> >> SAAS strategy and enhances their product. I don't think they care at all
> >> about the workflow of hobbyists - they care about the workflows of teams
> >> producing commercial products. They do not care one bit about loosing
> >> non-paying customers to KiCad. They care about loosing paying customers
> to
> >> Altium. Perhaps someday they'll drop free versions. But it doesn't hurt
> >> their sales and enhances the flow of paying subscribers while getting
> them
> >> some library parts for zero investment. So it's unlikely. Autodesk has
> for
> >> years provided free versions of tools! like inventor to educational and
> >> non-profits like FIRST to get students familiar with their products.
> They
> >> are a billion dollar company doing quite well. They may someday have to
> >> overhaul the Eagle code base. But that doesn't appear to be anything in
> the
> >> near future. Eagle remains far more open than any other commercial
> package
> >> with respect to adding and extracting data and supplementing it. In any
> >> case there is plenty of room for KiCad and Eagle in the short term.
> >>
> >>
> >> On Mon, Jul 27, 2020 at 9:49 PM John Ackermann <jra at febo.com> wrote:
> >>
> >>> That's a great synopsis, Wally.
> >>>
> >>> One unavoidable concern, and I don't have an answer for it, is the
> >>> learning curve where different team members are used to different
> tools;
> >>> that's much more likely in a volunteer project than a commercial
> >>> enterprise, I think.  Standardizing on a tool within everyone's reach
> helps
> >>> with that, but I doubt that outweighs the other arguments you're
> making.
> >>>
> >>> But as a tiny side point I'll mention again, just for future reference,
> >>> that snapeda.com seems to have a very good engine for designing
> symbols
> >>> and footprints according to some (unknown to me) standard
> specification,
> >>> and a very large collection of pre-defined parts.  I often make minor
> edits
> >>> to their files (easy to do in KiCad), but so far everything I've used
> from
> >>> them has worked -- as in physical footprint matches physical device,
> and
> >>> wires go to the right places.  (Now, keep in mind I'm dealing with far
> more
> >>> pedestrian parts than the ones you're talking about...)
> >>> On Jul 27, 2020, at 8:51 PM, Wally Ritchie via Ground-Station <
> >>> ground-station at lists.openresearch.institute> wrote:
> >>>>
> >>>> 1. Few if any tools are perfect, certainly not any PCB design tools,
> or
> >>>> as John Ackermann eloquently put it - all of them suck to varying
> degrees.
> >>>> All depends on whether your outlook is half-empty or half-full, what
> you
> >>>> are trying to accomplish, and what value you place on different
> things -
> >>>> especially, time and money.
> >>>>
> >>>> 2. Generally, we are not in the business or non-business of producing
> >>>> tools - except maybe those that are so specialized to our tasks that
> they
> >>>> make sense, either because of the nature of the task or the learning
> curves
> >>>> associated with the alternative. So we might write some ad-hoc
> open-source
> >>>> verification tools in python instead of an expensive simulink
> framework -
> >>>> then again the latter may make more sense - it all depends on what we
> are
> >>>> trying to do and the skill sets available to the project.
> >>>>
> >>>> 3. We are embarking on a level of Engineering development on a scale
> >>>> not undertaken before in the Amateur community, at least with regards
> to
> >>>> the technologies we are working with - $2000 FPA chips, $800 radio
> chips,
> >>>> 12 layer boards, SERDES lanes operating at 12GHz, multi-kilobuck dev
> >>>> boards. These many technologies are pretty far from traditional
> Amateur
> >>>> radio and hobby boards. The projects we are undertaking involve
> >>>> professional skill sets in many fields. Those working in these fields
> are
> >>>> accustomed to having tools able to do the job at hand. We are
> counting on
> >>>> many Amateur Radio Enthusiasts who are in fact professionals with
> >>>> relatively current skill sets, many with high hourly value in
> commercial or
> >>>> government settings. We are asking such hams and non-hams to
> contribute to
> >>>> our projects on a volunteer basis. We don't expect them to have to
> bring or
> >>>> buy their own software tool licenses, test equipment, $3000 eval
> boards, or
> >>>> $2000 chips. We want their skills - not their stuff. For these
> projects to
> >>>> succeed we will find ways to supply the stuff - and the volunteers
> will
> >>>> supply the much higher value engineering labor. Whatever investments
> we
> >>>> make in tools will be those that are highly leveraged.
> >>>>
> >>>> 4. You wouldn't make your own hammer, or drill, or CNC machine -
> >>>> although you could with open source designs. It might be fun to do
> that -
> >>>> but it would be a diversion taking you away from the current mission.
> If
> >>>> you can get a carpenter to build something for free labor - you
> wouldn't
> >>>> ask him to make his own tools - just because he can. We won't build
> our own
> >>>> spectrum analyzers or oscilloscopes - although we could. We focus on
> our
> >>>> project and we will beg, borrow, steal, or buy if necessary the tools
> and
> >>>> test equipment to complete the jobs we are doing.
> >>>>
> >>>> 5. With regard to PC tools, the opinions that matter are those of the
> >>>> people who will be doing the critical work and what they need to
> perform
> >>>> their job. What tools are used for a simple pi-shield don't matter
> much.
> >>>> What tool is used to produce a 12 layer FPGA board with 5 DDR4's and a
> >>>> dozen transceiver lanes may matter much - especially to the person
> doing
> >>>> the work and the downstream fab, smt, and test processes. Over the
> past few
> >>>> decades or so the roles of pcb layout specialist and draftsman have
> all but
> >>>> disappeared. Mechanical engineers themselves are married to
> solidworks, or
> >>>> Catia, or whatever. EEs are married to Allegro, Altium, OrCad or some
> other
> >>>> multi kilobuck per seat tool - and in relatively rare cases some small
> >>>> companies may use Eagle Professional multi-seat versions - some still
> >>>> living in Version 7 and others having moved to Autocad Fusion.
> Mechanical
> >>>> and Electrical groups often need close collaboration which is the
> value
> >>>> that PCB/3dCAD integration brings to the table. Catia handled this
> well at
> >>>> the high end if you have megabucks. Fusion looks like it's workable
> for the
> >>>> low end. I've never known of any organization doing commercial or
> military
> >>>> work using KiCad. I suppose it's possible but it's usually a poor
> choice
> >>>> economically - like asking engineers to work at ping-pong tables
> sitting on
> >>>> folding chairs with CRT monitors. These are certainly cheap and
> plentiful.
> >>>> But productively comes from proper capitalization of workers -
> including
> >>>> programmers and engineers. Time is money. Volunteer time may have zero
> >>>> associated dollars but it has associated value that we do not wish to
> >>>> squander - especially when it comes to the most complex parts of our
> >>>> projects.
> >>>>
> >>>> 6. Our goals are to produce open source designs that anyone is free to
> >>>> adapt to their specific needs. Some parts may require specialized
> tools to
> >>>> use - we wish to minimize that, but non-free non-open source tools may
> >>>> sometimes be required to utilize the sources. We can limit IP and
> >>>> endeavor to avoid purchasing IP beyond that included with the standard
> >>>> tools. But I don't think we can afford not to use commercial tools
> when
> >>>> they are the best choice for completing a particular set of tasks. If
> we
> >>>> need Matlab to run a vendor's filter generation tools - so be it. If
> >>>> someone wants to take on converting this to Octave - please have at
> it. If
> >>>> you can modify it and prove it's valid we'll be happy to use it.
> Otherwise,
> >>>> we will just suck it up and use Matlab (beg'd, borrowed, stolen, or
> >>>> purchased).
> >>>>
> >>>> 7. Eagle has a long following - many have used it since Version 4 or
> >>>> early on Mac, Linux, and Windows. They captured a lot of users a
> decade ago
> >>>> with free versions for hobbyist use, free versions usable by board
> houses,
> >>>> and economic professional versions with auto-routing etc. It's a bit
> >>>> weird and quirky but generally extremely stable. I don't see any
> reasonable
> >>>> argument against using Eagle. Nor KiCad for those so inclined. But I
> am
> >>>> against mandating either the forced use of open tools or particular
> tools.
> >>>> As projects involving PC boards proceed - consensus will likely
> appear as
> >>>> to what is appropriate for the task at hand.
> >>>>
> >>>> 8. While we are on the subject, PCB layout has some esoteric black art
> >>>> skills - especially for RF - but a very major part of the work
> >>>> load involves preparing footprints, symbols, and 3d models for parts.
> While
> >>>> there are lots of parts in standard libraries there is a rule that
> says
> >>>> that many of the ones you want won't be there (unless you made them
> >>>> before). There is a lot of effort required to make parts correctly
> and to
> >>>> verify them. But this does not involve special skills - just a normal
> skill
> >>>> with the tool and the usual conventions (like what goes in what
> layers and
> >>>> what does not. There are tools that will generate parts from generic
> >>>> descriptions to the formats of popular cad tools - e.g.
> Ultra-librarian and
> >>>> Library Loader - but they are often less than ideal - particularly
> with
> >>>> complicated parts that should have multiple symbols in functional
> >>>> groupings, not  one big block with 900 pins. Element14 also added a
> lot of
> >>>> parts (thank you) to Eagle, but often with poor symbols. And a lot of
> stuff
> >>>> you'll download from the Internet is poor or outright wrong. If a part
> >>>> cannot be found, then considerable time will need to be devoted to
> building
> >>>> and verifying the part before the PCB layout can continue. Even if a
> part
> >>>> is found - is it correct? What design rules are implied? Frankly,
> this is
> >>>> the vast majority of all PCB design activities. So this is an area
> where
> >>>> many hands could potentially help by contributing. There will be
> ongoing
> >>>> needs to build parts, verify parts, and manage libraries of proven
> good
> >>>> parts. Have a look at the oresat project's Eagle libraries
> >>>> https://github.com/oresat/oresat-eagle-libraries. They seem to have a
> >>>> workable approach for their needs.
> >>>>
> >>>> 9. PCB design software is more than schematic capture and layout. It
> >>>> also involve simulation (e.g. Spice) and design rule verification.
> Over the
> >>>> last decade, integration with 3D mechanical tools has also become
> common.
> >>>> Those in the tool business must  continue to provide value to their
> >>>> customers. Autodesk bought Eagle to add to their other offerings.
> Their
> >>>> Fusion product is now pretty usable and economical at the low end and
> >>>> integrates with their 3D.  They continue to offer free eagle versions
> but
> >>>> their main offering is now their $60/month Fusion product. Several in
> this
> >>>> group use these tools professionally and they are good value for
> money. The
> >>>> Autodesk model is pretty workable as the tools are licensed per named
> >>>> individual but they can be purchased month to month (or longer). So
> they
> >>>> are a good match to specific board projects. Part work can always be
> done
> >>>> with the free versions or the very stable version 7. When we are
> designing
> >>>> and building complex boards with $2000 parts a few months of Fusion
> for a
> >>>> couple of people is in the noise. They are a wise use of funding -
> >>>> especially when they leverage what would otherwise be tens of
> thousands of
> >>>> dollars of engineering labor.
> >>>>
> >>>> 10. So I think that the original question that started this thread
> >>>> should probably be rephrased as:
> >>>>
> >>>> A. Who has available time and willingness in the coming months (and
> >>>> reasonable skill) for building parts in X, or Y, or X and Z including
> >>>> Footprints, Symbols (not just big squares), and 3D models and/or
> verifying
> >>>> same keeping in mind that it's usually best for building and
> verifying to
> >>>> be done by different persons. What tools would be needed to take
> advantage
> >>>> of those skills.
> >>>>
> >>>> 11. As to the complex boards, I think that is going to be case by case
> >>>> as design/layout/design rules etc are pretty much engineered together
> and
> >>>> difficult to partition within a single board. Generally, the board
> >>>> designer(s) will be using the tools. I'm sure expert advice on best
> >>>> practices for any tool will always be encouraged and well received.
> >>>>
> >>>> 12. As a final note, Eagle/Fusion 360 in  the latest versions have a
> >>>> feature called "Design Blocks" which allow grouping of components and
> >>>> traces to be made and treated as one (other tools also have this but
> it has
> >>>> been notably awkward to do this with Eagle in the past). This adds
> another
> >>>> layer of library-like work. It's especially useful for things like
> >>>> switching power supplies and audio circuits where grounding and
> routing
> >>>> issues are critical. It's valuable to have drop in blocks for such
> things
> >>>> that have been proven all the way to hardware verification (including
> EMC).
> >>>> Generally using these and the 3D fetures requires Fusion as well a
> Fusion
> >>>> user in the Organization that hosts the resources. So there might
> need to
> >>>> be at least one more or less permanent fusion subscription by the
> >>>> organization in addition to whatever month to month subscriptions are
> >>>> required by those that are not already fusion subscribers.
> >>>>
> >>>> As usual - this is only my $0.02 - your mileage may vary - use at your
> >>>> own risk.
> >>>>
> >>>> WU1Y
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Mon, Jul 27, 2020 at 3:51 PM Bruce Perens via Ground-Station
> >>>> <ground-station at lists.openresearch.institute> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Jul 27, 2020 at 9:32 AM Robert McGwier via Ground-Station
> >>>>> <ground-station at lists.openresearch.institute> wrote:
> >>>>>
> >>>>>> I wish to say that the issue of which tool to be used should not be
> >>>>>> dependent on cost or personal ability to pay.  Don't ask me more
> than that,
> >>>>>> but you are entitled to guess all you want.
> >>>>>>
> >>>>>
> >>>>> This is just fine if you are making a decision on behalf of your
> >>>>> university, Federated Wireless, or Hawkeye 360.
> >>>>>
> >>>>> We are Amateurs.
> >>>>>
> >>>>> It is a given that we would be using these tools in a personal
> >>>>> capacity to build experience and achieve our own projects. And then
> using
> >>>>> them in a broader role. Thus, a tool which is in our reach
> financially is
> >>>>> indeed important.
> >>>>>
> >>>>> We also wish to teach with our tools. *Formal* education is not a
> >>>>> mission of ORI because of the need to be licensed and accredited,
> and the
> >>>>> fact that this would have delayed our initial 501(c)3 acceptance.
> But we
> >>>>> still wish to teach through example, through the opportunity to
> >>>>> participate, and all of the things we create.
> >>>>>
> >>>>> When we first got money, we used it to license proprietary software.
> >>>>> This is ironic. It's certainly less than optimal, and we should be
> using
> >>>>> Open Source if at all possible. Decisions to license proprietary
> products
> >>>>> should never be made lightly.
> >>>>>
> >>>>>     Thanks
> >>>>>
> >>>>>     Bruce
> >>>>>
> >>>>>
> >>>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20200727/0015db07/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Ground-Station mailing list
> Ground-Station at lists.openresearch.institute
>
> http://lists.openresearch.institute/listinfo.cgi/ground-station-openresearch.institute
>
>
> ------------------------------
>
> End of Ground-Station Digest, Vol 28, Issue 31
> **********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20200728/9656218c/attachment-0001.html>