Russell's Blog

New. Improved. Stays crunchy in milk.

Arduino in the lab, example 9,345,234

Posted by Russell on June 10, 2013 at 6:23 p.m.
Last week, my friend Emily at Pivot Bio was debugging some crazy protocol she's working on, and she was wondering if her incubators were maintaining correct temperature. So, we decided to find out.

For my own project, I happen to have a bunch of Arduino hardware. So, I threw together a quick solution based on Adafruit's thermistor tutorial (I have a bunch of thermistors sitting around). Here is Emily's setup, complete with masking tape junctions and protoboarded electronics :

A few hours later, and she's got a pretty good answer to one of science's oldest and most important questions : "Is this thing even working? WTF, man?" Here's the data collected at 1Hz with a one minute moving average :

I'm not sure what those wobbles around hour two are from. Hopefully someone just opened the door or something. Arduinos really are the Swiss Army Knife of the laboratory!

Trouble with SoftSerial on the Arduino Leonardo

Posted by Russell on May 25, 2012 at 12:05 p.m.
While I was wandering around at Maker Faire last weekend, I heard someone say, "Woah, is this the Leonardo?" And lo, there was a handful of Arduino Leonardo boards lined up on a shelf for sale. I instantly grabbed one, and bundled it home to play with it.

The Leonardo is Arduino's latest board, announced last September. It uses the Atmega32u4 chip, which has onboard USB. This has two important implications; first, the Leonardo costs less than the Uno, and second it will be able to operate in any USB mode. That means people can make Human Interface Devices (HID), like mice and keyboards and printers, with Arduino, and present themselves to the host using the standard USB interfaces for those devices. That means you can build things that don't need to talk via serial, and use the host's built-in drivers for mice and printers and whatnot. This is a big step forward for Open Hardware.

Anyway, I'm developing an little remote environmental data logger to use for part of my dissertation project, and I thought I'd see if I could use the Leonardo board in my design. I'm using the Arduino board to talk to an Atlas Scientific pH stamp, which communicates by serial. It works fine on the Uno with SoftwareSerial (formerly known as NewSoftSerial until it was beamed up into the Arduino Core mothership).

Unfortunately, it didn't go so well on the Leo. The board can send commands to the pH stamp, but doesn't receive anything. I swapped in an FTDI for the pH stamp, and confirmed that the Leonardo is indeed sending data, but it didn't seem to be able to receive any characters I sent back. I tried moving the rx line to each the digital pins, and had no luck. Here is my test program :

#include <SoftwareSerial.h>

#define rxPin 2
#define txPin 3

SoftwareSerial mySerial( rxPin, txPin );

byte i;
byte startup = 0;

void setup() {

  mySerial.begin( 38400  );
  Serial.begin(   9600   );
}

