# Sharing GND pin with several wires



## balanga (Feb 19, 2018)

Apart from using a breadboard is there any way to connect several wires to a GND pin?

I've been looking for some sort of connector, but can't find anything suitable...


----------



## SirDice (Feb 19, 2018)

A soldering iron can do wonders.


----------



## obsigna (Feb 19, 2018)

SirDice said:


> A soldering iron can do wonders.


Yes, and for somebody who is not ready to solder, a plain screw terminal could do a good job as well:


----------



## Datapanic (Feb 19, 2018)

I would ground the several ground wires to chassis or a bus bar to chassis and then have just 1 ground wire going to the connector.  Depends on the application.


----------



## unitrunker (Feb 20, 2018)

There isn't enough information here to give a proper answer. Please provide a context. Ground pin to what? Is it a chip? Socketed? Soldered in-place? Analog or digital?

Normally you don't connect "several wires to a ground pin". You connect each pin (that needs to be grounded) to ground - where ground is a relatively thick trace on a circuit board or one of the two power-bus rows on a breadboard. 

Ground wires should be kept short. If you are adding a jumper to an existing circuit board, you will often find a spare solder-able ground location on a nearby capacitor. Visual inspection plus an ohmmeter can confirm which pins are connected to ground. Given multiple choices - pick the closest one.


----------



## ralphbsz (Feb 20, 2018)

