I’ve been extracting video and images from Jason dive J1096, which occurred after the installation of COVIS. This dive focused on temperature and flowmeter measurements of venting sites on Mushroom and Inferno, and includes quite a bite of close-up video of both vents. The wide-angle video is generally not as usable as J1092: the science instrumentation visible on JASON’s “porch” occludes some of the field of view, and the ROV generally spends less little time loitering, instead focusing on the sampling mission.

All videos captured by ROV Jason during the 2018 Cabled Array Visions18 Operations and Maintenance Cruise, please credit: UW/OOI-NSF/WHOI; Visions 18 Unless otherwise noted, videos are from Jason dive J1092, which took place on July 27th on the third leg of the operations cruise off the R/V Revelle, cruise rr1812. Cruise meta-information available in the WHOI VirtualVan. Survey of Mushroom and Inferno, mp4, 169MB. Not a great view; there’s a lot of backscatter from suspended solids, but Jason is able to see both vents and CamHD, providing a good contextual view.

Contents Introduction Primary sources Overview of Ashes Orthomosaics East face South face West face North face Major vents on the lower half of Inferno SE base vent North side protruding vent Venting on crown of Inferno North slope cluster NE vent SW vent Proposed placement Calculating scale Revision history Todo Add CamHD to map 5/13/19: I’ve added a second page with a closer examination of the North Face vent.

Since I’m a bit of a masochist, I decided that I would try running RancherOS on the nodes of my in-house compute cluster. Actually, let me back up. Since I’m a masochist, I decided to run my own compute cluster. And since I’m really a masochist, I decided to try running RancherOS as a guest OS on some sort of hypervisor. I decided to start with Xen because Open Source, although I did consider the free tier of VSphere.

I’m supporting a project which will install a new instrument on the OOI Cabled Array in the summer of 2018. Unlike many of our other projects, this is a “mature” instrument which was previously installed on the Ocean Networks Canada “Neptune” array for almost five years. While the instrument was on the Canadian cable, a set of post-processed data products were defined, and over time responsibility for making those products moved from the inidividual scientsts to the Canadian Data Management and Archiving (DMAS).

To support upcoming research on shooting 2.4GHz wifi through the ocean, I purchased a couple of Mikrotik SXTG2HnD. Besides their low cost, these units ticked my boxes: dual-chain, high-power, highly-directional 2.4GHz Wifi access points. And I’m pretty comfortable with the RouterOS. OK, I could have asked for some truly oddball stuff (like a totally illegal 80MHz channel width option for 2.4GHz), but for $160 all-in, they seemed like a great way to get some initial results.

I’ve posted my final report for the MaSCOT project.

We’re working with a UW-Bothell Senior ME Capstone team to develop a low-cost technology demonstrator/testbed for wireless data and power transfer. We’ve partnered with Wibotic, a UW spin-off. Their wireless power transfer technology is awesome, and I’m eager to have a simple demonstrator on hand to show to sponsors. The students are finishing up their system level design and starting to dive into the detailed design. In the spirit of trying to stay one step ahead of them, I fired up my copy of SharpieWorks and sketched out the current state of play.

We are starting some high-throughput wireless testing and I needed an embedded endpoint that can generate relatively high traffic levels (realistically, ~200Mbps). The standard solutions (RPi), just won’t cut it. We settled on the Odroid XU4, which uses the Samsung Exynos 5422 eight core processor. I’m also interested in the big.LITTLE thing, so this was a great chance to try it out. {:center} Before we get to the real testing, I did a bit of benchmarking.

I’ll be honest. I don’t need to use a CI tool. I’m not deploying mission-critical software across multiple teams spread around the world. I don’t need sub-millisecond notification when my I’ve posted a bad commit. But I do like the idea of TDD (even if I’m an uneven practitioner). For a long time I’ve used Travis because it was free for Open Source projects (though who isn’t these days?), and I didn’t need extravagant performance guarantees, just having it run at some point.