npatwari's blog

YouTube Playlist for RSS-based DFL

EvAAL Competition at Living LabI'm impressed with the quantity and quality of videos created about people's research in device-free localization and radio tomographic imaging. I think it is time to group them together in some way so that someone interested in this area of research can find them all and watch them. I created a Youtube playlist called "RSS-based Device-Free Localization". When you run out of things to watch on Hulu and Netflix, take a view!

Also -- if you've put up a public video on the topic and want me to include it, post a note on the playlist.

Capturing camera photos at regular intervals

In my research, I sometimes need to record video from an experiment. But in reality, I don't need multiple frames per second video, I just need a photo of the environment at a regular interval, like once per second. These photos allow me to go back in post-processing to figure out exactly where people were in the environment, for example. Here are the problems with using, for example, a Flip video recorder to record video:

  • Low quality: I need images that perhaps can go into publications. Even a HD video frame is not really a high quality image for a print publication.
  • Un-synchronized: I am typically collecting data simultaneously on my laptop. The video time stamps are not synchronized to my laptop's clock, so then the problem is that in post-processing I have to figure out what time each frame was taken in terms of my laptop's clock.

Another problem with my web cam is that it hard to point it in the right direction to capture a picture of the environment. Instead, I use a usb-connected camera with a stand that I can point in whatever direction I want.

The solution I use to capture images at a regular interval is to use the "streamer" program. It will allow me to collect images at a set rate (with the -r option). It allows me to change the video camera from the web cam, which appears as /dev/video0 on ubuntu, to the usb camera, which appears as /dev/video1. Also, it automatically increments the file name, and will stop after a known period of time. For example, here is my command to collect a picture once per second for 10 minutes:

streamer -c /dev/video1 -t 600 -r 1 -f jpeg -o temp000.jpeg

The files will have a unique number as the last three digits of the file name, and the "date modified" field will show my laptop's system time when it was created.

Coming soon to a Korean-language broadcast near you

Joey Wilson KBS Interview
I just dug out this photo from my phone: This is Joey Wilson (Xandem Tech, a former SPAN lab member) and Chris O from KBS TV, a Korean broadcasting station, and a cameraman from the station. Joey was being interviewed for a Korean documentary on radio waves, a documentary sponsored by the Korean institute of Radio (a government agency). This is a photo from October 26, 2010.

Making noise for fun and sleeping

I'm a new dad these days and, I guess it goes without saying, sleep deprived. I have a wonderful baby daughter who is otherwise perfect (in my opinion) but who is not fond of sleeping. Which may make her great at all-nighters later in life but is something I'm not too fond of today.

One thing that has helped is having white noise in the background to cover up all of the other sounds going on in the house. I think it also has become part of the routine, so she knows that the background noise means that its time for sleep. There are many ways to make noise, and we've tried running the bathroom fan, or putting the radio on a channel with no station. But my favorite continues to be our white noise CD. It doesn't waste energy (it certainly uses energy, but not as much as a fan) and doesn't waste water (running a faucet).

My noise CD is "handmade" which really means computer made; and not by my computer, but by my students in 5510 from Fall 2006. I assigned them each the task of making a three-minute white noise sound track. And when I say "white noise", I only mean that in the common use of the term.

Actually, white noise is non-white noise. Seriously. I don't mean in the ethnic sense, I mean in the frequency domain sense. Pure white noise, that is, constant power spectral density (PSD) as a function of frequency, is awful to hear. Try it if you don't believe me. If you analyze one of the "Pure white noise" CD tracks on a commercial CD, you'd see that it is emphasizes some frequencies (lower bands) more than others (higher bands).

So the assignment was to design the linear-time invariant (LTI) filter which would produce a good-sounding white noise track, and to analyse the PSD that the filter would produce, using techniques learned in class.

In any case, when I assigned it, I didn't know how valuable these tracks would be for me today. I've probably played on my CD player (on the one-song-repeat option) a white noise track on the order of 10,000 times. So I owe a debt of gratitude to my students.

Since I've been thinking about this CD quite a bit, I thought I'd post and share the link in case someone else would benefit from a white noise CD. The tracks are in MP3 format so they're ready for your standard CD burner software. Your results may vary, and some of these tracks sound quite a bit better (to my ear) then the others, so not all of them are equal -- you might want to select your favorites and only burn those.

