Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronic Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

wireless speech comunication

Status
Not open for further replies.

steviemidnight

Junior Member level 1
Joined
Feb 12, 2002
Messages
19
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
365
my 433MHz walkie-talkie project summary:
re RF project thread: http://www.elektroda.pl/eboard/viewtopic.php?topic=12087&forum=1&start=25&33

after reading/researching and your help i know the following.

I need a anti-alising filter after the mic to prevent spectral repetitons. i have decided to go for a 5 or 7 order chebyshev with a .5 db ribble. this has a good steep curve which cuts of frequencies below 4Khz which sould stop all anti-alising.

I can get pics with an on board ADCs and UARTs, the 16C74 has a 8 bit A/D and a UART. ok i need a speech codec before the Tx this can be built using the 16C74 and its A/D then writting a few lines of code to encode the bit stream with stop, sync and parity bits depending on my chosen method of encription.
I then need to decode this at the RX end. the Rx will let in a lot of unwanted interference/noise and so the reciver code will be more complicated, as i believe. i need to decode the sent packets of information with some kind of error checking. A warm up signal from the Tx encoder would help be set up the Rx decoder - but unsure
Ok manchester code is 50% efficent has it encodes a 1 with a 1 then the opposite a 0, which doubles the length of the bit stream. i have available data rates of upto 128kbits which should be enough.
The RS232 standard is intended for relatively short (50feet or less), relatively low speeds(19kbit/s) serial communication over a wire. this could work as it is implimented in radio modems, but is not designed for this purpose and so would cause problems.
GSM speech codec use only 13kbit/s with the channel codec using a further 22kbit/s but this is a very complicated method and so would need a DSP chip with a complex code - far beyond me!

A filter at the output is needed to smoothe the staircase wave form from the DAC and a simple amplifier(not sure of what class) will probably be required to power the speaker. this will enable a onway communication device.
A switching method which u hold when speaking could simplify my coding problem. AS you hold the button a set of warm up bit/s is sent followed by a snync bit and stop bit is sent after the release of the switch( could cause problems with long periods of speech. this switching method would need to be inplace for a 2way radio link and so would be good if i could impliemnt this into my design.

so it sound like i know what im dong and i do to some exstent. but im stuck on the programming. i know i could buy a chip thas does everything ie CVSD etc. But i would like to prog a pic to better my understanding. so im stuck on pic programming

I know that pics can be programmed in C, assembly and hex. And assembly as the benefit of better timing control, i think. but i would like some basic wireless communication code that sets up all the ports/pins etc. so i can consentrate on the modulation. i will test this over a wire link first before adding the fm modules
 

Encrypted

Advanced Member level 4
Joined
May 28, 2001
Messages
115
Helped
17
Reputation
36
Reaction score
5
Trophy points
1,298
Activity points
705
I've tried telling you this a few times but I think you're confused. This scheme will not work. The start and stop bits need to be added to EACH sample.

You are going to take 8-bit samples, 8,000 times a second. To your 8-bit sample you are going to add at the very least start and stop bits, forget about the rest for now. So you now have 10-bits * 8,000 samples per second = 80,000 bits per second. The manchester encoding doubles this to 160,000 bits per second. Oops! The modules can only handle 128,000 bits per second, you DON'T have enough bandwidth!
 

steviemidnight

Junior Member level 1
Joined
Feb 12, 2002
Messages
19
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
365
Ok i know that i cannot use Manchester coding but it is possible to do that why i need to use a compressive encoding technique for example GSM( there are alot). also there are alot of these digital walkie talkies on the market and these will have limited bandwidth due to goverment regulations so what im asking is possible. your right though just not with manchester encoding.

what i am doing is possible im sure i just need some guidence.

when you say:The start and stop bits need to be added to EACH sample.

do you mean each packet of what data. ie you speek the adc digitizes the speech and then encode this into packets of a certain length, with start stop bits. which also needs sync bits so the clock is not lost. which does increase the length of the bit stream i agree but engineers having been solving this problem for years as there is allways limited bandwidth and data rates. i know i need some kind of complex alogarithms.

but is it possible to prog a pic with a few lines of encoding code like my lecturer suggests. then UART the code in a pic decode then sendit out to a DAC
 

Encrypted

Advanced Member level 4
Joined
May 28, 2001
Messages
115
Helped
17
Reputation
36
Reaction score
5
Trophy points
1,298
Activity points
705
All these walkie-talkies (I presume you mean the FRS/PMR446 ones) are analog.

You will have to use some sort of biphase encoding. The links in the previous posts explain why.

Of course what your doing is possible, you just don't seem to be taking the guidance!

Engineers have been solving this by using compression and/or more efficient modulation methods which can transmit more bits down the same bandwidth. You can't use these modulation methods with your modules, you're stuck with FSK.

I don't know much about CVSD but I think that why it was suggested is that you can do without the start and stop bits, etc. You just take your raw 64K/bit CVSD output, manchester encode it and feed it straight into your module. This is the best suggestion, if you have something against using the CVSD chips then try doing it in code. If you must use a PIC then use one to do the manchester encoding/decoding.

I'd start by getting a couple of the CVSD chips and get it working across the workbench using wires to carry the data and clock. Now, combine the data and clock onto one wire and test this. Now is the time to get out the tx/rx modules.
 

Status
Not open for further replies.
Toggle Sidebar

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Top