Kurt's Weblog

autoconf/automake changes to mb-system for conditionally removing GSF

Kurt — 2013-06-16T12:57:01-04:00

This is my first really deep dive into autoconf / automake. I have been a heavy user of configure scripts and could sort of hack my way through minor changes, but I feel like I can actually do some useful work on autoconf and automake scripts now. I just posted a very large patch on the mb-system mailing list that lets people use --without-gsf to build mb-system without the Generic Sensor Format library by SAIC, code which has no license. Here is a version of that email.

https://gist.github.com/schwehr/5792674

This is a first step towards removing GSF to allow MB-system to be packaged by Hamish for submission to RedHat linux and Debian linux. I think this should make copyright sanitization job of the packaging just require deleting the gsf subdir, making a new tar, and then including --without-gsf in the build process.

I've got a patch that I believe successfully builds with or without gsf. Would really appreciate very detailed review of this patch. It builds for me on Mac OSX 10.8 and the present of libgsf in the shared libraries list looks okay, but I haven't tried running any files through yet. Watch through of the patch below. I'm super detailed below to hopefully help in the review and because this is the first time I've done something like this with autoconf/automake and I'm double checking what I did.

The patch is kind of large because it contains deleting mb_config.h which shows as a "-" changes for the entire file.

Notes from Hamish about GSF issues of being unlicensed and submission to deb & rhel/fedora

Kurt, the optional-system's proj4 and GFS switches will certainly not get past the debian ftp masters, actually the deb packaging will need to rip out any license problematic stuff and make a new tarball, since all original code packages are hosted on the debian servers, and they as a legal entity need to be able to guarantee that they've got full copyright clearance for anything they redistribute.

TODO - header.h.in conversion

I did not convert any of the C headers that have to change to their respective .in template version. e.g.

mb_format.h -> mb_format.h.in

That means that building against installed headers & libs is not going to work right. e.g.

WITHOUT gsf means that prototype for mbr_register_gsfgenmb should not be in mb_format.h at all (or it should at least be commented out)

TODO - should we delete, rename or leave alone structure members for gsf?

In order to catch the use of gsfid, I renamed this struct member to _gsfid_placeholder when GSF not defined:

#ifdef WITH_GSF
        int     gsfid;          /* GSF datastream ID */
#else
        int     _gsfid_placeholder;
#endif

Would it be better to leave it alone or could we just drop it like this, which would change the size of the structure (possibly causing problems with things like what ???):

#ifdef WITH_GSF
        int     gsfid;          /* GSF datastream ID */
#endif

mb_config.h

This file should not be checked into svn. It doesn't cause trouble if you build on top of the source tree, but if you do VPATH style building, it gets included before the new mb_config.h that gets written into the build tree.

How I was building

svn co svn://svn.ilab.ldeo.columbia.edu/repo/mb-system/trunk mb-system
cp -rp mb-system{,.orig}

mkdir build
cd build

WITHOUT gsf

(cd ../mb-system; ./autogen.sh); rm -rf src Makefile config.{status,log}; \
../mb-system/configure --with-netcdf-include=/sw/include --with-gmt-lib=/sw/lib \
--with-gmt-include=/sw/include --disable-static --without-gsf && make -j 2

(cd ../mb-system; ./autogen.sh); rm -rf src Makefile config.{status,log}; \
../mb-system/configure --with-netcdf-include=/sw/include --with-gmt-lib=/sw/lib \
--with-gmt-include=/sw/include --disable-static --with-gsf=no && make -j 2

WITH gsf (no option, means include/build with gsf)

(cd ../mb-system; ./autogen.sh); rm -rf src Makefile config.{status,log}; \
../mb-system/configure --with-netcdf-include=/sw/include --with-gmt-lib=/sw/lib \
--with-gmt-include=/sw/include --disable-static && make -j 2

(cd ../mb-system; ./autogen.sh); rm -rf src Makefile config.{status,log}; \
../mb-system/configure --with-netcdf-include=/sw/include --with-gmt-lib=/sw/lib \
--with-gmt-include=/sw/include --disable-static --with-gsf && make -j 2

(cd ../mb-system; ./autogen.sh); rm -rf src Makefile config.{status,log}; \
../mb-system/configure --with-netcdf-include=/sw/include --with-gmt-lib=/sw/lib \
--with-gmt-include=/sw/include --disable-static --with-gsf=yes && make -j 2

