MEGAphone PCB Changes

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:

 

Now, the above build is based on the R2/R3 PCB as I mentioned, which makes the whole thing bigger than necessary. It also uses a bunch of different switches than we would intend to use in the end, which also makes it bulkier.  But its a start as a proof-of-concept.

We already have partly implemented the single-muscle input method for controlling the keyboard of the MEGA65, to demonstrate that side of input accessibility.  Mouse/touch interface control would be the next, and the MEGA65's VIC-IV already has a hardware cross-hair indicator that could be used as part of that, to move the touch point, and toggle the touch up/down, thus allowing full control of a touch screen oriented device in this way.  

The D-PAD and other buttons on the MEGAphone are already much more disability friendly for those with impaired fine motor control, compared with having to use a touch screen. Also even if the device ends up relatively chunky, this is also an advantage in many cases, by making it much easier to manipulate the device with impaired fine motor control. 

Also, apart from the disability support use-case, we are also looking at the MEGAphone for resilient field data collection for disaster zones, using the planned built-in solar + large battery (which is also helpful for the disability use-case, by helping users to maintain charge in the device, and thus their ability to communicate, even in the face of negligence on the part of carers, which sadly, is a phenomena that does occur).  Having real buttons etc for input allows, for example, for the device to be used inside a water-proof or vacuum sealed pouch, allowing use in a wider range of disasters -- including in response to pandemic or other disease outbreaks, while keeping the device sterile and dry.  Again, the solar charging option allows the device to be used in such situations without having to ever break the seal on the pouch.

We have digressed a little, but hopefully, it gives some idea of the wider uses of the MEGAphone that we are thinking about. But let's dive straight into the set of PCB design changes that we are planning for the next milestone.  One of the more obvious changes, is that we will be making more use of mezzanine PCBs, to help keep the area of the PCB down. As there are already a bunch of things sticking up on the back of the PCB, the use of such mezzanines will not increase the thickness or volume of the device, but rather help to reduce them somewhat.

So anyway, let's just dive straight in:

General Comments

The PCB is already rather complex and congested. To the extent possible, it is desirable to reduce the complexity of the PCB, rather than increase it. For these reasons, including the significant development advantages of modularising some of the trickier outstanding parts, like the headphone jack and Bluetooth, the current plan is to use a number of mezzanine PCBs that will lie across the rear of the device adjacent to the battery. Given that the FPGA board is already a mezzanine board, this is not a great departure from the existing approach, and will not make the device any thicker or larger.

Otherwise, the changes that will allow the two D-SUB connectors to be moved back inside the PCB outline, the result will be a reduction in overall size. Significantly, it will allow the device to return to being only ~100mm deep. Expected depth will also be slightly improved, as the joystick port will not longer be located beneath the battery. This means that the battery can sit perhaps 7 – 9mm above the PCB, rather than the current 13 mm forced by the D-SUB. The PCB is 1.6mm thick, and the battery ~15mm thick. Front-side components are ~6mm thick, not counting any raised surrounds required around the buttons and DPADs. Front and rear case facings, including the rear solar panel, will add perhaps 5 mm more. This suggests a total thickness of around 35 mm, and not more than 40mm. Total length will be 220 – 225 mm, allowing for case surrounds, including indentations/covers for power switches and SD/SIM card slots. This is likely to be at the higher end, as having securable covers over the SIM and SD card slots makes considerable sense, and we are also likely to want at least some kind of simple tamper evident housing to help make evil maid attacks more detectable.

JTAG debugger for the FPGA board will not fit in a ~35mm thick case, but could likely fit in a 40mm thick case. For development versions, a removable hatch could be supplied to make connecting a debug interface easy. However for the same reasons of defending against evil maid attacks, it would be preferable to NOT have such a hatch in final units.

While FPGA pin count is a significant limiting factor to the design, we do not wish to replace the entire FPGA module with either a BGA-placed FPGA on the main PCB, or with a different FPGA board, e.g., one from Trenz with 200+ pins that we have found, because it would effectively necessitate a complete redesign of the PCB. Rather, for this new revision of the PCB, we want to focus on fixing the known problems, and implementing the remaining missing sub-systems. 

Now onto the planned changes:

1 Make assembly easier

There are lots of little resistors around the board of differing values, that are a bit of a pain to place on the PCB when assembling by hand.  As we expect many people to build their own PCBs over time, this would be nice to make easier.

