Certainly during the initial campaigns, CARMA data were written with a rest frequency equal to the starting frequency in the first window of the LSB. This is most likely wrong for your data. Look again at the output of uvlist:
% uvlist vis=xxx.mir options=spec rest frequency : 100.27057 100.27057 100.27057 100.27057 100.27057 100.27057 starting channel : 1 16 31 46 61 76 number of channels : 15 15 15 15 15 15 starting frequency : 100.27057 100.73054 101.19050 104.33300 103.87304 103.41307 frequency interval : -0.03125 -0.03125 -0.03125 0.03125 0.03125 0.03125 starting velocity : -23.654 -1398.978 -2774.302-12170.599-10795.275 -9419.951 ending velocity : 1284.502 -90.822 -1466.146-13478.755-12103.431-10728.107 velocity interval : 93.432 93.432 93.432 -93.432 -93.432 -93.432
To fix this, you can set the restfreq variable to the (in this case CO 1-0) line you are interested in:
% uvputhd in=xxx.mir hdvar=restfreq varval=115.271203 out=yyy.mir
The drawback of this procedure is that the uv variable is now ``promoted'' to a (miriad) header variable, and in the process losing any potential time variability as well as (in this case 6) dimensionality.
At this stage it is perhaps useful to remind you of the difference
between a UV variable, which can be viewed as possibly
time dependant variables, and a header item. Both are
present in UV datasets.
The program uvputhd can operate on UV variables. Technically
they live in the DATASET/visdata item. On the other hand,
scalar items can be manipulated with puthd. If you create
an item with the same name as a UV variable, that UV variable has
now been made time-independent and is hidden from view until
you remove the item with delhd.