We're working to get the calculations for the SUSpoint motion in the IFO basis installed
see ECR E1600028 ,
FRS issue 4694 : https://services.ligo-la.caltech.edu/FRS/show_bug.cgi?id=4694
and totally-out-of-date Tech doc T1500610 

here is an updated white-board drawing showing what we want to do.
It is weird because:
1) ISI models are not attached to the RFM network, so we need to pipe the data to another model first and PEM has lots of extra time
2) We really want 2 channels, but both are pretty slow, so Joe B made us a multiplexer to save RFM data.


-- email chain here so I don't lose it --


From: Jeff Kissel 
Subject: Re: SEI RFM channels from end to corner.
Date: March 24, 2016 at 4:34:30 PM PDT
To: David Barker 
Cc: Joseph Betzwieser , jim warner , Dave Barker , "Vern Sandberg" , Keith Thorne , Hugh Radkins , Joe Betzweiser , Rolf Bork , Brian Lantz 

Hey Dave,
	Yup, next Tuesday for removal.

Cheers,
Jeff Kissel


On Mar 24, 2016, at 3:42 PM, David Barker  wrote:

Hi Jeff,

yep, I’ll confirm with Daniel if we can get rid of the sender-with-no-receiver RFM channels.

Are we planning on giving this a try next Tuesday, and if so on one or both arms?

cheers,

Dave



On Mar 24, 2016, at 15:34, Jeff Kissel  wrote:

Hey Joe,
	Thanks for putting this together. 

Hey Brian,
 	Are we definitely going this MUX route to save on transmission channels?

Hey Dave,
	Side statement: we should also clean up all of the RFM channels you’ve identified as unused here

in the end station ALS, ISC, and corner station OAF models too.

Cheers,
Jeff Kissel
Controls Engineer


On Mar 24, 2016, at 2:06 PM, Joseph Betzwieser  wrote:

Hi,

Just want to provide an update on the MUX code.  In the prior e-mail I had indicated I had not done full testing of all functions.  I have now done so on the LLO test stand, and after some minor copy/paste bug fixes in the 4 and 8 channel versions, all currently coded functions are working as expected.

This includes functions for combing 2, 4, and 8 channels together and then demuxing them at the end, assuming the same data rate throughout.  In addition, there is a demux function for a 2 channel input which can handle a 4x data rate change from slower to faster (i.e. 4 kHz to 16 kHz).

If/When needs change, its fairly simple to copy the current functions and change them to different data rates or number of channels.
Again, links to code are at:

https://redoubt.ligo-wa.caltech.edu/websvn/filedetails.php?repname=cds_user_apps&path=%2Ftrunk%2Fcds%2Fcommon%2Fsrc%2FLOW_FREQ_MUX.c

https://redoubt.ligo-wa.caltech.edu/websvn/filedetails.php?repname=cds_user_apps&path=%2Ftrunk%2Fcds%2Fcommon%2Fsrc%2FLOW_FREQ_DEMUX.c

I am to use these in the code we are planning to push next Tuesday for the ISI RFM communication to the corner.

Cheers,
Joe


On Wed, Mar 23, 2016 at 1:03 PM, Joseph Betzwieser  wrote:
I forgot to attach the pdf.

Here it is.

Joe

On Wed, Mar 23, 2016 at 12:22 PM, Joseph Betzwieser  wrote:
Hi,

Based on the discussions I had with Brian Lantz, I've put together a very simple diagram this morning describing what I think is what we should do for the RFM communication.  I don't remember the exact channel names (and there may have only been 1 channel going from the corner to the end), but I think the attached pdf is generally correct.  At the vary least its a discussion starting point.

I'm working under the assumption that the IPC problems are on the reading end (i.e. each RFM read takes 1-2 microseconds), so that sending is not an issue.  Given Brian Lantz wants to read out channels into OAF, that read in can't be avoided, although we can condense it down to 1 channel per end via Muxing.

I've written a number of user C functions in /opt/rtcds/userapps/release/cds/common/src/LOW_FREQ_MUX.c and LOW_FREQ_DEMUX.c

Links to code are:

https://redoubt.ligo-wa.caltech.edu/websvn/filedetails.php?repname=cds_user_apps&path=%2Ftrunk%2Fcds%2Fcommon%2Fsrc%2FLOW_FREQ_MUX.c

https://redoubt.ligo-wa.caltech.edu/websvn/filedetails.php?repname=cds_user_apps&path=%2Ftrunk%2Fcds%2Fcommon%2Fsrc%2FLOW_FREQ_DEMUX.c

The idea is you take data from 2 different channels, one on an even cycle, then one on the odd cycle.  In this way you can transmit two 8 kHz channels over one 16 kHz channel, for example.  

I've tested some but not all of these functions, so the principle seems to work fine.  You will need to add low pass filters before and after to clean up the data transmitted.

Joe

On Mar 22, 2016 6:49 PM, "David Barker"  wrote:
Hi Brian,

sounds good, let’s plan on trying this on H1 next Tuesday and discuss the details tomorrow.

Dave


> On Mar 22, 2016, at 16:41, Brian Thomas Lantz  wrote:
>
> Dave,
> I’d like to install that RFM sender into Hanford next Tuesday so we can get the suspension point motion from each end to the corner at LHO.
> Can we discuss briefly at the CDS call on Wed?
> Joe B has a suggestion for plumbing, since the SEI models are not attached to the RFM network.
>
> Thanks
> -Brian
>