VMT Time check

2024-04-19 20:45:07 VMT-1564554 PC Time 2024-04-19 20:44:11 UTC

VMT clock about 1 minute ahead of actual time.

184 detections (16 unique) both cod missions

AD2CP turned back on, same settings as previously (filename)

*this note meant for RU38 - copied to RU38's notes. Disregard here for RU34.

Back to battpos flying, changed query/telem interval for OBSVR to see if file size goes down for OBS files.

Huge wind event and power getting low. Turning off Observer for the day. Going a bit faster.

Back to .4 rad AP pitch control and a bit more pump, heavy wind/currents for the next week. Try to stay in zone.

File space check: approximately 1% ever 5+ days. currently at 6% capacity

From Chris talk

* he predicts 1% file space every 7 days or 1.68 GB/day
* Our unit has 1 TB not 500 GB
Things across serial line
* Status query:
% stroage
batt volt
temp
processing mode
* Detections in raw binary
* noise alerts

Query Interval not very useful, its only for status messages not detects or noise. Those are real time and it has some logic to re-send messages

Since deployment, roughly:

# Low density abort stuff
sensor: u_abort_min_burn_time(sec) 600 # Never drop the weight before this time
sensor: u_abort_max_burn_time(sec) 86400 # 24 hrs, at least a tidal cycle, Always drop the weight after this time

sensor: u_reqd_depth_at_surface(m) 2

# Steering params
sensor: u_hd_fin_ap_run_time(secs) 12
sensor: u_hd_fin_ap_gain(1/rad) 1.50
sensor: u_hd_fin_ap_igain(1/rad-sec) 0.015
sensor: u_hd_fin_ap_dgain(sec/rad) 6.00
sensor: u_hd_fin_ap_hardover_holdoff(sec) 30.0
#sensor: u_heading_deadband(rad) -1

# Altimeter settings:
sensor: u_alt_min_depth(m) 15 # average depth > 30 m, don't know if it saves power though
sensor: u_min_altimeter(m) 3.7 # in, altimeter reading must be between these(inclusive)
sensor: u_max_altimeter(m) 50.0 # the maximum range of the altimeter
sensor: u_alt_reqd_good_in_a_row(nodim) 2
sensor: u_alt_filter_enabled(bool) 0
sensor: m_altitude_rate(m/s) -1 # negative avoid the bug

# Pitch params
sensor: u_pitch_ap_gain(1/rad) -1.0 # -3 default
sensor: u_pitch_ap_dgain(s/rad) -1 # 1 default
sensor: u_pitch_ap_deadband(rad) 0.079 # .079 = 4.5 deg
sensor: f_battpos_deadzone_width(inches) 0.2 # .2 default
sensor: f_battpos_db_frac_dz(nodim) 0.625 # .5 default

# Slowing the pitch down - 10/7/20 took a quick look at ru34 dbd and it looks like defaults do well, it runs hot until about 6 m down and then starts doubling
sensor: u_min_pitch_ap_period(sec) 30 # runs no faster
sensor: u_max_pitch_ap_period(sec) 60 # runs at least this often

Previous SFW power analysis:

No observer or other sensors: 46 mA, with optics, optode, and ctd: 125 mA
With observer on: 263 mA, with other sensors: 340 mA

Current Rev Wind: Observer only: 255 mA, 330 mA with optode and ctd and observer

Appears as via data that Observer is drawing power through first segment downloaded, will watch if that continues seamlessly through each segment.

Previous deployment (SFW) deeper analysis:

.4 % reported in 23.8 days

Glider said same storage 976187 MB, other option is 536500 MB

.4% is 3.9 GB or 2.1 GB based on above. Neither of those make sense. We have collected at least 40 GB. It is a factor of 10 off from the first number....

1/19 AM obsvr storage check

Observer reports 976187 MB storage capacity. In logs I can only find 59.5+477 GB = 536500 MB

% storage used just jumped from 0 to .1%

That means we have used either 536.5 MB or 976 MB so far in 7 days

Previous deployment we used roughly 38 GB / 26 = 1.5 GB/day OR if all is working closer to 616 MB / .3 days = 2 GB/day

Both scenarios seem to put us way under in terms of storage usage.

ru34 pump with 50 m gearbox

Lithium Primary

Operating System: 10.08

Seabird pumped CTD
9698
3/18/2022

flbbcdslc
6649
1/27/2021

Aanderaa Optode Oxy3835
970
6/19/2023
In-house check: 12/20/2023

Jasco OceanObserver
1091

VMT
1564554
ID 51593