The messaging process starts with the web interface. The user inputs a message to be sent to one of the pagers, and the message is transferred via the Internet to the local web server, which in turn communicates via a serial port to the "local" station. This local station is an Atmel 8515 Chip connected to a transceiver. This transceiver sends messages to the remote transceiver on the pager at 433 Mhz, at which point the messages are parsed and outputted to the person carrying the pager via an LCD, with LED and buzzer notification.

Web Interface

The web interface is an html frontend with standard form submission process. There is some javascript embedded into the form to check that the text message is within a length limit we determined based on the LCD size.

Web server

The "Web server" we used for our system was comprised of an IBM Thinkpad 600E Laptop running Jakarta Tomcat Servlet Engine. Within our servlet program we where able to access the serial port using the Sun Java comm api. This interface was fairly easy to implement, allows us as programmers to do some fairly complex data manipulation while abstracting the technology itself from the end user. This setup also gives us a lot of expandability because we could have used Java servlets to send email or interface some software.

Local Station

The Local station is an Atmel Chip, which receives commands from the local server via an RS232 port, and uses the built-in hardware UART to receive these messages. The UART is interrupt driven, and stores characters received from the PC in a buffer, after which they are parsed and sent to the remote station. The local station is also responsible for synchronizing the remote transceiver by padding messages with pulse trains.

The Wireless Connection (w/ Software UART)

The connection, as stated previously, is made via two transceivers transmitting at 433 Mhz. They are hardwired such that one is a transceiver, and one is a receiver, however, software control to reverse these functions is possible, and is discussed in our Extra/Potential Features section. The connection is made via a software UART, which took over a week to perfect. We based are design on Atmel Application Note AVR305. It sends messages on the local station via Pin D4, which are in turn received by the remote station via its hardware UART. The messages that are sent to the remote station are padded with 0x55's, since 0x55 in binary is a pulse train, which is necessary to synchronize the oscillator of the remote transceiver. Once messages are received, they are parsed based on some strict rules, to eliminate characters received randomly by noise (which was a significant problem for over a week). The main rule is that all valid messages are started by the " ` " character. Also, the receiver ignores messages that are longer than the standard expected length, since these are most probably erroneous receptions due noise.

One additional feature of the receiver is that it goes to sleep when it senses that the base station is off. The user is notified of this via the LCD. The main point of this feature is to minimize anomalous behaviour due to noise, which becomes prevalent when the transmitter is turned off.

The Remote Station

The remote station (the pager) is responsible for receiving, parsing and displaying all messages received from the local station. First, messages are received via the hardware UART (Pin D0). Next these messages are parsed via their opcode, and then an appropriate task is performed (i.e. store message, store sender, update date/time, address pager, end message, etc).

Addressing

The pager in our system is fully addressable, and is referred to currently as "Bardeen1". The original plan was to have two pagers, but unfortunately, "Shockley" was never produced to do a shortage in transceivers. There is hope that one day, he will be conceived. And when he is, we're ready for him. Even though Bardeen1 is the only pager on our "network", he only responds to messages directed to him. This is done via a simple "add" command, that includes the name of the pager that is being contacted.

The Pager Interface

The key to the pager's interface is a 4x20 LCD that displays time, date, status, a message menu, and the messages themselves. In addition to this are four pushbuttons that allow the user to scroll through the different functions of the pager. Also, there is a buzzer, and a blinking LED, both of which can be turned on as message notification by the sender. If a button is pressed during the audio notification, the sound is stopped, in order to minimize disruption in a meeting.

The main screen of the pager (corresponding to state 1) displays the following:

EE 476 Pager
Time: 7:30 pm
Date: May 2
<Sleeping…>


The last line shown here is shown if the local station is off, or out of range.

The second screen (state 2) of the pager allows the user to scroll through the messages stored by the senders of the messages. The third screen (state 3) is used to view individual messages.

Messages

The pager is able to store up to 3 messages of 2 lines each, only due to memory restrictions. The original design concept included four messages of four lines each.

