Calliope Mini Rev 1.3

[HaraldRau]

Fritzing crashed by routing the part "Calliope Mini Rev 1.3" from nightlyParts. I use LINUX with a portable installation! The application window closes with the error message: Segmentation fault (core dumped)

The graphics for the breadboard has a serious error. At the short PIN header is one PIN too much. Not 6 PIN but 5 PIN are correct.

The names of the PINs do not correspond to the official documentation.

I try the following:

1. I extend my part to the missing connections.
2. I use the version "Calliope Mini Rev 1.3" from the NightlyParts.
3. I am putting this version up for discussion here!

I hope i can help to fix the Part.

[el-j]

can you please share an example sketch. i tried some routing without this error ... thank you (attache a .zip to the fzz so you can uploade it here (; )

[HaraldRau]

hier ist the sketch. i hope you can route it!

Greeting! wetter.fzz.zip

[HaraldRau]

i was looking for a clean svg-file. Can you confirm thise three files as clear?

max485_breadboard.svg.zip

max485_pcb.svg.zip

max485_schematic.svg.zip

When the file are clear, i will edit the file "Calliope Mini Rev 1.3" for this template!

I delete the TerminalID in the file. The termilal direction can defined by the parts editor.

[HaraldRau]

The first Result: Calliope_Mini_extended.fzpz.zip I must now check all connectors and test the routing!

Can you check, if he work with Windows?

[HaraldRau]

upgrading version:

• direction of the PIN corrected
• interne connection added

Calliope Mini.fzpz.zip

[el-j]

i checked this version. nice work so far but it is not possible to put more than one connector over each other in pcb-view. the problem: in the export the gerber will have multipel drills in every location connectors are stacked. so it is not possible doing this.

but: if you do not need the other connectors like the pads and the big-donuts the nightly part is corrected in 5min. the problem with my version is, that pads and pins are together in a bus. if you remove the bus from the part it is working. anyway if you just need these headers you use in your part. i can change the nightly version.

[HaraldRau]

ah, my mistake. Of course this is not possible in the pcb! In the pcb I only need the PIN header 2x13 and 1x5! I want to develop shields for Calliope.

[HaraldRau]

Newest try:

• i replace my pcb-file with your pcb-flile from the eagle-file source

• i connected all 45 links on the pcb

I hope the gerber-file is now usable

here is the package:

Calliope_Mini_final.fzpz.zip

[el-j]

did you measure the size of the outline in pcb-view? because the nightly part is smaller than your version and would like to use the right measurement ;)

[el-j]

@HaraldRau so for me the autorouter is working now. can you please check the size of the pcb view? lets work out the nightly part version. do you understand how you can participate directly with the git push and pull logic?

[el-j]

ok ... i had another crash... i am not sure if it the part or the autorouter...

[HaraldRau]

I check the distance by adding a OP37-chip. Is the Methode correct?

[HaraldRau]

but i'am sorry. I can not push the part in the nightlyPart. I develop the Part outside of the System-Part-Folder. Can i send you the Export-file?

[vanepp]

While I'm github (I find it ironic that the spell checker on github thinks github is misspelled) challenged and thus a poor one to comment, it shouldn't matter where your part is to push it to nightly parts. You need to clone the nightly parts archive in to your github account, then unzip the fzpz file and copy the fzp file in to path_name/core, for me using cygwin on windows I have /cygdrive/d/repos/fritzing-parts-nightly-build which contains:

$ ls fritzing-parts-nightly-build bins CONTRIBUTING.md LICENSE.txt README.md svg contrib core obsolete scripts user

of which

fritzing-parts-nightly-build/core fritzing-parts-nightly-build/svg/core/breadboard fritzing-parts-nightly-build/svg/core/breadboard fritzing-parts-nightly-build/svg/core/icon fritzing-parts-nightly-build/svg/core/pcb fritzing-parts-nightly-build/svg/core/schematic

are important. From your fzpz file unzipped:

$ ls /cygdrive/d/fritzing-backup/imported-parts/Calliope_Mini_extended part.Calliope_mini_pcb_extended_bdfd4d440253b87d1073a2c160e70c98_7.fzp svg.breadboard.Calliope_mini_pcb_extended_bdfd4d440253b87d1073a2c160e70c98_11_breadboard.svg svg.icon.Calliope_mini_pcb_extended_bdfd4d440253b87d1073a2c160e70c98_11_icon.svg svg.pcb.Calliope_mini_pcb_extended_bdfd4d440253b87d1073a2c160e70c98_11_pcb.svg svg.schematic.Calliope_mini_pcb_extended_bdfd4d440253b87d1073a2c160e70c98_11_schematic.svg

you need to copy

cp part-dir/part.Calliope_mini_pcb_extended_bdfd4d440253b87d1073a2c160e70c98_7.fzp repo-dir/Calliope_mini_pcb_extended_bdfd4d440253b87d1073a2c160e70c98_7.fzp

Note that the preceding "part." in the source directory has been removed to convert from fzpz format to directory format. Then the 4 svgs to their respective directories in the repository: cp part-dir/svg.breadboard.Calliope_mini_pcb_extended_bdfd4d440253b87d1073a2c160e70c98_11_breadboard.svg repo-dir/svg/core/breadboard/Calliope_mini_pcb_extended_bdfd4d440253b87d1073a2c160e70c98_11_breadboard.svg

The formatting here is lousy, I'm also markup language challenged. These should all be one long line. I shortened the paths to part-dir (should be /cygdrive/d/fritzing-backup/imported-parts/Calliope_Mini_extended) and repo-dir (should be /cygdrive/d/repos/fritzing-parts-nightly-build/ but it didn't help much.

