While I've been focusing on the software and case of late, work has been continuing on the hardware modules as well, as you can see below:
This post is really to give an check-in on everything that has got us to that point, and show the progress against the milestones -- and focusing just on the milestones.
k.2.2.4 Low-energy power-management module to minimise energy consumption of device, especially in low-power modes: PCB Fabrication
l.2.2.5 Low-energy power-management module to minimise energy consumption of device, especially in low-power modes: Assembly
m.2.2.6 Low-energy power-management module to minimise energy consumption of device, especially in low-power modes: Testing
n.2.2.7 Low-energy power-management module to minimise energy consumption of device, especially in low-power modes: Revision
All that's left is to confirm that the carrier PCB functions correctly once assembled. Here it is assembled:
And... it doesn't work.
After a pile of testing to figure out how a module that is mostly just 1:1 pin connections could be wrong, I discovered that I had wired one of the ports backwards. This means that pins A3 and B3 that are the USB UART are tied to 3.3V and GND, respectively. Not conducive for a working UART.
s.2.3.5 Battery management and energy harvesting module to allow USB-C, intergrated solar panel and external 12/24V vehicle battery power sources, and efficient management of the integrated rechargeable battery: Assembly
t.2.3.6 Battery management and energy harvesting module to allow
USB-C, intergrated solar panel and external 12/24V vehicle battery power
sources, and efficient management of the integrated rechargeable
battery: Testing
This one is also fairly simple to report on, but with less positive news.
We've assembled the module, but despite considerable testing and attempts at finding the problems with it, it refuses to work. This module was based on an existing open-source design, hence the "module in module" appearance. We've now come to the conclusion that we will need to completely redesign this from scratch using the datasheets, so milestone u.2.3.7 is not yet achieved.
aj. 2.6.2 External speaker and bluetooth headset interface module: Schematic
ak. 2.6.3 External speaker and bluetooth headset interface module: PCB layout
al. 2.6.4 External speaker and bluetooth headset interface module: PCB fabrication
am. 2.6.5 External speaker and bluetooth headset interface module: Assembly
at. 2.7.4 Primary FPGA carrier module, leveraging off-the-shelf FPGA modules if at all possible: PCB Fabrication
au. 2.7.5 Primary FPGA carrier module, leveraging off-the-shelf FPGA modules if at all possible: Assembly
av. 2.7.6 Primary FPGA carrier module, leveraging off-the-shelf FPGA modules if at all possible: Testing
aw. 2.7.7 Primary FPGA carrier module, leveraging off-the-shelf FPGA modules if at all possible: Revision
This module has been assembled and confirmed to work. Again, it's a fairly simple pin-mapping module. Schematic and PCB layouts in github at: https://github.com/gardners/mega65-megaphone-hardware-modules/tree/main/modules/te0725-carrier
ay 2.8.2 LCD panel interface module: Schematic
az 2.8.3 LCD panel interface module: PCB Layout
ba 2.8.4 LCD panel interface module: PCB Fabrication
bf. 2.9.2 Auxiliary communications module, e.g., LoRa, ultra-sonic, infra-red or mm wave: Schematic
bg. 2.9.3 Auxiliary communications module, e.g., LoRa, ultra-sonic, infra-red or mm wave: PCB Layout
bh. 2.9.4 Auxiliary communications module, e.g., LoRa, ultra-sonic, infra-red or mm wave: PCB Fabrication
bi. 2.9.5 Auxiliary communications module, e.g., LoRa, ultra-sonic, infra-red or mm wave: Assembly
bj. 2.9.6 Auxiliary communications module, e.g., LoRa, ultra-sonic, infra-red or mm wave: Testing
bk. 2.9.7 Auxiliary communications module, e.g., LoRa, ultra-sonic, infra-red or mm wave: Revision
This is another of the simpler modules, with just direct pin-to-pin mapping. The image below shows it assembled into the main carrier board. Testing was performed by ensuring that the pin mappings are all valid. Schematics and PCB layout as usual in gitlab at: https://github.com/gardners/mega65-megaphone-hardware-modules/tree/main/modules/lora
bm. 2.10.2 Main carrier board and assembly, into which the various modules connect: Schematic
bn. 2.10.2 Main carrier board and assembly, into which the various modules connect: PCB Layout
bo. 2.10.2 Main carrier board and assembly, into which the various modules connect: PCB Fabrication
bp. 2.10.2 Main carrier board and assembly, into which the various modules connect: Assembly
Here we again have mixed news: The carrier board has been assembled, but it's clear that we need substantial revisions on this, in part due to having placed some module recepticles up-side-down. We will need to work out a way to make that harder to do by mistake when designing with this modular system. Schematic and PCB layout on github as usual: https://github.com/gardners/mega65-megaphone-hardware-modules/tree/main/modules/main-carrier
Okay, so I have SMS working already, and a nice library to let me send and receive them, complete with emojis and international characters etc. But what I don't yet have is the voice call control working in the same way. The reason being that the EC25 module I have, while supporting 4G, lacks VoLTE support for the Optus Network in Australia.
I've poked the support at Quectel who make the modem, and I have a new firmware build for the modem from them which apparently supports VoLTE. So let's try that.
Except to do that we have to get the modem into Emergency Download Mode (EDL).
I tried tying the BOOT pin to GND (=normal boot) or to 1.8V. Tying it to 1.8V gets some other situation, but I don't know if it's actually EDL mode. At least QFirehose still fails to talk to it.
So it turns out you can't do it over the UART pins -- it has to be via the micro USB port on the evaluation board.
With that, it was easy to do the firmware update. So now let's try to enable VoLTE.
So, the firmware still lacks an Optus VoLTE profile -- but it does have a Telstra one.
After some poke and fiddle, I now have the modem such that it will receive phone calls, but trying to make one still results in NO CARRIER. This could be because of differences in the VoLTE profiles between Optus and Telstra, but it still strikes me as odd.
To get it to this state I had to use:
at+qmbncfg="AutoSel",0
at+qmbncfg="Select","Telstra-Commercial_VoLTE"
at+CFUN=1,1
<wait for the modem to reboot>
Then check that this command:
at+qcfg="ims"
Returns +QCFG: "ims",1,1 instead of +QCFG: "ims",1,0.
So there probably isn't any change to the MEGAphone software required for this -- it's just a once-off modem setup. We could make a MEGA65 native utility to set this all up, though. And perhaps we should use at+qcfg="ims" periodically to get the 3G/4G/VoLTE status and show that on the status bar, so that if this is a problem for others, they can at least see what's going on.
Okay, so the solution to that is to put a ; at end of the dial command to tell the Quectel modem that we want a voice call, not a data call.
So I now have working in-bound and out-bound calls :)
Requirements Specification
So I can finally get back to implementing our call state management library that will meet the following requirements:
1. Provide a mechanism to dial a number to establish a call.
2. Monitor the modem through +QIND status messages to tell the software what call state we are in.
3. Provide a function to accept a call.
4. Provide a function to hang up or reject a call.
5. Not allow the establishing of a second call while one is already in progress.
6. Periodically issue AT+qcfg="ims" and report current VoLTE status.
7. Provide a function to query the current microphone and speaker gain for the handset.
8. Provide a function to set the microphone gain.
9. Provide a function to set the speaker gain.
10. Provide a function to set the side-tone (i.e., "fold back from microphone into headset so you have a sense of being heard by the phone" gain)
11. Provide a function to mute a call.
12. Provide a function to unmute a call.
It probably makes sense to expand the existing modem library I've made to include those functions, rather than split the library, when both need to be parsing modem responses etc.
So let's start with the functions to establish, accept and end calls, since they're nice and easy. As are the mute, unmute and the various set gain functions. That gets us 1,3-4,7-11. We'll tackle the remaining ones in turn, starting with parsing for +QIND and other relevant messages.
We need to parse for +QIND messages that indicate call state, as well as +QCFG messages that tell us our VoLTE status. The place for this to happen is in modem_parse_line() where we already look for ERROR, OK and +CMGL.
+QIND: "ccinfo",4,1,4,0,0,"+61870106565",128 ata OK
+QIND: "ccinfo",4,1,0,0,0,"+61870106565",128 ath0 OK
+QIND: "ccinfo",4,1,-1,0,0,"+61870106565",128
and
atdt+61870106565; OK
+QIND: "ccinfo",3,0,3,0,0,"61870106565",129
+QIND: "ccinfo",3,0,0,0,0,"61870106565",129
+QIND: "ccinfo",3,0,-1,0,0,"61870106565",129
NO CARRIER
The meanings of those fields are documented with the AT+CLCC command, e.g., here.
But the run-down of the fields in order is:
ID : Internal call number, e.g., for using with AT commands for handling conference calls etc.
DIR : 0 = call from the phone, 1 = call to the phone.
STATE : 0= active, 1= held, 2=dialing (outbound calls), 3=alerting (inbound calls), 4=ringing (inbound calls), 5=waiting (inbound call). There is also the undocumented value "-1", which means "call just ended" as far as I can tell.
MODE: 0=voice, 1=data, 2=fax
MPTY: 0=not part of a multi-party/conference call, 1= it is part of one
NUMBER: The phone number
TYPE: Type of phone number: 129 = unknown type, 145 = international number (beginning with +), 161= national number. Looks like 129 is international number without the +.
ALPHA: Text of contact name if the number matches an entry in the phone's internal contact list (which we're not using).
So the DIR and STATE numbers are important for us to determine the actual call-state of the phone, and NUMBER and TYPE for getting the phone number of inbound calls. The rest is probably not that relevant for us.
Okay, I have the call state parsing working. The modem by default doesn't play a "calling tone" when you dial, nor when the call is being connected. The EC25 has support for playing a single tone, and I may eventually use that to send pulses of tone to indicate ringing. But for now, I'm using a much more fun feature of the modem: It has a built-in text-to-speech reader!
So now when you dial, it literally says "dialing" in your ear. And then it says "ring ring" when the far end starts ringing.
Ironically on the real MEGA65 hardware it will be easier to put timed tone work in here, case we have the video frame counter to keep time, but in the standalone Linux test program, that's obviously not available.
I've also put in some code to make sure that a previous command finishes before we send the next command to the modem, so that no commands get lost, and generally fixed a number of call handling bugs.
But I can now establish and hang up a call.
So now to implement waiting for an incoming call -- which was super simple.
That just leaves checking the VoLTE state periodically. The easiest way I can think to do that, is to do a randomised check when modem_poll() is being called, but no command response is pending, and with some low probability query the VoLTE status, so that it happens often enough.
For now, I'll just implement a modem_query_volte() command. This will work asynchronously -- i.e., you will have to call modem_poll() and then it will parse the response whenever it comes and update the shared.volte_enabled variable.
The question is how to demonstrate this? I'd go for a video, but the only practical ways I can show it working will need to show my phone number. So let's instead take a look at the API, some of which will be familiar from the SMS API post:
char modem_init(void);
Initialise the modem for operation.
char modem_poll(void);
Poll the modem for any responses, or to get a line of input from the modem for custom processing.
void modem_parse_line(void);
Automatically called by modem_poll() to process a line from the modem, e.g., a +QIND line.
char modem_place_call(void);
Establish a call, and set the call state accordingly to the CALLSTATE_CALLING state.
void modem_answer_call(void);
Answer an in-coming call and set the call state to CALLSTATE_CONNECTED.
void modem_hangup_call(void);
Terminate (or reject) a call and set the call state to CALLSTATE_DISCONNECTED. Also cancels the mute state.
void modem_mute_call(void);
Mute the audio channel in a call.
void modem_unmute_call(void);
Cancel the muting of the audio channel in a call.
void modem_toggle_mute(void);
Toggle the mute status of a call (convenient for just having a MUTE button that toggles).
char modem_set_mic_gain(uint8_t gain);
Set the microphone gain: 0 - 255, 255 = loudest.
char modem_set_headset_gain(uint8_t gain);
Set the headset gain: 0 - 255, 255 = loudest.
char modem_set_sidetone_gain(uint8_t gain);
Set the side-tone (microphone to speaker "comfort" loop) gain: 0 - 255, 255 = loudest.
void modem_query_volte(void);
Check whether the modem's cellular connection supports VoLTE.
void modem_query_network(void);
Request that the modem provide the name of the cellular network we are connected to.
Okay, so that's the API described. This lets us do things like this:
$ bin/modem /dev/ttyUSB1 115200 init sidetone=50 headset=100 mic=100 network volte callrx make: 'bin/modem' is up to date. INFO: Setting side-tone level to '50' INFO: Setting headset level to '100' INFO: Network name is 'YES OPTUS'. INFO: VoLTE is enabled.
Then it will sit there until a call is incoming, because I asked it to wait for a call with callrx. Then when that call comes we get something like this:
Answer incoming call from '<number redacted>' INFO: Notifying user of changed call state.
Okay, so that more or less confirms that.
And here's a short video showing it in action, with numbers redacted via a bit of shell-scripting magic:
For the current MEGAphone prototyping, I am using the MEGA65 R3 mainboards. The R3 specifically has on-board speaker drivers that I'm going to use for the ringer. Those drivers do have a bit of a heat-generating issue with some speakers because the audio is not filtered from digital before it hits them, but for ring indication purposes they should be just fine.
Anyway, whichever main board revision I use, I need to set it up with two UARTs: One to the cellular modem, and the other to the power control FPGA board.
I'd like to do that in a way that's compatible with the MEGA65 expansion board configuration, which means I can only put one of those UARTs on the PMODs: The one that would otherwise go to an ESP32 WiFi module -- or now, to a cellular modem.
But first, a sneak-peak of where I get to:
Looking at the board layout, there are three likely places I can find the extra 2 GPIOs I need: The keyboard connector, J17 or J21.
J21 has a bunch of GPIOs that are connected to the MAX10 FPGA that's on the R3 boards but not on the R6 boards. So I could use them, but to do that I have to reflash the MAX10, which is just a bit fiddly -- but doable.
J17 is the JTAG connector for the MAX10 FPGA, so similar issues there, except that it's harder to override the use of the JTAG pins.
The keyboard connector has the JTAG interface to the keyboard's FPGA (yes, everything on the MEGA65 is handled by an FPGA of some sort -- but I promise, there's only these 3 ;) But it also has 3 GPIOs for talking directly to the keyboard, and the JTAG pins on it are switchable via a JTAG enable line. But those pins also route through the MAX10 FPGA.
So it looks like I'll have to use the MAX10 FPGA one way or another. Well, except that for the R3 board, we already have the MAX10 relay those JTAG pins.
Okay, so here's my solution, which is only _mildly_ horrid: We make a funky keyboard cable that splits off the "JTAG" pins to the UART, and keeps the keyboard protocol pins going to the keyboard.
Importantly, this trick can also work on the MEGA65 R6, where the MAX10 is absent. So that gives me a board revision independent solution, where the only difference is what drives the ringer / internal speaker.
Okay, sounds like a plan.
So I just need to hook up the two UARTs to the MEGA65's buffered UART (I'll do it for R3 -- R6 targets) in a way that's compatible with the expansion board pinout for the UART on the PMOD. Should be super simple.
Let's see if I have it right on the first commit for any or all of the R3-R6 targets.
Now to do this, I'm going to need to go and get some wire and crimpers to make the cables (and also some of the other internal cables in the brief-case MEGAphone prototype). So a trip to Jaycar is in order.
Well, one typo on all targets. R3 builds now. R4 was broken, but for some other reason. Fixed that, and it's synthesising now. R5 and R6 are effectively the same target, so I'll just build R6. It's building fine, so I'll go and do a couple of things in the meantime.
Okay, one pin placement error for R5/R6 -- fixing that one, too.
While that runs, I might go and get the bits and pieces I need to more easily make the cables I'll need for this and for generally assembling the MEGAphone prototype with full wiring.
I was hoping to get loose dupont connectors and crimpy bits, so that I could just make up cables of the right lengths. But Jaycar only sells the pre-made 15 or 20cm long cables. So I'll have to cut them, solder in extensions and heat shrink them. It's just extra annoying work. But it will be manageable. I should also solder on the headers to the power management FPGA board that I've been studiously dodging by shoving male dupont connectors through the PCB holes and only having them fall out from time to time.
Let's start by looking at the keyboard connector and work out what needs to go where, and then I can pull out the soldering iron.
So we need 3.3V, GND and K_IO1 -- K_IO3 for the keyboard, so that's pins 1-2 and 8-10 that have to pass through to the keyboard. For the UART we need only pins 6 and 7.
So I've mode my extension cable for the keyboard, and now also soldered in extensions to 8 dupont 0.1" header leads. I'm still a bit annoyed that Jaycar doesn't have the raw parts for those, as it took an hour just to make those. But such is life.
Now in theory I have a MEGA65 bitstream that has the two UARTs plumbed to the PMOD and keyboard JTAG pins. The next step is to test them and that the buffered UARTs are working as I expect. I'll need a simple API for managing the buffered UARTs, so let's start with that, and then make a simple "MEGAcom" program that can work with them. I'll loosely base it on minicom.
The API for our purposes just needs these functions:
Okay, got those implemented. Now to work on the simple terminal program. I've hacked up a simple 80x50 text mode driver and some routines to draw boxes and make some simple menus. The actual serial port control code isn't in there yet, but it should be trivial to plumb it in. As described above, I've gone for making the structure mirror minicom so that muscle memory Just Works :tm:
Not bad looking, if I say so myself :)
Okay, so now I've got the serial port control in place, and with a bit of fiddling, I can even send data to a connected UART. Yay!
But for some reason nothing is being received. And that remains the case when I enable the UART loopback mode, which should cause local echoing of bytes I send... Ah, except that loopback mode is funny -- it connects the buffered UARTs to each other.
Anyway, once I had realised that, I can see that there seems to be something coming in. So it's possible that I have the plumbing for the UARTs wrong on the PMOD. Let's try the keyboard connector.
Hmm.. No sign of life on there yet. But it's the middle of the night, and I need some sleep. But it feels like it should be fairly easy going from here to make it work now.
Well, I stayed up some more, and got the MEGAcom working a bit more :)
Anyway, this all proves that the UART on the keyboard connector is working fine. It's just the PMOD one that's not receiving -- which I suspect is because the pin is set to inout, but hasn't been tristated. I'll resynthesise a bitstream with a fix for that while I get some more sleep.
Okay -- found the problem, I think I had the TX line on the wrong PMOD line -- anyway, with that it works now. So that means we know we have two working UARTs available for connecting the cellular modem and power control FPGA module :)
But after being up most of the night working on this, I need a snooze before I tackle the next part, which will be hooking those things all up, and documenting the pin connections on the various connectors to do so.
To summarise what we need for connections:
1. Cellular modem RX from UART0 (Left PMOD on MEGA65, bottom row, 2nd pin from the right) (purple/yellow wire in the photos below).
2. Cellular modem TX to Power Management FPGA pin E3 (short blue lead in the photos below).
3. Cellular modem TX relay from Power Management FPGA pin E1 to UART0 (Left PMOD on MEGA65, bottom row, 3rd pin from the right) (white wire in the photos below).
4. Power Management FPGA UART pins B3 (long blue wire in the photos below) and A3 (green in the photos below) to UART1 on MEGA65 keyboard cable pins 7 (second pin from left on rear row, when looking from front of the MEGA65 towards the back) and 8 (third pin from the left on the front row, when looking from front of the MEGA65 towards the back).
5. GND from MEGA65 PMOD (second pin from left, either top or bottom, either PMOD) to cellular modem (black wire in the photos below).
6. GND from MEGA65 PMOD (second pin from left, either top or bottom, either PMOD) to Power Management FPGA (brown wire in the photos below).
7. (In the phone, but not on my test unit) 3.3V from somewhere to the Power Management FPGA.
I've started with the cellular modem. And I think the connection is there, but I'm reading gibberish back from the modem, even though I'm set to 115,200bps as is correct.
Okay, so I did an experiment: I can talk to the cellular modem just fine, e.g., by telling it to dial my mobile phone. But the output from the modem is all messed up.
So what's really weird, is that echoing commands as I type them comes back ok. It's just when there's back-to-back character output that it's a problem, I think... And now it's suddenly completely fine (!!):
Was it just a bad connection?
Hmm.. Something more is going on here, as it's varying as to how good/messed up it is.
Slight baud rate mis-match, perhaps?
We use 40.5MHz/X to get baud rate. 40.5M / 115200 = 351.56, so it's possible that by rounding that down to 351 we're slightly too fast, and as a result pick up the end of the stop bit as the start bit of the next byte, which would explain the behaviour.
Well, except now it's all gone to gibberish again -- even command echo is messed up again. This happened after I moved some of the cables around. So maybe one of them has a bad connection, or a wonky solder joint?
And then without the ATI command echoing properly I just got one perfect ATI response !?
So I'm having a poke at the power management FPGA UART connection now. That seems to be rock solid. I can send the ? command repeatedly and get a solid slab of sensible looking text back, wit no apparent errors.
Switching the cables around, the problem follows the cellular modem, not the cables. So I think it's something specific there.
What I am going to try now is to hook up the UART relay from the cellular modem to the power management FPGA: It's possible that the drivers on the UART TX line of the cellular modem are a bit weak or off spec or something, so having the signal regenerated in the power management FPGA might just solve the problem.
Yup -- it's rock-solid when it goes through the little Lattice FPGA.
So let's have some images to help guide the wiring.
In the first two images we can see the keyboard cable made from dupont connectors, with two removed to let me sneak the UART connections in (the blue and green wires that don't follow the rest of the cable up):
(Note that the MEGA65 has an unsoldered second keyboard connector that could in theory be leveraged to allow use of the normal MEGA65 keyboard cable, assuming the JTAG lines don't mind actually still being connected to the keyboard's Lattice FPGA. As I've reasoned above, I believe that this should be fine, but don't go trying it until I confirm it's safe. (Of course, if you're using a DIY "MK-II" MEGA65 keyboard, that doesn't have JTAG at all, so would absolutely be safe. But unless you're one of the two people who've made one, you don't have a MK-II keyboard -- all retail MEGA65s come with the "MK-I" FPGA-based keyboard).
Don't forget that the purple wire in the bottom of the next image turns yellow in the middle! The yellow wire you can see in the top-left of the image is a red-herring -- just ignore it:
The blue lead in the following image is the short one to the power management FPGA board:
Note in the following photo, the long blue wire to the MEGA65 keyboard connector is the one next to the green, while the short blue wire to the cellular modem is the one on the right next to the white wire.
Okay, so in theory we have the connections we need, and we have the UART communications library all ready, so there doesn't feel like any reason why we can't just plumb it all together, and get the phone software talking with the cellular modem, and, say, show the VoLTE and mobile carrier name in the status bar.
Except... it looks like the weird UART gibberish problem from the cellular modem is rearing it's ugly head again. I think I need to get to the bottom of that next. My spidey-senses still tell me that there's a timing issue in there somewhere, or at least de-bounce.
I think the first thing I should do is make the UART RX sample mid-bit, instead of at the start, as it strikes me that there can be all kinds of problems with the way I've been doing it to date... except it looks like I fixed that ages ago. So it's not that. And it's de-bounced. So I'm really not sure what's going on here. It's only on the RX side as far as I can tell: The modem hears our commands just fine.
Okay, so I think I might have gotten to the bottom of it: The EC25 Eval Board has an on-board level converter that lifts the 1.8V UART lines to 3.3V. But sometimes that level shifter is having problems. This explains why the serial output is sometimes fine, sometimes marginal and sometimes rubbish. Here's some oscilloscope captures the contrast. Contributing to my suspicions here, the UART also feeds two other level converters on the eval board: One for the USB UART interface and another for the DB9 RS232 port. So it's totally possible that 1.8V UART is sagging a bit sometimes, and the 3.3V level converter gets confused as to what it should be doing.
Anyway, let's look at how this looks in practice:
Here it is mostly fine, but showing slow rising edges. In this state we get some bit-flips from 1 to 0 (I was probing both sides of a 10W 47 Ohm resistor to see if that helped, but it didn't. And, yes, I know that 10W monster resistor will be somewhat inductive, but I saw the same problems without it, I just didn't take pictures):
But then when it goes truly awful it looks like this:
or this:
When it should be looking reliably like this:
So my thinking here is to add a 10K pull-up to 3.3V on this line, so that when the level converter is having a bad day, we still get a clean signal.
So time to make up a little jumper lead with 10K pull-up side-line. This needs to go on the cellular modem to power management FPGA leg, so that we relay the cleaned up signal to the MEGA65.
I've made the jumper up, and connected it, but with the 3.3K Ohm (I couldn't find my 10K resistors) pull-up not connected, and am now waiting for a bad phase with the UART -- which of course isn't happening now that I want it. So I'll get on with the integration, and then worry about it when it shows up again, and connect the pull-up to see if it fixes it.
Okay, so back in that world, I'm trying to debug why the phone software is only seeing empty lines from the modem, even though we're clearly receiving, for example, a RING message from the modem:
Note that the modem line is reported as empty ('') the second time, even though clearly we have seen the 52 49 4E 47 bytes = R I N G. So that's the place for me to start looking.
Well, for whatever reason, it looks like the shared.modem_line buffer ends up with all $00 bytes in it. So why? They don't get written into the array at all, it seems.
This is all a bit fishy. I've confirmed it's not the write-protection of memory (that triggers a backtrace when violated, anyway).
To make things fishier and more annoying, after receiving the 2nd line, it seems to ignore all serial input, but it hasn't crashed, per se, it continues to update the status bar.
Okay, weird, it looks like the shared.modem_line thing is at $D0C0... Maybe I've got >4KB in my shared state structure. That could certainly cause problems.
Okay, that's indeed the case: It's almost 5KB! But I can't quite see why.
Ah, the shared resource structures allow for a resource name that's 240 bytes long x 4 fonts, and we have almost 1KB.
I tried increasing the size for the shared memory region, but then FONESMS doesn't fit (there are only about 700 bytes free in BSS, and I need slightly more than that)!
Now, the nuisance is that once a shared resource has been loaded, we don't need the name field anymore, but the shared resource API keeps the whole record around. It's literally only needed during the shared resource find and open process.
Right, with that fixed, we now have lines being recorded and seen:
... Modem line: '+QIND: "ccinfo",4,1,-1,0,0,"XXXXXXXXX",128', line len = 0x2B, first bytes = 2B51494E ... Modem line: 'NO CARRIER', line len = 0x0A, first bytes = 4E4F2043
So that's all great. But I'm not seeing call state events be handled. But let's go back a step, and make sure that FONEINIT actually initialises the cellular modem. Yep, that all looks fine. So really what we need now is something to make the modem periodically report things of interest to us -- like network name, network time and signal strength.
Okay, so I have added an automatic polling function that sends the AT commands to the modem every second or so to get network time, the network name etc. The first of those I've plumbed in with a parser is the network name function... and tada! We can now see the true network name:
Well, I've hit another nuisance here as I implement the rest of the modem response scanning and status bar update stuff: I've run out of program size again in the SMS program. I'm tempted to just not build that for the moment, and finish getting the modem response stuff in. That way I'll know just how short I am of space, rather than playing whack-a-mole repeatedly.
Okay, so now I have the network time parsing done. Let's move onto the network signal level. Got that, and VoLTE indication. So now it's onto the call state management stuff.
I've now plumbed in RETURN to answer or hangup a call -- and that works -- I've now got it so that I can accept a phone call... And make calls. There's still a bunch of rough edges to sort out, but it basically works for phone calls now :)
Here you can see it in action, after I added some fixes for handling calls without caller ID:
But let's go over what getting us to being able to place and receive calls achieves in terms of milestones:
Milestone: j. 1.3 Telephony software: Basic Communications With Cellular Modem: Implementation
Demonstrated by the correct display of the cellular network name and time, among other things.
Milestone: k. 1.3 Telephony software: Basic Communications With Cellular Modem: Testing
Demonstrated by getting the display of the status bar information as well as the placing and receiving of call sequences (private video is available for NLnet Foundation for verifying this).
Milestone: l. 1.3 Telephony software: Basic Communications With Cellular Modem: Revision
Documented in this blog post and in the source code, as I've gotten everything working to this point.
Milestone: y. 1.7 Integration testing and remediation of software: Requirements Specification Milestone: z. 1.7 Integration testing and remediation of software: Implementation Milestone: aa. 1.7 Integration testing and remediation of software: Testing Milestone: ab. 1.7 Integration testing and remediation of software: Revision
These four milestones have been addressed in this blog post and in the source code, as I've gotten everything working together: The cellular modem interface software, the GUI, the call state management etc.
In recent blog posts I've got the telephony and text messaging software working. What isn't there yet, is making it all talk to the cellular modem -- so that's what we're going to finish here.
So let's start by getting some hardware organised that can talk to the cellular modem. We're prototyping using a real MEGA65 mainboard, so we need to tweak a build for that, which has two buffered UARTs exposed on the PMOD ports: One to talk to the low-power FPGA that manages sub-system power, and the other that talks to the UART of the cellular modem.
But even before we get to that point, we can get the communications with the cellular modem in hand, using a USB UART adaptor from Linux. So let's do that.
The key things we need to do are:
1. Setup basic modem operating parameters
2. Configure the modem to say RING when the phone rings.
3. Configure the modem to issue a +QIND message whenever an SMS message is received, or the call state changes, e.g., pick-up, hang-up, ringing etc.
4. Retrieve the first queued SMS message if there are SMS messages pending.
5. Send an SMS to an indicated number.
6. Retrieve network time, name and signal strength information.
Let's go through those one by one and implement them.
But first, let's get that modem plugged in and powered up, and confirm that we have the UART relay through the low-power FPGA working:
So what we have here is the cellular modem development board connected to the USB UART (that is pretending to be the MEGA65 right now), with the TX line from the cellular modem (green) relaying through the low-power FPGA (yellow) so that it can monitor messages from the modem to auto-wake the main FPGA when required. The TX line from the "MEGA65" goes direct to the RX line on the cellular modem's UART (blue). And apart from that, we have GND (orange).
And as we can see in the screenshot above, we can talk to the modem.
I've also bought and installed a pre-paid SIM card for testing, although it seems to be taking a while to activate, which is annoying, as I'd like to make a test call.
So we can start working on a simple library to do the things we need to do with the modem.
Hmm.. Turns out the firmware on this module needs updating to support VoLTE with Optus. But I can still work on the SMS processing commands in the meantime.
For that we have AT+CMGL=4 that will list all unread SMS messages, AT+GMD=n that will delete a specific message, as well as commands to read a specific message. What is lacking, but would have been nice, is a command that returns the _number_ of SMS messages. I can approximate it with a list, but that's a bit annoying.
Complicating matters is that saving an SMS message takes a second or two if we index it. So we'll still want to AT+CMGR to read a message when we want to store it.
So let's start by fleshing out modem_poll() so that it indicates if it has returned a line from the modem, and have it count the number of +CGML lines seen, and also if it's seen an OK or ERROR line, so that we know when it's done. That way a call to get the number of SMS messages yet to be processed can simply call modem_poll() until it sees an OK or ERROR message, or some sensible timeout occurs.
Got all that. Now getting ChatGPT to implement a small SMS PDU decoder. This turns out to be more complicated than I'd like, but not absurdly so. Just pushing ChatGPT with each decoding error I see and getting it to fix them one by one. In theory I can now decode an SMS into a UTF8 string.
Okay, got that working. Now getting it to write me the opposite that can take a UTF8 string and prepare it for sending as one or more SMS messages. That seems to be okay, but now the actual sending the SMS is getting a +CMS ERROR: 304, which means the modem isn't in PDU mode -- but I have set it. So maybe it is botching the message construction after all.
The bug turned out to be my fault, not ChatGPT's: I was putting a CR/LF sequence after the PDU before sending CTRL-Z. With that fixed, and a few other minor things, I can now send short SMS, long SMS, SMS with emojis etc, and it all arrives correctly :)
There is an intermittent protocol lock-up that I'd like to get to the bottom of, but it fundamentally works :)
So SMS deletion is the next frontier, and one that should be super easy in comparison.
But before I can tackle that, I've hit a problem where if there are too many SMS messages, the AT+CGML=4 command seems to truncate output, and doesn't print OK at the end. So I've added a timeout to that.
With that fixed, the good news is that we can even delete SMS messages.
The bad news is that the message numbers don't pack or shuffle down after a lower number message has been deleted.
So we probably need a command that returns the oldest SMS message, including it's number, so that we can then ask for it to be deleted after.
In short, we can receive SMS messages in order, and then delete them.
So let's watch this all working together, sending and receiving SMS. I'm filming with my mobile phone, so I can't show them being received on my phone directly.
Milestone Checklist
So that completes the SMS part of our API, which satisfies these milestones:
q. 1.5 Text messaging software: Communications With Cellular Modem: Requirements Specifications
The requirements for this module ended up being able to be reduced to the very simple set of routine's we explored above: (1) Get number of unread SMS; (2) Read and SMS message; (3) Delete a received SMS message; and (4) Send an SMS.
We ended up going beyond this, by implementing some stretch goals, in particular: (5) Parse Unicode and Emoji-containing SMS; (6) Construct and send Unicode and Emoji-containing SMS; (7) Send multi-part SMS.
r. 1.5 Text messaging software: Communications With Cellular Modem: Implementation
The implementation is described and shown in the video above, as well as embodied in the source code, in particular in these files:
s. 1.5 Text messaging software: Communications With Cellular Modem: Testing t. 1.5 Text messaging software: Communications With Cellular Modem: Revision
The blog post text and video above shows the result of testing and iterative revision until a working module was obtained.
Okay, so now it's on to finishing the cellular modem telephony control module... If only Quectel had already responded with the firmware update I need for the modem for VoLTE on Australian networks...
This post is really just a summary of the work done for the telephony software user interface and SMS/Text messaging user interface. Various other posts describe the considerable work done to achieve this, and the requirements of the software.
This software is one area that I think is fair to say that I underestimated the work required. That said, the result is much better than I had originally anticipated -- we have a full anti-aliased proportional text rendering engine that can even display emoji and other arbitrary unicode characters, and with quite good performance -- no mean feat on a machine with 384KB RAM and a 40MHz 8-bit processor!
The architecture that it has ended up with for the software is quite sound, and fairly easy to extend now, with a very modular structure, which I exploit since a single ~50KB program file (the practical limit with the C64 memory layout and compiler tool-chain I'm using) can't fit everything. A 4KB shared state structure is passed between the sub-programs that are loaded practically instantly from the SD card.
Speaking of compilers, a fair bit of work went into switching from CC65 to MOS-LLVM to improve performance and code density, as well as getting LLVM's much better compiler warnings and errors.
The net result is something that looks quite credible and on a similar graphical standing to the Nokia S60-series of phones. Before we jump into the technicality of what's been done, and mapping that to the milestones for the NLnet grant that has so generously supported this work, let's have a look at some representative screen-shots and a short video that shows the user-interface in action.
Let's start with the status bar at the top of the display, where we have both network signal strength and battery charge information in the top-right. Both of these are already "live", and will reflect the real phone state once we hook the cellular modem in:
Then on the top-left we have the time and phone network information, again live and pending only the cellular modem integration to become fully active:
Between the two of these is space for message and other notifications.
So let's look now at the user-interface itself. Again we can see the use of the nice proportional text. I know I mentioned it before, but I'm still really quite pleased with the result -- remember this computer has so little RAM (intentionally), that a 720x400 pixel frame buffer with 8-bit colour depth would require 288KB, leaving very little RAM left for either code or data. So instead it is implemented using the VIC-IV's crazy text modes, which allow for variable width characters, hardware anti-aliasing and a variety of other subtle features that make this feat possible.
This is also why the display draws so quickly: The software doesn't have to render pixels -- it renders characters, and the anti-aliasing and other compositing effects are all done in hardware.
But back to the UI...
First up we have the default display of the phone, with dialpad on the left and contact list on the right. In terms of core telephony, this is the heart of what matters, so we've made it simple. The side-by-side layout means that you don't have to swap between the views endlessly. You can scroll up and down through the contacts, or add new contacts as needed.
By hitting F1, we can copy the phone number of a contact into the dial-pad, ready to dial:
Hit F1 a second time, and it will place the call. Now we see the dialer state change, with the call button changing from green to yellow that call is being established. The cross also goes to red to indicate that we can end the call by hitting that. Also I've hit the "mute button", causing that to go red.
Both the call-establishing and mute activated buttons blink, so that you have a visual indicator to remind you that they are active (see below). Again, the blinking is done in hardware, so the software doesn't have to do anything to maintain the display:
The other main part of the display -- and that can be used during a call as well as when the phone is idle -- is that contact list. Hitting F3 (or tapping on the contact -- I've been listing keyboard short-cuts for things above that I use for ease of development, but all of them map to the touch-interface as well) brings up the SMS thread for that contact, from where we can read and write SMS messages.
Being able to text back and forth while in a call is one of those things that I personally find quite useful, but is absurdly convoluted to do on most phones.
So that's a quick guide through the user-interface for telephony, contacts and text messages.
But let's now attend to the specific milestones associated with this work:
m. 1.4 Telephony software User-Interface: Requirements Specification
So let's look at the requirements for the telephony software:
1. Dialpad that allows dialing.
Visible in the demonstration video.
2. Contact list that allows storage of contacts, including creation and editing of contacts.
Visible in the demonstration video.
3. Ability to dial based on contacts, including showing the name of a contact.
5. Selecting a contact to view the SMS message thread for.
6. Implementation of call state management.
7. UI elements update according to call state.
8. Telephone battery status indication.
9. Cellular network status information.
n. 1.4 Telephony software User-Interface: Implementation o. 1.4 Telephony software User-Interface: Testing p. 1.4 Telephony software User-Interface: Revision
The evidence for these three milestones is presented in this post (implementation), and in previous posts where the software has been implemented, tested and revised to reach the point of demonstration in this blog post that satisfies the requirements of this component.
u. 1.6 Text Messaging Software: Requirements Specification
1. Ability to display SMS messages.
2. Ability to draft SMS messages.
3. Ability to request the sending of an SMS via the cellular network.
4. Logging of a sent SMS message.
5. Differentiation between received and sent SMS messages.
6. Scrolling through SMS messages.
In addition, we had stretch-goals of:
7. Supporting international characters in SMS messages.
8. Supporting emoji in SMS messages.
v. 1.6 Text Messaging Software: Implementation w. 1.6 Text Messaging Software: Testing x. 1.6 Text Messaging Software: Revision
The evidence for these three milestones is presented in this post (implementation), and
in previous posts where the software has been implemented, tested and
revised to reach the point of demonstration in this blog post that
satisfies the requirements of this component.
Okay, in the last post, I got the dialer and contacts screen and SMS thread handling etc, all largely in place and tied together.
We're on the home-stretch for the user-interface side of the telephony software, but there are a few things left to implement/do:
First up, we need to split the binary, as I keep hitting running out of RAM for the program in the bottom 64KB.
Second, I need to implement the ability to select a contact to call them, i.e., having it copy the name and number across to the dialpad side.
Third, I need to finish implementing the telephony state management, so that the phone knows when it should ring etc.
Fourth, we need a ring-tone of some sort, for testing at least. There's a whole can of worms as for how I want to manage that down the track, but for now, we'll just stick a SID file at $E000-$EFFF and do a bit of ROM banking.
So let's get started with binary splitting. I think I'm just going to use #defines to conditionally include the various functions, so that it's easier to share some of the stuff.
We do need a way to keep track of state between the various binaries. I'm thinking that I'll define a nice little structure that we can hard-code it's address to, say, $0200, and any state that needs to be shared can go down in there --- e.g., dialpad partially entered number, currently selected contact, telephone state etc. It shouldn't need to be very much.
I've created that in shstate.h, and made just dialer.c use it for it's shared state initially. But now the program crashes when I type digits into the dialer. So I must have stuffed something up. The structure is at 0x0200, and it's outputting asm that targets there. But the stacktrace is also a bit weird, making it hard to figure out the real cause.
Interestingly it is not the memory write-protection that's triggering it. Rather it thinks an NMI is being triggered. I was accidentally stomping on the $031x vectors, and I'd rather hoped that fixing that would solve the problem. But it hasn't.
The backtrace seems to show that the problem is happening in our __cyg_profile_func_enter() handler that does the backtrace storage. Or rather, it happens on the JSR to that routine -- which feels totally bonkers. The alleged BRK instruction is at some low ZP address, e.g., $0008, which suggests that it's jumping somewhere silly, or the NMI handler is being called some other way, and it just looks like it's happening there.
Nothing untoward seems to happen in the profile enter function, looking at the assembly language. Found it -- the KERNAL IRQ is doing C64 keyboard scanning type stuff, and didn't take kindly to me stomping all over $02xx. So now I've restricted myself to the tape buffer area at $33C - $3FB, and it's working better.
So let's continue with the splitting, then...
The obvious first line to split down, is between the contact list and the SMS thread screens. We just need to have the two binaries call each other when switching views.
Ideally, they shouldn't try to redraw the entire screen when switching, so we want to suppress the whole video setup stuff, which of course can just go in it's own separate binary that does that setup, then effectively throws away the code.
Ah, yes, and we need to unplug our IRQ and NMI catchers before switching binaries. We can do that with a JSR $FF8A. With that, and some general bug-fixery, we now have FONEINIT.PRG doing the screen setup and then launching FONEMAIN.PRG from the SD card :)
Now we just need to work out how we intend to split the programs. My current thinking is:
FONEINIT -- Screen initialisation etc
FONEMAIN -- Contact list display and telephony state management
FONESMS -- SMS thread display and editing and telephony statemanagement
FONESMSW -- SMS "write" (i.e., store SMS draft into the thread, update indexes etc, then return to FONESMS or whichever caller was indicated in the shared state area)
I'm sure there will be more than this needed, but that should get each small enough to leave for the telephony state management stuff to be included in each. There may yet need to be a "telephony event" program, but we'll tackle that when we get to it.
I have it somewhat working, but llvm-mos's C64 CRT0 bootstrap routine makes a call to $FFD2 to set lower-case mode. I have two choices: Find how to change the CRT0 routine, or just spoof the vector at $0326 that $FFD2 jumps through, so that it does nothing :)
That gets it a bit further, but it still bombs out, looking like it hits a BRK or NMI. So need to figure out what's causing that.
Putting a trap on $FE66, the default $0316 vector shows that it is being trapped. So apparently a BRK instruction. But weirdly, if I single-step, the problem never occurs -- it only happens when the CPU is free-running.
Well, it gets weirder. Today it's triggering a RUN/STOP-RESTORE type situation, but it doesn't hit $FE47, which is where the $0318 vector points.
I'm wondering if llvm binaries don't like being loaded the way I'm loading them. Or if BASIC or the KERNAL are winding up in some messed-up state.
There is still really something cooky going on, though, because what happens depends on whether the CPU is single-stepping or free-running. t1 and single stepping doesn't crash. tc with free-running single-stepping also doesn't crash. But t0 to set the CPU going loose totally does crash.
So now I'm putting infinite loops in the initial code in the binary so that I can catch where the crash happens.
Disabling IRQs in the helper loader seems to get it to go a lot further, which makes sense, since single-stepping generally disables IRQs.
With that, it looks like it actually loads the next program, but that then crashes with a report from our traceback code:
So it looks like it's not the program, but some interrupt that's happening. So what on earth could be enabling and NMI? Not many things in the MEGA65 can generate an NMI.
I've added a Makefile target that use mega65_ftp to push the updated files onto the SD card and then resets and runs FONEINIT.PRG, so that I have a simpler work-flow for tracking this down.
Let's find out if it's a BRK or an NMI that's triggering this for starters. Well, it turns out it was my memory write protection stuff, by the look of things. I have it setup to auto-protect the heap and RODATA of the LLVM compiled binaries -- which is ostensibly a good thing -- except when you switch binaries and the old write protect region is being used while the new binary is trying to set things up...
Okay, with that fixed, the binaries are being loaded now. But the display is being messed up a bit, specifically the status bar and the selected contact / dialed number bit above the dial-pad. It does look like the SMS display executable is being loaded, even though it should be staying in FONEMAIN which has the contact selection loop... Except that it seems that FONESMS is actually the one that actually has the contact list. So let's rename them, and make this all a bit more logical.
Done. Now, investigating the display glitches, this looks like the problem is that the glyph cache is not in the shared state area. The problem is that it's too big to fit in the cassette buffer where I have stashed it. The whole thing is 3KB. A nice solution would be to tell LLVM that it can't use $C000-$CFFF, and then I instantiate that whole area with my complete shared state structure. That just requires me to mess with the linker script thing.
So now we're kind of back to where we were before hit the program size issue. So let's not get it working so that we can select a phone number to dial from the contact list. We also want to be able to edit the dialing number field.
Done -- we can now press F1 to load a contact's number into the dialer field. Maybe I should make it so that if you press F1 a second time, it tries to commence the call. I can do this as part of the whole call state mangement, which it's high-time we implemented.
Let's work on a simple state diagram, so that we can make sure that this makes sense.
So we probably don't need IDLE. And DISCONNECTED becomes NUMBER_ENTRY whenever we modify the number to dial.
I've implemented some stub functions for the various modem functions (like call, answer, reject etc), and added a timer that we can use to timeout from attempting to make or receive a call, so that it then moves back to the DISCONNECTED state.
The dialpad buttons are supposed to change as well, when the call state changes, but that doesn't seem to be happening, at least when we request an outbound call. Okay, fixed that, and implemented F5 to toggle call mute, and F7 to end a call.
Well, I think that's everything except for a quick demo video!
Next stop is the power management stuff, and gettiing it to talk to the cellular modem.
