It depends on your system and location. Condensation in the sample lines will get the RH sensors wet, and this leads to failing RH sensors, overworked thermal cutoff switches, failing heaters, corrosion, and water in parts of the system where you do not want it. If your site is in a warm and humid location, it is typically better to have the instrument room be as warm as possible.

Consider this example. Suppose you have rain at the site and the ambient RH is 95%. If the outdoor temperature is 82F, you would be risking condensation if the temperature of the sampling lines inside the building falls below 80F. We insulate the sampling lines but the insulation is not perfect. If room temperature is kept at 76F you might have condensation occur during hot, humid weather. An easy way to protect the system at least a little would be to increase the building internal temperature to 78F. Of course higher temperatures are not always good for electronics, so you would have to try it and see if the system worked well at a slightly elevated temperature.

Most lines have six values in scientific notation. These are for the blue, green, and red channels, first for total scattering, and then for backscattering.

One possible reason is that there is a problem with one of the photomultiplier tubes. Look at the spancheck errors for each wavelength and see if one of the wavelengths has large errors. If there is a wavelength with large errors then look at the raw photon counts for that wavelength (use the’counts’ menu from the Neph window on the station laptop to look at photon counts). The photon calibrator counts values should be greater than 80 kHz for the blue wavelength and grater than 100 kHz for green and red wavelengths and the dark counts should be less than 30 for blue and green wavelengths and less than 300 for red. If calibrator and dark counts are both low then turning up the PMT voltage for that wavelength may help. If the PMT voltage for that wavelenghtt is below 1200V you can increase it. Don’t increase it above 1200V. Once you’ve adjust the PMT voltage then see if your span check values have improved. If not then you will need to recalibrate the neph followed by a span check.

If you can not turn up the PMT voltage further (it’s already at 1200V), then the PMT or color bandpass filter probably needs to be replaced. If it is necessary to replace the PMT, a calibration followed by a span check is in order.

The TSI nephelometer reports error messages whenever it detects that things are not quite right inside the instrument. The errors are represented by a 4-character code. The meaning of the individual codes can be found in the TSI nephelometer manual, I believe near the end of Chapter 6 (chapter discussing serial data commands). The '0008' error I believe is a chopper fault. It may be that for a second or two (or perhaps much longer) the chopper rotated slightly outside the normal rate of rotation, and the error was generated. The '000C' error looks like a chopper fault ('0008') plus a valve fault ('0004') at the same time (0008 + 0004 = 000C in hexadecimal). These errors could possibly be generated by power glitches that make the chopper, backscatter shutter, or zero filter valve rotate in a way different than the normal operation. On the other hand, something could actually be wrong here. If the amount of errors that the TSI neph generates increases greatly, or if the amount of time that the TSI neph spends in an error state becomes too large, then we would have to take action. Unfortunately, that might require pulling the TSI neph and shipping it back to TSI in the US, a lengthy and costly maneuver.

You can tell the fraction of time that the TSI neph spends in an error state by information contained in the daily email reports. If the TSI neph spends 0.5% or more of its time in an error state, you will see the following line appear in the New Data Report at the end of the 'Nephelometer #1 errors:' section.
'Percent errors in neph status = X'
where X = the percentage. As long as the error percentage is low (e.g., we can probably live with a few percent or less), then I would say we just leave things alone but continue to monitor the situation. If the fraction of time that the neph spends in an error state becomes too great, then you will have to either try to troubleshoot/fix the problem or else return the instrument to TSI for repair and overhaul.

1. Make the neph status window active:
   Press <Enter>, then press <N>
   
2. Activate the neph window, and then select "Change parameters"
   Press <M>, then press <4>
   
3. Edit the Lamp power setting
   Press the down arrow 5 times to highlight the lamp power line
   Press <Enter> to enter edit mode
   Press the backspace key twice to delete the current value
   Enter the new value (75) and press <Enter>
   
4. Press the down arrow 7 times to highlight the "Close and apply" line, then press <Enter>

Negative span check errors mean that the measured span in scattering between filtered air and filtered CO2 is not as large as the computer expects. This could be because either the filtered air measurement shows higher scattering than expected, the filtered CO2 measurement shows lower scattering than expected, or both. Large negative errors on the order of 60% typically mean that CO2 either is not getting into the nephelometer or is being sucked out of it by the vacuum system through a faulty solenoid bypass system. Check to make sure CO2 is getting into the neph during a span check.

