On Wed, 25 Sep 2013 01:36:13 -0400, rickman <gnuarm@gmail.com> wrote:>On 9/24/2013 3:18 PM, p wrote: >>> That could be tough. I did a design similar to this in an FPGA. It >>> received a simple bit stream and had to sync to the transitions. But >>> it had a timing setting to establish the base frequency approximately. >>> >>> This design used a locked loop to adjust the NCO to the bit rate. >>> Since the base frequency was set by the user the search mode is not >>> overly aggressive. In your case you might need to use a rather >>> aggressive search mode to set the base frequency very quickly, or even >>> do a frequency measurement for a direct setting. >>> >>> Do you have a spec on the data stream format you will need to sync to? >> >> S/PDIF. >> >>> As others have indicated, there should be a preamble which would be a >>> stream of bits which produce a single transition in the Manchester >>> encoded stream. Knowing the length of this preamble will give you an >>> idea of how quickly your circuit will need to adapt to the data >>> frequency and lock up to the data stream. >> >> Lost of first bits is no problem. > >So what is the problem exactly? Do you not know where to begin? The >patent shows one way of doing it. There are other ways of cooking the >goose. Do you understand the separate functions that are needed? Clock >rate detection, bit synchronization, data extraction?Good questions. A quick tutorial would be most helpful to the OP... I'd sure like to see it myself. ...Jim Thompson -- | James E.Thompson | mens | | Analog Innovations | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | San Tan Valley, AZ 85142 Skype: Contacts Only | | | Voice:(480)460-2350 Fax: Available upon request | Brass Rat | | E-mail Icon at http://www.analog-innovations.com | 1962 | I love to cook with wine. Sometimes I even put it in the food.
differential Manchester decoder and FIFO
Started by ●September 22, 2013
Reply by ●September 25, 20132013-09-25
Reply by ●September 25, 20132013-09-25
** snipped so aioe will accept **>>> Lost of first bits is no problem. >> >> So what is the problem exactly? Do you not know where to begin? The >> patent shows one way of doing it. There are other ways of cooking the >> goose. Do you understand the separate functions that are needed? Clock >> rate detection, bit synchronization, data extraction? > > Good questions. A quick tutorial would be most helpful to the OP... > I'd sure like to see it myself. > > ...Jim ThompsonReminds me of when, 30+ years ago, i designed a serial data coding system that would allow variable data rate, totally self-clocking. I think it was as good or better than MFM. The idea of that was ability to achieve constant bit density on a hard drive.
Reply by ●September 26, 20132013-09-26
On Tue, 24 Sep 2013 21:18:21 +0200, p <1@2.3> wrote:>> Do you have a spec on the data stream format you will need to sync to? > >S/PDIF.The maximum supported data rate for SPDIF is about 6 Mbit/s, so from where did you get that 10 MHz requirement ? So even if you have two transitions (half cycles) within a single bit time, the frequency is still 6 MHz. In SPDIF, the serial bit clock (after dividing down) is typically used for driving the DAC, which requires a jitter free timing. After initially sensing the bit rate from a large range, you need a narrow bandwidth PLL to maintain the rate as constant as possible.
Reply by ●September 26, 20132013-09-26
On 9/25/2013 1:18 PM, Robert Baer wrote:> ** snipped so aioe will accept ** > >>>> Lost of first bits is no problem. >>> >>> So what is the problem exactly? Do you not know where to begin? The >>> patent shows one way of doing it. There are other ways of cooking the >>> goose. Do you understand the separate functions that are needed? Clock >>> rate detection, bit synchronization, data extraction? >> >> Good questions. A quick tutorial would be most helpful to the OP... >> I'd sure like to see it myself. >> >> ...Jim Thompson > > Reminds me of when, 30+ years ago, i designed a serial data coding > system that would allow variable data rate, totally self-clocking. > I think it was as good or better than MFM. > The idea of that was ability to achieve constant bit density on a hard > drive.Why variable data rate, or do you mean "slightly" variable? The OP's requirement is for the clock rate to vary over 1 MHz to 10 MHz. That's a bit of a stretch. -- Rick
Reply by ●September 26, 20132013-09-26
On 9/26/2013 12:40 AM, upsidedown@downunder.com wrote:> On Tue, 24 Sep 2013 21:18:21 +0200, p<1@2.3> wrote: > >>> Do you have a spec on the data stream format you will need to sync to? >> >> S/PDIF. > > The maximum supported data rate for SPDIF is about 6 Mbit/s, so from > where did you get that 10 MHz requirement ? So even if you have two > transitions (half cycles) within a single bit time, the frequency is > still 6 MHz. > > In SPDIF, the serial bit clock (after dividing down) is typically > used for driving the DAC, which requires a jitter free timing. After > initially sensing the bit rate from a large range, you need a narrow > bandwidth PLL to maintain the rate as constant as possible.Yes, as I read more of this thread I realize this is almost exactly what I implemented in an FPGA a few years ago as part of a design still in production. At one end is a data link and an ADC which samples a time code signal. The data link has no clock, but rather an approximate rate is set by the software and the hardware slave to the data transitions. The CODEC is slaved to the data rate. The aggregate data bundle (fixed number of data bits and the CODEC sample) is shipped over an IP network where at the other end another copy of this unit receives the data and reconstitutes both the data stream and the time code signal in synchrony. This requires syncing up to the average data rate of the IP packets and clocking the CODEC in lock step with clocking the data. IIRC, the loop lock was actually regulated by the amount of data in the FIFO. The FIFO delay had to match the delay of the sigma-delta CODEC. The receiver half of this should be *very* much like what the OP wants to do. -- Rick
Reply by ●September 26, 20132013-09-26
On Thu, 26 Sep 2013 10:22:47 -0400, rickman <gnuarm@gmail.com> wrote:>On 9/25/2013 1:18 PM, Robert Baer wrote: >> ** snipped so aioe will accept ** >> >>>>> Lost of first bits is no problem. >>>> >>>> So what is the problem exactly? Do you not know where to begin? The >>>> patent shows one way of doing it. There are other ways of cooking the >>>> goose. Do you understand the separate functions that are needed? Clock >>>> rate detection, bit synchronization, data extraction? >>> >>> Good questions. A quick tutorial would be most helpful to the OP... >>> I'd sure like to see it myself. >>> >>> ...Jim Thompson >> >> Reminds me of when, 30+ years ago, i designed a serial data coding >> system that would allow variable data rate, totally self-clocking. >> I think it was as good or better than MFM. >> The idea of that was ability to achieve constant bit density on a hard >> drive. > >Why variable data rate, or do you mean "slightly" variable? The OP's >requirement is for the clock rate to vary over 1 MHz to 10 MHz. That's >a bit of a stretch.I remember doing a wide range PLL, I think it was for Commodore, back when they had a design center in Mesa, AZ... pushing things, they wanted equal physical bit density on the platter, thus each track data rate was a function of radius (at constant RPM). But I think it was only 3:1. Fun place Commodore, the floor was littered with peanut and sunflower shells ;-) ...Jim Thompson -- | James E.Thompson | mens | | Analog Innovations | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | San Tan Valley, AZ 85142 Skype: Contacts Only | | | Voice:(480)460-2350 Fax: Available upon request | Brass Rat | | E-mail Icon at http://www.analog-innovations.com | 1962 | I love to cook with wine. Sometimes I even put it in the food.
Reply by ●September 26, 20132013-09-26
rickman wrote:> On 9/25/2013 1:18 PM, Robert Baer wrote: >> ** snipped so aioe will accept ** >> >>>>> Lost of first bits is no problem. >>>> >>>> So what is the problem exactly? Do you not know where to begin? The >>>> patent shows one way of doing it. There are other ways of cooking the >>>> goose. Do you understand the separate functions that are needed? Clock >>>> rate detection, bit synchronization, data extraction? >>> >>> Good questions. A quick tutorial would be most helpful to the OP... >>> I'd sure like to see it myself. >>> >>> ...Jim Thompson >> >> Reminds me of when, 30+ years ago, i designed a serial data coding >> system that would allow variable data rate, totally self-clocking. >> I think it was as good or better than MFM. >> The idea of that was ability to achieve constant bit density on a hard >> drive. > > Why variable data rate, or do you mean "slightly" variable? The OP's > requirement is for the clock rate to vary over 1 MHz to 10 MHz. That's a > bit of a stretch. >I did not mean or imply or say anything about "slightly variable". The scheme was equally robust from data rates of millihertz to gigahertz. And i think a number of the intelligent individuals on this NG could dream up such a scheme.
Reply by ●September 27, 20132013-09-27
> The maximum supported data rate for SPDIF is about 6 Mbit/s, so from > where did you get that 10 MHz requirement ?Forgive me.> So even if you have two > transitions (half cycles) within a single bit time, the frequency is > still 6 MHz. > > In SPDIF, the serial bit clock (after dividing down) is typically > used for driving the DAC, which requires a jitter free timing. After > initially sensing the bit rate from a large range, you need a narrow > bandwidth PLL to maintain the rate as constant as possible. >
Reply by ●September 27, 20132013-09-27
> Try this link to the issued patent... > > <http://free.patentfetcher.com/Patent-Fetcher.php?submit=Fetch&PN=5889820> > > A digital implementation similar in concept to my analog posting. > > ...Jim ThompsonThank you. I'll try to figure it out.
