Robs Notes

From Seamonster
Jump to: navigation, search


Introduction

This page contains notes on reorganizing this SEAMONSTER wiki. And related.

20080802 Mend Lake notes is the trip out to fix brick 58 and survey some temps.


Actions

  • Go to all pages called 2007 TinyOS and 2007 Mote
    • Collect their names into a template
    • Push that template into their top line
    • Also include a path-back-out to the current Koala/Fieldmote stuff
    • Scan these pages for content for the current stuff
  • Finish up the Hobo Protocol page
  • Investigate VPC as alternative for VMWare
  • Does an Excel time conversion get to within the second of python time conversion?


Brick 53 --> 58 at NSRL

ip address is 137.229.208.53


2008 GSA Houston

  • Roberts, Sheila, H2O Chem Ottowa River Lucat Cty Ohio
  • Ooids: ubiquitous carbonate particles
    • mixing line
  • teleost fish has ray fins (triassic)
  • CA vanadium limit is 5 ug/L: www.cdph.ca.gov
  • poly-functional carboxylic acids, <math>\Delta_f\;G^o</math>
  • diamicton is poorly sorted sediment for example in a pro-glacial tidewater moraine


To Process: From Marijke

  • The main puzzel is the timing of the two velocity peaks, the discharge peak and the lake drainage. The biggest problem with interpreting the data comes from the large rainfall event that occurs during the lake drainage.
  • The meltmodel run that I did didn't bring any useful results yet. I'll have to talk some more to Regine to see if we can match the data better.
  • Looking at the discharge data, it seems like the lake drainage can be seen in Lemon Creek before the lower GPS site even moves. Because of the rain events it's hard to tell when the lake drainage arrived at the USGS site.
  • Martin thought that the velocity of the wave moving down glacier was way too slow, compared to other studies. But I would like to talk to Will some more about changing stress states that cause waves to move down the glacier.
  • Could it be that there are different main channels underneath the glacier? Could water be stored in the lake at the terminus of Lemon?
  • Could water be stored in the upper part of the glacier? (Radar measurements of the bed topography would be great!)
  • Does the upper gps station react on the lake drainage, and the lower one on the rain event?
  • Was there a well developed drainage system at the lower gps station? Could this lead to the station not reacting on the lake drainage, but the extra input of the rain event would get it moving?


Here's a list of further questions and things to do:

  • Look at position changes in more detail instead of smoothed velocities
  • Look at last years drainage; it looks like there was a similar increase of stage during the lake drainage.
  • Get estimated volumes of lake lynda
  • Check if the gps stations have diurnal signals, how much do they react on melt and rain events?
  • Does the lower station react more on rain events?
  • How strongly does the lake lynda level react on rain and melt events? Is it possible to get the rise in stage during the lake drainage with constant drainage and extra rain input?
  • Eran: Can you look at the YSI data some more and let me know if you can identify the water from the lake drainage from that? Should we be using the turbidity data?


Marijke vel stage discharge met Nov10 2008.jpg


Marijke YSI stage discharge Nov10 2008.jpg


wiki and VuS to do list

  • 53 is at Cairn Relay (at lab as of 10/8)
  • 54 is at Cairn Met (status: uncertain (but on!))
  • 55 is in the lab, running munin
  • 56 is in pieces, not much left of it: Needs one PCS (have a spare SBC)
  • 57 is under assembly by Nick
  • 58 is at M&M Peninsula, status: probably a bad e2fsck


  • List of TOCs that need to be built
    • analytics! include ppt ft
  • List of TOCs etc to delete
    • Extensible Markup Language should gobble up the other ML pages; must write a very good usable introduction.
  • Clean up the main map
  • Network template
    • Doesn't include the Network Plan page which is part of another template.
    • Visit this template and crush through it
      • Particularly Network Plan should go away
      • with any valid content moved under the Network template.
  • Fix: Gen 2 User's Manual pdf was at rf.net/Brick
    • need to move to the pdf site and/or relink off of VuS template
  • Search on Monitor and you find 3 pages
    • that talk about monitoring system health.
    • Should be one, with emphasis on Munin.
  • Template idea modification:
    • Create a Mendenhall page: This will have a seamonster:map_mendenhall template
    • Some of the pages there will not include the mendenhall tempate
      • Instead they have whatever--maybe logistics or something; MET stations and such
      • But their template must link to Mendenhall and its template. So that acts as a bridge.
        • Maybe flag this is some way in the template
  • Fix: Add in some edited version of this:

Since you might be involved in swapping in Lithium D cells I wanted to point out a couple things while I’m thinking about it.


First, these batteries are HOT. They typically run around 3V, so you want to expect a reading around 6V when they are ganged 2 in series. 


