Here are some Heltec (and a couple of other) Dev Board parts that I created recently. I’ve run them all through the Parts Checker, so at that level they should all be OK, but I’ve not yet been able to get them through the GitHub checking process so I thought I’d just post them here in the interim.
If it is similar to one of the other boards I can make the needed changes for you relatively easily and don’t mind doing so. More parts == more Fritzing users which is good for Fritzing and having you push Fritzing as an option to your community helps us as well.
Sure, go for it. I’ve created the relevant illustrations—there wasn’t much to do there—but following the discussion on GitHub in relation to consistency amongst all the above parts (names and metadata), I ultimately need to free up a bit of brain space to get that right. I have another part requiring similar attention, but I had a couple of other matters to attend to first.
I’ll post the final product to GitHub, but if someone needs a ‘workable’ part sooner, the only practical change required [to one of the WiFi LoRa boards] is the pin numbering.
In my opinion, your parts are fine as is at the moment. We are still working on figuring out what the current standards should be. The ones we have are old, and sometimes wrong, and there is no one left who knows what the original intent of some of the stuff was. We need to read the source code and try and figure out what some of this stuff does (or in some cases is supposed to do, because it may not be implemented yet.) In any case here is a part for the Kit 32 part @EmitWheasel asked for, I’d advise waiting til someone at Heltec has looked the part over because some of the descriptions may be wrong (I think the part should be correct though if you need it in a hurry!)
Now on to what I did to the Heltec WiFi LoRa 32 V2.fzpz part I cloned this from and why I did them.
I first ran the Heltec WiFi LoRa 32 V2.fzpz through FritzingCheckPart.py, its only complaint is that there are missing layerIds for breadboard and schematic (which is correct due to a case issue) which will mean the part won’t export as a svg or pdf, and that the scale on the svgs is wrong (which doesn’t affect function in any way.)
breadboard:
ungroup the svg (needed to rescale it) which had the side effect of deleting most of the pins as they were defined as groups rather than as the id of a circle drawing element. The purpose of rescaling is to make the viewbox conform to the recommendation that one drawing unit be 1/1000 of an inch in the part file format document. Instructions for doing it in Inkscape are available here:
Then I set the text font-size a uniform 25px for all the pin labels and added a text-anchor:middle to the style commands. That way when you change a label you don’t have to re adjust the x position to keep it in the center of the pin. I then recreated the connector definitions that had been groups as the id of the circle for the pin and moved them all to the bottom of the xml editor window. The reason for this is that I have a python script that will allow me to set, add, or modify connectors in an svg as long as they are the last elements in the svg (it also makes finding the pins in Inkscape easier as they are sequence at the bottom of the xml editor window.) Changed the text on the pin labels to match the pin out for the Wife Kit 32 documentation. Resized the svg, edit->select all, then regrouped and named the group “breadboard” (case needs to match the layerId label in the fzp file, in the original part the group label is “Breadboard” which doesn’t match the fzp file.) I also deleted the LoRa connectors and adjusted the components to match the pictures of the Kit 32 on the web site (although the components probably aren’t in the exact right place.)
PCB
Again ungroup and rescale the svg to standard scale. Then using a text editor, modified the pad radius to be 29 (0.078in diameter) and stroke-width:20 to cause a 0.038 hole in the pads. This is the standard hole size for .1in headers, and I assume that is usually what will be connecting to the board. In Inkscape the PCB hole diameter is:
Hole diameter = pad diameter - (2 * stroke-width)
At present I have left the pin labels in silkscreen, but added a text-anchor:middle to each, and reduced the font size to 20px to provide more space between the pad and the silkscreen border. The recommendation is to not put text on the silkscreen, because to remove it the user has to modify the part. If the text is not in the part and the user wants it, they can add it in the sketch without modifying the part. It won’t hurt anything to have the text there except if someone doesn’t want it on the silkscreen for some reason, so I left it there to match the rest of your parts.
schematic
ungrouped and rescaled the svg. In a text editor changed all the stroke-widths to be 10, the terminalId height and width to be 10 (making the terminalId a 10thou by 10thou rectangle) and checked the alignment (which was out slightly because the original values were smaller.) Then changed the text to match breadboard (and the Kit 32 pinout pdf.) Added text-anchor:start (right side pins) text-anchor:middle (center labels and the pin numbers on left and right) and text-anchor:end for the right side pins so changes in text length don’t change text alignment. Resize regroup (and name the group “schematic” to match the svg) and save as plain svg.
fzp file
The part number property is likely wrong, I couldn’t find a part number for the Kit 32 on your web site so left it as the one for the WiFi LoRa 32 V2 which is likely incorrect. The description probably needs some changes too, I changed the LoRa 32s to Kit 32 but I expect the rest of the desciption needs a proper update too (and I don’t know how to make it.) As well when adjusting the pin descriptions I came across this on pins 29 or 30 and don’t know if this is correct or not (it seems likely to me that the two touch numbers should be the same across the different boards, but that may not be correct.):
is “Pin 33, XTAL32, GPIO33, ADC1_5, Touch9” in the LoRa 32 part and as noted I would expect them to be the same (Pin30 has Touch9 and Touch8 in the LoRa 32 part.) I assumed the Kit 32 pinout pdf was correct and used that in the part, but it is worth checking if that is correct. Finally I adjusted the pin numbers for the bus definitions and added a 5V bus to make the buses for this part correct and it is done.
No, I believe that you guessed correctly. I did have to really scratch around to find it myself, because I don’t actually have one of these boards. I had to find an image of the underside of the board, which is where the part number is written.
I would expect them to be the same (Pin30 has Touch9 and Touch8 in the LoRa 32 part.
Yes, I made that observation too, but this is indeed the way it is (i.e. reversed between the LoRa and non-LoRa boards) according to the pin descriptions in the Heltec documents (WIFI_LoRa_32_V2.pdf).
As for all the other stuff, I’m exhausted just reading what would need to be done to all the parts I’ve made in order to ‘fix’ them. I think I’ve at least been consistent, but that just means that all of them will have the same problems. Part of this is that I use Illustrator, with metric measurements and ‘point-sized’ fonts, but I did begin with what I thought to be ‘official’ Fritzing templates, so I would have thought that any measurements of critical components (holes or pad sizes for example) would have carried through. I’ve noticed various ‘grouping’ problems, and some font sizing issues but thought they were just idiosyncrasies of the Parts Editor and dealt with them accordingly. Again, this may have to do with the way Illustrator handles and subsequently exports groups and sublayers—it’s often difficult to visually tell the difference.
For someone in my position, it would help to have a set of templates (just one for each view) that have all the correct measurements (pad and hole sizes), layer/group structure and fonts and sizes in place, with some simple instructions relating to what should or shouldn’t be grouped and any layer or grouping hierarchy that should be observed. I absolutely appreciate the need for things to conform to standards but, as I say, I thought I’d used all the recommended templates, fonts and even colours—obviously I’ve missed a thing or two.
OK. that is the way the part is now so that should be fine.
If it is any help your parts are better than many currently in core parts. At some point (after I finish a new revision of the part check script) I intend on cleaning up core parts, hopefully with automation to make changes easier. As I said, your current parts are better than many currently in core and should be fine as is.
I’m working on something on those lines, but I don’t know how Illustrator handles holes (I know Coral draw is different than Inkscape, and assume Illustrator is different again.) It should be easy enough to list the current common hole sizes 0.035in for ICs, 0.038in for .1 headers, 0.042in for 1n4000 series diodes are the ones I can think of off the top of my head) but we really need a formula for each editor to set a custom hole size, because often the data sheet for the part specifies a recommended hole size, Unfortunately the current templates are in old 72dpi Illustrator with dimensions in px (which causes scaling problems when Fritzing tries to guess the dpi) so they do need an update, it just hasn’t been done yet.
Hey guys,
I really like the new parts introduced in this post. Is there any chance that someone could create a part for the Wifi Kit 8 as well? (https://heltec.org/project/wifi-kit-8/)
Once again, I’ll put it on my To-Do list. I also saw the new CubeCell board released recently, so there are a couple of things there to do now.
I was holding off on making more parts because I’m still trying to sort out exactly what’s required to get everything on the previous parts I’ve done fully aligned with Fritzing expectations. The more parts I make that are ‘not quite right’, the more work I end up making for myself down the track…
What is your primary need? Illustration, schematic or PCB, or all of the preceding? My primary focus has always been on illustration, and it seems that I am falling foul of some of the more specific details associated with other aspects of parts (metadata, schematic and PCB details), which I rarely use.
Hmmm … Maybe we should do some collaboration. I’m comfortable with the technical details of creating parts, and can do the line style diagrams for schematic and pcb. I can create functional breadboard parts, but am no good at making them (or icons) actually look good. See the recent post for Dragino LoRa Shield part creation for a sample. The graphics in that that look any good, I copied from someplace else. Or created from dimensions and straight numbers. I edit the svg files with a text editor, not using Inkscape, Illustrator, Corel, or any other graphics program. That way I get the pieces exactly where I want them based on coordinates.
Hey Pete,
thanks for working on it. I actually only need it for the breadboard view. I just want to illustrate a little setup with the Wifi Kit. Therefore, an illustration would actually do it for my purposes. I don’t need the PCB view.
That was pure luck, really —I had just completed another project and, because I work with Heltec stuff a bit and had already done the other parts, everything was pretty much there. I’m not usually looking for things to do on a Sunday afternoon…
Is it the header pins that won’t fit in the holes, or are the holes in the wrong place? I just used the ‘standard’ pads provided in the Fritzing template, and the pin spacing should be exactly 100 mil—I use the part primarily for documentation, but it fits perfectly on the Fritzing breadboard, so the spacing shouldn’t be a problem…
and having you push Fritzing as an option to your community helps us as well.
—I had just completed another project and, because I work with Heltec stuff a bit and had already done the other parts, everything was pretty much there. I’m not usually looking for things to do on a Sunday afternoon… 