Twenty-eight tips for research writing

Part of my job is to train students to write research papers. This involves me "teaching" technical writing, which I am definitely not trained to do. So I don't know what general training to give students to improve their writing. However, there are a lot of do's and don'ts that I like and don't like, respectively. These are (mostly) easy rules to follow that a student can (and should) check on their own. Please add comments to this post if you think of other helpful do's and don'ts.

  1. DO NOT start a sentence with a reference.
  2. DO NOT start a sentence with any number that is not spelled out. That is, don't say "34 sensors are placed in a circle..."; instead say "Thirty-four sensors are placed in a circle".
  3. DO tend to put citations at the end of a sentence rather than at the start. It's nicer form to say "Objects moving near a transmitter or receiver cause fading [6]", rather than "Reference [6] shows that objects moving near a transmitter or receiver cause fading". The latter makes it seem like you just want to check off of all of your references that you need to cite, rather than wanting to add the contributions of these other authors as the basis for the paper you're writing.
  4. DO build your research upon others' results. Hal Daumé (Utah SoC) reports being struck by a reviewer who commmented, "Other approaches don't have to be bad in order for your approach to be good." There's no need to put down other results, just show how your results or your research builds on the foundation of this past research.
  5. DO NOT excessively name the authors in papers when citing them. Say what they've contributed, then cite the paper.
  6. DO specify the contributions of the paper in at least one or two sentences when citing it. DO NOT cite lots of papers at once, unless the topic is only marginally related to the topic of your writing.
  7. DO write out in words any whole numbers below about fifteen when counting the number of something in a paper. I'm not sure exactly where the line is; but instead of, "There are 4 filters in Figure 2", say "There are four filters in Figure 2".
  8. DO put some concrete numerical results from your research in the abstract, for example, "We demonstrate a 35% improvement compared to the state-of-the-art method".
  9. DO NOT say "complex" when you really mean "complicated". The word "complex" should be used only when describing numbers which have real and imaginary components.
  10. DO NOT say "Rx" when you mean "receiver". The abbreviation "Rx" is for "prescription", which is probably not what you mean. The abbreviation "RX" can be used for receiver.
  11. DO NOT say "being done" when you mean "performed".
  12. DO NOT say "utilize" when you mean "use". In general, use simple language when it exists.
  13. DO NOT say "I". Not in technical paper. Even if you are writing a paper as a sole author, use "we". Al Hero, my former advisor, told me that it is the royal "we".
  14. DO say "we" to avoid excessive passive sentences, when talking about what we do in this paper. I imagine technical writing classes tell you not to, but in my experience, it often works well, and helps people read your writing.
  15. DO use acronyms when they are common. Or perhaps you are allowed to create one or two in your paper. Just be sure to spell out any acronym before its first use. Also, if you spell out the acronym in the abstract, you will have to do it again in the introduction.
  16. DO NOT excessively use acronyms. Don't use an acronym if you only use that acronym once, because then you have to spell it out anyway (and thus doesn't save you any space). If you've first defined an acronym in the Discussion or Conclusion section, it's probably too late to introduce that acronym.
  17. DO start each paragraph with a topic sentence that says what the paragraph is going to say. The following sentences in the paragraph support that topic sentence. Anything that doesn't support that topic sentence doesn't belong in the paragraph. If you find some odd sentence that you want to say, but it doesn't fit in that paragraph, put it in some other paragraph, make a new paragraph, or delete it (if it is unrelated to any topic in your paper, then you don't need it).
  18. DO finish each paragraph with a concluding sentence, which either ties the supporting sentences together, or provides a lead-in to the next paragraph. Or both.
  19. DO NOT start a section with a "The function blah is given by" followed by an equation. Each section requires a reason to exist, and that reason must be presented first. No equation's importance is self-evident.
  20. DO NOT use the phrase, "It means ...". You might instead write "Equivalently, ...", or "That is, ...".
  21. DO run a spell check! I know its a pain to "ignore" all of the math and LaTeX notation that the spell check catches. But you will find errors.
  22. DO NOT present data without discussion! This is a big one. Your job is not just to do the analysis and produce a beautiful figure or table. Your job is to tell the reader what it means. Sure, they could figure it out on their own. But most will not spend the time. Tell them what you learned from looking at the data and/or results.
  23. DO capitalize things that are named after a person, e.g., Fourier, and Gaussian. DO NOT capitalize a phrase just because it has an acronym associated with it. For example, if you're introducing radio tomogoraphic imaging (RTI), you can keep the words "radio", "tomographic", and "imaging" all lowercase, even though there is an acronym also being introduced. People will know where you got the letters "R", "T", and "I".
  24. DO NOT use non-technical language. That is, some words that are acceptable in spoken English are not acceptable in technical writing. For example, "totally", "good".
  25. DO learn about the crazy things we are supposed to do for the sake of the English language. I apologize for this language, there is no reason for some of these things, but here we are. Learn when to use "the" or "a" or nothing before a noun ("We present the maximum likelihood estimator..." vs. "We present an estimator..." vs. "We discuss estimation ..."). Do make sure that the subject and verb agree, when the subject is plural vs. singular, you need to match the conjugation of the verb to match. When capitalizing a title, learn which words are capitalized and which (short) words are not (for example, the word "of" is not in "University of Utah").
  26. DO look up tech words to see if your use is standard notation. Your spell check is probably useless; but Google isn't. For example, is "multi-path" hyphenated? Google gives "multipath" thirty times more results than "multi-path", so it gives me a good indication to kick the hyphen on this one.
  27. DO NOT use the word "clearly". In my opinion, this word is used by researchers who don't want to explain themselves. I've read it in papers, and quite often, have no idea why the conclusion is so clear.
  28. DO be as specific as possible, all things being equal. If an equivalent-length sentence could have been more specific, then use it instead.

