not enough voltage on GPIO14 on pi3 about lipopi HOT 20 CLOSED

Ahh I think this is because the Pi3 doesn't have a real UART on the GPIO. The UART on GPIO14 on the Pi3 is emulated in software because the actual UART is now used for the Bluetooth.

Try the following in the boot config file:
enable_uart=1

If that doesn't work try disabling the bluetooth and see if it makes a difference:
dtoverlay=pi3-disable-bt

If that still doesn't work try both at once :)

Let us know how you get on....

from lipopi.

Hmm. does work partially. when enabling console, it works, but because of al the messages there is enough 0 volt to trigger a power down without a proper shutdown command. Disabling BT does not change something

from lipopi.

could i swap tx and rx? it seems the GPIO15 does carry 3.3v. we can live with a minute without power warning i think

from lipopi.

GPIO15 has 3v3 straight from power up?
Or after a minute after start up?

from lipopi.

straight up, but with a very weak pullup. and. its not pulled low at shutdown. so a dead end. :-(

from lipopi.

I thought so. Unfortunately as far as I know GPIO14 was the only way to do it :(
I don't have a Pi3 so I can't test but it may be the case that you literally can't use a Pi3 :(
If that is true I will update the instructions...

The only other thing you could do would be to monitor the output from the power LED on the board or something like that. It would be tricky though and involve working out a circuit and surface mount soldering.

from lipopi.

I've attached a DSlogic to all the pins and 14 is the only one with the behaviour we need. bu i was thinking in another direction: as serial console is enabled, maybe we could bridge the zero volt pulses with a big capacitor and a slightly larger resistor going to pin14. but i have not tested the setup yet as i am not in my lab and took only some resistors with me. it seems that enabeling the console does not influence the battery sensing ability

from lipopi.

I think you might need diodes because 1 is a source but 0 is a sync so it would actually drain the cap?

from lipopi.

if the pulses are small enough (115200) and using a sufficient high resistor like 60k could do the trick. i will test tomorrow as I am heading home right now. a diode is just the opposite of what you want: the signal should go low to shut down the machine. the databurst is short enough for the capacitor to revive. Hmm maybe a forward diode paralel to the resistor can help in recharing the capacitor...

from lipopi.

Yeah I'm guessing voltage drop on diodes would be the issue.

from lipopi.

well, simulations in LTSpice show that using a 1uf capacitor over the 100K resistor should work, taking in account that in the character A there are five successive zeroes in a byte, resulting in a dip of 52us. as it is 23:24 here, i will try that tomorrow and get back to you

from lipopi.

It works now. You don't even have to press the button for more than a instant to boot the pi. I only put an 100uf 10v capacitor parallel to the 100k resistor. This is just enough to bridge the short period during booting that the serial port is not yet up.
So to recap: keep the serial console running on the pi and place a 100uf 10v capacitor parallel to the 100k resistor.
As I am using this setup to monitor power loss, I changed the script somewhat because I sense another pin on the chip: !PG. this signal goes high when power is lost, so i had to change "!=" to only "=" in line 20 of the low_bat_shutdown script. I also followed that condition on line 20 with a sleep 25 and another copy of line 20 inserted on line 22 so if the power is interrupted briefly by a loose powercord or a change of power socket in your room, the pi stays on for at least another 15 seconds before issuing the shutdown command.

from lipopi.

Thanks for your help with this Simon.
I've updated the readme in a number of places (search for Pi 3) and added you as a contributor. Let me know if what I've added is wrong (or do a pull request) or if you would like to change/remove your contributor entry.

from lipopi.

Sorry to reopen this... but I'm testing my pi_power set up on a Pi 3 (which uses the same power up/power downcircuit) and it works fine with the 'regular' set up - i.e. no capacitor and the serial interface disables in raspi-config...

My setup is a Raspberry Pi 3 Model B v1.2 (2015) running Raspbian Jessie (I believe - the login says Linux raspberrypi 4.1.19-v7+ and /etc/debian_version says 8.0

Simon, what was your board ? I'll try and reproduce it

thanks

from lipopi.

I don't have it here at the moment as the installation is at someone elses place. next week I will be there and get back to you.

from lipopi.

Hmm... in my Pi3 / PowerBoost 1000C setup I had connected the PowerBoost output USB +/- pads directly to the Pi 5V and Ground pins on the GPIO connector, which is supposed to work (and does) but I was seeing some weirdness - when powered down the blue LED on the Powerboost would flicker dimly - unplugging the HDMI cable to my monitor fixed this... so there was some current passing back from the HDMI ?

So I wired up the PowerBoost USB output through a regular cable to the Pi USB power input - and in this configuration I needed to use your solution for the Pi 3...

Never change more than one thing at a time... I should know that by now

I'm doing some more testing right now

from lipopi.

Hey guys, commenting here to ask a related question: With the same circuitry, on my pi 3 I need to hold the power button for around 20 sec for it to stay on. If I hold it for only a couple of secs, it starts to boot but at some point it looks like the tx pin goes low, so I need to hold it for around 20 secs or so, til it finishes booting. Have you see this?

from lipopi.

The Pi3 is messed up due to the fake UART. Did you follow the Pi3 specific instructions?

from lipopi.

After getting clarification from Rob and Daniel on the pi_power project (thank you), I have been working on a project in which I have implemented pi_power with some modifications. In short, the schematic was followed as prescribed, except I grounded the 1000C. With respect to software control, I remapped all original GPIO usage to avoid conflicts with the comm (UART, I2C, SPI) and EEPROM GPIO functions I needed for the project, and to use physical GPIO pins on the header more suitable to my IC and component placement on the stackable Pi HAT I built from a PCB blank (soldered and wire-wrapped). I ended up remapping GPIO BCM pins as follows:

pi_power (Modified pi_power)
26 (27)
20 (18)
21 (16)
25 (13)
24 (06)
23 (05)
18 (12)
14 (26*)

*I use GPIO BCM 26 to simulate the action of the GPIO 14 (UART-TXD) during the boot process by first setting GPIO BCM 26 mode to output and then writing a 1 to GPIO BCM 26 (setting it high) immediately afterward. I currently do this via rc.local (soon to be deprecated), so I'll move it to systemd later on. In addition, in the user_shutdown_setup() function of pi_power.py, I had to insert a time.sleep(2) function call between the GPIO.setup() and the GPIO.add_event_detect() functions for the "shutdown_pin"; otherwise, the Pi will shut down as soon as the GPIO.setup() function is called to setup the "shutdown_pin". I also had to measure actual resistance of the resistors in the voltage dividers to calculate Vout, and run stress tests to determine actual high and low limits of my 6600 mAh LiPo battery...it mattered...especially with the resistors I used (+-5% my bum :) ).

So...for those with similar GPIO conflict problems, this is very doable as it has been stable for several weeks during further development of the project. I suggest, however, that if you try to do this using the original pi_power design, you first develop a GPIO conflict matrix for your design and a board layout and soldering map for your stackable Pi HAT to ensure that you minimize wire run lengths and optimize placement of your components. I even found room to include access headers on the HAT for both used and unused GPIO pins, which makes for easy troubleshooting and expansion.

ADDITIONAL QUESTION: Will an increase in capacitance (e.g., say doubling by placing an additional 100uF capacitor in parallel with the 100uF capacitor that is already in parallel with the 100k resister to ground in the Pi 3 power circuit) allow a consistent reboot of the Pi via the Pixel GUI or "sudo shutdown -r now"? The reason I ask is that more than 50% of the time with the current design I can perform such a reboot, but other times it fails. I haven't tested additional capacitance yet, because my new stackable Pi HAT is buried in its enclosure, I am in too many development rabbit holes at the time to step back to this part of the project, and I thought someone out there more knowledgeable that I am regarding circuit design may know off the top of their head. If someone out there is remotely sure that the concept would at least work in theory with the Pi 3 and this type of pi_power design, I will try to increase capacitance until it works consistently and let you know.

UPDATE: (03-08-17) - I doubled capacitance by placing an additional 100uF capacitor in parallel with the 100uF capacitor in the original circuit (i.e., the one that is in parallel with the 100k resister to ground for the RPi 3 circuit). Since my original post, I have been cutting code daily in my application's kernel, which has required many system reboot events during development and testing. I have had no instances where the reboot process has failed...it has consistently rolled over, latched and powered up. Given the number of times I have had to reboot, I call this doubling a success. As a caveat, if a Pi 3 system is configured differently, requiring a longer reboot, the 200uF solution may fail...but the concept of increasing capacitance appears to work.

Here are a couple pics of the stackable Pi HAT:

from lipopi.

I think you meant to thank Rob rather than me :)
With reference to the capacitor I think I would find a value by trial and error, it would be hard to guess what would work.

from lipopi.