February Update: Show and Tell

Lukasz Erecinski Feb 15. 2021 90

Welcome to this month’s community update. As many of you know, we have now entered the Chinese New Year (CNY) period, which means that all manufacturing and related business activities have ground to a halt. It is always a mad rush to complete ongoing work prior to CNY, but now that the festive period is upon us we get a chance to catch our breath and evaluate the progress made.

In this month’s update we’re going to take a close look at the Quartz64 model-A, showcase headway made on the PinePhone keyboard, discuss our first RISC-V single board computer and introduce plans for making LoRaWAN a staple of the PINE64 ecosystem.

You can watch the synopsis of this month’s community update on Youtube (embedded below) as well as on LBRY and Peertube. Stay up-to-date with PINE64 news and make sure to subscribe to this blog (subscription widget at the bottom of the webpage), follow PINE64 Telegram News channel as well as our Twitter and Mastodon.

I’d like to acknowledge JF, Marek (Gamiee), Alex (clover), PizzaLovingNerd, Konrad, Biktor and Dylan for their contributions to this community update. Thank you!

This may just be the most news-packed update since July last year, so strap in for some PINE64-goodness and let’s get to it.

Video Synopsis by PizzaLovingNerd

TL;DR for this month’s update:

  • Housekeeping: Two PineTalk episodes are out!
  • Housekeeping: Pinecil back in stock late Feb/ early March
  • Housekeeping: Shipping status of PinePhone Mobian CE
  • Housekeeping: Manufacturing difficulties expected after CNY and for much of Q2/Q3 this year
  • Quartz64: Detailed specs listed and pictures of the SBC shown
  • Quartz64: Comparison to ROCKPro64 connectivity & performance 
  • Quartz64: Generic benchmarks on par with most popular SBC on market
  • Quartz64: More than a stand-alone SBC – a dev platform for future devices
  • Pinebook Pro: Production resumes in March; pre-orders mid-March
  • PinePhone pt.1: End of CEs; PinePhone to ship with Plasma Mobile on Manjaro from now on.
  • PinePhone p.1: A close look at the PP keyboard; fitted with 6000mAh battery 
  • PinePhone p.1: We decided on the keyboard layout with community – the keyboard will be programmable, for those who wish to alter keyboard functionality
  • PinePhone p.2: Opensourcing the modem – a status report by Biktor, Konrad and Dylan
  • PinePhone p.2: Modem – work done on kernel 5.11; running open userland on kernel 3.18; making phone calls from open firmware
  • PinePhone p.2: Expected modem improvements using FOSS firmware 
  • PineTime: 3 versions of InfiniTime released in short succession in last 30 days
  • PineTime: Blob-less heart rate monitoring working on InfiniTime + improvements to OTA flashing
  • PineTime: Navigation on PineTime synced to Linux or Android Phone
  • RISC-V PINE64 SBC: We’re entering the RISC-V SBC game 
  • RISC-V PINE64 SBC: Starting with an entry-level SoC combined with a RISC-V WiFi/BLE currently being opensourced (Nutcracker challenge) 
  • RISC-V PINE64 SBC: Goal to make RISC-V accessible to all at a reasonable price; fun SBC with multiple potential applications; sub $15 SBC
  • RISC-V PINE64 SBC: Stay tuned for a name reveal via riddle 
  • LoRa & LoRaWAN PINE64 integration: we are doubling down on LoRa integration – coming to all PINE64 devices
  • LoRa & LoRaWAN PINE64 integration: we will build our own base stations based on next gen technology with better range, lower power consumption & higher transfer-rates
  • LoRa & LoRaWAN PINE64 integration: Novel use of technology – text-based communication without a middleman

Housekeeping

I want to start by giving Peter and Ezra – our PineTalk Podcast hosts – a huge shutout. They’ve worked really hard on the first two episodes of the podcast and, judging by the number of episode downloads, so far their style has resonated well with the community. In the last episode they spoke to Dalton Durst from UBports, discussed the recent announcement of PinePhone Community Editions coming to a close and answered some questions from the community. PineTalk is now available on all major platforms, including Spotify and Apple’s Podcast app, and I highly encourage you to subscribe to the RSS feed

Yes, of course, you can listen to PineTalk on your PinePhone too

Over this past month we received a significant amount of feedback concerning the new PINE64 website. This included suggestions on improving the site’s responsiveness, functionality as well as a variety of various minor bugs encountered by community members. As a result, responsiveness has been significantly improved and sections of the site have been reworked to offer a better experience on mobile devices. There is now also a dedicated blog button (honestly, I was surprised to hear people had issues finding the blog on the new site) and the blog itself received some much needed tweaks to improve navigation. A number of fixes were also made to make the page less taxing. Thank you to Gamiee for his continued work on the community site and to all of you who submitted feedback and suggestions. 

As I mentioned in the opening bit of this blog entry, CNY is now upon us and there will be no manufacturing or shipping activity until late February. All Pine Store contractors in Malaysia, China and Hong Kong are now enjoying time off with their families and close ones (where permissible, of course, given COVID19 is still rampant). To those of you awaiting a response from the support or info teams, please be aware that you will not receive a reply until after CNY. If you have an urgent query concerning your shipping or order status, i.e., a query which cannot wait, then please reach out to me or one of the moderators in our chats.

I’d like to quickly touch upon the Pinecil’s availability. I get bombarded with questions about when it will be back in stock, so I’m answering the query here: stock will be available again late this month or early the next. Don’t expect it to show up in the store before the end of CNY.

I must say, the Pinecil looks good in red – picture via Dan Lien on Twitter

Before proceeding to the main topic of this month’s housekeeping section, I want to write a few words about the Mobian Community Edition PinePhone shipping status. As some of you are aware, we ran into issues with DHL shipments in late January and early February. Long story short, we effectively had to reship an entire palette of KDE CE PinePhones twice due to a DHL error. This threw a wrench into our schedule; the shipping team worked hard to dispatch as many phones as possible prior to CNY, but unfortunately most Mobian CE units ended up waiting at the warehouse to be shipped to their rightful owners. Only phones destined for Europe were successfully shipped before work ceased. Please follow the dedicated forum thread to stay up to date on the shipment process.

