Quantcast
Channel: fritzing forum - Latest posts
Viewing all 31215 articles
Browse latest View live

Circuit Diagram

$
0
0

What sketch? I have try one sketch, and I didn’t finish, I didn’t like it, and so I deleted it.


Circuit Diagram

$
0
0

Then you need to make another one. I don’t mind helping with something you can’t figure out, but I’m not intending on doing your project for you.

Peter

Circuit Diagram

$
0
0

I understand, thank you. I will comeback with the sketch.

Circuit Diagram

$
0
0

If you haven’t already found it a google search for “fritzing part HB100” turns up a part here (and all of these I have used have been good parts):

http://omnigatherum.ca/wp/?p=338

Peter

I look for the GY-86 sensor and the BN-220 GPS modul

$
0
0

Dear Peter,

Thanks a lot for your fast help.

Now, the size is 17 * 22mm and the hole are 3 mm with a corner distanz from around 1mm.

On this Link, you will see a datasheet with a difference of the size.

Have a good weekend
Willi

I look for the GY-86 sensor and the BN-220 GPS modul

$
0
0

That is what is needed. I’ll fix up the part and repost it.

Peter

Png with Background Color?

$
0
0

I was able to change the background color using View/Set background color. But when I go to export my breadboard view as a PNG, the image I get has a white background. I’d love to have the color and grid show in my export. Am I missing a setting somewhere?

Png with Background Color?

$
0
0

Can’t say I’ve ever tried to do this, but it doesn’t appear that the exporter preserves the color on export. A work around would be to export the image as svg then edit it in Inkscape and set a rectangle around the entire image and set the color background color on that. Less efficient, but it should work (you probably need to move the rectangle to the top so the image shows on top of it).

Peter


DFPlayer Mini ESP Board - No Copper in Holes

$
0
0

I have just designed my first board in Fritzing. When I am sending the exported gerber files to the Fab service, the copper around the holes of the DFPlayer Mini are missing. How to solve that?

DFPlayer Part

LOLIN32.fzz (176.7 KB)

Part request - Arduino MKR WiFi 1010

$
0
0

Hi,
Does anyone have a part for an Arduino MKR Wifi 1010?

I’ve seen images (jpg) of fritzing sketches that include the MKR WiFi 1010, so I assume the part exists somewhere. I just haven’t been able to find it.

DFPlayer Mini ESP Board - No Copper in Holes

$
0
0

While I see some potential problems, the mini player pads appear in the gerber output under gerbv and shouldn’t be an issue. The board doesn’t pass DRC (routing->Design Rules Check) that can be a problem with translates in parts. That said it is better to have DRC pass because sometimes the clutter is masking a real error a;though a quick visual check of the gerber output doesn’t show one. This is a capture of the gerbv output for your board:

As you see, here the miniplayer has pads and holes (its holes are a little small, around 0.036in where .1 square headers are normally 0.038in which may be a problem) but there. Also of note is the only 4 mounting holes that are being drilled are the 4 purple ones (that being drill layer) on the 4 corners. That means the rfid reader is only being supported by the header pins which may be a problem unless there is additional mechanical support off board. Also the SMD mosfet as noted (again circled in red here) is under the Lolin32 board on the top side. I would move the Mosfet towards the bottom edge of the board to give your self additional clearance and airflow from the Lolin board.

Capture

from this capture from pcb view, you look to have room to move the mosfet down towards the mounting hole (and maybe left to clear the mouting hole) to clear the lolin board. The red markers on the traces just above the mosfet are where DRC is complaining about lack of clearance. While you should be able to clear that by moving the traces, when I do so DRC complains about the edges of the header pads (which it shouldn’t.) That indicates to me the problem is likely translates in the player mini part that are affecting DRC and the only way to fix them is to fix the underlying part (which I’m currently too lazy to do, although as it is in core parts it will eventually get fixed for both hole size and translates.)

Peter

Part request - Arduino MKR WiFi 1010

$
0
0

Neither have I. There was a bug report on github about this part (it was recently closed though, so you would need to search the closed reports), but the person reporting it never provided a source for the part. There is a MRK Wifi 1000 from SteelGoose here:

and I understand the pinout is the same so this should work for the 1010.

Peter

Png with Background Color?

$
0
0

I do it on finished projects so I have a colored image to use for Icon’s and Folder’s…

This GIF shows the basic steps (I did not complete it but, you get the idea…)

There are different ways to do it in Inkscape so, explore… You can set default colors and can use other Tools in Filter Menu, too…

Also, another example using PaintBrush… simpler than using Inkscape…

