Jump to content
Dataton Forum

bgillette

Moderator
  • Content Count

    7
  • Joined

  • Last visited

About bgillette

  • Rank

Profile Information

  • Gender
    Male
  • Location
    New York, USA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi Percival, I did a quick test of some 1080 DXV content with WATCHOUT 6.4 and have found limited functionality when QuickTime 7.7.9 was installed on the production PC. Since WATCHOUT does not directly support DXV, we cannot guarantee portability of DXV content from system to system, so what works on your systems may not work for others. Our recommendation at this time, would be to re-encode DXV content for a supported codec, such as HAP or h264 or another supported Watchout codec.
  2. (Minor Disclosure: I work for a display systems manufacturer) While I can’t speak for Dataton and their plans for WATCHOUT, I would think this would require strong participation from a GPU vendor in order to design an HDBASET output card to implement natively in a Watchout computer or Watchpax. So far, the major GPU vendors seem to be focusing on DisplayPort and HDMI technologies. Perhaps this will change if HDBASET gains wider acceptance. Right now, several display and projector manufacturers are implementing native HDBASET inputs…I happen to work for one of them :-) And it works very reliably. For example, check out the Barco RLM-W14 3-chip and Barco F50 single-chip projectors which both natively accept HDBASET without any receiver boxes. To the projectors, the HDBASET is just a regular input. Otherwise, in general, I think Watchout would work fine with most of the HDBASET transceiver kits today. The usual PC/GPU issues (ie not WATCHOUT) with HDCP and EDID management still apply, but when properly implemented, HDBASET transceivers kits should be fairly transparent in the signal path. HDBASET has been primarily a ‘transport’ and 'endpoint' infrastructure technology thus far, so most use-cases have been with HDBASET matrix switches and large deployments where the cost of thousands of meters of HDMI/DVI or fiber gets costly as you start running it through a building. I personally have completed several Watchout projects using HDBASET. For example, at InfoComm 2015 in Orlando, I used Crestron HD-TX3-C HDBASET transmitters with my own WO6 rig to bring WQXGA 2560x1600/60Hz, at 10-bit up to a simple blend of 3x Barco F50 projectors which have a native HDBASET inputs. HDBASET It isn’t quite right for every project, and like many technologies, the devil is in the details… Over one line, HDBASET can carry uncompressed HDMI/DVI, HDCP encryption, EDID, CEC channels, even serial and IR along with 10/100 Ethernet…Reliable video, EDID and HDCP are one thing, but getting all those other features to work together, is today, very much vendor dependent, but surely improving all the time. I can say from working several projects that HDBASET has gotten very good, but reliability depends heavily on quality cable and most of all, good RJ-45 terminations. For live events, I would always suggest using shielded CAT6 cables even though most manufacturers say they require only UTP CAT5e...People tend not to consider their RJ-45 cable seriously, but with HDBASET keep in mind you are shoveling up to 8GB/s of uncompressed HD or higher video over a set of wires that was basically designed to make phone calls 100 years ago. So cable and terminations do matter. As we enter the era of UHD and 4K and more, note that some of the current HDBASET transceiver solutions begin to subsample at UHD and 4K progressive at 24/30/60 frame rates to 4:2:0 colour and/or limit 8-bit colour which may affect blend zones, so read the specs carefully if you are getting into UHD/4K. Again, these minor limitations will improve with time. I'm interested if others have used HDBASET kit in their WATCHOUT deployments and what kind of success or challenges have been seen.
  3. Hi Torbjørn, as Jonas mentioned Barco RLM-series projectors have a limit of two simultaneous, open TCP connections. This is a LAN chipset limitation. When more than two TCP connections are opened to the projector, the third attempted connection will be refused by the RLM. In Watchout, this results in the connection error message you see. If you are using a secondary control application, such as the Barco Projector Toolset simultaneously, this may eventually cause your recurring and seemingly random issue. Here is why this occurs with the combination of RLM-projector and Watchout: By using the Wireshark analysis tool and some previous knowledge gained here on the excellent Dataton Forum, I have observed that Watchout will close the open TCP port at exactly 60-seconds after the last command is transmitted from Watchout to the RLM. The next time a command is sent, Watchout re-establishes the connection successfully, if there are less than two connections to the projector. Mostly I think this 60-second port hold is a good idea and I would guess is used for housekeeping purposes due to the random-access nature of a timeline based tool such as Watchout. IE Watchout cannot predict when and where a timeline might jump to and is always trying to ensure every command gets sent instantly and does not want to keep a port open forever, so it is closed after 60-seconds of idle time. The RLM will maintain a TCP connection until power-cycled, it will not itself close the TCP port unless powered-down, as best I can tell. This behaviour of the RLM projector is correct, in my opinion, because the projector operates as a client/server model, so the RLM expects the controlling device (Watchout) to have good behaviour and manage the port state as it sees fit. A note for Mike Fahl, I do notice when a TCP port is closed by Watchout, Wireshark shows it as a port ‘RST' (reset). I am not fully knowledgeable on this, but an RST appears to be a somewhat non-standard way to close the port. Terminal applications I have available to me (I tried MS Hyperterminal, PuTTy, Crestron Viewport and the Apple command-line Telnet client) will all maintain the TCP connection under normal circumstances until closed. When the socket is closed by the terminal Wireshark will show a disconnect as a "FIN,ACK" exchange and seems happy. It is only with Watchout the RST occurs. I am not certain, or if this is bad behaviour. In any case, there cannot be more than two simultaneous TCP connections to the RLM. In my testing, I have sent lots commands simultaneously by making numerous calls by creating several looping Aux Timelines, and although I could get the projector to buffer commands into oblivion, I could not get the error message unless I opened the 43680 port from another application or device such as Toolset. The best solution I can suggest is to avoid running Toolset or accessing the projectors at the same time as Watchout.
  4. I think the problem is that the FaceTime protocol is Apple proprietary. Possible workaround: i have used a software app for PC and Mac called 'Airserver'. http://www.airserver.com. This allows your computer to receive from AirPlay (and Miracast for Android) devices. Your mobile device sees the PC as an AirPlay or Miracast receiver and will send a perfect stream of everything shown on your iDevice/Android screen. Then use the Live Video Media type to bring your PC desktop into the Watchout stage via VNC. This requires no hardware capture gear, just purchase of Airserver.
  5. (disclosure: I work at Barco...I also feel your pain! ) Agreed, the 'classic' Barco protocol is going on 20+ years, it is definitely showing its' age. Having now worked for several projector manufacturers in my career, I admittedly get to see a little bit more under the hood and frankly it is quite a marvel to see how well the multiple embedded systems found inside a typical projector work together. There are a lot of things going on inside these projectors and they generally don't all speak the same language. The good news with the HDX is that anything that can be done in the OSD can generally be accomplished via protocol. The bad news is that the classic Barco protocol is very 'bare-metal' and the protocol document currently lacks command examples and responses to make it more bearable for control system programmers (be glad you dont need to extract lamp hours for a touchpanel, it is quite an exercise in ninja programming-fu to do something that should be easy and common! ) All that being said, there are efforts underway to improve the readability of the protocol document and adding more examples of commands and responses in order to make the protocol a bit more friendly to we mere mortal humans. To help with the modulo checksum: A commonly overlooked tool for working with hex-based control protocols is the good-old Windows Calculator in Windows 7! (not sure about 8). I use this all the time to help me when I am working with control systems and programming tools. By starting up Windows Calculator and navigating to: View > Programmer (or Alt + 3) you see you can easily flip back and forth between hex and decimal notation! So for those of us that aren't computers we can easily calculate checksums. In hex mode, use the hex numbers in your command to add up the checksum. Then, for the modulo checksum, take the result and press 'mod' and 100 and then = to confirm you have the right result. Hope this helps. -Bill Gillette
  6. There is an old Windows-based standalone control application available from the Barco/Folsom public FTP archive... ftp://ftp.folsom.com/Image%20Processing/MatrixPRO-8x8-DVI/ You may want to try this application out as a confirmation to test connectivity from your production PC to ensure you can control the MatrixPro. I believe the application also has a command window you can use to sniff out the commands to see the structure. The application may also be useful for you to set up presets with this application, as suggested by Walter, and then use those simple Preset commands to control the switcher rather than trying to build complete Input/Output salvos in Watchout.
  7. There are several reports of something like this happening with Panasonic projectors, the usual way to resolve is switch over to the PJLink protocol. Ive been thinking about what has been reported here over the years, and then looked at some of the forums at other media server and control system manufacturers for similar issues and have some thoughts about why this occurs: Watchout doesn't monitor what is happening on the port other than manage the connection, because Watchout is NOT a control system. Mostly this is a good thing, let Watchout be good at what it does. Use other tools when required. Watchout is built for efficiency and speed...It gets the connection established and sends the command as fast as possible. (Otherwise, we'd be complaining about latency) Watchout doesn't show the response from the controlled device, however it does provide feedback in the Messages Window if the connection is not successful. Watchout simply manages the port connection, and when that is successful, it sends the string in the cue. With these points in mind, I believe the problem here lies with the way the Panasonic protocol functions: When TCP port 1024 is established, the Panasonic opens the port and responds with some text: "NTControl 0/x0d" Presumably this is because Panasonic defines two methods of connection, 'protect' and 'non-protect' and the Panasonic is letting the controller know which mode it currently is working in because the protocol is different for each mode. Although this response is documented by Panasonic in the protocol, it does break the typical 'challenge/response' nature of most control protocols. That is, the controlled device should only 'speak after spoken to'. The moment the port is opened, instead of waiting for a command to be sent in, the Panasonic is busy figuring out the status of the projector, and outputting text to the port. This is a response not requested by the controller (Watchout). Watchout ignores this anyway, but it does mean the projector is likely not ready to receive commands when the port is opened. So, given the round-robin nature of the failure mode, documented here and around the web, this is what I think is happening: Watchout attempts to connect to port 1024. Connection is opened successfully. Panasonic projector responds with "NTCONTROL 0\x0D"... ...Watchout simultaneously sends out the command for the first time which is only partially received by projector because it is 'busy' No action occurs because command is received by projector as a partial string so it sits in the projector buffer waiting for a proper terminator in order to begin processing... ...Connection remains Open Watchout sends complete command second time. The projector interprets this as received with bad characters because part of previous command is already partially in buffer. Command fails with Undeliverable Error, waits for another command... The projector buffer is now empty because a complete challenge/response cycle has completed... ...Connection remains Open Watchout Sends complete command third time. Command Completes without an error. My guess is that if you use Wireshark or some other ethernet sniffing tool, you will see an "ERR3" and "ERR5" returned from the Panasonic when the command is sent three times. Things to try: 1) Prepend and/or append your command with a padding of a few $OD 's to flush the projector command buffer and give the Panasonic some time to prepare for receiving commands. 2) Use TWO cues, separated by .5 seconds (try varying this) First Cue, Open port send one or more $0D strings Second Cue, send actual shutter command Bill Gillette
×
×
  • Create New...