Transmission - Omneon

Even though we have been talking with Timeline about the possibility of getting an EVS from them to deal with playout I still felt that it would be use3ful to get the Omneon up and running as a backup. I connected the director to two media ports via firewire and then powered up the store. At this point I realised that I didn’t have the connector between the fibre channel connections on the Director and the 9 pin D-type connections on the store. After a fruitless search for this cable I emailed Omneon support using a link on their website.
 

 N-Store

Simon from Omneon support got back to me on the same day and has been incredibly useful helping to identify our system as a D1 (Director) with an NStore (Storage). However he also stated that “This is a very old unsupported system”, no surprises there, but it appeared that all we were missing was the connection cable which is hopefully being sent through as I write this.

 Director

Although we may not use the Omneon on the day we will certainly get the system up and running and ingest content onto it just to make sure that it still works. At the end of the day the EVS will have to be returned and while it is a viable work around I think we still need to be looking at re-integrating the Omneon with the Pharos control platform in the long term. Maybe this could be done next year as a side project integrating it with the mobile presentation racks.
 

Fibre Channel Connections

Transmission - Bug Burners

Over the past few weeks I have been involved in several smaller projects that I just haven't had the time to blog but I'll try and do all that in the next few days.

The first is the bug burners. After messing around with these a few weeks ago Jamie and I managed to get one Probel bug-burner keying and filling the old logo correctly while another one appeared to have troubles with it's SDI i/p and so we had to use it to generate the bug and then use a Microvideo bug-burner to key and fill (this was the only solution at the time because we couldn't figure out whether or not the Microvideos' had a way to store the image to be keyed).

I was still not happy with this situation so  couple of weeks ago I went back to the bug-burners and had another look. This started with a repeat of the original test which again proved that Channel 2's bug-burner wasn't working, so I disassembled the casing to take a look at the different cards inside. James Uren and I were able to isolate the fault down to the SDI i/p card, which was different on each bug-burner. After testing voltages over the card we began to further cut down the peripherals to a small pot on the card. Adjusting this proved to be the key as the background signal began to appear, I will openly admit however that we are still not sure what exactly this pot is for, we believe it to be some kind of i/p timing adjustment which would make sense.

After doing this I then began looking at how to get our new bugs being generated and keyed. I had previously been told that I would need to use the Mirada Animation tool on the Router PC to generate a different file-type (.oxt) but after several attempts at doing this and ending up with files that were far to large to fit on a floppy disk (1.44MB) I began looking for a user manual to see what I really needed.

As it happens the bug-burners will take TARGA (.tag) files, this can be either stored as a key or an image and must be named accordingly (imag.tga, key.tga). I got branding to create a white bug, correctly positioned on a 720 x 576pix black background which I then renamed as imag.tga and uploaded to the bug-burners. Thankfully it worked and the bug was keyed over the video, this can then be readjusted in terms of positioning and transparency but the basic idea was that it was working. The only problem now is that this bug has serious amounts of aliasing on it, which of course won't pass QC, that's another problem for another day though because at least the system is working!