MCP1700-xx, SOT-89


I have been trying to build the PCB svg for the SOT-89 version of the MCP-1700 fixed voltage regulator. I have had interesting problems.
First, I used the layout suggested in the data-sheet:

I hand edited the PCB, scg file. Starting from a SOT-89 transistor.
I had to make some adjustments, because it seems that Fritzing doesn’t like pads so close to the edge of the device definition, nor pads so close to each other.

Three issues remain.

First, I don’t know how to deal with Pad2, which is the sum of two rectangles.
Also, I get the following errors, which I don’t know how to deal with:

The first two error lines have to do with the two touching rectangles that represent pad2.
I know this because if I comment out one the rectangles, that error message goes away.

Second, the next three lines in the DRC report I don’t know how to resolve – the part is an SMD part, so the PADs should only be on the “top” side. So they are in the copper0 layer. The copper1 layer is empty. What I am missing?

Third, when I associate pads with connectors, I can’t click on the rectangle, if the silkscreen layer is there. The silkscreen layer seems to be above and obscuring the copper layer.

Does anyone have experience designing an SMD part, who has seen these error messages?

Attached is the part

allan Voltage Regulator.fzpz (5.9 KB)


Here is an sot-23 version I made and have been using for a year now.
MPC1700.fzpz (7.1 KB)

For your errors you need to make the shapes merged and not overlapping. Also you need to have your copper1 inside a group called copper0 (or maybe it is the other way around)(one way works and the other does not). Have a look through mine to see the structure for SMD parts.

Edit: One more thing is to check your DRC rules to see if they are set to allow that tight of clearances.

A discussion of future direction

Okay maybe my math sucks but when I calculate the diagonal distance between the corner of the small pad and the closest corner of the large pad using the datasheet it comes out to 0.25mm which is 0.00984252 inches which is smaller than the default DRC rule. In the DRC rules the custom settings start at 0.254mm or 0.010 inches. Professional shops will often go as low as 0.006 inches on their cheap 2 layer boards but be sure to check before changing the settings to match. You could also make the space a little larger or cut the corners off slightly without doing any major harm.


Yes, I saw that and fixed that issue first. I made a modification to the drawing where there was .5 mm of space between all pads, and between the pads and the edge of the frame around the device.
Here is my definition of the rectangles, all dimensions are in mm:


I do all my SVG editing in Inkscape so my understanding of the underlying XML is not that good. But what I do know is your part made up of two pieces would need to be merged into a single object in Inkscape to work correctly.

I would assume that would mean you need to merge GND and pad4 into a single shape.

It also looks to have the contents inside copper1 but they need to be in copper0 which needs to be inside copper1 (or the other way around).

@vanepp could you enlighten us since you are the XML expert around here.


I’ve see my solution by looking at sublimeartistry part.
I replace the two “rect” with a single polygon. I’m working on that now.
Also, I understand what you are saying about copper0 has to be within group copper1
(but the example of the SOT-89 transistor has it the other way.)


As I said one way works and the other complains about being wrong. I am not sure which is the correct way.


I have it completely working now.
One trick is to define the silkscreen layer, in the svg file, before the copper layers. By doing that, the copper layer is “on top”, and pads are clickable when associating them.

Another trick is to use the <polygon> element. The middle pad, pictured below, is a polygon.

Here is my complete svg file, for anyone to look at. It would be nice to integrate this SOT-89 version with the other MCP1700 versions (TO-92, SOT-23, DPAK, etc.). I don’t know how to do that.


actually, I see the above svg file ends up being rendered, instead of being downloadable.
So instead, I’ll export my part and upload it here:

allan Voltage Regulator.fzpz (6.1 KB)

thanks, various experts, for your help.



You can right click and save as and get the SVG but having the entire part is better for anyone that comes along looking for your part.

Glad you got it working now.


While in Fritzing if you click on help > tips and tricks . You will find this useful bit of information (plus a lot more).

This will let you select those pads even when the order is wrong. Although putting them in the correct order in the SVG is the better idea.


Although I’m late to the party and most issues are solved, you can eliminate copper0 from the svg safely, as only copper1 is defined in the fzp file and Fritzing isn’t looking for copper0 (leaving it there won’t hurt anything either though, it will just be ignored). Two minor issues show up in a check of the part with my python script that checks parts (there is a lot more output but most of it isn’t relevant here):

$ part.allan_de273a470d92b745bd63d359f0d8e358_6.fzp

This is a smd part as only the copper1 view is present.
If you wanted a through hole part add the copper0 definition before line 41

… (modified silkscreen colors and reference files deleted)

Warning 11: File
At line 52

Type pad is not male (it usually should be)

Warning 24: File
At line 37

Font family ‘MyriadPro-Regular’ is not Droid Sans or OCRA
This won’t render in Fritzing

Neither of these are fatal (which is why they are warning rather than Error) because you may want to do them sometimes. The connectors in the fzp file should usually be type male, although breadboard appears to be happy (or at least works) with the pad designation (it also only warns about the first one it sees to keep the message volume down, in this case all three connectors are in fact wrong and would be complained about later if only the first is fixed). Fritzing usually won’t render any font except ocra or droid sans although it has either substituted fonts or rendered in this case. If you want another font choice you are supposed to convert it to a path in the svg editor. That is a pain to anyone that needs to change the text later, but sometimes may be necessary if you need a certain font.



ok. i’ll work on these issues.