Check for libgsf shared library being linked in as a double check

# WITHOUT gsf
otool -L src/utilities/.libs/mbinfo  | grep gsf

# WITH
otool -L src/utilities/.libs/mbinfo  | grep gsf
#	/usr/local/lib/libmbgsf.0.dylib (compatibility version 1.0.0, current version 1.0.0)

Building the patch

cd ../mb-system

# revert files with don't need to patch
find . -name Makefile.in | xargs rm
rm -rf configure autom4te.cache aclocal.m4 
svn up

# this file needs to leave svn!
rm src/mbio/mb_config.h

cd ..
diff -ruN --exclude=.svn mb-system.orig mb-system > mb-with-gsf.patch

Changes to how configure.in and the resulting configure

The options now look like this:

  --with-otps_dir=DIR        Location of OSU Tidal Prediction Software
  --without-gsf           Disable unlicensed SAIC Generic Sensor Format (GSF)
  --with-netcdf-lib=DIR	Location of NetCDF library

The configure.in changes:

AC_MSG_CHECKING([whether to build with Generic Sensor Format (GSF)])
AC_ARG_WITH([gsf], AS_HELP_STRING([--without-gsf], [Disable unlicensed SAIC Generic Sensor Format (GSF)]), [ ], [with_gsf=yes])
AC_MSG_RESULT([$with_gsf])

AS_IF([test x"$with_gsf" = xyes], [AC_DEFINE(WITH_GSF, 1, [Build with GSF])])
AM_CONDITIONAL([BUILD_GSF], [test x"$with_gsf" = xyes])

The above is different than all the other options. I tried to use the provided autoconf and automake macros as much as possible. The above does 3 things:

convert the "#undef WITH_GSF" in mb_config.h.in to "#define WITH_GSF 1" or nothing.
Set the value of BUILD_GSF so that the Makefile.am files are properly converted to Makefiles with control of the "if BUILD_GSF" tweaks
The combination of using all the AS_ macros means that --quiet can work as intended.
Anything other than no option, --with-gsf, or --with-gsf=yes is treated as a leave out GSF

TODO: should we rename BUILD_GSF to WITH_GSF so that they match?

The final line of configure.in shows how autoconf wants us to print summaries:

AS_ECHO(["Build with Generic Sensor Format (GSF) Support: $with_gsf"])

is a lot simpler than:

if test x"$with_gsf" = xyes ; then
	echo "Generic Sensor Format (GSF) Support: Enabled"
else
	echo "Generic Sensor Format (GSF) Support: Disabled"
fi

Do not build the gsf subdirectory

In src/Makefile.am, I conditionally insert the gsf directory into SUBDIRS. I normally use "SUBDIRS +=", but I wanted to follow the convention already used in the file.

if BUILD_GSF
  XBUILD_SUB_GSF = gsf
endif

SUBDIRS = $(XBUILD_SUB_GSF) surf mr1pr proj mbio mbaux utilities gmt otps macros $(XBUILD_SUB) $(XBUILD_SUB_GL) man html ps share

conditionally add gsf files

I put gsf only source files in with the "+=" syntax of Makefile.am. e.g. in mb-system/src/mbio/Makefile.am:

include_HEADERS = mb_config.h \
        mb_format.h mb_status.h \
        mb_io.h mb_swap.h \

        mbf_mbarirov.h mbf_mbarrov2.h \
        mbf_mbpronav.h mbf_xtfr8101.h

if BUILD_GSF
  include_HEADERS += mbsys_gsf.h mbf_gsfgenmb.h
endif

use mb_config.h to conditionally compile code

For example in mb_close:

#include "gsf.h"

Becomes:

#ifdef WITH_GSF
#  include "gsf.h"
#endif

The include guard situation in mb_system is a little inconsistent

The normal style of include guards is that the actual head should do the include guard, not the file that does the #include.

-#ifndef MB_DEFINE_DEF
+#include "mb_config.h"
 #include "mb_define.h"
-#endif
-
-#ifndef MB_STATUS_DEF
 #include "mb_status.h"
-#endif

As discussed above, I did this in mb_io.h to help make sure I didn't miss anything

+#ifdef WITH_GSF
 	int	gsfid;		/* GSF datastream ID */