1. Renumber capacitors and resistors to be more easily located on the board.

2. Consider having the numbers relate to the values, where there are some common values?

3. Consider putting sub-system suffixes on other sub-systems, not just modems.

4. https://au.mouser.com/ProductDetail/ROHM-Semiconductor/RS1G120MNTB?qs=npTsUczJOtMlfWBQYBagow%3D%3D parts tend to move during reflow due to asymmetric thermal pad on underside. Consider an alternative part that does not have this problem. Maybe these? https://www.digikey.com.au/product-detail/en/alpha-omega-semiconductor-inc/AO4484/785-1202-2-ND/2353867

2 Remove all intentional transmitters from the main PCB

For regulatory purposes, it is desirable for the main PCB to not be an “intentional transmitter”, that FCC/EC etc approvals are greatly simplified. This means moving the WiFi and BT modules from the main PCB to mezannines, which is explained later in this document.

The design changes for this will be described in separate sections below.

3 PCB Outline Changes

1. Return the PCB outline to the main rectangle, removing the extensions for the D-SUB connectors (ERRATA#20).

2. Make a notch in the PCB for the touch digitiser cable to be able to wrap around the edge, without being crushed. (ERRATA#2).

4 Remove Smart-Card Connector

Removing this frees up a lot of PCB space, and 2 FPGA pins.

1. Remove smart-card connector.

5 Speakers / Headphone Jack / BT Circuit Changes

Net PCB area change: reduction of 4 – 8 cm^2

The MEGAphone has both a headphone jack with audio in and out, and separate from that, 2W amplifiers for stereo internal speakers. These audio circuits are completely separate from one another, and both have problems that require rectification.

It may well be possible to eliminate the bulk of the headphone audio output circuit, using a simple R/C filter to knock out the high frequency components (>22KHz) of the signal, and just give it some reasonable amplification. Maybe a transistor on the digital signal to provide more current, and then the R/C filter would give reasonable sound quality? Would it be too inefficient, as the high-frequency energy would be dumped after amplification.

We suspect that the amount of high-frequency energy that is reaching the speakers with the current circuit design is also why the speakers in the MEGA65 get hot, and thus it would be beneficial to add additional high-frequency filtering to the internal speaker circuit.

Separately, we could move the entire audio circuit – including the BT module onto a mezzanine, so that these problems can be resolved asynchronously from the main PCB. This would also reduce pressure on PCB space. We would only need to have 3.3V, 5V, GND, UART RX/TX for BT, 4x PCM audio lines for BT and three lines for headphone jack = 12 pins. This would also help the BT antenna to be further from other components etc. The internal speaker connectors could be on the mezzanine board instead of on the main PCB.

The main challenge here is that the LCD panel is behind the PCB here. So as with the existing speaker connectors and WiFi header, we will need to make those pins flush, and provide insulation on the panel side of the PCB.

1. Consolidate the stereo speaker headers into a single smaller 4-pin connector to save PCB space (ERRATA#6). (Note that this will end up being on the mezzanine connector, instead of on the main board.

2. Design a mezzanine PCB that replaces the entire audio circuit, the BT module layouts on the main PCB, and that routes all necessary signals (ERRATA#8). This mezzanine requires 3.3V, 5V, GND, UART RX/TX for BT, 4x PCM audio lines and three lines for headphone jack, plus one extra for the headphone jack sense line and the two PDM audio lines for the stereo internal speakers. It should use a BM83 BT module in place of the existing RN52 for Bluetooth function (ERRATA#9).

3. Determine connector type and location for the mezzanine PCB, taking into account layout on the main PCB and stability of the mezzanine PCB during connector insertion/removal.

4. Ensure that the BT antenna of the BM83 hangs slightly over the edge of the main PCB outline for optimal performance (ERRATA#10).

5. Change the audio filter circuit for the headphones to something that more effectively blocks high-frequency noise to fix the excess background hiss of the current circuit (ERRATA#21), e.g.:
   https://github.com/MrBuddyCasino/ESP32_MP3_Decoder/blob/master/doc/filter_schematics.png
   or even the very simple:

   https://web.archive.org/web/20180423024219/https://janostman.wordpress.com/audio-hacking-with-the-esp8266/

6. Consider removing the audio amplifier for the headphones jack, if not required, i.e., if the new circuit is loud enough without amplification (ERRATA#22).

7. Connect headphone jack sense line to a spare I2C IO expander input pin, so that we can detect when headphones are connected (ERRATA#23).

8. Add additional high-frequency filtering to the internal speakers to block all energy above 22KHz.

6 MEGAphone Power Management Circuit Ideas

Net PCB area change: 0 cm^2

The CN3801 is a simple solar MPPT (constant voltage, which is okay, but not optimal) LiFePO4 charger IC.

There is a nice little design based on this that does exactly what we need:

https://easyeda.com/wagiminator/y-cn3801-lifepo4-solar-charger_copy_copy

This has battery protection, 5V step-up and the solar charge circuitry all in one. The only question, really, was whether the circuit is too big to fit on our board.

It should also allow charging from a normal boring USB mini/micro connector, admittedly at lower current than we can supply through a barrell connector. But USB charging might trump that. Or we can just add a microUSB power input connector parallel to the DC barrel connector, since it won’t take much space.

A further advantage of using this circuit, is that the DC barrel connector will be treated like the solar panel, and thus able to be up to ~21V, allowing use of a MEGA65 12V DC power supply. Appropriate over-voltage protection will be required when both DC and solar are active, if the solar panel is capable of generating >12V.

The PCB area is ~15.35 cm^2, but could probably be reduced to more like ~12cm^2. So it might be possible to rearrange the power connector corner of the PCB to smoosh it in, especially if we put a few of the larger easier to place SMT components on the reverse side of the PCB, where there is (a little bit of) space above the D-PAD, especially after the DPAD gets shrunk to its correct size.

The main challenge would be that the headphone jack and its amplifier and filter circuits would need to be moved – but we are already planning to put those on a separate mezzanine PCB, so this is not a problem.

Actually, we can do this much more simply and easily: Use this existing power module as a mezzanine PCB that sits adjacent to the battery over the corner of the PCB that has the DC barrel connector and battery connector. Indeed the battery connector can then be replaced by two a 2-pin IDC header that just run jumper leads to the power circuit, which then also directly connects to the battery. Thus we lose no PCB space.

The only issue would be making the mazzanine PCB sit stably, as it has no mounting holes through which we could fix it to stand-offs. It would not be hard to extend the PCB to include such stand-offs. It could also be extended to include a header for the power connections, and microUSB + DC barrel connectors. These would all be placed where the current DC barrel connector and battery bulk connector sit on the PCB, so that they won’t interfere with the Pi Compute Module slot (described later). If the DC barrel connector and microUSB connector are placed on the opposite side of the stand-offs to the rest of the PCB, this will help to counteract the mezzanine leaning down over the Pi CM too easily. Similarly, if we make the power header connector sideways and long enough, it will also help to stabilise in that axis.

Care will be required to make sure the stand-off hole(s) and header don’t line up with the D-PAD. Some creativity may be required here, as to working out the best placement, but it should be possible. There are already two stand-off holes in the general vicinity.

Overall, what we are proposing is to take this y-cn3801 based PCB, and adapting it to meet the above requirements:

1. Take the y-cn3801 PCB design, and modify it to include 2.1mm DC barrel connector (centre positive) and USB micro connectors, both of which are parallel to the solar panel input, and thus can be used to charge the single LiFePO4 cell. Provide a two pin 0.1” IDC header for the solar panel (ERRATA#24, ERRATA#25). It is possible (but should be verified) that all three of these can simply be connected in parallel (ERRATA#26).

2. Also modify this PCB design to be able to fit as a mezzanine PCB, located on the battery-side of the MEGAphone PCB in the corner where the current DC connector and battery connector are attached. Take care to ensure that the hole-throughs do not interfere with the D-PAD pads on the opposite side of the PCB.

3. Add the means to measure the battery voltage to the main PCB, so that the level of charge can be determined (ERRATA#27). There is considerable freedom as to how this could be done. One approach would be to add a 2^nd LIS3DH accelerometer, and use one of the ADC inputs of that to monitor the battery.
   If this ADC is placed on the power mezzanine, this would give it separation in the X, Y and Z axes, and allow the two ADCs in combination to detect rotation as well as orientation, which while not a core requirement, would be a pleasant side-effect of solving the battery voltage monitoring function in this way. This would require connecting one of the I2C busses to the power mezzanine, and selecting an appropriate available I2C address for the accelerometer. The existing LIS3DH would then ideally be moved as far as possible towards the opposite corner of the PCB to maximise the ability to detect rotation.

4. While tending to the LIS3DH accelerometer, the current circuit has the sense of the interrupt lines reversed. Correct the sense of this circuit, or no space, remove it (ERRATA#36). It would be desirable to connect the interrupt pins on the newly added LIS3DH as well, as this could be used to trigger an interrupt to wake up the phone when the battery level increases to a certain level.

7 Power Switch changes

Net PCB area change: reduction of ~1 cm^2

It feels a bit weird having two of the power switches on the top edge, and four down the side. We should probably move the two at the top to the same side as the other four. There seems to be space – unless routing congestion causes problems.

As the space on the edge where the switches currently sit is relatively useless, this effectively frees up the space previously occupied by these two switches.

1. If possible, move the two power switches from the top edge of the PCB to the left-edge of the PCB. If the PCB must be widened by upto 2mm to accommodate this, this would be acceptable.

2. Swap pins 1 and 3 of S7, so that the "on" position is "on under control of the power control circuit" and "off" is truly off (ERRATA#39).

8 NOR OTP Flash + IO Expander U12

Net PCB area change: reduction of ~2 cm^2

These can most likely, and should be moved to the reverse side of the PCB, as both can be placed relatively simply using hot-tweezers or other soldering techniques, without requiring double-sided relow. This will free up a little bit of space.

1. Move the NOR flash to the reverse side of the PCB (ERRATA#41).

2. Move IO Expander U12 to the reverse side of the PCB (ERRATA#41).

3. Connect the SI and SO pins of the NOR flash to pins on the U12 IO expander (ERRATA#40).

9 LCD & Panel Touch Connector Relocation

Net PCB area change: reduction of ~3 cm^2

1. Remove the currently routed 6-pin FLC connector for the touch panel, and the 6-pin FLC connector near the bottom of the PCB, but not the one nearest the bottom of the PCB, which is to be retained (ERRATA#5).

2. Remove the smaller of the two slot-holes in the PCB, and the two extra 6-pin FLC connectors to free up some PCB space (ERRATA#29). This will be somewhat offset by having to route the I2C lines further to get to the connector’s new position.

3. Move the remaining 6-pin touch panel digitiser connector 2mm in the direction of the D-SUB9 joystick port (ERRATA#3).

4. Move the 40-pin LCD panel connector 10mm further towards the top of the board (ERRATA#1).

10 Touch-screen 6-pin connector footprint wrong

The mounting pads are wrong for the connectors we are using, resulting in inadequately stabilised connectors prone to ripping off, and taking tracks with them. Work around is to hotglue them down, but on next PCB revision we should just fix them.

1. Ensure the footprint and connector for the 6-pin FLC connector for the touch screen match. This should be a piano-hinge type connector, as other forms of FLC connector have been tested, and proven to be a royal pain to insert.

11 LoRa Modules

Net PCB area change: 0 cm^2

We should replace these with ones based on the RNode, which uses a much newer chip, and are Arduino compatible. It’s not clear what the net difference in PCB area will be. It is likely to remain similar. It may be that one STM32 is sufficient to control both LoRa chips, which would also free up two FPGA pins, which is a rather attractive proposition.

1. Replace the on-board LoRa radios with a single header connector that can be used to connect an arbitrary packet radio module (ERRATA#12). This connector should be compatible with the RFD900 packet UHF radio.

2. Design an Rnode compatible PCB that can be fit to this header connector, and still fit beneath the battery (ie no higher than the other components under the battery, and not physically overlapping with other components in the region, and with the antenna protruding just beyond the edge of the main PCB, if possible.

12 Q15 Fix

Q15 is a MUN5233 on the R2 board, and the bodge fix that was made apparently is a BSS138. This should be updated on the new PCB. See section 5.1.7 of Lucas Moss’ thesis for an explanation of the problem, and the temporary fix used there.

1. Replace Q15 with a BSS138, including any consequent corrections required (ERRATA#44).

13 Replace VGA with HDMI interface

Use the HDMI circuit design from the MEGA65 R3 PCB schematic to implement HDMI, freeing up a number of pins (ERRATA#4). We need to verify that the necessary signal integrity is possible via the standard .1” IDC headers for this. This may mean that the first step is to make a small test PCB that has just an HDMI connector that can connect to the TE0725 via its IDC headers, in the same location as would be required on the complete PCB.

1. Replace the VGA interface with HDMI interface based off the MEGA65 R3 PCB (ERRATA#4).

14 Relocate and verify orientation of ESP8266 Connector

1. Relocate and reorient this connector so that the wifi antenna would hang slightly over the top edge of the PCB (ERRATA#7).

2. Verify the pinout and chirality (correct side of mirror/PCB orientation) of pinout for the ESP8266 to attach to the rear (non-panel) side of the PCB (ERRATA#7).

3. Connect RST and all other open pins on this connector to spare I2C IO expander pins.

15 Use Opto-Isolators for improved power isolation

Back-flow through a number of the circuit interconnections result in sufficient voltage and current to allow some components to continue to operate when their VCC is shut down. The issue is that voltage can flow from powered on components to components that are supposed to be powered down. Thus it is pins that are inputs into the various power domains that are the primary problem. However, any output that has pull-up external to the power domain will also require isolation.

1. Identify all pins that can potentially leak current between the various power domains.

2. Add opto-isolators or some other means of isolation on all mono-directional signals between the different power domains (ERRATA#11).

3. Audit the final design for current leakage between the different power domains.

16 Verify microSD card connectivity

The test PCB had an assembly fault, that means the microSD card could not be properly tested.

1. Confirm correct layout of microSD card, and remediate any problems identified (ERRATA#13).

17 M.2 Expansion Bays

Net PCB area change: ~1-2 cm^2

There is conflicting information on the correct voltage for the UART voltage for these. We have been using 3.3V, and it seems to work, but according to the EC-25AU documentation, they should be 1.8V.

1. Move M.2 UART connections to use voltage level converters, with a mechanism to select either the 3.3V or 1.8V domain (e.g., via PCB jumper pads) (ERRATA#14, ERRATA#15). The existing voltage level conversion circuits used on other pins of the M.2 bays can be used as a model for the voltage conversion.

2. Add pull-ups to VCC_FPGA on the RI lines on the M.2 bays (ERRATA#37)

3. Examine and correct the circuit for Q2_M1 and Q2_M2, if required (ERRATA#38). See the blog post for explanation of the problem.

18 Real Time Clock

We have proposed switching the real-time clock to match that used on the MEGA65 R3 PCB. However, this is not necessary, and to avoid (further) unnecessary changes to the PCB, we will leave it as it is. Thus we are NOT acting on ERRATA#16.

19 D-SUB9 Joystick Port

1. Copy the POT-X/Y circuitry from the MEGA65 R3 PCB (ERRATA#17)

2. Allow the FIRE line of the joystick port to be controlled and read at high-speed, by using 2 FPGA pins: one to read the level-converted FIRE input, and the other to control a transistor that can be used to pull the 5V side of the FIRE pin to GND when activated. Retain the existing connection to the I2C IO expander (ERRATA#18).

3. Move the D-SUB9 connector to the approximate position of U24, so that it can fit in the main rectangular outline of the PCB (ERRATA#19).

20 D-Pad

In short: The spacing between the pads is currently 18mm, but should be 16mm.  The outline hole positions for retaining the light green contact part must also be reduced. The distance between these should be 30mm, rather than the 40mm on the current PCB. The outline of the circle should have a diameter of 29mm, cropped at top and bottom to 27mm. See the blog post for more specific information.

1. Fix the position and markings of the D-PAD, including orientation holes (ERRATA#28).

2. Replace the two small thin black buttons with another pair of round pads, as described in the blog post (ERRATA#29).

3. Swap the function of the existing pair of round pads and the two thin black buttons (ERRATA#30).

21 Thumb-wheel knobs

We had a terrible time trying to work out the correct resistance to get full range of motion being detected on the volume wheels. Thus we wish to replace all the fixed resistors for the voltage dividers with trimpots, so that we don’t have to worry about this.

1. Replace R46, R47, R48, R67, R68 and R70 all with 1K resistors, and place 50K Ohm trim-pots serially with each of those resistors (ERRATA#31).

2. Change VCC_FPGA to VCC_MIC for the thumbwheels (ERRATA#33).

22 Indicator LEDs

One of the buttons on the PCB causes LEDs either side of the LCD panel to illuminate if the relevant sub-system is powered. However the carbonised rubber buttons have high resistance, which is also somewhat proportional to the pressure on the button. This causes the indicator LEDs to vary in brightness with pressure, and between one another, because of the way the circuit is currently structured. It would be better to digitise the button, so that constant voltage and current is supplied to the indicator LEDs.

There is also some problem with the VCC_MIC power rail, as described in the blog post and referenced in ERRATA#34. It is quite possible that adding isolation among the different voltage domains will correct this problem.

1. Digitise the indicator button input to deliver constant voltage/current to the indicator LEDs (ERRATA#32).

2. Investigate the whole VCC_MIC power rail and associated indicator LED circuit for correctness, as something is clearly wrong with it (ERRATA#34).

23 Infrared LED Receiver

1. Add a TSP382-series or similar IR LED receiver using last spare FPGA pin (ERRATA#35).

2. Verify that the specified IR TX LED is compatible with this receiver.

24 Raspberry Pi Slave Processor

An anticipated criticism of the MEGAphone will be that it cannot run modern phone apps, e.g., designed for Android. This problem is largely resolvable by allowing the attachment of a slave processor that can run an Android instance. One approach to this is to use a Raspberry Pi Compute Module for this purpose. The latest revision of this board contains 32GB onboard flash, and thus does not require an external SD card. There is also a "lite" version that does use an external SD card slot. As we have an unused SD card slot on the 2nd SIM card/SDcard slot, it probably makes sense to use the "lite" version.

The compute module itself is 68mm x 30mm compared with the 60mm x 40mm footprint of the Smart card. There are vertical and horizontal connectors. The horizontal connectors are preferable.

Basically the idea is to add a Raspberry Pi with its digital VGA output in parallel to the MEGAphone’s own digital VGA output, with these two being muxed to the LCD panel. Several of those signals, in particular HSYNC, VSYNC and PIXELCLOCK need to also be available to the FPGA as inputs, so that the MEGAphone can synchronise with the Pi’s display for displaying composited over-lays, e.g., for call notifications. Some creative re-use of existing inputs is required to achieve this. The current plan is to multiplex four input lines from the M.2 modem bay with these four signals from the Pi. The multiplex control can be driven from a spare pin on an I2C IO expander. The M.2 UART RX, PCM DATA OUT, PCM SYNC can be the 3 pins that are multiplexed for this.

Refer to the blog post for more information on what is being considered here.

1. Remove the smart-card connector.

2. Add a connector to accept a Raspberry Pi Compute Module and associated interface circuitry (ERRATA#42). This should be powered from an independent VCC_PI, which can be hard-switched by the same switch that controls the power to the 2^nd M.2 module, but with an independent soft power cut circuit. See https://www.raspberrypi.org/documentation/hardware/computemodule/datasheets/rpi_DATA_CM3plus_1p0.pdf for information about the power control requirements for the Pi, including the sequence of power on.

3. Multiplex the Raspberry Pi and MEGAphone’s digital video interface to the LCD panel, with multiplexor control via an FPGA pin.

4. Multiplex the Raspberry Pi’s HSYNC, VSYNC and PIXEL CLOCK lines as described above, with the selection pin coming from an I2C IO expander, so that the FPGA can read these signals at high speed.

5. Add a multiplexor to the touch panel I2C bus, that allows the FPGA to connect to the Pi’s I2C bus or to the touch panel I2C bus. Note that the Pi cannot directly connect to the touch digitiser, as we intend to have the FPGA provide synthetic touch events to the Pi (ERRATA#43).

Summary

The above changes explicitly indicate which errata they address, so that I could check in the reverse direction, that all errata are covered.  Together with identifying the design and component changes, this covers the first of the five requirements of this milestone:

• 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.

This also has also dealt with the next three, to the extent that this is possible:

• 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.

We are currently talking with a contracter to do the actual PCB layout, which is focus of the next mile-stone, so it is counter productive to define the PCB floor plan more finely than we have done in the above text.

So indeed, the next step is to get the next PCB revision completed, so that we can then get some prototypes built up from that, and get the MEGAphone hardware working to the point where it can be shared with the community more widely, so that we can move onto the software side of development -- which is all very exciting :)