Devices That Need Timestamping

Short version:

Wireless webcam feeding images to BSS sends them with wrong timestamp because device enables normal functioning before getting a reliable NNTP update.  If you’re using “smart” network-based devices, make sure that they’re capable of always providing data with reliable timestamps.

 

Long version (ranting included for no extra charge)

I’m doing a project that involves importing images from a motion-activated camera into the BSS (Blog Storage Service).  Because I had one lying around, I used a http://www.linksysbycisco.com/US/en/products/WVC54GCA wireless, self-contained webcam.

Let me say, for the record, that this is a very poorly implemented camera, something that is not helped by Linksys’ refusal to provide timely firmware updates.  E.g.: If you use a dynamic DNS service like http://www.dyndns.com/, presumably you’re doing so because you want to, y’know, actually use it, maybe?

WRONG!

Why how come?  Because Linksys knows more than you about…INTARWEBS! They have a MASTERS DEGREE, in teh INTARWEBS.  As such, they know that your preferences are merely the pathetic dribblings of a puny mind, and in order to make you life better, you will be using TZO.COM for your DNS redirection service.  “Who?” I hear you thinking.  “Who?” say lots of users on the LinkSys message boards.  Yeah, “who?” exactly.  Never mind that DynDNS (and others) are around, and that you might have existing accounts and reasons for using them.  No.  You will use the Precious, the shiny-shiny Precioussss…..yessss….

Sorry….just went to Middle Earth there, just for a second.  The point, and there is one, I assure you, is that this device, when the power is removed, forgets a critical bit of data: the time and date.  Yep.  $.25 for a battery was too much for the product design geniuses, apparently.

“Big deal,” you say.  Doesn’t the device access an NNTP service during boot, as all other devices in Known Space do?  You’d think that, wouldn’t you, with your pointy little brain, but guess what?  You’d be, that’s right,

ALMOST WRONG!

There is a “Sync with PC” in the administrative interface, but no settings to allow you to specify a specific xNTP server/stratum/protocol.  And, since the device is never, at any time, connected to a PC, the actual functioning of this button, when it’s not mysteriously grayed out, is a Mystery of Science.  Presumably it’s actually using one, because at some point it seems to know the correct(ish) time, but you’d have to do protocol analysis to find out.  No settings for this, either.

All of this would simply be annoying, were it not for the piece de resistance: the device begins sending data BEFORE THE SYSTEM CLOCK HAS BEEN SET FROM A RELIABLE SOURCE.  “Ha-ha!” I hear you say.  Yup, pretty much.  In practice, this means that files uploaded by FTP (no, not SFTP, why would we want a secure connection?) have bad filenames, because the date+time is used for the filename.

“But Lynne, it’s just an inexpensive webcam, surely the designers…” NO! NO!  BE QUIET! BAD USER, NO PR0N FOR YOU!  I might be inclined to agree with you, except that I’ve used other networked webcams, in the same price range ($75+), and they’re just not this bad.

In reality, the device is too complex for a complete novice to use, and they’re presumably the target, given the price.  They’re not sophisticated enough for a user with a modicum of expertise, because they remove certain important choices. You know, I think we’ve all learned an important lesson, except the Windows Mobile UI design team:

Either make a thing an appliance, with a volume knob, or expose every single solitary setting so that experienced users can make it work correctly in any environment.

Conclusion

This specific device is only suitable for casual research projects.  I wouldn’t even use it at home.  My choice for inexpensive network cameras would have to be a D-Link unit, which even 6 years ago worked better.  We used them in retail establishments and spent about $350 each.  I’d link to their site, but http://d-link.com/products/category/?cid=37 is borked ATM.

At the high end of the scale are units like the http://www.axis.com/ one, designed for deployment in public and industrial environments, including hostile ones.  They also document and expose an API  Expect to pay 5-10 times as much as the D-Link models with similar functionality.

Oh, and the BSS import is moving along.

If you’d like to see the live feed from this unit:

(we’ve discovered that a lot of places won’t let this through their proxy/firewall/gateway, but it’s known to work from SLO, at least)

Dear Santas Jeff and Derek*: my CygNet wish list

This is going to be a regular thing.  In addition to putting these in the “bug” tracking system, I’m going to jot down things that would solve problems I run into using our product.  I do understand that I am not even remotely a typical user, and that I’m really concerned about the coming explosion of points/data.  This means a lot of my wish-list items are intended for a future version of CygNet that’s been designed to cope with putting the world in a box.

They’re not in any particular order, and I should hasten to point out are not complaints by any conceivable stretch of the imagination.  Some of my past items have been delivered, too, in the form of the enterprise gateway.

  • BSS
    • Hierarchical storage
    • file system driver (i.e.  accessible via URI –> cygnet://research.bss/Images/Camera001/foo.jpg
  • DDS
    • File import – not just file contents.  I’d like to be able to say, “take this file and put it in the BSS”
    • more examples, more devices, more everything
  • HSS
    • .NET interface/implementation to allow scripting in any language (e.g. Iron Python)
    • Scripting in general using Visual Studio and/or Eclipse, including debugging support
  • FAC
    • migration of the FAC into a more general type system.  I could see, for instance, merging the GRP & FAC (and perhaps TRS) services to make a single metadata service
  • General
    • replication service that actually synchronizes 2 or more service databases, regardless of type
    • .NET version of CygNet
    • ability to support multiple and/or dynamic addresses without restarting
    • much longer field lengths, especially the default value field
    • Studio replaced with Visual Studio plug-in
    • all tabular views sortable via column-heading click
      • sub-sorting via similar mechanism
    • “Hobbyist” version of CygNet preconfigured to work with increasingly common A->D/D->A devices like weather stations, One Wire sensors, USB-provided SCADA, etc.
    • More non-trivial, cradle-to-grave examples, like the MSDN stuff (e.g. Access’ Northwind Trading)
    • General support for accessing CygNet resources via URI.  Need to take a look at http://code.google.com/apis/protocolbuffers/ to see some examples of potentially faster-than-XML technology.  Exposing our services via WCF mechanisms will also allow access via non-Microsoft means.
  • ELS
    • services write logs to Windows event logs and/or support for W3C-like logging formats to allow parsing by system management tools
  • MSS
    • finer grained resolution of timers
    • support for distributed/cloud execution
  • ACS
    • Much tighter and more comprehensive integration with external security mechanisms, especially Active Directory
  • ARS
    • hierarchical/graph trees
    • round-robin resolution (only effective after repli-synch is available, to support cloud-based storage/retrieval)
  • TRS
    • merged into the ARS
  • GNS
    • general support for delivery via RSS and similar mechanisms (e.g. Twitter, Facebook)

*and Doug and Steve and Chris and Tom and everyone, actually.