+#else
+        int     _gsfid_placeholder;
+#endif

I then #ifdefined WITH_GSF around any gsf related code

This is where I could really use others taking a close look. e.g.

+#ifdef WITH_GSF
 	mb_io_ptr->gsfid = 0;
+#else
+        /* TODO: possibly set to -666 */
+#endif

and

@@ -3072,6 +3086,7 @@
 	return(status);
 }
 /*--------------------------------------------------------------------*/
+#ifdef WITH_GSF
 int mbcopy_reson8k_to_gsf(int verbose,
 		void *imbio_ptr,
 		void *ombio_ptr,
@@ -3479,4 +3494,5 @@
 	/* return status */
 	return(status);
 }
+#endif
 /*--------------------------------------------------------------------*/

How much of the world is deeper than X

Kurt — 2013-06-13T11:14:50-04:00

I was asked for fraction of the ocean deeper than 20 fathoms. That gets tricky. What would the differnce be if this were at MLLW vrs MHW? I welcome input from anyone specializing in geodesy, vertical datums and tides.

I prefer to work in units of chains. So how much is deeper than 1.8 chains (aka -36.576m)... 97.1% of the WORLD (oceans + other things that might be deeper but not in the ocean). And this is relative to whatever vertical datum topo30 uses.

Here is using the topo30 2012 edition from David Sandwell and JJ Becker. First a warning. There is a non-commercial license on the topo30 data. This is more restrictive than the GPL license that many are familiar with.

Permission to copy, modify and distribute any part of this gridded
bathymetry at 30 second resolution for educational, research and
non-profit purposes, without fee, and without a written agreement is
hereby granted ...

... use for commercial purposes should contact the Technology Transfer
& Intellectual Property Services, University of California, San Diego ...

wget ftp://topex.ucsd.edu/pub/srtm30_plus/topo30/topo30.grd
gdal_translate topo30.grd topo30.tif
grdinfo topo30.grd