I’d like to finish this housekeeping section by making you aware that difficult times are ahead of us manufacturing-wise. It was a year ago to the day when I first wrote about the impact the COVID19 pandemic would have on the supply chain and manufacturing process in China. I reported on the situation more than a month before any big brand even murmured a word about the severity of the electronics shortages, which we all witnessed mid-and-late last year. You see, big brands don’t really want customers to know that their devices will not be available or in short supply. So here I am, a year later, once again being a bearer of bad news (edit: since originally writing this passage, 10 days ago or so, some reporting of the issues already begun in the media). We expect severe component shortages and major component price hikes after CNY. I am writing this to prepare you for what is to come. Production-wise, we’re entering a difficult phase and compromises will be made – there is no doubt in our minds that the emerging market situation will have a significant negative impact on PINE64. However, the extent of the impact won’t be known for at least an entire month, so let’s not worry too much about the unavoidable and hope for the least disruptive outcome. Keep your fingers crossed! I will, of course, keep you up to date on how things pan out. 

Quartz64

It is finally time for us to take a look at Quartz64 model-A, the first installment in our ‘Quartz-line’ of next generation single board computers (SBCs). The Wiki page for Quartz64 is now available for those of you who wish to study the schematics and datasheets. Keep in mind that photos of the Quartz64 depict a prototype device and some modifications to the hardware may prove necessary prior to the SBC’s release. Any changes made, however, will be very minor at this point and only implemented to remedy issues identified by developers, if such arise. In other words, although this is an engineering sample, production units will look indistinguishable from it. With the board’s layout now finalized, we’re happy to share all the details you’ve been waiting for with you.

Top view of Quartz64 model-A

Many of you will immediately notice the close resemblance, in terms of both the available I/O and general layout, that this board shares with the ROCKPro64. Both boards feature USB 3.0, alongside 2xUSB 2.0 ports and have an open-ended 4xPCIe slot, which can be populated by a variety of peripherals. The similarities don’t end here: the Quartz64 features un-populated IR and SDIO headers (current IR and WiFi/BT modules are compatible), has HDMI capable of 4K output at 60FPS as well as a DSI and CSI output and MiPi interface. There is also 128Mb of onboard SPI flash, just as on the ROCKPro64. The eMMC and mSD card slots too can be found in the exact same position on both boards. There are also FAN, VBAT and 12V power headers, situated in the same model-A layout locations. A RTC connector is also located on the PCB. The 12V header is capable of powering up-to two 2.5″ SSDs or HDDs when using our 12v 5A power supply, just as on the ROCKPRo64.

While the SBCs share many similarities, there are some significant differences between the two. For one, as you have likely already spotted, the Quartz64 has a native SATA 6.0 port located right behind the USB ports. The Quartz64 has one USB 3.0 port, while the ROCKPRo64 has one USB 3.0 and one USB-C port. The Quartz64 PCB also features an integrated battery charging circuitry. This means that, similarly to the PINEA64-LTS, the board can be completely battery operated. A unique feature of the Quartz64 is its native e-ink port; as I already mentioned in last month’s update, we hope to have a 10″ e-ink panel available in the Pine Store when the SBC releases to the public. Perhaps most importantly of all, Quartz64 is capable of supporting up-to 8GB of LPDDR4 RAM.

Front view of Quartz64 model-A

Back view of Quartz64 model-A

Performance-wise, early testing indicates that the Quartz64, with its 4 cortex A55 cores clocked at 1.8Ghz, is only 15-25% slower in computational tasks than the ROCKPro64. Do keep in mind, however, that the Quartz64 isn’t a Pro-grade PINE64 single board computer. The intended purpose for it is to eventually supersede the PINE A64 and ROCK64, rather than the higher-end ROCKPro64. If anything, the fact that I am comparing a non-Pro next generation SBC to a Pro-grade current generation board should be rather exciting. Lastly, since I know that many of you are curious, the Quartz64 delivers computational performance that is very similar to the most popular single board computer on the market (based on generic benchmarks). Do keep in mind, however, that such benchmarks do not always translate well to real-life tasks, so one board may be superior to another depending on the nature of the scenario. I also ought to mention that from our initial testing, the RK3566 runs really cool – under load, without a heatsink, it rarely spiked above 60*C.

Don’t read too much into these generic benchmarks

Designing the Quartz64, we envisioned that it will serve an additional purpose in the future. Aside from being a stand-alone SBC, it will also be used as a development platform for future non-Pro devices. We have been thinking about democratizing development for some time now, and we intend to start the process with the Quartz64. Creating dedicated development platforms, such as the Don’t Be Evil PinePhone kit, is expensive and time consuming. Such kits also limit the number of people who can participate in the bring-up process, as usually a very limited number of such devices are manufactured. The Quartz64, however, features all the necessary circuitry to start work on a next generation phone, tablet or laptop. Plug a display into the DSI port, a modem into the USB port and add a battery – voila, you’ve got yourself a next-gen phone dev kit. So to those who aren’t usually interested in SBCs in general – it may be worthwhile picking one up and helping the Linux bringing-up process on the RK3566.

Speaking of the bringing-up process, a small number of Quartz64 boards have now been shipped to low-level developers. I am looking forward to seeing how Linux takes shape on this RK3566 platform in the coming months. A major encouraging factor in the bringing-up process is that the Panfrost open source GPU driver ought to ‘just work’ once Linux is brought-up and functional to a point where video output is possible. GPU drivers are always tricky and usually take a long time to open source, so the fact we already have a FOSS GPU for this SoC is a major boon.

Under high load it manages to stay cool, even without a heatsink

It is too early to talk about general availability at this point. A lot will depend on how quickly rudimentary Linux support can be brought to the Quartz64. That said, I place a lot of trust in the developer’s abilities. You can expect an update on Quartz64 in the next community update.

Pinebook Pro

I am happy to let you know that we will be resuming production of the Pinebook Pro shortly after CNY. We were fortunate enough to secure A-grade LCD panels and the necessary RAM (currently in short supply) for the production to begin, and we already have an allocated slot at the factory for the assembly process. I presently do not have a pre-order date for you – that will be announced at a later time. But if you’re interested in picking up a unit then I strongly suggest you follow our Telegram news channel and/or social media for pre-order news  (links in the opening paragraph of this post). I know, however, that many of you would appreciate a ballpark idea of when stock will be available, so to this end: based on our current schedule, pre-orders are set to open sometime mid-March 2021.

The Pinebook Pro is now a mature platform with a lot of fun development – image by Clover

PinePhone Part 1

Earlier this month we announced the end of the Community Editions. The Community Edition program was a vital step not only in bringing support to the PinePhone, but also in bringing attention to mobile Linux outside of our immediate bubble. Countless people worldwide were made aware of alternatives to the duopoly of Android and iOS, and I’m sure that we can all agree this is a good thing. This exposure is obviously good for PINE64, but I’d argue that it is equally good for the entire Linux community. Promotion of the Community Edition PinePhones propelled mobile Linux development like nothing else in recent years and gave birth to multiple new projects. With tens of thousands of PinePhones in people’s hands, it is no longer an unlikely possibility that a mainline Linux smartphone will take hold, but rather an inevitable certainty. Before moving on, let me once again thank all the projects and their developers who participated in the Community Edition scheme. You all did a great job.

