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.
