MEGAphone PCB Re-spin

In amongst everything else, we have had an engineer, Goran, working on the MEGAphone PCB design under the NLnet Foundation grant that they awarded us.  

 

This is the fourth milestone from NLnet on this project:

4. Either Complete MEGAphone r3 PCB design or Design simple near ultrasound communications protocol

This is the first of two sub-tasks that will be decided based on the outcome of sub-task 1, the prevailing conditions of the COVID19 crisis, and the progress of other projects working in this area. Essentially, if the MEGAphone is capable of near ultrasound communications, and there continues to be a need for this, and no other project has obsoleted the need for advancing this field, then it is anticipated that the near ultrasound pathway will be pursued, and that otherwise the revision 3 PCB design will be pursued.

Milestone(s)

• This milestone shall be considered complete as soon as any of the two following options are complete.

• Complete MEGAphone r3 PCB

• Transform the schematic and PCB changes necessitated by sub-task 2 into a PCB design that is ready for test-fabrication.

• 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 announcing revised schematics and PCB layouts.

• Design simple near ultrasound communications protocol

• Taking into account the capabilities of the low-cost commodity MEMS microphones and readily available speakers that can be included in the MEGAphone, and the centre frequency and communications bandwidth that these entail, design a simple near ultrasound communications protocol.

• Creating an optimised protocol is beyond the scope of this milestone. Rather, the focus shall remain on creating a protocol with sufficient bandwidth and appropriate properties that would allow its use in an application like COVID19 contact tracing, i.e., a bandwidth of 10 – 10,000 bits per second, and a range of 1 – 10 metres.

• The primary activity of this sub-task is to outline the physical and link-layers of a potential protocol that would satisfy the requirements outlined above. It is possible that more than one protocol option will be described, which are likely to contain performance/complexity of implementation trade-offs.

• It is possible that a negative result will occur, i.e., that after careful consideration, it is not believed to be possible, for one or more reasons that may or may not be surmountable.

