EVENT LOG FOR SITE WEA Most recent activity to be listed first. First line of each entry lists date, time and who is reporting. Subsequent lines of each entry aligned under Time column. Do not use tabs, only spaces. Date Time Who What ---------- ----- -------- ----------------------------------------------- 12/04/2002 13:38 acarson@ Wells West adult ladder will be de-watered from Dec 2, to Dec 31, for maintenance and inspection. This will affect coils 05-08. . 11/05/2002 14:06 acarson@ 01:LowExcCurrent: Mike Bruno with DCPUD informed me the dates coincide with the operators log for dewatering operations for cleaning the fish view windows. . 11/01/2002 17:07 acarson@ 01:LowExcCurrent: Coils 01-04 excessive noise levels occured 10/30/02 from 13:01:18 to 13:25:18. Coils 05-08 excessive noise levels occured from 7:42:50 to 8:38:50. I will forward this information to DCPUD. . 10/10/2002 09:07 Dave Responded to persistent notices of missing data files. PcA'd into WEA- PC1. Found message "Waiting for host to acknowledge file transfer" on status bar. Manually uploaded one outstanding data file. Returned to log panel; status message was unchanged. Stopped and restarted data collection. This action cleared the status bar, and logged the message "Error Downloading Ack File #20302-Interrupted". 10/04/2002 12:31 Darren_C With the assistance of Wells personnel we found that PC1 was locked up with the "blue screen of death" and was restarted but we were still unable to PCA into PC2. Site personnel confirmed that minimon was running but that the computer may have been locked up. The PC was rebooted and in doing so the file 02277.b (6:00-11:25) was lost. I have sent the files into ptagis for filling the holes up to now. We do not have a direct cause for both PC's locking up at the same time. 08/19/2002 10:07 acarson@ 01:LowExcCurrent: Noise reports indicate an increase in levels from 35% - 75% on all coils: Westside coils 01-04 between 9:22:23 - 10:10:23, and Eastside coils 05-08 between 8:26:20 - 9:54:20. I will look at closer with DCPUD personnel. . 07/30/2002 12:05 acarson@ 01:LowExcCurrent: Low Exc Current acknowledged. . 07/30/2002 11:59 acarson@ 01:ExcessiveNoise,02:ExcessiveNoise,03:ExcessiveNoise,05:ExcessiveNoise,06 :ExcessiveNoise,07:ExcessiveNoise: Noise levels and Low current alarm that occurred on 7/26/02 9:04:57 - 9:31:32 may have been from a power outage on the Eastside ladder effecting coils 01 - 04. I'm in the process of determining this with DCPUD personnel. Noise data show a dramatic increase, up to 100%, on all coils for approximately 30 mins. then back to normal operating levels. Levels have been steady since. I will also check on the Westside noise spikes that seem to be occurring at the same time but different days. . 07/23/2002 12:14 Anthony 7/5/02 I was informed of missing files from Dave Marvin that occurred 7/3/02. We discussed minimon, UPS units, and possible solutions to the missing file issues. Contacted Mike Bruno with Douglas Co. P.U.D. about the power outage in the Pit Tag Room. He mentioned there has been no power outage during the time of the missing files 7/3/02. If power were lost it would only be for 2-3 seconds during switching of breakers. During this time Dave Marvin informed me of another incident of files missing that occurred on 7/8/02. Biomark personnel was scheduled to be on site 7/15/02 to inspect the condition of both ups units on PC1 and PC2 at 7/15/02. Scott McCutcheon informed me on 7/15/02 that no UPS units where installed and the computers were connected directly to the AC outlets. I can’t recall when I saw UPS units installed at Wells but it was some time before the wall locker was placed in the computer room. No other Biomark personnel have worked with the UPS units at Wells so I cannot explain why they are missing. UPS units were purchased and installed on PC1 and PC2 the next day. No missing file issues have occurred since. 07/17/2002 13:24 Scott_Li Per conversations with Darren and Anthony , We all, including myself agree that there was UPS's installed at the site at one time. They were the APC 350's which are not the same UPS's that we deployed at all the sites this spring. We could be wrong and can't explain what happen to them but irregardless, the problem has been taken care of. 07/16/2002 09:33 Dave Scott McCutcheon, BioMark, contacted me this morning from Wells Dam. He inspected the WEA computer installation yesterday, and determined that the facilities were not UPS protected. He purchased UPS units last night and installed them this morning. As of 8:00 AM (PST), both WEA-PC1 and WEA-PC2 are wired through individual Uninterrupted Power System units. Scott S., please verify that only the CPU (and not the monitor) of each computer station is UPS-protected. 07/16/2002 09:26 Dave Another power outage at ~9:00AM on 7/12 wiped out almost three hours of data. 07/10/2002 18:04 Dave We're missing another 4 hours, 50 minutes of data in two data files. I pcA'd into both WEAPC1 and WEAPC2, and could not locate these files on either machine. Probably more power outages. 07/05/2002 13:53 Dave We're missing 4.5 hours of data from July 3, from noon until 16:32 (PST) in file WEA02184.C I pcA'd into both WEA-PC1 and PC2, and could not locate this file on either machine. The log file for July 3 is too large to open with NotePad, and Wordpad doesn't function on WEA-PC1, so I couldn't locate the events around the outage. Given that the file is missing from both machines, I'm guessing there was a power outage, and the file was eaten. This is a documented bug, with a trouble ticket (4/9/02) in Test Track Pro. Suggestion: installing WinCmd to the WEA machines would make it much easier to search for, and especially browse, data files. 06/26/2002 09:21 bbeckley 02:ExcessiveNoise,03:ExcessiveNoise,04:ExcessiveNoise: O&M visit scheduled for this week the 27th or 28th of June. Will check and address the noise problem. 06/24/2002 11:07 Scott_Li PC1 had not been collecting data since day 02172.b. PCA'd to PC2 and manually sent files 02172.c thru 02175.a. As posted in the previous e-mail, PC1 is now back online. 06/24/2002 11:07 Scott_Li Called Paul at the project and asked him to reboot PC1. The computer has been non-respondent since day 02172. PCA'd to PC1 to verify operation and file submission. Everything checked out ok. 06/22/2002 10:22 scottl_l Noticed that WEAPC1 had not subitted files since 02172.b. Could not PCA into primary computer,Successfully PCA'd to PC2 to ensure that data was being collected. Will address problem no later than Monday AM. In the time will monitor PC2 closely to ensure data is being collected. 06/21/2002 17:07 acarson@ 01:ExcessiveNoise,02:ExcessiveNoise,03:ExcessiveNoise,04:ExcessiveNoise,05 :ExcessiveNoise,06:ExcessiveNoise,07:ExcessiveNoise,08:ExcessiveNoise: Excessive noise levels due to noise spikes. Coil 03 will be addressed at next site visit 06/27/02. 06/13/2002 16:17 Scott_Li Missing data files WEA02163.C-D do not exist on the primary or backup pc's. Obviously a power outage at the facility lasting longer than the UPS's battery capacity. We will verify that the monitors are not o the ups battery but rather on the surge output.. 06/13/2002 08:07 bbeckley 03:ExcessiveNoise: 03:ExcessiveNoise: Noise spike caused by Power house operations, site visit done checked all readers and operations. 06/13/2002 08:06 bbeckley 03:ExcessiveNoise: Noise spike caused by Power house operations, site visit done checked all readers and operations. 06/07/2002 09:25 bbeckley 01:ExcessiveNoise,02:ExcessiveNoise,03:ExcessiveNoise,04:ExcessiveNoise,05 :ExcessiveNoise,06:ExcessiveNoise: Excessive Noise Alarms caused by routine Power House operations. 05/26/2002 09:48 Darren_C I PCA'd into sites and sent files manually. sites were collecting data. 05/24/2002 11:39 Anthony On 05/23/02 I replaced all analog boards except for 07 and 08. The analog board from 05 went to 04. As it stands now: Coils 01, 02, 03, 05, 06 and the spare transceiver have the new modified analog boards. Coil 04 has the original analog board from coil 05. Coils 07 and 08 have the original analog boards. If the new modified analog boards did not increase the performance they were not replaced on that particular transceiver (boards from 05,07, & 08). All transceivers are re-tuned, calibrated, and communicating with the pit tag room. 05/24/2002 11:01 acarson@ 01:ExcessiveNoise,02:ExcessiveNoise,03:ExcessiveNoise,04:ExcessiveNoise,05 :ExcessiveNoise,06:ExcessiveNoise,07:ExcessiveNoise,08:ExcessiveNoise: Alarms caused by replacing analog boards and re-tuning all transceivers. 05/24/2002 10:54 acarson@ 01:LowExcCurrent,01:TestTagFailure,02:LowExcCurrent,03:LowExcCurrent,03:Te stTagFailure,04:LowExcCurrent,04:TestTagFailure,05:LowExcCurrent,06:LowExc Current,06:TestTagFailure: Alarms caused by replacing analog boards and re-tuned all transceivers. 05/14/2002 16:35 acarson@ 01:ExcessiveNoise,02:ExcessiveNoise,03:ExcessiveNoise,04:ExcessiveNoise,05 :ExcessiveNoise,06:ExcessiveNoise,07:ExcessiveNoise,08:ExcessiveNoise: Biomark personel working on all transceivers 05/09/02-05/10/02. 05/14/2002 16:07 Anthony On 05/09/02 I turned the noise reports status dumps on all transceivers to every 2 minutes. Transceiver ID# 06, s/n 2377 was replaced by s/n 2134. Transceiver s/n 2377, property of PSMFC, was returned to the PSMFC shop on 05/11/02. Transceiver s/n 2134 was flashed, re-tuned, and tested for communications with the pit tag room. All transceivers, including the spare, have been modified by removing R29 and R31 from the motherboard per Sean Casey’s request. This was recommended if the transceivers are to be synced together. The West side transceivers have been synced together since water-up. The East side have been synced together since the modification 05/09/02. I planed on replacing the analog boards on coils 01,02,03,04, and 06 to help with the noise levels. The analog boards where shipped from Destron-Fearing 05/08/02 FedEx priority overnight. They did not arrive until 05/13/02 due to weather delays and the wrong shipping address. They are now located in the pit tag room at Wells. I was able to bring the noise levels down on coil 04 from 22-28% to 8% by replacing the transceiver with the transceiver from coil 05. I noticed that the power for coil 06 was running off the UPS for coil 05. I powered up the UPS and now coils 05 and 06 are running on there own UPS. I plan to replace all analog boards if necessary on the next site visit. This will definitely fix the problem with coil #04 not firing the test tag due to excessive noise levels. 05/12/2002 09:14 darren@p 02:BadOscFreq,02:LowExcCurrent,03:TestTagFailure,04:LowExcCurrent,08:LowEx cCurrent: It appears that the alarms generated on 5-9-02 were caused by site personnel perfoming maintenance. Same with the alarms generated on 5- 10-02. I believe that the transceiver on coil 08 was being replaced. 05/06/2002 11:17 Scott_Li The about time program was set to time sync from an external nist. This is a bad thing because the time daemon observes daylight savings time. reconfigured PC1 about time to sync to itself and PC2 to time sync to PC1. This was done at 7:41 PST. 05/06/2002 11:06 Scott_Li Set the file submission frequency to upload 4 times per day. 05/03/2002 09:53 Scott_Li Changed the number of files generated per day to 4 on both primary and backup computers at 0850pst. 04/29/2002 12:55 Scott_Li Turned noise report status dumps off and set the readers status dumps to 720 min on all 8 transceivers. 04/25/2002 08:36 acarson@ 03:ExcessiveNoise,04:ExcessiveNoise: Noise spike. 04/23/2002 11:50 acarson@ 01:ExcessiveNoise,04:ExcessiveNoise: Excessive Noise is due to noise spikes. High noise levels on Coil #04 can be the cause of the timer tag not firing. The analog board will be modified at the next site visit to help bring the noise level down. The next site visit is scheduled as soon as the parts are available. 04/21/2002 20:51 acarson@ 01:ExcessiveNoise,04:ExcessiveNoise,06:ExcessiveNoise: Excessive noise alarms due to noise spikes. 04/19/2002 12:54 bbeckley 01:ExcessiveNoise,02:ExcessiveNoise,03:ExcessiveNoise,04:ExcessiveNoise,06 :ExcessiveNoise: Noise Alarms caused by periodic noise spikes. Brian Beckley 04/17/2002 12:27 bbeckley 06:ExcessiveNoise: Excessive noise alarm caused by periodic noise spikes. Brian Beckley 04/15/2002 07:21 acarson@ 01:ExcessiveNoise,04:ExcessiveNoise: Excessive noise due to noise spike on all West side coils. 04/13/2002 15:20 acarson@ 04:ExcessiveNoise,06:ExcessiveNoise: Excessive noise levels due to noise spikes. 04/09/2002 06:34 darren@p 01:ExcessiveNoise,02:ExcessiveNoise,03:ExcessiveNoise,04:ExcessiveNoise: Alarms generated by personnel doing site maintenance. 04/06/2002 20:57 acarson@ 07:ExcessiveNoise,07:LowExcCurrent,07:TestTagFailure: 07:ExcessiveNoise,07:LowExcCurrent,07:TestTagFailure: Alarms occurred during site visit. Tuned all West side coils after water-up. 04/06/2002 20:57 acarson@ 07:ExcessiveNoise,07:LowExcCurrent,07:TestTagFailure: Alarms occurred during site visit. Tuned all West side coils after water-up. 04/06/2002 09:47 bbeckley 06:ExcessiveNoise: Alarm acknowledged, noise spikes. Brian Beckley 04/04/2002 13:51 acarson@ 04:ExcessiveNoise: 04:ExcessiveNoise: Noise spike caused alarm. Dean Park 04/04/2002 13:51 acarson@ 04:ExcessiveNoise: 04:ExcessiveNoise: Noise spike caused alarm. Dean Park 04/04/2002 13:51 acarson@ 04:ExcessiveNoise: Noise spike caused alarm. Dean Park 04/04/2002 13:50 acarson@ 08:ExcessiveNoise: 08:ExcessiveNoise: Noise spike caused alarm. Dean Park 04/04/2002 13:50 acarson@ 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: Noise spike caused alarm. Dean Park 04/04/2002 13:50 acarson@ 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: Noise spike caused alarm. Dean Park 04/04/2002 13:50 acarson@ 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: Noise spike caused alarm. Dean Park 04/04/2002 13:50 acarson@ 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: Noise spike caused alarm. Dean Park 04/04/2002 13:50 acarson@ 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: Noise spike caused alarm. Dean Park 04/04/2002 13:50 acarson@ 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: Noise spike caused alarm. Dean Park 04/04/2002 13:50 acarson@ 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: Noise spike caused alarm. Dean Park 04/04/2002 13:50 acarson@ 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: Noise spike caused alarm. Dean Park 04/04/2002 13:50 acarson@ 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: Noise spike caused alarm. Dean Park 04/04/2002 13:50 acarson@ 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: Noise spike caused alarm. Dean Park 04/04/2002 13:49 acarson@ 08:ExcessiveNoise: 08:ExcessiveNoise: Noise spike caused alarm. Dean Park 04/04/2002 13:49 acarson@ : 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: Noise spike caused alarm. Dean Park 04/04/2002 13:49 acarson@ 08:ExcessiveNoise: 08:ExcessiveNoise: 08:ExcessiveNoise: Noise spike caused alarm. Dean Park 04/04/2002 13:49 acarson@ 08:ExcessiveNoise: Noise spike caused alarm. Dean Park 04/01/2002 18:04 acarson@ 01:ExcessiveNoise: Noise spike triggered alarm. Biomark will be on site 04/02/02 for further testing and tuning of all coils. 03/29/2002 17:12 acarson@ 08:ExcessiveNoise: West Ladder was water-up. Will be re-tuned 04/02/02. 03/29/2002 17:11 acarson@ 07:ExcessiveNoise,07:TestTagFailure: West Ladder was water-up. Will be re-tuned 04/02/02. 03/29/2002 17:09 acarson@ 06:ExcessiveNoise: West Ladder was water-up. Will be re-tuned 04/02/02. 03/29/2002 17:08 acarson@ 05:ExcessiveNoise: West Ladder was water-up. Will be re-tuned 04/02/02. 03/29/2002 13:12 acarson@ 04:ExcessiveNoise: Alarm triggered by noise spike. 03/27/2002 14:16 acarson@ 06:ExcessiveNoise: Appears to be a noise spike. 03/27/2002 14:15 acarson@ 04:ExcessiveNoise: Appears to be a noise spike. 03/24/2002 14:26 dlwarf@p 01:ExcessiveNoise: Alarm will be monitored for further instances. 03/22/2002 11:03 acarson@ 04:ExcessiveNoise: Coil Noise Report shows noise spike cause of alarm. 03/21/2002 11:34 Scott_Li PCA'd to the site and changed the readers "Unique" setting to ON for xcvrs 1 thru 8. After some discussion, it was determined that there was really no reason for the readers Unique setting to be off. Anthony C. is requesting that the noise report frequency stay at the 2 Min. interval for at least another week or until the West ladder is watered-up. 03/20/2002 07:11 acarson@ 01:ExcessiveNoise: Re-tuned antenna and flashed new ver. 3.11 firmware. 03/20/2002 07:10 acarson@ 02:BadOscFreq,02:ExcessiveNoise,02:LowExcCurrent: Re-tuned antenna and flashed new ver. 3.11 firmware. 03/20/2002 07:08 acarson@ 03:ExcessiveNoise: Re-tuned antenna and flashed new ver. 3.11 firmware. 03/20/2002 07:07 acarson@ 04:ExcessiveNoise,04:LowExcCurrent: Re-tuned antenna and flashed new ver. 3.11 firmware. 03/20/2002 07:06 acarson@ 05:ExcessiveNoise,05:LowExcCurrent: Re-tuned antenna and flashed new ver. 3.11 firmware. 03/20/2002 07:04 acarson@ 06:BadOscFreq,06:ExcessiveNoise,06:LowExcCurrent: Re-tuned antenna and flashed new ver. 3.11 firmware. 03/20/2002 07:00 acarson@ 07:ExcessiveNoise,07:TestTagFailure: Re-tuned antenna and flashed new ver. 3.11 firmware. 03/20/2002 06:57 acarson@ 08:TestTagFailure: Re-adjusted timer tag to read 100% and flashed transceiver with new ver.3.11 firmware. 03/19/2002 09:04 Scott_Li The site interrogation computers have been upgraded to Minimon Ver. 1.0.81. All transceivers were optimized and reflashed with coil id's and current threshold alarm settings. The west ladder has not been watered up as of 3/18/02. Not sure exactly when the ladder will be watered up. Biomark was on site performing maintenence and taking electrical measurements. 03/05/2002 07:57 Sean_Cas Scott, You are correct. The test tag is being treated like any other tag. This means that the Unique feature affects the timer tag. This is NOT desirable. We are currently having Steve Lemay (STR) review the parameters in the code that affect the test tag. Roger is also reviewing all the test tag functions from the keypad, maint. port and high-speed port. We want to make sure that we only turn this code once. We will be calling today to resolve the implementation of the test tag (and any other issues we can take the opportunity to address at this time). Thank you for the great job isolating the problem and are sorry for the inconvenience. Take care, Sean -----Original Message----- From: Scott Livingston [mailto:scottl@psmfc.org] Sent: Monday, March 04, 2002 6:38 PM To: Sean Casey Cc: 'John Tenney'; 'Darren Chase'; 'Carter Stein'; 'Dave Marvin'; 'dlwarf@psmfc.org'; 'Sean'; 'Anthony'; Roger Clark; 'Pitevent' Subject: Re: More on Adult Testtags, wea Sean/Roger , What software are you using to collect the data from the reader? I have used Minimon and Multimon and still get the same results. Heres whats happening... If the reader Unique function in set to "ON", a different tag code is required to be read before the testtag will again be displayed . If no other tag code, different than the testtag code is read before the test tag interval timer expires , then no TT data will be logged. This is not the case with the Juvenile firmware. Let me know how we want to approach this... Thanks, Scott... Sean Casey wrote: >Scott, > >We have tested the features in the lab and did not duplicate the error >condition per your information. Possibilities are: >1.) You need to reset parameters, the reader ID after programing will be >the old one as the memory location for the ID has changed. >2.) One of the three software/firmware programs necessary for the TT is >incorrect. >3.) PIC processor on the analog board (socketed) is loose (poke-job). >4.) Re-program 188 code as it maybe corrupt. > >If you are still having problems, send the reader to Roger for analysis. > >Take care, > >Sean > > > >-----Original Message----- >From: Scott Livingston [mailto:scottl@psmfc.org] >Sent: Monday, March 04, 2002 3:13 PM >To: John Tenney; Darren Chase; Carter Stein; Dave Marvin; >dlwarf@psmfc.org; Sean; Anthony; Sean; Roger Clark; Pitevent >Subject: More on Adult Testtags, wea > > >FYI..... For FS-1001A firmware ver. 3.9 > >The Testtag data ( tag code ) will not be displayed in the interrogation >file if the " Reader Unique " function is turn to " ON " The text >message associated with a testtag upon exiration of the TT interval >timer WILL be sent and logged to the interrogation file. Although, if a >reader reset is issued, the timertag will be sent to the display >irregardless of the unique setting. > >I thought that if the "Reader Unique delay" option was less a value than >the Testtag delay, this would allow the testtag information to be >written to the data file. Not the case... > >Again, for Testag data to be written to the interrogation file the " >Reader Unique " option needs to be set to " OFF" > >Not sure if this is a feature or a bug. Seems to me that it is at least >an undesirable situation. Also, I am curious if this Unique delay option >even works with fish tag codes, I will test that also.. > >I will change the device configs at WEA for Unique to OFF. Also , coil >03 noise report is set to 0, no report, will change to 2min interval. > > >. > 03/04/2002 16:27 Scott_Li Sean/Roger , What software are you using to collect the data from the reader? I have used Minimon and Multimon and still get the same results. Heres whats happening... If the reader Unique function in set to "ON", a different tag code is required to be read before the testtag will again be displayed . If no other tag code, different than the testtag code is read before the test tag interval timer expires , then no TT data will be logged. This is not the case with the Juvenile firmware. Let me know how we want to approach this... Thanks, Scott... Sean Casey wrote: >Scott, > >We have tested the features in the lab and did not duplicate the error >condition per your information. Possibilities are: >1.) You need to reset parameters, the reader ID after programing will be >the old one as the memory location for the ID has changed. >2.) One of the three software/firmware programs necessary for the TT is >incorrect. >3.) PIC processor on the analog board (socketed) is loose (poke-job). >4.) Re-program 188 code as it maybe corrupt. > >If you are still having problems, send the reader to Roger for analysis. > >Take care, > >Sean > > > >-----Original Message----- >From: Scott Livingston [mailto:scottl@psmfc.org] >Sent: Monday, March 04, 2002 3:13 PM >To: John Tenney; Darren Chase; Carter Stein; Dave Marvin; >dlwarf@psmfc.org; Sean; Anthony; Sean; Roger Clark; Pitevent >Subject: More on Adult Testtags, wea > > >FYI..... For FS-1001A firmware ver. 3.9 > >The Testtag data ( tag code ) will not be displayed in the interrogation >file if the " Reader Unique " function is turn to " ON " The text >message associated with a testtag upon exiration of the TT interval >timer WILL be sent and logged to the interrogation file. Although, if a >reader reset is issued, the timertag will be sent to the display >irregardless of the unique setting. > >I thought that if the "Reader Unique delay" option was less a value than >the Testtag delay, this would allow the testtag information to be >written to the data file. Not the case... > >Again, for Testag data to be written to the interrogation file the " >Reader Unique " option needs to be set to " OFF" > >Not sure if this is a feature or a bug. Seems to me that it is at least >an undesirable situation. Also, I am curious if this Unique delay option >even works with fish tag codes, I will test that also.. > >I will change the device configs at WEA for Unique to OFF. Also , coil >03 noise report is set to 0, no report, will change to 2min interval. > > >. > 03/04/2002 16:27 Sean_Cas Scott, We are using our test software that Roger developed and displaying whatever comes across the port. We will check into the fact that the test tag is being treated as a standard tag. Get back to you later. Take care, Sean -----Original Message----- From: Scott Livingston [mailto:scottl@psmfc.org] Sent: Monday, March 04, 2002 6:38 PM To: Sean Casey Cc: 'John Tenney'; 'Darren Chase'; 'Carter Stein'; 'Dave Marvin'; 'dlwarf@psmfc.org'; 'Sean'; 'Anthony'; Roger Clark; 'Pitevent' Subject: Re: More on Adult Testtags, wea Sean/Roger , What software are you using to collect the data from the reader? I have used Minimon and Multimon and still get the same results. Heres whats happening... If the reader Unique function in set to "ON", a different tag code is required to be read before the testtag will again be displayed . If no other tag code, different than the testtag code is read before the test tag interval timer expires , then no TT data will be logged. This is not the case with the Juvenile firmware. Let me know how we want to approach this... Thanks, Scott... Sean Casey wrote: >Scott, > >We have tested the features in the lab and did not duplicate the error >condition per your information. Possibilities are: >1.) You need to reset parameters, the reader ID after programing will be >the old one as the memory location for the ID has changed. >2.) One of the three software/firmware programs necessary for the TT is >incorrect. >3.) PIC processor on the analog board (socketed) is loose (poke-job). >4.) Re-program 188 code as it maybe corrupt. > >If you are still having problems, send the reader to Roger for analysis. > >Take care, > >Sean > > > >-----Original Message----- >From: Scott Livingston [mailto:scottl@psmfc.org] >Sent: Monday, March 04, 2002 3:13 PM >To: John Tenney; Darren Chase; Carter Stein; Dave Marvin; >dlwarf@psmfc.org; Sean; Anthony; Sean; Roger Clark; Pitevent >Subject: More on Adult Testtags, wea > > >FYI..... For FS-1001A firmware ver. 3.9 > >The Testtag data ( tag code ) will not be displayed in the interrogation >file if the " Reader Unique " function is turn to " ON " The text >message associated with a testtag upon exiration of the TT interval >timer WILL be sent and logged to the interrogation file. Although, if a >reader reset is issued, the timertag will be sent to the display >irregardless of the unique setting. > >I thought that if the "Reader Unique delay" option was less a value than >the Testtag delay, this would allow the testtag information to be >written to the data file. Not the case... > >Again, for Testag data to be written to the interrogation file the " >Reader Unique " option needs to be set to " OFF" > >Not sure if this is a feature or a bug. Seems to me that it is at least >an undesirable situation. Also, I am curious if this Unique delay option >even works with fish tag codes, I will test that also.. > >I will change the device configs at WEA for Unique to OFF. Also , coil >03 noise report is set to 0, no report, will change to 2min interval. > > >. > 03/04/2002 14:59 Sean_Cas Scott, We have tested the features in the lab and did not duplicate the error condition per your information. Possibilities are: 1.) You need to reset parameters, the reader ID after programing will be the old one as the memory location for the ID has changed. 2.) One of the three software/firmware programs necessary for the TT is incorrect. 3.) PIC processor on the analog board (socketed) is loose (poke-job). 4.) Re-program 188 code as it maybe corrupt. If you are still having problems, send the reader to Roger for analysis. Take care, Sean -----Original Message----- From: Scott Livingston [mailto:scottl@psmfc.org] Sent: Monday, March 04, 2002 3:13 PM To: John Tenney; Darren Chase; Carter Stein; Dave Marvin; dlwarf@psmfc.org; Sean; Anthony; Sean; Roger Clark; Pitevent Subject: More on Adult Testtags, wea FYI..... For FS-1001A firmware ver. 3.9 The Testtag data ( tag code ) will not be displayed in the interrogation file if the " Reader Unique " function is turn to " ON " The text message associated with a testtag upon exiration of the TT interval timer WILL be sent and logged to the interrogation file. Although, if a reader reset is issued, the timertag will be sent to the display irregardless of the unique setting. I thought that if the "Reader Unique delay" option was less a value than the Testtag delay, this would allow the testtag information to be written to the data file. Not the case... Again, for Testag data to be written to the interrogation file the " Reader Unique " option needs to be set to " OFF" Not sure if this is a feature or a bug. Seems to me that it is at least an undesirable situation. Also, I am curious if this Unique delay option even works with fish tag codes, I will test that also.. I will change the device configs at WEA for Unique to OFF. Also , coil 03 noise report is set to 0, no report, will change to 2min interval. 03/04/2002 12:49 Scott_Li FYI..... For FS-1001A firmware ver. 3.9 The Testtag data ( tag code ) will not be displayed in the interrogation file if the " Reader Unique " function is turn to " ON " The text message associated with a testtag upon exiration of the TT interval timer WILL be sent and logged to the interrogation file. Although, if a reader reset is issued, the timertag will be sent to the display irregardless of the unique setting. I thought that if the "Reader Unique delay" option was less a value than the Testtag delay, this would allow the testtag information to be written to the data file. Not the case... Again, for Testag data to be written to the interrogation file the " Reader Unique " option needs to be set to " OFF" Not sure if this is a feature or a bug. Seems to me that it is at least an undesirable situation. Also, I am curious if this Unique delay option even works with fish tag codes, I will test that also.. I will change the device configs at WEA for Unique to OFF. Also , coil 03 noise report is set to 0, no report, will change to 2min interval. 03/04/2002 10:47 acarson@ 04:ExcessiveNoise: Noise spike ackowledged 03/04/2002 10:45 acarson@ 01:ExcessiveNoise: Noise spike ackowledged 03/04/2002 10:43 acarson@ 03:ExcessiveNoise: Noise spike ackowledged. 03/04/2002 10:36 acarson@ 05:ExcessiveNoise: Noise spike acknowledged. 03/04/2002 10:34 acarson@ 06:ExcessiveNoise: Noise spike effected all transceivers on the west ladder. 03/04/2002 10:31 acarson@ 07:ExcessiveNoise,07:TestTagFailure: Noise spike caused missed timer tag. 02/27/2002 17:46 acarson@ 06:ExcessiveNoise: Noise spike occurred on all coils on the West side around the same time. I will continue to monitor for a pattern. 02/27/2002 17:43 acarson@ 03:ExcessiveNoise: When using the Coil Noise Report to see the noise levels the report displayed --< Noise Parameter Data Not Found>--. I will check with Scott L. to be sure that the transceiver is sending noise data every 2min. This noise spike occurred at the same time as all the coils on the West side ladder. 02/27/2002 17:23 acarson@ 05:ExcessiveNoise: Noise spikes appear from 10:57:13-11:09:01 on 2002/02/27 with two spikes in the 100% range. Will monitor for any patterns. 02/27/2002 17:12 acarson@ 08:TestTagFailure: The noise spikes every hour of 10-20% show that the test tag is being triggered but not enough to read the tag. Coil 07 shows the same spikes every hour but they are in the 25-33% range. Coil 07 is reading test tags. The test tag level for coil 08 could have been set at a level best for tuning the antenna and not re-adjusted after the antenna was tuned. This can be tested at the next site visit. 02/27/2002 16:51 acarson@ 07:ExcessiveNoise,07:TestTagFailure: Both alarms occurred at the same time. A 90% noise spike appeared to have caused the test tag to fail. Other than this spike the coil has had low noise averages since data has been. collected. 02/27/2002 12:27 Scott_Li Heres the status of the timer tags situation. Biomark indicated that after they had flashed the xcvrs , they notice slugish behaviour when scrolling through the menus on the xcvrs and also noticed that the previous timertag code was still being observed by the reader when the TT was fired. Wierd? not really if the PARMS were not reloaded. After a reader reset, everything was cool. Pca'd to the the site and manually reset reader id's ,05,06,07,08. Coil 05 , fired testtag upon reader reset, Coil 06 , fired testtag upon reader reset, Coil 07 fired timer tag upon reader reset, Coil 08 did NOT fire TT on reader reset. Prior to 2/26 @ ~ 1030 , something happen to the TT on Coil 08 and had no way of knowing until the next site visit. Coil 04 has excessive noise levels and this could and more than likely is the culprit. Adjusted noise threshold alarms on Coils 05,06,07,08 to 45 % to avoid tripping the tass panel to red. Again verified that the TT delay for all coils is set to 60 mins. Will monitor situation to see if the reader reset will shake loose the TT's. 02/27/2002 09:01 scottl@p 06:ExcessiveNoise: This transceiver needs to be tuned and optimized. Will address no later than 3/18/02 just prior to water up of the West ladder. 02/27/2002 08:57 Scott_Li Pulled these snippets from 2 most recent files submitted. Looks as if noise levels are excessive causing testtag to be aborted due to system activity but may not be the sole source of the failure. Coils 4 thru 8 are not detecting testtags. Will investigate further. | 03 02/27/02 03:59:03 3E7.0000001D02 XX 02 | 03 02/27/02 03:59:03 3E7.0000001D02 XX 02 | 06 02/27/02 03:58:05 3E7.0000001D03 XX 03 | 06 02/27/02 03:58:05 3E7.0000001D03 XX 03 | 02 02/27/02 04:01:31 3E7.0000001D01 XX 01 | 02 02/27/02 04:01:31 3E7.0000001D01 XX 01 02/26/2002 16:13 Scott_Li See raw snippets indicating high noise levels hindering timertags from being fired and detected. ~04-7 02/23/02 06:58:49 ALARM MESSAGE: Single-shot test with Test Tag. :-( ~04-7 02/23/02 06:58:49 ALARM MESSAGE: Test aborted due to system activity. ~08-9 02/23/02 07:45:34 ALARM MESSAGE: Single-shot test with Test Tag. :-( ~08-9 02/23/02 07:45:34 ALARM PROBLEM: Test Tag Failed( reason for failure unknown ) The default noise alarm threshold is 20 percent. the west side transceivers were reflashed and the threshhold was not elevated above the 20 percent default. Will talk with Anthony Carson to see what these levels should be set at... 02/26/2002 11:55 Carter_S Added "Virtual Timertag Standard Codes" for coils 05-08 at WEA. --Carter 02/26/2002 11:33 Scott_Li Set the noise report on xcvrs 05,06,07,08 to status dump every 2 mins as requested by Anthony Carson, ( Biomark ) 02/26/2002 10:29 acarson@ 07:ExcessiveNoise,07:TestTagFailure: Work was being done at site on all transceivers from 02/19/02-02/22/02. 02/26/2002 10:27 acarson@ 06:ExcessiveNoise,06:LowExcCurrent,06:TestTagFailure: Work was being done at site on all transceivers from 02/19/02-02/22/02. Transceiver will be adjusted before water-up, this should reduce the noise levels. 02/26/2002 10:22 acarson@ 05:ExcessiveNoise: Work was being done at site on all transceivers from 02/19/02-02/22/02. 02/26/2002 10:18 acarson@ 04:ExcessiveNoise,04:TestTagFailure: Work was being done at site on all transceivers from 02/19/02-02/22/02. 02/26/2002 09:56 acarson@ 02:BadExcFreq,02:BadOscFreq,02:LowExcCurrent,02:TestTagFailure: Work was being done at site on all transceivers from 02/19/02-02/22/02. 02/26/2002 09:49 acarson@ 01:ExcessiveNoise: Noise acknowledged. 02/25/2002 11:38 Scott_Li Site visit activities on 2/22/02 included upgrading PC2 with MiniMon version. 1.0.80. that incorporates communications to the xcvrs. Replaced transceiver for Coil 06 due to a hardware failure. Reflashed xcvrs, 05,06,07,08 with proper coil ID's and current alarm threshold settings to 3.5 Amps. Set timer tag reporting duration to 60 mins on all coils. Attached fiber optic cables on the West ladder to the xcvrs and verfied communications to the data collection platforms. One note: after replacing xcvr on coil 06, the xcvr was retuned but could not get the FDX noise level below 15 to 20 % with the door closed. With door open, the xcvr would tune to noise levels ~ 5 -8 %. Talked with Biomark this morning about the tuning procedures and how they optimimize the xcvrs and will request a formal written procedure if this process differs from the standard operating and tuning process that was taught in the fs-1001a training class... Biomark indicated that they will revisit the site prior to the West ladder water-up to optimize the xcvr performance , PTOC Kenn. will be involed during this visit... 02/15/2002 15:47 acarson@ 03:TestTagFailure: Test tag failure acknowledged 02/14/2002 06:50 acarson@ 03:TestTagFailure: Test tag failure acknowledged. Transceiver and antenna to be tested the 02/19/02. 02/13/2002 11:40 carters@ 03:TestTagFailure: Tag failure acknowledged. 02/12/2002 09:51 Don_Warf PCanywhered into PC1 to find Minimon not running. When I tried to restart Minimon the PC said it was already running. Rebooted PC. Below is the log showing the shutdown: Sys 02/11/02 12:35:33 INFO User requested to stop Interrogation Sys 02/11/02 12:35:33 INFO Attempting to disconnect devices... Sys 02/11/02 12:35:33 INFO Devices disconnected Sys 02/11/02 12:35:33 INFO Interrogation stopped, file count is 147 Sys 02/11/02 12:35:33 INFO Free Physical Mem:186,672 KB; Page Usage: 1%; Free Virtual Mem: 98%; Disk Free: 38,585,792 KB Sys 02/11/02 12:35:33 INFO Request to cancel auto-upload process... Sys 02/11/02 12:35:33 INFO User halted interrogation process. Sys 02/11/02 12:35:33 WARN Shutdown Request:user chose the Close command from Application's Control box Sys 02/11/02 12:35:33 INFO Application is shutting down normally. 02/11/2002 06:49 acarson@ 04:ExcessiveNoise: Noise acknowledged 02/11/2002 06:48 acarson@ 03:TestTagFailure: Possible transceiver failure or shorted antenna. Working on the fix. 02/08/2002 17:55 acarson@ 03:BadExcFreq,03:BadOscFreq,03:LowExcCurrent,03:TestTagFailure: Alarms acknowledged. Gathering information to determine the cause of failure. 02/07/2002 08:27 darren@p 04:ExcessiveNoise: It appears that 3 coils noise levels rose at the same time. But all returned to normal before the next noise report. I think that the spike was roughly about the same time yesterday. I will check to see if there is a pattern developing with this spike. 02/06/2002 06:59 darren@p 04:ExcessiveNoise: Noise appears to be a spike. The level was at 97% on peak and FDXB peak but the average was no more than 30-40%. It did return to normal almost immediately and was back to normal within 5 min. 02/05/2002 07:45 acarson@ 04:ExcessiveNoise: Noise acknowledged. 02/01/2002 17:59 acarson@ 04:ExcessiveNoise: Noise acknowledged. I will contact DCPUD to help find the source of spike everyday around 17:00. 01/31/2002 17:10 acarson@ 04:ExcessiveNoise: Noise acknowledged 01/31/2002 15:11 darren@p 01:ExcessiveNoise: What ever generated the noiise seemed to be just a spike. There did not seem to be any long term noise. 01/29/2002 16:50 carters@ 04:ExcessiveNoise: Testing. DougC 01/29/2002 16:38 carters@ 04:ExcessiveNoise: Testing. DougC. 01/29/2002 16:35 carters@ 01:ExcessiveNoise: You guessed it. Doug 01/29/2002 16:23 carters 01:ExcessiveNoise: This is yet another test! Doug C. 01/29/2002 15:54 carters 01:ExcessiveNoise: This is another test. DougC. 01/29/2002 15:50 carters 01:ExcessiveNoise: This is another test. Doug C. 01/29/2002 15:44 carters 04:ExcessiveNoise: This is a test. Doug C. 01/29/2002 15:39 carters 01:ExcessiveNoise: acknowledged. 01/29/2002 15:34 carters 01:ExcessiveNoise: Acknowledged. 01/29/2002 14:35 carters 04:ExcessiveNoise: 04:ExcessiveNoise: Carter acknowledged noise on coil 4 01/29/2002 14:34 carters 04:ExcessiveNoise: Carter acknowledged noise on coil 4 01/29/2002 14:27 acarson 02:ExcessiveNoise: Noise acknowlrdged 01/29/2002 14:26 acarson 01:ExcessiveNoise: Noise acknoledged 01/29/2002 14:17 acarson 01:ExcessiveNoise,02:ExcessiveNoise,04:ExcessiveNoise: Noise acknowledged 01/24/2002 16:50 Dave Turned file checking on in etc/sites. 01/24/2002 15:02 Carter_S Timer tags for Wells Adult coils 01-04 are set up. 01/24/2002 10:16 scott Site computers and transceivers are actively and collecting and sending data as of 0800 2/24. Timer tag data for the Left laddere (Ea (East)should be contained in file WEA02024.N file sent this morning. Pc's are generating new files every 3 hrs and submitting every 4 hrs. The Right Ladder infrastructure has not been completed therefore no data will be available for this side No info on when this side will be completed. Pittag room is 90% complete. ####End of Event Log for WEA###