Second what unitrunker said.  You need to provide context.  Here is an example of a detailed question: You are using a RPi2, and you are wire-wrapping wires directly to the 40-pin GPIO connector, and sticking the wires into the Frankenstein monster you are assembling in a transsylvanian castle (please watch Mel Brooks "Young Frankenstein" for some amusement).  You are sticking a GPIO pin into each digit of the monster (for the dirty jokes from the movie regarding some digits, you'll have to watch it yourself, explaining the jokes here would violate the CoC).  Every GPIO pin requires a matching ground wire attached to the table, and you don't have 11 ground pins.  Unfortunately, your blonde and very well-endowed assistant Inga doesn't know how to solder, and Frau Blucher has hidden the only breadboard for the RPi2.  So how to use out the few ground pins on the RPi2 connector to get enough grounding to the monster's table?  Wire nuts?  Luesterklemmen?

Well, good question!  Instead of answering it, I'll fire up youtube, and watch the monster and Gene Wilder sing and dance "puttin' on the ritz" now.


----------



## Phishfry (Feb 21, 2018)

How about a screw terminal block.
https://en.wikipedia.org/wiki/Screw_terminal


----------



## Manuell (Mar 11, 2018)

With a soldering iron and a Dupont kit you can just make a 4 to 1 plug. by soldering 4x1 piece, fix the wires together and connect it sideways on the gnd-pin.

However, if you have room for it, and you can handle some voltage loss, maybe you better order some mini sticker-breadboards like these: https://nl.aliexpress.com/item/7PCS...derless-Prototype-Test-Board/32311122381.html


----------



## Phishfry (Mar 12, 2018)

I ran into this problem last night. I was attempting to build a multiple GPIO pin OneWire device tree overlay. The mechanism for Linux doesn't work so I built my own overlay with muptiple pins for separate onewire buses. Each bus is limited to 10 devices.
I kept having troubles as the pins would work in one arrangment but in 2 seperate busses only 1 bus pins would show devices.
The other the bus was erroring out.
So I added a second power and ground to my breadboard for the second onewire pin and all the sensors worked fine.
It was a ground problem all along. Separate onewire buses did not work with a shared ground.

So this is a good example of why a shared power source for multiple IO pins is bad. It looked like a software issue but was hardware.
I can't tell you how many times I redid that overlay. I tried every possible combination possible from the 3 examples.
In the end it was the last gasp of trying a separate power source that solved my 8 hour struggle.
Yes the GPIO power and ground pins are limited so plan accordingly. I was able to power my RTC sharing power/ground pins.
Some of the problem with my setup is there is a parasitic mode that the ds1820 onewire temp sensor can run in. It shares data and power line. I am using all 3 wires to my sensors so maybe parasitic mode is the reason. With a shared power line to the two buses maybe data was leaking over. Supposedly FreeBSD onewire does not support parasitic power. I did not address that in my overlay. I should have disabled it. I noticed the RPi W1 overlay has a parasitic setting.


----------



## Snurg (Mar 12, 2018)

Phishfry 
Interesting!
Do you experience that problem also if you solder instead of using a breadboard?
I wonder if that could be caused by breakdown voltage of the oxide layers involved in breadboard connections.


----------



## Phishfry (Mar 12, 2018)

No I think onewire bus data is leaking over the power line causing OneWire bus error. Just a wild guess.
I need to explicitly disable parasitic to test this theory.
Could also be a ground problem. I had problems in the past with multiple OW buses and I bet it is related.


----------



## drhowarddrfine (Mar 12, 2018)

I've been designing hardware as an electronic engineer since 1974 till 1995 for everything from medical computers to cash registers to computer graphic workstations. I mostly switched to software, though I still do hardware projects for theatre companies, and I just want to say that I have no clue what you are talking about.


----------



## Phishfry (Mar 12, 2018)

https://en.wikipedia.org/wiki/1-Wire
I am inputting 1 wire temperature sensors on the Beaglebone. I am using a 3 wire configuration with power, ground and onewire signal. I can only use 10 onewire devices per bus(pins on Beaglebone)
So I wanted to add more pins for more 1-Wire temperature sensors.
To do so you have to modify the device tree. This describes the hardware to the OS similar to plug and play.
So I have to tell the device tree that another pin is now input for onewire data.
To do that I modify the Linux device tree overlay library. This is where devices are cataloged for non-plug and play devices.
Like Arm powered Device Tree boards without plug and play.
https://source.android.com/devices/architecture/dto/
So the standard Linux pin overlay for onewire is for only one GPIO pin use. Like I said I want multiple GPIO pins for onewire. So modifying the device tree overlay is like a black art. There are no instructions. You just need to try things and see what the result is.

I tried from 3 different Linux examples and modified with my knowledge of what the FreeBSD to Linux differences are in the device tree structure.

I could tell from dmesg output that the device tree overlay I created for two pins worked correctly and was actually assigned to the GPIO pins in the proper input capacity.

So then I went looking for culprits to the onewire bus errors I was seeing in dmesg and considered powering the second GPIO onewire pin sensors with a second set of power leads coming from the Beaglebone.
The average plastic breadboard has accommodations for power pins on both sides. I usually only supply 1 set of power connections to the breadboard for all the sensors to share.

I have found that such an arrangement did not work correctly for me and when I supplied a second set of power leads to the breadboard the second onewire bus stopped erroring out and sensors were available.
So each onewire pin needs a separate set of power connectors.

Using 2 onewire pins with one set of power leads for powering the sensors caused the onewire bus errors.
The onewire temp sensors I use have 4K7 resistors on each board.

There is a software mode to turn off parasitic power in the device tree overlay.
I will try that to see if I can isolate the two buses. With parasitic power on and a common power source I can now see trouble.

So this was really a story about troubleshooting. How a hardware power problem led to onewire bus errors.
Similar to sharing a bunch of GPIO grounds and trying to troubleshoot.

Anyway welcome back doc. I have really missed your critiques.


```
owc0: <FDT GPIO attached one-wire bus> at pin 15 on gpiobus3
ow0: <1 Wire Bus> on owc0
ow_temp0: <Advanced One Wire Temperature> romid 28:ee:ba:09:2f:16:02:74 on ow0
ow_temp1: <Advanced One Wire Temperature> romid 28:ff:4e:51:70:16:05:c2 on ow0
ow_temp2: <Advanced One Wire Temperature> romid 28:ff:61:b3:70:16:04:45 on ow0
owc1: <FDT GPIO attached one-wire bus> at pin 14 on gpiobus3
ow1: <1 Wire Bus> on owc1
ow_temp3: <Advanced One Wire Temperature> romid 28:ff:a8:08:70:16:04:91 on ow1
gpioc3: <GPIO controller> on gpio3
```


----------



## drhowarddrfine (Mar 12, 2018)

The only suggestion I have, if I'm understanding this correctly, is to make sure a 4.7K resistor is the right size for pulling the pin all the way down or all the way up and the signal isn't hanging somewhere half way between.


----------



## krisb (Mar 12, 2018)

Phishfry said:


> https://en.wikipedia.org/wiki/1-Wire
> So each onewire pin needs a separate set of power connectors.
> 
> Using 2 onewire pins with one set of power leads for powering the sensors caused the onewire bus errors.
> ...



If you are using parasite power mode make sure you have also strong pull-up (in addition to weak pull-up via 4.7k resistor). Otherwise even 2 sensors on the bus will drain too much current for weak pull-up while in conversion mode (can be even 1.5mA each so then voltage drop across 4.7k resistor will not leave enough voltage for sensor to operate, minimum is 3V). Hence you may be observing errors.
It is explained in sensor datasheet:



> However,  when  the  DS18B20 is  performing  temperature  conversions  or  copying  data from the scratchpad memory to EEPROM, the operating current can be as high as 1.5mA. This current can cause an  unacceptable  voltage  drop  across  the  weak  1-Wire pullup  resistor  and  is  more  current  than  can  be  supplied by Cpp. To assure that the DS18B20 has sufficient supply current, it is necessary to provide a strong pullup on the 1-Wire  bus  whenever  temperature  conversions  are  taking place or data is being copied from the scratchpad to EEPROM. This can be accomplished by using a MOSFET to pull the bus directly to the rail as shown in Figure 6. The 1-Wire  bus  must  be  switched  to  the  strong  pullup  within 10μs  (max)  after  a  Convert  T  [44h]  or  Copy  Scratchpad [48h] command is issued, and the bus must be held high by  the  pullup  for  the  duration  of  the  conversion  (tCONV) or data transfer (tWR = 10ms). No other activity can take place on the 1-Wire bus while the pullup is enabled.



Here on page 7 you have correct wiring in case of parasite power (how to connect MOS) and for external power.
Generally you do not need additional power leads if one can deliver sufficient current, and provided wiring is done correctly.
And from experience - when you are done with breadboard also check with long wires - this is where I had most issues with transfer due to parasitic capacitance introduced.
Hope it helps

*edit - and please check in datasheet of the chip you are using how much current you can drain from a pin. I think for Beaglebone it is just few mA which might not be enough for couple of sensors. If that is the case then you can only use external power, not parasite mode.


----------

