Friday, 2 April 2010

Racking up

We have split each major sections into seperate racks, which can then be quickly assembled into the complete chain by patching between each rack.
This dual rack here is the distribution unit, which i have been working on.
On the left we have digital audio monitoring, bug burning, and wide screen signalling (WSS) insertors.
For Pres 1 (output for channel one) we are able to use a single Miranda EasyKey unit, to both key and burn the bug (Or DOG- Digital-On screen-Graphic) over the input video, before the WSS information is inserted.

However for pres 2, the EasyKey unit is not fully functioning. The work around that we use is to use the EasyKey to first key the bug, before a second simlar Oxtel unit burns the bug to the background video. Pres two also then has its WSS info added.

At the momment for testing we are using last years BUG's to test out system. However when the branding department come back to us with their designs for the this years channel BUG's we can then create the bug using the Mirinda software and then load the BUGs on the machines via their floppy card readers.



Tuesday, 2 March 2010

Recent Time





The system diagram of the section of the chain that i have been working on the last couple of days













MediaViews, WSS insertors and BUG burners.













The BUG or DOG (digital on screen graphic) is stored on these floppy disks.
We will have to contact the branding dept. to organize updating the bugs for this years logo.

Thursday, 26 November 2009

Restoring Divicom Encoders

Finally we got round to trying a complete re-installation of the control software on the Divicom server. Matt and Jamie saved and backed up all the configuration files, saved .ovm layout files and the TFTP boot files, before completing uninstall the HP Openview and other related software.

Then using the original restore disk did a complete reinstall of the software onto the machine.
Much to our surprise on rebooting the server, the encoders successfully managed to load and boot the file and the encoders are once again usable.

Now the next step will be to configure them and managed to generate ASI out of them.

Tuesday, 10 November 2009

More Divicom trouble shooting

After finding a spare Divicom server, for general interest we decided to see if we could have a go working with that one.

After connecting all up to CPU switcher, we turned on the power and......
its goes all the way through bios/boot etc.
then windows 2000 fails to start due to some major error.

Not deterred we swapped the SCSI drives from the working unit into and succeeded in booting this second unit correctly, it appears that that either the OS or that the original hard drives on the second unit have failed.

We also attempted another method, installing all the software onto a laptop from the divicom backup disk, and then configuring the software using the existing settings on the divicom and attempting to boot the encoders using the laptop.
However we ran into a fair share of problems, the HP Openview software installed corrected but the config/saved set-up was still on the Divicom and this is where problems began,
USB flash drive transfer it, not possible, Divicom has no USB ports.
CD-RW transfer, also not possible, Divicom has a CD drive but cannot write to disks
Floppy drive, not possible, files larger than 1.44mb
Access the server from the local network and tranfer file that way, no cannot access.

In the end we decided that this was more trouble than it would be worth.

Our next idea came from this though, as the 2 working sets of drives are mirrored in RAID 1. We can boot up 1 drive in each Divicom box, and then on one attempt to reinstall the the software one, and still have a backup, untouched system on the other.

Tuesday, 3 November 2009

Trouble shooting encoders

Right from the beginning, in trying to get this system work we have struggled to get our 5 DVB encoders to give us anything positive. Once powered up they attempt to load their firmwire from the divicom control compputer via a network and patchbay.
After POST (Power-on self-test) they get stuck in a loop trying to load this boot file to its DRAM.

At first we though that this was due to a networking error, and thus we traced all the routes the cables take from the encoders and added this to our system diagram.
However when we viewed the deamon boot logs on the Divicom control computer and comparing them to the MAC/IP numbers of the encoders, we could see that all the encoders could be detected on the network.
However they where all reporting "missing boot files"

From this we now think that the problem could be at the server end, specificatly one of the boot services "BGTFPT.exe" (background trivial file transfer protocol) not starting when the computer boots.
This protocol is what the system uses to the transfer the boot file from the server to the encoders.

We could possibly fix this by reinstalling the system or trying to reconfigure the service in question.

Sunday, 1 November 2009

A few recent pics



Pharos control unit and CPU switching unit



5x Divicom encoders



Patch panel and network hub for encoder control