[Watford] Some April meeting notes

[Yvan Seth]

Hi All,

I'm not going to have time to type up the plethora of ideas discussed in
this month's meeting (let alone remember all the details!)  Instead
here's a few points I picked up, I've left a lot out (hey, another good
reason to reinstate a wiki!):

* Linux interface to RS232 hardware.
    * Most languages can work with serial devices and it is very
      simple.
    * Example: http://www.ontrak.net/linux.htm
    * Also, RS232 to USB dongles exist (most useful when your machine
      lacks a serial port.)
    * Also, if using USB instead then the libraries do exist to
      communicate with USB (libusb for C, libusb++ for C++, and bindings
      for all the usual interpreted languages.)
    * I'll see if I can dig up some RS232+PIC hardware I can use to demo
      this sort of thing (at the very least I have a PIC programming
      board that can also be used to communicate with the PIC - but a
      simpler RS232 line to switch/LED would be a better demo.)

* Linux interface to GPS
    * Variety of hardware:
        * Simple USB (and bluetooth) dongles for as little as 10 quid.
        * Full blown handheld GPS hardware.
        * Many programs exist to read these devices, 'gpsbabel' is a
          good one.
    * Also, could be used to read GPS time signals to sync PC clocks,
      possibly far more precise than NTP?  Possibly a good replacement
      for very expensive specialist time sync hardware?  I found a
      paper on this:
        Low-cost, High Accuracy GPS Timing
            ftp://ftp.cnssys.com/pub/ION-GPS2000/ion-time.pdf 
      It is worth reading.  Note:
        "the average error is only 50/19.5 = ~2.56 nsec"
    * Next meeting I'll bring along my Garmin GPS (SiRF) and show a few
      ways it can be used with Linux.  I wrote this on the topic a
      little while ago: http://tinyurl.com/yntruh
    * Steven and/or Mwill try to bring

* OSS (or non-million-dollar) solutions for resolving phone numbers to
  6-digit provider codes.  What was the number of records?  168 million?
    * MySQL should theoretically handle this many records.
        * http://jeremy.zawodny.com/blog/archives/000796.html
        * More sensible may be to distribute over multiple databases
          (each on a different machine) with the first 4 digits (or
          whatever makes a sensible data partition) determines the
          machine to use.
        * Additionally each database could be replicated multiple times
          and something like round-robin DNS used to distribute load.
    * PostgreSQL theoretically should also handle this.
    * A custom datastructure will probably be faster and use less space,
      but would require much more development time.
        * I.e. a common fast and space-efficient structure is the Radix
          Trie: http://en.wikipedia.org/wiki/Radix_tree
        * Though for digits something more tunes for binary
          representations (rather than strings) will probably use less
          space.
        * Give a computer scientist a day to think about it and they'll
          probably work out something good.
        * I'd try working with MySQL first and only fall back to this
          if MySQL doesn't work out. 
    * Thoughts on upper storage bounds.  48 bits are required to store
      a 14 digit phone number (00447111222333 - is that right, need
      more/less?) and 20 bits for 6 digit numbers (assuming maximum size
      of 99999999999999 and 999999 respectively.)  200 million such
      fields would need just a bit more than 1.5GB of memory.  There'd
      be some overhead though ... but even at 4x this is a reasonable
      amount of memory for a single mid-range server.  It'd take a lot
      more storage if the numbers were kept in in ascii (8 bit char)
      format.

* There was a brief discussion of MythTV but I don't know if much was
  resolved.  Alan suggested another program he preferred, I forgot
  the name I'm afraid.  Was it opTV?

* Alan suggested a group development project as an intro to writing some
  software on Linux.
    * Specific example: application for coding PDF filenames.
    * Idea to be developed further in following meeting?

* Also suggested a little more structure to the meetings.  This probably
  would go astray.  I think Steven will see about getting access to the
  website?  Next meeting we can discuss re-establishing a wiki or
  something to collaborate on meeting details (i.e. people can add their
  questions to the wiki pre-meeting so that some preparation is
  possible, answers can then go on the wiki, it can be used for
  presentation info as well of course.)

There was much more, including law, taxation, and music ... but it's
late now.

-Yvan