Hi Brent, I have been working with HDMI for a while. It is not uncommon for us to observe emissions at 742.5 MHz or other multiples of the fundamental 74.25 MHz pixel frequency. (Whether they are high enough to be an EMC problem is a different story.) The HDMI data are transmitted using TMDS with 8b/10b encoding at 10 times 74.25 MHz. In fact, the whole chip operates at this frequency. So there are lots of opportunities for these frequencies to escape into the air. 1080p is 148.5 MHz and deep color and 4k are different in terms of frequencies but the problems are similar.
> My question is, is this inherent to HDMI, or to the 9777? As is probably obvious, I don’t have a whole lot of experience with HDMI video. Without knowing the details to be sure, I'd say it is not surprising that you are seeing these problems. We have seen these sort of things on all HDMI chips that we have work with. The difference is only in magnitude, and the board layouts and system configurations also have everything to do with the level of emission, if not more than the HDMI chip themselves. Metal enclosures that act as Faraday cage and common mode chokes on the HDMI cable are useful bandaid. I don't fully understand your descriptions below. > When used at any resolution below 4k, there seems to be a 10 dB emission “pedestal” that stands out of the baseline emission at several frequencies, 742 MHz in particular. Do you mean there are line spectrum at 742 MHz above the noise floor of the spectrum analyzer? (Are they all at exact multiples of 74.25 MHz?) > The pedestal is 666 usec long and repeats at whatever frame rate is selected. If I understood you correctly, the pedestal is a feature you observed in the spectrum. How do you give a spectrual feature a time measurement? Obviously I am missing something, unless you are doing a 2D/3D waterfall display of spectrum vs time plot. > At first, I thought it was correlated with the SPI bus activity, since the timing was identical, but further experiments show that not to be true. The HDMI signal is not unlike that of NTSC signal in some respects. There are line blanking and line sync signals that occur at the line frequency, which I recall is 2200 pixels. There are also frame syncs that occur at the frame frequency. There are also audio and other housekeeping signals that are stuff into various blanking intervals. All of these are at more or less fixed frequencies and show up in the spectrum as well. To definitively rule it in or out, you might pick up the HDMI video signal (through a loop coupler or even directly touching one of the TMDS data line) and add it to the antenna signal and see if they correlate well in the time domain, or the waterfall specturm display. Assuming 1080p, each line is 2200 pixels or 14.6 usec. So 666 usec is roughly 45 lines. My guess is this has something to do with either the frame control signals sent at frame frequency, or audio data being packed into blank area and there are more of them at frame boundary. Try sending different 2 channel PCM data or high bit rate bitstream audio and see if they make a difference in magnitude. Best Regards and Good Luck, Alfred On Sat, Oct 15, 2016 at 3:57 PM, Brent DeWitt <[email protected]> wrote: > I’ve been working with some Silicon Images (Lattice Semi) 9777 multiplexer > chips lately and would appreciate any insight list members might have. > When used at any resolution below 4k, there seems to be a 10 dB emission > “pedestal” that stands out of the baseline emission at several frequencies, > 742 MHz in particular. The pedestal is 666 usec long and repeats at > whatever frame rate is selected. At first, I thought it was correlated > with the SPI bus activity, since the timing was identical, but further > experiments show that not to be true. > > > > My question is, is this inherent to HDMI, or to the 9777? As is probably > obvious, I don’t have a whole lot of experience with HDMI video. > > > > Thanks all! > > > > Brent DeWitt, AB1LF > > Milford, MA > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> > Virus-free. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link> > - > ---------------------------------------------------------------- > > This message is from the IEEE Product Safety Engineering Society emc-pstc > discussion list. To post a message to the list, send your e-mail to < > [email protected]> > > All emc-pstc postings are archived and searchable on the web at: > http://www.ieee-pses.org/emc-pstc.html > > Attachments are not permitted but the IEEE PSES Online Communities site at > http://product-compliance.oc.ieee.org/ can be used for graphics (in > well-used formats), large files, etc. > > Website: http://www.ieee-pses.org/ > Instructions: http://www.ieee-pses.org/list.html (including how to > unsubscribe) <http://www.ieee-pses.org/list.html> > List rules: http://www.ieee-pses.org/listrules.html > > For help, send mail to the list administrators: > Scott Douglas <[email protected]> > Mike Cantwell <[email protected]> > > For policy questions, send mail to: > Jim Bacher <[email protected]> > David Heald <[email protected]> > - ---------------------------------------------------------------- This message is from the IEEE Product Safety Engineering Society emc-pstc discussion list. To post a message to the list, send your e-mail to <[email protected]> All emc-pstc postings are archived and searchable on the web at: http://www.ieee-pses.org/emc-pstc.html Attachments are not permitted but the IEEE PSES Online Communities site at http://product-compliance.oc.ieee.org/ can be used for graphics (in well-used formats), large files, etc. Website: http://www.ieee-pses.org/ Instructions: http://www.ieee-pses.org/list.html (including how to unsubscribe) List rules: http://www.ieee-pses.org/listrules.html For help, send mail to the list administrators: Scott Douglas <[email protected]> Mike Cantwell <[email protected]> For policy questions, send mail to: Jim Bacher: <[email protected]> David Heald: <[email protected]>
