I’m helping fix up some parts for the FRC robot folks to get them included in core parts. I’m intending on posting the fixed up parts here (as being easier than on github) so the original author can review them, but any of you are welcome to comment as well. The original discussion is here on github:
Unrelated to this part, but of interest: I am currently playing with making my own shaft encoders (the AMT103 is around $35 Can on digikey). I first used the Honeywell HOA0901-011 which was about $15 at digikey, but is now obsolete and $20 from the single source on ebay. Then I found the “Velocimetry Motor 334 line AB phase Encoder” on Ebay for $2.50 ea (unfortunately I bough all that were available at this price, but there are still some in the $3.50 range, still cheap compared to the alternatives). This is a small motor (low torque) with a 2mm shaft, a 334 line optical disk that can be removed (with difficulty!) from the motor shaft and a sensor like the Honeywell part, with active drive and I suspect comparitors on chip on a flimsy pcb that is easy to detach from the motors. This is worth it just for the optical part (which has no part number unfortunately), the motor and encoder disk are a bonus! I’ll probably produce a small board to hold the sensors (I have 3 so far where I destroyed the original board trying to put wires on it 
.) If you want cheap shaft encoders this is a good bet!
That said here is a copy of the first part that has been done, the AMT103 encoder part (in three forms, the original part, the probable final part and an alternative schematic version):
original part
AMT103-orig.fzpz (5.5 KB)
likely part
edit (30 july 2019)
I have replaced this part with one that has the label field changed from enc to cui-enc because with both encoders labeled enc Fritzing creates two copies of enc1 which refer to different parts which is not correct (but will take a code change to fix). This is a simple workaround for this case.
AMT103.fzpz (7.5 KB)
alternate schematic
AMT103-alt-sch.fzpz (6.0 KB)
all three have different moduleIds so you can load all three at the same time if you like. To make things easy without having to download anything, png images of a test sketch using all three parts:
fzp file:
Mostly ok, added reference file and fritzing version to the module line. Removed some unneeded properties and changed the varient from 6 to 1 (as this is the first version of this part). Added a description of the part from the data sheet so it will show up in inspector, added descriptions to each of the pin names so the data comes up when you hover over a pin in any view. Add a url for the part datasheet, added a 1 (for the varient number) to each of the file names (and renamed the files to match after I found a new Fritzing bug when I didn’t rename them the first time . Removed the terminalId definitions from all connector’s breadboard layer line as the terminalIds are not in the svg. This doesn’t hurt anything, Fritzing ignores it but the parts check script complains and it isn’t correct.
Breadboard:
Breadboard was mostly ok, it lacked a layerId (which breaks svg export in Fritzing), needed to be rescaled (as did all the svgs) . I increased the height of the encoder to match the real part (it was a couple of mm short in the original) and copied (probably poorly ) the connector from the encoder datasheet to indicate that it is a shrouded connector. I reduced the pin size to make the individual pins stand out better. Removed unnecessary transforms (possible performance issue, transforms imply a matrix multiplication at every render.)
schematic:
Again rescale the svg, change the units from px to in (px can cause scaling problems a Fritzing will guess at the original resolution 72dpi or 90dpi, I don’t think it knows about the current 96dpi), inches or mm isn’t subject to guessing. Made an alternate schematic with a standard box outline (alt schematic), but it isn’t much smaller than the one with the outline of the encoder and I think the outline of the encoder one is clearer and so should be the choice. Again removed unneeded transforms and unneeded parameters in the xml to reduce size / increase performance. The main user visible change here is adding terminalIds to the pins which corrects the “line terminates in the middle of the pin” problem you see in the original part. Without a terminalId Fritzing uses the center of the pin which looks ugly. I think the size of the original encoder is an example of the scale problem, as both sets of xml should be identical, but the possible part one is set to inches so scales correctly.
pcb, again rescaled and removed transforms. Fairly major changes here. In practice I don’t think it is likely the encoder will be mounted on the PCB. The connector (from the data sheet) doesn’t look like it would fit in a PCB, it is expecting an AMP connector and wires. Thus I replaced the connections with a 5 pin .1 header (and adjusted the hole size to 0.038 in, standard for .1 connectors). I also followed the original developer’s recommendation and removed the text in pcb view. The theory is that if the user wants the labels on silkscreen in pcb, they can add them via the text function in Fritzing, but if they are in the part, the user would have to make a new part to remove them. For reasons I don’t understand, the original part silkscreen renders very poorly in the gerbers (the xml looked pretty normal to me so I don’t know why exactly), I didn’t poke further because I wasn’t planning on using it on the final part. If you see something you don’t like or something I missed, please post here so I can correct it. The final objective is to get this series of parts added to the core parts distribution.
Peter
