Blm03

[Misca1234]

Chip Ferrite Beads serie BLM and BLE

BLE is an alias to BLM

The foot print used are Resistor_SMD

The generic data sheet is here https://www.murata.com/en-global/products/productdata/8796737372190/S0608E.pdf?1519048809000

The specific data sheet is here https://www.murata.com/en-global/search/productsearch?cate=luNoiseSupprFilteChipFerriBead&scon=productionStatus;1_avairable%40In%20Production&rows=100

---

Thanks for creating a pull request to contribute to the KiCad libraries! To speed up integration of your PR, please check the following items:

• [x] Provide a URL to a datasheet for the symbol(s) you are contributing
• [x] An example screenshot image is very helpful
• [x] Ensure that the associated footprints match the official footprint library
• [x] If there are matching footprint PRs, provide link(s) as appropriate
• [x] Check the output of the Travis automated check scripts - fix any errors as required

[Ratfink]

We already have a generic Device:Ferrite_Bead symbol, and plenty of footprints in Inductor_SMD.pretty. We don't need or even want symbols for individual parts like these, just as we don't want specific resistor and capacitor symbols. That would just inflate the library to a ridiculous size for no good reason.

[Misca1234]

So your impression of how to use an EDA is

1. I want the ferrit bed BLM18SN220TH1# because it meets my criteria
2. Open KiCad 2a1 No this component did not exist either in KiCad, f this, I use Eagle instead

2b2 No it did not exist, but I know KiCad presumable have the foot print 2b3 So first I open the footprint editor and scout the foot prints in an attemt to find one 2b4 oh, in Resisor_SMD it looks like it fits, I can not be sure but let me take a chance 2b5 Now do a 'grep * "Resistor_SMD" in the symbol directory to see where it is used 2b6 Oh , it is connected in these 12 places, which one is a ferrit symbol 2b7 Does the symbol fit, well sort of, lets go with that one

Or 2. Open KiCad 3 Oh, the symbol I need is there, super, great

I am not sure how you look at an EDA, if it is just a minimalistic symbol drawing tool for you, if it is, as it seems on your comment, then we can for example, replace all symbols that use a 28 SOIC foot print with one generic symbol.

[poeschlr]

Short answer: Fine grained part management might be better done outside of kicads library structure by a dedicated tool. Just think about how many different resistors there are.

---

Fully specified symbols make a lot of sense but not for everything. (They make sense for things like ics but not really for resistors.) The question really is where to draw the line. I would say evan is in the right here as including these parts would be a bit far. (There are not as many ferrite parts as there are resistors but there are still thousands of them with very little difference.)

