Matt, as we discussed, let's start by swapping out cam 1. I believe Paula swapped 1 and 3 which apparently made little to no change. I don't think this is a control line problem, but will be the easiest to eliminate.

 
More trouble with ghost images in Moscow Ed 1 cameras. There was no trouble for an hour of class then the ghosting started. It went away when I powered up the cameras in this order: 2, 3, 1. Then ghosts came back after about half an hour. It apparently spontaneously cleared up again about an hour later. Engineers: any idea what is going on here?

 
Moscow Ed 1 and CdA 1 codecs are back on LAN.

 
Moscow Ed 103 codec and CdA1 codec have lost their LAN connections. I see that Ed 103 is now running E1.2 software. Is this correct for this codec?

 
I had the same trouble with Ed103 cameras 1 and 2 last week. Not only was I seeing a ghost of cam 1 in cam 2, I was seeing cam 2 ghosting in cam 1. And they were crawling from opposite directions! Power cycling resolved the trouble, as it did for Paula. Today, however, I could not clear the problem by turning the cams off and on. I tried turning them on in different orders but did not find a sequence that worked. I ran the class with camera 1 turned off. After class I turned Camera 1 on last (after 2 and 3 were already on) and the problem was gone.

 
Don, Remember the other day I was telling you about, the transparent image repeatedly rolling across the image of Camera 2? Well tonight it began doing that about 45 minutes into the class, I have it on VHS tape. This rolling image makes Camera 1's image really blurry. I have figured out that the rolling image is camera 2 in transparent form. The rolling is from right to left. At some time the rolling began on cam 1's blurry image. At the class break I turned cam 1 & 2 off and back on again. The problem stopped.
Paula

 
MCU took a massive hit of some kind today at 1322. Four of the sites in one conference as well as one of two in another dropped. IF was the first to disappear. IF was doing some testing with their portable unit at the time, connecting to the mcu.

 
Regarding TMS and CaSP 536: Wednesdays both CdA1 and B3 are in use for Law 975 immediately prior to CaSP 536, which also involves those rooms. Therefore the scheduled start time for 536 is 4:55. I'll shave a few more minutes off of 975 and see if I can get a 4:52 start time for CaSP 533 (starting next week in JEB). I manually added Boise to your class yesterday since TMS is not playing nicely with B3. Well, parts of TMS don't want to play anyway. The Graphical Monitor module in TMS can see B3 in a meeting just fine but if you flip back to the conference in the Conference Control Center it shows B3 as disconnected. TMS will not allow ISDN dialing from the MCU to B3 so I have been trying to have TMS fire B3 to dial in, but that hasn't been working.

 
TMS, CASP 536, at 5:50 the message Sched mtg in 5 min, at 4:55 sched mtg 1 min, at 4:56 connected, Ed 103 & Cda, at 4:59 Boise was connected. TMS says CASP 536 for 4:55.
TMS says ADED 577 connects at 4:50 and it did. Matt will you adjust the dial time for CASP 536 so we have a five minute lead time? Thanks! Paula

 
CdA2 troubles:
Participant in today's mcu conference in CdA2 reported her incoming audio became a screech or whine and she disconnected. When I reconnected her the problem cleared. Participant also reported multiple freezes. The received audio from CdA2 is about twice as hot as other sites. When CdA2 unmutes their mic their AGC pumps up mic audio to extreme levels and room noise becomes a major problem until there is some actual voice audio and the AGC resets. Point-to-point (Ag-CdA2) later in the day ran flawlessly.

 
The wireless instructor mic from CNR is now in Ed. There is no wireless mic in CNR.

 
The wireless instructor mic in Ed 103 is dead. I took it to engineers for repair.

 
Regarding operator support at CdA1--
Joe is doing a great job operating the camera in CdA.

 
Regarding operator support at Boise--
Erin left the B3 room unattended on the first day of class. The CaSP 536 students needed to unmute their mic but did not know how and disconnected themselves instead. They apparently did know enough to call Erin since she came into the room just after I got them reconnected. Then she left again. Boise accidentally disconnected themselves again later.

 
Regarding operator support at remote locations--
Today's research seminar had no operator in Twin Falls or Idaho Falls. Neither location had a decent cmera shot and I had to mute IF due to noise. Parma support was good, with a good camera shot and participants knowledgable in use of the mute button.

 
CdA2 today had a couple of 30 second freeze and a spontaneous disconnect from MCU. CdA participant reported audio cutting out and severe tiling.

I have disconnected the Iomega external CD-R drive from the CNR control room computer since it was not working properly and was generating annoying error messages. Will reinstall/reconnect at a later date.

 
Regarding Boise connectivity--
When I request system information for Boise 1 and 3 in TMS I get this message: Receive or Send method failed. The socket is not connected. This is odd since the rest of the connection seems okay: I can web into the codecs, etc. Might have to ask Tandberg what this means.

 
Still unable to reach the Twin Falls codec via TMS. It still returns a SNMP error. I talked to the network person at TF and he checked out the SNMP service to the codec IP using a 'SNMP walker' program. According to him SNMP traffic is going fine to the unit. I think the problem may be with TMS or the server that it is running on.