Welcome to our site! EDAboard.com is an international Electronics 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.
I have worked on a GSM Mobile system (The handset side).Here is the most generic test set-up I used to test the systems. I would describe the overall system for you so that you can have an idea of the system I'm talking about. The genral data flow would take the path as described (This would be helpful on a simulaton environment of Companion side(DSP side))
a) Audio In from serial port. (also refered to as the codec port)
b) Input to the Encoder. (set through the config file of DSP)
c) Modem. (Data is output in I/Q symbols)
In this senerio the essential tools required would be
a) Config file for DSP (This is a normal batch file setting the required register for DSP in simulator)
b) DSP simulator .
c) HOST command file (another batch file which sets the host register at the revelent places according to the test)
d) Modulator (simple C code that would modulate the encoder ouput)
The same thing is inversed for the receving path.
Host Side testing:
Done after the DSP test is complete. The host and DSP images are fused and then run on the HOST side.
1) This involves both the software testing of the command handling mechanism in the data flow through the debugger. (I used ARM host so all the test on simulation was through Code-warrior)
This is the overall test in the development platform
The testing is similar to the above to case except that the data is provided through CMTS or any other packet inserters and data is tapped through logic-analyser. I will not go into details to this as they vary at lot from test to test.
I don't know to what extent this was useful but will sure give you an insight to the whole testing environment setup.
Thanx for the help.
Basically I am using a universal communication tester (CMU200) to run the tests on edge and gsm audio. The purpose of the tests is to test out the functionalities of the mobile handset i am developing now. All these testings are done manually but later on the tests have to be put in automation by using agilent vee program. The automation program is for the production floor side. The main concern now is that what are the parameters that are suppose to test on gsm audio and edge.
I find your question a bit vague but I hope you meant the test criteria for the audio subsystem on the handset I hope, well that is what I'm answering here,if thats not what you expect you are more than welcome to post another query
Anyway now that you have mentioned about CMU & Agllent apparatus I assume the initial testing and the PART A of the testing is complete. Now the basic test setup in this scenerio would depend on the primary setting of IA (Integrated Analog module this h/w chip configure all the interfaces and h/w components through set of register setting that are always ready during the h/w ramping).
Now we perform a module testing both for the stack and the audio subsystem.
I describe the audio subsystem tests, to the extent I remember them
1) Echo cancellation --> this primarily has two type of test first is near- echo and second is far -echo. The cretia here is that the call should never be disconnected due to far -echo. Secondly there is a distance of tolerance beyond which call should be connected for near-echo this is basical AEC testing for values of α, decay-constant etc.
2) For all decoder i.e HR,FR,EFR,AMR decoder s for all suported bitrates
Create a sutiable stream with data packets on alternative time slots for HR, with all the consequtive time slots for other codecs. Now intercept the 13th with SACCH and FACCH on random time-slots this should provide suitable range for DTX and VAD testing.
Sorry I don't remember the specific acceptance ranges as I worked on this setup about 2 years ago.
But the acceptance values can be calculated from the specification and use auto-correaltion techniques (I used corelation techniques) or acoustics precision equipment (I didn't work on them) for calculating the tolerance values.