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.
I've been really interested in getting a Pine64 as a means of toying with a baremetal [i.e. without an OS] machine along with a moderately powerful GPU. In particular, I was looking to write a minimal graphics library without an OS and I was wondering if anyone had already tinkered with the GPU instruction set for the Pine64 and gotten some examples to work.
If not, I was wondering if anyone could point me some examples of baremetal on the MALI400-MP2 or some documentation about how to interface with it.
This procedure is new so it may have issues. The key feature is that all of Android and lichee are in git. That means you can clone the repos (look in the manifest files), make changes, and then send pull requests. Then use 'repo sync' to get everyone's changes.
Anyone up for getting this working on the longsleep kernel so that we can get rid of lichee?
You need 100GB free disk space, it uses 96GB.
This takes around nine hours to run depending on network and CPU speeds. $ mkdir ~/bin
$ PATH=~/bin:$PATH
Download the Repo tool and ensure that it is executable:
$ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
$ chmod a+x ~/bin/repo $ mkdir android
$ cd android
$ repo init -u https://github.com/pine64-android/manifest.git -b master
$ repo sync
$ . ./build/envsetup.sh
$ lunch (tulip_chiphd-user, Baomi/db1000)
$ make -j 5
$ cd ..
$ mkdir lichee
$ cd lichee
$ repo init -u https://gitlab.com/pine64-android/manifest.git -b master
$ repo sync
$ ./build.sh config (choose '0' for all)
$ ./build.sh
$ cd brandy
$ ARCH=aarch64 ./build.sh
$ cd ../../android
$ extract-bsp
$ pack image in:
../lichee/tools/pack/sun50iw1p1_android_Baomi-db1000_uart0.img This makes a Phoenix card image.
Lot's of tools for installing here: lichee/tools/tools_win To get a 'dd' image, install it to an SD Card. Boot it. Then use 'dd' to copy the image off from the SD Card.
Google Play login seems to be working in this build.
Also note that by adding items to the manifest apps like Kodi can be included in the build.