Second, these batteries have NASTY solder tabs that reach a long ways. Meanwhile the brick batt clips have lots of spare metal exposed. This is a recipe for short-melt-smoke-fail. So you have to cut off most of the solder tab on each battery and exercise extreme caution when installing them. I recommend working with a lab microserver and following these steps; all along you are watching for little wisps of smoke or other signs of shorting. If this happens the batteries will be hot and the wires will try to burn your hand. It really sucks. So we’re going to do this the slow methodical way rather than the Rob way (which is burn yourself a bunch of times, get pissed off, swear, and melt boards).


1.	Cut off the solder tabs so that only small electrical contacts are left
2.	Clear away any extraneous / blocking cables from near the clips
3.	Disconnect the battery and external power leads from the PCS board
4.	Make sure that the battery clips are fastened securely to the base plate with nylon screws
a.	(Nylon shouldn’t really matter; examine the clips carefully to see why…)
5.	Also examine the wiring on the clips to make sure they are all free and clear of accidental short potential
6.	Wrap electrical tape around any exposed metal (batts, clips, solder tabs, wiring) to reduce contact-short potential
7.	Make sure you got your batt polarities are all lined up ok 
8.	Drop in the first pair of batteries, being ready to PULL THEM IMMEDIATELY
9.	Keep your hands on these batteries for 2 minutes. No kidding. 
10.	Drop in the second pair, same deal.
11.	Keep your hand on these batts and the other hand on the other batts for 2 minutes.
12.	Check the output voltage on the battery lead: Should be about 6V
13.	Plug in the batt lead to the PCS board with the slider switch off: Again touch batts for 2 minutes
14.	With no external power connected to the PCS board: slide the slider switch to ON
15.	Touch batteries for 2 minutes
16.	Slider off, connect external power, slider ON, brick should boot
17.	Touch batteries for 2 minutes


Let the system run for ten minutes touching the batteries a few times. Check voltages. Once you’re satisfied that the damn thing isn’t going to catch fire you can walk away. Entire process ought to take about 30 minutes after you practice it in the lab a couple times. 


  • Fix: Add in some edited version of this:
Possibility 1: There is an available DIO pin coming off the microcontroller that you can turn Hi/Lo using code running on the SBC. This would be the quick solution assuming you are running some sort of crontab process or Agent program which can in turn run the /root/bin/ucInterface program. Physically it requires you to attach your control wire to one of the pins on the PCS board which is in turn connected to a ADC-OR-GeneralPurposeDIO pin on the microcontroller (A/GP). There are two such and we refer to them as A/GP-1 and A/GP-2. 


On the PCS board is a 4-pin jumper called J3. Going from "south to north" the first pin is A/GP-1 and the second pin is A/GP-2. The firmware configures both of these by default as output DIO lines. If you issue "ucInterface 1 28" then A/GP-1 should go to 3.3V, if you issue "ucInterface 1 29" it should go to 0V. See this page: 


http://robfatland.net/seamonster/index.php?title=Gen_3.2_SBC_Operations


for the listing of what "ucInterface 1 X" does. 


See


http://robfatland.net/seamonster/index.php?title=Gen_3.2_SBC_Ops_ucInterface.c


for the code listing. 


You could also use A/GP-2 btw. Hopefully these voltages are correct, functional and will be able to source enough current or whatever to affect what you are turning on/off. I've used A/GP-1 before and it worked properly. 


The second option would be to look at the TS-7260 user's manual 


http://www.embeddedarm.com/documentation/ts-7260-manual.pdf


and find the pin-out for either DIO-1 or LCD. I think DIO-1 might be preferable as we are using it as the SBC-send and it pushes 0 / 3.3V. LCD port runs at 5V. We are only using FOUR of the 9 DIO lines to talk to the microcontroller on PORTB: DIO 4, 5, 6, and 7. Therefore you could use the low bit, say DIO_0, to drive your device. You'd have to be careful not to scramble the 4567 bits which could confuse the microcontroller. Here again the ucInterface and 'bc' programs have example code on how to address these bits as memory.


Here roughly is a procedural for getting this to work:


- Look up which physical pin corresponds to the DIO_0 bit on DIO1 port. 
- Write a little program which toggles this bit in the register every second.
- Look for the toggling voltage on the header when the SBC is running that program.
- Identify the corresponding wire within the ribbon cable coming off that port
- Perform surgery to pull that wire out of the ribbon cable and connect it to what you want to control
- Ensure that your toggle program is not affecting Bits 4567 of DIO1


Once you have that good you could integrate everything into your operational scheme. In a perfect world DIO_0 (which see page 31 of the Users Manual) is on DIO1 Pin 1, which means it might be the red/edge wire on the ribbon cable.


Per earlier email: Beware these ribbon cable - header connections as any stress/tension on the cable will cause it to pull up off the header, killing your communication between SBC and microcontroller.