void loop() {
  
  if( startup == 0 ) {             // begin startup
    for( i = 1; i <= 2; i++ ) {
      delay( 1000 );
      mySerial.print( "l0\r" );    // turn the LED off
      delay( 1000 );
      mySerial.print( "l1\r" );    // turn the LED on
    }
    startup = 1;                   // don't re-enter
  }                                // end startup

  Serial.println( "taking reading..." );
  mySerial.print( "r\r" );
  delay(1000);
  
  Serial.println( mySerial.available() );
  
}
On the Uno, I see the number increasing as the read buffer fills up :
taking reading...
0
taking reading...
0
taking reading...
7
taking reading...
16
taking reading...
16
On the Leo, it seems that nothing ever gets added to the read buffer, no matter how any characters I send over from the FTDI or which pins I used for the rx line :
taking reading...
0
taking reading...
0
taking reading...
0
taking reading...
0
taking reading...
0
taking reading...
I really wanted to see if I was crazy here, but I'm one of the first people among the General Public to get their hands on a Leonardo board. So, I started talking with Ken Jordan on #arduino on Freenode (he goes by Xark) who has a similar board, the Atmega32u4 Breakout+. It's based on the same chip as the Leonardo, but it has different pinouts and a different bootloader. He flashed the Leonardo bootloder onto his board, and worked out the following pin mapping :
Arduino 1.0.1     Adafruit         ATMEL
digitalWrite pin  atmega32u4+ pin  AVR pin function(s)
----------------  ---------------  ------------------
D0                D2               PD2 (#INT2/RXD1)
D1                D3               PD3 (#INT3/TXD1)
D2                D1               PD1 (#INT1/SDA)
D3#               D0               PD0 (#INT0/OC0B)
D4/A6             D4               PD4 (ICP1/ADC8)
D5#               C6               PC6 (OC3A/#OC4A)
D6#/A7            D7               PD7 (T0/OC4D/ADC10)
D7                E6 (LED)         PE6 (INT6/AIN0)
D8/A8             B4               PB4 (PCINT4/ADC11)
D9#/A9            B5               PB5 (OC1A/PCINT5/#OC4B/ADC12)
D10#/A10          B6               PB6 (OC1B/PCINT6/OC4B/ADC13)
D11#              B7               PB7 (OC0A/OC1C/PCINT7/#RTS)
D12/A11           D6               PD6 (T1/#OC4D/ADC9)
D13#  (LED)       C7               PC7 (ICP3/CLK0/OC4A)
D14   (MISO)      B3               PB3 (PDO/MISO/PCINT3)
D15   (SCK)       B1               PB1 (SCLK/PCINT1)
D16   (MOSI)      B2               PB2 (PDI/MOSI/PCINT2)
D17   (RXLED)     B0               PB0 (SS/PCINT0)
D18/A0            F7               PF7 (ADC7/TDI)
D19/A1            F6               PF6 (ADC6/TDO)
D20/A2            F5               PF5 (ADC5/TMS)
D21/A3            F4               PF4 (ADC4/TCK)
D22/A4            F1               PF1 (ADC1)
D23/A5            F0               PF0 (ADC0)
-     (TXLED)     D5               PD5 (XCK1/#CTS)
-     (HWB)       -  (HWB)         PE2 (#HWB)
This was derived from the ATmega 32U4-Arduino Pin Mapping and ATMEL's datasheet for the ATmega32U4 chip. Once that was worked out, he flashed my test program onto his board, and also found that SoftwareSerial could transmit fine, but couldn't receive anything.

Ken rummaged around a little more, and had this to say :

The SoftSerial seems to use PCINT0-3 so there seems to me a minor problem in Leo-land in that only PCINT0 appears to be supported (and it is on "funky" output for RXLED). Hopefully I am just misunderstanding something (but it imay be the interrupt remap table is incorrect for Leo).
Then he disappeared for a little while, and came back with :
I have confirmed my suspicion. When I disassemble SoftSerial.cpp.o I can see that only __vector_9 is compiled (i.e., one of 4 #ifdefs for PCINT0-3) and the interrupt vector 10 is PCINT0 (0 is reset vector so offset by one makes sense). So, unless you hook serial to RXLED pin of CPU I don't believe it will work with the current libs.

Also I believe the Leo page is just wrong when it says pins 2 & 3 support pin change interrupts (I think this was copied from Uno but it is incorrect, the only (exposed) pins are D8 D9 D10 and D11 that support PCINT according to the ATMEL datasheet (and these are PCINT 4-7 not the ones in the interrupt mapping table AFAICT).

I believe this is where I can stop worrying that I'd be wasting the time of the core Arduino developers, and say quod erat demonstrandum; it a bug in SoftwareSerial. Hopefully they can update the Arduino IDE before the boards hits wider distribution.

Update : So, it turns out that this is a known limitation of the Leonardo. David Mellis looked into it, and left this comment :

You're right that the Leonardo only has one pin change interrupt, meaning that the software serial receive doesn't work on every pin. You should, however, be able to use pins 8 to 11 (inclusive) as receive pins for software serial. Additionally, the SPI pins (MISO, SCK, MOSI) available on the ICSP header and addressable from the Arduino software as pins 14, 15, and 16 should work.
He is, of course, correct. I'm not sure why my testing didn't work on pins 8-11, but they do indeed work fine. Unfortunately, this means that the Leonardo is not compatible with a number of cool shields. The Arduino SoftSerial Library Reference documentation has been updated with a more detailed list of limitations.

Sneak Pique

Posted by Russell on July 13, 2011 at 3:41 a.m.
I'm about to release a new piece of Open Source software; it's a fast, fully automated and very accurate analysis package for doing ChIP-seq with bacteria and archaea. I'm doing my best to avoid the sundry annoyances of of bioinformatics software; it uses standard, widely used file formats, it generates error messages that might actually help the user figure out what's wrong, and I've designed the internals to be easily hackable.

I have two problems, though.

Most of the people who will be interested in using this software are microbiologists and systems biologists, not computer people. At the moment, the software is a python package that depends on scipy, numpy and pysam. I used setuptools, wrote tests with nose, and hosted it on github. If I were going to distribute it to experienced Linux users, it's basically done. However, installing these dependencies on Windows and MacOS is a showstopper for most people -- scipy in particular. So, how would you suggest distributing it to MacOS and Windows users?

The second problem is... it's kind of ugly. I wrote the GUI in Tk, which is not particularly great in the looks department. Should I bother creating native tooklkit GUIs? Would that make people significantly more comfortable? Or would it be a waste of time?

Fun with de Bruijn graphs

Posted by Russell on October 29, 2010 at 4:34 a.m.
One of the projects I'm working on right now involves searching a better approaches to assembling short read data metagenomic data. Many of the popular short read assembly algorithms rely on a mathematical object called a de Bruijn graph. I wanted to play around with these things without having to rummage around in the guts of a real assembler. Real assemblers have to be designed with speed and memory conservation in mind -- or, at least they ought to be. So, I decided to write my own. My implementation is written in pure Python, so it's probably not going to win any points for speed (I may add some optimization later). However, it is pretty useful if all you want to tinker around with de Bruijn graphs.

Anyway, here is the de Bruijn graph for the sequence gggctagcgtttaagttcga projected into 4-mer space :

This is the de Bruijn graph in 32-mer space for a longer sequence (it happens to be a 16S rRNA sequence for a newly discovered, soon-to-be-announced species of Archaea).

It looks like a big scribble because it's folded up to fit into the viewing box. Topologically, it's actually just two long strands; one for the forward sequence, and one for its reverse compliment. There are only four termini, and if you follow them around the scribble, you won't find any branching.

Rooted phone

Posted by Russell on September 12, 2009 at 4:05 a.m.
I finally got fed up with the pathetic official Android release from T-Mobile, and rooted my G1 and installed the CyanogenMod firmware. Cyanogen feels about twice as responsive as Cupcake! It's like a whole new device.

Also, the tethering app is awesome. It turns your G1 into a WiFi base station and routes traffic from WiFi to 3G. Since I'm still waiting for broadband at my new apartment, it's a lifesaver.

I suppose tethering (and rooting the phone) technically violates T-Mobile's TOS, but I'm convinced that T-Mobile will allow both sooner or later. It's just too awsome, and it would help them sell more contracts.

It's kind of difficult to abuse tethering anyway; it sucks down the battery very quickly, and the latency is significant. It's the sort of thing you'd only use in a pinch. Those happen to be the situations where a little benevolence or selfishness from a big company can shape a customer's opinion forever. T-Mobile seems to be more sensitive to that kind of thing than the other networks. I know they've got their reasons for banning tethering apps, but I think they could be convinced to change their minds. (You can download various petitions from the Android Marketplace.)

Openness is where Google and T-Mobile could really go after the unwholesome, anticompetitive and un-American AT&T/iPhone alliance. The open nature of Android is a step in the right direction, but T-Mobile needs to get its legal department on the Open Access bandwagon if it wants to press the advantage.

After all, if some random people on the internet can roll better firmware for the G1 than their in-house developers, isn't it a strategic business advantage to let them?

Why I don't care about 802.11n

Posted by Russell on March 03, 2009 at 5:17 p.m.
I wish the WiFi Alliance people would stop worrying about the maximum speed of the 802.11 family of protocols, and instead worry about improving cooperation among networks. When 802.11b was new and shiny, it was fairly unlikely that you'd have to worry about spectrum competition. Now, wherever you are likely to find one network, you are likely to find a dozen.

Usually, this kind of mess happens in residential areas, but I've seen it lab buildings also. I would be more than happy to route a few of my neighbor's packets on my network in exchange for less spectrum congestion. What is needed here is a protocol that would allow owners of clashing access points to decide who they are friends with.

Of course, this would mean that anyone who owned an access point would have to be able to assert common carrier status, which could have some interesting side effects.

eBook reader

Posted by Russell on June 01, 2007 at 6:57 a.m.
I had a chance to play with Sony's eBook reader (a.k.a. the PRS-500) at Borders Books today. I was surprisingly pleased with it. It is a comfortable size and shape for reading prose, and the device is thin but not flimsy. If I read a lot of fiction for a living, I would buy one of these devices immediately.

The transition when you "flip" the page produces a very strange visual effect. Imagine you are looking at a page of text, and then someone spills a few blobs of ink on the page. The ink spreads out and covers most of the page, and then fades to reveal the next page. It takes about a second. After you press the next-page button, there is a one second delay before the computer wakes up and starts the re-draw process. So, it's about two seconds to flip the page. It's no slower than it takes to flip a page on an ordinary book, so I don't think it's a drawback.

Also, the screen does not look at all like paper. It looks like a light-gray plastic card printed with darkish-gray text with a matte finish. Although it doesn't have the look-and-feel of paper, the readability is just as good. Or, at least its as good as a paper printed with same color scheme. It's very similar to newsprint.

If I were going to use an eBook reader extensively, I would probably need more than one. The size of the screen is good for reading prose, but it is not appropriate for many other kinds of reading. Newspapers, textbooks and scientific papers really need a larger display area. These works are not meant to be digested linearly; the reader is encouraged to wander among the main body of prose, figures, tables, equations, and their respective captions. You need a display area at least as big as US Letter (8.5" x 11") or A4 (210mm × 297mm), and probably bigger. I would really need a 6" x 9" reader for casual reading and a 18" x 27" reader for serious work.

It would also be of great utility to be able to write on these devices. I can live without handwriting recognition, as long as there is a convenient way of filing and organizing my scribbles.

The eBook Reader is the first Sony product that has tempted me since I declared my Sony Moratorium. Nevertheless, at $350, plus overpriced DRM infested books, it's way outside my budget for this sort of thing.