LSI/CSI Quadrature Clock Converters LS7083N and 7084N

Hello,

I am working on a project that uses LSI quadrature clock converter. These components allow me to get a clock signal to sample an analog input according to angular position (angular position sampling).

  • The 7083N provide two clocks, one for each direction
  • The 7084N provide a clock plus a direction (suits as input for a basic counter)

I am discovering Fritzing, I hope these first part may be usefull for someone else than me…

Have a nice day,
Mathieu.

LSI LS7083N Quadrature Clock Converter.fzpz (7.0 KB)
LSI LS7084N Quadrature Clock Converter.fzpz (7.0 KB)

It also exist a “new” (?) version of theses ICs, with the 7183N and 7184N. Same functionnality, with little changes in timing caracteristics (see specifications).

LSI LS7183N Quadrature Clock Converter.fzpz (6.9 KB)
LSI LS7184N Quadrature Clock Converter.fzpz (6.9 KB)

I ran the contents of “LSI LS7083N Quadrature Clock Converter.fzpz” through FritzingCheckPart. Here is a summary of what it reported, and what I noticed doing a manual inspection and smoke test in Fritzing. I did not check the others. I expect they are similar.

  • Silkscreen, converted stroke from white to black

    • The new convention is to use black graphics for pcb silkscreen, instead of white. Fritzing automatically converts (and so does the FritzingPartsCheck tool), but for future reference, black is preferred for the silkscreen of pcb svg files.
  • No Fritzing version in fzp file

    • The fzp part definition file does not have a “fritzingVersion” attribute for the module element. The handling of some part details has changed over time (older versions of Fritzing), and the value of the version is used to choose which way certain things are interpreted. A value of “0.9.6” should tell Fritzing to use the (currently) latest rules. Fritzing Parts Editor automatically fills in the full version number. When manually creating parts files, a shorten version is good enough.
  • The part definition shows terminalId attributes for connectors in the breadboard view, which do not actually exist in breadboard svg. If the terminalId is defined, a matching graphic element should exist in the svg.

    • Normally, a terminalId is not needed for breadboard view connectors. Especially when the connections are just header pins. An edge connector might need one.
  • The terminalId elements in the schematic svg are on group (g) elements. That does not work correctly. The connector«n»terminal id needs to be on an actual graphic element. Typically a small circle or rectangle.

  • The connector leads in the schematic svg are 0.2 inches long. The latest convention is to use 0.1 inch leads. If you copied from the generic “IC” part, you got the 0.2 inch leads, but that is outdated.

  • Wires attached to the schematic view connectors snap to the middle of the lead, instead of the end. That is because the terminalId on g elements does not work.

  • The box for the IC in schematic view is bigger than it really needs to be. Even with the part number included as part of the graphics, the width could be reduced .1 or .2 inches.

  • I have not looked at the datasheets, but from the description in the post, these are (mechanically) 4 very similar parts (or 2 pairs). Same pinouts, same footprint. Instead of creating 4 distinct parts, it should be possible to have one (or 2) that is more generic. Exclude the chip label text in the schematic view. The part number property can be filled in when the part is used. Set that for the specific case. Fritzing can be adjusted to include or exclude that from the part label, which can be shown or excluded from each view.

This looks very close to what is created using the generic “IC” part, setting the pin and chip labels. Slightly different text sizes and chip label position.