linktitle: aptrepo
parent: Home
ctime: 2009-12-10
+mtime: 2012-08-01
Repositories: [[aptrepo]].
--- /dev/null
+title: Blog
+linktitle: blog
+parent: Home
+ctime: 2012-08-15
+mtime: 2000-01-01
+
+This category contains various articles blogged by TMI staff. Please select
+from the side menu on the left.
--- /dev/null
+title: 2011-07 blogs
+linktitle: 2011-07
+parent: 2011
+ctime: 2011-07-01
+mtime: 2000-01-01
--- /dev/null
+title: 2011-10 blogs
+linktitle: 2011-10
+parent: 2011
+ctime: 2011-10-01
+mtime: 2000-01-01
--- /dev/null
+title: 2011 blogs
+linktitle: 2011
+parent: blog
+ctime: 2011-01-01
+mtime: 2000-01-01
--- /dev/null
+title: 2012-08 blogs
+linktitle: 2012-08
+parent: 2012
+ctime: 2012-08-01
+mtime: 2000-01-01
--- /dev/null
+title: 2012 blogs
+linktitle: 2012
+parent: blog
+ctime: 2012-01-01
+mtime: 2000-01-01
--- /dev/null
+title: Read Only Root
+linktitle: ro-root
+parent: 2012-08
+ctime: 2012-08-02
+mtime: 2012-08-02
+
+For GNU/Linux desktop installations, I prefer to have the root filesystem, which
+mounts to /, be mostly read-only. This means /home (user data), /var (variable
+data) and /tmp (temporary data) should be mounted elsewhere. The benefits of
+this approach are several, but two in particular stand out for desktop use
+cases.
+
+ * It is much easier to do a clean install the OS. User data in /home, and
+ in some cases application data in /var, need not be backed up and restored
+ in the process. Of course recent backups should still be available.
+ * A root fs that is rarely written to is a good candidate for SSD (solid state
+ disk) storage. This allows one the performance benefit of SSD while
+ mitigating a critical deficiency. Current SSD technology is not nearly
+ as reliable as mechanical disk in read/write environments, so reducing
+ writes to SSD is a productive strategy.
+
+Placing /home on a separate partition is easy, and GNU/Linux desktop installers
+have supported this for some time. And thanks to the recent introduction of
+/run (see [here](http://lwn.net/Articles/436012/) to learn more), migrating
+/var to a separate filesystem is now pretty easy for desktop installs.
+
+Of course, with multiple partitions, there is the issue of what to do if one of
+them fills up. A common solution is to use LVM. Volumes are given minimal
+practical sizes, and then incrementally grown as required. LVM works fine on
+the desktop, but requires a bit more knowledge and effort to administer.
+
+[[!pquote text="A simpler solution is to use bind mounts"]]
+
+A simpler solution is to use bind mounts. By bind mounting /var from /home/var
+and /tmp from /home/tmp, all user, variable and temporary data are on a single
+partition. The root partition will be nearly static in content and size. I
+currently use a 25 GB root partition on desktop installs, and that filesystem is
+generally only about 25% full, even with a large number of development tools
+installed. A swap partition is present of course, and the rest of the available
+hard drive storage space is assigned to the home partition, which now holds the
+contents of /var and /tmp. Essentially, /home, /var and /tmp share a common
+large pool of storage, so there is less need for a volume manager. I am finding
+this configuration to be quite optimal for developer desktops at my company.
+
+# Using bind mounts in a new installation
+
+These notes assume Xubuntu 12.04 desktop i386 installation, but a similar
+process should work for other distributions and versions.
+
+ * Boot from the xubuntu 12.04 desktop CD
+ * Run the installation
+ * Use a custom configuration when asked
+ * At least three partitions are required: root, swap and home
+ * Proceed with installation until the installer asks to reboot to continue
+
+Before rebooting, access a shell and type the following commands
+
+ cd target # where the new root filesystem is currently mounted
+ cp -a var home/var # copy var to its new storage location
+ mv var var.old # can remove later
+ mkdir var # Need some dirs and symlinks during boot for some OSes
+ ln -s /run var/run
+ ln -s /run/lock var/lock
+ cp -a tmp home/tmp # copy tmp to its new storage location
+ mv tmp tmp.old
+ mkdir tmp
+ vi etc/fstab # add the following 2 bind mounts to end of /etc/fstab
+ /home/var /var bind defaults,bind,noatime,mode=0755 0 0
+ /home/tmp /tmp bind defaults,bind,noatime,mode=1777 0 0
+ sync
+
+Now allow the installer to reboot. The system should boot up using the bind
+mounts for /var and /tmp, so their contents will actually be stored in the home
+partition at locations /home/var and /home/tmp, respectively. Once the system
+appears to be working OK, you may remove the /var.old and /tmp.old directories.
+
+# Upgrading to use bind mounts
+
+First, boot from a recovery or live CD, then run commands like the following
+commands.
+
+ mkdir /mnt
+ mount /dev/sda1 /mnt # replace /dev/sda1 with dev for your root
+ mount /dev/sda2 /mnt/home # replace /dev/sda2 with dev for your home
+ cd /mnt
+ cp -a var home/var # copy /var to its new storage location
+ mv var var.old # can remove later
+ mkdir var # Need some dirs and symlinks during boot for some OSes
+ ln -s /run var/run
+ ln -s /run/lock var/lock
+ cp -a tmp home/tmp # copyt /tmp to its new storage location
+ mv tmp tmp.old # can remove later
+ mkdir tmp
+ vi etc/fstab # add the following 2 bind mounts to end of /etc/fstab
+ /home/var /var bind defaults,bind,noatime,mode=0755 0 0
+ /home/tmp /tmp bind defaults,bind,noatime,mode=1777 0 0
+ sync
+
+Now remove the CD and reboot. You should be using bind mounts. Once the system
+appears to be working OK, you may remove the /var.old and /tmp.old directories.
--- /dev/null
+title: Virtual Windows 7
+linktitle: virtual-win7
+parent: 2011-07
+ctime: 2011-07-28
+mtime: 2011-07-28
+
+# Introduction
+
+This page documents the process of converting a dual-boot Linux/Windows
+installation into a Linux installation running the Windows partition under a
+KVM virtual machine. This work was first performed under Ubuntu 10.10 and
+11.04 versions.
+
+# Why virtualize Windows 7?
+
+During my development activities, customer needs infrequently require use of
+software only available under Windows. But booting between OSes is an
+incredible waste of time and drain on productivity. My work notebook, a Lenovo
+X201, came pre-installed with an OEM version Windows 7 Home Premium. The
+obvious solution? Virtualize Windows under Linux.
+
+# Microsoft licensing issues?
+
+[[!pquote text="The OEM Windows EULA allows for virtualization"]]
+
+I downloaded the EULA for Windows 7 from microsoft.com as applicable for
+pre-installed OEM versions of Windows 7 Home Premium. For this OS configuration,
+the license specifically allows execution of the pre-installed OEM OS when
+virtualized on the same hardware. The actual text is found in Section 3.d:
+
+> Use with Virtualization Technologies. Instead of using the software directly
+on the licensed computer, you may install and use the software within only one
+virtual (or otherwise emulated) hardware system on the licensed computer. When
+used in a virtualized environment, content protected by digital rights
+management technology, BitLocker or any full volume disk drive encryption
+technology may not be as secure as protected content not in a virtualized
+environment. You should comply with all domestic and international laws that
+apply to such protected content.
+
+# Virtualization requirements
+
+For Windows virtualization to be effective in my development use cases, the
+following requirements and constraints must be met. Additionally, I want the
+virtualization solution to support running additional virtual machines as well.
+
+* Run 32-bit x86 Windows 7 from 32-bit x86 Ubuntu Linux 10.10 and newer.
+* Run various flavors of Linux or other Intel x86 based operating environments.
+* No unnecessary dependences to software or hardware that will limit the
+ability of the virtualized OS from functioning properly in the future.
+* Ability to run with native disk, not disk-as-file, for improved IO
+performance.
+* Supports use of VT-x and VT-d, again for performance.
+* Will be sufficiently performant on the target hardware when virtualized. The
+X201 has an i5-M560 CPU which offers 4 cores at 2.66 GHz each, and 8 GB of RAM.
+* Simple management of VMs, including configuration, start and stop.
+* VMs must behave sanely in the presence of host OS power saving functionality,
+like suspend.
+* There is no requirement to continue to run Win7 natively.
+* High end graphics are not required: no need for 3D, Aero effects, video
+playback, etc.
+* And finally, a reliable mechanism return to the prior physical configuration
+if the VM experiment fails to work as hoped.
+
+# Selecting a virtualization framework
+
+There are a few virtualization options suitable for use on a development system,
+including VMware, Xen, VirtualBox, and KVM. All can do the job, but KVM was
+chosen for a variety of reasons:
+
+* KVM has the features needed, and is available through the standard
+Ubuntu repositories.
+* KVM management via libvirt is more than adequate.
+* KVM can use an SDL local window for rendering the virtualized OS, for quite
+good display performance.
+* The enterprise features of Xen are overkill for this application.
+* VMWare is not open source, so there is some concern about support for this
+particular hardware in the far future (I tend to keep hardware for a very long
+time).
+* VirtualBox can not access USB hardware unless the purchased version is used.
+
+The virtual machine manager, using libvirt, is a pretty nice environment. This
+management tool already supports a few different VM strategies, called
+*backends*, and they are likely to improve moving forward. Therefore, gaining
+knowledge about VMM, libvirt, and KVM could in the near future represent
+an intellectual asset deployable against future customer needs.
+
+# Disk organization, pre-virtualization
+
+Prior to any changes, the 320 GB notebook disk drive was organized as follows:
+
+ /dev/sda1, 1.17 GiB, Label=SYSTEM_DRV
+ /dev/sda2, 78.17 GiB, Label=WindowsOS_7
+ /dev/sda3, 19.68 GiB, Label=Lenovo_Recovery
+ /dev/sda4, an extended partition container
+ /dev/sda5, 15.26 GiB, swap partition
+ /dev/sda6, 23.84 GiB, / partition
+ /dev/sda7, 159.96 GiB, /home partition
+
+* The SYSTEM_DRV apparently supports the Lenovo ThinkVantage functionality
+which includes some backup and restore capability.
+* The WindowsOS_7 partition is the one to virtualize, containing the licensed
+OEM version of Windows 7 Home Premium that came with this notebook.
+* The system boots using Grub2, which initially included an entry to boot the
+Windows_7 partition.
+
+# The solution
+
+Unfortunately, the solution is not so simple as to point the VM to the /dev/sda2
+partition. First, the virtual hardware expects to see a hard drive, complete
+with partition table. Second, suitable drivers for the virtual hardware must be
+installed into the windows installation. I took several steps to convert
+/dev/sda2 in place to look like a hard drive (kpartx, etc) but the best I could
+accomplish was Windows 7 hanging during boot. Since my expertise with Windows
+internals is limited, and so is the information available online, I elected to
+do a clean re-install Windows from the virtual environment.
+
+## Create backups
+
+### R&R image
+
+Levnovo offers a recovery capability accessible by booting the Lenovo_Recovery
+partition. I used this to create a recovery image for the WindowsOS_7
+partition.
+
+* Create a windows repair disc from the Win7 OS
+* Create an R&R recovery boot disc
+* Back up the current Win7 image via R&R to the Lenovo_Recovery partition. This
+required removing all other prior backups because of size constaints in that
+partition.
+* Back up the current Win7 image to a set of DVD optical discs. It took 3: a
+boot disc and two data discs.
+
+### Partition level backups
+
+Since the space was available in the Linux partition, I opted to create parition
+level backups as well, which would be 'easier' to restore, at least for me.
+
+ # Backup the first MiB of /dev/sda to capture MBR and any bootloader stuff
+ dd if=/dev/sda of=mbr.save bs=1M count=1
+ # Use ntfsclone to make a space-efficient copy of the windows partition
+ ntfsclone --save-image -o - /dev/sda2 | gzip -c > sda2.img.gz
+
+## Prepare /dev/sda2 for virtualization
+
+First, /dev/sda2 must look like a DOS style disk, complete with disk level
+partition information. This can be accomplished using this fdisk command:
+
+ fdisk -c -u /dev/sda2
+
+Drive fdisk to create a single windows partition spanning the entirety of the
+'disk' (actually the physical partition /dev/sda2). Now /dev/sda2 will look
+like a valid disk image usable by a VM to re-install Windows 7.
+
+## Install the virtualization tools in Linux
+
+ sudo apt-get install virt-manager virt-viewer python-vm-builder \
+ kvm-pxe ubuntu-vm-builder
+
+I tested the VM tools by creating an Ubuntu 11.04 install. I ran the Virtual
+Machine Manager using an Ubuntu 11.04 install .iso image as its CD-ROM. The
+installation was successful and the resulting virtual machine worked without
+fail.
+
+## Re-install Windows 7
+
+Next windows was re-installed. A Windows 7 Home Premium 32-bit OEM .iso was
+used to do a clean install of Win7. See the virtioinstall.sh script for more
+information. I used the Win7 iso, and virtual floppy and CD-ROM images from
+RedHat containing signed virtio drivers for disk and network devices. The VM was
+started using the virtio disk driver, booting into the Win7 iso. Then the
+virtual floppy was accessed during the Win7 install process to load in the
+virtio drivers so the Win7 install program could see the disc, which was of
+course the disk image on the host /dev/sda partition. I formatted the 'drive'
+(which is really the /dev/sda2 partition on the physical drive), then proceeded
+to install Win7 onto it. The installation process, from first boot of the Win7
+iso, to first user login to Win7, took just under 45 minutes.
+
+At this point, the VM was stopped so its configuration could be altered it use
+the virtio network driver. The VM was then restarted with the virtio iso from
+RedHat connected as the virtual CD-ROM disc. Once Win7 was running, in device
+manager the drivers for the broken network device were updated from the .iso to
+get the network running. The virtio network interface seems very efficient. The
+VM configuration was finally modified to provide for 2 CPU cores and 2 GB of
+RAM.
+
+## Re-activate Windows 7
+
+At this time, Win7 had to be re-activated. The online technique failed, so the
+phone call technique was required. It was a bit painful, but the end result was
+a properly activated installation.
+
+## Install other Windows 7 tools
+
+Since I installed from scratch, I had to reinstall the few tools I use under
+Windows. Since these tools were few in number, this process was pretty
+painless. This strategy would be much more painful if there were lots of tools
+and/or custom configuration or data required to be recovered.
+
+## Improving diplay performance
+
+The default display mechanism when interacting with the Windows VM display is
+VNC. This is not very performant. Since the Windows VM is only to be accessed
+from the local hardware, I instead configured the VM to use SDL for rendering
+the VM display in a window. Interestingly, this change also allowed sound from
+the Win7 VM to propagate to the sound hardware. The SDL configuration is fast
+enough to watch Netflix from the VM.
+
+ Stop the win7 VM
+ Reconfigure the VM:
+ Remove VNC graphics entry for the VM and add the local SDL one.
+ Change the sound driver to ac97
+ Edit /etc/libvirt/qemu.conf. Add:
+ user = "smckown"
+ group = "smckown"
+ sudo service libvirtd-bin restart
+ Restart the virtual machine
+
+### Why not SPICE?
+
+The SDL method creates a new local window that hosts the VM display. It cannot
+be embedded into the virtual manager VM window. It looks like the better
+solution is going to be to use the SPICE facility. Special drivers in the VM
+work with special client features to implement a much improved connection. SPICE
+provides better display performance than VNC, can do stereo sound, and also
+provides for USB redirection. As of 7/13/12, Ubuntu 12.04 does not have the
+right stuff to do spice through virt-manager. There is a PPA that will allow it.
+The nice thing about SPICE is it is network-able and can be embedded. Since
+network access to the VM is not necessary, the SDL window method seems optimal.
+
+## Anti Virus considerations
+
+It should be noted that the VM, as the native install before it, is running
+Microsoft Security Essentials for Anti-Virus. There appears a noticeable
+performance hit for using AV within the VM, in comparison to running it
+natively. Unfortunately, the protection offered is probably worth the
+performance penalty.
+
+# Conclusion
+
+I am quite happy with the results of this process. Win7 boots noticeably faster
+from the VM than it did on native hardware. Disk CPU are perceptibly sluggish
+within the VM with respect to native performance, but it is tolerable. Network
+performance seems on par with native. For the tasks in which I will use
+Windows, the virtual machine performance is more than adequate.
+
+Of course the big win is that Win7 can be running simultaneously with Ubuntu.
+This solves a host of workflow problems and removes the terrible inefficiencies
+caused by having to boot between the two OSes natively. For one, I was able to
+continue working with apps in the host Ubuntu OS while the Win7 VM chugged away
+literally for hours downloading and rebooting ad nauseum as it updated itself
+with the latest Win7 SP1 and subsequent patches.
+
+My overall concern with this strategy is that a change in Microsoft policy could
+complicate my life. Although this use of my windows license is perfectly
+legitimate according to my reading of the EULA, I depend upon Windows Product
+Activation to honor this legitimacy. Here is to hoping that Microsoft will take
+care to ensure that their WPA policies retain convenient use of Windows for all
+legitimate uses.
+
+---
+
+# Updates
+
+### 2012-08-13
+After using this configuration for over a year, I have found it to be quite
+reliable. The upgrade to 12.04 triggered Windows Product Activation, and
+another phone call to the automated WPA phone number was required. The
+activation was successful.
+
+---
+
+# Links
+
+The following links, in no particular order, were invaluable in completing this project. Thanks to all those who published their prior experience for others to use!
+
+* <http://support.microsoft.com/kb/927392>
+* <http://answers.microsoft.com/en-us/windows/forum/windows_7-system/hp-mini-210-windows-7-recovery-0xc000000f-bcd/6c79d900-79dc-4f54-bcf7-22edf6f44dd4>
+* <http://windows.microsoft.com/en-US/windows7/Startup-Repair-frequently-asked-questions>
+* <http://www.sevenforums.com/tutorials/20864-mbr-restore-windows-7-master-boot-record.html>
+* <http://www.sevenforums.com/tutorials/104341-bootmgr-missing-fix.html>
+* <http://www.sevenforums.com/tutorials/163216-bootrec-exe-tool-how-use-windows-recovery-environment.html>
+* <http://brandonkonkle.com/blog/2009/apr/27/lvm-based-virtualization-kvm-and-jaunty/>
+* <http://techpp.com/2009/11/11/download-windows-7-iso-official-direct-download-links/>
+* <http://bderzhavets.wordpress.com/2011/01/08/set-up-rh-virtio-scsi-driver-on-windows-xp-kvm-at-kvm-qemu-instance-on-f14/>
+* <http://techpp.com/2009/11/11/download-windows-7-iso-official-direct-download-links/>
+* <http://cloud.ubuntu.com/2011/03/fast-win7-kvm-virtiodisk-net-install/>
+* <http://www.sevenforums.com/tutorials/1649-clean-install-windows-7-a.html>
+* <http://rghost.net/3412907>
+* <http://www.sevenforums.com/installation-setup/156599-help-windows-7-clean-install.html>
+* <http://www.sevenforums.com/installation-setup/151566-reinstalling-windows-7-a.html#post1300819>
--- /dev/null
+title: WWVB
+linktitle: wwvb
+parent: 2011-10
+ctime: 2011-10-28
+mtime: 2011-10-28
+
+Repositories: SOON
+
+TMI uses a WWVB receiver in its RWS product.
+[WWVB](http://www.nist.gov/pml/div688/grp40/wwvb.cfm) is a radio station
+operated out of Ft. Collins, CO by NIST, which provides a 60Hz carrier wave on
+which is encoded the current time as synchronized with a pair of on-site atomic
+oscillators. The low frequency of the WWVB broadcast means it is available
+through most of North America. Perhaps you have heard of *Atomic Clock* radios.
+These simply incorporate a WWVB receiver which is then used to automatically
+set, and periodically compensate, the radio's internal real time clock
+circuitry.
+
+TMI's RWS (Remote Weather Station) project collects weather data completely
+autonomously, time-stamping recorded data using its onboard RTC. The WWVB
+broadcast is used to both initially set the RTC, and to periodically compensate
+for its drift over time.
+
+TMI chose to incorporate the C-MAX
+[CMMR-6](http://www.c-max-time.com/products/showProduct.php?id=31) WWVB receiver
+into its RWS design. This simple board requires very little power, and the fact
+that the WWVB receiver need only be consulted occasionally to compensate for RTC
+drift means its time averaged power consumption is very low. The CMMR-6 offers
+a simple output, TCO, treated as a digital signal. TCO is logic high when the
+WWVB carrier is transmitting at full power, and is logic low when the WWVB
+carrier is transmitting at reduced power. Each second uses a variable period in
+which the carrier is at reduced power to encode one of three values: a 0 bit, a
+1 bit, and a frame marker. 60 of these tri-state bits form a time frame
+containing the time, to the minute, during the current frame transmission. More
+about the WWVB signal format is available
+[here](http://tf.nist.gov/stations/wwvbtimecode.htm).
+
+While the [WWVB time code format](http://tf.nist.gov/stations/wwvbtimecode.htm)
+is easy to parse, this is not so true in the presense of noise. TMI has chosen
+to address noise by implementing a digital 4th order Butterworth filter, using a
+32Hz sample rate and a 3 Hz cutoff frequency. The filter inputs are either 0.0
+and 1.0, sampled from the CMMR-6 TCO pin, and the filter output is some fraction
+inclusive of the range 0.0 through 1.0. The microprocessor code implements
+hysteresis to generate a digital output, where outputs >= 0.7 are treated as
+logic 1, outputs <= 0.3 are logic zero, and any value in between these
+thresholds leave the logic output unchanged. This filter, implemented within
+the uC, requires up to 5% of the CPU while WWVB is in operation, but does a
+stellar job at cleaning up the WWVB signal. To evaluate filters and generate
+their implementation logic, we used the simple and easy to use
+[Fiview](http://www.uazu.net/fiview) design tool.
+
+Consider the following oscilliscope capture of live WWVB reception. TCO is the
+output from the CMMR, and FOUT is the output from the digital filter. Note that
+the filter delays the signal by approximately 200 ms.
+
+
+
+As mentioned earlier, the duration of the low period indicates the bit type.
+200 ms for bit 0, 500 ms for bit 1, and 800 ms for a frame mark. As can be seen
+in the TCO trace, there is a significant amount of relatively high frequency
+noise interfering with the TCO signal. A discrete algorithm would likely be
+unreliable in decoding TCO. However, the filtered output, FOUT, successfully
+removed all the noise with minimal signal distortion. A discrete algorithm can
+parse FOUT with a high degree of reliability. In this case, the trace as
+decoded -- 0 0 1 0 M 0 0 1 1 -- was the correct sequence for the captured frame.
+
+The decode algorithm determines a bit value for the current low period duration
+that is best matched by the expected durations. But the low pass filter cannot
+remove all sources of error, so a frame may be received with bits in error.
+Frames are validated according to the [WWVB time code
+format](http://tf.nist.gov/stations/wwvbtimecode.htm), and two frames must have
+matching data to consider a valid time acquisition. Of course in this sense,
+matching frames do not have the exact same values, but the second frame's
+contents differ from the first frame's only by the number of minutes separating
+their acquisition.
+
+There are still a few enhancements possible in this design. First, the TCO
+signal could be captured via an ADC, to bring additional information on each
+bit into the filter. This, however, might require some software gain control
+depending upon how good the CMMR-6 AGC circuitry is, and may not be worth the
+effort.
+
+The second enhancement is one that will be implemented. Instead of matching two
+complete frames to indicate valid aquisition, instead match complete frame
+sections. Three incoming frames all with errors in different sections would
+allow this latter approach to construct a known good frame, where the current
+algorithm could not. In very noisy cases, this enhancement should perform
+better.
+++ /dev/null
-title: CP210X
-linktitle: cp210x
-parent: Home
-ctime: 2009-12-10
-
-Repositories: [cp210x](/gitweb/?p=cp210x.git;a=summary), [[aptrepo]].
-
-# A USB to UART chip
-
-[Silicon Labs](http://www.silabs.com) sells a single-chip USB to UART bridge,
-the
-[cp210x](http://www.silabs.com/products/interface/usbtouart/Pages/default.aspx).
-For windows platforms, Silicon Labs offers manufacturing support for setting the
-various USB descriptor fields, port configurations, etc. They also offer a DLL
-and example programs showing how to manipulate the GPIO pins available on the
-cp2103 part.
-
-With support from Silicon Labs, TMI has modified their GPLv2 licensed reference
-Linux driver to support all of the features their Windows DLLs and utilities
-provide. This is accomplished via extended `ioctl()` calls from the kernel
-cp210x driver, and various utilities and sample code. This code is invaluable
-for those working on hardware designs using the cp2103. For example, TMI
-enhancements to tos-bsl in [[tinyos]] allow programming of an MSP430 based
-target using a USB/serial connection, by leveraging two of the four additional
-GPIO pins present on the cp2103.
-
-TMI completed these driver changes were originally completed in late 2007, but
-have been periodically updated since then to track changes to the linux kernel
-source. Silicon Labs was to push these changes through to the mainline kernel,
-did not do so. In mid 2010, TMI had discussions with the
-linux-usb developers, and a decent number of changes need to be made before they
-will include our modifications upstream. Specifically, they want to see all
-ioctl calls replaced with another mechanism. Perhaps we can allocate some time to
-work on these issues in the future. Meanwhile, TMI will continue to maintain
-its branch of the cp210x driver.
-
-The `cp210x-module-dkms` package in the TMI APT
-repository has been tested on (X)Ubuntu 8.04 LTS (Hardy Heron), 9.10 (Karmic
-Koala), 10.04 LTS (Lucid Lynx), 10.10 (Maverick Meerkat), 11.04 (Natty Narwhal),
-and 12.04 (Precise Pangolin). Because the driver uses the dkms facility, the
-driver should build for both 32 and 64 bit systems. Some testing has happened
-using older versions of 64-bit (X)Ubuntu, but TMI developers predominantly use
-32-bit Xubuntu 12.04 at the moment (2012-07-09).
-
-Note: Silicon Labs has introduced new USB/Serial chips, like the cp2104. The
-latest merge of the mainline cp210x driver, as present when used on 12.04
-systems, may be compatible with these newer parts. TMI has not tested for this
-compatibility.
+++ /dev/null
-title: Router Firmware
-linktitle: firmware
-parent: Home
-ctime: 2006-02-13
-
-Tarball: [gpl](http://www.titaniummirror.com/gpl).
-
-TMI has developed a fault tolerant internetworking platform composed of a set
-of proprietary cluster, event and web management applications running atop a
-GNU/Linux open source platform core. Essentially, the core represents a
-customized Linux distribution geared specifically for network appliances. The
-proprietary code developed by TMI does not link with any GPL components of the
-core and honors the terms of the license. Some minor changes have been made
-to the core components. Those changes are available
-[here](http://www.titaniummirror.com/gpl).
+++ /dev/null
-title: GIT Utilities
-linktitle: git-utils
-parent: Home
-ctime: 2009-12-10
-
-Repositories: [git-utils](/gitweb/?p=git-utils.git;a=summary).
-
-# GIT
-
-Read about [GIT](http://git-scm.com) here.
-
-# Utilities
-
-TMI is starting to collect a number of small utilities for git. Each utility
-has a man page describing its operation. A few notables:
-
-* `git-diffall`. Provides a facility for file-aware visual diff using an
- external diff tool such as kdiff3, meld, or a similar tool.
-
-* `git-empty-branch`. Create an empty branch in a local git repository.
-
-* `git-local`. Store local branches in a shared git repository under a private
- namespace. Upload, download, remove and list operations are provided. We
- use this tool to backup up local commits not yet suitable for pushing into a
- local shared branch.
-
-* `git-overview`. A simple script that scans a directory tree for git repos,
- showing the overall state of each.
-
-* `git-publish-branch`. A shell version of the ruby script created by William
- Morgan. See his [git utilities page](http://git-wt-commit.rubyforge.org).
- We did not want to have to install ruby just for this one little utility.
-
-* `git-push-public`. Used by TMI to replicate changes made to open source
- projects hosted on TMI private servers to the TMI public server.
-
-* `server-gc`. A tool to run git-gc on each bare git repository found within a
- given filesystem directory tree. Newest versions of git generally make this
- utility redundant.
-
-* `update-mirror`. Used by TMI to update a local git mirror of an upstream git
- or svn repository. Derived from the clone.sh script found at
- [girocco](http://repo.or.cz/w/girocco.git).
-
-# Installation
-
-These scripts are not packaged in the [[aptrepo]]. To install the utilities,
-copy the scripts to `/usr/local/bin` and ensure they have execute permission.
-Then copy the `*.1` files, which are the man pages, to `/usr/local/man/man1`.
title: OSS Repository
template: bodyheader
ctime: 2009-12-17
+mtime: 2000-01-01
title: OSS Projects
linktitle: Home
ctime: 2009-12-15
+mtime: 2000-01-01
# Introduction
--- /dev/null
+title: Misc
+linktitle: misc
+parent: Home
+ctime: 2012-08-15
+mtime: 2000-01-01
+
+This category contains miscellaneous items of possible interest. Please select
+from the side menu on the left.
--- /dev/null
+title: Router Firmware
+linktitle: firmware
+parent: misc
+ctime: 2006-02-13
+mtime: 2006-02-13
+
+Tarball: [gpl](http://www.titaniummirror.com/gpl).
+
+TMI has developed a fault tolerant internetworking platform composed of a set
+of proprietary cluster, event and web management applications running atop a
+GNU/Linux open source platform core. Essentially, the core represents a
+customized Linux distribution geared specifically for network appliances. The
+proprietary code developed by TMI does not link with any GPL components of the
+core and honors the terms of the license. Some minor changes have been made
+to the core components. Those changes are available
+[here](http://www.titaniummirror.com/gpl).
--- /dev/null
+title: MSP430
+linktitle: msp430
+parent: misc
+ctime: 2008-01-03
+mtime: 2012-07-01
+
+*This project is obsolete*. As of the release of Ubuntu 12.04 Precise Pangolin,
+an up-to-date version of the MSP430 cross toolchain is available in the standard
+repositories. For this reason, TMI is no longer maintaining its own MSP430
+toolchain, which ultimately use the same upstream source as the new standard
+packages do. See the [[TMI Repository|aptrepo]] page for more information.
+
+As of 2012-08-15, the msp430-gdb package does not install due to a file
+conflict as shown below.
+
+ dpkg: error processing
+ /var/cache/apt/archives/gdb-msp430_7.2~mspgcc-7.2-20110612-1ubuntu1_i386.deb
+ (--unpack):
+ trying to overwrite '/usr/share/gdb/python/gdb/__init__.py', which is also
+ in package gdb 7.4-2012.04-0ubuntu2
+
+Repositories:
+[msp430-binutils](/gitweb/?p=msp430-binutils.git;a=summary),
+[msp430-gcc](/gitweb/?p=msp430-gcc.git;a=summary),
+[msp430-libc](/gitweb/?p=msp430-libc.git;a=summary),
+[[aptrepo]].
--- /dev/null
+title: OSS Website Code
+linktitle: oss-web
+parent: misc
+ctime: 2009-12-15
+mtime: 2009-12-15
+
+Repositories: [oss-web](/gitweb/?p=oss-web.git;a=summary).
+
+The website you are viewing now is statically generated from the
+[oss-web](/gitweb/?p=oss-web.git;a=summary). repository using [[Webber]].
--- /dev/null
+title: Webber
+linktitle: webber
+parent: misc
+ctime: 2009-12-15
+mtime: 2009-12-15
+
+Repositories: [webber](/gitweb/?p=webber.git;a=summary).
+
+[Webber](http://gitorious.org/webber) is a great static website generator
+written in Python by
+[Holger Schurig](http://www.holgerschurig.de/projects/webber/). We maintain
+a [local copy](/gitweb/?p=webber.git;a=summary) of his repository
+with a few changes. This website is built using webber; see [[oss-web]].
+++ /dev/null
-title: MSP430
-linktitle: msp430
-parent: Home
-ctime: 2008-01-03
-
-Repositories:
-[msp430-binutils](/gitweb/?p=msp430-binutils.git;a=summary),
-[msp430-gcc](/gitweb/?p=msp430-gcc.git;a=summary),
-[msp430-libc](/gitweb/?p=msp430-libc.git;a=summary),
-[[aptrepo]].
-
-TMI maintains an msp430 toolchain, including [[Ubuntu packages|aptrepo]], which
-works with newer members of the msp430 family including the popular MSP430F2x1x
-parts such as the MSP430F2618. This toolchain is properly patched for use in
-[[TinyOS]] development.
-
-As of the release of Ubuntu 12.04 Precise Pangolin, an up-to-date version of the
-MSP430 cross toolchain is available in the standard repositories. For this
-reason, TMI is no longer maintaining its own packages, which ultimately use the
-same upstream source as the new standard packages do. See the [[TMI
-Repository|aptrepo]] page for more information.
-
-As of 2012-06-15, the msp430-gdb package does not install due to a file
-conflict. This will likely be fixed soon.
title: News
ctime: 2009-12-16
+mtime: 2012-08-15
-### 2012-08-13
-Post [[Virtual Windows 7|virtual-win7]] article, and perform some
-cleanups.
+### 2012-08-15
+Reorganize the website into three categories: [[blog]], [[misc]], and
+[[projects]].
---
+++ /dev/null
-title: OSS Website Code
-linktitle: oss-web
-parent: Home
-ctime: 2009-12-15
-
-Repositories: [oss-web](/gitweb/?p=oss-web.git;a=summary).
-
-This website is statically generated from the repository using [[Webber]].
+++ /dev/null
-title: OpenVZ + BackupPC
-linktitle: ovzbpc
-parent: Home
-ctime: 2008-06-09
-
-Repositories: [ovzbpc](/gitweb/?p=ovzbpc.git;a=summary).
-
-# TMI backup strategy
-
-TMI hosts its compute resources in [OpenVZ](http://www.openvz.org) Virtual
-Environments (VE) running on a cluster of Dell PE1800 servers. The contents
-of each VE, as well as the servers hosting them, are backed up using
-[BackupPC](http://backuppc.sourceforge.net). Periodically, a clone of the
-BackupPC disk archive is made on one of a pool of external eSATA drives, which
-are rotated off-site for disaster recovery. TMI has authored a few program
-scripts which integrate these backup components.
-
-* `BackupPC_ovz` allows an OpenVZ VE to be backed up and restored via BackupPC
- without special configuration of the VE, nor with BackupPC being told on
- which hardware node the VE is running. See the
- [README](/gitweb/?p=ovzbpc.git;a=blob;f=README;hb=HEAD) for more
- information.
-
-* `bpcdump` and friends support cloning the BackupPC VE to a removeable eSATA
- drive for disaster recovery. See [README.bpcdump](/gitweb/?p=ovzbpc.git;a=blob;f=README.bpcdump;hb=HEAD)
- for more information.
-
-* `esata` wraps the `scsiadd` utility for properly handling eSATA drives on
- Dell PE1800 and PE1900 platforms. Newer hardware and better Linux kernel
- support will someday make scripts like this unnecessary. See
- [README.esata](/gitweb/?p=ovzbpc.git;a=blob;f=README.esata;hb=HEAD)
- for more information.
--- /dev/null
+title: Projects
+linktitle: projects
+parent: Home
+ctime: 2012-08-15
+mtime: 2000-01-01
+
+TMI has posted code and info for various projects on this website. Navigate the
+projects from the left pane.
--- /dev/null
+title: CP210X
+linktitle: cp210x
+parent: projects
+ctime: 2009-12-10
+mtime: 2012-07-03
+
+Repositories: [cp210x](/gitweb/?p=cp210x.git;a=summary), [[aptrepo]].
+
+# A USB to UART chip
+
+[Silicon Labs](http://www.silabs.com) sells a single-chip USB to UART bridge,
+the
+[cp210x](http://www.silabs.com/products/interface/usbtouart/Pages/default.aspx).
+For windows platforms, Silicon Labs offers manufacturing support for setting the
+various USB descriptor fields, port configurations, etc. They also offer a DLL
+and example programs showing how to manipulate the GPIO pins available on the
+cp2103 part.
+
+With support from Silicon Labs, TMI has modified their GPLv2 licensed reference
+Linux driver to support all of the features their Windows DLLs and utilities
+provide. This is accomplished via extended `ioctl()` calls from the kernel
+cp210x driver, and various utilities and sample code. This code is invaluable
+for those working on hardware designs using the cp2103. For example, TMI
+enhancements to tos-bsl in [[tinyos]] allow programming of an MSP430 based
+target using a USB/serial connection, by leveraging two of the four additional
+GPIO pins present on the cp2103.
+
+TMI completed these driver changes were originally completed in late 2007, but
+have been periodically updated since then to track changes to the linux kernel
+source. Silicon Labs was to push these changes through to the mainline kernel,
+did not do so. In mid 2010, TMI had discussions with the
+linux-usb developers, and a decent number of changes need to be made before they
+will include our modifications upstream. Specifically, they want to see all
+ioctl calls replaced with another mechanism. Perhaps we can allocate some time to
+work on these issues in the future. Meanwhile, TMI will continue to maintain
+its branch of the cp210x driver.
+
+The `cp210x-module-dkms` package in the TMI APT
+repository has been tested on (X)Ubuntu 8.04 LTS (Hardy Heron), 9.10 (Karmic
+Koala), 10.04 LTS (Lucid Lynx), 10.10 (Maverick Meerkat), 11.04 (Natty Narwhal),
+and 12.04 (Precise Pangolin). Because the driver uses the dkms facility, the
+driver should build for both 32 and 64 bit systems. Some testing has happened
+using older versions of 64-bit (X)Ubuntu, but TMI developers predominantly use
+32-bit Xubuntu 12.04 at the moment (2012-07-09).
+
+Note: Silicon Labs has introduced new USB/Serial chips, like the cp2104. The
+latest merge of the mainline cp210x driver, as present when used on 12.04
+systems, may be compatible with these newer parts. TMI has not tested for this
+compatibility.
--- /dev/null
+title: GIT Utilities
+linktitle: git-utils
+parent: projects
+ctime: 2009-12-10
+mtime: 2012-05-16
+
+Repositories: [git-utils](/gitweb/?p=git-utils.git;a=summary).
+
+# GIT
+
+Read about [GIT](http://git-scm.com) here.
+
+# Utilities
+
+TMI is starting to collect a number of small utilities for git. Each utility
+has a man page describing its operation. A few notables:
+
+* `git-diffall`. Provides a facility for file-aware visual diff using an
+ external diff tool such as kdiff3, meld, or a similar tool.
+
+* `git-empty-branch`. Create an empty branch in a local git repository.
+
+* `git-local`. Store local branches in a shared git repository under a private
+ namespace. Upload, download, remove and list operations are provided. We
+ use this tool to backup up local commits not yet suitable for pushing into a
+ local shared branch.
+
+* `git-overview`. A simple script that scans a directory tree for git repos,
+ showing the overall state of each.
+
+* `git-publish-branch`. A shell version of the ruby script created by William
+ Morgan. See his [git utilities page](http://git-wt-commit.rubyforge.org).
+ We did not want to have to install ruby just for this one little utility.
+
+* `git-push-public`. Used by TMI to replicate changes made to open source
+ projects hosted on TMI private servers to the TMI public server.
+
+* `server-gc`. A tool to run git-gc on each bare git repository found within a
+ given filesystem directory tree. Newest versions of git generally make this
+ utility redundant.
+
+* `update-mirror`. Used by TMI to update a local git mirror of an upstream git
+ or svn repository. Derived from the clone.sh script found at
+ [girocco](http://repo.or.cz/w/girocco.git).
+
+# Installation
+
+These scripts are not packaged in the [[aptrepo]]. To install the utilities,
+copy the scripts to `/usr/local/bin` and ensure they have execute permission.
+Then copy the `*.1` files, which are the man pages, to `/usr/local/man/man1`.
--- /dev/null
+title: OpenVZ + BackupPC
+linktitle: ovzbpc
+parent: projects
+ctime: 2008-06-09
+mtime: 2009-12-16
+
+Repositories: [ovzbpc](/gitweb/?p=ovzbpc.git;a=summary).
+
+# TMI backup strategy
+
+TMI hosts its compute resources in [OpenVZ](http://www.openvz.org) Virtual
+Environments (VE) running on a cluster of Dell PE1800 servers. The contents
+of each VE, as well as the servers hosting them, are backed up using
+[BackupPC](http://backuppc.sourceforge.net). Periodically, a clone of the
+BackupPC disk archive is made on one of a pool of external eSATA drives, which
+are rotated off-site for disaster recovery. TMI has authored a few program
+scripts which integrate these backup components.
+
+* `BackupPC_ovz` allows an OpenVZ VE to be backed up and restored via BackupPC
+ without special configuration of the VE, nor with BackupPC being told on
+ which hardware node the VE is running. See the
+ [README](/gitweb/?p=ovzbpc.git;a=blob;f=README;hb=HEAD) for more
+ information.
+
+* `bpcdump` and friends support cloning the BackupPC VE to a removeable eSATA
+ drive for disaster recovery. See [README.bpcdump](/gitweb/?p=ovzbpc.git;a=blob;f=README.bpcdump;hb=HEAD)
+ for more information.
+
+* `esata` wraps the `scsiadd` utility for properly handling eSATA drives on
+ Dell PE1800 and PE1900 platforms. Newer hardware and better Linux kernel
+ support will someday make scripts like this unnecessary. See
+ [README.esata](/gitweb/?p=ovzbpc.git;a=blob;f=README.esata;hb=HEAD)
+ for more information.
--- /dev/null
+title: RGB Lamp
+linktitle: rgblamp
+parent: projects
+ctime: 2012-03-10
+mtime: 2012-03-10
+
+The RGB Lamp was a little filler project. A 4.2W CREE RGBW LED module is driven
+by a PIC16LF1933. Learn more:
+
+* [[Code Notes|rgb-code]]
+* [[Features|rgb-features]]
+* [[Mechanical|rgb-mechanical]]
+* [Source Code](/gitweb/?p=rgblamp.git;a=summary)
+
+A future implementation might accept audio input from a stereo jack or onboard
+microphone, use a DFT to examine the frequency components present in the audio
+stream, represent each of several bands of frequencies with a color whose
+brightness is proportional to the signal strength, then 'mix' the per-frequency
+color results into an RGBW output that can drive the LED module. Because of the
+higher performance needed, we will probably use a STMicro STM32 or EnergyMicro
+EFM32 low power ARM Cortex-M3 processor.
--- /dev/null
+title: RGB Lamp Code
+linktitle: rgb-code
+parent: rgblamp
+ctime: 2012-03-10
+mtime: 2012-03-10
+
+PIC code for the [[rgblamp]] is written in C and compiled using the MPLAB X
+cross-platform IDE and the HI-TECH C compiler.
+
+The lamp code uses a simple event driven strategy. Events are generally
+initiated through hardware events. Application logic is structured as a set of
+tasks, each of which is executed in response to a given event. Because much of
+the behavior of the lamp application is dependent upon timing, a timer
+abstraction is also useful.
+
+So, this code uses both of these useful abstractions: tasks and timers. This
+project hacks together some basic support for tasks and timers for the PIC16.
+Thankfully the atypical architecture of the PIC16 is mostly abstracted by the C
+compiler. And because this is such a simple project, the simplistic interrupt
+handling of the PIC16 is not an issue either. And although not very flexible in
+its use, driving Timer 1 via a 32 kHz crystal offers reasonable support for
+auto-on from soft off.
+
+* [[rgb-task]]
+* [[rgb-timer]]
+
+The project yielded some other other novel tidbits.
+
+* [[rgb-leds]]
+* [[rgb-random]]
--- /dev/null
+title: RGB Lamp Features
+linktitle: rgb-features
+parent: rgblamp
+ctime: 2012-03-10
+mtime: 2012-03-10
+
+# [[rgblamp]] features
+
+* Auto power cycling, 5 hours on, 19 hours off.
+* Brightness level adjustment
+* Twelve colors, which include white and a simulated candle color
+* Several modes: random color change, slow color change, and fixed color
+* Simulated candle flicker for all colors except for white
+* Persistent state configuration
+
+# The power switch
+
+The power switch has three positions: off, on, and auto. When the switch
+position changes to auto, a timer is started that turns off the lamp in five
+hours, then back on again nineteen hours later.
+
+# The push button
+
+When the pushbutton is depressed briefly, then released, the lamp color mode is
+changed. Modes cycle through all twelve color modes, the first of which is the
+candle simulation and the last of which is white. The mode immediately
+following white is the slow color change mode, which itself cycles through the
+colors every sixteen minutes. The next and final mode is a rapid and random
+color change mode (party mode). A mode change when in party mode returns to the
+first mode.
+
+When the pushbutton is depressed and held, brightness varies until the
+pushbutton is released. Brightness is dimmed until a minimum brightness is
+reached. After a short delay at the minimum brightness, brightness is
+then increased over time until a maximum brightness is reached. After a short
+delay at the maximum brightness, the process repeats. Once the pushbutton is
+released, the brightness setting at that point is retained persistently.
--- /dev/null
+title: RGB Lamp Led Driver
+linktitle: rgb-leds
+parent: rgb-code
+ctime: 2012-03-10
+mtime: 2012-03-10
+
+# PWM drive
+
+The LEDs in the module receive varying current to adjust their brightness via
+the hardware PWM features of the PIC16LF1933 in conjunction with Timer 2. The
+module has 4 capture/compare peripherals, which is perfect for the 4 LEDs in the
+module.
+
+Each PWM output controls a simple current limited 2-transister drive circuit.
+This circuit is superior to a simple single transistor switch, as the CE
+junction of one transistor is used as a fixed voltage drop controlling current
+through a resistor of known size. This is particularly nice given that
+different LED modules have differnt voltage drops, and voltage drop is also a
+function of current and temperature. A fixed current driver removes these
+variables.
+
+# Mixing color and brightness
+
+An interesting challenge is to manipulate the output of the discrete color LEDs
+both for the purpose of emitting a specific color and for controlling the
+brightness. The solution is to treat the pre-computed PWM output value as a
+fraction of the maximum value (255). In the same fashion, the color range and
+the brightness are also treated as a fraction of their respective maximums.
+Therefore, the rgb drive output is essentially the product of the color and
+brightness values. Simple, and it seems to work out pretty well.
+
+ rgb = 255 * (color/color_max * bright/bright_max)
+
+Of course, for this processor the preference is to do this computation in
+integer math. The actual implementation looks more like this:
+
+ color: 0..63
+ bright: 0..BRIGHT_MAX
+ rgb = (color << 4) * bright / 4 / BRIGHT_MAX
+
+# LEDs
+
+An interesting effect was uncovered during testing. A certain delta change in
+drive string of a LED at a relatively low average power level is readily
+perceptible vsually, while the same delta is hard to detect at higher power
+levels. Some research shows this to be a nature of the human eye -- it
+perceives changes at lower intensities more readily than at higher percentages
+[(1)](http://neuroelec.com/2011/04/led-brightness-to-your-eye-gamma-correction-no/).
+To get a perceived linear output, the PWM value must be adjusted according to
+CIE Lightness.
+
+ L* = 116(Y/Yn)^1/3 - 16 , Y/Yn > 0.008856
+ L* = 903.3(Y/Yn), Y/Yn <= 0.008856
+
+Using these formulas, a look-up table can be created to provide the
+compensation. It works pretty well. The rgb.c and rgb.h files in the
+[repository](http://oss/gitweb?p=rgblamp.git;a=summary) implement this feature.
+Note that there are two different look-up tables available, depending upon the
+resolution desired.
--- /dev/null
+title: RGB Lamp Features
+linktitle: rgb-mechanical
+parent: rgblamp
+ctime: 2012-03-10
+mtime: 2012-03-10
+
+The [[rgblamp]] mechanicals are based on a little rectangular lamp purchased at
+IKEA. The CREE LED module is placed on a 1/2 inch think heat sink designed for
+the module, and that module is mounted inside the lamp in place of the standard
+screw bulb mount.
+
+There are several challenges with this design. First, the LED module must not
+exceed its thermal specs during operation. Second, the lamp must not expose
+human eyes to the direct output of the LED module. Finally, we need to find a
+way to mount both the module and the electronics.
+
+# Thermal issues
+
+The
+[datasheet](http://media.digikey.com/PDF/Data%20Sheets/Wakefield%20Thermal%20PDFs/882_Series.pdf)
+for the 0.5 inch thick [heat
+sink](http://search.digikey.com/us/en/products/882-50AB/345-1104-ND/2640527)
+specifies a 60 degree C rise in temperature when dissipating 9W with natural
+convection. That is 60/9 or 6.67 C/W. Since the [CREE LED
+module](http://search.digikey.com/us/en/products/MCE4CT-A2-RGBCW-STAR-IND/955-1043-ND/2357817)
+will be limited to 350 mA at about 3.2 V by the control circuitry, maximum power
+dissipation is 1.12 W per LED, or 4.48 W for the entire module. In ambient air,
+the 0.5 inch heatsink will see a rise over ambient of about 30 degrees Celcius.
+So if room temperature is 30 C (86 F), the temperature and the juntion beween
+the module and the heatsink should be about 60 C. I failed to locate a maximum
+junction temperature for this module, but 60 C is not too high for most other
+LEDs out there. To ensure good thermal contact, the module was secured to the
+heat sink with machine screws and a bit of thermal paste.
+
+In operation, the lamp when tested in operation suggests the heat sink is
+actually performing a bit better than the data sheet numbers suggest.
+
+# Eye protection
+
+The problem with the IKEA lamp used is that it is open through the top. This is
+an advantage thermally because the lamp acts like a chimney, allowing cool air
+to enter through the opening in the bottom -- which was left open for
+ventilation purposes -- and warmer air to rise out of the top. The downside is that a
+person could easily look into the lamp from above. These high power modules can
+cause retinal damage, so this is a problem. The solution was to mount a few
+inches above the LED module a diffuser. The diffuesr spreads the light nicely
+while also blocking direct visual exposure of the module LEDs.
+
+# Mechanical mounting notes
+
+This was a quick project, so the mechanicals are of the basic prototype variety.
+The electronics are mounted on perfboard in a small project box, and a short
+section of 28 AWG cat 5e cable delivers current to the LED module. A DC wall
+wart is used for power, and the heat sink is mounted in the lamp with hot glue.
--- /dev/null
+title: A Source of Randomness
+linktitle: rgb-random
+parent: rgb-code
+ctime: 2012-03-10
+mtime: 2012-03-10
+
+# Randomness
+
+The lamp implements a 'party' mode, which randomizes the next color and the time
+for which that color will be displayed before the next color change. The code
+uses an efficient parallel bit implementation of a Galois linear shift register.
+However, unless a random seed value can be acquired, the sequence will be the
+same each and every time.
+
+# Truly random
+
+The PIC16 has no PRNG (pseudo-random number generator). An approach to
+simulating a PRNG is to use the ADC to capture from an unused pin. The
+assumption is that noise present in the last least significant bit or so of the
+result can be summed to generate a pseudo-random number. No testing was done to
+attempt to quantify the quality of this methodology, but it certainly provides
+some amount of randomness and is adequate for the simple needs of this project.
--- /dev/null
+title: RGB Lamp Tasks
+linktitle: rgb-task
+parent: rgb-code
+ctime: 2012-03-10
+mtime: 2012-03-10
+
+# Tasks
+
+A task implements an application behavior in response to an event. Tasks are
+executed to completion without pre-emption. Task start requests are queued if
+another task is already executing. A task start request when that task is
+already queued to start is effectively a null operation. However, a task start
+request for a task that is not queued but currently running will queue the task
+for a subsequent execution. This very simple task design is more than
+sufficient for the needs of the lamp application.
+
+One key decision under such a task architecture is which task to run next if
+multiple tasks are queued. This code selects the task with the highest priority
+in such a case. Application code must be cognizant of this fact, as a
+perpetually queueing high priority task will prevent execution of a queued lower
+priority task. This behavior is similar to hardware interrupt dispatch in many
+processor architectures, so most developers should already be familiar with its
+pitfalls.
+
+# Task implementation
+
+Tasks are implemented in the task.c, task.h and task_defs.h files,
+as found in the [repository](http://oss/gitweb?p=rgblamp.git;a=summary).
+
+Task identifiers are defind in the task_defs.h file. Each task id is an
+enumeration, with the highest priority task given the value of zero, and
+successively lower priority tasks having incrementally larger numbers. Since
+the task queue is implemented as bits in a variable, the width of the task_id_t
+structure defines the maximum number of supported tasks.
+
+Before using, initialize the task subsystem:
+
+ task_init();
+
+To queue a task for execution, post it. Tasks can be posted from within an ISR
+or from without. A task can post itself as well.
+
+ task_post(TASK_ID);
+
+Task dispatch is constructed from the task_get() function, which atomically gets
+and clears the next task (bit). The user application code then constructs a
+switch statement or similar structure to call a function associated with each
+task id. The lamp code implements this behavior in the user_tasks() function
+in main.c. Check it out in the
+[repository](http://oss/gitweb?p=rgblamp.git;a=summary). A short version:
+
+ void user_tasks(unsigned char block)
+ {
+ task_id_t tid;
+
+ while ((tid = task_get(block)) >= 0) {
+ switch (tid) {
+ case TASK_BTN_PB:
+ pb_task();
+ break;
+ ...
+ }
+ }
+ }
+
--- /dev/null
+title: RGB Lamp Timers
+linktitle: rgb-timer
+parent: rgb-code
+ctime: 2012-03-10
+mtime: 2012-03-10
+
+# Timers
+
+Most microcontroller applications must respond to temporal events. The timers
+subsystem allows an application to have multiple timers running concurrently,
+each with a different duration before expiration. This implementation is very
+simple, in that timers can be started, stoped, and polled for expiration
+(fired). By integrating with tasks, a timer expiration can post an event.
+
+Timers are identified by a timer id. A timer started will fire at the end of
+the time period specified in the timer start call. A timer may also be started
+via startPeriodic(), which will fire the timer periodically according to the
+timer period specified in the call.
+
+# Implementation
+
+The timer subsystem is implemented through the use of the PIC16 TMR0. It is
+configured to trigger a hardware interrupt every 32.768 milliseconds. Within
+each interrupt, the status of the currently active timers is updated. This is a
+very simplistic approach. A better solution would be to use a timer compare
+feature, which would dramatically reduce the number of ISR events and therefore
+servicing overhead for the timer subsystem.
+
+Periodically the application can poll for timer fired by the tmr_fired() call.
+A good time to do this is in the ISR, and timers that fire can post tasks. The
+comments in tmr.h gives a complete example. Check the
+[repository](http://oss/gitweb?p=rgblamp.git;a=summary).
+
+# Timer and low power modes
+
+Unfortunately, the PIC16 has limitations when it comes to using timers in sleep.
+While it is true that Timer 1 can run when the PIC16 is in sleep using an
+external 32 kHz crystal, no timer compare feature is possible in sleep.
+Therefore, the only timer inerrupt that can wake the micro is the overflow.
+This overflow happens every 2 seconds. In fact, the lamp code uses this
+behavior to handle the long term timer events via the tmr32 module.
+Specifically, this is used for the auto-off and auto-on events.
+
+It is possible to get different overflow periods by programmatically setting the
+Timer 1 register. Since this is a 16 bit value implemented in 2 8-bit
+registers, there are race conditions that challenge this use. But the ability
+to support variable timer periods in sleep is possible.
+
+When it comes to managing temporal events and deep sleep, the MSP430, the EFM32,
+and the STM32L are superior processors.
+
--- /dev/null
+title: TinyOS
+linktitle: tinyos
+parent: projects
+ctime: 2009-12-07
+mtime: 2012-03-21
+
+Repositories: [tinyos](/gitweb/?p=tinyos-2.x.git;a=summary),
+[deputy-tinyos](/gitweb/?p=deputy-tinyos.git;a=summary),
+[nesc](/gitweb/?p=nesc.git;a=summary),
+[[aptrepo]].
+
+# TMI TinyOS
+
+TMI maintains a [TinyOS](http://www.tinyos.net) branch containing certain
+features not available in the official tree. We use this this code for our
+internal and customer development efforts. TMI enhancements include:
+
+* Support for newer [[msp430]] chipsets, such as the MSP430F2618.
+
+* An implementation of the USCI peripheral, supporting UART, SPI and I2C
+ communications. Both SPI slave and master modes are supported, with the
+ driver knowing what to do in slave mode if the master unasserts the slave chip
+ select line.
+
+* Enhanced clock framework supporting parts with the basic_clock+ peripheral
+ and simplifying changing msp430 clock speeds on a per platform or per
+ application basis.
+
+* Support for a number of other chips, including the Silicon Labs
+ [[cp210x]] USB to UART adapters, the Texas Instruments BQ2403x Li Ion/Polymer
+ charge controllers, and the VTI SCP1000-D01 barometric pressure sensor.
+
+* A modularized tos-bsl program that simplifies adding other msp430 boards using
+ different mechanisms to access BSL programming features. Included is support
+ for boards using the cp2103 and its GPIO pins to effect BSL via USB.
+
+* Support for TMI reference platform design, [[tmicore]].
+
+# About the TMI repository
+
+The TMI TinyOS repository is based upon code from the [official
+repo](http://tinyos-main.googlecode.com/svn/). The TMI repository contains
+various branches and tags representing current and past work. Most notably, the
+tags beginning with `patchset/` are clean patches against a given official
+upstream release.
+
+* Current patchset tag: `patchset/2.1.1-4.5`
+* TMI enhancements are based upon the upstream release tag: `tinyos/2.1.1`
+* The commits between the two above tags represent the series of patches in the
+ [latest patchset](/gitweb/?p=tinyos-2.x.git;a=shortlog;h=refs/tags/patchset/2.1.1-4.5).
+
+The TMI TinyOS code requires a GCC 4.4+ based [[msp430]] toolchain.
+
+# Using TMI TinyOS
+
+A complete TinyOS development environment including toolchain is available for
+installation from our [[APT repository|aptrepo]]. Since we only use Ubuntu
+workstations for our internal development, we cannot cost justify maintaining
+packages for Windows or other Linux distributions at this time.
--- /dev/null
+title: tmicore
+parent: projects
+ctime: 2009-12-02
+mtime: 2009-12-02
+
+Repositories: SOON
+
+TMI has developed an [[msp430]] target board for low power data acquisition.
+Its design is not complete yet, but it is (SOON) available under an open
+source license. The design was created using [Eagle](http://www.cadsoft.de).
+It provides a breakout of all uC pins, incorporates a Lithium Ion/Poly charger,
+and a USB interface for communications and programming.
+
+The actual design files are for the tmirws board, which is a superset of the
+tmicore design. One can trivially derive the tmicore design by simply cutting
+the board layout at the inner rectangle. The tmirws design is the heart of an
+off-grid solar powered remote weather station that reports its observations to
+an internet server via the cellular network.
+
+TMI enhanced [[tinyos]] contains platform support for both the tmicore and
+tmirws variants of this design.
+++ /dev/null
-title: RGB Lamp
-linktitle: rgblamp
-parent: Home
-ctime: 2012-03-24
-
-The RGB Lamp was a little filler project. A 4.2W CREE RGBW LED module is driven
-by a PIC16LF1933. Learn more:
-
-* [[Code Notes|rgb-code]]
-* [[Features|rgb-features]]
-* [[Mechanical|rgb-mechanical]]
-* [Source Code](/gitweb/?p=rgblamp.git;a=summary)
-
-A future implementation might accept audio input from a stereo jack or onboard
-microphone, use a DFT to examine the frequency components present in the audio
-stream, represent each of several bands of frequencies with a color whose
-brightness is proportional to the signal strength, then 'mix' the per-frequency
-color results into an RGBW output that can drive the LED module. Because of the
-higher performance needed, we will probably use a STMicro STM32 or EnergyMicro
-EFM32 low power ARM Cortex-M3 processor.
+++ /dev/null
-title: RGB Lamp Code
-linktitle: rgb-code
-parent: rgblamp
-ctime: 2012-03-24
-
-PIC code for the [[rgblamp]] is written in C and compiled using the MPLAB X
-cross-platform IDE and the HI-TECH C compiler.
-
-The lamp code uses a simple event driven strategy. Events are generally
-initiated through hardware events. Application logic is structured as a set of
-tasks, each of which is executed in response to a given event. Because much of
-the behavior of the lamp application is dependent upon timing, a timer
-abstraction is also useful.
-
-So, this code uses both of these useful abstractions: tasks and timers. This
-project hacks together some basic support for tasks and timers for the PIC16.
-Thankfully the atypical architecture of the PIC16 is mostly abstracted by the C
-compiler. And because this is such a simple project, the simplistic interrupt
-handling of the PIC16 is not an issue either. And although not very flexible in
-its use, driving Timer 1 via a 32 kHz crystal offers reasonable support for
-auto-on from soft off.
-
-* [[rgb-task]]
-* [[rgb-timer]]
-
-The project yielded some other other novel tidbits.
-
-* [[rgb-leds]]
-* [[rgb-random]]
+++ /dev/null
-title: RGB Lamp Features
-linktitle: rgb-features
-parent: rgblamp
-ctime: 2012-03-24
-
-# [[rgblamp]] features
-
-* Auto power cycling, 5 hours on, 19 hours off.
-* Brightness level adjustment
-* Twelve colors, which include white and a simulated candle color
-* Several modes: random color change, slow color change, and fixed color
-* Simulated candle flicker for all colors except for white
-* Persistent state configuration
-
-# The power switch
-
-The power switch has three positions: off, on, and auto. When the switch
-position changes to auto, a timer is started that turns off the lamp in five
-hours, then back on again nineteen hours later.
-
-# The push button
-
-When the pushbutton is depressed briefly, then released, the lamp color mode is
-changed. Modes cycle through all twelve color modes, the first of which is the
-candle simulation and the last of which is white. The mode immediately
-following white is the slow color change mode, which itself cycles through the
-colors every sixteen minutes. The next and final mode is a rapid and random
-color change mode (party mode). A mode change when in party mode returns to the
-first mode.
-
-When the pushbutton is depressed and held, brightness varies until the
-pushbutton is released. Brightness is dimmed until a minimum brightness is
-reached. After a short delay at the minimum brightness, brightness is
-then increased over time until a maximum brightness is reached. After a short
-delay at the maximum brightness, the process repeats. Once the pushbutton is
-released, the brightness setting at that point is retained persistently.
+++ /dev/null
-title: RGB Lamp Led Driver
-linktitle: rgb-leds
-parent: rgb-code
-ctime: 2012-03-24
-
-# PWM drive
-
-The LEDs in the module receive varying current to adjust their brightness via
-the hardware PWM features of the PIC16LF1933 in conjunction with Timer 2. The
-module has 4 capture/compare peripherals, which is perfect for the 4 LEDs in the
-module.
-
-Each PWM output controls a simple current limited 2-transister drive circuit.
-This circuit is superior to a simple single transistor switch, as the CE
-junction of one transistor is used as a fixed voltage drop controlling current
-through a resistor of known size. This is particularly nice given that
-different LED modules have differnt voltage drops, and voltage drop is also a
-function of current and temperature. A fixed current driver removes these
-variables.
-
-# Mixing color and brightness
-
-An interesting challenge is to manipulate the output of the discrete color LEDs
-both for the purpose of emitting a specific color and for controlling the
-brightness. The solution is to treat the pre-computed PWM output value as a
-fraction of the maximum value (255). In the same fashion, the color range and
-the brightness are also treated as a fraction of their respective maximums.
-Therefore, the rgb drive output is essentially the product of the color and
-brightness values. Simple, and it seems to work out pretty well.
-
- rgb = 255 * (color/color_max * bright/bright_max)
-
-Of course, for this processor the preference is to do this computation in
-integer math. The actual implementation looks more like this:
-
- color: 0..63
- bright: 0..BRIGHT_MAX
- rgb = (color << 4) * bright / 4 / BRIGHT_MAX
-
-# LEDs
-
-An interesting effect was uncovered during testing. A certain delta change in
-drive string of a LED at a relatively low average power level is readily
-perceptible vsually, while the same delta is hard to detect at higher power
-levels. Some research shows this to be a nature of the human eye -- it
-perceives changes at lower intensities more readily than at higher percentages
-[(1)](http://neuroelec.com/2011/04/led-brightness-to-your-eye-gamma-correction-no/).
-To get a perceived linear output, the PWM value must be adjusted according to
-CIE Lightness.
-
- L* = 116(Y/Yn)^1/3 - 16 , Y/Yn > 0.008856
- L* = 903.3(Y/Yn), Y/Yn <= 0.008856
-
-Using these formulas, a look-up table can be created to provide the
-compensation. It works pretty well. The rgb.c and rgb.h files in the
-[repository](http://oss/gitweb?p=rgblamp.git;a=summary) implement this feature.
-Note that there are two different look-up tables available, depending upon the
-resolution desired.
+++ /dev/null
-title: RGB Lamp Features
-linktitle: rgb-mechanical
-parent: rgblamp
-ctime: 2012-03-24
-
-The [[rgblamp]] mechanicals are based on a little rectangular lamp purchased at
-IKEA. The CREE LED module is placed on a 1/2 inch think heat sink designed for
-the module, and that module is mounted inside the lamp in place of the standard
-screw bulb mount.
-
-There are several challenges with this design. First, the LED module must not
-exceed its thermal specs during operation. Second, the lamp must not expose
-human eyes to the direct output of the LED module. Finally, we need to find a
-way to mount both the module and the electronics.
-
-# Thermal issues
-
-The
-[datasheet](http://media.digikey.com/PDF/Data%20Sheets/Wakefield%20Thermal%20PDFs/882_Series.pdf)
-for the 0.5 inch thick [heat
-sink](http://search.digikey.com/us/en/products/882-50AB/345-1104-ND/2640527)
-specifies a 60 degree C rise in temperature when dissipating 9W with natural
-convection. That is 60/9 or 6.67 C/W. Since the [CREE LED
-module](http://search.digikey.com/us/en/products/MCE4CT-A2-RGBCW-STAR-IND/955-1043-ND/2357817)
-will be limited to 350 mA at about 3.2 V by the control circuitry, maximum power
-dissipation is 1.12 W per LED, or 4.48 W for the entire module. In ambient air,
-the 0.5 inch heatsink will see a rise over ambient of about 30 degrees Celcius.
-So if room temperature is 30 C (86 F), the temperature and the juntion beween
-the module and the heatsink should be about 60 C. I failed to locate a maximum
-junction temperature for this module, but 60 C is not too high for most other
-LEDs out there. To ensure good thermal contact, the module was secured to the
-heat sink with machine screws and a bit of thermal paste.
-
-In operation, the lamp when tested in operation suggests the heat sink is
-actually performing a bit better than the data sheet numbers suggest.
-
-# Eye protection
-
-The problem with the IKEA lamp used is that it is open through the top. This is
-an advantage thermally because the lamp acts like a chimney, allowing cool air
-to enter through the opening in the bottom -- which was left open for
-ventilation purposes -- and warmer air to rise out of the top. The downside is that a
-person could easily look into the lamp from above. These high power modules can
-cause retinal damage, so this is a problem. The solution was to mount a few
-inches above the LED module a diffuser. The diffuesr spreads the light nicely
-while also blocking direct visual exposure of the module LEDs.
-
-# Mechanical mounting notes
-
-This was a quick project, so the mechanicals are of the basic prototype variety.
-The electronics are mounted on perfboard in a small project box, and a short
-section of 28 AWG cat 5e cable delivers current to the LED module. A DC wall
-wart is used for power, and the heat sink is mounted in the lamp with hot glue.
+++ /dev/null
-title: A Source of Randomness
-linktitle: rgb-random
-parent: rgb-code
-ctime: 2012-03-24
-
-# Randomness
-
-The lamp implements a 'party' mode, which randomizes the next color and the time
-for which that color will be displayed before the next color change. The code
-uses an efficient parallel bit implementation of a Galois linear shift register.
-However, unless a random seed value can be acquired, the sequence will be the
-same each and every time.
-
-# Truly random
-
-The PIC16 has no PRNG (pseudo-random number generator). An approach to
-simulating a PRNG is to use the ADC to capture from an unused pin. The
-assumption is that noise present in the last least significant bit or so of the
-result can be summed to generate a pseudo-random number. No testing was done to
-attempt to quantify the quality of this methodology, but it certainly provides
-some amount of randomness and is adequate for the simple needs of this project.
+++ /dev/null
-title: RGB Lamp Tasks
-linktitle: rgb-task
-parent: rgb-code
-ctime: 2012-03-24
-
-# Tasks
-
-A task implements an application behavior in response to an event. Tasks are
-executed to completion without pre-emption. Task start requests are queued if
-another task is already executing. A task start request when that task is
-already queued to start is effectively a null operation. However, a task start
-request for a task that is not queued but currently running will queue the task
-for a subsequent execution. This very simple task design is more than
-sufficient for the needs of the lamp application.
-
-One key decision under such a task architecture is which task to run next if
-multiple tasks are queued. This code selects the task with the highest priority
-in such a case. Application code must be cognizant of this fact, as a
-perpetually queueing high priority task will prevent execution of a queued lower
-priority task. This behavior is similar to hardware interrupt dispatch in many
-processor architectures, so most developers should already be familiar with its
-pitfalls.
-
-# Task implementation
-
-Tasks are implemented in the task.c, task.h and task_defs.h files,
-as found in the [repository](http://oss/gitweb?p=rgblamp.git;a=summary).
-
-Task identifiers are defind in the task_defs.h file. Each task id is an
-enumeration, with the highest priority task given the value of zero, and
-successively lower priority tasks having incrementally larger numbers. Since
-the task queue is implemented as bits in a variable, the width of the task_id_t
-structure defines the maximum number of supported tasks.
-
-Before using, initialize the task subsystem:
-
- task_init();
-
-To queue a task for execution, post it. Tasks can be posted from within an ISR
-or from without. A task can post itself as well.
-
- task_post(TASK_ID);
-
-Task dispatch is constructed from the task_get() function, which atomically gets
-and clears the next task (bit). The user application code then constructs a
-switch statement or similar structure to call a function associated with each
-task id. The lamp code implements this behavior in the user_tasks() function
-in main.c. Check it out in the
-[repository](http://oss/gitweb?p=rgblamp.git;a=summary). A short version:
-
- void user_tasks(unsigned char block)
- {
- task_id_t tid;
-
- while ((tid = task_get(block)) >= 0) {
- switch (tid) {
- case TASK_BTN_PB:
- pb_task();
- break;
- ...
- }
- }
- }
-
+++ /dev/null
-title: RGB Lamp Timers
-linktitle: rgb-timer
-parent: rgb-code
-ctime: 2012-03-24
-
-# Timers
-
-Most microcontroller applications must respond to temporal events. The timers
-subsystem allows an application to have multiple timers running concurrently,
-each with a different duration before expiration. This implementation is very
-simple, in that timers can be started, stoped, and polled for expiration
-(fired). By integrating with tasks, a timer expiration can post an event.
-
-Timers are identified by a timer id. A timer started will fire at the end of
-the time period specified in the timer start call. A timer may also be started
-via startPeriodic(), which will fire the timer periodically according to the
-timer period specified in the call.
-
-# Implementation
-
-The timer subsystem is implemented through the use of the PIC16 TMR0. It is
-configured to trigger a hardware interrupt every 32.768 milliseconds. Within
-each interrupt, the status of the currently active timers is updated. This is a
-very simplistic approach. A better solution would be to use a timer compare
-feature, which would dramatically reduce the number of ISR events and therefore
-servicing overhead for the timer subsystem.
-
-Periodically the application can poll for timer fired by the tmr_fired() call.
-A good time to do this is in the ISR, and timers that fire can post tasks. The
-comments in tmr.h gives a complete example. Check the
-[repository](http://oss/gitweb?p=rgblamp.git;a=summary).
-
-# Timer and low power modes
-
-Unfortunately, the PIC16 has limitations when it comes to using timers in sleep.
-While it is true that Timer 1 can run when the PIC16 is in sleep using an
-external 32 kHz crystal, no timer compare feature is possible in sleep.
-Therefore, the only timer inerrupt that can wake the micro is the overflow.
-This overflow happens every 2 seconds. In fact, the lamp code uses this
-behavior to handle the long term timer events via the tmr32 module.
-Specifically, this is used for the auto-off and auto-on events.
-
-It is possible to get different overflow periods by programmatically setting the
-Timer 1 register. Since this is a 16 bit value implemented in 2 8-bit
-registers, there are race conditions that challenge this use. But the ability
-to support variable timer periods in sleep is possible.
-
-When it comes to managing temporal events and deep sleep, the MSP430, the EFM32,
-and the STM32L are superior processors.
-
+++ /dev/null
-title: Read Only Root
-linktitle: ro-root
-parent: Home
-ctime: 2012-08-02
-
-For GNU/Linux desktop installations, I prefer to have the root filesystem,
-which mounts to /, be mostly read-only. This means that /home, /var and /tmp
-need to be mounted elsewhere. The benefits of this approach are several, but
-two in particular stand out for desktop use cases.
-
- * It is much easier to do a clean install the OS. User data in /home, and
- in some cases application data in /var, need not be backed up and restored
- in the process. Of course recent backups should still be available.
- * A root fs that is rarely written to is a good candidate for SSD (solid state
- disk) storage. This allows one the performance benefit of SSD while
- mitigating a critical deficiency. Current SSD technology is not nearly
- as reliable as mechanical disk in read/write environments, so reducing
- writes to SSD is a productive strategy.
-
-Placing /home on a separate partition is easy, and GNU/Linux desktop installers
-have supported this for some time. And thanks to the recent introduction of
-/run (see [here](http://lwn.net/Articles/436012/) to learn more), migrating
-/var to a separate filesystem is now pretty easy for desktop installs.
-
-Of course, with multiple partitions, there is the issue of what to do if one of
-them fills up. A common solution is to use LVM. Volumes are given minimal
-practical sizes, and then incrementally grown as required. LVM works fine on
-the desktop, but requires a bit more knowledge and effort to administer.
-
-A simpler solution is to use bind mounts. By bind mounting /var from /home/var
-and /tmp from /home/tmp, all user, variable and temporary data are on a single
-partition. The root partition will be nearly static in content and size. I
-currently use a 25 GB root partition on desktop installs, and that filesystem is
-generally only about 25% full, even with a large number of development tools
-installed. A swap partition is present of course, and the rest of the available
-hard drive storage space is assigned to the home partition, which now holds the
-contents of /var and /tmp. Essentially, /home, /var and /tmp share a common
-large pool of storage, so there is less need for a volume manager. I am finding
-this configuration to be quite optimal for developer desktops at my company.
-
-# Using bind mounts in a new installation
-
-These notes assume Xubuntu 12.04 desktop i386 installation, but a similar
-process should work for other distributions and versions.
-
- * Boot from the xubuntu 12.04 desktop CD
- * Run the installation
- * Use a custom configuration when asked
- * At least three partitions are required: root, swap and home
- * Proceed with installation until the installer asks to reboot to continue
-
-Before rebooting, access a shell and type the following commands
-
- cd target # where the new root filesystem is currently mounted
- cp -a var home/var # copy var to its new storage location
- mv var var.old # can remove later
- mkdir var # Need some dirs and symlinks during boot for some OSes
- ln -s /run var/run
- ln -s /run/lock var/lock
- cp -a tmp home/tmp # copy tmp to its new storage location
- mv tmp tmp.old
- mkdir tmp
- vi etc/fstab # add the following 2 bind mounts to end of /etc/fstab
- /home/var /var bind defaults,bind,noatime,mode=0755 0 0
- /home/tmp /tmp bind defaults,bind,noatime,mode=1777 0 0
- sync
-
-Now allow the installer to reboot. The system should boot up using the bind
-mounts for /var and /tmp, so their contents will actually be stored in the home
-partition at locations /home/var and /home/tmp, respectively. Once the system
-appears to be working OK, you may remove the /var.old and /tmp.old directories.
-
-# Upgrading to use bind mounts
-
-First, boot from a recovery or live CD, then run commands like the following
-commands.
-
- mkdir /mnt
- mount /dev/sda1 /mnt # replace /dev/sda1 with dev for your root
- mount /dev/sda2 /mnt/home # replace /dev/sda2 with dev for your home
- cd /mnt
- cp -a var home/var # copy /var to its new storage location
- mv var var.old # can remove later
- mkdir var # Need some dirs and symlinks during boot for some OSes
- ln -s /run var/run
- ln -s /run/lock var/lock
- cp -a tmp home/tmp # copyt /tmp to its new storage location
- mv tmp tmp.old # can remove later
- mkdir tmp
- vi etc/fstab # add the following 2 bind mounts to end of /etc/fstab
- /home/var /var bind defaults,bind,noatime,mode=0755 0 0
- /home/tmp /tmp bind defaults,bind,noatime,mode=1777 0 0
- sync
-
-Now remove the CD and reboot. You should be using bind mounts. Once the system
-appears to be working OK, you may remove the /var.old and /tmp.old directories.
<div class="articleListing">
<%
- recently = get_recently()
+ recently = get_recently(max_items = 20)
%>
% if len(recently) > 1:
<h2>Recent Changes</h2>
<div id="footerInner" class="clearfix">
<p class="copyright">
-Copyright (C) 2001-2011 Titanium Mirror, Inc. All Rights Reserved</p>
+Copyright (C) 2001-2012 Titanium Mirror, Inc. All Rights Reserved</p>
<p>This page last updated ${format_date(file.mtime)}</p>
</div> <!-- close footerRight -->
+++ /dev/null
-title: TinyOS
-linktitle: tinyos
-parent: Home
-ctime: 2009-12-07
-
-Repositories: [tinyos](/gitweb/?p=tinyos-2.x.git;a=summary),
-[deputy-tinyos](/gitweb/?p=deputy-tinyos.git;a=summary),
-[nesc](/gitweb/?p=nesc.git;a=summary),
-[[aptrepo]].
-
-# TMI TinyOS
-
-TMI maintains a [TinyOS](http://www.tinyos.net) branch containing certain
-features not available in the official tree. We use this this code for our
-internal and customer development efforts. TMI enhancements include:
-
-* Support for newer [[msp430]] chipsets, such as the MSP430F2618.
-
-* An implementation of the USCI peripheral, supporting UART, SPI and I2C
- communications. Both SPI slave and master modes are supported, with the
- driver knowing what to do in slave mode if the master unasserts the slave chip
- select line.
-
-* Enhanced clock framework supporting parts with the basic_clock+ peripheral
- and simplifying changing msp430 clock speeds on a per platform or per
- application basis.
-
-* Support for a number of other chips, including the Silicon Labs
- [[cp210x]] USB to UART adapters, the Texas Instruments BQ2403x Li Ion/Polymer
- charge controllers, and the VTI SCP1000-D01 barometric pressure sensor.
-
-* A modularized tos-bsl program that simplifies adding other msp430 boards using
- different mechanisms to access BSL programming features. Included is support
- for boards using the cp2103 and its GPIO pins to effect BSL via USB.
-
-* Support for TMI reference platform design, [[tmicore]].
-
-# About the TMI repository
-
-The TMI TinyOS repository is based upon code from the [official
-repo](http://tinyos-main.googlecode.com/svn/). The TMI repository contains
-various branches and tags representing current and past work. Most notably, the
-tags beginning with `patchset/` are clean patches against a given official
-upstream release.
-
-* Current patchset tag: `patchset/2.1.1-4.5`
-* TMI enhancements are based upon the upstream release tag: `tinyos/2.1.1`
-* The commits between the two above tags represent the series of patches in the
- [latest patchset](/gitweb/?p=tinyos-2.x.git;a=shortlog;h=refs/tags/patchset/2.1.1-4.5).
-
-The TMI TinyOS code requires a GCC 4.4+ based [[msp430]] toolchain.
-
-# Using TMI TinyOS
-
-A complete TinyOS development environment including toolchain is available for
-installation from our [[APT repository|aptrepo]]. Since we only use Ubuntu
-workstations for our internal development, we cannot cost justify maintaining
-packages for Windows or other Linux distributions at this time.
linktitle: tinyospkgs
parent: aptrepo
ctime: 2009-12-10
+mtime: 2012-07-09
Repositories: [tinyos](/gitweb/?p=tinyos-2.x.git;a=summary),
[deputy-tinyos](/gitweb/?p=deputy-tinyos.git;a=summary),
+++ /dev/null
-title: tmicore
-parent: Home
-ctime: 2009-12-02
-
-Repositories: SOON
-
-TMI has developed an [[msp430]] target board for low power data acquisition.
-Its design is not complete yet, but it is (SOON) available under an open
-source license. The design was created using [Eagle](http://www.cadsoft.de).
-It provides a breakout of all uC pins, incorporates a Lithium Ion/Poly charger,
-and a USB interface for communications and programming.
-
-The actual design files are for the tmirws board, which is a superset of the
-tmicore design. One can trivially derive the tmicore design by simply cutting
-the board layout at the inner rectangle. The tmirws design is the heart of an
-off-grid solar powered remote weather station that reports its observations to
-an internet server via the cellular network.
-
-TMI enhanced [[tinyos]] contains platform support for both the tmicore and
-tmirws variants of this design.
+++ /dev/null
-title: Virtual Windows 7
-linktitle: virtual-win7
-parent: Home
-ctime: 2011-07-28
-
-# Introduction
-
-This page documents the process of converting a dual-boot Linux/Windows
-installation into a Linux installation running the Windows partition under a
-KVM virtual machine. This work was first performed under Ubuntu 10.10 and
-11.04 versions.
-
-# Why virtualize Windows 7?
-
-During my development activities, customer needs infrequently require use of
-software only available under Windows. But booting between OSes is an
-incredible waste of time and drain on productivity. My work notebook, a Lenovo
-X201, came pre-installed with an OEM version Windows 7 Home Premium. The
-obvious solution? Virtualize Windows under Linux.
-
-# Microsoft licensing issues?
-
-[[!pquote text="The OEM Windows EULA allows for virtualization"]]
-
-I downloaded the EULA for Windows 7 from microsoft.com as applicable for
-pre-installed OEM versions of Windows 7 Home Premium. For this OS configuration,
-the license specifically allows execution of the pre-installed OEM OS when
-virtualized on the same hardware. The actual text is found in Section 3.d:
-
-> Use with Virtualization Technologies. Instead of using the software directly
-on the licensed computer, you may install and use the software within only one
-virtual (or otherwise emulated) hardware system on the licensed computer. When
-used in a virtualized environment, content protected by digital rights
-management technology, BitLocker or any full volume disk drive encryption
-technology may not be as secure as protected content not in a virtualized
-environment. You should comply with all domestic and international laws that
-apply to such protected content.
-
-# Virtualization requirements
-
-For Windows virtualization to be effective in my development use cases, the
-following requirements and constraints must be met. Additionally, I want the
-virtualization solution to support running additional virtual machines as well.
-
-* Run 32-bit x86 Windows 7 from 32-bit x86 Ubuntu Linux 10.10 and newer.
-* Run various flavors of Linux or other Intel x86 based operating environments.
-* No unnecessary dependences to software or hardware that will limit the
-ability of the virtualized OS from functioning properly in the future.
-* Ability to run with native disk, not disk-as-file, for improved IO
-performance.
-* Supports use of VT-x and VT-d, again for performance.
-* Will be sufficiently performant on the target hardware when virtualized. The
-X201 has an i5-M560 CPU which offers 4 cores at 2.66 GHz each, and 8 GB of RAM.
-* Simple management of VMs, including configuration, start and stop.
-* VMs must behave sanely in the presence of host OS power saving functionality,
-like suspend.
-* There is no requirement to continue to run Win7 natively.
-* High end graphics are not required: no need for 3D, Aero effects, video
-playback, etc.
-* And finally, a reliable mechanism return to the prior physical configuration
-if the VM experiment fails to work as hoped.
-
-# Selecting a virtualization framework
-
-There are a few virtualization options suitable for use on a development system,
-including VMware, Xen, VirtualBox, and KVM. All can do the job, but KVM was
-chosen for a variety of reasons:
-
-* KVM has the features needed, and is available through the standard
-Ubuntu repositories.
-* KVM management via libvirt is more than adequate.
-* KVM can use an SDL local window for rendering the virtualized OS, for quite
-good display performance.
-* The enterprise features of Xen are overkill for this application.
-* VMWare is not open source, so there is some concern about support for this
-particular hardware in the far future (I tend to keep hardware for a very long
-time).
-* VirtualBox can not access USB hardware unless the purchased version is used.
-
-The virtual machine manager, using libvirt, is a pretty nice environment. This
-management tool already supports a few different VM strategies, called
-*backends*, and they are likely to improve moving forward. Therefore, gaining
-knowledge about VMM, libvirt, and KVM could in the near future represent
-an intellectual asset deployable against future customer needs.
-
-# Disk organization, pre-virtualization
-
-Prior to any changes, the 320 GB notebook disk drive was organized as follows:
-
- /dev/sda1, 1.17 GiB, Label=SYSTEM_DRV
- /dev/sda2, 78.17 GiB, Label=WindowsOS_7
- /dev/sda3, 19.68 GiB, Label=Lenovo_Recovery
- /dev/sda4, an extended partition container
- /dev/sda5, 15.26 GiB, swap partition
- /dev/sda6, 23.84 GiB, / partition
- /dev/sda7, 159.96 GiB, /home partition
-
-* The SYSTEM_DRV apparently supports the Lenovo ThinkVantage functionality
-which includes some backup and restore capability.
-* The WindowsOS_7 partition is the one to virtualize, containing the licensed
-OEM version of Windows 7 Home Premium that came with this notebook.
-* The system boots using Grub2, which initially included an entry to boot the
-Windows_7 partition.
-
-# The solution
-
-Unfortunately, the solution is not so simple as to point the VM to the /dev/sda2
-partition. First, the virtual hardware expects to see a hard drive, complete
-with partition table. Second, suitable drivers for the virtual hardware must be
-installed into the windows installation. I took several steps to convert
-/dev/sda2 in place to look like a hard drive (kpartx, etc) but the best I could
-accomplish was Windows 7 hanging during boot. Since my expertise with Windows
-internals is limited, and so is the information available online, I elected to
-do a clean re-install Windows from the virtual environment.
-
-## Create backups
-
-### R&R image
-
-Levnovo offers a recovery capability accessible by booting the Lenovo_Recovery
-partition. I used this to create a recovery image for the WindowsOS_7
-partition.
-
-* Create a windows repair disc from the Win7 OS
-* Create an R&R recovery boot disc
-* Back up the current Win7 image via R&R to the Lenovo_Recovery partition. This
-required removing all other prior backups because of size constaints in that
-partition.
-* Back up the current Win7 image to a set of DVD optical discs. It took 3: a
-boot disc and two data discs.
-
-### Partition level backups
-
-Since the space was available in the Linux partition, I opted to create parition
-level backups as well, which would be 'easier' to restore, at least for me.
-
- # Backup the first MiB of /dev/sda to capture MBR and any bootloader stuff
- dd if=/dev/sda of=mbr.save bs=1M count=1
- # Use ntfsclone to make a space-efficient copy of the windows partition
- ntfsclone --save-image -o - /dev/sda2 | gzip -c > sda2.img.gz
-
-## Prepare /dev/sda2 for virtualization
-
-First, /dev/sda2 must look like a DOS style disk, complete with disk level
-partition information. This can be accomplished using this fdisk command:
-
- fdisk -c -u /dev/sda2
-
-Drive fdisk to create a single windows partition spanning the entirety of the
-'disk' (actually the physical partition /dev/sda2). Now /dev/sda2 will look
-like a valid disk image usable by a VM to re-install Windows 7.
-
-## Install the virtualization tools in Linux
-
- sudo apt-get install virt-manager virt-viewer python-vm-builder \
- kvm-pxe ubuntu-vm-builder
-
-I tested the VM tools by creating an Ubuntu 11.04 install. I ran the Virtual
-Machine Manager using an Ubuntu 11.04 install .iso image as its CD-ROM. The
-installation was successful and the resulting virtual machine worked without
-fail.
-
-## Re-install Windows 7
-
-Next windows was re-installed. A Windows 7 Home Premium 32-bit OEM .iso was
-used to do a clean install of Win7. See the virtioinstall.sh script for more
-information. I used the Win7 iso, and virtual floppy and CD-ROM images from
-RedHat containing signed virtio drivers for disk and network devices. The VM was
-started using the virtio disk driver, booting into the Win7 iso. Then the
-virtual floppy was accessed during the Win7 install process to load in the
-virtio drivers so the Win7 install program could see the disc, which was of
-course the disk image on the host /dev/sda partition. I formatted the 'drive'
-(which is really the /dev/sda2 partition on the physical drive), then proceeded
-to install Win7 onto it. The installation process, from first boot of the Win7
-iso, to first user login to Win7, took just under 45 minutes.
-
-At this point, the VM was stopped so its configuration could be altered it use
-the virtio network driver. The VM was then restarted with the virtio iso from
-RedHat connected as the virtual CD-ROM disc. Once Win7 was running, in device
-manager the drivers for the broken network device were updated from the .iso to
-get the network running. The virtio network interface seems very efficient. The
-VM configuration was finally modified to provide for 2 CPU cores and 2 GB of
-RAM.
-
-## Re-activate Windows 7
-
-At this time, Win7 had to be re-activated. The online technique failed, so the
-phone call technique was required. It was a bit painful, but the end result was
-a properly activated installation.
-
-## Install other Windows 7 tools
-
-Since I installed from scratch, I had to reinstall the few tools I use under
-Windows. Since these tools were few in number, this process was pretty
-painless. This strategy would be much more painful if there were lots of tools
-and/or custom configuration or data required to be recovered.
-
-## Improving diplay performance
-
-The default display mechanism when interacting with the Windows VM display is
-VNC. This is not very performant. Since the Windows VM is only to be accessed
-from the local hardware, I instead configured the VM to use SDL for rendering
-the VM display in a window. Interestingly, this change also allowed sound from
-the Win7 VM to propagate to the sound hardware. The SDL configuration is fast
-enough to watch Netflix from the VM.
-
- Stop the win7 VM
- Reconfigure the VM:
- Remove VNC graphics entry for the VM and add the local SDL one.
- Change the sound driver to ac97
- Edit /etc/libvirt/qemu.conf. Add:
- user = "smckown"
- group = "smckown"
- sudo service libvirtd-bin restart
- Restart the virtual machine
-
-### Why not SPICE?
-
-The SDL method creates a new local window that hosts the VM display. It cannot
-be embedded into the virtual manager VM window. It looks like the better
-solution is going to be to use the SPICE facility. Special drivers in the VM
-work with special client features to implement a much improved connection. SPICE
-provides better display performance than VNC, can do stereo sound, and also
-provides for USB redirection. As of 7/13/12, Ubuntu 12.04 does not have the
-right stuff to do spice through virt-manager. There is a PPA that will allow it.
-The nice thing about SPICE is it is network-able and can be embedded. Since
-network access to the VM is not necessary, the SDL window method seems optimal.
-
-## Anti Virus considerations
-
-It should be noted that the VM, as the native install before it, is running
-Microsoft Security Essentials for Anti-Virus. There appears a noticeable
-performance hit for using AV within the VM, in comparison to running it
-natively. Unfortunately, the protection offered is probably worth the
-performance penalty.
-
-# Conclusion
-
-I am quite happy with the results of this process. Win7 boots noticeably faster
-from the VM than it did on native hardware. Disk CPU are perceptibly sluggish
-within the VM with respect to native performance, but it is tolerable. Network
-performance seems on par with native. For the tasks in which I will use
-Windows, the virtual machine performance is more than adequate.
-
-Of course the big win is that Win7 can be running simultaneously with Ubuntu.
-This solves a host of workflow problems and removes the terrible inefficiencies
-caused by having to boot between the two OSes natively. For one, I was able to
-continue working with apps in the host Ubuntu OS while the Win7 VM chugged away
-literally for hours downloading and rebooting ad nauseum as it updated itself
-with the latest Win7 SP1 and subsequent patches.
-
-My overall concern with this strategy is that a change in Microsoft policy could
-complicate my life. Although this use of my windows license is perfectly
-legitimate according to my reading of the EULA, I depend upon Windows Product
-Activation to honor this legitimacy. Here is to hoping that Microsoft will take
-care to ensure that their WPA policies retain convenient use of Windows for all
-legitimate uses.
-
----
-
-# Updates
-
-### 2012-08-13
-After using this configuration for over a year, I have found it to be quite
-reliable. The upgrade to 12.04 triggered Windows Product Activation, and
-another phone call to the automated WPA phone number was required. The
-activation was successful.
-
----
-
-# Links
-
-The following links, in no particular order, were invaluable in completing this project. Thanks to all those who published their prior experience for others to use!
-
-* <http://support.microsoft.com/kb/927392>
-* <http://answers.microsoft.com/en-us/windows/forum/windows_7-system/hp-mini-210-windows-7-recovery-0xc000000f-bcd/6c79d900-79dc-4f54-bcf7-22edf6f44dd4>
-* <http://windows.microsoft.com/en-US/windows7/Startup-Repair-frequently-asked-questions>
-* <http://www.sevenforums.com/tutorials/20864-mbr-restore-windows-7-master-boot-record.html>
-* <http://www.sevenforums.com/tutorials/104341-bootmgr-missing-fix.html>
-* <http://www.sevenforums.com/tutorials/163216-bootrec-exe-tool-how-use-windows-recovery-environment.html>
-* <http://brandonkonkle.com/blog/2009/apr/27/lvm-based-virtualization-kvm-and-jaunty/>
-* <http://techpp.com/2009/11/11/download-windows-7-iso-official-direct-download-links/>
-* <http://bderzhavets.wordpress.com/2011/01/08/set-up-rh-virtio-scsi-driver-on-windows-xp-kvm-at-kvm-qemu-instance-on-f14/>
-* <http://techpp.com/2009/11/11/download-windows-7-iso-official-direct-download-links/>
-* <http://cloud.ubuntu.com/2011/03/fast-win7-kvm-virtiodisk-net-install/>
-* <http://www.sevenforums.com/tutorials/1649-clean-install-windows-7-a.html>
-* <http://rghost.net/3412907>
-* <http://www.sevenforums.com/installation-setup/156599-help-windows-7-clean-install.html>
-* <http://www.sevenforums.com/installation-setup/151566-reinstalling-windows-7-a.html#post1300819>
+++ /dev/null
-title: Webber
-linktitle: webber
-parent: Home
-ctime: 2009-12-15
-
-Repositories: [webber](/gitweb/?p=webber.git;a=summary).
-
-[Webber](http://gitorious.org/webber) is a great static website generator
-written in Python by
-[Holger Schurig](http://www.holgerschurig.de/projects/webber/). We maintain
-a [local copy](/gitweb/?p=webber.git;a=summary) of his repository
-with a few changes. This website is built using webber; see [[oss-web]].
+++ /dev/null
-title: WWVB
-linktitle: wwvb
-parent: Home
-ctime: 2011-10-28
-
-Repositories: SOON
-
-TMI uses a WWVB receiver in its RWS product.
-[WWVB](http://www.nist.gov/pml/div688/grp40/wwvb.cfm) is a radio station
-operated out of Ft. Collins, CO by NIST, which provides a 60Hz carrier wave on
-which is encoded the current time as synchronized with a pair of on-site atomic
-oscillators. The low frequency of the WWVB broadcast means it is available
-through most of North America. Perhaps you have heard of *Atomic Clock* radios.
-These simply incorporate a WWVB receiver which is then used to automatically
-set, and periodically compensate, the radio's internal real time clock
-circuitry.
-
-TMI's RWS (Remote Weather Station) project collects weather data completely
-autonomously, time-stamping recorded data using its onboard RTC. The WWVB
-broadcast is used to both initially set the RTC, and to periodically compensate
-for its drift over time.
-
-TMI chose to incorporate the C-MAX
-[CMMR-6](http://www.c-max-time.com/products/showProduct.php?id=31) WWVB receiver
-into its RWS design. This simple board requires very little power, and the fact
-that the WWVB receiver need only be consulted occasionally to compensate for RTC
-drift means its time averaged power consumption is very low. The CMMR-6 offers
-a simple output, TCO, treated as a digital signal. TCO is logic high when the
-WWVB carrier is transmitting at full power, and is logic low when the WWVB
-carrier is transmitting at reduced power. Each second uses a variable period in
-which the carrier is at reduced power to encode one of three values: a 0 bit, a
-1 bit, and a frame marker. 60 of these tri-state bits form a time frame
-containing the time, to the minute, during the current frame transmission. More
-about the WWVB signal format is available
-[here](http://tf.nist.gov/stations/wwvbtimecode.htm).
-
-While the [WWVB time code format](http://tf.nist.gov/stations/wwvbtimecode.htm)
-is easy to parse, this is not so true in the presense of noise. TMI has chosen
-to address noise by implementing a digital 4th order Butterworth filter, using a
-32Hz sample rate and a 3 Hz cutoff frequency. The filter inputs are either 0.0
-and 1.0, sampled from the CMMR-6 TCO pin, and the filter output is some fraction
-inclusive of the range 0.0 through 1.0. The microprocessor code implements
-hysteresis to generate a digital output, where outputs >= 0.7 are treated as
-logic 1, outputs <= 0.3 are logic zero, and any value in between these
-thresholds leave the logic output unchanged. This filter, implemented within
-the uC, requires up to 5% of the CPU while WWVB is in operation, but does a
-stellar job at cleaning up the WWVB signal. To evaluate filters and generate
-their implementation logic, we used the simple and easy to use
-[Fiview](http://www.uazu.net/fiview) design tool.
-
-Consider the following oscilliscope capture of live WWVB reception. TCO is the
-output from the CMMR, and FOUT is the output from the digital filter. Note that
-the filter delays the signal by approximately 200 ms.
-
-
-
-As mentioned earlier, the duration of the low period indicates the bit type.
-200 ms for bit 0, 500 ms for bit 1, and 800 ms for a frame mark. As can be seen
-in the TCO trace, there is a significant amount of relatively high frequency
-noise interfering with the TCO signal. A discrete algorithm would likely be
-unreliable in decoding TCO. However, the filtered output, FOUT, successfully
-removed all the noise with minimal signal distortion. A discrete algorithm can
-parse FOUT with a high degree of reliability. In this case, the trace as
-decoded -- 0 0 1 0 M 0 0 1 1 -- was the correct sequence for the captured frame.
-
-The decode algorithm determines a bit value for the current low period duration
-that is best matched by the expected durations. But the low pass filter cannot
-remove all sources of error, so a frame may be received with bits in error.
-Frames are validated according to the [WWVB time code
-format](http://tf.nist.gov/stations/wwvbtimecode.htm), and two frames must have
-matching data to consider a valid time acquisition. Of course in this sense,
-matching frames do not have the exact same values, but the second frame's
-contents differ from the first frame's only by the number of minutes separating
-their acquisition.
-
-There are still a few enhancements possible in this design. First, the TCO
-signal could be captured via an ADC, to bring additional information on each
-bit into the filter. This, however, might require some software gain control
-depending upon how good the CMMR-6 AGC circuitry is, and may not be worth the
-effort.
-
-The second enhancement is one that will be implemented. Instead of matching two
-complete frames to indicate valid aquisition, instead match complete frame
-sections. Three incoming frames all with errors in different sections would
-allow this latter approach to construct a known good frame, where the current
-algorithm could not. In very noisy cases, this enhancement should perform
-better.
projects / oss-web.git / commitdiff