mov

Part: Connector Numbers

$
0
0

I’ve made quite a few parts and generally don’t bother worrying about this kind of “stuff that isn’t perfect” when they’re for my own use. But…

… it is annoying to have an unsolved mystery like this:

Connectors seem to always start at “connector0” but, adding connectors skips a number.
For example (screenshot) shows: connector2 then the next one is connector4.
Question1: What happened to “connector3” ?

I’ve repeated this starting with only 1 connector (connector0, Name = pin1) and when changing the number of connectors from 1 to 5, for example, connector1 gets skipped and continues from connector0 with the next one being connector2, not connector1.
Question2: How to correct this and get sequential connector numbering ?

Question3: How to start connectors at connector1 (not 0) ?

Click to expand image for full graphics

Part request - Arduino MKR WiFi 1010


Part: Connector Numbers

$
0
0

This would appear to be a parts editor bug. Parts editor wasn’t finished when development ceased so it has both bugs and parts that are incomplete (that is part of why I don’t use it). It doesn’t support a number of elements: bendable legs for one, split copper0 and copper1, and probably others I don’t know or remember at the moment. Hopefully with development restarted this will improve. That said, I don’t remember hearing of this particular fault before.

I expect the only way is to edit the fzp file with either an editor or a script that will change all the sequence of connectors back to what they should be (on a large part that is a lot of work unless scripted!) I tend to delete the connectors entirely and replace them with boiler plate generated by this python script.

I then have to edit the fzp to add back in the pin name and description fields. Not the desired workflow, but less work than trying to fix parts editor at the moment. I think a complete rewrite of parts editor in javascript is still proceeding although I haven’t heard anything of it lately.

You can do that in the fzp file and nothing I know of but the parts check script objects. The part file format does however specify that connectors should start at zero and be sequentiaI, so something may break if that isn’t true (but I don’t know of anything, many of the eagle2fritzing parts start on non zero pins, and are not sequential and appear to work fine. I think the reason here (but no one that would have known was still around when I joined Fritzing) is C++ array addressing (which starts at 0) against common pin numbering (which starts at 1.) For internal storage, pins starts at 0. (so you don’t waste the first array slot in every part.) For external display it starts at what ever pin number you set. If the pins are not sequential (possibly only in parts with subparts because that is the only place I’ve seen it happen), the “hover on the pin and get the description” function screws up. For pin sequence (internal) 0, 1, 3, 4, 0 and 1 display correctly, 3 gives random garbage and if I recall correctly 4 gives the data for 5 (it has been a couple of years since I discovered this) and it recovers on 5. I think I tried to reproduce it on non subpart part and failed so it may need subparts to fail.

Peter

Part request - Arduino MKR WiFi 1010

$
0
0

There are eagle files for this board. I may have seen them the first time, but waited to see if the broken Fritzing part was available before doing anything about it. I’ll generate a part from the eagle files via eagle2fritzing and post it in a bit.

Peter

Part: Connector Numbers

$
0
0

Thank you.

I figured out a similar answer… after using a different starting part to work with. Generally I use the Antenna part - it’s clean and works well.

I used the Mystery part for today’s part starting point and that was the problem.

Anyway, after editing/tweaking the .fzp, I have what I want… Screenshot of it in the Inspector.
(FYI - though not a part of this Part, I’m now able to include tables, boxes…etc in the .fzp (you’ve seen some parts with tables etc, CSS is the trick to use in .fzp). And, I was able to use a real photo (or .png) for the Icon (after tweak in Gravit).

46%20AM

DFPlayer Mini ESP Board - No Copper in Holes

$
0
0

Thank you for sharing your expertise on my pcb design.

The RFID won’t be placed on the board itself, so I have replaced it with a 8-pinheader. So the drillholes are okay. I did the same with the dfplayer to fix the problem with the wrong sizes. I would even fix the part myself, but I don’t know what is exactly to do…
The LOLIN32 and the DFPlayer will be placed onto pinheaders.

I have moved the SMD part to the edge.

The DRC problems where only existent because I increased the configuration to have more space between the traces. Otherwise autoroute putted lines beween the dfplayer pins. I set it back to the “professional” settings and everything was fine.

DFPlayer Mini ESP Board - No Copper in Holes

$
0
0

That is to the good, the DRC errors looked ok, but a similar issue recently turned out to be masking a real error once I fixed up the offending part. Does the fab now accept the mini player pads? I don’t see why they should have been missing on the original because the proper pads appeared to be in the gerbers.

Peter

Viewing all 31215 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>