While the Community Edition program is now closed, we’re working on a plan to actively support mobile Linux projects moving forward. Talks are held with all major projects and we already have some ideas on how to provide developers with ongoing support. Aside from projects which received a Community Edition, we are now also talking to Maemo Leste, LuneOS, openSUSE, DanctNIX and Fedora developers. While we haven’t settled on a means to achieve this type of support just yet, I hope that a part of the strategy will be an introduction of branded back-covers to the Pine Store. In short, the idea is to sell back-covers with projects logos at approx. a $15 price-point, out of which $10 would go towards the donation. I think that this is a good and fun way of supporting development, which provides end-users with a tangible benefit for submitting their donation. It will take a couple of weeks for us to figure this out, or maybe even longer, but once we do arrive at a suitable arrangement I’ll write a dedicated blog entry about it. 

At this stage I know many of you are wondering what the future of the PinePhone holds. A question that I frequently receive concerns the default operating system and user interface that will ship on the PinePhone. Today we are very pleased to announce that the PinePhone will ship with Plasma Mobile on a Manjaro ARM base from this point on. We have a long-standing relationship with Manjaro and KDE Community, and both projects have supported us and our efforts since the dawn of PINE64. I’m not sure if I wrote about this publicly in the past, but the promise that Plasma Mobile held in its early stages was the deciding factor for us to proceed with creating a Linux smartphone in the first place. Needless to say, we have been excited to see the UI environment mature and flourish on our platform over the past 12 months. Manjaro is our core partner, offering support for all our flagship Linux devices, including the ROCKPro64 and the Pinebook Pro. Their work on the PinePhone has been indispensable, and their current OS images are among the best and most fully-featured for the platform. Working with both projects on the PinePhone has been a pleasure and I am convinced that together we will reach new heights in the months to come.

Manjaro and Plasma Mobile is just a great combination (picture of widget on main page)

Earlier this month we also received the PinePhone keyboard, perhaps the most anticipated accessory of them all. It literally arrived a week ago from the factory. Looking at the pictures below, those eagle-eyed of you will probably notice the missing key caps. The key caps and the keyboard’s PCB are the two outstanding parts we’re still waiting for – we expect both to be delivered shortly after CNY. The molding is completed however, and has now been submitted to us for review. I’m happy to let you know that our initial impressions are very positive and we’re convinced that you’ll be pleased with it too. Please keep in mind that the pictures are of an early preview unit, and everything you see is a subject to change before they keyboard becomes available in the Pine Store.

PinePhone in the keyboard chassis from the front and side

PinePhone in the keyboard chassis from the side

PinePhone in the keyboard chassis closed top

PinePhone in the keyboard chassis closed bottom

From the very inception of the keyboard design we wanted to include a large battery in the base of the chassis. Aside from the obvious benefit of significantly extending the PinePhones operating time, a large battery also serves as a counter balance to the PinePhone placed in the top section of the keyboard’s body. We wanted to cram as much battery power as possible into the keyboard, and we were lucky to find a 22Wh 6000mAh battery which fits the bill perfectly. From my estimates, the PinePhone fitted with the keyboard will be able to remain in standby mode for nearly a week with the modem active. With the modem disabled, however, it will last you more than two weeks on a single charge when placed in deep-sleep. Due to the battery’s size taking up the bulk of the space inside the keyboard’s bottom section, the charging circuitry had to be shrunk down to a tiny PCB. But don’t be deceived by it’s tiny size, this charging circuit can simultaneously charge the keyboard and the PinePhone via the keyboard’s USB-C port. Since I know someone will ask: the USB-C port on the keyboard can only be used charging, it doesn’t support data or any alternate modes.

PinePhone keyboard charging PCB

Look at the size of that battery!

This effectively completely frees up the USB-C port on the PinePhone. You can plug a convergence dock into it or use it for any other common USB-C devices, e.g. thumbdrives. A quick web-search revealed to me that there are now a number of USB-C wireless mice available on the market (something I wasn’t aware of!). So you can pick one up and plug it into the PinePhone, thereby transforming it into a pocketable Pinebook. Many GUI environments available for the PinePhone – including Phosh, Plasma Mobile and Lomiri – already work well in a desktop mode, but I am sure that the keyboard accessory will entice people to bring MATE, XFCE, GNOME and full-fledged Plasma to the device. And why not – after all the keyboard converts the PinePhone into a PDA capable of running full-blown Linux.

Before moving onto discussing software, I quickly wish to touch upon the keyboard’s layout. We spent a weekend in January ping-ponging ideas about the layout with the community. After some push and pull we finally arrived at a compromise that most end-users should be happy with, given the space and design constraints. The illustration attached below depicts the layout we arrived at and submitted to the vendor. I know that not everyone will agree with every design decision made; to those of you who would prefer a different layout, or really need a CAPS key (for whatever reason), rest assured that eventually you’ll be able to flash your own firmwares to the keyboard via the i2c pins, and thereby change the keys functions. This will, however, require input from the development community – an effort similar to that made on the Pinebook Pro will be needed. The time it took to get the community’s approval of the design led to a delay in delivering the keycaps prior to CNY. But even without its keys, doesn’t it just look awesome?

Here is they keyboard layout we agreed on with the community

PinePhone Part 2 [by Konrad, Biktor and Dylan]

We are currently working on three different fronts modem-wise: 1) porting the mainline (kernel.org) kernel; 2) open-sourcing the userspace and; 3) improving the way incoming calls and texts are handled while the phone is suspended.

The modem can now boot version 5.11 of the Linux kernel with minimal functionality (serial, USB and NAND). Konrad has been working hard on all the low level drivers that are needed (PMIC, clocks etc) so the rest of the devices inside the SoC can start. There’s still a lot of work to do, since the SoC has never seen an official release from Qualcomm ever since kernel 3.18.x, so even if some pieces can be adapted from other mainlined Qualcomm models, there’s a lot of code that needs to be written from scratch. Work is being done by Konrad to send his existing patches upstream, so that they can get merged and so that he can further continue the work.

VoLTE blobless audio calls will be possible in the future. Original Twitter post By Biktor

On the present factory firmware, there are about 150 closed source binaries and libraries that make the modem work. Biktor is working on replacing all of them with 3 open source alternatives that will hopefully get 90% of the required functionality. At this point we can initialize the modem, establish data connections and make both CS (normal) and VoLTE calls without any binaries, although sometimes audio fails, and call reception doesn’t work yet. Stay tuned for more information about the open sourced userspace in near future.