Entropy of English

I just finished dusting off some Matlab code to estimate the entropy of English character sequences from a text source. In my opinion, this is a good tool to teach entropy rate. One might use the idea to calculate the entropy rate of another language, or other discrete-valued data source, like numerical data or twitter tweets. My code isn't particularly smart; my storage (and computation) is increasing as $L^N$ where $L$ is the number of characters considered and $N$ is the character sequence length. I'm sure someone more adept at programming can implement a more efficient version (perhaps a hash table?). However, the code does work, and computes the entropy for a sequence of characters (I've tested up to 4) from a given text file. I used Shakespeare's Romeo and Juliet, and found per-character entropies of 4.12, 3.73, 3.35, 2.99, for $L=$ 1, 2, 3, and 4, respectively. Info on how this is done is in my lecture 4 notes from today's Advanced Random Processes class; and the letter entropy Matlab code and Shakespeare text are also posted.

Automatic Bibliographies Aren't Automatic

Automatic download of bibliographic information is a great tool for keeping track of what you've downloaded, read and reviewed, and learned from published research. My favorites are Zotero and Google Scholar's Bibliography Manager, which (if you change your Scholar Preferences) shows you the BibTex for an article. However, at this stage, I have this warning: it is not yet automatic. That is, don't just take the BibTex entry as supplied. I notice lots of errors and typos, and they make a reference list look unprofessional. People can tell when they read a paper with bib file that was generated automatically and never reviewed.

For example, Google Scholar has chosen a seemingly random set of words in conference titles to be left lowercase, for example, leaving a conference proceedings titled "Proceedings of the 2nd international conference on Multi-hop, ad Hoc, and mesh Networks". Fix this so that all words are first letter capitalized except for a few common short words (e.g., "a", "on", "and", "of", "the"). Second, these managers don't seem to know that just because the paper appears in Citeseer, that its publisher isn't Citeseer. Or that an ACM conference was probably not located in New York, NY, even though the ACM is headquartered in NYC. Delete any publisher information from a conference proceedings paper, except for when the publisher is part of the name (e.g., "Proceedings of the IEEE International Conference on Blah Blah Blah"). Next, capitalization in titles should be consistent -- the first word in the title capitalized, but no other title words capitalized (except for proper nouns, and acronyms). You may need to put extra curly brackets around each proper noun or acronym to keep the capitalization like you have written in the title field. And you may need to fix the rest of the capitalization in the title field.

Maybe this is just my pet peeve, but I wouldn't bet on it. Look at and fix all BibTex entries as you add them, until the day comes when bibliographic managers have better data.

Syndicate content