Project Logs

Collapse

• AutoBlock Software Behavior

  David Levi • 04/30/2017 at 23:06 • 0 comments

  Before writing code, it's always a good idea to plan ahead. Below, I've outlined the basic behavior the AutoBlock will follow to decide which calls to let thought.

  The AutoBlock will be able to:

  • Read in and send out audio on the phone line
  • Decode caller ID and dial tones by processing input audio
  • Detect when the phone line ring
  • Pick up or accept a call
  • Control a relay between the phone line and the user's phone
  • Send and receive data from a mobile app

  Below is a diagram of what happens when the phone line rings:

  A ringing phone creates an interrupt service routine (ISR) and sets the processor to follow the above behavior. Once the phone starts ringing, all other interrupts are disabled. Then, the signal from the phone line is recorded. This data is processed and Caller ID info is taken from the Dial Tone or FSK data. In the United States, the caller ID information is sent after the first ring.

  Once the incoming phone number has been detected, the system decides whether to block the call. Whitelisted numbers stay connected to the phone line. If it is not on the whitelist, the user's phone (the "Office") is disconnected. The loop switch is closed so that the Autoblock picks up the call. Then, an Audio Captcha tests if the incoming call is from a robot.

  The Audio Captcha decides on a random PIN number. It sends audio instructions on what AutoBlock is and how the Audio Captcha works. Then, it sends the PIN numbers by piecing together audio files of spoken numbers. Random background noise is added to make it harder for a computer to turn the audio back into number. The system waits for the correct dial tones to come back, then determines if the incoming caller is human or not.

  If the incoming call passes the test, the number is added to the whitelist. Instructions are sent over audio, and the loop switch is opened, ending the call. The newly whitelisted caller can redial and will be directly connected to the user's phone.

  One important side case is how to handle calls that come with no caller ID. Almost all of these calls seem to be spam anyway, so the default setting will be to automatically reject these calls. But, if the end user wishes, calls without ID can be handled separately. When a phone line without caller ID passes the Audio Captcha, AutoBlock will be disabled for perhaps 90 seconds. In this time, the caller can redial to reach the end user.

  To keep costs down for the customer, we decided against the extra electronics required to create the high voltage ringing signal. Because of this, the caller needs to redial after passing the audio captcha. Since each caller would only need to redial once, we think this is not an issue. But let us know if you think adding the extra features are worth it.

  Also, because we want the user's phone to be able to collect caller ID info, we do not block the call until after caller ID info has been sent. By default, the line is connected, and only disconnects once a call off the whitelist is detected. Because Caller ID is not sent until after the first ring, spam calls will ring once before being blocked. Again, let us know what you think of this decision.

  This diagram will keep us organized as we add all the different features and functions needed for the AutoBlock system.

• Electronics Design V0.1

  David Levi • 04/30/2017 at 21:16 • 0 comments

  Below, I will outline the first draft of the hardware needed for Autoblock. We're making landlines smart, and to do this we need to connect a processor to telecom lines. We've put together a prototype on a breadboard, and are writing code to make it all work.

  This first revision uses three main stages: A Silvertel telecom module, a codec, and a Raspberry Pi. By building off of modules, we'll be able to quickly bring this product to spam-filled phone lines.

  The first stage contains the Silvertel AG2130 module, the related resistors/capacitors/protection, RJ11 connectors, and a relay. The AG2130 connects to the phone line with all the proper impedance and isolation. Analog audio from the phone line is brought out to the Vin Pin, and audio can be sent to the phone line at Vout.

  When the phone line rings, the "RS" pin on the module goes low. By setting the "LSC" pin high, the system can close the loop switch, accepting the phone call. With this, a processor can tell when a phone call is coming in, and can pick up the call.

  A relay controls if the phone line from the wall (the station side) connects with the user's phone (the office side). When this relay is open, no signal reaches the user's phone. The exact relay, and if the relay is magnetic or optical, has not yet been decided.

  A voice band codec CPC5750 digitizes the input and output analog audio from the telecom module. Audio data is sent and received from the processor using PCM, with SPI to control different setting internal to the Codec.

  Finally, we have the processor for this system. Since we are using a Raspberry Pi, the schematic above is for a header that will connect to the Raspberry Pi Zero W board. The Pi connects to the Codec using SPI and PCM, and connects to the "RS" and "LSC" pins on the Silvertec module using GPIO

  The Pi will be able to process dial tones/caller ID, send out the audio captcha, remember whitelisted phone numbers, run analytics, and decide what phone calls can pass though. Since we're using a Pi Zero W, we'll be able to control settings and review analytics over Bluetooth using a mobile app.

  Telecom module, digitization of analog audio, and a processor. With these parts, we can make phone lines smart and finally block spam.

View all 2 project logs