In the previous post, I got to the point where I could talk to the I2C IO expanders that are used to read the buttons and joystick port, and control the various power rails. The next step is for me to confirm that all those power rails can indeed be switched, and confirm that all is well with that, so that I can then happily move on to bringing up the main FPGA, and get to the point of having a MEGA65 READY display. At that point, the core bring-up will be complete. There will still be a lot of work following that, to make the whole device work, but we will have confirmed that the major differences to the previous revision of the board are functioning correctly.
For a spoiler for how far we get:
Note that the MEGA65 in the right of the image is off: It is the hand-held unit in the lower left that is driving the HDMI display, as well as its own LCD, and running the OpenROM BASIC. Yay!
So let's dive into how we get to that point:
Modem 1 - '@' activates 3.3V power, and '`' should disables it (without a modem plugged in, it takes a while to sink back down to 0V)
Modem 2 - 'A' activates 3.3V power, and 'a' disables it (without a modem plugged in, it takes a while to sink back down to 0V).
RFD900 Modem bays - 'B' activates 5V power and 'b' disables it (without a radio installed, it takes a while to sink back down to 0V).
ESP32/Wifi Module Bay - 'C' activates power which sits at around 3.7V without a load, and 'c' disables it.
Screen power - 'D' and 'd' should control this. Goran has previously tested this one, and there isn't any convenient test point, so it will have to wait until I have a screen attached.
Speaker Amplifier 'E' and 'e' should control this. Will tests it when I have the main FPGA running and can try something.
Mic / Joystick Power - 'H' activates it and 'h' disables it.
So apart from the screen and amplifier, that covers the directly switchable modules. We now just need to confirm the Xilinx FPGA module power can be switched.
The FPGA power is controlled via an S-R flip-flop. The /R line of the flip-flop is tied to the "FPGA Power Off" line which is connect to the OrangeCrab. The INTerrupt line from the various I2C peripherals and the "power on" button are connected to the /S line, so that the main FPGA can be powered on by any of those events.Specifically, the INT line can be pulled low by either of the cellular modem bay's Ring Indicate signal, the INT1 line of the accelerometer, the real-time clock, or the INT line of each of the three IO expanders.
The INT line cannot however be directly read by either the OrangeCrab or the Xilinx FPGA. This means that it is a bit tricky to use the "power on" button for other purposes, including just being able to tell when it has been pressed when the screen is disabled, but the Xilinx FPGA is being kept on for some reason, e.g., if the device was being used as a music player. So we should probably connect it to one or the other of the two FPGAs.
The easiest solution here is to use one of the unallocated pins on the Xilinx FPGA connector to tie to the /INT line. Doing this will also help reduce the latency for detecting and responding to interrupt sources on the Xilinx FPGA. I've filed an issue to make this change on the next revision of the board.Now, back to switching the FPGA power, the gpio_a0 line on the OrangeCrab is connected to this line, so we can switch off power to VCC_FPGA by pulling that line low. I have setup the . and : characters on the control UART to pull this line low (i.e., request power be cut to the main FPGA), and to drive it high (i.e., stop requesting power be cut to the main FPGA). So to request a power cut, what should really be done, is to do . and then :, so that the flip-flop will request the power cut, and then release it after a little while, so that if the main FPGA is turned on via an interrupt, that it won't just be turned off again straight after. So I will adjust this to just have . pulse the line low for a short time.
I've implemented that, and it works: When I send a . the power cuts, and then comes back on again a few ms later. This is currently expected behaviour, because the I2C IO expanders are currently powered on VCC_FPGA, and thus they get their power cut. When their power is cut, their /INT lines go low, and this thus requests that the power to VCC_FPGA is re-activated. At least that's my working hypothesis, and one that is quite reasonable.
Anyway, at this point we now have all power rails working as expected for this prototype board, and we can finally move on to adding the Xilinx FPGA board. It's a known errata that the Xilinx FPGA board pinout was rotated 180 degrees from what was intended. This doesn't really matter, except for making the USB JTAG connection face inwards over the board, rather than outwards out the side of the board, as the following image shows:
Then with a bit of work, I have an empty bitstream building, that in theory, should be able to drive the LCD display and digital video outputs, but will still be missing some parts. I already know from Goran that we have a problem with the digital video output, because of a thing I forgot about with VCCIO requirements on Xilinx FPGAs for producing TMDS25 differential signals that are needed for DVI and HDMI. Thus my focus will be on getting the LCD panel working.
The first step to getting the LCD panel working, is to hook it up. Because this is a prototype board, we have a bunch of bodge wires that we have to dodge, and also we don't have a custom shim yet to go behind the screen to ensure electrical isolation from all the connectors underneath it. For this unit, I am just cutting a piece of cardboard box to do the job, and which will also act as the jig to hold the LCD panel in place, yet still be easy to remove:
Making holes for the LEDs like this means the cardboard holds itself in place, but can be easily removed later, when I need to rework the board. Next step is to make cut-outs for the thicker bodge cables, so that it sits flat enough, that the LCD's ribbon cable can still reach the connector on the other side:
Then a loop of packing tape to hold the LCD panel in place, and route the ribbon cable through:
And finally, flip the screen right-side up and onto the loop of tape:
Not bad for a bodgey test unit, I think.
For those who have been following for a while, this LCD panel is an upgrade on the previous generation that I tried. It is in theory 1000nit brightness, so should be usable in full sunlight, all going well. They come in both capacitive and resistive models. This one is resistive, so I won't be able to test the touch panel directly with it, but I am pretty sure I have some capacitive ones lurking about somewhere.
In fact, I found one of the capacitive ones, already, so I really should just switch it over now, and be done with it. Done. And I think the black bezel looks better, too:
So now in theory we should be able to power it up again, and turn on and off at least the LCD backlight, since that is controlled by the OrangeCrab, and then work our way towards getting an actual image on the display.
First stop is to get the backlight to turn on, which we should be able to see.
The relevant lines from the IO expanders are:
LCD Standby - F to enable, f to disable
LCD Display Enable - L to enable, l to disable
LCD Backlight Enable - M to enable, m to disable
VCC_LCD Enable - D to enable, d to disable
So typing: DLMf into the OrangeCrab serial port should get the LCD powered up. But I'm not seeing anything just yet. Let's check the pinout of the LCD connector, and look for the voltages in the right places. I have also just made sure all the power isolate switches are not preventing things.
Pin 1 - LEDK
Pin 2 - LEDA
Pin 3 - GND
Pin 4 - VCC
Pin 5 -- 28 - RGB signals
Pin 29 - GND
Pin 30 - Pixel Clock
Pin 31 - DISP
Pin 32 - HSYNC
Pin 33 - VSYNC
Pin 34 - DE
Pin 36 - GND
And that's all the signals it has. So let's first look for LCD VCC and backlight LED cathode and anode (LEDK and LEDA) signals.
Okay, I can see at least the backlight voltage on pins 1 and 2, but in the process I have noticed that the LCD panel ribbon connector has pulled loose from the connector. With that fixed, D to turn on the VCC_LCD and M to turn on the backlight does now work, producing a soft glow from the screen:
The light in this room is not that great, and you can see how the crappy camera in my phone has reduced the exposure to try to balance things, making the screen look quite white, the PCB very dark and gloomy, and the little red LED look much brighter than it is.
That all said, this is a good indication of just how bright this LCD panel should actually be. Going through my email, it looks like I actually ordered 1300nits versions, rather than 1000nits, so I'm really hoping that these will be spectacularly bright. But first we have to get an image displaying on it.
The test bitstream I built earlier in the day should in theory be driving a test pattern display onto the panel interface. So I'll plug the Xilinx FPGA board back in, fire it up, and see if it shows anything, and if not, start checking that we have the right signals on the right pins.
What I am seeing is a ~800Hz waveform that looks almost identical on all the pins -- whether RGB signals, HSYNC, VSYNC or the DE line. It could be that I have pulled a dud FPGA board out of the pile (I have a dud one somewhere among them, but can't remember which), or that the bitstream is producing rubbish. This won't be too hard to figure out, even if it takes a bit of time to make some alternate test bitstreams.
Hmm... It might be the dead FPGA board, as the FPGA itself is quite hot. Much hotter than it should be. Time to try to find another one... I have one last brand new on in its box, which will need its headers soldered on. Time to head out to the shed for a few minutes, then.
Okay, all soldered up and connected. FPGA on this board is pleasingly cool, instead of almost hot enough to burn your finger. No image on display, yet, though. So let's examine those signals again...
Well, not really on that topic, but I have noticed that the backlight LED power doesn't go completely to zero when the VCC_LCD is disabled. It drops to around 2.65V, but still enough that the backlight doesn't go black. It's probably back-flow of current through the /SHDN line when its high, partially powering things. Issue logged for adding a resistor in-line between the EN_BACKLIGHT and /SHDN pins, so that there is no current supply available to do this back-powering. In the meantime, I should make sure that I clear EN_BACKLIGHT when VCC_LCD is disabled.
Now, back to debugging the test pattern display from the Xilinx FPGA. Let's see what we can see on the various digital video pins to the panel... and I see nothing.
For pin 30, we should see the 27MHz Pixel Clock, but the line is idle. But I can see the 27MHz signal on one of the pins of the Xilinx FPGA module. In fact, I can see 27MHz on two of the FPGA's pins: Ah, those must be the DVI/HDMI clock pins. That's interesting, because I thought we had this VCCIO problem that would be stopping that. Ah, we are using DIFF_SSTL18_I, instead of TMDS25 or similar... And would you believe it, we have a valid HDMI image, straight up! That was not the order I was expecting things to happen, but I'll take what I can get!
Right, well that is a big win in and of itself. But it also removes any and all doubt that this test bitstream might not have been producing an image. It also tells me that the XDC file is correct for at least a bunch of pins, i.e., those related to the DVI/HDMI video output.
Of course, having just said that, the HDMI display has now just gone blank for no apparent reason. I don't mind too much, as I know that this can be fixed with the correct VCCIO, so that we can use TMDS_33 IO standard instead of DIFF_SSTL18_I, which should make it stable, since the pin connections are all good.
So now to try to find out why we don't have signals on the LCD panel pins that we expect. Looking in the VHDL and XDC more closely, it seems that I haven't actually reallocated the LCD panel pins. And for some reason I still have VGA pin assignments hanging around. So it is clear that my XDC file is not up-to-date.
I know at some point in the past, I went through the whole process of producing a chart showing the mapping of FPGA pins to pins on the headers of the TE0725, which would be super useful right now. Of course I can't for the life of me remember what I did with that. So I'll have to re-create it now.
What I do have that will be helpful for that, is my PIN_ID VHDL module that displays a unique binary code on each pin. There is also an old test bitstream I built for mapping this, which I have just resurrected, and used this pin_id module with. So I have now a confirmed map of the pinout, which I will use to make a nice annotated image, once and for all.
So here is what I believe the pinout to be:
Finally, the pin numbers and FPGA pins and pin positions nice and clear for me.
So with this, I can look at the MEGAphone R4 schematic, and make sure I match things up correctly. In particular, what we care about is this part of the schematic:
U9A and U9B are the J1 and J2 from above. So now I can just populate the XDC file with the correct pin assignments, and then tie this in to the design... and of course I just realised that Goran has been super-nice and put the FPGA pins in blue next to all of these signals :) It is good as a double-check that we have these all around the right way.
Anyway, now to fix the XDC file...
Discovered in the process we forgot to route PCM audio interface to an optional bluetooth module header. We have spare FPGA pins, but no header to connect it. Issue logged to note this.
Trying to get it to synthesise, I have to change the DIFF_SSTL18_I lines for DVI out to TMDS_33, because other lines on the bank are using 3.3V. It might be that VCCIO was 3.3V and this is why the DVI output was working, but not quite right.
Anyway, with those things all fixed, both the LCD panel and DVI output are now working:
The image is offset a bit on the LCD, but that's something I can easily sort out later. The LCD image also has the bottom bits of the red channel inverted, causing visible horizontal bands. I'll fix that one now, so that the colour gradients are smooth.
I've also had a bit more of a dig into the DVI/HDMI output disappearing. The TPD12S016 HDMI companion chip we are using to provide protection for the HDMI lines doesn't claim to have any mechanism by which it can disable HDMI output. One possible clue I have found, though, is that the HDMI monitor says "no cable connected" when the problem occurs -- this likely means that the TPD12S016 isn't supplying 5V on the line that it should.
But in the meantime, suddenly I'm not getting an image on either the LCD or the monitor. So I must have messed something up somewhere. After prodding and fiddling for a few minutes, LCD display is back again. I'll have to investigate this further. It looks like the Xilinx FPGA didn't finish configuring or something.
Anyway, I have succeeded in fixing the banding in the red channel. The LCD display now has a smooth gradient in each of the red, green and blue channels. It looks really nice, I think:
Compare that to the previous image, where if you look carefully at the deeper red corners of the pattern there is quite visible horizontal banding.
I'd like to probe the HDMI interface to see if the 5V line is present or not, but the Xilinx FPGA board sits directly over it, so I'm going to have to investigate that problem using the HDMI protocol analyser at some point.
That said, I have just had a bit of a dig around, and the HDMI output requires 5V which comes from the VCC_MIC line, so we have to have VCC_MIC enabled for HDMI output to work. That means we have to type H into the serial control interface. It doesn't seem to fix it immediately, however. This might be due to the current limiting in the HDMI companion chip. Anyway, after turning it on with H, and then leaving it for a few minutes, I have display on the HDMI monitor again. With a bit more fiddling, I have confirmed that if I turn off VCC_MIC, then after a little while (a few seconds upto a few minutes), then the DVI/HDMI video link goes down. If I turn it back on again, it takes a few seconds, but then the DVI/HDMI output reappears. So I think we have this problem fully understood, and a work-around found, until we can make the 5V to the HDMI companion chip not be tied to the microphone 5V rail.
So I think we are now very rapidly approaching the point where I will put the MEGA65 machine into the bitstream again. The step I will take first, is to re-route the OrangeCrab serial port to go through the Xilinx FPGA, as will need to happen in the end, anyway, and verify that I can control it via the serial interface on the FTDI JTAG adapter on the Xilinx board. This will also mean I need one less cable connected, which will simplify my development and debugging.
The first step for this is to change the OrangeCrab FPGA program to do this. We have 4 lines that connect the OrangeCrab with the Xilinx FPGA. Two of those will be used for this link, and the other two will, as I have described earlier, be used to provide a fast serial link between the Xilinx FPGA and one selected serial port at a time.
Going through setting up all the OrangeCrab pins, I found that we have had to sacrifice one of the four lines to the Xilinx FPGA on this version, because we had originally attempted to use an input-only pin on the OrangeCrab for this. We should move this to the unused bit 7 of port 1 of the U14 I2C IO expander. Issue logged.
Using the great reference at https://orangecrab-fpga.github.io/orangecrab-hardware/r0.2/docs/pinout/ I was able to quickly setup the pin assignments. Again as I did for the TE0725 earlier in this post, having a "this physical pin goes to this FPGA pin" chart is super helpful and makes life much, much easier.
So now to move the UART to the correct pins to talk to the Xilinx board, and built a bitstream. I'll likely also leave the output appearing on the other connector for now, so that I can easily debug crossed-over UART RX/TX lines.
Now to route those lines through to the FTDI UART on the Xilinx FPGA, and build a bitstream for that.
After the usual requirement to get the UART RX and TX lines confused at least 3 times, before finding it was right to begin with, although for some reason it didn't work (a curse that USB seems to have inherited), I can now command the OrangeCrab FPGA via the Xilinx FPGA.
This all means that all the ingredients are now ready to be combined to attempt to bring up the MEGA65 core on this hardware: I just have to insert the machine.vhdl module into the Xilinx design, and then connect various pieces of plumbing, such as the buttons and D-PAD to joystick inputs, and the touch screen and other I2C peripherals.
The bitstream is built, and the serial monitor interface is responding. The timing closure was however pretty horrible, even after I disabled some optional MEGA65 features, such as the virtual 1541. This also meant that synthesis took almost 2 hours, which is also really inconvenient. I've now also disabled the ethernet controller, to see if that reduces the pressure a bit more.
But while that is running, I can at least examine the current build: The serial monitor interface is responding, as I mentioned. The RX side is also tied to the OrangeCrab UART, so that I can still control the power rails for the screen and digital video output. I have confirmed this is working by typing DMFLH to turn everything on required for the LCD panel.
The LCD panel is sporadically displaying things, including the MEGA65's on-screen keyboard. However, there is nothing on the DVI output. I'm suspecting that one or more of the video signals is messed up.
Pin 34 of the LCD interface seems to be showing valid DE (Data Enable) signals, with a 31KHz frequency, which matches the HSYNC rate for the video mode.
Pin 33 is showing ~60Hz VSYNC. Setting $D06F to $00 to select PAL correctly changes the video mode to PAL. So that's good, too.
Pin 32 is showing valid HSYNC data, so that's good, too.
Pin 31 is showing ~2V DC, which strikes me as odd. This is the Display Enable/Standby line, which should be enabled or disabled by F/f on the OrangeCrab UART interface. This line is showing very weird behaviour, changing fairly randomly between 3.3V, ~2V and ~0V:
This should definately not be like this, and is very likely a signficant part of the problem. The question is how on earth this can be happening. The DISP line is only connected to the IO expander and the LCD panel. By resetting the OrangeCrab, I have been able to confirm that the crab is driving the line up and down randomly. I presume that it thinks that it is receiving random commands. It should be listening for serial input on the gpio_miso line. But that line looks idle. With the Crab reset and idle, I can see the serial line from the Xilinx FPGA crossing to it, so the connection is correct.
So what on earth is going on here? I'm going to route the OrangeCrab's serial output to go to the Xilinx FPGA and to a pin on the ESP32 header, so that I can still sample it directly, to see if there are any clues as to what is happening. I want to know which lines are toggling madly. Is it, for example, as simple as the Xilinx FPGA sucking too much power, and this is causing voltages to sag where they shouldn't?
Well, this is quite interesting in a so-far incomprehensible kind of way. I get output like this spewing from the OrangeCrab UART:
MEGAphone CTL0 e2fffff0MEGAphone CTL0 e200fff0ffff8
MEGAphone CTL0 e200ffffffff9
MEGAphone CTL0 e200ffffMEGAphone CTL0 e200ffff471aa
MEGAphone CTL0 7c00ffff4MEGAphone CTL0 7c0fffff471ab
MEGAphone CTL0 7c0fe8fMEGAphone CTL0 7c0fe8d1471ac
MEGAphone CTL0 7c0fe8d1eMEGAphone CTL0 7c0fe8d1e1e1d
MEGAphone CTL0 ff0fe8d1eMEGAphone CTL0 ffffe8d1e1e1e
MEGAphone CTL0 ffffe2d1eMEGAphone CTL0 ffffe20be1e1f
MEGAphone CTL0 ffffe20bfMEGAphone CTL0 ffffe20bffff0
MEGAphone CTL0 a3ffe20bMEGAphone CTL0 a30ce20bffff1
MEGAphone CTL0 a30c6d0bfMEGAphone CTL0 a30c6d6dffff2
This means that at least one line is continually flipping, because it only pushes a new announcement whenever a line changes. What is perhaps a clue in this, is that the announcements are typically appearing at a rather regular interval, which we can see by the way that a previous announcment is chopped off after almost exactly the same number of characters each time, with the messages only being allowed to complete almost exactly every second message. As we know the UART rate is 2mbps, we can work out the frequency, based on how long it takes to send a string like "MEGAphone CTL0 a3ffe20b". That's 23 characters x 10 bits = 230 bits. 2Mbps / 230 bits = ~8.7KHz. Not sure what that means, yet.
Meanwhile, I have confirmed that the VCC_FPGA on the I2C IO expanders is stable at 3.3V, so my sagging voltage rail theory is out the window.
Annoyingly I can't get to U14 to probe the power control pins directly at their source. U12 is the only I2C IO expander I can access with the LCD attached.
Ah... I think I see the problem: The I2C bus of the OrangeCrab is also directly connected to the I2C bus of the Xilinx. These should be separate, with only the IO expanders and U31 ADC for measuring the battery voltage (that I still need to hook up) connected to the OrangeCrab, and the other I2C peripherals connected to the Xilinx FPGA. Then each FPGA can look after its own bus, without fear of messing up the other's.
Okay, so that's very likely to be the root cause of all this, i.e., that two masters are writing to the bus at the same time, causing no end of crazy results. Time to resynthesise with the Xilinx FPGA not driving the bus, and see how that goes.
While that runs, let's just do an audit of I2C devices, and which bus they should be on:
OrangeCrab FPGA: U12, U13, U14 (IO expanders), U31 (ADC for reading battery voltage), U25 (Real-Time Clock), ESP1 (ESP32/WiFi Adapter header)
Xilinx FPGA: U24 (accelerometer)
Okay, so perhaps the easiest solution here is that we have the OrangeCrab control all of the peripherals, and the Xilinx FPGA can actually just snoop the bus, and directly read the state of the various things from the bus. That will likely be faster to develop, anyway, since its really fast to resynthesise and test with the OrangeCrab. It will also avoid the need to communicate the various signals from the IO expanders via the UART link between the FPGAs. So I think I like this approach. It gets low-latency reading for the Xilinx FPGA, while keeping the OrangeCrab in control of power management.
Anyway, fixing that cross-driving of the I2C bus has got the core running on the LCD, although the CPU is running off into la-la land somewhere, as we can see here. The timing closure is not nearly as bad as before, now that I have removed some non-essential components.
Nothing on the DVI/HDMI output at the moment, though, even though I have turned on the 5V power rail.
I'll check if there are signals on the differential pairs.
Looking into the boot loop problem, this is actually due to the target setup stuff in the hypervisor not yet knowing about the MEGAphone R4 PCB: It is trying to setup MEGAphone R1 I2C registers:
megaphone_i2c_setup:
;; Start with backscreen very dim, to avoid inrush current
;; causing FGPA power rail to sag.
lda #$01
sta $d6f0
lda #$00
sta $d020
ldy #$00
mps_loop:
lda megaphone_i2c_settings,y
cmp #$ff
bne +
ldz #$00
;; Set full brightness on LCD on exit
lda #$ff
sta $d6f0
rts
+
taz
iny
lda megaphone_i2c_settings,y
iny
;; Keep writing it until it gets written
-
sta [<zptempv32],z
;; Wait for I2C register to get written
inc $d020
cmp [<zptempv32],z
bne -
jmp mps_loop
The highlighted routine is where it is getting stuck. This is very encouraging, as it means it will likely boot if I fix the target detection/triage routine.
We really should have some conditional compilation for this stuff, so that only the code relevant for the target being built is included, thus saving a bit of space. But its not desperate, so it can wait.
Now, back to that lack of digital video output...
I can see the 27MHz pixel clock, but the 3 data channels look to be carrying rubbish, or more the point, carrying repetitve nothingness. Looking through the VHDL, I can see that the hdmi_dataenable line was not connected, which explains why the interface was basically idling.
So, time for another 2 hour synthesis run. Bed time for me in the meantime. If I have time first thing in the morning before work, I'll give it a look.
I woke up in the middle of the night, so I figured I would try the bitstream, and it now progresses past the I2C check, and the DVI output is working again. Things are generally progressing much further, but we still are not booting the whole way. I can now just use the m65 tool to get a screen capture (my phone is on charge, so I can't take a picture of the screens just yet):
... and success! The MEGA65 core starts, and drops us nicely into the OpenSource OpenROM BASIC for the MEGA65, because I don't have an SD card inserted:
I can even load and run something:
So at this point, I think we have core bring up done, and we can say that we have completed the final milestone of the NLnet Foundation supported project to make the MEGA65, as summarised below. But this is of course not the end of the project -- rather it is a key turning point enabled by NLnet Foundation's generous support. Next steps will include making more units with the PCB erata fixed, and which should be able to capable to operate as stand-alone devices. We have parts to build up 3 of those right now, at least one of which I will make available to a volunteer developer to help work on the telephony and state management software.
But right now, let's revist what the requirements of the last milestone for the NLnet Foundation were. As you read the text below, you will see a carry-over from the fact that this project was established at the start of the COVID-19 pandemic, and there was an alternative path allowed, that focussed on using ultrasound for sharing contact tracing information, instead of using Bluetooth as was being proposed more generally at the time. I investigated that, and found while it could be a good non-RF data channel, it wasn't any good at useful distances. For MEGA65 fans, this is also how the MEGA65 got Amiga-like DMA audio support, because I needed it for that task.
But back to this final milestone, here it is, with the path we have taken and tasks achieved highlighted:
5. Either Fabricate prototype MEGAphone r3 device or Implement Proof-of-Concept Near Ultrasound Communications protocol
This is the second 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, and we have been able to propose a feasible near ultrasound communications protocol, then it is anticipated that the near ultrasound pathway will be pursued, and that otherwise the fabrication of one or more hardware revision 3 MEGAphone prototypes will be fabricated.
Milestone(s)
This milestone shall be considered complete as soon as any of the two following options are complete.
---Fabricate MEGAphone r3 prototype---
Submit PCB design for fabrication through PCBWay or a similar service, and respond to any errata that they identify.
Purchase the hardware Bill of Materials required for assembly.
Assemble the PCB, including all soldering of components.
Attempt initial hardware bring-up.
Identify and document any errata that occurs in the course of this sub-task.
The milestone shall be considered complete when the five preceding dotpoints have been completed and their results communicated via the MEGA65 blog (https://c65gs.blogspot.com.au), specifically documenting the assembly and initial testing and collection of errata of the revision 3 device.
---Implement Proof-of-Concept Near Ultrasound Communications protocol---
Select one of the proposed near ultrasound communications protocols from sub-task 4.
Create a software design for its implementation on the existing MEGAphone hardware prototypes.
Create a proof-of-concept implementation based on this design, accepting that the design may need to be revised based on the experience of attempting to do this. This is particularly true considering the reduced complexity of the MEGAphone platform, and what can be achieved in low-power and small-area. Such refinements are wholly applicable to any COVID19 contact tracing application, where similar power, size and cost factors will be paramount.
It is accepted that this sub-task may deliver a negative result.
The milestone shall be considered complete when near ultrasound communications has been achieved between two MEGAphone prototypes or hardware analogs, and this has been communicated via the MEGA65 blog (https://c65gs.blogspot.com.au), specifically documenting the location of the source code, and summarising the obtained performance, any significant challenges encountered, and how these might be overcome and/or performance improved.
In short, we have sent off the revised PCB design for fabrication by PCBWay, bought the components and built up a prototype, and tested that it works, noting all resulting erata. Doing this while changing day-job, and even more so, during COVID-19 and the associated supply chain distruptions has been much slower and harder than anticipated, and thus why this final milestone has taken until now. But we have finally achieved it!
I am very much looking forward to continuing development of this device, to create something that is both fun, and also a fully "self ownable" communications device.
