A short while ago I posted about my first successful outgoing calls on the PinePhone, and stated that they weren’t terribly consistent and that they had no voice:
I can get the PinePhone to ring other phones – which is still a new accomplishment – but no voice comes through. Alas.
If you’re like me, you’ll now have a 1:5 (up from 0:5) chance of being able to successfully dial out.
That has changed, due both to a software update and a trick.
Stick to the Dev Channel
I can’t speak for the Stable channel, but at least with Dev Version 61 outgoing calls have crystal-clear voice 100% of the time.
Lose the Extra G
Browsing the UBPorts Forums, folks indicated that UBPorts doesn’t have a good time with VoLTE (Voice over LTE), and thus can’t pull off 4G calls at all. Normally, the phone should be able to recognize this fact and switch automatically to 3G, and I’m guessing that’s what my phone did the 1 in 5 times that it successfully placed a call.
To up that ratio to 1:1, go to Settings | Network | Cellular Settings and select 2G/3G as the Connection Type.
As part of another project, I need to be able to build software for the PinePhone, and that means I need an ARM64 environment with as much oomph as possible (trying to compile stuff on the PinePhone = bad idea).
The solution is to run a Debian VM that, in turn, runs a Qemu ARM64 emulator with a Debian image.
Nearly every step that follows is taken verbatim from this guide by Blahcat, so all credit goes there. The only reason I made my own post is because I had to change a couple lines in order to get the network working. Hopefully this brings you joy.
Get that VM going
I’m a VirtualBox guy, but you do you. You’ll also want the latest Debian ISO, which at the time of writing is Buster. I gave mine 4 cores, 4GB of RAM, and 20GB of storage.
Install Qemu
Terminal. sudo apt install qemu. Nuff said.
Download the Debian Bits
You need the initrd and kernel of the Debian installer. Blahcat’s links are outdated, so here’s the latest:
Blahcat recommends 20G, but that’s the size of my Debian VM. I haven’t managed to fill up 12G yet — but, as said before, you do you.
qemu-img create -f qcow2 disk.qcow2 12G
Invoke the Installer
This is where I depart the most from Blahcat. Every time I followed their instructions, the resulting image was unable to connect to the internet, even though it ran a blasted net installer. The solution, in my case, was to force the emulation of an ethernet adapter (in addition to the one that Qemu automatically creates). Some of the command that follows is likely malformed, redundant, or both, but by golly it worked.
During installation you’ll be asked to pick an Ethernet adapter; pick the Intel one and life is good.
Extract your fancy new kernel
Let it be known that I have no idea how half this stuff works, nor what nbd stands for. Essentially, you mount your new image, extract the kernel and initrd, and use them the next time you invoke the image.
Normally, my ASUS MB169B USB Monitor lives in my briefcase, to be used when I need two screens at a coffee shop or a client. But, given the new work-from-home reality, it’s found a new life as a dedicated spot for tiles showing email, calendar, and Slack…
…at least it does when I’m running Windows. When running Manjaro, the USB monitor has sat idle, unused, and sad.
That’s not to say that Manjaro doesn’t support the use of DisplayLink to attach USB monitors — it’s just that, like all things Arch Linux, you have to work for it; doubly so if you’re running an nVidia card.
So, here’s how I got mine working.
1. Install DisplayLink and EVDI drivers.
Do you need both? Beats me, but this is what I have and it works. Purists will do this via pacman but I’m lazy and used the GUI.
2. Install the nVidia drivers, even though they’re not very good.
This turned out to be the key step. Normally, I use modesetting as my graphics driver, mainly because it doesn’t suck. With the nVidia drivers, I get some annoying mouse flickering that I haven’t yet been able to address.
However, the USB monitor also uses modesetting, and with both on the same driver, xrandr returns the following when you try to link them up:
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 139 (RANDR)
Minor opcode of failed request: 21 (RRSetCrtcConfig)
Value in failed request: 0x0
Serial number of failed request: 22
Current serial number in output stream: 22
What does it mean? No idea.
How do we fix it? Bust out those crap-ass proprietary drivers.
Enter Manjaro Settings Manger, choose Hardware Configuration, and attain the following setup (the video-linux drivers may be optional, but they’re doing no harm so whatev):
3. Enable and configure the DisplayLink service
Per the instructions in the Arch Wiki, enable DisplayLink by typing in the terminal sudo systemctl enable displaylink.service
Then, create a file at /usr/share/X11/xorg.conf.d/20-evdidevice.conf with the contents
This is where it gets new. Gone are the days of flashing each day’s image and losing your stuff. Now, UBPorts can auto-update (w00t).
Navigate to Settings | Updates | Update Settings (the last being cleverly hidden at the bottom of the screen) and change your channel to Development.
Give the phone some time to think, and it should load the latest Ubuntu image (at the time of writing, the latest is version 54).
Nota Bene: These version numbers are not updated daily, and as such have no correspondence to the build numbers on the CI page.
3. Reboot and Update
Once the update has been downloaded you will need to reboot so that it can load. When you reboot, make sure that you’re still on the dev channel since sometimes it reverts.
4. Place a call (prayer never hurt)
If you’re like me, you’ll now have a 1:5 (up from 0:5) chance of being able to successfully dial out.
(The title to this post said “nearly” for a reason.)
5. Stay Tuned
At this rate an actual, working voice call can’t be far off, right?
So far, the only configuration that I’ve used that can pull off both incoming and outgoing calls is PostmarketOS. The steps – what relatively few there are – follow.
My preferred interface is Phosh, and I prefer to include the firefox and midori packages since the built-in browser never connects, no matter how many hints I follow.
Even though most work on the device is via ssh, it can also be helpful to install xterm.
I’ve also started including the postmarketos-anbox and android-tools packages in an attempt to get Android apps running, but that’s another story entirely.
Configure sound
Once the phone is up and running, the only additional step needed is to enter Sound configuration and set both configurations to Place a Phone Call. This accomplishes all the mappings that we were previously trying to pull off using pactl.
‘Tis Better to Receive than to Give
I don’t know why, but for some reason I can’t place calls until I’ve received one first. So make sure that your first test is a call to your PinePhone.
Celebrate your cleverness
Receive a call. Place a call. Revel in the new ability to say “hello” from your left hand and hear it with your right hand.
We all know that, when playing around with a new device, the most important thing you can do is record the experience so that others can behold your techno-wizard glory. Pics or it didn’t happen, no? Which makes it that much more frustrating that the PinePhone currently can’t take screenshots in seemingly any of the OSes that are compiled for it.
Attempt 1: The Built-In Option
I’ve been using Ubuntu Touch, since at the moment it has the most features and the least suck of the available OSes. (Technically the build is from UBPorts, but I’m going to use the terms interchangeably because I’m lazy.) Allegedly, UBPorts lets you take a screenshot by simultaneously pressing Volume Up and Volume Down, but that doesn’t work on the PinePhone – best I can gather, that only works on Android ports of Ubuntu Touch.
Attempt 2: The Command Line Option
Other posts suggest that you can use phablet-screenshot from the phablet tools package, but that too leads to disappointment, with the program freezing. Running debug mode (-d) shows that it’s trying to pull the screenshot from adb:
Since the PinePhone isn’t running Android, adb isn’t really a thing, and you’ll end up waiting forever.
Attempt 3: The Raw Option
Looks like we’re going to have to create this from scratch. All of the above-mentioned techniques essentially do the same thing: they dump the framebuffer /dev/fb0 to a file and then convert that file to PNG, JPEG, or whatnot. How hard can that possibly be?
Dump the Framebuffer
The first step is easy enough: cat /dev/fb0 > img.raw. This dumps the framebuffer (i.e. what’s on screen) to a raw file.
Figure Out Your Screen Size
The raw image file is just that: a raw stream of pixels, with no dimensions built in. As such, you next need to figure out how big your screen is. For the PinePhone, this is 720×1440 pixels. If you want to discover this yourself, you can just type fbset (sudo apt install fbset if necessary).
Get the Script
This helpful chap cooked up a lovely little Perl script that will then convert the raw image to png. Download the script, chmod + xto mark as executable, and invoke with ./iraw2png 1440 720 img.raw img.png.
NB: I swapped the dimensions. You’ll see why.
Inspect the Results
Here’s the result, which doesn’t exactly look like the Desktop:
Success!
It definitely captured a thing.
Mope!
It captured some manner of console, perhaps the TTY output? I don’t know. Evidently there are other framebuffers to be found. If you know how to find them, please do send a comment since I’m up a creek on this one.
As mentioned before by me and many, many others, the PinePhone Brave Heart edition is very much not road ready. That’s fine, but it does mean you’ll probably find yourself reflashing your device’s image a few times. What follows are the various mistakes that have led me to re-flash my phone.
Decreasing the Brightness
As soon as you move that slider, your brightness will go to nil. As in no image at all. If you have SSH enabled, you can probably set that brightness back, but there’s a good chance that you’ll make the move prior to having SSH set up. Whoopsie.
Applies To
Sailfish OS
Ubuntu Touch (only if you decrease it fully)
PostMarketOS (only if you decrease it fully)
Turning off WiFi
Under Ubuntu Touch, turning off WiFi somehow borks the radio, requiring you to toggle it off and back on. Not a huge nuisance, but not nothing either.
A lot of folk, myself included, have tried to enable voice calls by following this file.
Don’t. do. it.
The file relies on a custom kernel, and if you set your QDAI settings per this file, you will end up unable to make phone calls until you reset it to factory defaults – which you have to do manually.
Of the four operating systems I’ve tried so far on the PinePhone, Ubuntu Touch (aka UBPorts) is the most stable, getting me nearest to actually placing a successful call.
Installation
The process starts by downloading the latest image, either from the Pine64 wiki or from the UBPorts Jenkins site. Flash the image onto a microSD card using Balena Etcher or your favorite flashing tool.
First Use
Initial startup works like a charm. You’ll want to attach to WiFi since the SIM won’t initially be read. Once you’re in, hop on the Interwebs and have some fun. Just nothing that requires audio, since that’s the next step.
Enable Mobile Data
Ironically, your fancy new phone won’t be able to use any mobile functions. You need to enable the modem, this time andevery time you boot. There’s probably a way to turn the process into a startup script; I’ll report back if so.
At any rate, open the Terminal app and enter these commands (taken from this post):
Once you’ve entered the first command, the second one is a piece of cake thanks to Ubuntu Touch’s nifty keyboard. Swiping up on the keyboard reveals the cursor, which is moved by swiping around. Nice touch, UBPorts.
Enable Audio
Much like enabling mobile data, you’ll have to do this every time you start the device.
Open the Terminal app and enter the following:
sudo modprobe snd_soc_simple_amplifier
sudo modprobe snd_soc_simple_card_utils
amixer -c 0 set 'AIF1 Slot 0 Digital DAC' unmute
amixer -c 0 set 'Line Out' unmute
Optionally, add the line amixer sset 'Line Out' 100% to max out the volume (best I can tell, you’re setting the volume that 100% on the volume rocker corresponds to; i.e. if you leave this at 55% (the default), the loudest you can make your phone is 55% of its true potential).
Don’t Disable Wifi
If you do, it won’t come back. Rather, it will appear enabled, but no access points will appear and even saved APs won’t connect. To remedy, open Terminal and enter the following:
sudo nmcli radio wifi off
sudo nmcli radio wifi on
What Works
So far, I have successfully
Played YouTube videos
Surfed the web on mobile data
Rebooted the phone a bunch of times
What May Yet Work
It turns out that my cheapo FreedomPop SIM requires some proprietary app to do text and calls, so I can’t test that at present. But if the Reddits and the forums are any indication, I’ll be a lucky son of a gun if I manage to successfully place a call. Texts shouldn’t be a problem.
What Doesn’t Work
Taking a friggin screenshot. Maybe there’s another app required?
My PinePhone BraveHeart edition arrived yesterday, and the past few hours have been spent playing around with it and trying to place a basic call. Findings so far:
For Developers and Maniacs Only
The folks at Pine64 make very clear that this phone is not a daily driver, but it bears repeating: this is not so much a phone as a fun Linux project with a SIM slot. You have to install your own operating system, and none of the choices on offer claim to be even remotely road-ready. In particular, the four I’ve installed so far have had one or more of these symptoms:
Unusably slow
Can’t find the SIM
Require a light to be shined on them to display anything
Lock you out without a password
Further, even the folks online who have managed to get past the above nuisances still generally can’t get the silly thing to successfully place calls – you know, the one thing a phone is supposed to do. So again, not a daily driver.
But All Kinds of Fun to Play With
With all those caveats out of the way, the thing’s a hoot to mess with. If something goes pear-shaped, just pull out the microSD card and re-flash it. And at $150, the price point is great for a project.
What Lies Ahead
I’ll do my best to make the silly thing work, and will report back with whatever tips and tricks I come across.
Back in November I decided to try out mining XYO using the Coin app on an old Nexus 5X that I reappropriated for the purpose.
Now it's February, and I think I'm about done with the whole thing.
To be candid, the main reason is that my sentinel went through the wash, and while it looked like a fresh battery would fix it back up, the new batteries don't seem to last more than a couple weeks. As such, I'm out $12.95 for the sentinel and $7 for a set of replacement batteries. In the same amount of time, I've earned about 8,000 COIN, which, if I could convert them to XYO (that option doesn't start until 10,000), would be worth...
31 cents.
I'll probably throw a few other posts about the various aspects of the COIN app and geomining, but for now here are my main takeaways:
Great for Truckers
Perusing the Reddits, the one group of people who seem to get a decent-ish return from geomining are truckers, who spend literally all their time cruising from tile to tile. I'd wager that Uber drivers fit this description as well, though truckers have the advantage that they can geoclaim gobs of regions every cycle. Truckers, who pass from cell to cell quickly and thus need a rapid recharge cycle, are probably the only group who benefit from Pro accounts as well.
And Nobody Else
As an ordinary schlub who works in an office and either drives to work or takes a train, there's simply no return to be had. Five miles of walking net about 100 COIN, which isn't a whole lot greater than just sitting around refreshing the tile periodically while I work from my desk. Geoclaiming isn't an option either, since the two regions I can claim (work and home) are both chronically oversubscribed, making the a losing proposition for everyone involved.
It's a shame, really. The premise of geomining, as outlined on an XYO Medium post, ain't bad. Using a fleet of smartphone-armed passers-by to determine whether packages arrived is clever, and I really do hope they figure out a way to make it work. For now, though, it's just another GPS device attached to yet another freight truck.
Recent Comments