This time the svg.breadboard. is ommitted for the same reason. The other 3 svgs are the same. Then comes the part I have trouble with: you need to push this to your copy of the repository on github (easy, just git push), then make the pull request on the nightly-parts repository (which I'm not entirely sure how to do).

Peter

[vanepp]

I should first note this is just how I make parts, we haven't yet come up with the specs that future development will use, but I will be aruging for this, unless there is a good reason to do something different.

file max485_breadboard.svg (max485_breadboard.zip on github, I assume github doesn't accept svgs in the comments)

Copy and rename max485_breadboard.zip to

imported-parts/max485_breadboard.svg

first issue:

Scaled wrong

In Inkscape

Edit->preferences->Behaviour->Transforms

make sure

Scale stroke width

is ticked (I usually want it unticked so Inkscape does't change the stroke width when extending a line).

Using xml editor

ungroup

til there aren't any groups any more. The re scale works poorly with groups (it inserts transforms which are undesirable)

edit select all

record current size in px (max resolution) from the tool bar:

0 0 38.400 41.280

document properties->Scale is 1.04167 currently, change it to 10.41667

part shrinks in size a lot.

edit select all

change toolbar y from 37.152 to 0

change toolbar width from 3.840 to 96.800 (from the original drawing above)

change toolbar height from 4.128 to 129.393 (from the original drawing above)

You sometimes have to do this several times as Inkscape moves the origin and changes the width or height sometimes, I don't know why (it is however very annoying!)

Now the drawing is at the desired 1/1000 scale called for in the parts file format document.

What this changes is the first element in xml editor. The original has:

height 0.43in

(good, units blank or px is bad, as Fritzing will guess at a scale and often gets it wrong.)

width 0.4in

viewbox 0 0 40 43.00014

the new one has

height 0.43in

width 0.4in

viewbox 0 0 400.00014 430.00012

Edit->preferences->Behaviour->Transforms

untick

Scale stroke width

again for normal operation.

ignoring the floating point round off errors (the trailing .00014 and .00012),the ratio of the new one is 1/1000 as called for in the part file format document. Having a constant scale makes automated part checking easier (we don't have to recalculate the scale all the time).

The only other issue is the text. It is currently an unknown font encoded as a path. Sometimes (because you want a specific font that Fritzing doesn't support) this is ok, but as a template it is preferable to have one of the two supported fonts. In this case from the graphic standard, for an IC that should be OCRA and 5pt font size 5pts works out to 89.03997803 px (which Inkscape font size is in) so for ease of remembering and efficiency, I used 90px as the font size. I changed the text anchor from text-anchor:start to text-anchor:middle so the label is centered and will grow both ways (to stay centered) if more text is added. The label has id label so Fritzing will substitute the text from the Title field in the fzp file (and the metadata tab in the new parts editor) for the text IC (which it can't do with the path). As well someone wanting to clone the part can easily change the label if it is text. Everything now looking fine, I then did

edit-select all file->document properties->Custom Size-> Resize page to content

then

Resize page to drawing or selection

to change the viewbox to surround the entire part. If you don't do this, anything outside the viewbox gets trucated. On bendable leg parts, you need to be more careful because the legs need to be outside the viewbox in order to work (but that isn't an issue here).

Now with everthing selected

Object->Group

to create the layerId group which needs its id set to breadboard

File save-as->plain svg

saves the file to disk and we are finished with Inkscape. However two problems remain: because of the CSS standard (which Inkscape obeys) all font-sizes are in px. Fritzing doesn't like the px in a very bad way. As long as you load the part (but don't edit it with parts editor) the fonts are fine. If you edit the part with parts editor the font size gets set to zero and your text disappears. As well Inkscape uses the style command in the xml. Bendable legs don't work with style commands. To solve both those problems (and to find anything else I missed) I run the resulting svg (and eventually the entire part from the part.device.fzp file) thorough my part check script which removes the px from the font-size, converts style commands to the equivelent inline xml and does a variety of other checks (many of which don't apply in breadboard).

FritzingCheckPartw.py max485_breadboard.svg

produces:

Modified 4: File 'max485_breadboard.svg' At line 30

ReferenceFile

'generic_ic_dip_8_400mil_bread.svg'

doesn't match input file

'max485_breadboard.svg'

Corrected

Modified 1: File 'max485_breadboard.svg' At line 209

Removed px from font-size leaving 90

Warning 34: File 'max485_breadboard.svg' At line 63

translates are undesirable.

(you won't see the Warning 34 message from the current part check script on github this is a development version that I'm working on).

This tells me that it removed the px from the font size on the text (it also inlined all the style commands but silently as there are too many of them). It found the reference file wrong and corrected it (but nothing in Fritzing as far as I know cares abouth the reference file). The last one is warning me there are translates which should be removed for perfomance reasons, but in this case that isn't easy to do. We (the developers) need to find an automated way to do that. If (as I often do) I had forgotten to regroup and set the layerId, I would have gotten this message in the script output:

Error 69: File 'max485_breadboard.svg' At line 39

Found a drawing element before a layerId (or no layerId)

The only bad effect from no layerId I know of is that the part won't export as a pdf, svg or other format from the export menu, but that is annoying enough as it causes questions in the forum about why this part is missing in the pdf. So all that said here is the file I would use as your template (the one created above):

max485_breadboard-fixed.zip

Now I'll move on to the others (although, that may not be til tomorrow at this point).

Peter

[vanepp]

I just came back in and decided the tempaltes are a longer term problem, and downloaded Calliope_Mini_final.fzpz. It isn't yet ready to be pushed I don't think (although Fritzing loads it). The check script can't parse the fzp file (and it is usually a pretty good judge of valid xml). It is objecting to this at the end of the description field:

text-indent:0px;">^@</p></body></html> ------------------^^

with the "^@" removed it parses. However then the errors start flowing: some are informational or harmless, but this isn't:

Modified 6: File 'svg.pcb.Calliope_mini_cb68f829b4eb11fc3122f1bd5a9c956e_6_pcb.svg.bak' At line 149

Added inherited stroke-width value

Modified 6: File 'svg.pcb.Calliope_mini_cb68f829b4eb11fc3122f1bd5a9c956e_6_pcb.svg.bak' At line 175

Added inherited stroke-width value

This is indicating that the script added a missing inherited stroke-width which is legal xml, but fatal to the gerber generator (which doesn't do inheritance). These pads (and there are more of them) won't generate a hole in pcb unless run through the check script (which is telling me it corrected the problem). This is usually caused by optimized xml in Inkscape which doesn't work well with Fritzzing. As with the template file, the svgs are at the wrong scale. They will work, it is just preferred they get corrected, I'll do that on the way by because I'm used to doing it. The bus configuration is not right (probably left over from the part this was cloned from which looks to be the raspberry pi). I'll fix that up too. Looks like breadboard is missing a layerId:

Error 69: File 'svg.breadboard.Calliope_mini_cb68f829b4eb11fc3122f1bd5a9c956e_6_breadboard.svg.bak' At line 468

Found a drawing element before a layerId (or no layerId)

there look to be connector problems:

Error 18: File 'part.Calliope_mini_18e1f312913c8c9c43b618584bd40d02_3.fzp.bak'

Connector connector0terminal is in the fzp file but not the svg file. (typo?)

svg svg.breadboard.Calliope_mini_cb68f829b4eb11fc3122f1bd5a9c956e_6_breadboard.svg.bak

Error 18: File 'part.Calliope_mini_18e1f312913c8c9c43b618584bd40d02_3.fzp.bak'

Connector connector1terminal is in the fzp file but not the svg file. (typo?)

svg svg.breadboard.Calliope_mini_cb68f829b4eb11fc3122f1bd5a9c956e_6_breadboard.svg.bak

again possibly left over from the original part. These can be a false positive as the script can't recognize (yet) a path that will in fact generate a hole, but it may also be pads that have become ellipses (which really won't generate a hole in the gerber), I won't know which til I look at the files.

Error 74: File 'svg.pcb.Calliope_mini_cb68f829b4eb11fc3122f1bd5a9c956e_6_pcb.svg.bak' At line 124

Connector connector46pin has no radius no hole will be generated

Error 74: File 'svg.pcb.Calliope_mini_cb68f829b4eb11fc3122f1bd5a9c956e_6_pcb.svg.bak' At line 149

Connector connector40pin has no radius no hole will be generated

Error 74: File 'svg.pcb.Calliope_mini_cb68f829b4eb11fc3122f1bd5a9c956e_6_pcb.svg.bak' At line 175

Looks like they are paths, so this is probably a false positive. I'll check the gerber output in a bit. I'll do what I can tonight but it is getting late here, so it may be tomorrow before I have a corrected part.

Peter

[HaraldRau]

Thank you, I will work on it tomorrow. Today I am on a business trip. I will first set up Inkscape correctly. After that I try to get git running. I do not want to destroy the existing work. That's why I'm careful.

[el-j]

@vanepp @HaraldRau just to let you know. i will remove the calliope stuff from the other issue because it is off-topic there. @HaraldRau please keep topics related to the issues (never mentioned ;) 🗡

[HaraldRau]

I do the following: @vanepp These pads (and there are more of them) do not create a gap in the board unless they pass through the test script (indicating that the problem has been resolved). This is usually caused by optimized XML in Inkscape that does not work well with Fritzing.

• open in Inkscape xml-editor

• erase 5 pads from the PIN-Header for the H-Bridge, there are "ellipse" and have the value stork-width

• deleted groups with the element "title" and empty groups

• shift the group "silkskreen" and "cooper1"

• added a hole under the PAD in the element "path" of the group "silksreen"

• save in normal-svg Format

• copy to the nightlyPart Folder and test it

[vanepp]

I just got a mostly fixed up part (there is still some work to do) created. I made a fair number of changes especially in schematic and on the way noticed that that fzp file calls one of the edge pins C0 but the pin out drawing on their site calls it C8. I have a list of the changes I made, but it is after midnight here, so I'll post it tomorrow (along with a completely fixed up part). This one has the buses disabled and the pins and terminalIds in schematic probably aren't properly aligned but it at least loads in Fritzing so it is mosltly right. I added connectors (and a connector in breadboard) for the battery and grabbed a couple of grove connectors from seed also in breadboard. The pins were all renumbered as well so they are contiguous so this particular part won't work with any preexisting sketches.

Calliope_Mini_final-partial-fix.fzpz.zip

Peter

[HaraldRau]

Thank you! Have you disabled this busses? `

` I have also they deleted, without errors. When i test my Version, Fritzing crashed by auto-routing in pcb. The Main Window close without message. The routing in Schema is possible.

Which editor can be used to edit the * .fzp file. "Geany" does not open the file, only "nano" in a terminal.

[HaraldRau]

@vanepp

max485_breadboard-fixed.zip Excuse me, i can't open or import the Part: Is the zip-archiv corrupted?

Harald!

[vanepp]

"Have you disabled this busses? <bus id="5V"/> <bus id="3V3"/> <bus id="GND"> <nodeMember connectorId="connector19"/> <nodeMember connectorId="connector23"/> <nodeMember connectorId="connector25"/> </bus>"

Yes, I removed all the bus definitions to save time late last night. I'll add then back in this morning with the new pin numbers. By the way I need to know which terminal on the battery connector is positive and negative. The documentation that I have found so far doesn't say which pin is which. Any text editor should open the fzp file (it is just a text xml file). I usually use vi on unix and notepad++ on Windows (or more usually vi in cygwin on Windows). I'm surprised Geany won't open it (maybe doesn't recognize the .fzp extension?). I rarely use autorouting because it doesn't work very well. It is possible that it is objecting to the missing pins in pcb view. I'll try a board and autoroute it and see if mine crashes. There is a debug log available in help->enable debugging log, but it assumes you are debugging the source code and so isn't all that readable to normal folks. As to max485_breadboard-fixed.zip, sorry my fault. It isn't a zip file but rather an svg, so just rename it from max485_breadboard-fixed.zip to max485_breadboard-fixed.svg and it should open in Inkscape.

Edit: I just tried autorouting with both my new part and your original and both work for me. Could you upload the fzz file of the sketch that is breaking autorouting please? It may be either something misconfigured in the part or a bug in Fritzing, a misconfiguation in the part needs a check script update to alert people not to do that, and a bug in Friting needs to be on the long list of bugs to fix if we get development working again.

Peter

[vanepp]

OK. time for another long post and a better (but not yet acceptable) quality part. Here is a log of what I did to get the part to this point and the last problem which is the path for the outline of the board in pcb along with a mostly (other than pcb silksscreen part for testing:

Unzip the part to recover the fzp and svg files, then start with breadboard svg: Edit the svg with Inkscape. The first issue is the scale is wrong (.75 instead of the desired 10.41667), so ungroup the entire svg. This mostly removes any transforms (some, such as polygons don't get removed but Inkscape can deal with that usually). I edited the svg and deleted the xml:space="preserve" from the document. lxml which both Inkscape and the check script use is one of the few tools that doesn't ignore this and it makes the xml output annoying. So with the svg ungrouped, rescale it to the desired scale. Note rescaling often turns circles in to ellipses, which doesn't matter in breadboard but does in pcb. Other than the scale there wasn't a lot to do in breadboard, I grabbed a grove connector from a seed board to replace the two grove connectors with something more realistic and grabbed a jst type battery connector to add connectors fot the battery. With that done I renumbered the connectors so they are contiguous and added a 6th connector (which I later supressed) to the motor header connector. Later I realized there are several versions of this board and you look to have an older one without the 6th ground pad or apparently a microphone connection (according to a picture I found here:

https://www.zeit.de/digital/internet/2016-12/calliope-mini-crowdfunding-grundschule

If that is not correct we should add a connector or connectors for the microphone as well. That pretty much completed breadboard for now. I see that the text is all rendered as paths, later I needed to change some text and inserted it as text (which makes later modification much easier). If you have a reason such as a special font, you may need to change my added text to paths. If not you may want to consider replacing the rest of the text as text rather than paths to make future changes easier. You also look to be using gradients, while I have no idea what they do, they add a lot of xml and thus likely a lot of extra processing. I also discovered when I tried to move an image from breadboard in to schematic, that schematic doesn't appear to support gradients. The image is there, but it doesn't render in Fritzing. So unless gradients are important for something you might want to avoid them in parts. On to the pcb svg, again it is the wrong scale so I converted it as above, but this time I needed to adjust the radius and x/y position of the pads to exactly match the original to get the same placement as your original board. With that done, I changed that pads stroke-width parameter to 20 (to give a 20thousndth pad width) and changed the radius (which in Inkscape changes the size of the circle but not the x/y position) to .078in diameter. This causes the gerber code to generate a 0.038in hole suitable for installing .1 inch headers in. I set the path width of the path in silkscreen to 10 (for a standard 10 thou line) and then had to edit the path to move it out a bit from the pads (the gerber code would have turncated it because it is to close to the copper) and delete the interrior circle on the 6 banana jack pads. The place where it was calling for silks screen would have been in the drill hole and it is possible a board house would have a problem with a silk configured that way. In any case you won't get the silk so there is no harm in removing it (other than my butchering the path as we will see later). With that done I removed the smd pads for the two grove connectors as you can't get to them from the pcb anyway (I fixed that in the fzp file to keep Fritzing happy). Then I renumbered the pads to be the same as the new set defined in breadboard and regrouped and was done. Now on to schematic, as you have probably seen I made a lot of changes (and have made even more in this version) in schematic. Basically I prefer to have all the pins in breadboard be visible in schematic and be laid out in as similar a manner to the board layout in breadboard because it makes debugging easier, so that is what I did here. You may or may not like this format, and if you don't, feel free to change it back to the original format (but please use my svg as the base so the scale and pin numbers remain correct). Given that this part is aimed at children that probably aren't familiar with schematics, in the final version I imported scaled down vesions of the connectors from breadboard view that indicate where the connections in schematic actually connect to the physical board. Again if you don't like it feel free to delete it. Again the pins were renumbered to match breadboard and pcb. Again resized the page to content, regrouped the svg and saved it. At this point last night, I deleted the bus configuration in the fzp file (because it needed renumbering which was going to take some time and posted the partially fixed part last night. Today I started renumbering the bus configuration and found a numner of problems (which in turn has caused changes in all the svgs). There were extra pins (probably left over from the part this was cloned from) in the fzp file so I dug up the schematic and started tracing what ports share pins and thus need to be bused. The schematic is remarkably confusing with a mixture of names, but I think I have identified all the ports that need to be bused and discovered what I think are a number of pins in breadboard that were incorrectly labeled. There are several new buses for pins that weren't previously bused (but from the schematic should be) so you may want to take a physical bpoard and a couple of leds, then attach the leds to the ports I think should be bused and run a program that toggles the port to make sure both leds come on and go off when the bused port bit is toggled just to be sure I have it correct. As a part of that I needed to change text in breadboard and added text as noted at the start of this. With that done I changed the file names, varient and moduleId to make this a new part so that it can be loaded along side your original part to compare the two. I ran the resulting part throught the check script which runs mostly clean (some complaints but they are unimportant) and loaded it in to Frtizing to test. It tests fine in Fritzing (I will attach the sketch I used) so I created gerbers from the pcb and checked it with gerbv (a free gerber viewer). There my changing the path in pcb has bitten me. It looks fine in Fritzing but the gerbers show the path has blown up and drawn a spike from the top of the board down to the connectors instead of the curve that is supposed to be there. Perhaps you are better than I at editing paths and can fix it up. I did find the eagle files for the production board so it may also be possible to get an outline from there (although I understand the eagle to fritzing converter is complex as well). The prupose of the connections in schematic being at 45 degrees to the pins is to insure that the termialIds are all in the correct places. The sciprt will complain if the terminalId is missing, but won't if it is present but in the wrong place. This test checks for that. Hope this helps! I'm going to try and upload the sketch and the part as native files, if github won't let me I'll rename them to zip files. First the new part: Nope doesn't like fzpz files. Tack a .zip on the end of both:

Calliope_Mini_final-fixed.fzpz.zip

and the test sketch

test-Sketch.fzz.zip

Peter

[HaraldRau]

Unbelievable, so hard work for that part!

Later I realized there are several versions of this board and you look to have an older one without the 6th ground pad or apparently a microphone connection (according to a picture I found here:

The GND number 6 is not on this part. This version is never published, or it is a mistake in the documentation. I will ask the Calliope gGmbH. We can delete the Pad.

I soldered the PIN header later!

My Text-Work:

In a guide of the magazine MAKE was said: 'One should take the font' OCRA font 'and then convert them into paths.' Is that wrong?

You also look to be using gradients, while I have no idea what they do, they add a lot of xml and thus likely a lot of extra processing.

I did not want to use gradients. I have the graphics from the Calliope page. Gradients is not necessary!

On to the pcb svg, again it is the wrong scale so I converted it as above, but this time I needed to adjust the radius and x/y position of the pads to exactly match the original to get the same placement as your original board.

I think i have not enough basic knowledge. I did not know that i have to scale in SVG's. I thought they are always 1: 1. Why not scale when rendering?

Basically I prefer to have all the pins in breadboard be visible in schematic and be laid out in as similar a manner to the board layout in breadboard because it makes debugging easier, so that is what I did here.

I really like the result. But it's a bit tricky to take all the breadboard connections into the scheme. A basic competency in engineering is: To transfer technical reality into a schema or to form a model of a technical system. I thought schemata must always be simplified and unique, , without redundancies. For debugging is your schema really easier.

Perhaps you are better than I at editing paths and can fix it up. I did find the eagle files for the production board so it may also be possible to get an outline from there (although I understand the eagle to fritzing converter is complex as well).

I think i'am not better, but i will try it. The Sketch work in my "Fritzing-Dsitribution" perfect.

Thank you!

[HaraldRau]

I unpacked the files, they are all very beautiful.

The scheme I will adapt to your template. I think I'll put it up for discussion on Tuesday.

I looked again at the scheme of the Arduino Nano (Rev3.0) (ICSP). There are also no double connections.

This is my favorite, above voltage input, below GND, right and left inputs and outputs.

[HaraldRau]

Here is a picture with the names of the connectors from the technical documentation.

I will try to implement this logic in the Schema:

These PIN's are multiple in the breadboard and in the schema only once

8 x GND + 1 Battery-Connector GND = 1 PIN 5 x 3.3V + 1 Battery-Connector 3.3V = 1 PIN 1 x C16 + 1 x TX grove = 1 PIN 1 x C17 + 1 x RX grove = 1 PIN 1 x C18 + 1 x SDA grove = 1 PIN 1 x C19 + 1 x SCL grove = 1 PIN 1 x C0 + 1 x P0 = 1 PIN 1 x C1 + 1 x P1 = 1 PIN 1 x C2 + 1 x P2 = 1 PIN 1 x C3 + 1 x P3 = 1 PIN

[vanepp]

"Unbelievable, so hard work for that part!"

Yes, in general good parts take a lot of work. Often (as in this case) testing in Fritzing is almost as time consuming as making the part in the first place. Much of this can and should be automated but we aren't there yet.

"The GND number 6 is not on this part. This version is never published, or it is a mistake in the documentation. I will ask the Calliope gGmbH. We can delete the Pad.".

Your version is similar (but not I think identical) to the one Adafruit is selling, then there is the latest version (which seems to be 1.3 I think) that has the extra ground pad and a microphone connector (which seems to be only 1 pin). I'd like to leave connector13 in, but not used in your version if you don't mind. I expect someone else is going to want a part for the later revision of the board and then we will need connector13. Since Fritzing sometimes displays incorrect pin labels (it may be only with parts that have subparts though which this one doesn't) if the pin numbers aren't contiguous, so I'd rather not have to renumber all the pins after it. Fritzing does display a red dot for the connection (although the actual pad is suppressed in the xml), because the connection exists, it just doesn't have a connection. I can try removing connector13 and see if the label for connector14 displays wrong.

"My Text-Work:

In a guide of the magazine MAKE was said: 'One should take the font' OCRA font 'and then convert them into paths.' Is that wrong?"

That may refer to an eariler version of Fritzing, 0.9.3b will display OCRA and Droid Sans as text. It is only necessary to convert to a path if you are using different font from one of those two now and having them as text is much easier to change. I'll convert all the text to standard text and try and remove the gradiants

"I think i have not enough basic knowledge. I did not know that i have to scale in SVG's. I thought they are always 1: 1. Why not scale when rendering?"

Fritzing will work fine with the scale as is, I prefer to change the scale because the parts format specification calls for the document size to viewbox (which sets the scale) to be 1 to1000 (i..e. one px in the document will be about 1/1000 of an inch. It is slightly off because a px is 96dpi, but it is close.) Having all svgs the same scale makes automated parts checking easier as well. I can also then easily calculate hole sizes in pcb ( hole size = pad diameter - (stroke-width * 2) without resorting to a calculator. At the standard scale a 0.078in diameter hole with a stroke -width of 20 (around 20 thousandth of an inch) creates a 0.038in hole suitable for a .1 inch header. At other scales I have to get out the calculator. Although I don't have any measurements yet, I think we will find that scaling at render time is expensive. A transform implies a matrix multiplication at render time (and rendering happens a lot). If at part create time we can remove all the transforms (which should be possible because Inkscape will most of the time do it if you ungroup), then we should save some processing time at render. The thing I don't know yet is if the saving is significant or not in practical terms. I hope to be able to instrument rendering when I get the development environment running and see how much if any difference transforms make. I'll make another pass through the part and try and remove the gradients and change the text back from paths to text and have another try at getting the path correct. I expect I have hit a bug in Frtizing and some little adjustment in the path will get it working again.

Peter

[HaraldRau]

I have just found the version with the 6 PIN's! Sorry it is my mistake!

[HaraldRau]

Now I understand the scaling. I always tried to implement a grid of 0.1 inch in Inkscape for drawing a Schema! But the hole must be 0,03 inch - ah O.K.!

Thank you!

[vanepp]

"I have just found the version with the 6 PIN's! Sorry it is my mistake!"

It isn't a mistake, there are just multiple versions of the board available, depending on who you buy from (and probably when you bought). That being the case I expect we will get a part request for one or more of the later versions of the board eventually and can then make a new varient of your part rather than starting from scratch.

"Now I understand the scaling. I always tried to implement a grid of 0.1 inch in Inkscape for drawing a Schema! But the hole must be 0,03 inch - ah O.K.!"

The width of the pin is supposed to be .3 in (and in fact the part factory generates IC pins like that) but you are correct the pitch between pins in both breadboard and schematic is supposed to be .1 in. That is getting blurred lately with 2mm connectors and even 1.27mm (.05in) on some of the wireless boards. The grove connectors I used on your board are in fact spaced at 2mm just as they are in real life. They are however getting somewhat crowded as bb wires are fairly thick. The 1.25mm ones will likely be a problem I expect (I haven't had to deal with them yet, but I will because I have some wireless boards with 1l25mm connectors. Before Inkscape decided (probably beacause of a wrong key press on my part) that all moves should be done with translates, I was working on correcting the part template documents which are quite badly broken. I'll send you a copy when I get them finished..

Edit:

OK, I have a better version to try out. The text has all been converted from path to text and I managed to get a better (still not perfect, but better) version of the silk screen path going: This is the gerber output from the part from last night:

and this is the gerber output from the current version:

and finally the current version of the part. Now I'll try and figure out how to remove the gradients to save both space and time (they are still in this part).

Edit2: Not any more. It was a lot simpler than I thought, just changed the fill url in 6 places from the gradient to #f7bd13 and delete 170k+ of gradient xml. The part is now half the size it was with the only change the color of the banana plug pads. I think it is pretty much done at this point, if you want to change schematic so the power pins are on top and ground on the bottom, that is easu to do, just select the pin (you may have to group it to get everything to rotate correctly) rotate it 90 degrees and drag it to its new position. If you do make changes you eill need to run the part through the check script again because Inkscape will add px to the font-size and convert inline xml to style, but thats easy to do. I would still be interested in the getting a copy of you part and sketch that crashes autorouter. An earlier version of this part with half a dozen connections to the headers autorrouted for me just fine (or as fine as autoreoute ever does anyway) and didn't crash.

Calliope_Mini_final-fixed1.fzpz.zip

Peter

[HaraldRau]

Here's the sketch with the problems with auto-routing the PCB.

Sketch_Autoroute.fzz.zip

just select the pin (you may have to group it to get everything to rotate correctly) rotate it 90 degrees and drag it to its new position.

I will change the schema as described. As a font I use OCRA! Before turning, I group to avoid losing the terminal.

[vanepp]

"I group to avoid losing the terminal." If you don't group it, in this part, it is no big deal. You just have to move the terminals afterwards. That's because one of the things the script does (and is done in this part) is change 0 height or width terminals to 10 thou. A 0 width or height terminal isn't selectable in Inkscape (and the parts factory creates terminal ids like that) and moving them is hard. You can't drag and drop them because they won't drag, you have to select them and use the tool bar to change their x/y coords to move them. The Sketch_Autoroute.fzz.zip sketch doesn't have the Calliope part in the temp parts bin (I suspect it may not have been a valid part and the loader couldn't load it). When I tried your wetter.fzz.zipa at the very start of this thread, it also doesn't have the calliope part. However I see from a later post back there that the early parts had overlayed pins in pcb which would probably be what was breaking the autorouter, so I think we can safely ignore that. When you finish your changes you can either run the final part through the part check script which is available here on github at: https://github.com/vanepp/FritzingCheckPart or post the part here and I can run it through the script for you. It is important to either run the part through the script or edit all the svg files and remove the px that Inkscape will append to the font-sizes. Fritzing will set the font-size to 0 after a parts edit if there is a trailing px on the font-sizes and it causes a lot of confusion (because the part works correctly before editing, which is somewhat odd).

Peter

[HaraldRau]

I started!

• Backup and open in Inkscape

• Move the GND pins down

• Turning the GND pins

• Position the terminals

• superimpose the pins and terminals

• Position the pins on the schema

Then I came across a problem. The I2C bus is only connected to the grove connector and pin C18 C19. Here, however, it looks like C0 and C1 are responsible for I2C communication.

I have to check that first.

[HaraldRau]

I have check the source. The PIN and the bus are wrong.

https://github.com/calliope-mini/calliope-mini.github.io/blob/master/assets/v10/

We have these buses: GND bus with 8 PIN (+Bat.) 3V3 bus with 5 PIN (+Bat.) Terminal bus with TX/RX at grove A1 and C16 C17 (your bus C2 C3) I2C bus with SDA/SLA at grove A0 and C18 and C19 (your bus C1 C0) Outside-PIN bus with (C0;C1;C2,C3) = (P0;P1;P2;P3) (your bus (C19;C18;C17,C16) = (P0;P1;P2;P3))

Should I prefer the bus in the fzp file or in Fritzing parts editor?

[HaraldRau]

I have the schematic edited without edited Text! The script say: Removed px from font-size leaving for every text-element. Noting errors are output. Here is the file.

svg.schematic.Calliope_mini_cb68f829b4eb11fc3122f1bd5a9c956e_7_schematic.svg.zip

When the file O.K., Then i will change the Text and the buses!

[vanepp]

Its morning here, and I missed the part about the text not being changed, so I corrected that as well. I made a number of changes (listed in detail below), but the important ones are that some of the pins were misaligned by 0.005in. Doesn't sound like much, but it is visible as an offset at the wire / part boundary in schematic. The rest of the changes are cosmetic and you can remove them again if you don't like them.

Reduce the size of the rectangle in x by .1in so the power pins are symmetrical and the ground pin is on the .1in grid (not .05 offset)

reduce height of the rectangle by .3in to eliminate unused space and save space in the schematic. All optimization, not technically necessary.

rename left side pins correctly

C1/SDA -> C1/BP1 C0/SCL -> C0/BP0 C19/BP0 -> C19/SCL C0/SCL -> C0/BP0 C2/TX -> C2/BP2 C16/BP3 -> C16/RX C18/BP1 -> C18/SDA

rename right side pins correctly

C3/RX -> C3/BP3 C2/TX -> C2/BP2 C16/BP3 -> C16/RX C17BP2 -> C17/TX C1/SDA -> C1/PB1 C3/RX -> C3/BP3 C17/BP2 -> C17/TX C19/BP0 -> C19/SCL

Increase y on all power pins by .005in to align to grid same with associated terminals. Additionally, pin Y on the top wants to be on a .005 boundary while terminal every where wants to be exactly on a.1in boundary and pin Y on the bottom wants to be 0 pins on the right side need a 0.005 offset in X. This is so the terminals on exact .1in boundaries are centered in the round line cap that a wire in schematic will connect to. I find it useful to offset the page grid in Inkscape by .005in in x and y which puts the grid lines in the center of the pins, so the connection point of a pin will be at the crossing of two major grid lines which makes it easier to check alignment visually. As an example using connector20: connector20pin X 1.105 Y 1.1, connector20terminal X 1.2 Y 1.1. I swapped the 3.3V and Vin (which incidentally I would label VM as the pin document does, to indicate it is the power supply for the motor, but I have not done that in the schematic) as it is associated with the 2 motor pins on the left side of the drawing. The corrected schematic is here (it is the same name as the current one so you may want to keep a copy of or rename the current one to keep a record of it for later):

svg.schematic.Calliope_mini_cb68f829b4eb11fc3122f1bd5a9c956e_7schematic.svg.zip

Peter

[HaraldRau]

i have my copy from the source! I change my Grid and go on. O.K., now I will merge the PINs for RX, TX SDA, SCL, P0 to P3!

[HaraldRau]

I did: remove the PIN RX,TX,SDA,SCL,P0-P1 and change the description.

I give the file to the python-script. Message are:

Warning 23: File svg.schematic.Calliope_mini_cb68f829b4eb11fc3122f1bd5a9c956e_7schematic.svg At line 129 Key -inkscape-font-specification value 'OCRA, Normal' is invalid and has been deleted Warning 26: File svg.schematic.Calliope_mini_cb68f829b4eb11fc3122f1bd5a9c956e_7schematic.svg At line 144 Apparant nested tspan which fritzing doesn't support If your text doesn't appear in Fritzing this is probably why Warning 26: File svg.schematic.Calliope_mini_cb68f829b4eb11fc3122f1bd5a9c956e_7schematic.svg At line 155 Apparant nested tspan which fritzing doesn't support If your text doesn't appear in Fritzing this is probably why Warning 26: File svg.schematic.Calliope_mini_cb68f829b4eb11fc3122f1bd5a9c956e_7schematic.svg At line 166 Apparant nested tspan which fritzing doesn't support If your text doesn't appear in Fritzing this is probably why The tspan hast the same x-y-Coordinate as the text-element. Can i delete the tspan?

[HaraldRau]

I delete the tspan, python says O.K.! I hope the grid is correct? Here is the file: (i added a version number dd.mm++.zip) svg.schematic.Calliope_mini_cb68f829b4eb11fc3122f1bd5a9c956e_7schematic.svg.260201.zip

Tomorrow I will change the description and the bus in the fzp-file!

Good morning for you Good night for me

[vanepp]

I don't know what the point of tspans is perhaps for something more complex that Fritzing. I've never seen a case where I can't delete them without harm (I fact the not yet ready for release version of the script automatically deletes them for you). Fritzing accepts some types of tspans but doesn't others so removing them all fixes that up and so far I haven't come across a case where anything breaks. The grids are a little bit off. Floating point roundoff and/or perversity on Inkscape's part tend to make them vary a bit. So usually as the last step after resizing the page and grouping and adding the layerId (I normally ungroup and svg as the first step as that avoids adding some types of translate when moving things if Inkscape is feeling charitable and/or I haven't hit the wrong key) is check and adjust if required the alignment on all the pins. Here snipping tool comes to the rescue as I can grab screens shots from Inkscape. The easy way to check and adjust pin alignment is to set the tool bar units to "in" then select the pin or terminal in xmleditor. That brings up its X Y coords in inches on the tool bar. If it is off, changing the tool bar number and clicking on another field to update it (because Inkscape usually won't change it if you don't click on another field first) corrects it. You latest one is mostly OK, but is out a little on some pins. I'd wait until you have the final version then check all the pins and terminal locations just before saving the file.

Starting at the left bottom pin

X is out by .001, not really enough to worry about, but I like to correct even the small ones although they probably aren't visible. The ground on the bottom is a little further out in X but not much, otherwise fine.

pin 42 on the right side looks fine. Here we see the X is 1.105 (with the .005 offset mentioned above)

and the terminal is exactly on the boundary at X 1.2 and Y 0.2 as desired.

Over all looking good. For the buses I find editing the fzp file to be easiest, but parts editor does the same job and makes the same changes ( although I don't think it will delete no longer used entries if they are present which is part of why I like to edit the file directly), so which ever you are most comfortable with is fine. The script will complain if you make a mistake in the editing, it checks that connector exists and are only in one bus (but of course will let you put a pin in the wrong bus!)

Peter

[HaraldRau]

Good Morning, i will continue! In the scheme I found some strange elements. Will they be removed from the script? I think will remove it by hand. <linearGradient y2="520" y1="454.20001" gradientTransform="matrix(6.0539313,0,0,6.0539228,-1517.4747,1978.1775)" x1="105.1" x2="105.1" id="gradient-pin-3-5" gradientUnits="userSpaceOnUse">

When inserting into the Fritzing editor, the text 'MA' and 'MB' was displayed as large. In control, I could see a very big style element. I reduced it. I found other large style-element like this: style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:49.00001526px;font-family:OCRA;-inkscape-font-specification:'OCRA, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#555555" it's look like a redundancy. Can i change there to: style="font-size:49px;font-family:OCRA;text-anchor:start;fill:#555555"

The 'font size' is changed by the script?

I think, then i can use the scheme.

I will try to work with the Fritzing Part Editor.

Still a question: How can I make the unzipped files (Breadboard, Schema, PCB, Icon, FZP) back to an FZPZ-File?

[vanepp]

"In the scheme I found some strange elements. Will they be removed from the script? I think will remove it by hand. <linearGradient y2="520" y1="454.20001" gradientTransform="matrix(6.0539313,0,0,6.0539228,-1517.4747,1978.1775)" x1="105.1" x2="105.1" id="gradient-pin-3-5" gradientUnits="userSpaceOnUse">"

Yes you need to remove this by hand, the script doesn't know about gradients and won't do anything to it. I probably didn't do a search for grandients after I removed the huge def.

"When inserting into the Fritzing editor, the text 'MA' and 'MB' was displayed as large. In control, I could see a very big style element. I reduced it. I found other large style-element like this: style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:49.00001526px;font-family:OCRA;-inkscape-font-specification:'OCRA, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#555555" it's look like a redundancy. Can i change there to: style="font-size:49px;font-family:OCRA;text-anchor:start;fill:#555555"

The script doesn't (or shouldn't anyway) change the font size, all it does is remove the px from the end of the font size. I suspect you are seeing an Inkscape quirk. When you have an inline font-size such as

font-size = "45px"

and you change that in Inkscape (say to font-size = "35" what Inkscape does is make a style command:

font-size = "45px"

style="font-size:35;font-family ..."

It does not remove the original font-size nor change its value. For Inkscape that is fine because it ignores the inline font -size 45 and uses the one in the style command, Fritzing does the opposite. Fritzing will use the font-size = "45px" and give you a larger character than you expect. The script removes (actually overwrites) the first font size doing what Inkscape does and preferring the font-size in the style if there is one. The result is that the above after the script will be in line xml with a single

font-size="35"

(the font-size="45 being discarded). I suspect what happened to you is you edited with Inkscape which looked fine, because it was using the style font size value and Fritzing then used the left over large font size and displayed larger characters. It is easy to deal with once you know what is happening, but the first time you see it, it is startling and confusing until you figure out what is happening. This is really a bug (one of many!) in Inkscape, it should not be keeping both font sizes.

"Still a question: How can I make the unzipped files (Breadboard, Schema, PCB, Icon, FZP) back to an FZPZ-File?"

Any zip program should do, I use 7zip. Just select the 5 files (the fzp file and the 4 svgs for each view) and zip them then rename the file to .fzpz instead of .zip.

Peter

[HaraldRau]

I start this morning with a big problem. The drawing in our part and the part of @el-j differ. The 6x1 PIN header looks a bit like a zig zag in the original documentation. @el-j created the drawing with brd2svg.

I wrote down the coordinates of the PIN header. Before that, I set the inch and the scaling to 10. The y coordinate changes by 0.793 inches and the PADs are 7.2 inches away. Here are the coordinates:

pin	cx	cy
GND	103.243	161.508
MA	110.443	160.715
MB	117.642	161.508
GND	124.843	160.715
Vin	132.043	161.508
GND	139.243	160.715

Furthermore, the PINs are not at the same x-coordinate as the 13x2 PIN header. I will try to align the PINs with the coordinates.

[vanepp]

This may not be as big an issue as you think. I saw the offset pins in some of the photos online, but that is just a variant on the standard .1 header outline. Either will take a .1 header, the zig zag pattern (I think) is to make automated assembly easier by holding the .1 header more securely. Either pattern should work fine as long as the spacing is .1 in (which it is). If the 5pin pad is in the wrong position compared to the dual row header, that would need to be corrected. I'll have a look at the original and ours and see if there is an error. On a different topic, there may be an error in the parts script that would cause the font size to change. As I recall (it is a while since I last touched that part of the code) the script processes the style command when it comes across it. Usually the extra font size is before that, the value in the style overwrites it and all is well. But it is possible (I now know which I did then) that Inkscape will sometimes write the font-size after the style and if it does that I think the wrong font-size will probably overwrite the correct on from the style command. I'll have a look at what I did when I get some time.

Edit:

Yes it looks like our pcb is wrongly spaced. The top pins in y in the original are 0.520in for the low ones and 0.528 for the top ones making the center line 0.524in. The top of the two row connector is at 0.383in so 0.524 - 0.383 = 0.141 space between the rows in the original. Ours is 0.757 - 0.567 = 0.19 which is indeed incorrect. in X ours matches between top and bottom and the original looks to be offset by about .05 in. The scales are different between the two svgs so I will change the scale on the original to match and copy the exact coords from the original in to ours to fix this up (and add the zig zag to to the top row of pins.)

Edit2:

OK here is what I think the board should look like with the moved correctly. Note they are likely now out of position with respect to the banana jacks as those pads are not in @el-j 's original svg, so you need to figure out where they should be from an actual board. Once we settle on a final config (i.e. mine and yours match each other) then you should print out a 1 to 1 copy or the svg (or better yet the output from a gerber viewer as that is what the actual board will be made from) preferably on a transparent sheet for projection and overlay it on a physical board to make sure the holes line up correctly as the final test of whether we have it correct. To make mine I took @el-j 's original svg from nightly parts, rescaled it to match ours and changed the radius and stroke size on two of the pads to match ours (which produce a standard pad for a .1 header pin unlike the original). I then used the tool bar to measure the offset (in inches, although px would have worked as well) and then moved the pads in our svg to match the original. I'll include both svgs below.

first the rescaled original with two pads updated:

svg.pcb.Calliope_mini_nightly_parts_pcb.svg.zip

and the corrected (but probably not aligned to the banana jacks) pcb svg:

svg.pcb.Calliope_mini_cb68f829b4eb11fc3122f1bd5a9c956e_7_pcb_corrected_pads.svg.zip

Peter

[HaraldRau]

I Can't change the coordinates from the PCB. The coordinates are completely different! I step one backward and edit the breadboard!

• copied i workspace
• edit the text from the grove A1 und A0
• delete the buses in the fzp-file
• build a fzpz-file and work in Fritzing-Editor

[HaraldRau]

The breadboard are to big. Have i the wrong scale, must the scale be 1000?

i got it, the scale must be 1000!

[HaraldRau]

So, i have rebuild the buses and check the files with the script:

• breadboard: tspan deleted and then without errors
• icon: tspan deleted and then without errors
• schematic: remove px and then without errors
• pcb: "This is a through hole part as both copper0 and copper1 views are present."
• fzp: script can not run Traceback (most recent call last): File "FritzingCheckPart.py", line 289, in <module> Doc = Fritzing.ProcessFzp(DirProcessing, FileType, FileType, InFile, None, CurView, PrefixDir, Errors, Warnings, Info, FzpDict, FilesProcessed, TagStack, State, InheritedAttributes, Debug) File "/home/hara/Software/Fritzing/FritzingCheckPart-master/FritzingTools.py", line 817, in ProcessFzp PP.OutputTree(Doc, Root, FileType, InFile, FQOutFile, Errors, Warnings, Info, Debug) File "/home/hara/Software/Fritzing/FritzingCheckPart-master/PPTools.py", line 432, in OutputTree f.write(XmlPP) UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 1092: ordinal not in range(128)

Build a fzpz-file and import in Fritzing and test it!

In the pcb looks like the old buses is enabled. When i connect SDA_A0 in pcb connect Fritzing P1 Banana. I will tomorrow edit the fzp-file!

Calliope_Mini.fzpz.zip

[vanepp]

" The breadboard are to big. Have i the wrong scale, must the scale be 1000?"

For reasons unknown (at least by me) Inkscape wants the scale to be 10.41667 to get the viewbox to be 1 to 1000. The .41667 is because of 96DPI, but I don't know why the scale is only 10. However that shouldn't affect breadboard's size, as the document is dimensioned in inches it should just work no matter what the scale is, there is something else wrong there, but I can't immediately think of what. If you post the fzpz file that generates a wrong breadboard size I'll try and figure out why it went wrong.

"* pcb: "This is a through hole part as both copper0 and copper1 views are present."

This is just an information message telling you this is a through hole board. If it had only copper1 it would tell you it is an SMD part, nothing to worry about.

The script error looks to be because there is a Unicode character in the xml somewhere and the hack I used to do pretty printing looks to be Ascii only. I'll see if I can make it accept unicode, but that may take a while. The main issue I see is the pcb pads in the Calliope_Mini.fzpz.zip file you posted are the old ones, and we need to get that corrected before moving on I think. I expect

"I Can't change the coordinates from the PCB. The coordinates are completely different!"

is the problem here. You are correct the original documents are in a different scale, so you need, as I did in the svg.pcb.Calliope_mini_nightly_parts_pcb.svg.zip file which is from the current nightly parts repository, but has no pads for the banana jack pins. I rescaled that to the 10.41667 scale and modified two of the pins to have a radius of 29 and a stroke-width of 20 like the current board and then the coordinates (while offset in x and y) can be used to position the pads. I'll look back through this thread and see if I can find a copy of the pcb svg with both the headers in the correct place and the banana jack pads present and use that to correct the position of the pins.

Edit: I managed to figure out how to back up the nightly parts repository to the initial commit and get a copy of the first pcb with all the pads in place. I'll use that to correct the latest pcb.svg so the pads are correctly aligned.
Edit2:

And now I'm sorry I did :-) , there is a difference between our latest version and the first commit to nightly parts, indicating one or the other is wrong. Unfortunately the original svg has dimensions in px and is thus possibly subject to dpi scaling issues. I have a copy of the Eagle files from the Calliope site and a copy of Eagle so I will pull up the board in Eagle and see if can figure out how to measure the pads in Eagle to tell which (if either) of our svgs is correct and go from there. edit3:

And I was right, I'm sorry now. All three are different. I measured from the left edge (because that is the Inkscape origin) of the top banana jacks in y. I think Eagle is measuring in mm

Eagle

top left banana pad in Y left edge of the pad y -23.8164(mm?) x 24.197837(mm?)
top right banana pad in y left edge of the pad y 14.239009(mm?) x 24.197837(mm?)

14.239009 - -23.8164 = 38.049mm in x

The original commit to nightly parts from eagle to fritzing (which has units in px and thus may have scaling issues in Inkscape)

Edit svg in Inkscape and set toolbar units to mm

select left top banana jack pad

left top banana jack x 14.247mm right top banana jack 42.815mm

42.815mm - 14.247mm = 28.568mm

Our latest pcb svg same measurements as above

x left edge 20.788 67.593

67.593 - 20.788 = 46.805mm

I think the way forward is likely to get an edge to edge measurement of the actual pcb (preferably with calipers) between the left edge of the to pads marked with red here, so I can figure out which one (if any :-) ) matches the real board.

Peter

[HaraldRau]

I continued to work on the autorouting problem. For this I have removed in the fzp-file all references to the PCB. There are now only the PCB-references to the PIN-Header. So I can connect to SDA, SLC, RX and TX clean again. Then I removed the PADs from the PCB file. I think we do not need the PADs. If we want to develop shields, we only need the PIN header. Everything else is just ballast.

Here are the export-Part and the Sketch.

Sketch.fzz.zip Calliope Mini experimentell.fzpz.zip

With this Part and this Sketch were the auto-routing process successful!

Attention: The files were not scanned with the script. I will clean up the files when you confirm the successful auto-routing.