As the Rascal has matured over the last few years, I've started to think about how it can change the working lives of artists and scientists. The Rascal is already a useful tool for people who have some experience with web programming and basic electronics, but I'd like to see it spread to a wider audience. I'm working on a number of projects to this end; I'll detail one in the scientific realm below.
In science, one of the largest changes in the last 20 or 30 years is the rise of computerized statistical analysis. Scientists have long used statistics to analyze their data, but with microcontrollers embedded in everything, we can now gather data more easily than ever before. I think it would be fair to say that our ability to gather data has outstripped our ability to manage that data.
In my experience, researchers manage data in a haphazard way, but only because it's so hard to do better. They're often collecting data from multiple instruments simultaneously. The data ends up with different timestamps, on various USB sticks or shared fileservers, often in CSV or Excel files, or in some weird text format specific to the instrument. The researcher then pulls the data together onto one computer, reconciles the timescales, and analyzes the data using Excel, SPSS, R, Python, or a software tool specific to their research specialty. Merging and reformatting the data into a form that you can analyze is painful, mind-numbing work, not worthy of the attention of a scientist.
I think we can do data collection and management better. It's a broad problem, but I'm working on a solution to one narrow slice of it, as I'll explain below.
I've been collaborating with an angel-funded startup at MIT called BioBright. Their goal is to build an open software framework for the collection, analysis, and visualization of biomedical data. Recently, we have been working on a device for the lab bench that will help biomedical experimenters log their progress while executing biomedical protocols.
The scenario goes like this: you're at the lab bench wearing nitrile gloves, holding a pipette in one hand and a test tube in the other. You might be working in a fume hood or a glovebox. You're working your way through a protocol, maybe printed out and stuck to the front of the fume hood. You'd like to be able to note down, "Yes, at 10:36 AM today, I exchanged the cell culture media," but given that the protocol is long and complex, and you have a lot of samples to deal with, you're not going to take the time at every step to log what happened. You'd have to put down the pipette, and type on your laptop one-handed, or use a pencil and a notebook. Your average time for each step could easily double or triple, and you might end up contaminating your samples as well.
If you could create a timestamped log of steps achieved and add less than 1 second per step, that would be worth it. Then, when something goes funny with your experiment, you can look back across multiple batches of samples or cultures and check where the preparations differed. Was one culture out of the fridge for longer? Did one solution spend the night on the stir plate, while the other was only stirred as long as it took to check email?
This is the idea of the event logger-- a small box that pulls your protocols from a central server. It shows you each step, and as you complete each step, you tap the button. You can hit it with a finger, the heel of your palm, or even your elbow. The box acknowledges your button press and moves to the next step. In the background, it timestamps the protocol step and logs to a file. If you're using the Biobright software or something that implements their API, the box logs the same data back to the central server.
That's the basic functionality, but we can add more advanced features. For example, if your protocol requires that you put your samples in an incubator for 18 minutes, the event logger will give you an 18-minute countdown, starting when you hit the button. Because every event logger contains a Rascal, it's also a webserver, so you can log into it remotely to change settings, look at the data, and so forth.
The event logger is obviously in a child-like state. If this sounds like something you would like to use in your lab, please get in touch with me at email@example.com. If you work in a lab around Boston, I would love to come to your lab and hear the details of what your lab needs. It may be nothing like the event logger; I'm still interested!
When I talk to people about the Rascal, they often ask about the differences between a Raspberry Pi and a Rascal.
Summary: if you want the cheapest possible computer, buy a Raspberry Pi. If you want to control some Arduino-style hardware from your web browser and you're a busy person, buy a Rascal.
The two boards have a lot of similarities, but a few major differences as well. Let's run through the similarities quickly.
I'll get to the specifics of the differences shortly, but let me explain what drives most of the differences: the two boards are intended for different purposes.
The Raspberry Pi is made by a nonprofit foundation in the United Kingdom for the purpose of teaching kids to program. To quote their website, "We want to see it being used by kids all over the world to learn programming. . . . Our main function is a charitable one – we’re trying to build the cheapest possible computer that provides a certain basic level of functionality . . ." The Raspberry Pi has connections for a monitor and keyboard.
The Rascal came from my work as an embedded systems engineer. I was frustrated that I couldn't buy an embedded Linux board that was preconfigured for controlling Arduino-style hardware from the web. I designed the Rascal so that I could plug Arduino shields directly into it, and I wrote the software using a modern web framework so that I wouldn't have to set that stuff up every time I started a new project. Then I added a code editor and wrote a Python library to make it even easier. The Rascal doesn't use a monitor-- you interact with it through your web browser.
Here's a summary of the differences.
|CPU||Broadcom BCM2835||Atmel AT91SAM9G20|
|ARM processor||ARM1176JZF-S @ 700 MHz||ARM926EJ/S @ 400 MHz|
|Graphics processor||VideoCore IV||None|
|RAM||512 MB||64 MB|
|Video||HDMI and analog||None|
|Audio||3.5 mm||Pins for I2S|
|Open source software||Some||All|
|Open source hardware||No||Yes|
|Hardware interface||26 male pins, plus 23 holes you can solder to||Arduino headers|
|Price (with SD card and power supply)||$52.66||$199|
|Webserver||None, but you can install one||Nginx|
|Python WSGI server||None, but you can install one||uWSGI|
|Code editor||None, but you can install one||Red|
|Web hardware API||None||Pytronics/Rascal API|
In the end, the decision comes down to the value of your time. Almost anything you could do with a Rascal, you could eventually do with a Raspberry Pi, if you're willing to learn a lot of Linux programming. If you're a Linux-savvy person just playing around with embedded computers, and tweaking the Linux kernel sounds interesting, you can save some money with the Raspberry Pi. If you're new to embedded computers or you just need to get something done quickly, I think the extra cost of the Rascal is worth it.
This post is to preview some of the stuff that I've been working on for the Rascal.
Suppose you want to build a pulse counter so you can tell how fast a motor is spinning. The pulses are coming out of the motor at around 10 kHz, i.e. at 10,000 pulses per second.
The Linux kernel that runs on the Rascal doles processor time out to different programs at 100 Hz, i.e. in 10 millisecond chunks. For example, the Rascal is constantly running a webserver, but also a program that watches for new USB hardware. The Linux kernel schedules those different programs so that they can share time on the same processor. If you were to add code that checked whether a pulse had arrived, it would share time with the rest of the processes running. With this kind of process scheduling running, reading pulses 10 times per second can be done, but reading pulses at 10 kHz is hopeless.
In my mind, I divide tasks into four groups:
In theory, you could change the Rascal's operating system so that the scheduling interval was much smaller, so you could actually check for pulses much faster. The problem with this approach is that every time you stop a process to run your pulse counting program, you burn some time in the switch. Eventually, your system is spending more time switching processes, and your pulse counter starts missing pulses.
A better approach is to use a secondary processor that can handle the low-latency stuff. I've been prototyping this kind of realtime coprocessor as a shield that can plug into the Rascal's headers. For lots of tasks, you could use almost any microprocessor, so long as it doesn't have an operating system. To make things easy, I'm prototyping with an Arduino kit. In the long run, I will probably use a small ARM processor, maybe something like the Cortex M3 used on the Arduino Due. For the meantime, I'm using an Arduino Uno and calling the project codename Slingshot. (Thanks to Dan Beyer for the naming suggestion. He thought a slingshot was the sort of accessory a rascal would keep close at hand.)
In the pulse counter example, the Slingshot counts the pulses very quickly. When the Rascal has a 10 ms slice available, it asks the Slingshot for the count. The Slingshot dumps the answer into its I2C hardware, which talks to the Rascal while the Slingshot keeps counting. In the long run, I would like the Rascal to come with a Slingshot built in, and with a pile of different programs available on the Rascal. If you want a pulse counter, you just select the pulse counter option, and the Rascal drops it onto the coprocessor for you.
The picture below shows the first attempt at the Slingshot. It's just an Arduino with some parts missing, but I think the functionality will be great.
I've left out the original headers and the power circuitry from the Arduino kit. For the power connections and I2C, I soldered pins in the open holes. These pins allow the Arduino to draw power from the Rascal's power supply and talk to the Rascal using I2C.
Anyway, this marks the beginning of the Slingshot. I think the Rascal/Slingshot combination will be powerful when the Slingshot is done.
I would remiss if I didn't mention that lots of other people have done this sort of thing before. In the open source hardware world, there's the Wyolum Alamode board, which is an Arduino that plugs into the Raspberry Pi and can talk over the serial port. One of the guys behind the Alamode, Kevin Osborn, works out of our local hackerspace here in Somerville, so I've talked this stuff over with him a few times.
One of the early Rascal customers was the Massachusetts General Hospital Learning Lab. The Learning Lab has been developing an attendance tracking system using 125 kHz RFID cards. In their current system, each card reader talks to an Arduino microcontroller using the Wiegand protocol; the Arduino talks to a PC over a USB cable; and the PC talks over the local network a database server to determine whether a card is valid or not.
The folks at the Learning Lab wanted to replace the PC and the Arduino with a Rascal, so I offered to help them interface their Wiegand card reader with the Rascal. For testing purposes, I got a cheap Wiegand protocol card reader off of Ebay. A little googling revealed that a gentleman by the name of Mark Jason Anderson had already written a Linux driver for Wiegand card readers. He used some CPU-specific kernel functions in his code, but luckily he was using the same Atmel AT91SAM9G20 processor that I use for the Rascal. I forked his wiegand-linux repository to my own on Github and modified the code slightly to use pins that the Rascal breaks out to its Arduino headers. I was able to build the kernel driver with the same cross-compiler I use for the Rascal kernel. The details of setting up the ARM cross-compiler are covered in the Rascal build guide.
There was one other challenge-- the card reader idles at 5 V, but the Rascal expects 3.3 V on its inputs. To scale the voltage down, I used a circuit not unlike the 2x voltage divider on the Sparkfun level shifter. The picture below shows the circuit. I used 4.64k and 9.09k resistors to scale the voltage down. In theory, this would reduce a 5 V signal to 3.31 V; I measured it at 3.29 V, so it was pretty close. I suspect that a 5k and 10k resistor would work fine, but I found the other values in my bins first.
The earlier kernel driver build provided me with a driver binary called wiegand-linux.ko. I copied that to the Rascal. For testing, I was able to insert it into the running kernel like this:
After this, the following shows up in dmesg:
To make the kernel load on boot, the binary should be moved into
/lib/modules/2.6.36+/ and the full filename,
wiegand-gpio.ko, added to
When a card is held next to the card reader, it beeps, the diamond flashes green, and we see new text in dmesg.
1 0 0 1 0 0 0 0 0 1 1 1 1 1 1 1 0 1 0 0 1 0 0 0 0 0 wiegand read complete
new read available: 32:65168
The new card data is also available from
In the long run, I'd like the RFID reader to display some confirmation that it's working properly on a display, so I hooked up a 4D Systems LCD that I had from a different project. Here's the whole assemblage.
The last step is to pull data from
/sys/kernel/wiegand/read and display it on an LCD. (Of course, the Rascal should also do something useful like unlock a door or log the card number to a database, but this is just a demo.) I wrote a short RFID monitoring Python script that does this on the Rascal. It would be nice to use the Rascal's Python server, uWSGI, to watch for new cards and trigger the Python so a second script wouldn't be needed, but that would mean writing a libudev plugin for uWSGI. I might do that eventually, but for now, this works fine. If you take a close look at the LCD in the picture above, you can see data from the few test RFID cards that I have.
One of the Rascal accessories I've been working on for scientists is what I call the Precision Voltage Shield. It's a circuitboard that plugs into the Rascal or an Arduino that allows you to measure 8 voltages very precisely. Yesterday, I got the precision voltage shield working as an 8-channel digital multimeter with an Arduino. I wanted to record some of the details of how I got working for posterity.
The core of the precision voltage shield is the Analog Devices AD7607 analog-to-digital converter. This chip measures 8 channels with 14 bits of resolution. There are also 16-bit and 18-bit versions, but they cost a little more. I'll probably offer variants of the shield that use those chips if people are interested.
The AD7607 has some awesome features that make it better than a classic A/D converter like the ADC0805. The first is the input filtering it includes. When you sample a voltage repeatedly over time, you run into the problem of aliasing, where high-frequency noise exceeds twice your sampling frequency, which makes it appear like low-frequency noise. Once you've sampled it, you can't tell whether it was high-frequency noise aliased down, or real low-frequency noise, so no digital filter can help you.
The fix for aliasing is an analog filter on each input. Older A/D chips didn't have this because we didn't know how to make capacitors inside chips cheaply. Analog Devices has apparently figured this out; their datasheet claims that each channel has an analog second-order Butterworth filter that attenuates noise over 15 kHz or so. (The 3 dB point changes slightly depending on the input range selected.)
The second cool feature is adjustable oversampling. In its default configuration, when you ask the precision voltage shield for a reading, it samples 64 times and gives you back the average reading. If you want, you can cut the traces under the OS0, OS1, and OS2 jumpers to configure the sampling rate to be higher, but there's no sense in doing that unless you can actually store data at significantly higher data rates than 1 kHz. (See the notes about speed further down for some more thoughts on this.)
The third excellent feature is the adjustable input range. With a jumper on the shield, you can choose whether the input range is +/-5 V or +/-10 V. This means that you can handle large voltages while still being able to read smaller voltages accurately if you need to.
To make the shield take a measurement, you pulse pin 5, which is labeled "CONV." The shield will answer by raising its "BUSY" line for around 300 microseconds. After this, the Rascal or Arduino can read the data out using the SPI protocol on "MISO" (pin 12). The oscilloscope screenshot below shows two full cycles of voltages being read. The gap between conversions (around 1 millisecond) is the time it takes for the Arduino to send the raw data to my laptop over USB at 115200 bps. With this gap, the system cycles at 735 Hz. The precision voltage shield Arduino code that I wrote for testing is up on Github. (You are welcome to use it however you like, but I would appreciate a link back to rascalmicro.com.)
The AD7607 spews out eight 14-bit measurements sequentially, each ranging from -8192 to 8192 to represent either -5 to 5 V or -10 to +10 V, depending on how the range jumper on the shield is set. The readings are encoded as the two's-complement of the count.
By default, the precision voltage shield oversamples by 64x and averages the values. As mentioned earlier, you can speed this up if you want, but you need a way to store the data.
The Arduino Uno I was using to talk to the shield has 32 kB of flash memory. If the Arduino pulls 8 readings at around 1 kHz and stores each reading in 2 bytes, that's 16,000 bytes per second, which means that the Arduino is full in 2 seconds. Some scientists do experiments that last less than two seconds, but many (most?) last much longer, which means we need a way to get data out of the Arduino.
I tried two different methods of sending the data: raw and formatting the 14-bit fields into ASCII characters separated by commas. The formatting makes the sampling around 3 times slower (200 Hz or so, rather than 735 Hz), but the limiting factor there was the Arduino's serial transmission rate. By default, the Arduino's serial library can only transmit at 115200 bps. From what I've read on the Arduino forums, an adjustment to the UART divider can get you up to 1 Mbps serial transmission, which should take the raw data transmission time from 1 ms to around 100 us. Adjusting oversampling to just 4x should get the conversion time down to 20 us, which means you're getting averaged samples every 200 us or so, which is equivalent to 5 kHz. To go faster than that, you could reduce oversampling further, speed up SPI (risking data corruption), and switch to a parallel data transmission scheme to get data out of the Arduino faster. In the right circumstances, the AD7607 can sample at 200 ksps, but actually achieving that would take some work.
The other obvious possibility is using something more powerful than the Arduino, like the Rascal. The Rascal's processor is 25 times faster than the Arduino Uno's, and it has an SD card for storage, so the delay incurred by sending the data out the serial port is avoided. When data does need to be transmitted, it has a 100 Mbps Ethernet port.
Next up: the precision voltage shield with a Rascal . . .