ttocs
Global Moderator 
I always have a wonderful time, wherever I am, whomever I'm with. (Elwood P Dowd)
Posts: 8,166
|
Post by ttocs on Jun 14, 2018 15:33:11 GMT -5
I believe hdmi cables are associated enough with respect to possible compatibility issues with the V3 board.
I came up with a freak thing last night. I accidentally switched to a hdmi input on the XMC-1 that had nothing attached. When I switched back to HDMI-1 with TiVo attached, the output went from picture/no picture/picture/no picture but the audio was continuous. After about a minute of this entertainment I switched to an input that would output a picture, then went back to HDMI-1 and all was well again.
The point of this is weird things happen, and if less weird things occur when using tested pieces of equipment - like Emo's HDMI cables, then that's "One less thing" to have to deal with. (Forrest Gump)
|
|
|
|
Post by Jim on Jun 14, 2018 16:28:58 GMT -5
Gentleman, The bug list we published a few weeks back was entirely correct and has been resolved. What we didn't realize though was one of the bugs was actually masking a couple of others that have been very difficult to resolve. One in particular has eaten up 100% of our engineering resources for the past three weeks. We have one projector and one TV that when they are in Standby are throwing out garbage information down the line and causing the video board to lock up. The difficulty here is sifting through the garbage to determine when the TV/Projector is actually On or in standby and should be ignored. For those of you that don't know much about HDMI, let me just say that this behavior does not fall within accepted standards, but here we are, we have to deal with it because the manufacturers of the units aren't. Anyway, we are working night and day to get it resolved. Lonnie That sounds like a total PITA to diagnose and resolve! I hope that your transparency is acknowledged by people that want answers. I know it’s hard to wait - but I think it’s awesome that you’re willing the share the technical reason for the delay and the challenges that are faced behind the scenes in delivering a product like this to market. Without a doubt, it’s always easier said than done. Nice for geeks like me to see what’s really going on in the development process. |
|
|
|
Post by Casey Leedom on Jun 14, 2018 16:31:19 GMT -5
Actually it's likely to be both HDMI Peers and HDMI Cables. At least that's our experience in the High-Speed Ethernet business (currently using 25Gb/s per Lane and four Lanes to get 100Gb/s). Neglecting bad Peers which are violating the Logical portions of the Specification, below that is the Physical portion and things get very strange down there. Here's an example of the levels of detail: Sender: - I have Data Sequence {X} which I want to send down the "wire".
- The first thing I need to do is carve that up into reasonable sized units. And there are high-level Protocol-based units (say, Maximum Segment Size) and lower-level Physical medium-based units (say, Maximum Transfer Unit). The lower-level packetization is what concerns us at the Physical Layer. The higher-level segmentation will have been performed by Transport Layer Protocols.
- Because we're at the very hairy edge of what's possible to send on copper wires, we add Forward Error Control (FEC). Basically, much like a CD's contents, we use things like Reed-Solomon Coding in order to reconstruct a Packet on the Peer even if fairly significant damage occurs to it by the time it's received on the Peer.
- Once we have an FEC-encoded low-level Packet that we want to send, we need to make sure that there aren't too many 0s or 1s in a row. If there are, the Phase-Lock Loops of the Receiver's High-Speed Serializer/de-Serializer (HSS, or SERDEZ, or often PHY) won't be able to stay locked on our bits streaming off the wire. I.e. the receiver's PHY needs sufficiently frequent 0/1 and 1/0 edges in order to know that it's keeping its Clock locked onto the received bits stream.
- All of the above gets bit-streamed onto the wire using a reasonably accurate clock.
And note, I'm completely skipping all of the Hand Shake which would go on when you first plugged in an HDMI Cable. This includes not only the High-Definition Copy Protection (HDCP) that we're all so fond of, but also Device Characteristics information, and, I'm betting, a TX Equalization / Adapter Error Control Phase where the two Receivers communicate with the remote Transmitters to get them to adjust their Transmitter Coefficients. Receiver: - The first stage here is often something called Electronic Dispersion Control. Basically the beautiful Square Waves the Transmitter injected onto the "wire" is now a complete mess because different frequencies propagate down the wire at different speeds. There's a similar problem with Optical Fibre where different photons in a burst of photons will take different bouncing paths down the Fibre resulting in a Smeared Out signal at the Receiver. So we apply Signal Processing to try to reconstruct what the original signal might have looked like.
- Then comes the SERDEZ Phase-Locked Loop.
- Then the low-level packetization engine.
- Then we deal with errors ... and hopefully correction using FEC.
- Then we hand it on up to the upper-layer protocols.
And also note that I'm skipping about three layers in each of the above descriptions. Things at the Physical Layer are basically pure Black Magic. So yeah, cables matter because two Peers which might be able to communicate well with one HDMI cable won't be able to keep a Link up reliably with a different one. And yes, lots of major manufacturers of High-End Ethernet Switches mandate that their customers use cables from an approved list (often rebranded with significant mark up). My company isn't nearly large enough to mandate that our customers use particular cables, but we do test quite a few and we have a list of cables that have tested out well. We'll also resell you rebranded cables is you want a complete end-to-end solution. Casey |
|
|
|
Post by adaboy on Jun 14, 2018 17:44:39 GMT -5
Actually it's likely to be both HDMI Peers and HDMI Cables. At least that's our experience in the High-Speed Ethernet business (currently using 25Gb/s per Lane and four Lanes to get 100Gb/s). Neglecting bad Peers which are violating the Logical portions of the Specification, below that is the Physical portion and things get very strange down there. Here's an example of the levels of detail: Sender: - I have Data Sequence {X} which I want to send down the "wire".
- The first thing I need to do is carve that up into reasonable sized units. And there are high-level Protocol-based units (say, Maximum Segment Size) and lower-level Physical medium-based units (say, Maximum Transfer Unit). The lower-level packetization is what concerns us at the Physical Layer. The higher-level segmentation will have been performed by Transport Layer Protocols.
- Because we're at the very hairy edge of what's possible to send on copper wires, we add Forward Error Control (FEC). Basically, much like a CD's contents, we use things like Reed-Solomon Coding in order to reconstruct a Packet on the Peer even if fairly significant damage occurs to it by the time it's received on the Peer.
- Once we have an FEC-encoded low-level Packet that we want to send, we need to make sure that there aren't too many 0s or 1s in a row. If there are, the Phase-Lock Loops of the Receiver's High-Speed Serializer/de-Serializer (HSS, or SERDEZ, or often PHY) won't be able to stay locked on our bits streaming off the wire. I.e. the receiver's PHY needs sufficiently frequent 0/1 and 1/0 edges in order to know that it's keeping its Clock locked onto the received bits stream.
- All of the above gets bit-streamed onto the wire using a reasonably accurate clock.
And note, I'm completely skipping all of the Hand Shak which would go on when you first plugged in an HDMI Cable. This includes not only the High-Definition Copy Protection (HDCP) that we're all so fond of, but also Device Characteristics information, and, I'm betting, a TX Equalization / Adapter Error Control Phase where the two Receivers communicate with the remote Transmitters to get them to adjust their Transmitter Coefficients. Receiver: - The first stage here is often something called Electronic Dispersion Control. Basically the beautiful Square Waves the Transmitter injected onto the "wire" is now a complete mess because different frequencies propagate down the wire at different speeds. There's a similar problem with Optical Fibre where different photons in a burst of photons will take different bouncing paths down the Fibre resulting in a Smeared Out signal at the Receiver. So we apply Signal Processing to try to reconstruct what the original signal might have looked like.
- Then comes the SERDEZ Phase-Locked Loop.
- Then the low-level packetization engine.
- Then we deal with errors ... and hopefully correction using FEC.
- Then we hand it on up to the upper-layer protocols.
And also note that I'm skipping about three layers in each of the above descriptions. Things at the Physical Layer are basically pure Black Magic. So yeah, cables matter because two Peers which might be able to communicate well with one HDMI cable won't be able to keep a Link up reliably with a different one. And yes, lots of major manufacturers of High-End Ethernet Switches mandate that their customers use cables from an approved list (often rebranded with significant mark up). My company isn't nearly large enough to mandate that our customers use particular cables, but we do test quite a few and we have a list of cables that have tested out well. We'll also resell you rebranded cables is you want a complete end-to-end solution. Casey Cool information Casey! What do you think would be a better pipe? More copper, a mix of copper and fiber? Maybe multiple fibers with each sending different things? |
|
|
|
Post by liv2teach on Jun 14, 2018 17:53:03 GMT -5
Why does this thread keep getting drug off into the nether's all the time. Start a thread about HDMI and cables instead of plugging this one with a bunch of blither. I think we are all complained out and just laying around waiting for the V3.... However, if we're going to have an alternate conversation on here, let's make it something we can all understand.  |
|
|
|
Post by rbk123 on Jun 14, 2018 18:37:01 GMT -5
Gentleman, The bug list we published a few weeks back was entirely correct and has been resolved. What we didn't realize though was one of the bugs was actually masking a couple of others that have been very difficult to resolve. One in particular has eaten up 100% of our engineering resources for the past three weeks. We have one projector and one TV that when they are in Standby are throwing out garbage information down the line and causing the video board to lock up. The difficulty here is sifting through the garbage to determine when the TV/Projector is actually On or in standby and should be ignored. For those of you that don't know much about HDMI, let me just say that this behavior does not fall within accepted standards, but here we are, we have to deal with it because the manufacturers of the units aren't. Anyway, we are working night and day to get it resolved. Lonnie I hope that your transparency is acknowledged by people that want answers. I know it’s hard to wait - but I think it’s awesome that you’re willing the share the technical reason for the delay and the challenges that are faced behind the scenes in delivering a product like this to market. Without a doubt, it’s always easier said than done. This one and the prior email update from Sarah were definitely well done. Kudos. |
|
|
|
Post by Casey Leedom on Jun 14, 2018 19:25:01 GMT -5
[Cool information Casey! What do you think would be a better pipe? More copper, a mix of copper and fiber? Maybe multiple fibers with each sending different things? Optical definitely runs further. The problem is the cost of the High-Speed Optical Transceivers. For a QSFP28 4 x 25Gb/s Optical Transceiver you can expect to spend ~$200/Transceiver x 2 Transceivers/Link = ~$400/Link. A 4 x 10Gb/s Optical Transceiver will run ~$50/Transceiver x 2 Transceivers/Link = ~$80/Link. In contrast, Copper (sometimes referred to as Direct Attach Copper or TWINAX) can be as low as $25 for a 1m finished QSFP+ 40Gb/s cable, and a bit more than twice that for a 100Gb/s 1m finished QSFP28 cable. Now the Audio/Home Theater business could probably driver higher volumes and quite possibly driver the cost down for Optical Transceivers, but I think you can see the cost problem ... In the high-speed Ethernet business, Copper is generally the preferred solution in most Data Centers because of cost. This is one of the big reasons that Forward Error Correction was developed: to cope with the problems of these more problematic interconnects. Casey P.S. As Lonnie has mentioned, HD-BaseT is a nice compromise but man do high-speed 100baseT PHYs draw huge current! P.P.S. And in all ways, the connectors for high-speed Ethernet are miles better than HDMI's stupid connectors. |
|
|
|
Post by socketman on Jun 14, 2018 21:21:39 GMT -5
Anyone here have a pic of the back of the Gen 3 XMC1. I am making my XLR cables need to see the layout.
|
|
|
|
Post by novisnick on Jun 14, 2018 21:26:33 GMT -5
Anyone here have a pic of the back of the Gen 3 XMC1. I am making my XLR cables need to see the layout.
|
|
|
|
Post by socketman on Jun 14, 2018 21:41:17 GMT -5
Anyone here have a pic of the back of the Gen 3 XMC1. I am making my XLR cables need to see the layout.
Thank you sir. Hopefully this will be available by the fall . |
|
|
|
Post by novisnick on Jun 14, 2018 21:43:37 GMT -5
Full service forum my friend! 😁
Thank you sir. Hopefully this will be available by the fall . 🤞 |
|
|
|
Post by novisnick on Jun 14, 2018 22:05:13 GMT -5
Hopefully ready by the fall. Pray its ready by July !!! Im thinking end of year unfortunately. 😢 |
|
|
|
Post by socketman on Jun 14, 2018 22:10:21 GMT -5
I dont think that's a reasonable expectation given everything that has transpired and how many products they are trying to release all around the same time.
|
|
|
|
Post by wilburthegoose on Jun 15, 2018 7:05:50 GMT -5
Being a software company can be a helluva lot more different than being a hardware company.
|
|
richb
Sensei
Oppo Beta Group - Audioholics Reviewer
Posts: 890
|
Post by richb on Jun 15, 2018 7:23:15 GMT -5
Being a software company can be a helluva lot more different than being a hardware company. All CE companies are software companies. - Rich |
|
|
|
Post by jiriza84641 on Jun 15, 2018 10:33:39 GMT -5
Thank you sir. Hopefully this will be available by the fall . 🤞 I'm liking the XMC-1, only thing I will need is a splitter for the HDMI monitor 2 for my setup in basement (3 tvs total). Then I can run something to stream to my patio for a zone 2. |
|
|
|
Post by jiriza84641 on Jun 15, 2018 10:34:42 GMT -5
Anyone here have a pic of the back of the Gen 3 XMC1. I am making my XLR cables need to see the layout. Let me know whats your total cost to make the cables. I was thinking the same thing. |
|
Lonnie
Emo Staff
admin
Pay no attention to the man behind the curtain
Posts: 6,999
|
Post by Lonnie on Jun 15, 2018 14:01:49 GMT -5
Quick update here.
The V3 code is done, vetted, approved for release.
Production is updating the XMC's that are in house as well as preparing the self install kits for shipping on Monday or Tuesday of next week.
Have a great weekend everyone.
Lonnie
|
|
|
|
Post by Casey Leedom on Jun 15, 2018 14:10:10 GMT -5
Woo Hoo!! That's one step closer to the XMC-1 Gen3 and the RMC-1 as well!!
Casey
|
|
|
|
Post by musicfan on Jun 15, 2018 14:11:23 GMT -5
Woo Hoo!! That's one step closer to the XMC-1 Gen3 and the RMC-1 as well!! Casey Bingo!!! |
|
