Hi Patrick, Did BBTI then tell you what can be the source of the interrupt failure or any other helpful comments? Although the data_receiver_error bit might not be the _root_ cause of the interrupt failure, it was always the case that we could read the data_receiver_error bit set after the interrupt-stop. Thus, it indicates the flexcop chipset is screwed up inside somehow. The interesting thing is I haven't seen any other error bits set including the ts_err bit after the interrupt-stop. On 5/11/05, Patrick Boettcher <patrick.boettcher@xxxxxxx> wrote: > Hi, > > On Wed, 11 May 2005, Q-ha Park wrote: > > recv_err denotes Receive_error_bit in 0x20c, and note that the number > > is way too high. No one in this list seems to know when this bit is > > set _precisely_. If we can get this information I'm sure we can get > > close to solving this problem or come up with a workaround at least. > > In the meantime I got information from BBTI about the Data_receiver_error: > > "The data_receiver_error bit indicates that the TS_ERR output pin from the > demodulator has gone high indicating a bad packet or sequence of packets. > This is similar but not the same as the transport_error bit which is set > based on the transport error indicator in the packet header, which is > usually set by the demodulator when it detects an error. > These may seem like identical functions, and essentially they are, however > some demodulators allow for the TS_ERR to be disabled or not connected." > > And they [..] "don't think this is the source of the interrupt failure". > > best regards, > Patrick. > > -- > Mail: patrick.boettcher@xxxxxxx > WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ > > _______________________________________________ > > linux-dvb@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > >
