Home made cellphone project.
Yes master..
Waiting for your command, master.
All this talk about the GUI and the exiting things its up to, is the software equivalent of People Magazine. How about the guy on the other end of the communication line that’s actually doing all the work?
Remember, the Adafruit FeatherFONA is what started all this.
When you get a FeatherFONA, you can set it up anyway you like. Its a blank slate, so to speak. Adafruit supplies a nice demo program you can play with, along with a library of commands you can use to access the cellphone chip on the board.
This is especially nice because you can look at their code and see how they made it work. This is really handy for when you get stuck trying to make it work yourself. And BOY did I get stuck at times! I found the SIM800 user manual to be pretty tough to wrap my head around.
What to do? Writing the FONA code, I set up its sketch’s loop() function to watch for incoming messages from the GUI. Easy, because that’s what the quickCom library was designed to do.
The layout of the messages was setup so that the first byte of the message was the command byte. This byte tells the loop function what handler function will be able to deal with the message. The remainder of the message is passed off to the selected handler function to deal with.
The hander functions are the ones that “know” how to work the Adafruit library calls to do things. The hander functions are at the end of my domain. From there, the Adafruit library takes over and talks to the SIM800 chip and make it do things. That wasn’t really my problem.
Each level calls lower levels, receives replies and decides on what sort of reply to pass back up to whomever called on it.
And for a long time, this worked just tickety-boo. Until version 2 when things were getting more stable and I was able to start adding “features”.
Adding features is like icing on the cake. They are fun to write, and are so zippy! I’d decided to add caller ID. I mean, all phones have this now. It would be silly not to.
I couldn’t get it to work. Debugging stuff like this, three processors, piles of code, some mine and some theirs, I find to be really tough! Where was this breaking down? And, now that caller ID was activated, why was everything else acting crazy?
Turns out that, while “everyone” on the chain of command was behaving. IE : Not talking unless spoken to, etc. The lower level code, responsible for called ID information, just dumped it out on the stream whenever it felt like it. Bad Minion! Bad!
What a mess! The Adafruit code, that was using this data stream, dealt with the issue by first dumping the stream whenever it wanted to talk on it.
In the end, I had to “inherit” the Adafruit library and write a derived version. Actually, not an uncommon practice when you need different functionality. My version would, before sending a command, sweep its input stream and check what if found. If it was a caller ID, it would squirrel it away in a caller ID buffer, saving it until it was asked for.
The patch worked. No longer could anyone tell that caller IDs were being dumped higgledy-piggledy into the data stream. And, the handler for caller IDs only had to read them back out of a saved buffer when called. Easy peasy.
Struggles like these are common writing code. Especially coding for hardware. Much of the goodies supplied in hardware are never fully implemented. For example, cell phone chips have FM radios built into them. How many cellphones have you seen with the ability to play the radio?
This SIM800 has all sorts of sound capabilities. Well, at least the manual says so. But for the life of me, I was never able to get any of it to work.
