Things have been a bit quiet on the blog here, as I have been pretty flat out with work, and starting to plan to move back to the city after nearly a year here in the Outback. The work on getting the MEGA65 DevKits shipped has been going along steadily over the last few weeks as well, but with less bloggable moments from my side. What has also being going on, is the work on the next milestone of the MEGAphone grant from the NLnet Foundation. For those who aren't familiar with this, this is a grant to move the MEGAphone project forward to having a PCB design that is mature enough that we can make a bunch for the community to get hold of, and to innovate on as a platform for resilient and secure communications.
The work on the MEGAphone results in various benefits for the MEGA65 work, as well as the value of making a hand-held MEGA65. For example, in the last work unit under this grant, the multi-port serial port interface got a complete overhaul, and makes it much easier now to interface multiple serially-connected peripherals to the MEGA65. People have already been talking about making trap-door wifi adapters, which would make use of this.
So in short, if a handheld MEGA65 doesn't interest you, there are plenty of side-benefits of the MEGAphone. One of the potential benefits of today's work unit, is that we think we have found the cause of the speakers connected to the MEGA65 R3 PCB getting hot (we use the same speaker amplifier circuit on both, as yet another commonality between the MEGA65 and handheld MEGAphone).
But enough of that, let's take a look at the 3rd milestone for this grant, and then what we have done to complete it:
3.
Determine specifications for MEGAphone r3 hardware prototype
As described in
sub-task 2, we wish to make a revision 3 hardware prototype that
should have all key functionality included, that would make the
device in principle usable by a developer. This means that it must
have functioning communications, energy, computation, display and
input sub-systems, such that it can be used and programmed without
undue complication.
Milestone(s)
-
Combine the
errata identified in sub-task 2, together with consideration of the
functional requirements of the revision 3 milestone, and identify
the design and component changes that this entails to achieve that
goal.
-
Determine the
revised intended specifications of the device.
-
Determine the
revised list of sub-systems required to achieve this
-
Identify the
changes to the Bill of Materials for the revision 3 device
-
Sketch out
possible schematic changes / PCB floor plans for each of the above,
accepting that they may not be final.
-
The milestone
shall be considered complete when the four preceding dotpoints have
been completed and their results communicated via the MEGA65 blog
(https://c65gs.blogspot.com.au), specifically addressing those five
points above.
So in the previous milestone, we had collected together all the errata, and actually also completed part of this milestone, by suggesting a number of potential solutions to various of the errata. This milestone basically transforms that set of errata into a set of concrete design changes for the MEGAphone R4 PCB.
These changes can be largely be lumped into four groups:
1. Corrections to known problems with the MEGAphone R2/R3 PCB, e.g., problems with some of the power control circuits;
2. Improvements to the existing functions, that aren't so much fixing problems, as making things better / more logical, e.g., moving some of the switches around;
3. Adding originally planned but missing sub-systems, e.g., battery charge circuit; and
4. Adding the ability to use a Raspberry Pi Compute Module 3+ as an "Android Co-processor".
Now, the first three are probably no great surprise, but its worth explaining why we want to make it possible to include a Raspberry Pi Compute Module in the MEGAphone, especially when in the MEGA65 we have purposely avoided including any "big" processors.
As a geek and University Academic, I keep thinking about multiple possible uses for the MEGAphone. First, it is simply a hand-held MEGA65, for retro-fun on the go. Second, its a phone that you can trust, through the careful security design of the hardware, that isolates all the untrustable parts, like the cellular modem. Third, it is designed to support resilient communications, e.g., including UHF packet radios (or rather connectors for them), so that it can do mesh networking. Fourth, I have been thinking for a while about the challenge for people who need accessible devices.
The challenge for accessible devices is that while certain kinds of disabilities are fairly well catered for, e.g., impaired sight or hearing, this is not the case for motor control impairments, where special input methods may be required. Think, for example, of Stephen Hawking, who in the latter part of his life controlled computers using a single cheek muscle. One of the problems I see for people in such situations, is that computers keep advancing very rapidly, and that keeping up with the changes to computers -- or in this case, with mobile phones. We are all familiar with how quickly a phone becomes obsolete, and stops getting updates, and how hard it is to compile your own custom version of Android, let alone modify it to support some custom feature.
So what we have envisaged with the MEGAphone, is that we can have support for an upgradeable co-processor module that can run ordinary Android, unmodified. This means that as newer builds of Android for the module come out, or as the module itself is upgraded over time, the rest of the chasis of the phone can remain unchanged. By using the FPGA in the MEGAphone to pretent to be a normal touch screen interface, we can make the acessibility layer live entirely in the MEGA65 side, with the Android instance not even realising that it is on the receiving end of an accessibility interface. That is, the user can upgrade Android as often as they want, and even upgrade the processor that it is running on as often as they want, and they won't have to worry about losing their accessibility customisations.
Also, by having the accessibility layer in the MEGA65 side, it is much more tractable for end-users (or their support networks) to make fully customised accessibility interfaces that suit the capabilities and preferences of the user, rather than having to accept cookie-cutter accessibility solutions. In this way, we hope to help support the dignity of people living with disability, and help them to more fully participate in the digital world, by allowing them to keep up to date in the mobile phone sphere.
We selected the Raspberry Pi to be this co-processor, as there is a very strong and long-term community around the Pi, including maintaining an up-to-date port of Android. For example, there is a commercial supplier of Android for the Pi, who offer ongoing automatic updates for 5€ per year. Or there are also multiple open-source initiatives as well. The key here again is choice, which means dignity for the end-user.
If I had to guess the best option for making a sustainable commercial market for the MEGAphone, it would be this one around accessibility. Here in Australia we have a National Disability Insurance Scheme (NDIS) that would effectively be the customer, if we progress things sufficiently. This is why we have had a student, Luke, working on an initial concept of this, based on the existing R2/R3 PCB, to see what might be possible. Here is the 3D printed case and jelly switch connected on the MEGAphone's standard joystick port, to allow single-muscle operation:
