In the pic above we are looking at an alternate method of powering the PineA64 with DC-IN on the Euler Bus; +5v on pin(4), and ground ( - ) on pin(6).
In this pic above white is common (ground) and black is 5v ( + ) the 'hot' wire. Electrically, pin(2) and pin(4) on the Euler bus are connected to DC-IN on the micro usb power jack (see schematic pp6 of (19)); if a person is careful, either method may be used to provide 5v power to the PineA64 board. WARNING: do not do this if you are not sure of your skills, nor if you are unsure of the theory. Check with someone skilled before proceeding.
There are a couple of reasons why you might want to connect DC-IN with this alternate method: 1) you may want to provide your Play Box with a 5v barrel connector for charging, 2) your power supply is only rated at 2.0A (5v) and you want to shorten the supply line and bypass the weaker micro usb connector, 3) you want to make a more solid power connection perhaps with a [ toroid | cap ] low pass filter for use in an auto or with other dc-dc converter.
Normally I do not recommend this method; because it has the potential for making mistakes; only connect 5v on DC-IN, never reverse the polarity of the wiring (always check, never guess); that said, this method does provide an alternative for routing DC-IN for those who have the skills and know what they are doing.
WARNING: If you're looking at the schematic(s) pp12 of (19) the 5v on pin(8) is NOT a DC-IN pin; pin(8) is a 5v output pin only. The only DC-IN pins are pin(2) and pin(4). Any ground pin may be used for ground; however, pin(6) is convenient for the purpose.
The purpose of this post is to discuss two power supplies, and their ratings, why they are good, and why one is better.
The pic above shows two power supplies available on the market which may be used with the PineA64 (or the Raspberry PI, for that matter). Both of these supplies are international supplies , which means they have interchangeable heads which match the mains of several different prominent world locations; these have been set to mains U.S. 120v AC. The black PSU on the right is good, the white PSU on the left is better; why?
The reason comes down to the AC rating (the size of the mains primary winding) the length of the cord, the gauge of the wiring in the cord, and the rating of the DC output volts & amps. The rating of the PSU is on the label ; the following pics show the labels of the two supplies high-lighting the positive attributes of each supply.
The black supply in the pic above is (good) has 22 AWG two conductor cable of reasonable length (about 1 meter) and is rated at the mains for .35 amps and provides an output of 5v @ 2.0A or 2000 ma. The higher the gauge number, the smaller the core diameter of each conductor and the less current it can carry effectively without adverse voltage drop. 22 AWG is good, but is not the best. A range of 18-20 AWG is satisfactory, and 22 AWG is on the low side. This power supply is only rated for .35 A on the mains side, and can only deliver 2000ma on the DC side at 5v. This also is 'good' for the PineA64 (or Raspberry PI 3) but is not the best.
The pic above shows the Raspberry PI international PSU. It has 18 AWG two conductor cable and is rated at the mains for .5A. The DC rating of this supply is 5v @ 2.5A or 2500ma. This supply is the best supply for the PineA64 (or the Raspberry PI 3) because even though its power cord is about 15cm longer, its core diameter two conductor cable is superior; also the mains primary is beefier (.5 A) and its DC output is 500ma higher for the same voltage output of 5v.
It is preferable to shorten the power cord of this supply (if possible) to further reduce the voltage drop which occurs with DC voltages transmitted over a distance (the shorter the cord, the better the stability of the switching supply).
The white supply listed above is specifically listed as a 'switching' adapter; while the black supply shown above is not. This does not mean 'for sure' that it is NOT a switching supply, only that it is not rated as a 'switching' supply and may in fact be a linear supply. A 'switching' adapter is more efficient than a linear supply, and better able to maintain a steady 5v at full rated current loads - 2500ma in this case.
This is in no way intended to be disparaging; it is intended to show what is available and high-light the differences.
I have been testing the Ada Fruit GPS Ultimate Breakout Board with my PineA64, and have found it to be a very handy device for local GPS, and truly the ultimate breakout board for GPS gurus.
The breakout board is in the mid-ground of the pic above. I have the board connected to uart4 (ttyS4) on the PineA64 board, where I am reading and parsing the NMEA sentences from the GPS receiver using Python (codes submitted and explained below). The pinouts for the euler bus may be found here. I use a four color ribbon from the gps module (red 3v3 Vcc, green Tx, white Rx, black Grnd). The red wire plugs into euler bus pin(17) 3v3, the green wire plugs into pin(21), the whire wire plugs into pin(19), and the black wire plugs into pin(25). It is important to note that the Tx line of the module (green) plugs into the Rx pin on the euler bus; the Rx line of the module (white) plugs into the Tx pin of the euler bus. Tx and Rx cross. ( in human terms, your mouth speaks to someone's ear, they listen with their ear to your mouth!). Use the pinouts sheet from the wiki to identify and utilize the uart3 if you like. The codes will need to modified slightly should you decide to use uart3. In the pic below you'll notice that the white wire is missing; that's ok, if you're not going to be sending commands to the gps receiver, and the receiver works very well by default in most cases.
The PineA64 lith-ion batt is in the foreground with the LED lab in the background. The pic below is the verso of the breakout board showing the backup batt and holder (which may be optionally soldered in place). I strongly recommend the backup batt (and bracket) because it significantly reduces startup and acquire times... the receiver gets smarter over time, and memorizes GPS sat information as it runs.
The pic below is a close-in of the ada fruit ultimate gps breakout board clearly connected to the uart4 (ttyS4) of the PineA64. I have posted the codes below. Again , you'll notice that the white wire (used to send commands to the gps receiver is missing. The cable on the near end of this pic below is the uart0 serial console which runs over to my notebook gnu+linux system and is my interface into this board. The transmit Tx wire green of the serial cable plugs into uart0 pin(8) of the EXP header, the white receiver line Rx plugs into pin(7) of the EXP header , and the black wire (grnd) plugs into pin(9).
The codes listed below are a simple Python script that parses the primary NMEA sentences for local display making some sense of the otherwise cryptic messages typically received by any GPS receiver. The code has been tested on gnu+linux (lennyraposo debian mate) and displays latitude, longitude, time, date, altitude, and satellite position for fixing sats. The codes should be run as root; while they are intended to get a person started, they may not be robust enough for direct application , and may or may not be suitable for a particular purpose.
ada_fruit_GPS4.sh
Code:
#!/usr/bin/python
##
## ada_fruit_gps4.sh
## v.01a
#
#*****************************************************************
# author: Mark H. Harris
# license: GPLv3
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
# CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
# INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
# MECHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
# DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENCIAL DAMAGES (INCLUDING, BUT
# NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
# LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE
# EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
#*****************************************************************
##
import serial
## SERIAL PORT SETUP PINEA64 UART4
#
uart4 = serial.Serial(port="/dev/ttyS4",bytesize=8,stopbits=1)
uart4.baudrate = 9600
## MAIN TRY BLOCK WHERE WE ATTEMPT TO PARSE SOME NMEA SENTENCES
#
while(not kb_interrupt):
try:
cline=uart4.readline().split('*')
dline=cline[0].split(',')
if (dline[0]=='$GPGSV'):
if (dline[2]=='1'):
gsvflag=True
for n in range(4,len(dline)-3,4):
svndct[dline[n]]=(dline[n+1],dline[n+2],dline[n+3])
continue
if (dline[0]=='$GPRMC' and count==0):
print("\n"+gprmc)
gprmc="time: "+dline[1]+" date: "+dline[9]+" "+dline[4]+": "+dline[3]+" "+dline[6]+": "+dline[5]
count+=1
else:
if (dline[0]=='$GPRMC'):
count+=1
if (dline[0]=='$GPGGA' and count==0):
gprmc+=" El: "+dline[9]+" "+dline[10]
print(gprmc)
ggagsa=" sats: "+dline[7]
ggagsa+=" type: "+GGAFIX[dline[6]]
svns=int(dline[7])
if (dline[0]=='$GPGSA' and count==0):
dsvns=[]
for n in range(svns):
dsvns.append(dline[3+n])
## print("svns: "+str(dsvns))
ggagsa+=" mode: "+GSAFIX[dline[1]]+" "+GSAFIX[dline[2]]
print("\n"+ggagsa)
print("\n SVn: ('El', 'Azi', 'dB')")
print(" ----------------------------")
if (gsvflag):
for svn in dsvns:
print(" "+svn+": "+str(svndct[svn]))
if (count>=5):
count=0
except KeyboardInterrupt:
kb_interrupt=True
uart4.flush()
run with :
sudo ./ada_fruit_gps4.sh
The breakout board will flash once every second until a fix is established; thereafter it will flash once every fifteen seconds.
The codes listed above will work with other GPS receivers, but may need to be modified for display depending on the order of NMEA sentences the GPS receiver provides and how often the receiver updates the GSV sentences; which are updated by the ada fruit breakout every five cycles (or every five seconds).
Hey all... I just thought I'd toss this out there in the hopes that it saves someone the frustrations that I went through.
I've searched and found more than a few threads about people wondering if their boards were dead when they first get them.
Symptom: Plug in an LCD, either HDMI or DVI/Adapter, and when you plug the power in, the red LED comes on, but there's NO life
to the screen at all. I first attempted an Android image, then a Debian. Neither made any difference.
I was using an Acer 22" LCD monitor, Model X223Wbd. It's Max Resolution is 1680x1050.
I'd come across a few posts about the software for the Pine A64 not being quite up to snuff yet on "video detection" for lack of a better term.
My primary home computer is an Asus Gaming Laptop, and I didn't have a full HD 1080p monitor lying around, BUT, I do have an Epson full HD Projector.
After running out of options, I plugged the Pine A64 into my Projector, and Bingo! That was the issue. It fired right up and within less than 30 seconds, I was
looking at the Debian Login screen. As I type this, I'm about to change the resolution on the Pine to 1680x1050, shut it down and then see if it'll fire up
on the Acer now.
I've waiting from june the shipment RS907614952CH. My local post office indicate that You need to make a complaint with your local post service because it's lost.
However, I noticed that the LED isn't as bright when I use any of the PL pins. I don't have much experience here so could anyone explain the reason for this?
I also couldn't get PL10 to work at all as the LED wouldn't come on. All other pins on the Pi2, Euler and Exp bus work fine, however. Could this be a problem with my board or is there something I have to set to use this as an output pin?
Just for reference, these are the PL pins I tested GPIO Pin No. PL10 362 8 (Pi 2) PL9 361 27 (Pi 2) PL8 360 28 (Pi 2) PL11 363 7 (Euler) PL7 359 2 (Exp)
I ordered a PINE64 A64+ 1GB board on 24/02/2016, but I never received any tracking number and still wainting for the board (about 6 months).
Order #102223072.