If you see large negative span check errors in an otherwise functioning neph, have the tech search for the most likely problems. From my experience, these are:

1. A faulty NC solenoid
   We have had problems in the past where a valve that was supposed to be closed for a span check was actually slightly open, due to a bad seating of the plunger. This could be due to dirt in the valve body or just a bad valve mechanism. Unfortunately, the impactor box is not the easiest thing in the world to disassemble, so a valve replacement here will take some effort. One easy test to try first is to disconnect the vacuum line that runs between the impactor box and the neph outlet right at the neph outlet fitting. During a span check, there should be NO suction in this line. Place your finger over the line to check this. The valve should be competely closed so that the the CO2 that is being fed into the neph stays in the neph (or at least only exits under its own pressure from the inlet). If you feel ANY suction on this line during the CO2 portion of the span check, then you have either a dirty or malfunctioning solenoid valve.
   
2. A failed neph zero filter ball valve
   Another thing to check is to make sure that the zero valve on the nephelometer is rotating. Notice I did not say the motor or the flange rotating. The typical failure point is at the junction of the shaft and ball inside the valve. The motor and flange still turn, but the ball does not, so the tech must look down the inlet of the instrument with a flashlight to see if the ball itself is turning. If the ball is stuck in a partially open position, this allows air with particles in during the zero air portion of the span check - thus higher scattering than expected during this part of the span check with large negative errors resulting. Depending on how clean the laboratory is, you would probably notice a step change in the hourly neph background measurement, but if it is in a clean environment, maybe not.
   
3. Problem with CO2 delivery system
   To verify this, you can disconnect the inlet sampling line to the neph during the span check and smell to see if CO2 is exiting from the neph inlet there. Since the neph outlet path is blocked by the closed solenoid, the CO2 should must exit from the neph inlet. Problems could be at any of the following locations:
   a) Broken CO2 delivery tubing - could be inside of the neph cover
   b) Broken CO2 solenoid valve or electrical connector
   c) CO2 delivery tube inside neph cover blown off fitting by high CO2 pressure.
   d) empty CO2 tank
   e) Improperly set CO2 rotameter or regulator

1. discontinue the neph measurements. (hopefully you don’t choose this!)
   
2. remove the neph and send it to TSI for a motor upgrade. They will replace both internal motors with better ones (i.e., larger shafts and bearings) for around US$7500. This is the best long-term solution but is expensive and will cause a significant data gap.
   
3. replace the failing motor yourself. We keep a supply of these motors here at NOAA for our collaborators which we rebuild with higher quality bearings and lubricant. This does not solve the problem, it just extends (we think) the motor life a little. If you choose this option you will be changing these motors periodically (perhaps every year or two), but the cost is low (basically only shipping costs to us) and there is less of a data gap. We require that you send us the failed motor after replacement so that we can rebuild it for the next replacement.

If you are considering Option #3, please let us know. We can send you a document on how to replace the backscatter shutter motor. You can at least see if it is something you think you can handle. We have other colleagues that have done this replacement, so you can probably handle the task. If you end up breaking something, well, the neph needed repair anyway so you would then have to send it in to TSI.

The impactor takes 30 lpm volumetric flow to achieve a 1-um cutpoint. What is being displayed in cpdclient is a calibrated, mass flow rate. So even if the true volumetric flow through the system was 30.0, the displayed flow would not equal 30.0, unless the temperature at the sensor is 0 degrees C, the pressure is 1013.25 mb, and the calibration ratio (true flow/measured flow) is exactly 1:1 with no offset. If you are reading the value displayed by the #4 PID in the Filter Rack#2 PID box, then what you are reading is an UNCALIBRATED, mass flow measurement of the flow through the filter. If you are reading the flow displayed on the aerosol laptop ("Q Filter (slpm)" in the "Filter-2" window in cpdclient), then you are reading a CALIBRATED mass flow measurement of the flow through the filter.

You can use a multimeter to measure resistances across the stack heater connections to determine if there is an electrical problem with the stack heater:
(a) measure the resistance between the two vertical prongs of the stack heater plug. the resistance should be ~55 ohms
(b) measure the resistance between one of the vertical prongs and the centered ground prong. the resistance should show that the circuit is open - resistance should be infinity. do the same with the other vertical prong and the ground prong.