Your example with replacing all ic symbols with generic symbols goes into the other extreme. (And i would guess you wrote that to provoke @Ratfink . Please don't do that.) ICs have more differences then simply the ordering information. Each pin has a specific function that differs between different devices (will require a specific name to communicate that function and a electrical type to communicate with ERC)

---

There will always be a tradeoff between lib size and possible part management. There is currently a detailed discussion over at the forum with a lot of useful information: https://forum.kicad.info/t/how-do-proper-parts-components-librarys-what-have-i-missed/9912

---

Currently i would use the inductor footprints to represent a ferrite. ~~They also use L as the reference designator so it would fit:~~ https://www.pcblibraries.com/forum/ferrite-bead-symbol-and-reference-designator_topic2271.html (Edit: it seems FB is in newer standards.)

One option would be to have a specific ferrite footprint library. The two terminal rectangle footprints could easily be generated using the generator script https://github.com/pointhi/kicad-footprint-generator/tree/master/scripts/SMD_chip_package_rlc-etc

This would allow specialized footprints to be added if there are ferrite parts that do not use a standardized package. It would also make it easier for people to determine which footprints to use. (If they don't make the connection between inductor and ferrite bead.)

The footprints would then be called FB_...

[jkriege2]

I personally think haveing some of these specified symbols does not really hurt, if they are in a separate lib (which the ones in this PR were ... filter.lib was the best choice from what was available IMHO). I also think that they are convenient, if you already know which one you want to use during schematic input. If you don't, the generic symbol from device.lib can be used. Finally lib-size is (IMHO) not so much of a concern here.

I agree that I wouldn't do this for resistors (maybe at most have symbols R_0805, R_1206, ... for convenience), but we do it for diodes and some LEDs and at least. I'm also not sure where to really draw that line, but rejecting these symbols as harshly is surely not the way to go (I think). In the end this PR at least shows that there are some users that see use in such symbols and also they were not added for each single value, but for whole series (using wildcards).

So to conclude: I would allow such series-generic devices in the lib. For the symbol, I would like to see the standard symbol from device.lib: or (then we would also need to change the symbol in device.lib) the one I found in a summary of the IEC-60617 standard:

Just my 5 cents, JAN

[Ratfink]

I see now that I was too quick to close this, and for that I apologize. I stand by my earlier statement though about individual ferrites being a step too far. I don't think I'd be the right one to reopen this PR either, and I don't know if there's enough consensus for that to be the right move yet. If the consensus of the library team shifts towards including individual ferrite symbols, I offer the following input; please don't mistake this for a shift in my own feeling.

I agree with @jkriege2 that if these are included, they should use the same symbol as the Ferrite_Bead in Device.lib (regardless of whether we change that symbol or not, these should match it). Also, resistor footprints are definitely wrong here. As @poeschlr says, ferrite beads are a type of inductor, so should either use inductor footprints or maybe a new library for ferrites.

I'm not sure how I feel about putting individual inductors, if they are to be included in the library, in Filter.lib. If inductors can be included there, we'd have to allow capacitors in Filter.lib as well, as they can be used for filtering. As I see it, that library isn't for passives, but for more complex devices, like the SAW filters it currently contains. With this many symbols being added, I think it would be okay to follow the lead of the diode or transistor libraries and put these in a new library for inductors.

@Misca1234 Re-reading your comment, I feel like nearly everything you wrote was intended to provoke me. Please try to be constructive, rather than trying to start fights. 🙃

EDIT: I really only meant the above paragraph to mean that whether you meant it that way or not, your words felt hurtful to me. I certainly wasn't upset with you or trying to escalate anything, just trying to air my own feelings on what you wrote and asking you to avoid potentially hurtful argumentation in the future.

I'll bow out of this discussion now, as I have nothing further to add to the important part and I'm afraid of unintentionally continuing the bad part. I really just want us all to be polite and get along, and I'm deeply sorry for hastily closing this PR.

[Misca1234]

I have a strategic goal with my engagement in KiCad, which is far beyond to get a couple 100 people to work on their spare time for making me a personal tool.

My strategic goal with KiCad is to contribute to a tool that people will choose in first hand and/or a tool that is so strong so people can argued for it to even replace licensed EDA's already used in an organisation.

I have hard time to see that there should be a goal in itself to create a minimalistic EDA where you need to fix and trick to get what you want, or have, on forehand, knowledge about what foot prints exist or not, and which one I should select in combination with what generic symbol.

If KiCad have the strategic goal to be widespread and/or replace licensed EDA within an organisation then the approach should be

• As large symbol libraries as possible
• Good support for the 3D library

Now, some people would argue that the foot prints are most important, well, they are, but that is expected, a person who argue for an EDA with largely faulty foot print would be in a bad position.

If people find a large support for symbols and good visualization then KiCad is in a position to be argued for. KiCad will be judged on the first experience of the tool, that is, the symbol support.

Do anyone think that KiCad would be accepted with arguments like -Yes, there is no component support and no 3D but I guess that must be supported in some way. Companies do not have a very large threshold to pay license fees if the alternatives are so bad it does not even have

So if your goal is in line with mine, your should do as I do,

1. At work, write down all different components that the people are using in their constructions (in other EDA's) and then immediately add them to KiCad.
2. Scout and scan the internet for constructions and design and add symbols to KiCad if they do not exist.
3. If you find a symbol in KiCad that have missing variants, add those.
4. Make 3D models, even on "commission" for others that can not make them
5. Clean up libraries
6. Hijack months old abandoned pushes and fix them
7. If you add a symbol, always add the 3D model.

@Ratfink "I feel like nearly everything you wrote was intended to provoke me. Please try to be constructive, rather than trying to start fights." Yes it was, because your strategic goal with KiCad is very different from my goals. and the analogies I wrote was to highlight the downsides with your minimalistic thinking.

[jkriege2]

Guys!

Cool down a bit! Throwing back and forth accusations willl not help anybody, but will just lead to annoyed people all around.

---

I think everybody will have to accept that different volunteer will have different views and ideas of how a software should be ... and we will have to agree to disagree on some points. Still I think in this case, starting a broader discussion (especially taking into account the amount of work that went into this PR) would have been the way to go. On th other hand it is difficult to be presented with a "strategic goal with KiCAD" that someone might wish the project to work towards, if the goal is not recognized in the community. So far the idea of the official KiCAD libs was to value quality over quantity, as we feel that we don't have the ressources to achieve both (@Misca1234 I know you want to achieve both and have done some tremendous additions to the lib already). So far my experience was also that we are a quite nice community that is helpful and respectful to all people and that we encourage everyone to participate in this project and to openly discuss issues and questions. In the end we all have the same goal to make KiCAD as good as possible (but again: We are all volunteers and I don't see how we could achieve a comprehensive library with the ressources at hand, especially I don't see that such a lib would be manageable in the future ... thinking of converting to the new fileformat and also bug-fixes ... and ensuring the quality by a thorough review of new symbols that would have to flow in in masses to achieve the proposed huge library).

---

Now for the actual matter at hand: I stated my opinion on the topic above already, but would want to repeat it, as I think that would be a viable way to go:

• Series of inductors would be fine for me, especially since there is a wide variety of different footprints and I also think it's easier to find them directly by name/MPN when doing the schematic (I feel that inductors are more likely selected by MPN than by simply saying that I want an inductor of 100µH)
• For e.g. resistors I feel that they are more exchangeable and more standardized, so there I wouldn't go for specific symbols or series symbols.
• Therefore: I propose to allow for series-type symbols (as the ones in here) for such devices.
• The even better option would be some means in KiCAD that allows to have a generic symbol + a table with properties+different footprints for them, then one could select the generic and will then be presented with a list to choose from (or add a new one). But I don't see such a tool currently on the horizion, so the only alternative would be atomic symbols that would then for sure blow up this library to an unmanageable size (I'm thinking about bug-fixing ...)

Best, JAN

PS: @evanshultz @poeschlr @CarlPoirier What do you think on this topic? should we accept these symbols? PPS: Iff we accept the symbol, please do the following changes:

1. use the standard symbol
2. Please use the L_... footprints from Inductor_SMD.pretty
3. Please put them into a new library Inductors.lib, or Inductors_FerriteBeads.lib
4. Please use a lower-case x as wildcard in the symbol name

[jkriege2]

PS: Until we come to a conclusion I will reopen this PR ... pending a final decision on the greater matter!

[poeschlr]

@Misca1234, @Ratfink, @evanshultz, @jkriege2

After thinking about this (and reading the opinion by @jkriege2) i retract my previous assessment of not allowing these.

I think the lib is generally going towards using more and more fully specified symbols. At some point the device lib will be mainly there as a starting point and to help beginners dive into kicad.

Whatever conclusion we reach here should also be codified in my klc clarification: https://github.com/KiCad/kicad-website/pull/272

I assume everyone in the maintenance team will want the line drawn at a different point. I guess jans proposal is a good compromise.

[evanshultz]

I agree with Jan and Rene, and here is the reason: Ferrite beads often have significant effects to EMI/EMC. Products with an FCC badge likely cannot easily exchange ferrite beads without re-testing/re-qualifying products. The exact MPN used may be material to product operation or behavior. Resistor and chip capacitors, most often, can have many alternate sources without issue and far less verification. Again, this is my personal opinion and experience but doesn't cover all cases.

Ferrite beads have a few common footprints, and then loads of parts that fit those footprints which vary primarily by their impedance vs frequency curve. So we should be able to have just a few symbols with a ton of ALIASes. The DCM files will be inflated, but fortunately it's a relatively small amount of text to add a new entry there (as opposed to a whole new symbol in a LIB file).

Inductors store energy while ferrite beads do not. They are commonly joined together, but I think they should be separate schematic symbols. And using IEC symbols in KiCad is quite clear.

For footprints, putting them in Inductor_SMD.pretty isn't objectionable to me unless there are so many footprints in that repo we want to split them up.

So in summary, I agree with everything Jan said except item 3: I think FerriteBeads.lib is a better name because they aren't inductors. If that's done, adding unique ferrite beads from Murata seems like a worthwhile addition to me.

[jkriege2]

OK,

so I think we came to a decision.

@Misca1234 would you do the required changes:

1. Move symbols to FerriteBeads.lib
2. Use the standard symbol from device.lib
3. Use the L_...-footprints from Inductor_SMD.pretty
4. Use lower-case x as wildcard in the names.

Then I can merge!

Thanks, JAN

[jkriege2]

@poeschlr : Since you're rewording some of the KLC in that domain anyways (https://github.com/KiCad/kicad-website/pull/272) ... could you find a wording encompasing inductors, diodes etc. (I think the resoning given by @evanshultz is quite good)?

[jkriege2]

@Misca1234 Will you still work on this, along the suggestions/disscussion results above?

Thanks, JAN

[Misca1234]

@jkriege2 Not at the moment, I have a number of open pushes and is only spending my time to get one or two finished at the same time, this is currently not one of them but it is in the stack.

[Misca1234]

Changed the symbol Moved to Ferrit_Bead.lib Removed BLM32, seems to have been removed from their homepage

[evanshultz]

• I'm not sure about the datasheet. For BLE02xxxxxxx1x, the link doesn't list any matching parts. Is there a datasheet or better link you can use?
• Furthermore, page 10 of https://www.murata.com/~/media/webrenewal/support/library/catalog/products/emc/emifil/c31e.ashx?la=en doesn't show BLE series in any size but BLE32. Neither does DigiKey.
• Can the PNs be more specific? For example, BLE32PNxxxSN1 vs just BLE32? See https://www.murata.com/en-us/products/productdata/8796742844446/ENFA0047.pdf. You mentioned above about you desire to search for the exact MPN so can you add more detail without losing any generalization?
• You don't need SMD size in the description.
• I don't see them as filters by themselves, so I'm against putting /Frequency Specified Filters in the description.
• The keywords seems excessive and not specific enough to help a user find just these parts.
• Why are pin numbers visible? That doesn't seem required to me since a FB isn't polarized.
• Ref des should not start with "U".
• Should we have a FB footprint repo? Some inductors come in chip sizes too, and I'm more against it than I am for it, but figured I should ask before anything is merged.
• While it's probably not a big deal, since we've discussed for chip parts that the American sizes are the most common, could/should the footprint filer change from L*01005*0402Metric* to just L*01005?

[Misca1234]

When I remade them last night I notice that the old url's did not work any longer so I changed them, but apparently I did not change them all, I change the other stuff

[Misca1234]

Should we have a FB footprint repo? Some inductors come in chip sizes too, and I'm more against it than I am for it, but figured I should ask before anything is merged.

The manufacture used the "ordinary resistor sizes" so i guess they don't want to add new foot prints.

[evanshultz]

• IEEE315 says the ref des for "ferrite bead rings" should be E. L lists "coil (all not classified as transformers)" and also "inductors". It seems like L is the best choice, but let's make sure.
• Since our footprints is named L_0603_1608Metric for BLE18PS080xx1x, I think it's best to put 0603 in the description or, slightly less favorable to me 0603 (1608 Metric). Just putting 1608 is going to be misleading I think.
• Is the 3rd character just something to wildcard too? It is important to have separate symbols for BLM and BLE parts? They seem close enough to me that with any wildcarding they can be combined.
• Further, maybe package is the key thing to break these symbols up by since that is what would make the LIB file unique (the default footprint and footprint filter). Perhaps generalize as much as possible while sticking all parts that share a common package into one common symbol?
• I'm lost how "The manufacture used the "ordinary resistor sizes" so i guess they don't want to add new foot prints." is a response to my question. I'm asking if a new footprint repo just for ferrite beads should be created.

[Misca1234]

I'm lost how "The manufacture used the "ordinary resistor sizes" so

You was speculating if we should create a Ferrite Bead footprint repo so i responded to what they write in the data sheet and that they use the "ordinary/standard resistor sizes" which would mean that a creating a specific Ferrit Bead repo might be unnecessary because the manufacture make the components to fit the "ordinary/standard resistor sizes".

Is the 3rd character just something to wildcard too?

You thinking of the E and M in BLE/BLM ?

[evanshultz]

You thinking of the E and M in BLE/BLM ?

Yes, that is what I was thinking about.

[Misca1234]

Is the 3rd character just something to wildcard too? You thinking of the E and M in BLE/BLM ?

They use different foot prints so reducing the symbols even more would mean that the user must rely on CvPcb for choosing correct foot prints.

I think it's best to put 0603 in the description or, slightly less favorable to me 0603 (1608 Metric). Just putting 1608 is going to be misleading I think.

You are right, the imperial code messes things up with the 0402 size, I change the description by adding 'Metric'

[evanshultz]

Wow. A blast from the past...

1. Since Imperial units are more common all over the word for chip parts, as I understand, why not put both sizes so it's most helpful to all KiCad users?
2. BLE and BLM use different footprints? https://www.murata.com/en-global/products/productdata/8796737372190/S0608E.pdf?1519048809000 doesn't mention any restrictions. Searching for 0603 beads at https://www.murata.com/en-global/search/productsearch?cate=luNoiseSupprFilteChipFerriBead&scon=emiSupprFilteFilte-sizeCodeininch;0603 turns up both BLE and BLM MPNs, but not for 0402. So you mean that each part type comes in different sizes that don't fully overlap? If that's what you mean then I get it and I'm OK with separate symbols.
3. In fact, the above link to the part search table shows there are BLM parts in 0603. Did you not want to include them?
4. Rene said somewhere that ferrite bead ref des should start with FB.

General question: Why not just go with BLE32 and BLM15 and leave off all the xs? It seems like the PDF link above those aren't important if we're not doing fully classified MPNs.

[antoniovazquezblanco]

Closing and reopening as CLA has gone mad and is showing this as not signed when it was clearly signed time ago.

Also ping @Misca1234 just in case he has forgotten about this.

Sorry for the annoyance.

[evanshultz]

@Misca1234 ?

[Misca1234]

Ohhh, not sure if I should continue with this one, having a period of inactivity atm Perhaps I should restart it

[evanshultz]

What's the reason? If the branch conflicts are resolved I have no problem continuing with this PR.

[myfreescalewebpage]

Agree with @evanshultz, please @Misca1234 continue on the same thread to keep history of the comments made by previous reviewers. Thanks, Joel

[Misca1234]

Conflict solved

[evanshultz]

@Misca1234 Thanks. I don't see any response to my comments at https://github.com/KiCad/kicad-symbols/pull/369#issuecomment-428332588, if you want to close all open items here.