On Tuesday 05 July 2005 01:30 pm, Michael Krufky wrote: > Mac Michaels wrote: > >This is going to take a bit of explanation. Short answer > > - I am correct and it seems to work anyway. > > > >There are two control registers that control the > > detection of start of packet (SOP) - TS_HW_SOP_CNTRL > > and TS_SOP_STAT. Both of these registers are documented > > in the CX23880 data sheet. > > > >cx_write(TS_HW_SOP_CNTRL,47<<16|188<<4|0x00); > > > >is interpreted as Packet start byte value is 47, Packet > > length is 188, 0 start bytes must be received before > > declaring the packet stream in sync. Logic indicates > > that if 0 start bytes must be received then the value > > of the start byte does not matter. It is in sync all > > the time. This is a bug and should be fixed. > > > >Changing the line to: > > > >cx_write(TS_HW_SOP_CNTRL,47<<16|188<<4|0x01); > > > >will appear to work since somewhere in a small number of > > packets it is likely that the decimal 47 will appear. > > It does not need to be the first byte. I only needs to > > appear once to have the stream declared in sync. Actual > > start of packet is done by another hardware signal. > > > >How does this get in sync? That is where TS_SOP_STAT is > > used. > > > >cx_write(TS_SOP_STAT, 0<<16 | 0<<14 | 1<<13 | 0<<12); > > > >Bit 16 selects active high polarity. Bits 15,14 select > > SOP detects rising edge of TSSCP input, BIT 13 selects > > width of SOP as byte in serial mode (FusionHDTV 3 Gold > > uses serial mode), Bit 12 was used when I was > > experimenting and may be removed as the default is 0. > > This code does not need to be changed in the driver. > > > >An interesting option for bits 15,14 is 3. This uses the > > Packet start byte value set in the TS_HW_SOP_CNTRL > > register to locate the start of a packet. This is > > intended for hardware that does not have connection to > > TSSOP or TSVALERR suitable for detecting the start of a > > packet. It is interesting for testing the value of the > > SOP byte value. > > > >Here are two variations I tried: > > > >cx_write(TS_HW_SOP_CNTRL,47<<16|188<<4|0x01); > >cx_write(TS_SOP_STAT, 0<<16 | 3<<14 | 1<<13 | 0<<12); > >Result: no packets detected. > > > >cx_write(TS_HW_SOP_CNTRL,0x47<<16|188<<4|0x01); > >cx_write(TS_SOP_STAT, 0<<16 | 3<<14 | 1<<13 | 0<<12); > >Result: packets detected and normal operation of mythtv. > > > >If you can verify that the other frontends use the > > normal default value for the packet start byte, you > > could do this: > > > >- > > cx_write(TS_HW_SOP_CNTRL,47<<16|188<<4|0x00); + > > cx_write(TS_HW_SOP_CNTRL,0x47<<16|188<<4|0x01); > > Mac- > > cx88 datasheet says that 47d is the correct start byte. > Originaly Mauro and I thought that you may have either > (a) misread the datasheet, or that maybe (b) the cx88 > people made a mistake on the datasheet, and should have > instead indicated 0x47 as the start byte. Hmm - what is the date on your data sheet? Mine is August 08/26/2002. Figures 2-36 and 2-37 on page 2-80 show the start byte as 0x47 twice on each of the timing diagrams. The HW SOP Control on page 6-99 lists it as d47. The CX23880 default value is not consistent :-( > I will assume > that you obtained your information from DViCO, which > leads me to the next question: I also saw that the recommended value is 0x47 is some ATSC specification that I read. I do not recall what document that was. > Perhaps the datasheet is correct, and you are also > correct. This would mean to keep the current setting for > other boards, and follow your advice for the fusionhdtv3 > gold boards. In this case, are you telling me that for > the lgdt3302 frontend, that the start byte is 0x47 > instead of 47d, as previously defined? Maybe lgdt > properties are different from other frontends? My test proves that lgdt3302 uses 0x47 as the start byte value. I can not speak for other boards as the start byte is not a part of the transmitted data stream. The start byte is inserted under control of the frontend hardware. > If this is the case, then I will try to revise cx88-mpeg > such that it will test for (frontend==lgdt3302) instead > of (core->board == CX88_BOARD_DVICO_FUSIONHDTV_3_GOLD) > ... this would probably be more appropriate, although we > may have to stick with the board condition, as I dont > think cx88-mpeg has access to the frontend name ... I'll > have to look that up. > > Is there anything on the lgdt3302 to support this? (i > understand that you cannot show me, so I am asking you to > look this up) Yes. "The data segment sync is set to 47H." This sentence appears in both VSB and QAM sections. There is no reference to a decimal value of 47 anywhere. > Thank you. Also important to note is that the code as it was originally written before lgdt3302 was added does not actually use the value of the start byte. The 0 value in the start byte count causes the value of the start byte to be ignored. -- Mac
