Reply by Mehrnaz Hazrati●February 11, 20092009-02-11
Hi Jeff,
thanks for your last comments. You exactlygotthe issue!
Actually the test setup in the lab is not the same as scada room (power
station), because the Multiplexer and PLC are missed. By the way, the
problemexists yet. I use Line-in and Line-out codec jacks to communicate
between DSK boards( a doughter card for digital connection is developed but I
don't use them right now). >I assume this means you are using McBSP to communicate
between DSK boards, not >RS-232. One board is the master and drives framesync
and clock to the other board at 12 >kHz -- is that correct? I have done another test, similar to what you proposed. I wired the codec
clock inboard 1 from board 2 and I noticed that data transmission was perfect
for half an hour and then every thing corrupted !
At this time, I'm trying to recover clock from received data in DSKto send
it to one pinand feed the clodec and Mcbsp clocks. I don't know if it is
practical at all. but i don't have any idea aboutsoftware PLL !
Bests,
Mehrnaz
--- On Mon, 2/2/09, Jeff Brower wrote:
From: Jeff Brower
Subject: Re: [c6x] implementing the software PLL
To: c...
Date: Monday, February 2, 2009, 12:46 AM
Mehrnaz-
> thank you for your reply and your nice
suggestions.
> Would you introduce me a source file for studying about jitter buffer concept
in VoIP?
This is easy to search for on online, you can put something like 'what is a
jitter buffer' into Google.
> while the whole implanted progam in DKS works with a
single clock, can a software PLL help me to regulate the
> clock in receiver equal to transmitter?
You already have your algorithm, including QAM and timing recovery, working and
if you implement RS-232 (async serial
method) as Richard suggested then you can communicate between boards reliably.
Or if you can connect the boards with
McBSP (sync serial method), and let one board drive clock and framesync to other
board, and again your communication
between boards would be 100% reliable.
But in either case the clock slip issue will persist, because your analog domain
clock (ADC + DAC) is different for
each board. One board or the other will eventually "eat data" faster then the
other board is supplying the data. You
can:
1) Find some way to derive analog domain clocks from your receive digital data.
For test purposes (to prove the
solution), maybe use your interboard McBSP clock to drive the AIC23B on both
boards. That's easy enough to wire
(you're already doing some re-wiring experiments) , but one thing that is
tricky is when you initialize the AIC23B
codecs in software, you have to make sure the interboard McBSP is already
running.
2) Let each AIC23B continue to use its own oscillator, but implement a software
PLL technique such as one I described.
> P.S:The CPU clock is 216M and McBSP works in 12k and
codek 48k.
I assume this means you are using McBSP to communicate between DSK boards, not
RS-232. One board is the master and
drives framesync and clock to the other board at 12 kHz -- is that correct?
-Jeff
> The problem, as I guess, is that the F_ref in two
boards are not the
> same.when I run Initpll in Gel fileto set CPU Clk, there is yet a very
little different between two boards.
> I have disconnected codec 50M cystal on board and use the same clock(24M) for
codec part.
> As a fact, this modem should be mounted on a PLC (power line carrier) and the
communicaion should be sync and
> countinously. I have not option of async !
> I have done another test: I disconnected the 24M crytal form one board and
wired clock from theother board to it. Now
> every thing works perfect.
> Before applying this change, when I check the data transmission with a data
tester(Acterna) Device, I see a BER every
> nearly 100s.
> But in practice these two modems should be placed 12Km far from each other! So
wiring is obviously ridiculous.
> I just wonder, how other synch. MODEMs, implemented on DSK boards, work?
> I appreciate any new idea from you :)
> regards,
> Mehrnaz
>
> P.S:The CPU clock is 216M and McBSP works in 12k and codek 48k.
> --- On Fri, 1/30/09, Jeff Brower wrote:
>
> From: Jeff Brower
> Subject: Re: [c6x] implementing the software PLL
> To: c6x@yahoogroups. com
> Date: Friday, January 30, 2009, 8:53 PM
> Mehrnaz-
>
>> Actually, I am working in a project, implementing the MODEM using
>> DSP6713, and I hope I can gain your deftness in this case.
>> After implementing the whole algorithm on DSK boards (using
>> MATLAb simulink + Code composer) I encountered a problem.
>> It seems all parts of model include 32 QAM, Timing recovery,
>> Equalizer and carries recovery algorithms act well during
>> simulation.However, after implementing it on two separate
>> DSK boards(due to the small difference between oscillator
>> crystals) the 48khz doesnot match exactly and I see slip error
>> in practice. Have you any idea how I can remedy it using a
>> software PLL(is it logically possible)?
>
> First, you might want to study the jitter buffer concept in VoIP --
that's basically
> a software PLL, assuming Ethernet as the underlying comm method.
>
> Second, you can use async communication (e.g. RS-232) between your DSK 6713
boards,
> as Richard suggested. There are some things you can do there to make sure the
two
> systems stay in sync, basically amounting to allowing clock drift only for
each byte
> transmitted.
>
> Third, you can use a sync method between the boards, which can give you a far
higher
> bandwidth than RS-232.
>
> Let's say your analog sampling is using separate sampling clocks (that
could be audio
> I/O, or in your case RF communication assuming baseband data), and they
communicate
> with each other using a synchronous method (e.g. sync serial port, RS-422,
etc),
> which is driven from separate clock (maybe same one that drives the DSP).
That's two
> clocks, there could be more, but my point is there may be multiple causes of
clock
> drift between the boards, so trying to monitor clock edges or other
relative
> techniques on one board, even if it can "see" the clock from the other board,
may
> still become overly complex.
>
> One way to deal with this is to introduce a bit of buffering in the sync
> communication, let's say 4 buffers. For example the audio frame is 128
samples, and
> sync comm buffers are 10 to 20 bytes (say after speech compression) . The ISR
code
> watches these buffers and tries to keep the actual buffering at 2. If the
number of
> buffers decreases or increases then the the code inserts one sample in the
incoming
> audio frame or deletes one. This doesn't happen often assuming the clock
drift is
> not dramatic -- from a percentage standpoint, maybe one out of 1000s of audio
samples
> are affected -- so the effect on voice quality can be neglected. What this
amounts
> to is adjusting the analog sampling rate clock, which is the least sensitive
clock in
> the system to small changes.
>
> Of course the tradeoff is latency; the extra sync comm buffers may be a
problem. The
> same tradeoff exists in VoIP -- the jitter buffer gets too large and people
start to
> notice. Limit the jitter buffer, then a packet gets dropped, and again
people
> notice.
>
> -Jeff
_____________________________________
Reply by Jeff Brower●February 1, 20092009-02-01
Mehrnaz-
> thank you for your reply and your nice
suggestions.
> Would you introduce me a source file for studying about jitter buffer concept
in VoIP?
This is easy to search for on online, you can put something like 'what is a
jitter buffer' into Google.
> while the whole implanted progam in DKS works with a
single clock, can a software PLL help me to regulate the
> clock in receiver equal to transmitter?
You already have your algorithm, including QAM and timing recovery, working and
if you implement RS-232 (async serial
method) as Richard suggested then you can communicate between boards reliably.
Or if you can connect the boards with
McBSP (sync serial method), and let one board drive clock and framesync to other
board, and again your communication
between boards would be 100% reliable.
But in either case the clock slip issue will persist, because your analog domain
clock (ADC + DAC) is different for
each board. One board or the other will eventually "eat data" faster then the
other board is supplying the data. You
can:
1) Find some way to derive analog domain clocks from your receive digital data.
For test purposes (to prove the
solution), maybe use your interboard McBSP clock to drive the AIC23B on both
boards. That's easy enough to wire
(you're already doing some re-wiring experiments), but one thing that is
tricky is when you initialize the AIC23B
codecs in software, you have to make sure the interboard McBSP is already
running.
2) Let each AIC23B continue to use its own oscillator, but implement a software
PLL technique such as one I described.
> P.S:The CPU clock is 216M and McBSP works in 12k and
codek 48k.
I assume this means you are using McBSP to communicate between DSK boards, not
RS-232. One board is the master and
drives framesync and clock to the other board at 12 kHz -- is that correct?
-Jeff > The problem, as I guess, is that the F_ref in two
boards are not the
> same.when I run Initpll in Gel fileto set CPU Clk, there is yet a very
little different between two boards.
> I have disconnected codec 50M cystal on board and use the same clock(24M) for
codec part.
> As a fact, this modem should be mounted on a PLC (power line carrier) and the
communicaion should be sync and
> countinously. I have not option of async !
> I have done another test: I disconnected the 24M crytal form one board and
wired clock from theother board to it. Now
> every thing works perfect.
> Before applying this change, when I check the data transmission with a data
tester(Acterna) Device, I see a BER every
> nearly 100s.
> But in practice these two modems should be placed 12Km far from each other! So
wiring is obviously ridiculous.
> I just wonder, how other synch. MODEMs, implemented on DSK boards, work?
> I appreciate any new idea from you :)
> regards,
> Mehrnaz
>
> P.S:The CPU clock is 216M and McBSP works in 12k and codek 48k.
> --- On Fri, 1/30/09, Jeff Brower wrote:
>
> From: Jeff Brower
> Subject: Re: [c6x] implementing the software PLL
> To: c...
> Date: Friday, January 30, 2009, 8:53 PM
> Mehrnaz-
>
>> Actually, I am working in a project, implementing the MODEM using
>> DSP6713, and I hope I can gain your deftness in this case.
>> After implementing the whole algorithm on DSK boards (using
>> MATLAb simulink + Code composer) I encountered a problem.
>> It seems all parts of model include 32 QAM, Timing recovery,
>> Equalizer and carries recovery algorithms act well during
>> simulation.However, after implementing it on two separate
>> DSK boards(due to the small difference between oscillator
>> crystals) the 48khz doesnot match exactly and I see slip error
>> in practice. Have you any idea how I can remedy it using a
>> software PLL(is it logically possible)?
>
> First, you might want to study the jitter buffer concept in VoIP --
that's basically
> a software PLL, assuming Ethernet as the underlying comm method.
>
> Second, you can use async communication (e.g. RS-232) between your DSK 6713
boards,
> as Richard suggested. There are some things you can do there to make sure the
two
> systems stay in sync, basically amounting to allowing clock drift only for
each byte
> transmitted.
>
> Third, you can use a sync method between the boards, which can give you a far
higher
> bandwidth than RS-232.
>
> Let's say your analog sampling is using separate sampling clocks (that
could be audio
> I/O, or in your case RF communication assuming baseband data), and they
communicate
> with each other using a synchronous method (e.g. sync serial port, RS-422,
etc),
> which is driven from separate clock (maybe same one that drives the DSP).
That's two
> clocks, there could be more, but my point is there may be multiple causes of
clock
> drift between the boards, so trying to monitor clock edges or other
relative
> techniques on one board, even if it can "see" the clock from the other board,
may
> still become overly complex.
>
> One way to deal with this is to introduce a bit of buffering in the sync
> communication, let's say 4 buffers. For example the audio frame is 128
samples, and
> sync comm buffers are 10 to 20 bytes (say after speech compression) . The ISR
code
> watches these buffers and tries to keep the actual buffering at 2. If the
number of
> buffers decreases or increases then the the code inserts one sample in the
incoming
> audio frame or deletes one. This doesn't happen often assuming the clock
drift is
> not dramatic -- from a percentage standpoint, maybe one out of 1000s of audio
samples
> are affected -- so the effect on voice quality can be neglected. What this
amounts
> to is adjusting the analog sampling rate clock, which is the least sensitive
clock in
> the system to small changes.
>
> Of course the tradeoff is latency; the extra sync comm buffers may be a
problem. The
> same tradeoff exists in VoIP -- the jitter buffer gets too large and people
start to
> notice. Limit the jitter buffer, then a packet gets dropped, and again
people
> notice.
>
> -Jeff
_____________________________________
Reply by Richard Williams●February 1, 20092009-02-01
Mehranaz,
on a RS-232 protocol,the bit times must be sync'd often, it will not run
continuously with out the syncing.
The easiest way to sync is to have a large difference between the peripheral
clock rate and the data bit rate + at least 2 bit times of '1'(stop
bit) between
each character.
This allows the hardware to over sample the incoming signal so when the
'0'(start bit) arrives, the hardware can re-sync to within +/- 1
sampling
period. It does this on every start bit.
Rather than mess with the PLL, which will have little if any effect on the
oversampling, I would be looking at:
-- the divisor on the (high or low speed, not sure which for the McBSP)
peripheral clock control register
-- the communication control register format settings
-- the baud rate registers.
It might also be useful to look at the actual signal with a 'scope to
assure
there is no noise causing false edge triggering and that the rise/fall times
are
very fast (without causing any 'ringing').
Again, regarding the ratio between the peripheral clock rate and the baud
rate.
The higher this ratio, the better.
BTW:
gel files are for initial devlopment.
after the project is running from powerup-forward without the CCS connected,
the
gel files have no effect. Then all things done in the Gel files must be
implemented in the code.
This usually means, for your case, the setting of the PLL must be done during
the powerup initialization, not in some gel file.
R. Williams
---------- Original Message -----------
From: Mehrnaz Hazrati
To: Richard Williams
Cc: c...
Sent: Sun, 1 Feb 2009 00:30:29 -0800 (PST)
Subject: Re: [c6x] implementing the software PLL
> Dear Richard,
>
> thank you for your reply and your nice suggestions.
> There is an analog connection between two modems, using codec.
> I attach the block digram.
> The CPU clock is 216M and McBSP works in 12k and codek 48k.
>
> As a fact, this modem should be mounted on a PLC (power line carrier)
> and the communicaion should be sync and countinously. I have not
> option of async ! I'm thinking about your suggestions, it takes time
> to apply some of them. By the way, I have another question,isn't Rs-
> 485 protocol equal to Rs-232 except its voltage level that is higher
> for far communication? In my case I didn't need the far UART
> connection, the data is sent through a Multiplexer over power line. At
> this time I have the slip problem even in Lab, testing with a data
> tester.
>
> I have tried to edit the Gel file, to change the clock rate during the
> run of programm. But such a nimble variation that I need can't be
> adjusted by changing the registeres.
>
> regards,
> Mehrnaz
>
>
>
>
> --- On Fri, 1/30/09, Richard Williams wrote:
>
> From: Richard Williams
> Subject: Re: [c6x] implementing the software PLL
> To: m...@nri.ac.ir, c...
> Date: Friday, January 30, 2009, 4:20 AM
>
> ehranaz,
>
> slip between different systems is normal.
>
> There are several ways to re-align. Some of these are:
> --use two stop bits
> --limit the number of characters being transmitted in one sequence.
> --pause at least one character time between messages, with the line in
> the 'high' state (1). --force the line into the 'high'
state for at
> least two bit times before transmitting the start bit (0). --run a
> higher freq clock to the UART peripheral because ( peripheral clock /
> baud rate ) determine how many samplings are made for each bit time.
> The more samplings the better. --assure the rise/fall time of the
> edges of the bit transitions is well within the specs. --use RS-485
> rather than RS-232 protocol.
>
> R. Williams
>
> ---------- Original Message -----------
> From: Mehrnaz Hazrati
> To: c6x@yahoogroups. com
> Sent: Tue, 27 Jan 2009 06:17:27 -0800 (PST)
> Subject: [c6x] implementing the software PLL
>
> > Hello DSP experts !
> >
> > Actually, I am working in a project, implementing the MODEM using
> > DSP6713, and I hope I can gain your deftness in this case. After
> > implementing the whole algorithm on DSK boards (using MATLAb simulink
> > + Code composer) I encountered a problem. It seems all parts of model
> > include 32 QAM, Timing recovery, Equalizer and carries recovery
> > algorithms act well during simulation.However, after implementing it
> > on two separate DSK boards(due to the small difference between
> > oscillator crystals) the 48khz doesnot match exactly and I see slip
> > error in practice. Have you any idea how I can remedy it using a
> > software PLL(is it logically possible)? Thanks for you attention Mehrnaz
> ------- End of Original Message ------- ------- End of Original Message -------
_____________________________________
Reply by Mehrnaz Hazrati●February 1, 20092009-02-01
Dear Richard,
thank you for your reply and your nice suggestions.
There is an analog connection between two modems, using codec.
I attach the block digram.
The CPU clock is 216M and McBSP works in 12k and codek 48k.
As a fact, this modem should be mounted on a PLC (power line carrier)
and the communicaion should be sync and countinously. I have not option of async
!
I'm thinking about your suggestions, it takes time to apply some of
them.
By the way, I have another question,isn't Rs-485 protocol equal to Rs-232
except its voltage level that is higher for far communication?
In my case I didn't need the far UART connection, the data is sent through
a Multiplexer
over power line. At this time I have the slip problem even in Lab, testing with
a data tester.
I have tried to edit the Gel file, to change the clock rate during the run of
programm.
But such a nimble variation that I need can't be adjusted by changing the
registeres.
regards,
Mehrnaz
--- On Fri, 1/30/09, Richard Williams wrote:
From: Richard Williams
Subject: Re: [c6x] implementing the software PLL
To: m...@nri.ac.ir, c...
Date: Friday, January 30, 2009, 4:20 AM
ehranaz,
slip between different systems is normal.
There are several ways to re-align. Some of these are:
--use two stop bits
--limit the number of characters being transmitted in one sequence.
--pause at least one character time between messages, with the line in the
'high' state (1).
--force the line into the 'high' state for at least two bit times
before
transmitting the start bit (0).
--run a higher freq clock to the UART peripheral because ( peripheral clock /
baud rate ) determine how many samplings are made for each bit time. The more
samplings the better.
--assure the rise/fall time of the edges of the bit transitions is well
within
the specs.
--use RS-485 rather than RS-232 protocol.
R. Williams
---------- Original Message -----------
From: Mehrnaz Hazrati
To: c6x@yahoogroups. com
Sent: Tue, 27 Jan 2009 06:17:27 -0800 (PST)
Subject: [c6x] implementing the software PLL
> Hello DSP experts !
>
> Actually, I am working in a project, implementing the MODEM using
> DSP6713, and I hope I can gain your deftness in this case. After
> implementing the whole algorithm on DSK boards (using MATLAb simulink
> + Code composer) I encountered a problem. It seems all parts of model
> include 32 QAM, Timing recovery, Equalizer and carries recovery
> algorithms act well during simulation.However, after implementing it
> on two separate DSK boards(due to the small difference between
> oscillator crystals) the 48khz doesnot match exactly and I see slip
> error in practice. Have you any idea how I can remedy it using a
> software PLL(is it logically possible)? Thanks for you attention Mehrnaz ------- End of Original Message -------
Reply by Mehrnaz Hazrati●February 1, 20092009-02-01
Dear Jeff,
thank you for your reply and your nice suggestions.
Would you introduce me a source file for studying about jitter buffer concept in
VoIP?
while the whole implanted progam in DKS works with a single clock, can a
software PLL help me to regulate the
clock in receiver equal to transmitter? The problem, as I guess, is that the
F_ref in two boards are not the same.when I run Initpll in Gel fileto set CPU
Clk, there is yet a very little different between two boards.
I have disconnected codec 50M cystal on board and use the same clock(24M) for
codec part.
As a fact, this modem should be mounted on a PLC (power line carrier) and the
communicaion should be sync and countinously. I have not option of async !
I have done another test: I disconnected the 24M crytal form one board and wired
clock from theother board to it. Now every thing works perfect.
Before applying this change, when I check the data transmission with a data
tester(Acterna) Device, I see a BER every nearly 100s.
But in practice these two modems should be placed 12Km far from each other! So
wiring is obviously ridiculous.
I just wonder, how other synch. MODEMs, implemented on DSK boards, work?
I appreciate any new idea from you :)
regards,
Mehrnaz
P.S:The CPU clock is 216M and McBSP works in 12k and codek 48k.
--- On Fri, 1/30/09, Jeff Brower wrote:
From: Jeff Brower
Subject: Re: [c6x] implementing the software PLL
To: c...
Date: Friday, January 30, 2009, 8:53 PM
Mehrnaz-
> Actually, I am working in a project, implementing the
MODEM using
> DSP6713, and I hope I can gain your deftness in this case.
> After implementing the whole algorithm on DSK boards (using
> MATLAb simulink + Code composer) I encountered a problem.
> It seems all parts of model include 32 QAM, Timing recovery,
> Equalizer and carries recovery algorithms act well during
> simulation.However, after implementing it on two separate
> DSK boards(due to the small difference between oscillator
> crystals) the 48khz doesnot match exactly and I see slip error
> in practice. Have you any idea how I can remedy it using a
> software PLL(is it logically possible)?
First, you might want to study the jitter buffer concept in VoIP -- that's
basically
a software PLL, assuming Ethernet as the underlying comm method.
Second, you can use async communication (e.g. RS-232) between your DSK 6713
boards,
as Richard suggested. There are some things you can do there to make sure the
two
systems stay in sync, basically amounting to allowing clock drift only for each
byte
transmitted.
Third, you can use a sync method between the boards, which can give you a far
higher
bandwidth than RS-232.
Let's say your analog sampling is using separate sampling clocks (that
could be audio
I/O, or in your case RF communication assuming baseband data), and they
communicate
with each other using a synchronous method (e.g. sync serial port, RS-422,
etc),
which is driven from separate clock (maybe same one that drives the DSP).
That's two
clocks, there could be more, but my point is there may be multiple causes of
clock
drift between the boards, so trying to monitor clock edges or other relative
techniques on one board, even if it can "see" the clock from the other board,
may
still become overly complex.
One way to deal with this is to introduce a bit of buffering in the sync
communication, let's say 4 buffers. For example the audio frame is 128
samples, and
sync comm buffers are 10 to 20 bytes (say after speech compression) . The ISR
code
watches these buffers and tries to keep the actual buffering at 2. If the number
of
buffers decreases or increases then the the code inserts one sample in the
incoming
audio frame or deletes one. This doesn't happen often assuming the clock
drift is
not dramatic -- from a percentage standpoint, maybe one out of 1000s of audio
samples
are affected -- so the effect on voice quality can be neglected. What this
amounts
to is adjusting the analog sampling rate clock, which is the least sensitive
clock in
the system to small changes.
Of course the tradeoff is latency; the extra sync comm buffers may be a problem.
The
same tradeoff exists in VoIP -- the jitter buffer gets too large and people
start to
notice. Limit the jitter buffer, then a packet gets dropped, and again people
notice.
-Jeff
Reply by Jeff Brower●January 30, 20092009-01-30
Mehrnaz-
> Actually, I am working in a project, implementing the
MODEM using
> DSP6713, and I hope I can gain your deftness in this case.
> After implementing the whole algorithm on DSK boards (using
> MATLAb simulink + Code composer) I encountered a problem.
> It seems all parts of model include 32 QAM, Timing recovery,
> Equalizer and carries recovery algorithms act well during
> simulation.However, after implementing it on two separate
> DSK boards(due to the small difference between oscillator
> crystals) the 48khz doesnot match exactly and I see slip error
> in practice. Have you any idea how I can remedy it using a
> software PLL(is it logically possible)?
First, you might want to study the jitter buffer concept in VoIP -- that's
basically
a software PLL, assuming Ethernet as the underlying comm method.
Second, you can use async communication (e.g. RS-232) between your DSK 6713
boards,
as Richard suggested. There are some things you can do there to make sure the
two
systems stay in sync, basically amounting to allowing clock drift only for each
byte
transmitted.
Third, you can use a sync method between the boards, which can give you a far
higher
bandwidth than RS-232.
Let's say your analog sampling is using separate sampling clocks (that
could be audio
I/O, or in your case RF communication assuming baseband data), and they
communicate
with each other using a synchronous method (e.g. sync serial port, RS-422,
etc),
which is driven from separate clock (maybe same one that drives the DSP).
That's two
clocks, there could be more, but my point is there may be multiple causes of
clock
drift between the boards, so trying to monitor clock edges or other relative
techniques on one board, even if it can "see" the clock from the other board,
may
still become overly complex.
One way to deal with this is to introduce a bit of buffering in the sync
communication, let's say 4 buffers. For example the audio frame is 128
samples, and
sync comm buffers are 10 to 20 bytes (say after speech compression). The ISR
code
watches these buffers and tries to keep the actual buffering at 2. If the
number of
buffers decreases or increases then the the code inserts one sample in the
incoming
audio frame or deletes one. This doesn't happen often assuming the clock
drift is
not dramatic -- from a percentage standpoint, maybe one out of 1000s of audio
samples
are affected -- so the effect on voice quality can be neglected. What this
amounts
to is adjusting the analog sampling rate clock, which is the least sensitive
clock in
the system to small changes.
Of course the tradeoff is latency; the extra sync comm buffers may be a problem.
The
same tradeoff exists in VoIP -- the jitter buffer gets too large and people
start to
notice. Limit the jitter buffer, then a packet gets dropped, and again
people
notice.
-Jeff
_____________________________________
Reply by Richard Williams●January 29, 20092009-01-29
ehranaz,
slip between different systems is normal.
There are several ways to re-align. Some of these are:
--use two stop bits
--limit the number of characters being transmitted in one sequence.
--pause at least one character time between messages, with the line in the
'high' state (1).
--force the line into the 'high' state for at least two bit times
before
transmitting the start bit (0).
--run a higher freq clock to the UART peripheral because ( peripheral clock /
baud rate ) determine how many samplings are made for each bit time. The
more
samplings the better.
--assure the rise/fall time of the edges of the bit transitions is well
within
the specs.
--use RS-485 rather than RS-232 protocol.
R. Williams
---------- Original Message -----------
From: Mehrnaz Hazrati
To: c...
Sent: Tue, 27 Jan 2009 06:17:27 -0800 (PST)
Subject: [c6x] implementing the software PLL
> Hello DSP experts !
>
> Actually, I am working in a project, implementing the MODEM using
> DSP6713, and I hope I can gain your deftness in this case. After
> implementing the whole algorithm on DSK boards (using MATLAb simulink
> + Code composer) I encountered a problem. It seems all parts of model
> include 32 QAM, Timing recovery, Equalizer and carries recovery
> algorithms act well during simulation.However, after implementing it
> on two separate DSK boards(due to the small difference between
> oscillator crystals) the 48khz doesnot match exactly and I see slip
> error in practice. Have you any idea how I can remedy it using a
> software PLL(is it logically possible)? Thanks for you attention Mehrnaz ------- End of Original Message -------
_____________________________________
Reply by Mehrnaz Hazrati●January 27, 20092009-01-27
Hello DSP experts !
Actually, I am working in a project, implementing the MODEM using DSP6713, and I
hope I can gain your deftness in this case.
After implementing the whole algorithm on DSK boards (using MATLAb simulink +
Code composer) I encountered a problem.
It seems all parts of model include 32 QAM, Timing recovery, Equalizer and
carries recovery algorithms act well during simulation.However, after
implementing it on two separate DSK boards(due to the small difference between
oscillator crystals)
the 48khz doesnot match exactly and I see slip error in practice.
Have you any idea how I can remedy it using a software PLL(is it logically
possible)?
Thanks for you attention
Mehrnaz