Microserver desiderata

  • Agent
    • No camera between 9pm and 6am, say
    • If bricknum == 58: Manually turn on WDT
    • To avoid PORT collisions we need some careful utilities
      • Semaphor /root/PORTSINUSE
      • Use a killAgent command to create /root/AgentDie;
        • The Agent in its inf loop looks for this file, deletes it, and halt
    • Periodically turn Agent.log files into inbound log files
    • Log power events as data
    • Clean up /root/bricmove/expired/*.log


  • Other Soft
    • Matt wants some key info in /etc/motd
    • Matt wants some higher-level utilities
    • Rob wants a Bounce utility so Bounce.c in svn
    • Rob wants a path for root so .bashrc in svn
    • put camera grabs in more systematically
    • Make sure Marijke does something nice with .log files she can't parse
    • Make the enclosure bigger
    • Go to the eval page and incorp all that
    • Make the SD card pullable
    • Put the crontab in a cron file which is also in svn
    • /etc/hosts on svn so everyone knows everyone


  • Hard
    • Nick wants a latched case, Rob wants a lock hasp
    • Nick wants a USB thru that stays put
    • Matt wants a carry handle on the case... and backpack straps
    • Ammeter
    • Move all the circuitry AWAY from the thru mounting holes
    • Double mounting or flex-mounting design to accommodate different hole configurations / different SBCs
    • Bigger box
    • Instructions laminated


Data Desiderata

  • Accommodate Hydrologic Unit
  • Query: When On / When Off
  • Make location also be data
  • Handle photos / blobs and time sequence imagery


List of TOCs that exist

map
map_microserver
map_environment
map_motes 
map_deployment
map_data
map_howto
map_presentations


crit data browser

  • Number one: Pick some visitors and make the site work for them (hs student,
  • Runtime of stations is not updating live and needs breaks for dropouts.
  • The left pulldowns should fit on single lines
  • Need a Help link with the basic info, FAQ, ...
  • Make the disclaimer-ness of Browser very clear
  • Browser only goes to todays date at mignight, would be better if it would go to the present hour.
  • Data dropouts are a bit problematical; at least flag them with another color?
  • Can we read the data window (java / CSS person) to provide data from only a particular time range?
    • We do have the non-integrated approach on download where you re-type the date range; klunky
  • Can see two data records superimposed; we'd like to do more than just 2.
  • Bad formatting: When you click on one: We see other of the same unit below (badly formatted)...
  • We'd like to superimpose more than one data type
  • Rob would like radio buttons on the various sets so I can build new plots without going back
  • When you click on that second dataset you should stay in the current time range, not reset
  • Josh would like a youtube-style bubble interface
  • Marijke would like click and drag to pull up datasets
  • We would like to reinstate semi-trans yellow circles over the stations
  • Would like a map-driven pop up of the station expansion on left sidebar
  • Works with Firefox; ought to work with Safari and/or IE
  • Basic formatting, background color, etc....
  • Revisit the way the plots are done: Make sure it is useful (wind direction, precip, ...)
  • DBase comments could appear on the data server, like on the graph: Hey we pulled the sensor...
  • How bout click on the data and make a wiki entry...
  • IE data download page doesn't see the line breaks
  • I asked for some xls data and it gave me a disconnected handle error...
  • It also didn't like exceeding a sheet name 31 char limit so I went to csv; that worked.


Rob as data analysis interrogator

  • Looks at discharge LC and temp and precip Lower LC and Upper LC...
  • Discharge USGS data is scanty; other stuff basically mid-March thru mid-September...
  • Using sciscope: What are the units? What is the censor code? The hell? How come I can't get data from every 15 minutes? Why must I be content with daily averages?


Note to Matt on gappy data

I pulled a bunch of met data for the Mend terminus and found it gappy. This is fine but it is a pain to plot in Excel with other data that is not gappy or has different gaps.


Let’s face it, Excel is a pain (for our kinds of data). What I need to do is write a CSV parser that creates no-data entries in a regular time series from a gappy time series, and I need to write a data synchronizer that takes two time series datasets and makes them live on the same time stamps. For example one sample / 15 minutes should be easy to plot with one sample / minute data.


Excel does allow two datasets with the same horizontal axis but different units on vertical axis, so that's a plus.


What I did with the Mendenhall met data using Excel was generate a non-gappy time column and then insert blank lines in the gappy data until the times all matched up. This took like a couple hours. Then I used the non-gappy time column with the gappy met data with blank lines to generate plots.


What could be done in generating CSV files is to say “Here is the next time in the series; I will generate a line for that data and if no data exists then the data value will be “no data”.” That is, this could be done by the data server.


I’m not saying this is a high priority; it would just be a step towards making datasets interoperable. I’ll make the data tool I described above a priority on my list of coding projects, will let you know when I git it writ. Also Matt maybe you said the data is there but just fell through the cracks on ingest, so this is a reminder on that.