Dylan has been tackling one of the biggest complaints concerning the modem, namely the slow recovery from suspend and its USB resets, making the PinePhone lose incoming calls and texts when using ModemManager (since it cannot reconnect to the modem fast enough after suspend). These patches, currently in a testing stage, should make the PinePhone wake up and start ringing on the first dial tone when there’s an incoming call or text, as well as fix intermittent USB resets that show up when resuming from suspend.

We currently have: i) An open-source bootloader, allowing us to flash and boot custom software; ii) A temporary, open 3.18.140 kernel with minimal patches, that gives the same functionality as stock with less vulnerabilities and the chance of debugging drivers while moving to 5.x. iii) Open userspace options, with or without blobs, giving varying degrees of functionality, based on Yocto 3.2, or postmarketOS. iv) Modem SDK which serves as a playground for anyone who wants to build his or her own firmware based on Yocto. v) Initial support from the postmarketOS team that allows to create flashable pmOS images for the modem.

The end goal has always been the same, to have the modem as open source as possible. We aren’t touching the modem’s ADSP firmware, because in addition to the inherent difficulties that come with it, modifying the ADSP firmware could lead to problems with RF regulations or certifications.

PineTime [by JF]

January was a prolific month for InfiniTime: we released no less than 3 versions of InfiniTime in this short period of time. The biggest release was InfiniTime 0.11, which came with 2 major features – the long awaited integration of the heart rate sensor and a brand new navigation application from Adam.

Why did it take so long to integrate the heart rate sensor in InfiniTime? Well, in fact, I implemented a working demo of the HR sensor more than 6 months ago but couldn’t release it because it was based on a non-free/proprietary library. This library implements the algorithm that converts raw data coming from the sensor into human readable values (beat per minute).

From the beginning of the InfiniTime project, I always wanted it to be fully open-source. That’s the reason why I chose the GPLv3 license for InfiniTime. One of the implications of this choice is that we cannot include non-free/closed source modules into the codebase. This heart rate processing library was then conflicting with the license of the project and one of its main values.

But still, many people were asking for the heart rate sensor in InfiniTime, and fortunately, Daniel from WaspOS implemented a brand new algorithm for WaspOS and released it under the LGPL license, which allowed me to port his code in C++ and integrate it into InfiniTime. Thanks again to Daniel for his amazing work!

Heart rate measuring in-app (left) and displayed on watchface (right)

I teased the Navigation app in the last community update. I’m happy to announce that it’s now released! This app, written by Adam works in conjunction with Amazfish and PureMaps, and InfiniTime displays the navigation instructions from PureMaps when it’s connected to Amazfish. Best of all, these apps run on many Linux devices, such as the Pinebook Pro and the Pinephone !

Navigation instructions displayed on the PineTime

Speaking of Amazfish, Adam has also improved the integration in non-SailfishOS Linux distributions like ManjaroARM and Ubuntu.

The BLE connectivity has been greatly improved in InfiniTime 0.12 by updating NimBLE, the open source BLE stack integrated in InfiniTime. With this upgrade, you should expect less failed OTA and less unexpected disconnections from the companion app.

This month, I would also like to highlight Nico’s blog. In his blog, Nicolas writes about SailfishOS, smartwatches and… the PineTime! The first article is an overview of PineTime with SailfishOS. In a second article, Nico explains how to upgrade InfiniTime using Amazfish on SailfishOS. Finally, he reviewed InfiniTime 0.11 and 0.12 in this 3rd article. I really appreciate these blog posts, they are short, easy to read and give honest and accurate opinions about the progress of the project.

RISC-V PINE64 Single Board Computer(s)

It will probably come as no surprise to anyone following our project that we’ve been watching the RISC-V space very closely in the past 18 months. Many of you correctly concluded that the Pinecil, our recently released and very popular RISC-V soldering iron, was our first foray into the world of RISC-V SoCs. Indeed, the choice of the RISC-V SoC for the Pinecil was not mere coincidence. That said, Pincil’s SoC is rather rudimentary and incapable of running an advanced operating system such as Linux. We’re now at a point where we’re willing, and indeed keen, to dip our toes in the RISC-V pond and build our first single board computer capable of running full-blown Linux (and possibly also other FOSS operating systems). I’m not sure about you, but we’re rather excited about the prospect of this decision and its importance moving forward. 

While we’re not quite ready to talk about the specifics of the SBC at this point in time, in part because many PCB-design decisions haven’t been set in stone yet, I do nonetheless want to give you a general sense of the sort of hardware that we’ll be delivering. Our first SBC will feature two RISC-V CPUs, the main one being a C906 64-bit SoC coupled with an auxiliary 32bit BL602 SoC for WiFi and BLE. The C906 is already capable of running Linux and, from what I understand, is completely open while the BL602 is in the process of being open sourced (including firmware) in our Nutcracker community challenge. The SoC has solid I/O, including USB 2.0 and Gigabit Ethernet, and I see it as a great entry-level Linux-capable RISC-V platform.

The C906 feature list for those very tech savvy of you

I am making the specifications known well ahead of time to manage your expectations. The overarching idea behind this board is to make an inexpensive board, accessible to all who wish to explore the RISC-V architecture, and to get it into the hands of as many people as possible. We’re aiming at a sub-$15 price point. We also want it to become a gateway to more powerful RISC-V SoCs in the future. While it’s our first entry into the world of this particular architecture, it most surely isn’t our last. The board will allow you to create fun IoT, learning and DIY projects, but I won’t be surprised to see someone make Doom, Sonic the Hedgehog or MarioKart run on it in a matter of weeks. In a month or two, I’ll share more details concerning the board-design and the exposed IO. Lastly, as you noticed already I haven’t mentioned the name of the SBC – you can expect a riddle in the coming weeks.

LoRa and LoRaWAN PINE64 Ecosystem Integration

In the past 6 months I’ve mentioned LoRa and LoRaWAN on many occasions and in multiple posts. If it wasn’t clear until now, we have been quite interested in the technology and its potential for novel applications. After extensive internal considerations, we now feel ready to double-down and make LoRa an integral part of the PINE64 ecosystem. I’ll explain a bit more about the core premises of our vision further down in this section, but let me start by writing about the actual equipment we’re planning to deliver. For one, we will offer next generation modules for all our devices – this includes, but is not limited to, the PinePhone, the PineTab and Pinebook Pro. We will be using next generation LoRa chipsets in our expansion modules, which deliver better performance while consuming less power. We will simultaneously introduce LoRa modules for North America, Asia and Europe, that conform to the respective regional regulations

