|
My CID-PC project is a telephone project based around a PC using a US Robotics Sportster Voice modem, the USR5695. At this point it is really only a very elaborate caller ID box, with some advanced features. It logs all the information from both incoming and outgoing calls. For incoming calls this includes the calling number, the called number (I have a few distinctive ring numbers), time & date of call, number of rings, duration of the call, and any DTMF tones detected during the call. For outgoing calls this includes the dialed number, time & date of call, duration of the call, and any DTMF tones detected during the call. I can instantly (well, almost) sort all of my phone records based on any of the saved information, as well as display the data in a variety of ways.
|
I have done some initial work to implement the next phase, the actual answering machine part, but have not yet completed that. Though I have both recorded and played audio via the voice modem, there is still a lot of work to do before I have that working.
When I first conceived of this project I figured I'd want it in my basement. The extra PC wouldn't take up space in my work room, and I wouldn't be bothered by the extra noise of the fans in the PC (I hate that). I knew if I put it in the basement it would become home to all sorts of bugs that wanted a slightly warmer home. So, I built a wood and screen enclosure to keep everything in. Yes, that was a hell of a lot of work to do. I built it in the basement and ... almost made it too big to be taken up the stairs. I ran some cable from my second floor work room, up into the attic, across the attic, then down to the basement alongside the heating ducts. I then interfaced to the PC in the basement with Windows peer-to-peer networking and VNC Viewer.
This project was never meant to be a "stand alone" project, rather part of a much more elaborate home automation system. Some of the features I hope to implement are ...
- remote control of appliances (IE: calling home from work and instructing the DVD recorder to record the nightly news),
- control over how the phone ringer would work (IE: having a light flash if a call were received after 11pm, except if the called ID information indicated it were a family member, etc),
- unique outgoing messages based on the calling party,
- message forwarding (IE: having the system call my work number and play a message if a call was received from a particular party),
- display of the caller ID information on my television.
|
One of the great benefits of going to a telephone system based around a PC, was my ability to write the software in C, and create a Windows application to control everything. I wrote the Windows software portion of this project using Borland's C++ Builder. I still used a 8051 variant, the Atmel AT89S8252, to control some things that for whatever reason I did not want to do via the modem. These included the generation and detection of DTMF tones, and generation of an 'off hook' signal that controlled the state machine within the software. It also gave me an excuse to go ahead and start yet another microcontroller project. That's always a good thing.
This 8051 project would be a little different though in the fact that I wanted to be able to remotely download code to it. All of the 8252 projects I have ever done used the in-circuit programming feature of the processor. I used the extra lines of a PC's serial port to drive the SPI port and program the device. A limitation of this, due to the limited number of signals available, was that to initiate the programming processes, I first had to flip a switch to hold the processor in a reset state. This sort of made remote programming difficult. I didn't exactly want to run down to the basement to flip the switch every time I came out with a new version of software.
So, I devised a scheme where everything would still be done over an RS232 serial connection. I designed a circuit that used a smaller Atmel 8051 family part, the AT89C2051. It's serial lines were in parallel with the serial lines of the larger 8252. When the 2051 received a unique string, it would drive a transistor which then put the 8252 into the reset state. The 2051 would then receive the new program, over the serial lines, and use its programmable IO lines to drive the SPI lines of the 8252. This allowed me to do my remote programming as I wished, and provided much more accurate timing of the signals to the 8252's SPI port. I also added code to the 2051 to verify the checksum of the downloaded program. Using a 20 pin microcontroller to do all this was a little bit of overkill, but I could have reduced the circuitry by sharing the oscillator between the two CPUs.
After I came up with this little design I thought up another project I wanted to try. Not because I really needed it for anything, but because it would have been interesting and forced me to be somewhat creative to accomplish. I wanted to design a little module that would be a pin for pin replacement to the 8252, but provide the totally hands free remote programming capability I had created.
I would use a small surface mount circuit board, and a surface mount 2051 (or similar microcontroller). I'd put the small CPU and support ICs underneath a socket that would accept the 8252. The pins for the 8252 would extend through the surface mount PCB and solder into a regular socket that I could plug into any of my other 8252 projects. If I did things right, it would be the exact same footprint, only about a half inch taller then the 8252 alone. It actually would have required a few concessions though and would not have been quite pin for pin compatible with the 8252 by itself. I never did build this project, but had I done so, it might have been something like one of these modules (only a bit smaller).