If you want to check that the stack heater is working you can change the setpoint of the stack RH from 40% down to something lower than the measured value (say 15%). two things to look at after changing the setpoint.
(1) There's an amber colored light to the right of the PID display. when power is being applied to the heater (to make it hot) the light lights up. If the set point is lower than measured RH you should see the amber light come on.
(2) If power is being applied to the heater (based on the amber light lighting up) then if you can get your hand on the 2" stainless steel pipe the splitter sits on you may be able to feel it be slightly warm (or very warm - it depends on how much heating it needs to do to meet the setpoint value.)

Here's a quick explanation about how to change the setpoint on the PIDs.
On each PID there are 4 buttons, from left to right:
(1) 'circle arrow'
(2) 'up arrow'
(3) 'down arrow'
(4) 'enter arrow'

to change the PID setting use the up and down arrows to change the value of the setpoint from 40% to whatever. When you have it set where you want then use the 'enter arrow' to enter that value. The new setpoint value (the green numbers, lower half of readout) should stay at the value you chose and the measurement (the red numbers, upper half of
readout) should gradually adjust to the setpoint. If you lowered the setpoint below the measurement (i.e., from 40% to 15% as described aboved) then you should also see the amber light come on.

It depends on the site altitude and average temperature. Here are the equations needed to calculate te magnahelic setting "dP_inH2O".

Q_lpm = 2011 * sqrt( T_K * dP_hPa / P_hPa )
or, for the desired flow of 850 lpm (volumetric),
dP_hPa = P_hPa / (5.6 * T_K)
dP_inH2O = P_hPa / (13.9 * T_K)

Useful info:
V_average = 0.90 * V_centerline
dP_hPa = 2.49082 * dP_inH2O
Diameter = 1.75" (inner diameter of tube where flow is measured)
For more info, see http://en.wikipedia.org/wiki/Pitot_tube

Press F1 on the IBM screen during initial bootup
Select "Config"
Select "Power"
Set "Power Mode for AC" to "Customized"
Set "Power Mode for Battery" to "Customized"
Set "Processor speed" to "Fixed Max"
Set "Suspend Timer" to "Disabled"
Set "LCD off Timer" to "Disabled"
Set "HDD off Timer" to "Disabled"
Set "Hibernate by Timer" to "Disable"
Set "Suspend when LCD is Closed" to "No Suspend"
Press F10 to save and Exit and select "Yes"

You should take a look at your laptop, and if the battery indicator light is yellow, it means that you have a weak battery that is no longer capable of being fully charged. (See picture of indicator light below.) The laptop will go into "suspend mode" when the battery power is too low. This power threshold may not be exactly the same as that which causes the battery indicator light to turn yellow, so even if you have a yellow indicator light you may not have experienced a suspended session (yet). But it will happen eventually, so you should replace the weak battery with a new one.

Fortunately, new batteries for these laptops are still commonly available and many vendors sell them. We have purchased them recently from ebay, and I know that Amazon.com sells them. Traditional stores also sell these batteries. You can search online for something like

"New Battery for IBM Thinkpad T20 T21 T22 T23"

and see many vendor listings for this product. The last price we paid for these batteries was about $35 each. As long as the laptops are run with the AC adapter/charger plugged in (our normal operating mode), these batteries last for several years.

1. Switch to root command screen by pressing <Ctrl><Alt><F11>
   
2. Stop the NTP server:
   '/etc/init.d/ntp-server stop'
   
3. Display debugging information for NTP:
   'ntpd -dd'
   
4. Stop the NTP debugging output by pressing C
   after 5-10 seconds.
   
5. Start the NTP server:
   '/etc/init.d/ntp-server start'
   
6. Examine the debugging output. If the GPS is working properly, you should get several lines of output per second. Lines that begin with "refclock_gtlin:" indicate that NTP is getting clock sync information from the GPS. If you get a few lines of output when you start the program, but nothing more after that, it indicates that the computer isn't talking to the GPS receiver. Possible causes are an unplugged serial cable, unplugged power supply, or broken hardware (GPS receiver, serial port, power supply).
   
7. Switch back to GUI by pressing <Ctrl><Alt><F7>

The 3W PSAPs operate at 467, 530, and 660 nm.

We buy the pre-cut psap filters from VWR International. The web site is
http://www.vwrsp.com/
Once on the web page you can search for the product. The manufacturer's part number is E70-2075W. The VWR Catalog Number is 21431-350. Either of these numbers should find the product for you. The item you are searching for is 10mm diameter pre-cut filters, quantity 250.