• The milestone shall be considered complete when one or more such protocols have been designed and sufficiently described as to be implementable, and communicated via the MEGA65 blog (https://c65gs.blogspot.com.au), or in the negative, that the reasons why such a protocol is not possible at the current time, together with suggestions as to how this might be remedied. (€ 10000)

Reading the above, there were two different options that we were allowed to pursue.  In an earlier post we explored the ultrasonic communications capabilities of the MEGAphone design as part of NLnet's desire to consider non-BlueTooth options for automatic contact tracing.  While it turned out that ultrasonic communications would indeed be possible, we also came to the conclusion that it was not really feasible for that use-case.  QR codes and manual logging of entry into businesses has taken over that role here in Australia at least.  So anyway, we've all had enough of COVID19 I am sure, so no one will be sad that the rest of this post focuses on the more fun option of doing the PCB redesign for fabrication... and that design is now complete, ready for the next iteration of the PCB to get fabricated.

So let's start with the set of desired changes that we had on our list to resolve, and work our way through those:

1 Make assembly easier 

The goal here was to use less variety of resistors etc to make hand assembly simpler.  As the other changes ended up being quite major as you will read below, we came to the unfortunate conclusion that it is still a bit too early to optimise by trying to use the same resistor values in more places.  Thus only some relatively small optimisations were possible at this time.

2 Remove all intentional transmitters from the main PCB

This has been accomplished, with RFD900-compatible connectors in place of the LoRa radios, for example, and WiFi and BT reserved for a future little mezzanine PCB, thus making the main PCB devoid of all intentional transmitters, as planned.  The following 3D model of the underside of the PCB shows how these modules can be fitted:

In this image, from left to right, we can see the blue JTAG adapter for the FPGA board, the green FPGA board, then the two grey RFD900 radio modules, which can instead be other radios (including ones we might design in the future) that use the same fairly common pinout. Then on the right we have the two M.2 bays with cellular modems (light blue) fitted, above which sit the D-SUB 9 joystick port, headphone jack, battery connector and DC barrel power connector.

3 PCB Outline Changes

The PCB outline has been returned to the original rectangle, with no excursions for the big D-SUB connectors.

4 Remove Smart-Card Connector

This has been removed, and made space for a Raspberry Pi Compute Module, as we will discuss further down.

5 Speakers / Headphone Jack / BT Circuit Changes

The old incorrect BT module has been removed from the PCB, and the new WiFi/BT mezzanine connector has the necessary connections for the new BT module to be wired in, when we get to that point.  The speaker and headphone circuits have been moved to accommodate this and other changes on the PCB.

6 MEGAphone Power Management Circuit Ideas

The long-term goal is to have power management capable of charging an LiFePO4 battery from solar panel on the rear of the device, or from a USB or other DC power source.  The existing power supply could not run from a 1S battery without a bulky boost converter.  Fixing all these things to make a solar chargeable device is well beyond the scope of this milestone.  But what we were able to do was to fix the soft power-on and power-off functions, so that the existing power supply design can work properly with a 2S battery configuration.

7 Power Switch changes

The power switches are now all on one side of the device, which is much better and simpler. We also fixed problems with incorrect wiring of one of the power switches, so that these will now all work.

8 NOR OTP Flash + IO Expander U12

The corrections to the interface for the NOR flash for one-time pad storage have been deferred due to all the other changes made.

9 LCD & Panel Touch Connector Relocation

These connectors have been moved to the correct location.

10 Touch-screen 6-pin connector footprint wrong

This has been resolved as part of the movement of the connector relocation above.

11 LoRa Modules

These have been removed and replaced with RFD900-compatible connectors to allow the use of a wide variety of existing and future radio modules, giving better flexibility, and improving the modularity of the design, allowing those modules to be worked on in future, without having to build whole new PCBs.

12 Q15 Fix

This problematic power circuit section has been reworked and corrected.

13 Replace VGA with HDMI-compatible interface

Done. We now have an HDMI-compatible digital video + audio connector, which is fed directly from the FPGA using work that Goran had done for another open-source HDMI-compatible device. 

14 Relocate and verify orientation of ESP8266 Connector

Fixed as part of moving to having the WiFi+BT mezzanine PCB

15 Use Opto-Isolators for improved power isolation

The power isolation is to ensure that when we power down the cellular modem or other untrustworthy peripherals, that there is no back-current leakage allowing such devices to retain some power.  The previous revision of the PCB was horrible in this area, and there is now much better separation of the power domains between the major components, however we expect that there will still be some more work to achieve total power separation.  This new revision of the PCB will allow us to determine where such remaining back-current flows are occurring, now that we will have removed the major known ones.

16 Verify microSD card connectivity

Done -- this is now correctly wired to matching the working reference design.

17 M.2 Expansion Bays

The change required here was to make the UARTs have 1.8V level converters, so that the M.2 cellular modems can have the right voltage for the UARTs, instead of 3.3V which we were using previously.  3.3V seemed to work, but possibly only through luck.  We now have level converters in the UART path to solve this.

18 Real Time Clock

The original plan here was to switch to using the same RTC chip as on the MEGA65 R3 PCB.  However, as we looked into it, there seemed to be little point in doing this, as there are in fact a number of target specific components and registers on the MEGA65 already, and a system for managing this. Thus given all the other major changes, it was felt that achieving commonality for the RTC was thus no longer a priority. 

19 D-SUB9 Joystick Port

This connector is one of the ones that was sticking out from the rectangle outline of the PCB on the previous revision. This has been corrected, and the D-SUB connector moved to accommodate all the other changes.

20 D-Pad

The D-Pad connector is now the correct size.

21 Thumb-wheel knobs

Trim-pots and improved resistor ladders have been put in to replace the problematic fixed resistor ladders that were problematic to get the correct voltage range on the thumbwheels. The new trim-pot arrangement will allow us to determine the exact resistor values required.

22 Indicator LEDs

The indicator LEDs illuminate with uneven brightness, and require changing of the resistor values to reflect the different voltages being fed to them.  This requires only changing the resistor values, not the PCB layout, and thus have been deferred until we optimise the various resistor values.

23 Infrared LED Receiver

The infrared transceiver changes have been deferred due to being reassessed as lower priority than adding provisional support for a Raspberry Pi slave processor.

24 Raspberry Pi Slave Processor

Originally we were not expecting to do much on this front, however using Goran's experience with digital video circuitry, we have managed to make space for the Pi Compute Module, and connected the video output from the CM connector, as well as the UART lines to the FPGA on the MEGAphone. That is, we have the facility on this new PCB revision to test integration with a Pi, that can in principle be used to run Android, and have its video output relayed to the LCD panel in real-time via the FPGA.  This is an exciting development, and helps to address the anticipated objection that people will make about the MEGAphone being "too simple" and "can't run Android apps", by making this possible in a controlled manner.  

The following image shows how the Pi CM4 would sit between the PCB and RFD900 (or other) radio modules:

Summary and Next Steps

So, over all we now have the new PCB revision done, and it addresses the issues that we documented in the previous milestone, and are ready to send the boards off for manufacture.  The few small items we have not addressed have been assessed as being able to be deferred, to make room for higher-priority work, primarily around making it possible to incorporate a Raspberry Pi Compute Module that can be used to run Android, and the shift from VGA to HDMI-compatible video output, to free up sufficient FPGA pins to make this possible.