The user of your software application may not know the COMM port number or Interrupt (IRQ) value of the serial port in which the unit is connected. We recommend a search routine that tries different combinations of COMM port numbers and IRQ values to find the unit. For each combination your software should send an "@" symbol; the unit will respond with a "#" symbol. This automatic search will help minimize serial communication support. To further help with initial computer connections, you might consider a quick link to a simple terminal program preset at the correct serial parameters (9600, N, 8, 1).

A design limitation of the unit is that it can only send or receive data at one instant. Therefore, the unit must be idle when your application sends setup toggles. Also, the master processor of the unit must have enough time to read a toggle and write it to memory before it can receive another. Your application software must allow at least 50 milliseconds between toggles being sent.

Setup toggles are stored in non-volatile memory. The master processor retrieves these toggles and sends them to the 2 slaves processors during the power-up sequence. When toggles are changed by the application software after power-up, the slaves will receive these changes only when they request the toggle status. Slaves request the toggle status during extended periods of inactivity. Depending on the processor cycle time a change in a toggle after power-up may take as long as 2 minutes for the slave to recognize it. Fortunately, this should be an inconvenience only when the application initializes unit for the first time since setup toggles rarely change for a particular application.

The unit writes call records to both the serial port and to memory. The memory may become full even when it is connected to your application. The memory will scroll, so only the latest 248 calls will be in memory at any time. We recommend that when a user gracefully exits from your application, a software routine erases the memory. In the interest of exit time, it may not be necessary that your program wait for the unit to return "OK".

The memory is erased using the "Y" command twice (see pages 10 and 21). The memory requires approximate 27 seconds to erase no matter how many of call records are stored. With the exception of erasing upon a graceful exit, it is best if your application simply waits until an "OK" is sent to continue.

The unit can store 248 calls in memory. Beyond this limit, the memory scrolls dropping the oldest call and adding the newest as the 248th call. While call records are downloading from memory, real-time call records cannot be sent from the unit. If a call happens to arrive while the unit is downloading, the call record is stored in the slave processor. It will be sent to the application once the download through the master processor is complete.

You may consider using the "?" command to inform the user how many calls are in memory before downloading. The user may then have a choice to download immediately or wait. It takes approximately 35 seconds to download the entire memory. If you allow the user to stop the download before is completed, your application must send a “-” (dash) character to the unit. Since the processor can only read or write at one instant, it only looks for the dash command between records sent. You will have to send the dash between downloaded records.

Depending on when the memory was last erased (which may depend on whether a graceful exit was performed by the user) some records in memory may be duplicates of phone calls captured in real-time. It is highly recommended that a routine be incorporated to eliminate duplicate call records in your log files.

In order to save memory space, only end records are written to memory. This fact prevents storing both Caller ID names and digits dialed after an inbound call is answered (lower case "t" toggle) in the memory (see pages 9 and 12). Also, if the unit is set to deliver only "start of call" records in real-time, the memory will still log "end of call" records.