Skip to content

Commit

Permalink
Merge pull request #39 from sfregosi/dev
Browse files Browse the repository at this point in the history
Dev - pmar convert example and documentation done
  • Loading branch information
sfregosi authored Mar 9, 2024
2 parents 4f7b08a + 69ad754 commit d136a14
Show file tree
Hide file tree
Showing 4 changed files with 16 additions and 4 deletions.
1 change: 0 additions & 1 deletion .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,6 @@ agate/draft/
.Rhistory
.RData
.Ruserdata
*.Rproj
/.quarto/
/_site/

Expand Down
13 changes: 13 additions & 0 deletions agate-public.Rproj
Original file line number Diff line number Diff line change
@@ -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
2 changes: 1 addition & 1 deletion agate/agate.m
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
4 changes: 2 additions & 2 deletions docs/convert-acoustics.qmd
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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.

Expand Down

0 comments on commit d136a14

Please sign in to comment.