topo30.grd: Title: topo30.grd
topo30.grd: Command: xyz2grd -V -Rg -I30c topo30 -Gtopo30.grd=ns -ZTLhw -F
topo30.grd: Remark: 
topo30.grd: Pixel node registration used
topo30.grd: Grid file format: ns (# 16) GMT netCDF format (short)  (COARDS-compliant)           
topo30.grd: x_min: 0 x_max: 360 x_inc: 0.00833333333333 name: longitude [degrees_east] nx: 43200
topo30.grd: y_min: -90 y_max: 90 y_inc: 0.00833333333333 name: latitude [degrees_north] ny: 21600
topo30.grd: z_min: -11609 z_max: 8685 name: z
topo30.grd: scale_factor: 1 add_offset: 0
 
# z above is altitude in meters relative to ?
 
# install ipython, gdal-py and numpy
ipython

import gdal

src = gdal.Open('topo30.tif')
topo30 = src.GetRasterBand(1).ReadAsArray()
num_deep = (topo30 < -36.576).sum()  
'%.1f %% of the globe' % (num_deep / float(topo30.size) * 100)

67.7 % of the globe

num_ocean = (topo30 < 0).sum()
'%.1f %% of the ocean is deeper than 36.576m' % ( 100. * num_deep / float(num_ocean) )

'97.1 % of the ocean is deeper than 36.576m'

Minus issues with resolution, vertical datums, tides and other stuff, 97.1% of the world is deeper than 20 fathoms and 91.4% is deeper than 100 fathoms.

https://gist.github.com/schwehr/5789528 - http://nbviewer.ipython.org/5789528

smart phones and similar devices in the field

Kurt — 2013-06-11T21:21:54-04:00

It's great to see that work continues at CCOM on this topic:

For people who think they can never have enough monitors! This is
the new panoramic display in the VisLab. The monitors are hinged so
they can be arranged as a flat wall or curved inward for a more
immersive experience. Among other things, the display will be used
with a ship simulator to study the potential benefits of hand-held
spatially aware navigation aids like smart phones. Thanks to Will
Fessenden for the nice photo!

Back in 1990, I got to tour Scott Fisher's virtual reality lab at NASA Ames. After working on the Telepresence-ROV (TROV) vehicle in 1992, I was hooked on the idea of what might come when head mounted displays weren't so heavy that they quickly made your neck hurt and didn't require a 5kW generator.

Hiking around the Southern Snake Range doing geologic mapping, I dreamed of devices that would sync up the mapping via hill top repeaters (yeah, I had a HAM license). Why waiting until the evening to all copy our data to the master mylar sheet? And if we could capture field photos throughout the day, we could share best photos of geologic units and particular features as we discovered them. Instead, I had to wait to get back to civilization to develop physical film.

The next couple years, I had visions of laser range finders, stereo cameras and mapping tablets as I worked in Yellowstone mapping hot springs and in Mono Lake trying to get the TROV to do useful science. Perhaps more scientists would take notes in the field if they were wearing Google Glass and could just speak their observations.

I did quite a bit at SIO in the 2002-2005 range with a 21 foot by 8 foot curved display and then when I got to CCOM in 2005, I proposed hand held and head mounted augemented reality and heads up displays. I got CCOM to pony up for the first smart phone bought on the NOAA grant (an iPhone 3S for me).

Roland and Tom have been doing some really neat development at CCOM and it should be fun to see what comes.

Some images from the first half of the 1990's that triggered some of my thinking on wearable / portable devices and how they might help people work in the real world. If only GPS SA had been off back then!

Sorry about the quality of the images.

Google Ocean bathymetry update - World Oceans Day

Kurt — 2013-06-10T12:43:46-04:00

Saturday (2 days ago) was World Oceans Day. We made a small G+ post for it:

Google Earth: Revealing the Ocean on World Oceans Day!
Google Maps: On World Oceans Day, it's the perfect time to dive in and explore!

The text from the post and the image captions:

Here's a sneak preview of our work to improve our ocean map in
Google Earth and Maps in partnership with NOAA's National Geophysical
Data Center (http://goo.gl/zZpPB)
and the University of Colorado CIRES program (http://goo.gl/b3dGH).

Explore more today by downloading this Google Earth tour list http://goo.gl/jyDanHere

Visit a detailed ocean landscape in Boundary Bay, WA. NOAA's Crescent
Moegling says, "Within the Strait of Georgia, deep draft vessels
transit to several large refinery facilities. It's our job to provide
the mariner with the most accurate chart, with the most relevant
features and depths available for their safe navigation."

Notice the new high resolution 16 meter NOAA survey update (right)
relative to the lower 1 km resolution across the Canadian border
(left) in this area west of Bellingham, Washington.

The kmz showing the locations of the updates is here:

http://commondatastorage.googleapis.com/bathymetry/kml/NOAA-NGDC-OceanMapFootprints.kmz

Many thanks for the over 1000 +1's for the two G+ posts!

NMEA Transport, Annotate and Group (TAG) block encoding

Kurt — 2013-06-07T21:31:57-04:00

Before I start, there are so many strange things in the NMEA specification, but this is one of my favorites:

Since there is no provision for guaranteed delivery of messages and
only limited error checking capability, this standard should be used
with caution in all safety applications.

Wahoo! And off we go with safety of life applications without additional thought.

I finally started looking at the NMEA TAG block specification. I paid for version 4.0 of the spec, so I should use it, right? I have to say it is slightly painful. I'll do my best to describe what TAG block is, the issues that it is trying to address, and how well the authors did in their design. I really hate how standards often do not list the authors / contributors. No way to start up a discussion.

The motivation for a format change.

The basic NMEA 0183 (3.0 and lower) sentence is missing some things. First, it is limited to 79 characters per line. Therefore, there are many times that one line is too short for all that you would like to send. AIS introduced the concept of messages that span multiple lines with fields to help re-assemble the total message. This falls apart if you have a single feed coming from multiple devices that may all be doing the same thing giving intermixed multi-line messages. If we can identify the source of the message, then we can re-assemble these multi-line messages without fear of mixing unrelated parts.

The next issue is the lack of metadata in the NMEA0183 message format. Unless the message has a timestamp built in, there is no standard way to log the time. We may have additional metadata requirements and there is no place to put them.

History

The USCG created an initial metadata format somewhere in the pre-2005 time frame that appended fields after the existing message. I've documented that format elsewhere, but to summarize, it consists of comma separated fields that start with a letter code except the last field, which is the unix UTC timestamp. It works and that is what I've used since 2006 for my logging and processing in software line ais-py, noaadata-py and libais.

I created a python regular expression that parses the basic structure of these "old USCG format" messages. Here is an example message and the regular expression being used to pull apart the fields.

#!/usr/bin/env python

import re

nmea_re = re.compile (r'''^!(?PAI)(?PVD[MO])
,(?P\d?)
,(?P\d?)
,(?P[0-9]?)
,(?P[AB])
,(?P[;:=@a-zA-Z0-9<>\?\'\`]*)
,(?P\d)\*(?P[0-9A-F][0-9A-F])
(
  (,S(?P\d*))
  | (,s(?P\d*))
  | (,d(?P[-0-9]*))
  | (,t(?P(?P\d\d)(?P\d\d)(?P\d\d.\d*)))
  | (,T(?P[^,]*))
  | (,x(?P[0-9]*))
  | (,(?P(?P[rbB])[a-zA-Z0-9_]*))
)*
,(?P\d+([.]\d+)?)?''', re.VERBOSE)

match = nmea_re.match('!AIVDM,1,1,,A,14eG>3@01kqiIs8ICROownFn0D03,0*02,d-106,S0993,t140726.00,T26.49646933,r09STWO1,1370786847')

msg = match.groupdict()
for key, val in msg.iteritems():
    print '%s: %s' % (key, val)

# result:
'''
body: 14eG>3@01kqiIs8ICROownFn0D03
slot: 0993
t_sec: 26.00
t_min: 07
station_type: r
seq_id: 
t_hour: 14
chan: A
string_type: VDM
fill_bits: 0
sen_num: 1
s_rssi: None
t_recver_hhmmss: 140726.00
station: r09STWO1
time_of_arrival: 26.49646933
talker: AI
checksum: 02
time_stamp: 1370786847
x_station_counter: None
total: 1
signal_strength: -106
'''

Remember that you can use kodos to try out python regular expressions.

TAG block

Apparently, that style was not good enough. So some group of people tried to create something better. I'm going to ignore the control aspect. I typically only deal with logs from devices that are out of my influence. We get what we get.

The basic structure of TAG is to put additional data in the front of the original NMEA 0183 messages between two "\" characters. This is extra interesting in that most programming languages use the back-slash to start escape codes (e.g. "\n" and "\r"; c.f. "man ascii" and "man printf").

An example to show what this looks like. I got this chunk back in 2009.

\g:1-2-73874,n:157036,s:r003669945,c:1241544035*4A\!AIVDM,1,1,,B,15N4cJ`005Jrek0H@9n`DW5608EP,0*13
\g:2-2-73874,n:157037*1D\$ARVSI,r003669945,,172036.69698935,1376,-095,0*15
\g:1-2-73875,n:157038,s:r003669945,c:1241544035*45\!AIVDM,1,1,,B,15NEcU0001JriI4H@2DEN038069@,0*00
\g:2-2-73875,n:157039*12\$ARVSI,r003669945,,172036.77711928,1379,-097,0*1B
\g:1-2-5624390,n:2281546,s:r003669959,c:1241544037*7D\!AIVDM,1,1,,A,15PlLL@P1@JmA=DGWcw9M?w:069@,0*1D
\g:2-2-5624390,n:2281547*25\$ARVSI,r003669959,,246060,9999,-094,0*34
\g:1-2-5624393,n:2281555,s:r003669959,c:1241544037*7C\!AIVDM,1,1,,A,15PlLL0OhgJn2ORG`TQ6nEC:28ES,0*3F
\g:2-2-5624393,n:2281556*26\$ARVSI,r003669959,,246060,9999,-077,0*39
\g:1-2-5624394,n:2281557,s:r003669959,c:1241544037*79\!AIVDM,1,1,,A,18KKL00025rsc08J983:0D04,0*23
\g:2-2-5624421,n:2281619*20\$ARVSI,r003669959,,246060,9999,-053,0*3F
\g:1-3-60450,n:131065,s:r003669946,c:1241544038*4B\!AIVDM,2,1,9,A,55MwpAh000000000000
Pretty overwhelming and hard to read.  Let's start off by creating and
decoding a message that gives the Unix UTC timestamp, which is indicated by a 'c:' character.
We won't give a NMEA 0183 msg to go with it.  My reading is also that the checksum within
a TAG block ( "\\[^/+]\\" ) is optional, but I will start off with including the checksum.
#!/usr/bin/env python

from operator import xor
import time

def checksum(sentence):
  return ('%02x' % reduce(xor, map(ord, sentence.split('*')[0][1:]))).upper()

timestamp = int(time.time())
# 137079172

body = 'c:%d' % timestamp
msg = '\\{body}*{checksum}\\'

print msg.format(body=body, checksum=checksum(body))
# \c:1370791724*31\
We now need to start creating the regular expression to parse these TAG things.
Let's start without worrying about the internal fields.  I came up with
\\.*\*(?P[0-9A-F]{2})?\\.*
The back-slashes need to be escaped, so a single back-slash gets written as "\\" in the regex string.
Now we can add the section for the timestamp.  Sadly, the spec asserts that the timestamp is an integer.  They then
add the twist that the value can be either seconds or milliseconds, but does not give us an indicator for which.  Ouch.
Not like they had run out of letter codes.  Currently, timestamps have 10 digits and TAG block started in 2008.
int(1e9)
# 1000000000

datetime.datetime.utcfromtimestamp(1e9)
# datetime.datetime(2001, 9, 9, 1, 46, 40)
Therefore, we need our integer to have 10 or more digits for the timestamp.  I came up with this regex:
\\c:(?P\d{10,15})\*(?P[0-9A-F]{2})?\\.*
Viewed in kodos:







So we have a start!  More in a future post.

Behind the scenes at Google IO

Kurt — 2013-05-25T21:58:11-04:00

Google I/O was a totally insane experience for me this year. I got a substantial amount of my sleep for the week on mass transit or a bean bag in the speaker prep area. I know a lot of the teams are working hard on sharing more of the how it was done. I wanted to share a couple more images and some more of what I've been up to now that I have had a chance to sleep some.

First some general team news. I've moved offices this week. Before, I was sitting with the amazing imagery ingest team that handles bring in and processing all that amazing satellite and oblique imagery along with the terrain. I am still working with them, but I am now sitting with the Geo Outreach and Earth Engine Teams. For the first time since joining Google full time, I get to sit next to the other two full time Ocean team members. Woot! At Google, we do an amazing amount over VC, but there is nothing like just being around the team. We're never going to be able to get all the 20%ers who contribute to Oceans to be physically located in the same area. We're just too diverse a bunch.

And now, two pictures from IO. The first was the lineup outside Moscone West the day before the conference started. I was over from the SF office to do a "tech check" of the room. We tried out the slides on the actual projectors and made sure we were all comfortable with the on stage setup.

The cloud team was deploying hundreds of sensor datalogging notes throughout the three floors of the conference area. I've never seen so many sensor nodes before.

Processing and visualizing {ship/sensor} data - the matched set

Kurt — 2013-05-21T10:44:14-04:00

In case it wasn't clear, I'd like to re-iterate: These talks are not meant to be about ships. We want to you to think about YOUR data when watching these videos. If your data is AIS, then that's a lucky match, but we don't expect it. We want YOU to go forth, process lots of data and build amazing visualizations and analyitics systems that meet your needs (be they local or global). We think that AIS ship tracking makes a great example use case with many interesting stories that can be told with the data that give us chances to demonstrate techniques and strategies.

Brendan Kenny: "Google I/O 2013 - Google Maps + HTML5 + Spatial Data Visualization: A Love Story"

Francesc Campoy, Kurt Schwehr and Mano Marks: "Google I/O 2013 - All the Ships in the World: Visualizing Data with Google Cloud and Maps"

Jenifer Austin Folkes - Google I/O 2013 - Dive Into Underwater Street View

Amy Unruh and Kim Cameron: "Behind the Data Sensing Lab - Gathering, Processing and Analyzing Data at Scale using the Google Cloud Platform"

Massimo di Stefano - Ipython Notebook for GIS

Kurt — 2013-05-20T10:38:48-04:00

Lightning Talk - Massimo di Stefano - Ipython Notebook from PyData on Vimeo.

UK Hydrographic Office 5 minute video

Kurt — 2013-05-20T10:25:39-04:00

Thanks to GeoGarage for linking to this 5 minute video about the UK HO.

Cat nap

Kurt — 2013-05-18T13:22:01-04:00

Cleaning out the email this morning, I ran into older images from our web cam. The rough life of our cat... we'd had him for 8 months at this point. Terrible quality with this webcam, but it was cheap and uses wifi.