Opcodes

add <pager name> : Addresses the pager to whom the message is being sent

syn <mmddhhmm> : Sends updated time and date to the pager

fro <sender's name> : Sends the name of the message sender

tx1 <text> : Sends the first line of the message

bli <> : make pager blink when message is received

bzz <> : make pager buz when message is received

end <> : End message

Extra/Potential Features

There were a couple of features that were built into our design and almost fully implemented, but didn't make it into our final product due to certain constraints. First of all, our pagers are fully addressable, however, we were unable to make more than one pager since we only have two transceivers. Second, we had two-way software UART completely working, however, we were unable to use it in our design to temperamental timing requirements of the transceivers. The send and receive routines that are not used (i.e. acknowledgement sending by the remote station) still exist in our code, however, are not called. Lastly, due to memory constraints, we were unable to allow the user to store more messages in the pager. This was purely due to a limitation in SRAM. We were hoping to use external SRAM to avoid this problem, but we didn't have nearly enough ports on the 8515 chip to do this.

Program Details

Here are the highlights of our software. It's really quite straightforward to follow.

The software is programmed in C, with embedded ASM used for the timing-sensitive software UART functions.

Local station:

Timer 1 is used to produce 1ms interrupts, which in turn run "task1" every 50 milliseconds. Task1 is responsible for partly parsing, and then sending messages to the remote station. It checks to make sure that commands received from the PC are valid before they are sent to the remote station.

External interrupt 0 is used for receiving acknowledgements from the remote station via software UART. This interrupt is implemented and fully functional, however, we do not use it in our final version.

Sendword is used to send series of characters via the software UART. This function pads messages with synchronizing pulse trains, and sends them to the remote station.

Sendchar sends a single character via the software UART.

Hardware UART is interrupt driven, and is used to receive commands from the PC via its serial port.

Remote Station:

Timer 1 is used to generate 1-millisecond interrupts, which are used in both timing Task1 and Task2, and also updating the time of day.

Task1 occurs every 50 ms, and is responsible for parsing messages and detecting pushbutton presses. It also does a great deal of cleanup required after messages are received. It is also capable of sending acknowledgements, if they are fully implemented.

Task2 occurs every 1 second, and is responsible for refreshing the LCD display and changing states. As described in the Pager Interface section, state 1 displays the main title screen on the pager, state 2 shows a list of messages stored, and state 3 shows the user individual messages.

Hardware UART is interrupt driven, and is used to receive messages from the local station.

Hardware Details

The hardware is pretty straightforward for our pager. The integral hardware is the pair of transceivers. Other than that, we have an LCD, LED and buzzer on the remote station. We also have some capacitors used for decoupling, and the power circuitry for our 5V power supply. The detailed schematic of the hardware is given in the appendices.

Some Helpful Hardware Tips

A few hardware issues were encountered while we built our pager and its base station. These notes are handy for anyone trying to build a wireless system such as ours.

Antenna Length -> Make the antenna ¼ of a wavelength long. This helps with transmission reliability.

Decoupling -> Adding capacitors between the Ground and Vcc rails help reduce coupling, and make for less noisy reception.

Voltage references -> If the two stations' transmit and receive are connected (in our case, Port D.4 of the local to Port D.0 of the remote) via a wires for debugging purposes, make sure to also connect the grounds of the two stations. Wired transmissions will not be successful if the two stations are at different reference potentials.

The Results

Well, after almost four weeks of design/debugging, and one week of work on noise tolerance, we have fully functional web-enabled pager. Yeah! The pager is definitely susceptible to occasional noise, however, is much better than it was a week ago due to additional hardware and software techniques, as described above.

The potential application we see for such a pager is for an inner-office notification system, used to notify people of e-mail, visitors, or meeting reminders.

What we would have done differently if we had more time, or if we knew what we were doing earlier :)

Well, we're pretty pleased with the finished product, but there are a couple of things we would have done differently: