Tracks wont connect to ublox SAM-M8Q

This is probably a dumb question with a simple answer. I am using the ublox SAM-M8Q GPS and my tracks won’t connect to the pads. I’ve tried numerous track widths. What do I do?

This is what pad looks like
Capture2

Edit: I fixed it. Thanks for the help everyone. :smile:

There are multiple pads overlapping. Make sure all of them have the same pad number assigned.

Try these footprints. They are designed for assembly using a solder paste. Version with suffix _MP has additional mounting marks.
U-blox_SAM-M8Q.kicad_mod (10.3 KB)
U-blox_SAM-M8Q_MP.kicad_mod (11.0 KB)

1 Like

Which one is the one you use right now. (you only get free checks for anything else if you create a pull request over at the library repos :wink: . Fair warning: The result of that free check might be that the footprint requires complete redesign to fit our guidelines.)


Edit: just noticed that you are not the original poster. You can still add these to the official repo if you think they are fitting in.

As i have been an idiot here a full review of the footprint supplied by @Haz against the datasheet https://www.u-blox.com/sites/default/files/SAM-M8Q_HardwareIntegrationManual_(UBX-16018358).pdf page 10/11 (not listed in the footprint description but first result on google for me.)

I only found a minor issue regarding the outline of the inner details. (So my assessment is: this footprint is ok to use but would need additional work for being included in the official lib.)

If this footprint should be included in the official lib then the current polarity marker on the silk screen would need to be removed (the fact that only this corner is missing silk would already be an option for a pin 1 marker. Better might be to only remove the vertical line on this corner. So similar to how qfn footprints are handled in the lib.)
The description field would also need to be filled with a bit more detail including the link to the datasheet and the 3d settings would need to be filled out in the default way.

None of these issues would speak against using this footprint

I now also checked the paste pad layout. Sadly this has a minor mistake as well. (this might not really be an issue in most usecases. Would still be a good idea to fix.)

Thanks @Rene_Poschl for the review. We are going to correct these footprints according to your remarks and make the pull request to the kicad libraries.

1 Like

If you create a pull request maybe point to this topic as it will make the process faster.

Sorry @osiiris for highjacking this.

After looking at the footprint by @Haz i am quite sure you have 4 pads inside every pad to get the paste layout as requested in the datasheet. However you have enabled the copper layer for these 4 pads. This means they count for DRC. You also did not assign a pad number to them. (conjecture from what i see in your screenshot.) This means kicad wants them to be connected to nothing.
So there are two solutions to fix your personal footprint:

  • remove copper from these pads that normally should only supply paste.
  • add the pad number of the larger pad to the 4 pads (for every set of 4 smaller pads within a large pad)

The first option is the best option as it also guarantees that the paste pad sizes are not influenced by outside settings.


Another valid option is to use the footprint by @Haz as it is now, or if you want wait for their pull request and use the finalized (fixed) version.

The problem of paste pad layout has already been fixed in the github repository already.

Which repo are we talking about? There is no pull request on the official repo. The footprints above have been directly uploaded to the forum, they do not point to a repo.

The footprints and the fix for stencil (F.Paste) is already on kicad footprints master.

I can later try to make the fixes you found.

1 Like

Meaning @osiiris probably used the footprint from the official library before this fix was introduced.

I however looked at the one by @Haz which i guess is their own footprint. (silk screen look different at least) So i am not sure if the footprint currently in the lib has the same mistakes. I can check it this after work.

I now also checked the footprint found in the official library. It looks good. (None of the errors that are found in the one by @Haz and as already reported above by @jneiva the originally reported issue is also fixed.)

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.