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. I will assume that you obtained your information from DViCO, which leads me to the next question: 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? 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) Thank you. -- Michael Krufky