We will also build our own LoRaWAN base station, which too will utilize next generation LoRa technology. This chipset does not only allow for higher efficiency and lower power consumption, but also for an improved data-transfer rate when compared to presently available technology. We intend to introduce two versions of our base station, the first of which is intended for deployment indoors, while the second arrives enclosed inside an aluminum waterproof container for use outdoors. The theoretical range of the base station is measured in tens of km’s, at least in unobstructed line of sight. That said, a range of 5-6km is much more realistic in most scenarios due to terrain and other obstructions found in urban areas. As you have come to expect from us, the brains of the base-station will be running FOSS software atop of mainline Linux.

We aren’t the first ones to think of using LoRa for communication – source

So, then, why are we doubling-down on this? While LoRaWAN is usually used for a variety of IoT type deployments, we wish to use it for text-based communications. In its implementation we expect the functionality to be more akin to HAM radio rather than SMS or instant messaging. Most importantly of all, however, we see LoRaWAN as a means for communication without a middleman. To allow communication over vast distances, each base station can be connected to the internet. We hope that, in time, urban areas will see some degree of coverage and that people will be willing to join in on the fun. And yes, in the initial phase of this experiment, the purpose of LoRaWAN stations is to have a bit of fun, whilst simultaneously exploring the limits of the technology’s application for communication. Needless to say, getting developers onboard to support this novel implementation of the technology will prove crucial. Over the next months I’ll do my best to convince relevant parties that it makes sense to explore this LoRaWAN application and that it may be a first step in rethinking secure communication mediums.

That is all for now, I’ll catch you all in a month! 

90 responses to “February Update: Show and Tell”

Your email address will not be published.

