[Idea + Questions] Voice Encryption Using ADC & DAC

[OmarAta]

Hi everybody,

Finally i found a forum that talks only about electronics .. !!
Anyway .. first i am kind of new to the electronics world .. i have a good background, but not expert
alright, i'm thinking of a project to do with one of my friends in the university in our free time .. i'm thinking to do a "Voice Encryptor" .. but the main idea is to make it totally using hardware (with no PC required) ..
so we thought of a basic idea to use it as the base of our project .. the concept is too simple for the first step in our project then we will try to make it more advance if this works ..
anyway, the idea is to take the voice signal (which is analog) and insert it to a ADC (ADC0804) which will gives us digital output of 8-bit using the continues conversion circuit shown in this image ..

**broken link removed**

then do some process to the digital output (this process will be considered as the encryption)

then enter the result 8-bits to an DAC to re-convert it to analog (i'm using DAC0800LCN)

**broken link removed**

so that if we entered a normal sin wave from a function generator and graph the output on a Oscilloscope the output will not be a proper sin wave .. so we can consider that as a kind of encryption then the result analog signal we will take it and re do the whole process to it but with changing the digital process that we apply it to it so that the new process will decrypt the signal and the output analog signal will be the same sin wave we entered in the first time ..

this is the main idea i'm working for .. but right now i was trying to understand how to properly conect the ADC to DAC together ..
so i'm trying to connect the output from the ADC directly to the input of the DAC with no any process applied to it to just see how it works .. but i'm facing some problems knowing what should i connect some pins to !!
like the (Vref/2) in the ADC or the and the (Vref+ & Vref-) and the (VLC) in DAC ??

i tried to use an 5V PK-PK sinusoidal as an input for the ADC and i connected the (Vref/2) in the ADC to a +2.5V and in the DAC i connected (Vref+) to a +5V and (Vref-) to a -5V and the (VLC) to a GND and i haven't connected the (COPM) to anything .. the result was sinusoidal too, but the problem was that it was 10mV PK-PK only !!!

so any idea how to help me in my project .. and sorry for the very long post


Regards,
Ata

 

[Nigel Goodwin]

I suggest you dump the antique components, use a modern microcontroller, a PIC with in-built A2D and hardware PWM DAC (or use an R2R ladder DAC) can easily digitise the audio, encrypt it in software, and output an analogue signal.

 

[OmarAta]

well the problem that i don't know how to program the PIC .. and in this time these are just the components i have with me ..
but is there is any wrong with the way I'm using (except being too ancient ) ??
and you said encrypt it using a software .. do you mean a PC ?? because I'm trying to make it real time voice encryptor but i want to make it fully hardwarelly .. ?!

 

[Roff]

Just be aware that simple bit scrambling will yield an analog signal with a bandwidth that is potentially much higher than your original signal, so if you have a bandwidth-limited channel, such as a phone line, that the encrypted signal has to traverse, you will lose information and not be able to descramble on the receiving end. If you do have such a channel, you have to choose an encryption method that will not exceed its bandwidth.

 

[OmarAta]

yes this is what i'm trying to do ..
i want to connect this circuit to the phone microphone and speaker in the both sides ..
so that the encryptors will be in the microphones and the decryptor will be in the speakers ..
but my main question was .. what is the best voltages to apple to the Vref pins in the ADC & DAC ??

 

[Nigel Goodwin]

well the problem that i don't know how to program the PIC .. and in this time these are just the components i have with me ..
but is there is any wrong with the way I'm using (except being too ancient ) ??

How were you planning doing the encryption?, and were you planning running 9 core cable between the transmitter and receiver?.

A PIC gives a single chip solution, by just learning a little programming.

and you said encrypt it using a software .. do you mean a PC ??

No, inside the PIC.

 

[Gary B]

A few thoughts for your project if you have not already completed it.
Use a sample rate of 8k/sec. and input/output filtering to limit the band-pass to between 300hz and 3.5khz.

This will give you a data stream that is compatible with the public telephone network if you hold the sample rate accurately enough. Otherwise, you could have problems with the public network resampling your audio and inadvertently creating sampling artifacts.

Second, have you decided upon an algorithm? If you have a good chunk of memory available, and who doesn’t these days, you can just load it with a random number generator. Just XOR the data to encode or decode. The security level is related to the length of the codeword before it repeats. If you flip a coin for each 1 or 0, your repeat length is the size of the memory used. Otherwise it is related to the pseudorandom number generator you used to generate the key.

 

[arslan87]

Help me anybody

hey omarata i also making that project of title implementation of voice encryption and decryption in pstn
now plzz tell me all about that project
give me circuit diag of that which work correctly
and also the algorithm that run on it
my email is arslan_369@hotmail.com

 

[3lectrokid]

why would you need to encrypt voice data on a phone???

 

[Nigel Goodwin]

why would you need to encrypt voice data on a phone???

Fairly obviously so people can't listen in.

 

[3lectrokid]

why would you need to encrypt voice data on a phone???

Fairly obviously so people can't listen in.

Yeh i suppose. sorry for the silly question

 

[Warpspeed]

The final stage of transmission involves converting your scrambled digital signal back to an analog voltage with a d/a converter.

At the receiving end a similar a/d converter WILL NOT re create the exact same scrambled digital signal, because of random gain and phase effects of the telephone line. There is not even any guarantee beth ends will be switching and sampling in exact synchronism.

It might work in a fashion, if the d/a and a/d were directly connected and both clocked together, but even then you will have the plus or minus one bit ambiguity problem.

But connecting the d/a and a/d together through a long telephone line, and assuming a fair bandwidth utilization, and some added noise, with unknown amplitude and phase modifications to the signal. There are going to be far too many problems to make this workable.

 

[Roff]

The final stage of transmission involves converting your scrambled digital signal back to an analog voltage with a d/a converter.

At the receiving end a similar a/d converter WILL NOT re create the exact same scrambled digital signal, because of random gain and phase effects of the telephone line. There is not even any guarantee beth ends will be switching and sampling in exact synchronism.

It might work in a fashion, if the d/a and a/d were directly connected and both clocked together, but even then you will have the plus or minus one bit ambiguity problem.

But connecting the d/a and a/d together through a long telephone line, and assuming a fair bandwidth utilization, and some added noise, with unknown amplitude and phase modifications to the signal. There are going to be far too many problems to make this workable.

I agree. Sending scrambled audio raises the channel bandwidth requirement to at least half the sample rate.

 

[dougy83]

I agree. Sending scrambled audio raises the channel bandwidth requirement to at least half the sample rate.

Even without increasing the bandwidth, (as warpspeed said) it's unlikely that the second ADC will convert to the actual codes that you wanted/expected - therefore the 'decoded' signal will be totally different to what is fed into the first ADC.

 

[Roff]

Even without increasing the bandwidth, (as warpspeed said) it's unlikely that the second ADC will convert to the actual codes that you wanted/expected - therefore the 'decoded' signal will be totally different to what is fed into the first ADC.

That was my point.

 

[crutschow]

You could A/D the speech into an old fashioned 56K telephone modem, transmit the speech as a digital signal and then decode it with a D/A at the other end. All anyone listening in would hear is the usual modem "noise".

 

[Warpspeed]

You could A/D the speech into an old fashioned 56K telephone modem, transmit the speech as a digital signal and then decode it with a D/A at the other end. All anyone listening in would hear is the usual modem "noise".

That is how I would probably do it.

 

[Dick Cappels]

You did not describe the connections to the DAC0800LCN. Its a pretty simple chip and its difficult to hook it up incorrectly. Remember that it needs a negative power supply and load resistors from the output to the positive power supply. Failure to provide either or both of these could account for your very tiny output signal.

 

[audioguru]

I worked with tele-conferencing systems. Most of the big banks head offices used the systems I installed and improved. One bank was shocked to learn that the wireless mics can be received across the street and insisted on encryption.
I designed a single-sideband suppressed carrier circuit using MC1496 balanced modulator/demodulator ICs in the transmitter and receiver. I used switched-capacitor lowpass filter ICs to remove the unwanted sideband. The encrypted signal was perfectly unintellegible when received on an ordinary radio and the demodulated signal sounded perfect exactly like the original signal. They liked it and ordered it. But they soon went bankrupt for cheating their customers and the system was never paid for.

 

[Gary B]

I think you may be missing a bet. Both the AD and DA converters are on both ends. You convert to digital, encrypt, add a clock signal and convert back to analog. The telephone at the other end reverses the process. NOTE: this will probably fail if you attempt to use a VoIP link between the phones. I find a 56K minimum bandwidth is necessary to maintain lock.