Support Engineering Group : OASIS Moorings This page last changed on Dec 01, 2010 by kgomes. Something from an email from Rich:
    I ran some tests yesterday...

    1) I STRONGLY recommend looking at your cfg file in a hex editor before
    attempting to upload it to make sure that it has a cr lf line terminators.
    That is hex 0D 0A
    You may have multiple pairs between lines but you must at least have the 0A
    It wont look right in notepad of you are missing the pair, and it wont work
    when gets on the controller in certain send scenarios, so don't do it if its
    not right!!

    Some text editors - like ones that ask 'Do you want to convert to DOS' or
    something similar may cause a problem - but xfering w/hyperterm definitely
    can cause problems regardless of the editor you use depending on your coms
    settings.

    If the file 'looks right' in notepad, that's a good sign but still - look in
    a hex editor!!  XVI32 works quite well and is freeware
    http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm

    OK, here is what I found....

    2) ABSOLUTELY::: upload to a temporary file on the controller ** NOT TO
    OASIS.CFG !!! ****. They type it back to see that its not "all on one line"
    then its probably safe to rename it to oasis.cfg and reboot.

    3) It makes a big difference to hyperterm if you are at the OASIS> prompt or
    in picodos...

    4) Craig etal suggest going from picodos with a yr command, but I don't like
    to because if you forget your connected via radio you may be SOL for 30
    minutes because you'll probably kill the radio driver and have to wait for
    32 minutes for the hardware to rest(I have not tested that, Im trying at my
    desk right now...).

    5) I prefer to use "capture" command and motocross but you need a version
    that has the "Transfer>SendBinaryFile" menu item. (eg. v2.32 has it, an
    older version that Paul found out at sea did not)

    6) If you must, you can use hyperterm with the capture command and
    "Transfer>SendTextFile" but you ***ABSOLUTELY MUST FIRST SET "Send line ends
    with line feeds" PRIOR TO TRANSMITTING THE FILE***   My tests show that
    using capture at the oasis prompt with this setting off, causes hyperterm to
    strip the lf in your cfg file.  Then the file on the controller appears as
    all on one line when typed back.

    7) Motocross "send binary file" works from either the picodos or OASIS>
    capture command (as long as you obey rule #1)  In all cases, its "Comm
    Settings > "Send LF after CR" was un-checked.

    8a) Hyperterm works ok from OASIS> prompt IF the "Send Line ends with Line
    Feeds" is TRUE. (but you may later want to reset it to false so you don't
    get "Double OASIS> prompts"
    8b) Hyperterm works ok from picodos C:\> prompt IF the "Send Line ends with
    Line Feeds" is FALSE. (also will work ok if TRUE but then you get the double
    prompt symptom.

    *************************** THE BOTTOM LINE(S) *****************************
    USE dumb editors, check line endings with XVI32 to verify Rule#1 and xfer to
    a temp file (Rule#2) using MOTOCROSS !!!!
    (Or only if brave or hardwired to console port, you can use yr from picodos)
    ****************************************************************************

    If your forced to deal with an oasis.cfg file that may not have correct line
    endings even though it looks ok in notepad....  and you have no hex editor
    to verify...
    (eg. When you upload the file per recommendations above, it still is all on
    one line) It seems in my quick testing that you can use notepad to add extra
    lines at every line and then re-upload...(you will have line endings in hex
    editor of 0D 0D 0A which still seems to be ok with OASIS>)

    Curious if anyone else has experiences that differ from above, it would be
    great to nail this down and cookbook it along with how to recover if you do
    screw things up......

    -Rich
    If you mistakenly issue the "reset pico" command while connected to the
    radio port, you will loose contact... The only ways to get it back are to:
    1)Bounce the power
    2)Wait ~32 minutes for the hardware reset (plus the wait for the radio
    wakeup procedure)

    Fortunately in the next release of code (still in testing), Bob added a
    warning message with a Y/N to remind you your on the radio... (Thanks Bob!)

    And please correct my last.... re:  picodos using yr (ymodem receive...) is
    from hyperterm (motocross doesn't support ymodem file xfers....)

    -Rich
And from Paul:
    Another follow up to this thread... sorry for the overkill.

    We successfully transferred a new oasis.cfg file to 2010M1 via radio
    link on Tuesday afternoon.

    The file was edited with a hex editor to include the correct 0D 0A line
    terminators.  There were places where there were two in a row (0D 0A 0D
    0A) but in no cases were there multiple 0Ds before a single 0A as I've
    run across in some other oasis.cfg files that are floating around (0D 0D
    0A).

    Once the file was edited and double checked, we transferred it according
    to Rich's procedure in #6 below and detailed here:

    -Establish link with mooring
    -At oasis prompt, type "capture [filename] <enter>"
    -Go to HyperTerm properties, 'settings' tab, click 'ascii setup' button,
    check 'Send line ends with line feeds' button
    -Go to HyperTerm Transfer menu, and select 'Send Text File...'
    -Select file to send and wait for file transfer
    -At oasis prompt, type "^D" to close capture on oasis
    -Go back to HyperTerm properties and uncheck 'Send line ends with line
    feeds'
    -Check file on can to make sure it looks right (at oasis prompt, type
    "type [filename]")
    -If all looks correct, rename files (oasis.cfg to [oasis.bk?] and
    [filename] to oasis.cfg) and reset mooring.
    -Sacrifice a small animal (or vegetable for the vegetarians) to the
    mooring gods
    And finally...
    -Blame Rich if it doesn't work for you

    Just wanted to document the successful file transfer over the radio.
    The mooring came back immediately, and everything appears to be working
    well.

    Paul

    P.s.  In #1 below, Rich says that he strongly recommends checking the
    file in a hex editor.  I think this should be an absolute requirement.
From Paul again:
    A couple of notes regarding the oasis.cfg file issue from Wednesday's deployment:

    First off, we were NOT able to modify the config file with the new pCO2 constants before it was deployed...
    Attempts to transfer the new file to the controller on the buoy did not appear to work, and looked (for about ten minutes there) like it corrupted the entire oasis directory.  Due to past issues of corrupting the oasis controller with bad oasis.cfg files, and the above scare that the oasis directory was destroyed while on the way out to deploy the buoy, I was unwilling to continue attempting to get a file across to the controller.  So unfortunately the constants are not correct for the pCO2 that is on the buoy.

    Secondly, the config file needs to be in its deployment form at the time the oasis can is closed!!
    Because there are some idiosyncrasies with this file transfer, having it on the bench gives plenty of time to recover if there is an issue.  As of a week before deployment, the entire systems should ideally be hands off, and this definitely needs to be the case for all software/firmware on the can.  Further bench testing (Thanks Rich!!) has shown that we may have nailed down the problem with the file transfer, but until additional testing shows that we can reliably do this over the radio on the buoy, no changes should be made after the can is closed.

    Some pCO2 specific thoughts:
    I know it's been this way for a long time (forever?), but why are the pCO2 constants contained in the oasis.cfg file?  This is the only instrument-specific information contained in the oasis.cfg file (other than driver info); what would we need to do to bring them out?  Ideally we would have them on shore for post processing, but if they need to absolutely be on the buoy, can they be in a separate file (pCO2.cfg maybe)?  Maybe have a line in the oasis.cfg that would point to the pCO2 config file?  With this information no longer in the oasis.cfg file, there is not the same danger of hanging the entire buoy if the file becomes corrupt in the transfer.  It will also allow us to change the pCO2 constants if the instrument ever needs to be swapped in the field.  I'm sure this has been considered before... I've either forgotten the answer, or wasn't in on the discussion.  Apologies if I'm digging up old info.

    Thanks,
    Paul
And from Bob:
    On another note, if we can *ever* get up to speed with the most current
    checked-in code, (that is, if we can switch to the new radios and
    wire protocol), it's worth noting that this new code also has some
    line editing features.  They've turned out to be extremely useful
    for the respirometers, which are based on Oasis and where the line
    editor commands originated.  Allows you to add, delete, and comment-out
    lines in OASIS.CFG in situ, which greatly reduces the need for
    transferring files.
    -Bob

Document generated by Confluence on Feb 03, 2026 16:22