Yes, Thank You. This is some problem with the font. I have selected Droid Sans in Inkscape, but part editor complains about it and shows it small. I need to figure out what i’m doing wrong.
↧
Humidity and Temperature Sensor DHT11
↧
Part Request | Arduino MKR Boards
Hi, ok, I found the parts for the Arduino Zero and the MKR 1000, but the links you have provided do not show the Arduino MKR Zero and Arduino MKR GSM.
I am aware that they are quite similar to the MKR 1000, though they would need some changes.
Andrei
↧
↧
Part Request | Arduino MKR Boards
If you can indicate what changes need to be done, then I can make them. I’m working on making the Vidor part.
Peter
↧
Humidity and Temperature Sensor DHT11
I couldn’t see the usual “px” error, so we will have to wait for Van-the-man 
to see what’s going on.
↧
Humidity and Temperature Sensor DHT11
While I’m not sure yet if that is the cause, font size depends on scale and the part you cloned from is scaled incorrectly. I’ll post a corrected part in a bit.
Peter
↧
↧
Humidity and Temperature Sensor DHT11
OK, your font problem seems mostly to be the fonts were just too small in the svg files (there were translates as well, but that isn’t normally a problem).
Breadboard:
The layerID breadboard was missing. The only thing I know of that this breaks is exporting the part as an svg or image (the part won’t show up). I rescaled the svg (all of them actually) to be the standard scale. Many existing parts even in core are incorrectly scaled, I’m trying to fix that. The pins should start at 0 (not 8 as they do here) again a common problem. I added “pin” to the end of the connectors and renumbered them starting at connector0pin (again in all svgs and the fzp file).
Pcb:
rescaled and adjusted the pad sizes to create a 0.038in hole suitable for .1 square pins.
schematic:
Most of the changes are here. Rescaled, renamed the pins, added connectorxpin everywhere. Adjusted the font sizes (after deleting the translates) to the standard sizes. Reduced the size of schematic to just large enough to contain the text for the pins to save space in schematics. Added pin numbers to the pins to tell them apart. Ran the part through my part check python script which will remove the px from all the font-sizes. If px is left in sometimes Fritzing reduces the font size to 0 which can be the cause of the small characters. Did look to be in this case as Old_Grey noted. Below is a new part with all these changes (so you can load both your current part and mine to compare them:
Humidity and Temperature Sensor DHT11improved.fzpz (7.8 KB)
Peter
↧
ESP-WROOM-32 (ESP-32S) part
@vanepp After using this ESP32 file, why I cannot autoroute connected wires. All connected wires are lost after autoroute.
↧
ESP-WROOM-32 (ESP-32S) part
Upload the .fzz file with the 7th button
↧
Part Request | Arduino MKR Boards
It appears the Arduino store has the .fzpz files (although it is unclear how good they are) as part of the product page.
https://store.arduino.cc/usa/mkr-gsm-1400
under documentation has an fzpz file although the other 2 do not. I found this because I came across an issue on github asking for help with another of these products where the fzpz file is corrupt (the pcb svg file is zero length). The rest of the fzpz file however is a mess and I don’t think it has ever worked.
Peter
↧
↧
ESP-WROOM-32 (ESP-32S) part
@Old_Grey Can you give me more detail? I don’t know what is the 7th button.
↧
ESP-WROOM-32 (ESP-32S) part
I used ESP-WROOM-32 [ESP-32S] Module_fixed.fzpz 283 in previous post by @vanepp.
↧
ESP-WROOM-32 (ESP-32S) part
What he was asking for is the sketch that you used the part in (thus the fzz file). The part is thought to be working, the problem is likely in your sketch. I don’t normally use autoroute and thus don’t test against it, but I don’t remember anything strange in the part that should affect autorouting.
Peter
↧
ESP-WROOM-32 (ESP-32S) part
(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)
↧
↧
ESP-WROOM-32 (ESP-32S) part
testwroom04.fzz (37.8 KB)
This is my fzz file.
↧
Part Request | Arduino MKR Boards
↧
Humidity and Temperature Sensor DHT11
Hi Peter,
thank You for all the corrections! Looks great!
May I ask You … what do you mean by “rescaling the svg to standard scale”?
I have designed my part in mm with its real dimensions. Is that OK or should I use inches?
I have plan to make another part - 7 segment 4 digits display with 12 pins (CL5642BH-33) - so I want to follow all the standards.
↧
HiFive1 board part
Fritzing part for HiFive1 RISC-V based Arduino compatible board. It can be downloaded from here
HiFive1 Arduino IDE support: https://github.com/westerndigitalcorporation/CincoWinPkg
Publishing it on the forum before submitting into Fritzing parts GitHub to receive your feedback.
↧
↧
ESP-WROOM-32 (ESP-32S) part
OK for me autorouting works (as much as autorouting ever works). However it appears to not be able to route the traces to the wroom, I expect because the default trace size is too large. I tried setting the scale on the pcb down to .02 in but that doesn’t help. In general the autorouter does terrible pcb layouts and no one uses it. You are much better off to hand route the board. In this case you probably need to reduce the trace size in inspector to route the wroom although the default trace size does appear to work with the grid size set to .025 inch.
testwroom05.fzz (36.2 KB)
Peter
↧
Part Request | Arduino MKR Boards
OK, I’ll modify the current Zero when I finish the Vidor board. It is being quite exciting in that there appears to be little documentation and a lot of pins and is thus going fairly slowly.
Peter
↧
Humidity and Temperature Sensor DHT11
Rescaling involves the board dimensions (I typically use inches because the ratio wants to be in inches) to the size of the viewbox in the svg file. It isn’t visible ourside of the svg, but it is important to Fritzing if we want to use automated tools to check parts (which I do). The ratio comes from the part file format at
at the bottom of the About Svgs section (itself near the bottom of the document)
“Now about measurements and SVGs. One of the pleasures of SVG is that the format can support extremely accurate placement and sizing. At the top level of the SVG, there are three attributes, width, height, and viewBox. …”
What I do in Inkscape to correct the scale when it is incorrect is here (it is a pain in the ass I will admit!):
In pcb after doing this you need to verify that the pads have not changed to ellipse during the rescale (as an ellipse won’t generate a hole in the gerber). I generally run the result through FrtizingCheckPart.py (available here):
which checks for this and various other errors.
Peter
↧