Not necessarily. We often see particle number concentration measured by a CPC inversely related to aerosol light scattering. Larger particles (e.g., accumulation mode particles) will grow at the expense of the smaller ones. Sometimes you see extremely high particle counts during episodes of new particle formation, and the scattering may be very low. High scattering could mean a more aged aerosol advected into the area, with relatively few tiny particles. This may not be what is happening at your site, but I would not assume that higher particle number concentration should be expected from moderate scattering values.

The most likely problems are that the flow has decreased because your critical orifice has become a bit clogged, or the butanol in your CPC may have some water in it. If you have a flow calibrator (e.g., BIOS or Gilibrator), you can measure the flow rate into the inlet of your CPC. That will tell us if you need to change the flow rate entered in cpd.ini. For the other problem, the easiest thing to do would be to drain the old butanol from the instrument, dry out the saturator block, and then refill it with fresh butanol. If you get a step change in the particle concentrations, then the butanol may have been bad. For humid environments, you may have to change the butanol in your CPC periodically (e.g., monthly?, every two months?).

Open a terminal window and type
sudo date -u MMDDhhmmYYYY
Once that’s set, NTP should take care of the exact synchronization.

Open a terminal window and type the following two commands
sudo override /etc/ntp.conf
sudo nedit /etc/ntp.conf
Often all you need to do is uncomment the default server, but if they
use a different ntp setup you can find it by logging in to the existing
system and doing:
cat /etc/ntp.conf