I accept the Privacy Policy

    Probable Rockchip Pinephone, upcoming RISC-V single board, and an insane amount of work making modem to be open source. Pine64 and their community are absolute legends.

    1. I am concerned that development will slow down on other developments if the default OS is decided. I think a multi boot image would be better. I also have some prejudice against manjaro 🙂
    2. What material is the keyboard cover made of and does it attract fingerprints?
    3. Is the keyboard feel similar to Psion, does it have tactile feedback?
    4. Will it be easy to receive calls when the keyboard is closed?
    5. When will the keyboard be available to purchase?

    Lukasz Erecinski says:

    1. I doubt highly doubt it will have any impact at all. As I’ve said, we’ll continue supporting all projects moving forward.
    2. Some type of polymer. Again, do keep in mind that the pictures are of a prototype, and the finishing on the plastic may change completely.
    3. It should feel near identical to the Psion keyboard.
    4. No. You’ll probably want a BT headset or headphones with mic for this. The goal is to convert the PP into a PDA with LTE really – which is something many want.
    5. No idea. I can offer you my private guess; sometime between April – July.

    Ford Prefect says:

    Just to clarify:

    Incoming calls should still be received, but you must open the clamshell to *answer* it, correct?

    I know power management & always-listening radio reception, are not best friends, but the PinePhone will still receive calls while pocketed, I hope?

    (Needing to open the keyboard case to answer, actually sounds great to me, personally!)

    When are you guys sending a fully FOSS rocket to the Moon? Soon-ish by the look of it, the last couple years have only been the tip of the iceberg.
    Excellent post and updates, awesome projects, so much going on it slowly gets hard to keeping tracks of it all!

    The LoRa radio sounds very exciting. I’ve seen what LoRa can do with high altitude ballooning.

    With regards to PinePhone, do you expect Mobian to back in stock for UK deliveries later in Feb? Or is this unlikely? And when is it anticipated the KDE model will be available in the store?

    Lukasz Erecinski says:

    I’ll have more to say about the PinePhone availability late this month – once we know what the market situation looks like.

    Hi, I am sure many would appreciate if the web store had a feed of it’s own, so that we would learn when any item is in stock. Is that something we can look forward to?

    This is a great idea – something like a twitter feed or a discord channel would be helpful, especially if we could have it so that the only notifications are new or in-stock products.

    Very nice improvements such as equipping Quartz64 with a native e-ink port and also being capable of supporting up-to 8GB of LPDDR4 RAM while keeping all great features from RockPro64. I also love the fact Quartz64 has a native SATA 6.0 port
    and features an integrated battery charging circuitry. It would be interesting seeing Quartz64 model-B with a m.2 slot instead of a PCIe 2x open ended slot as shown on model-A. Great job people!

    Harsh Kedia says:

    Thanks for the awesome update.

    There has also been rapid development in LoRaWan in the blockchain space. Building on top of already emerging infrastructure might be one of the option the community can explore. Have a look at helium.com for more details.

    Amazing! Thanks for the hard work. I think that all my future computer devices that I’ll buy will be PINE64 products. I’m looking forward for the Quartz64 with the e-ink display. The PinePhone keyboard is a must have! nice idea with the big battery inside it.

    Skirmisher says:

    No mention of LoRa being a proprietary protocol with a homogeneity of available transceivers…? I’m really curious why Pine (whoever’s making these decisions) thinks that they can work around the data rate limitations of LoRa and make it at all suitable for direct communication between end users. There are more long-range radio specs to choose from, that are, y’know, actually open and have proper standards bodies, not to mention better suited for general-purpose transmission…

    Even if LoRa has the most readily available solutions right now, I don’t see that as a reason to compromise values important to developers and users alike and set back the ecosystem by choosing to rely on LoRa alone.

    I would strongly support modules or hats (depending on device) for this. I think LoRa could be quite useful and might be ideal for a headless device doing monitoring – thinking of a solar-powered ph, temp and moisture monitor on a farm, short logging/monitoring for medium-distance embedded systems, closed or communal test/chat type setups that don’t rely on Cell towers or hideously expensive wireless solutions, etc.

    I’m not super committed to LoRa though and it might be nice to have BT5 for pretty short distances, EG25 for cell, full-featured wifi for around the house, etc., hence the module idea.

    I am also very disappointed in the amount of mindshare (aka “free advertising”) that this proprietary protocol have garnered in hacking circles the last year or two. Especially when, as you correctly point out, open and standardized alternatives exist.

    Yes it’s all new and exciting, I get it. But inevitably, as soon as they control the market, is when they will start locking down the ecosystem. Look what happened with Android (and so many things before that). Therefore, why do we want to help them achieve that? I think instead we should be talking about these free and open alternatives.

    Pine did such an excellent job of spreading the spotlight around to all the existing Linux phone distros (as just one example), that promotion of such proprietary protocols just comes off as more than a little odd to me.

    Ford Prefect says:

    I agree completely about the dangers of favoring a proprietary protocol like LoRa. Its use cases overlap with any number of less captive wireless protocols which could be supported with a module, instead of putting so much dev time into a LoRa module dependent on proprietary code or hardware.

    I did come looking *specifically* to see if a LoRa module would be available, & I’m glad it will be, but that should absolutely not come at the expense of development of modules for any open protocols.

    Now… What open protocols would that be?

    ^^ Honest question; My mind is cluttered with proprietary protocols right now. As I think of radio modules I’d like to see available, most that immediately occur to me sadly *aren’t* open protocols or chipsets…?

    BLE, UWB, ISM, GMRS, LoRa… Zigbee? (in order of priority)

    When I was 10-12 years old, I loved to learn electronics, however my family could neighter afford buying kits nor sending me to a course. I’m pretty sure there are lots of kids like the little me out there which are learning from PINE64 community, using your devices and building on top of FOSS software, free from limitations, except for their imagination. This is truely fantastic. Thank you all.

    Heimen Stoffels says:

    It’s great that you can flash firmware to change the PKB layout, but since I use Dvorak, can I swap the keys as well? ‘Cause changing the layout to Dvorak doesn’t make any sense if the keys still represent QWERTY… I mean: sometimes I do have to look up a few keys, esp. with such a small keyboard where everything is more cramped, so I want the keys themselves to be in the right place.

    Lukasz Erecinski says:

    We actually made ‘keys being swappable’ a requirement when commissioning the keyboard. That said, until we get the keyboard with keys to test, and confirm that keys can be swapped around, I’ll stay on the cautious side and not boast about it. If it works, consider is a nice bonus 🙂

    Sooo, I’m going to be the one that asks.

    Will you be selling a “DAS” Pinephone Keyboard, free of markings? 😀

    If so, put me down for one.

    Katana Steel says:

    it’s pretty cool they’ll let you flash a new layout.

    would a qmk firmware supported controller possibly in the future?
    and the possibility for more layers?

    Sorry if this has already been answered somewhere, but do the pictures of the keyboard show the maximum amount that it can flip out (looks like 100-120 degrees)? It would be amazing if it could flip around a full 180 degrees, so that you can still hold it like normal.

    yeboy60200 says:

    My thoughts exactly! The number of degrees that it can rotate is a complete make or break for me. If it has to be used like a laptop (due to only rotating outwards 100-120 degrees), that will be a bit disappointing.

    Being able to flip it like a thinkpad yoga would make it much easier to use as a regulat phone. Might be to late for that thought, but maybe on v2.0?

    Just realized I meant a full 360 degrees, so you can still hold it in one hand (the keyboard would probably have to be disabled), but it would be nice if it could at least go 180 degrees flat like a Thinkpad.

    Might be tough to get the keyboard out like that now, but I would love that and be more likely to carry it with me. Might need some testing and ruggedizing/spillproofing/etc for the keyboard to work properly. I’ll still get it when it comes out – I already have a regular cellphone, the idea of a functional portable terminal that can run smaller linux apps is super appealing and there just haven’t been that many devices to do it effectively. Would love to get proficient enough with the keyboard to just connect to wifi or some kind of very portable battery powered WAP (no, not compatible with a bucket and a mop) to easily deploy and handle many of the basics.

    Great update! Excited for the new phone keyboard.

    Minor quibble: when the video mentions China and the New Year, it cuts to an image of Japanese lanterns.

    I like the path that the one for all (Quartz64) will take in the future, the LoRaWAN thing very interesting, I would have to see if you can compress voice in messages

    “LoRa+WiFi ClusterDuck Protocol by Project OWL for Disaster Relief” (2020) https://news.ycombinator.com/item?id=22707267

    “[OpenWrt-Devel] RFI: OpenWRT for #DisasterRelief: LoRA: ClusterDuck, LTE, 5G, Mesh, Throttling” (2020)
    https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg52055.html

    OpenWRT is a make-based distro. LuCI is the web-based config gui written in Lua; which configures the device with uci. You can configure OpenWRT devices over SSH (and without having Python installed) with Ansible.

    OpenWRT docs > Developer Guide: https://openwrt.org/docs/guide-developer/start

    Request UFS storage for vast speed increase over emmc.
    UFS 3.1 preferred, even 2 would be faster and better on battery life

    Arwen Evenstar says:

    Tim Grech said:

    > Request UFS storage for vast speed increase over emmc.
    > UFS 3.1 preferred, even 2 would be faster and better on battery life

    In general, these features are exposed by the SoC designer and manufacturer. Meaning if the SoC is not designed with UFS, (Universal Flash Storage), then Pine64 can’t really do anything about that. If Pine64 uses the PCIe bus for this function, the UFS card slot would not not be bootable.

    I checked the Rockchip RK3566 and it does not include UFS.

    the01player says:

    I love the idea of a keyboard for the PinePhone and an extended battery, but it actually looks a bit impractical for everyday use.
    If you use the PinePhone more as a phone, often using it with one hand, taking calls, and otherwise using it vertically, it feels like the keyboard would get in the way at times.

    If the keyboard could fold a full 180 degrees, that would solve this issue entirely. (And it would be a cool bonus if the keyboard disabled any input while folded to this degree!)

    Without being able to fold that much, it feels like it forces you to use it like a laptop somewhat, which isn’t always the most practical for a phone.

    I understand that this product is probably geared more towards people who want to use it like a laptop most of the time (or will only connect this case when needed), but I personally would love a dynamic keyboard case that can be attached all the time for that extra battery life, as well as folding “away” to allow normal use of the smartphone when needed.

    Hi Lukasz,

    Thanks for your elaborate monthly update. Love reading these, it’s something I look forward to around this time of the month 🙂 It’s amazing to see all the ideas Pine64 are starting, and the

    Regarding the keyboard I was wondering the same thing the01player is wondering; when you attach the keyboard to the Pinephone, will you still be able to use it as a phone without an extra headset? However much I’d want the keyboard extension, for me personally it would be a deal-breaker if this is not the case.

    Thanks for your reply!
    Best wishes, Thomas

    Lukasz Erecinski says:

    You are correct. The keyboard turns the PinePhone into more of a PDA-type device with LTE. For taking calls, I can only suggest a BT headset or wired headphones+mic. We did explore a 180* hinge, but the mechanical complexity as well as molding price were not something we were ready to commit to.

    Thanks for your fast and clarifying response. I don’t know yet for sure, but the keyboard extension might not be for me then as I use my phone when I’m standing up or am on the go quite a lot, meaning I’ll often have to be able to control it with one hand. I’m assuming the board extension will make this (much) harder but I’ll follow the further keyboard developments and early reviews eagerly nonetheless 🙂

    I’ll just wait for the battery cover then, hoping that will have an equally large (6000MAh 22kWh) battery! 😀 When combined with an external smaller keyboard that should provide similar functionality with some extra usecase flexibility.

    How about an additional earpiece located inside the top back cover of the keyboard case, so you could make calls with the keyboard case closed? The 3.5 audio jack is close to that part, could it be used by the keyboard case for this, perhaps? I’d even be willing to connect it manually, as long as the connector would be molded in a way that allows for the phone+keyboard to be carried in a pocket without breaking the jack…

    I think someone will convert keyboard to Bluetooth one and add detachable magnetic hinges. I’m using 3d party bluetooth compact keyboard with my Pinephone, works great, but you need to have a table to use this combo effectively.

    Thanks for the info about the case. That makes a lot of sense. I’d rather have an affordable keyboard and/or battery expansion out in a few months then wait a year for a fancier version that still will need user reports and field testing.

    I wonder if it would be plausible to ass a PineTime dialer app for the phone?

    Lukasz Erecinski says:

    A sliding keyboard is something we want to do at some point too. That said, since the PinePhone is a completely custom design, all accessories for it require a custom design too. Custom design means custom molding, and custom molding is very expensive (5-6 figures depending of the object’s complexity).
    For the time being we’ve very happy with the current keyboard design, but we’ll keep exploring our options for a sliding keyboard.

    I love how the keyboard case makes the pinephone look like a nintendo DS!

    Reminds me of back in the day when I carried my DS in my pocket (and I didnt have a smartphone).

    Since “community editions” are over – what about the future of 32/3GB mmc/ram PinePhone model that was offered in “convergence bundles”? Base 16/2GB PinePhone specs are too low especially if we look for device longevity. Will there be any options to order higher specs model or 32/3GB could become default? I’d pay even for 4GB – Firefox could run better! 🙂

    Unfortunately, the A5 chip used in the pinephone can only address a maximum of 3GB of ram. I’m sure the convergence package will still be available though.

    If we can keep testing and devloping the Pinephone and then the Quartz64 as it comes around, maybe we will be looking at a QuartzPhone for a followup generation. 4 to 8GB on a phone should still be plenty and we’ll have worked many of the crucial bugs out by then so maybe it will be a fairly capable daily driver. I think the Pinephone will get there but the extra RAM and CPU sure wouldn’t hurt – and it would be pretty interesting to have an integrated NPU on a Linux phone, with apps already developed to use it.

    CrystalGamma says:

    Looking forward to the Quartz64 … looking at the datasheet and board schematics left me with a couple of questions:

    I’m assuming the goal is that this board, like all other Pine64 boards, will eventually be bootable blob-free.
    For now I haven’t seen any U-Boot forks with RK35xx support or similar.
    Is there a plan for this? As the levinboot author I’d prefer if I could just rewrite memory init source code from U-Boot or similar, instead of doing legally murky reverse engineering.
    If you could get Rockchip to release register docs for the memory controller that would be great too.

    In other matters, the Q64 has a “G Sensor” on the board, according to the schematics … what is this about? Is it the typical set of smartphone sensors (accelerometer, gyro, potentially magnetometer)?

    Like the older boards, the Q64 has a 16MiB SPI flash on-board.
    As a bootloader author I’m interested in making that available as a place to store an OS, so I’m a bit confused by how the voltage selection for the SPI and eMMC works … is it at all possible to use the two simultaneously? I suppose if the SPI could only be used before bringing up eMMC, that’s fine as well for this purpose, but clarification would still be appreciated.

    Lukasz Erecinski says:

    I’ll ask Maya to respond to you once she has some insight. She literally got her board yesterday.
    Most of your questions will be better directed to devs than me. A Quartz64 channel was opened in the Discord server today – if you want to join in.

    I can help with trying to get the register docs for the memory controller. I’ll ask TL tomorrow. We’ve got a good working relationship with RK now, so maybe we’ll be able to work something out with them.

    The sensor, if I’m not mistaken, is the same as on the PinePhone — I’ll double check and get back to you if I’m wrong.
    SPI is always first in RK’s boot sequence. So if you flash uboot to SPI then it overrides any and all other bootloaders on eMMC, SD, USB and PCIe

    CrystalGamma says:

    Alright, I’ve had a look at the channel (though I’ve pinged fire219 about making a Matrix side for it, since that’s what I usually use).

    I’d expect the BROM to prefer SPI to any other boot medium, yeah.
    I’m just confused because the boot SPI and the eMMC, at least going by what’s written on the wiki, have disjoint voltage ranges, so I’m not sure how that’ll work out.
    I’ve asked in the channel and none of us seems to really understand what’s going on there right now (and apparently the dev units have the SPI unpopulated as of now, so maybe that’s not actually set in stone yet).

    Arwen Evenstar says:

    The RISC-V board is a step forward. Nice that it has the Vector extensions.

    What we need in the longer run, is a usable “desktop”, like a RPi.

    The BeagleV board is also a good start. But it lacks reasonable video out, 1080p @ 30hz only. Which means some monitors will not work, because they support 50 – 76hz, not 30hz. Plus, limiting the board to SDXC or USB storage is, well, limiting. A single SATA or eMMC slot, (like Pine64 uses), would help.

    RiscV is already popular enough, the only thing preventing its adoption from rising (exploding?) is the absence on the market of SBC of the ROCK64 / ROCKPro64 class. I really appreciate your interest in the RiscV platform, but if you don’t plan to manufacture a board at least as good as the BeagleV, your efforts would be better spent on another project.

    Lukasz Erecinski says:

    We have a tendency to work our way up from low-to-mid-range SoCs. Surely this is what you’ll see us do with the RISC-V over time too.
    While I understand your position, I believe the right move is to get people an affordable option to get their first RISC-V board.

    The Manjaro+Plasma announcement is a bit a surprise for me. I’d believe the smart move would be using Phosh to avoid community split. Librem invested a lot in phosh and I guess the release of the Pinephone gave them a lot of users, bug reports, and contributions. This dynamic with a “High-end” Librem5 with a company supporting a lot of the developments and a “low end” Pinephone bringing FOSS enthousiasts bug reports and contribution is appealing.
    I certainly don’t know all the reason of this final choice, though. I guess the endless Linux UI war is endless 🙂

    Personally I’m not found of Manjaro with KDE having tried it and not liked it much preferring Mobian, so can I ask if an option for a pinephone version with no OS will be available for those who want to use something else? Or will it be still easy to install an OS on the phone as it is now?

    Hello, about the pinephone keyboard, will it be possible to make phone calls with the keyboard case attached? Would it perhaps be possible to add an additional earpiece to the top back cover of the keyboard case (where the opening for camera is located) so that people can make phone calls with the keyboard case closed? Thanks!

    With regards to the comments on phone capability with the keyboard attached: I think we should wait the next generation. And instead of adding new phone related tech to the keyboard like a microphone, one should rather improve keyboard related things that help your wishes. For example a mire expensive keyboard version or generation with a 360 degree hinge fixes the portability concerns in phone calls. As you swap the keyboard backwards. Anyway, once the keyboard is out, people will demand more, like adding a keyboard backlight or language specific keycaps. So I would wait for the next generation and wish the keyboard improvements have a keyboard tech specific approach to fix shortcomings you get when the phone is attached to the keyboard. Or an easy way to take the phone out of the keyboard case, e.g. by reserving space for the phone’s backcover so you don’t touch the battery or sim card behind the phone case. Right now to keep the keyboard case thin and to have an easy contact to the pinephone pins, the phone case has to be taken off. This certainly won’t be the last keyboard prototype or generation.

    Right now I would already be really happy to being able to type this long comment on a phone sized keyboard to a privacy oriented phone.

    Lukasz,

    I believe you meant a SATA 3.0 port – that’s what is currently available. Or you meant a SATA 6Gb/s port (which is what SATA 3.0 is). I glanced right over it earlier but then realized it could be confusing to some folks.

    Please sell replacement plastic screen protectors. No really 🙂 — I don’t want the visibly thick glass, I do want to refresh my thin soft plastic every few months. (My phone lives in a nice sleeve.) How about a 10 pack for $10? That’s good for about 5 years, plus leftovers for projects. Put a few bucks of that in the OS Projects Tip-Jar when you figure that out more. (PH and PBP are both working well here – THX.)

    Lukasz Erecinski says:

    I’ll look into it. That said, I’m sure you’d be better off buying a plastic screen protectors for the iPhone Max (or whatever its called) locally, from pictures posted online it looks like a perfect fit.

    I know with Chinese New Year you’re having logistics issues, but is there any word on when the PineTab will be available again? Will it resume production after CNY, like the Pinebook Pro?

    Podoba mi się nowa płytka. Choć chyba tak skupiliście się na wydajności, że zapomnieliście o oszczedzaniu. Brak trybu głębokiego uśpienia jak i wylączania rdzeni i koprocesorów. Co można i należy zmienić pewnie w nowym wydaniu.

    Widze,że moje pomysły by dodac FPGA nawet niewielkie by w przyszłosci przejąć bloby lub po prostu zwiekszyć wydajnośc za pomocą dodatków, które niejako skleją się za pomoca tego fpga nie przypadło wam do gustu. Szkoda, bo fpga jako dodatek naprawiający wspołczesne przyciężkie komputery to dobry pomysł.
    W każdym razie nie uciekniecie od koprocesorów SI i różnych dodatkóœ, które dobrze by było obsłużyć z pełną szybkoscią.

    Zadam też jedno pytanie. Czy te wszystkie dodatki, ogromna praca przełoży się na dłuższy czas pracy systemu? Powiedzmy 60% dłużej będzie działał laptop? To duży skok i nie chcę dezawuowac tego co robicie. Ale zwykli ludzie chcą miec system, który wstanie w pól sekundy i będzie działał kilka dni, może tydzień a nie kilka godzin. Choroba cyferkozy jest straszna. Bo przesłania faktyczne zastosowanie. Faktyczny szary nudny user, sekretarka jest ważniejsza niż zbitek kolejnych cyferek na diagramie, który uzasadnia zachwyty. Pomyślcie o zwykłych normalnych nie-hakerach. Użyszkodnicy powinni miec głos. Może nie decydujący ale słyszalny.

    I poprawcie klawiaturę ;-P

    co do lora to dobry kierunek, choć ja wolałbym nowinki nntp niz komunikacja tekstowa ? cokolwiek to nie znaczy.
    jakiekolwiek protokoły będą musiały uwzględniać cachowanie danych i mesh. ale to oczywiste.
    nieoczywiste jest to, by łączyc wifi z lora. bo w miejskim systemie łatwiej to połączyc z wifi a na terenach wiejskich raczej lora.

    ale dopoki nie pokazecie sprzetu to tylko dywagacje. kazdy tak reklamuje , ze bedzie super hiper i bedzie cool.

    dla wszystkich którzy jednak się znają a nie bredza bez sensu niech po prostu policzą. miasto wielkości warszawy, 2mln mieszkańców, nie ma internetu bo (tu wstaw przerazająca przyczynę) i każdy z mieszkańców chce wysłac 2 wiadomości do znajomych i rodziny. To wszystki 2 wiadomości dziennie. Gdzie 10-20% protokołu to nagłówki i informacje sieciowe. Kto nie policzył tak oczywistej rzeczy dalej bedzie fantazjować o super zasięgu i przepustowości. Dlatego lora tak, ale trzeba oprzec sie też na innych pasmach tzw. ISM. A może nawet na CB (choć np. w Polsce zakazana jest transmisja cyfrowa ale w afryce juz nie)

    The pipe and backslash positions on the Psion-like keyboard are in completely unusable positions. They should be on the “:” “;” key as the two Fn special functions, with the Insert Fn function moved to L. In general special characters should be close to their original positions (and this is based on US ANSI or ISO UK, I assume), so top-left for pipe and backslash just completely messes up anyone’s muscle memory and vague idea of where these keys are supposed to be. It’s just not a usable spot at all.

    Also compare the Gemini PDA’s US/UK layout, which is similarly cramped but makes sure to follow this rule and accordingly, places pipe and backslash as well as the quotes and everything close to where they usually are, even if of course all in slightly unusual spots as is avoidable for such a cramped layout.

    As a more optional suggestion, it would also be cool if the special second-Fn-function were to be accessible via Fn+Shift+Key too and not just AltGr+Key, since that is again closer to how US/UK layouts usually work that don’t need use of something in AltGr’s vicinity to activate any “normal” special characters. I know this will be less weird for our EU folks so I don’t think it’s bad AltGr exists, just would be nice if its use wasn’t required for non-international uses. (If that is already how it’s intended to work then cool!)

    I love the PinePhone keyboard. One thing to mention: maybe some type of cooling (passive would be good enough as part of the keyboard top side where the phone is snapped in, but also maybe active) – I mean anything that would help with the phone cooling would be very very useful. The phone gets really hot when used in convergence mode.

    Gerald Staruiala says:

    I would really like to order a unit.
    For the life of me I cannot find how to “pre-order” or to simply buy a unit.

    Also, in the Convergence offer the USB-C Docking Bar – 2x USB Type-A host ports, digital video port, and 10/100Mbps Ethernet port is really a good solid offer and I would like to order a few for use with my systems.

    Is there a time line to allow “pre-orders” of the Pine Mobile systems and is it possible to buy the “docking” unit?
    Cheers

Subscribe to the PINE64 blog