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
_____________________________________
implementing the software PLL
Started by ●January 27, 2009
Reply by ●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 -------
_____________________________________
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 ●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
_____________________________________
> 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 ●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
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 ●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 -------
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 ●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 -------
_____________________________________
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 ●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
_____________________________________
> 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 ●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
_____________________________________
