28BYJ-48 Stepper Motor and ULN2003 Driver Module

hi there!

I just finished these two fritzing parts to correct many of the issues that other similar available parts have: incorrect dimensions, no JST connector, missing pins, incorrect wiring, incorrect naming, etc.

They are available at https://github.com/mgesteiro/fritzing-parts
And here the fritzing example in the picture: 28BYJ-48-driver_and_motor.fzz (42.6 KB)

As you can see, they look and connect nicely (and correctly).

I used the @vanepp FritzingCheckPart tools to validate them, but let me know if anyone discovers any issues with them.

best regards!

Nice job, although with a few issues. I assume because the stepper has female pins you were hoping to be able to connect the stepper to the module in breadboard and have it connect. Unfortunately the current breadboard doesn’t align on 0.1in boundaries so that doesn’t work. I moved the connectors in breadboard slightly so they all align and now that works:

then move the motor over the connector on the module

still no connection (the pin is red, not green) so you have to move the module left then back to get it to connect

now we have a connection (green pins) and rats nest lines in schematic

(you will also notice the motor schematic looks quite different to ccomodate this connection!) I also modified both the pcb svgs, in the module I removed the text as text can be added in the sketch (but the user has to change the part to remove text included in the part which is why text isn’t recommended in parts!) As well I moved the connectors to their real positions and added circles for the mounting holes in silkscreen (again if the user wants the mounting holes they can drag a hole part in to the sketch to produce them, if they are in the part the user has to change the part to remove them!) In the motor the holes were slightly to large so I set them to the standard 0.038in for header pins. Here is the complete test sequence of the two parts (including gerber output)

and the output gerber files for the sketch.

and finally the two modified parts

28BYJ-48 Driver Module-improved.fzpz (17.3 KB)

28BYJ-48 Stepper Motor-improved.fzpz (8.3 KB)


Thank you very much for your report @vanepp: I’ve updated the parts taking into account your changes/suggestions, although not all of them, as I consider some to be overcorrections:

  • You removed my Icon view for the motor, which was different from the Breadboard view.
  • The JST connector has a pitch of 2.50mm, not 2.54mm(0.1in) as per your corrections.
  • The motor schematic symbol has been updated following your idea but respecting my own original drawing and accurate info (which coil lead connect to where, naming, etc.).
  • In the driver schematic symbol I decided to keep the whole name to differentiate it from the ULN2003 IC: it’s a module, not a breakout board.
  • Your SVGs contain metadata (Illustrator?).

I also updated the fritzing file example: 28BYJ-48-driver_and_motor.fzz (36.8 KB)

Now, some aclarations:

My original part worked fine: it was NOT a problem of alignment (did you try the attached FZZ file?) but, as you mentioned, a question of pins genre. The spacing was not perfect (now it is as I sacrificed/traded accuracy for usability), but it appears that Fritzing assumes female pins to be in the bottom (because of the breadboard?) and male pins on top when you drag some part into another (to connect), so the weird effect result is that you had to connect the driver board to the motor, and not the other way around. It was unnatural so I swapped the pins genre in the JST-connectors for both the motor and the driver and it’s easier now (again, traded accuracy for usability).

I didn’t find this. What I saw instead is that you changed the JST connector pins from 2.50mm to 2.54mm(0.1in), that was not a problem anyway.

I won’t use Fritzing to create PCB’s (I use KiCAD) so I followed your recomendations there, although it doesn’t make any sense to me to use the PCB footprints for this two parts, especially the driver itself, as it is a module with THT components that won’t fit in a PCB (but I’m no expert in these matters :man_shrugging:)

Best regards!

Inkscape, but nothing unusual (at least for Inkscape, and no where near as much crap as Inkscape adds if you let it save as an Inkscape file rather than plain svg!) and nothing that Fritzing objects to.

Yes, but as you note I was moving the motor not the interface board and that indeed does not work. I agree if I move the interface board then it connects correctly (and I think that is a Fritzing bug as it should be symmetrical)

I would agree, but it was there, so I corrected it. Even if it doesn’t make sense I often add pcb with at least header pins so if someone wants to include it in a pcb they can (presumably by connecting wires from the connectors.) If I’m lazy I suppress pcb view.


It was for me: my inkscape doesn’t generate those metadata fields, that’s why I doubdted :thinking:

Out of curiosity, I’ve been looking around and you produce a lot of parts: would you mind sharing your process of part creation/editing? (tools, steps, environment…) I’m specifically curious about how do you test small changes, because for me it is very time consuming just the simple repetitive steps that go from “updating the svg” until you can actually check the part in Fritzing. Maybe I should start a topic just for this subject…

fair enough.

another interesting question: how do yo generate the SVG line elements (used in the connectorXXpin parts of the drawings)? Inkscape can’t produce them (although, oddly enough, can manipulate them…).

best regards!

This series of posts

describe what I do. I have some tools (some published on github some not) that will create fzp boilerplate for connectors, (FritzingCreateFzpConnectors.py on gighub) and these 3 which need more work before they are ready for prime time


SvgRenumberConnectors.py renumbers connectors in an svg. At present I modify the python code to do what I need on the fly, that needs to be generalized so it can be controlled from the command line.


These two (SvgSetConnectors.py for schematic) and SvgSetConnectorsbb.py for breadboard and pcb) take an svg with the connector pins at the bottom of the svg, with the first connector labeled connectorxpin (I think connector anything works) and assigns the pins sequentially. SvgSetConnectors.py looks for a line followed by a rectangle (pin and terminal) where SvgSetConnectorsbb.py looks for only the connector and assumes everything after it is another connector. This allows me to move the pins and terminals in order in a svg without typing the pin numbers then run the svg through one of these to create the correct pin numbers. On large parts that saves a lot of time. Again the two scripts need to be merged in to one with command line options to control behaviour (after I finish the new version of FritzingCheckPart!)

I don’t know of any shortcuts here. This is usually the most time consuming part and is covered in

in the tutorial series. Hopefully more can be done in FritzingCheckPart eventually, but I am having enough trouble just updating it to not have false positives so it can front end parts submission on github. A number of places it will sometimes complain about something that is in fact fine. For its original purpose, that is fine because the output goes to a human, but as a part of automated part submission, it is not.


Forgot this one:

Yes the line is an Illustrator construct but I like it. Both copy/paste and duplicate in Inkscape will deal with line, so I copy / paste from an svg that has one if there isn’t one and duplicate to get more once I have one. The schematic template uses them already and I often replace schematics with a copy of the template (which is the correct scale with the correct pins and terminalIds and the correct colors to match the graphic standard) instead of trying to correct an existing one in Inkscape.


Thanks for all the details @vanepp: you are long way before me (and suspect than most of us too :sweat_smile:)

I like that approach of self-made tools to optimize (or sometimes even solve) the tasks: reminds it to myself.

Best regards!

Linking this behaviour…

to a relevant github issue here: