diff --git a/.gitignore b/.gitignore index b78bb33..27bc5aa 100644 --- a/.gitignore +++ b/.gitignore @@ -21,7 +21,6 @@ agate/draft/ .Rhistory .RData .Ruserdata -*.Rproj /.quarto/ /_site/ diff --git a/agate-public.Rproj b/agate-public.Rproj new file mode 100644 index 0000000..d063e8b --- /dev/null +++ b/agate-public.Rproj @@ -0,0 +1,13 @@ +Version: 1.0 + +RestoreWorkspace: Default +SaveWorkspace: Default +AlwaysSaveHistory: Default + +EnableCodeIndexing: Yes +UseSpacesForTab: Yes +NumSpacesForTab: 2 +Encoding: UTF-8 + +RnwWeave: knitr +LaTeX: pdfLaTeX diff --git a/agate/agate.m b/agate/agate.m index b2365ca..2e09303 100644 --- a/agate/agate.m +++ b/agate/agate.m @@ -36,7 +36,7 @@ function agate(missionCnf) global CONFIG % CONFIG = struct; -CONFIG.ver = '0.1.20230629 github.com/sfregosi/agate-public'; +CONFIG.ver = '0.1.20240309 https://github.com/sfregosi/agate-public'; fprintf(' agate version %s\n\n', CONFIG.ver) if nargin < 1 diff --git a/docs/convert-acoustics.qmd b/docs/convert-acoustics.qmd index 361480e..f1dfeb2 100644 --- a/docs/convert-acoustics.qmd +++ b/docs/convert-acoustics.qmd @@ -18,7 +18,7 @@ Additionally, following a mission in Spring 2023, a bug in the WISPR firmware wa See [`workflow_convertPMAR.m`](https://github.com/sfregosi/agate-public/blob/main/agate/example_workflows/workflow_convertPMAR.m) in the `example_workflows` folder for a simple example workflow for converting a mission's PMAR .dat files to .wav. -Like other workflows in `agate` it must first be initialized with a mission-level configuration file (e.g., [agate_config_example.cnf]( https://github.com/sfregosi/agate-public/blob/main/agate/settings/agate_config_example.cnf)). Only the top *REQUIRED* and `CONFIG.pm` settings in the *Acoustics* sections of the configuration file are needed for file conversion. +Like other workflows in `agate` it must first be initialized with a mission-level configuration file (e.g., [agate_config_example.cnf]( https://github.com/sfregosi/agate-public/blob/main/agate/settings/agate_config_example.cnf)). Only the top **REQUIRED** and `CONFIG.pm` settings in the **OPTIONAL - acoustics** sections of the configuration file are needed for file conversion. Additionally, a PMAR conversion configuration file (e.g., [pmarConvert_example.cnf](https://github.com/sfregosi/agate-public/blob/main/agate/settings/pmarConvert_example.cnf)) is needed. This contains the specific paths and is where you can set your desired conversion settings. Detailed descriptions of each parameter setting are in the example configuration file or can be found on the [Configuration](./configuration.html#pmar-conversion-configuration-file) page. @@ -34,7 +34,7 @@ Additionally, a PMAR conversion configuration file (e.g., [pmarConvert_example.c ## Fix WISPR gain bug -A bug was discovered in WISPR in spring 2023 (should be fixed now??) that leads to sound recordings that look like they have variable gain settings applied on different files. One file would be half as loud as the next (6 dB gain change?). For more info on this bug, contact Chris Jones. An imperfect, but workable fix was developed with C. Jones and is included here just in case someone else would find it useful or if the issue arises again in the future. The below instructions are a outline/draft of documentation for this hopefully one-off issue, so please reach out if you encounter the same problem or need further assistance. +A bug was discovered in WISPR in spring 2023 (should be fixed now??) that leads to sound recordings that look like they have variable gain settings applied on different files. One file would be half as loud as the next (6 dB gain change). For more info on this bug, contact Chris Jones. An imperfect, but workable fix was developed with C. Jones and is included here just in case someone else would find it useful or if the issue arises again in the future. The below instructions are a outline/draft of documentation for this hopefully one-off issue, so please reach out if you encounter the same problem or need further assistance. This process assumes you have initially converted the .dat files to .wavs, and in looking at those .wavs, noticed an issue. Those 'bad' .wavs will be used to make decisions about file gain adjustments so those need to be retained. Then, this process will *reconvert* the .dat files into .wavs, making adjustments to the expected gain if needed, as assessed following a set of rules or according to manual user input.