Generally it means that either the time source isn't configured right (GPS on the wrong port, etc), it isn't behaving correctly (bad time server, GPS doesn't have a fix), or it isn't responding (server down, GPS not plugged in). You can verify that it's having a problem by running "ntpq -c peers" and making sure there's a line with a "*" at the start and that it has valid values. If you see a line with reasonable values but no flag code (or an "x") then it was likely rejected for some reason (ntpd thinks it's a bad time source).

You can see if it's a problem with the GPS not reporting by stopping ntpd (start it again after running this) then running as root:
ntpd -ddd -n
You should (eventually) see lines that look like GPS records (with a bunch of ntpd debugging information that isn't really useful). Youshould also also see lines about a refclock time if it's reporting valid times (figuring out why it isn't generally involves manually interpreting the GPS records). A common cause is that the system time is too far off the GPS time, so if it differs by more than a minute try setting it with 'date -u MMDDhhmmYYYY'.

You can see if it's a misbehaving time source by doing (with ntpd running) 'ntpq -c as', then use the "assID" of the server/GPS with 'ntpq -c "rv assID"'. The rootdelay, rootdispersion, offset, delay, dispersion and jitter should be reasonable, for example mine are rootdelay=1.129, rootdispersion=70.099, offset=-0.266, delay=0.238, dispersion=18.672, jitter=0.042. Similarly you can run "ntpq -c rv" to inspect the local clock and verify that the parameters for it are also sane (my computer currently has frequency=90.052, jitter=0.248, noise=0.215). Unfortunately for both these "sane" has a somewhat flexible definition, in the event of badly behaving clocks I often have to dig through the ntp source code to figure out why it rejected a clock.

If you don’t know the networking information but have access to the system, open a terminal window and type:
cat /etc/network/interfaces
Once you’ve done this, or if you know the existing networking information, type in a terminal window:
sudo livecpd2.setupnetworking

You need to generate a public/private pair of keys and copy the public key from your remote system to the LiveCPD system. In the example below, ${IP} is the IP address of your LiveCPD system.

1. Execute these commands on the remote system:
   ssh-keygen -t rsa
   # ^--- accept all the default answers
   scp ~/.ssh/id_rsa.pub cpd@${IP}:id_rsa.remote
   # ^--- provide the 'cpd' user password when prompted
   
2. Execute these commands on the LiveCPD system:
   override ~/.ssh/authorized_keys
   cat ~/id_rsa.remote >> ~/.ssh/authorized_keys
   chmod 0600 ~/.ssh/authorized_keys
   

The data are located in the /aer/${stn}/log directory, where ${stn} denotes the lower-case station identification code (e.g., "mlo" for Mauna Loa). A computer that has been configured to allow login to the LiveCPD system (at address ${IP}) without a password can download these files with the following command (all on one line):
scp -p cpd@${IP}:/aer/${stn}/log/*_2*_* .
Note that output buffering by the operating system causes these files to be a bit behind real-time, and to potentially have incomplete last lines.

Alternatively, a listing of the latest 30 minutes of aerosol data can be displayed by executing this command on the remote computer (all on one line):
ssh cpd@{IP} 'cpdrotate; sleep 5; ssh cpd@${IP} cnvth__ /aer/${stn}/log/AEROSL* |sort -u |tail -30'

Use of the 'cpdrotate' command causes the current output files to closed and the buffers flushed, ensuring that the most recent data are displayed.

The format of the displayed data is described at https://gml.noaa.gov/aero/data/datafmt.html#h_

There are several ways the contamination flag can be set: (a) based on a wind sector (b) based on a low or high wind speed (c) based on a CN concentration. These parameters are set in the cpd.ini file in the [AERMON] module. The contaminated bit will be set if any samples during the averaging period were flagged as contaminated (even if they were not averaged because of the above setting). Note: if you want the data values logged rather than replaced with missing value codes make sure that the following parameter:
Average_On_Contam=TRUE in the [AEROSOL] module is set to TRUE. If it is set to FALSE then the data will be replaced with missing value codes in the raw data.

There are three approaches that come to mind:
- manually add edits from cpx2 to invalidate the affected data;
- write a program to generate the edits, and merge them in to
the edit directives file;
- call a program from the edit correction chain.
None of these are simple, especially if the problem occurs regularly. The latter approach is the simplest, but it requires adding a line to a configuration file for every time interval that you need to edit.

Documentation for how the latter approach can be implemented is in the section "Correction Chain" at https://gml.noaa.gov/aero/software/aerosols/
The program 'data.edit.corr.field' (https://gml.noaa.gov/aero/software/aerosols/data.edit.corr.field.html) is used to do the work of invalidating the scattering data when on the sub-micron cut size. The call to data.edit.corr.field goes in the configuration file for data.edit.corr (https://gml.noaa.gov/aero/software/aerosols/data.edit.corr.html). Documentation on the configuration file is at https://gml.noaa.gov/aero/software/aerosols/corr.conf.html

I would not invalidate data or call the data contaminated if the pitot tube flow rate is not ideal. The reality is that there is a large range of flows down the stack whereby you still get basically the same answer for the aerosol quantities we measure. If there is ZERO flow down the stack, then that will cause a problem because the aerosol will take much longer to get from the top of the stack to the sub-sampling point(2-inch stainless tube inside stack). If the 850 lpm excess stack flow is only off by, say, a factor of 2, then we have aerosol that is SLIGHTLY enriched or depleted in large particles due to anisokinetic flow at the 2-inch inlet. Frankly, I have never been able to see anything of this effect.

We monitor this parameter to see if MAJOR changes in stack flow occur, thereby signaling that something is wrong. While you should strive for 850 lpm if possible, I would not be too upset sampling with the stack flow at 750 lpm or at 1000 lpm.

Config->Station Config
Select the "Graphs" tab
Select the "Flows" graph
Go to the "Axes" tab
Select the "Left" axis
Select "Exact Value" (if not already) for "Min" and "Max"
Set the values to desired range
Repeat for the "Right" axis
Click "Save"
Close the config screen and click Replot
Note: a similar procedure can be followed to change other plot parameters, e.g., color of axis label.

In the configuration screen at the top of the lists there is a button that looks like two documents on top of each other. Pressing this button will duplicate the selected object(s) within a station. After that you can use the button with a check mark to rename the new ones.

To transfer things between stations, there is a button that looks like a disk at the top of the lists. Using this button will export the selected object(s) and their dependencies (for example variables that are used in traces of a graph) to a separate XML file. After starting CPX2 for another station you can use the folder (import) button to load a file saved with the export. Importing a file will only import objects within that list (i.e. it will not load variables that the imported graph used, if they didn't already exist for the station; you'd have to import the same file in the variables tab to do that).

All of these buttons have a tooltip (help text which appears when you hover your mouse over the button) that details the function of the button.

https://gml.noaa.gov/aero/software/aerosols/cpx2.html

If you want to transfer files from your virtual machine to the host machine (if the host machine is running Windows), first download WinSCP (available free at http://winscp.net/eng/download.php) if you don’t have it already. Next you need to find the IP address of the virtual machine. On the virtual machine desktop open up a Terminal windows, and type in:
/sbin/ifconfig <enter>
look for a section labeled eth0, and a line titled "inet addr:"

for example, if I type /sbin/ifconfig <enter> on my computer here at NOAA I get:
> > eth1 Link encap:Ethernet HWaddr 00:0C:29:43:57:4B
> > inet addr:140.172.192.209 Bcast:140.172.192.255 Mask:255.255.255.0
> > inet6 addr: fe80::20c:29ff:fe43:574b/64 Scope:Link
> > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> > RX packets:572767487 errors:477387 dropped:24704 overruns:0 frame:0
> > TX packets:202373331 errors:0 dropped:0 overruns:0 carrier:0
> > collisions:0 txqueuelen:1000
> > RX bytes:1154124900 (1.0 GiB) TX bytes:3194454047 (2.9 GiB)
> > Interrupt:193 Base address:0x2080
> >

from this my IP address is therefore 140.172.192.209
you'll have a different IP address for your virtual machine.

Now on the host machine (your windows computer) open winSCP, and type in the IP address for aer_vm in the hostname field (confusing, but correct), and the username and password you use to log-in in the username and password fields, then click connect. Now you can drag files to and from the VM to the host machine! For example, if you got 192.168.35.120 for the ip address for aer_vm this is what your winscp login would look like:

Yes! You can use the xt2 command to get a basic averaged file. The xt2 command is described at: http://gml.noaa.gov/aero/software/aerosols/xt2.html. A couple examples here:
Hourly averaged data for THD for the month of January 2009 with a header:

xt2 –header –h thd 2009 1 2009 32

Daily averaged data for BRW for 2008 without a header:

xt2 –d brw 2008 2009

xt2 generates a file with the name al_*X.stn where * represents the averaging stype and stn is the three letter station id so for the two examples above the file names would be al_HX.thd and al_DX.brw. The format for the al_*X.stn file is described at the Aerosol Data Format Page

Why yes! A summer student (Michael Seltzer) developed a clickable powerpoint tutorial to walk you through various ways to extract the data you want from the db system.

Open a terminal window and type at the command prompt:
data.aggregate.nilu.archive --dryrun=<DIR> stn START END
Example 1:
data.aggregate.nilu.archive --dryrun=. alt 2009 2010
This will create a number of files in the directory identified by ‘dryrun’ that can be looked at before actually submitting to WDCA. Note: in this case, the given directory ‘.’ is the directory that the script is run in.
Example 2:
data.aggregate.nilu.archive --dryrun=/aer/alt/work/2010/ alt 2009 2010
In this second example the file is put in the directory /aer/alt/work/2010/. (The directory must exist prior to data being put in it!)

Run the following command: data.publish stn timerange
Example: data.publish alt 2009Q1
This will queue all data to be sent, if running on an AER_VM system. It will also prompt if you want to run the entire send immediately or ??

You should be able to use cpx2 to view the PSAP data during the zero test as a quick way to check the stability.
The command for doing the statistical analysis is shown below. Replace the times with the start and end times of your filtered air runs. Type this all on one line.
data.get wlg A11a 2010-04-22T01:43:45Z 2010-04-23T05:00:30Z | data.avg --stdev=on --interval=year | data.export --mode=excel > psap_stats.csv
alternatively, you could use year and DOY values:
data.get wlg A11a 2010:112.04 2010:112.80 | data.avg --stdev=on --interval=year | data.export --mode=excel > psap_stats.csv


Transfer the .csv file to a Windows computer and pull it into Excel. The header line gives the field names. The ones you want look like
BaB0_A11 BaB0g_A11 BaB1_A11 BaB1g_A11
and likewise for the green "BaG" and red "BaR" channels. The "0" denotes the PM10 size range and the "1" denotes the PM1 size range. The "g" in the header marks the fields with the standard deviations.

For the neph correction you would so a linear interpolation using the appropriate angstrom exponent. So to correct 550 nm scattering to 530 nm scattering:
angstBG=log(scat_450/scat_550)/log(550/450)
scat_530=scat_450*(450/530)^angstBG
example:
If scat_450=20 and scat_550=15 then:
angstBG=log(20/15)/log(550/450)=1.44
scat_530=20*(450/530)^1.44 = 15.8

To adjust the other two wavelengths you'd want to use the angstrom
exponent spanning the range of the adjustment.
angstGR=log(scat_700/scat_550)/log(550/700)
scat_667=scat_550*(550/667)^angstGR
and
angstBG=log(scat_450/scat_550)/log(550/450)
scat_467=scat_550*(550/467)^angstBG