Anamnesis Launched
I have just put up the code for a project I’ve been working on called Anamnesis. It is a SIMBL-based plugin for Safari on Mac OS X that adds “Reopen Last Closed Tab” functionality. Please check out the Anamnesis page (see links @ top of page) for more information.
Reading and Parsing USB GPS Data in C (with NmeaLib)
I’m currently working on a project that requires GPS data, and need a way to retrieve data from a USB-based GPS receiver I purchased (a USGlobSat BU-353 USB GPS receiver). Fortunately, most GPS receivers, particularly USB ones, support the NMEA 0183 protocol. NMEA 0183 is a serial-based protocol was developed by the National Marine Electronics Association and is used to collect data from a variety of aquatic electronic devices (such as sonar, GPS, and others). Most USB-based GPS receivers have a serial-to-USB converter built in, which allows data to be read from a device as if it were a serial device. For instance, the BU-353 shows up in Mac OS X as /dev/cu.usbserial. If you plug in your GPS device and boot up minicom, you’ll see output that looks a lot like this
Sample NMEA 0183 Strings
Obviously the strings are somewhat cryptic, but you can discern some data among them that looks like GPS data. Unfortunately the protocol is not open, and costs at least $270 to buy from the NMEA. Fortunately, most of it has been reverse engineered, and there is a great library which already exists to parse these strings into useable data. It is called NmeaLib and it is released under the LGPL. The way it works is that you first initialize it, then just feed it every string that the GPS device feeds you over the serial device, and it will interpret the data and keep a cumulative collection of all available data from the GPS receiver. In addition to the basic latitude and longitude data, it will also report the number of satellites in view, the number satellites being used, the signal strengths of both, as well as the current GPS time and many other useful pieces of information.
The big remaining task once you have the library is to read from the GPS serial device. Reading from a serial device might seem like it would be as simple as reading from a file (and in some ways it is), but because serial port data can come at various rates and in various formats (for instance it might come at 9600 Baud with no parity bit and with 8 bits of data), there are some other calls you need to make to set the various serial settings.
To begin with, we need to get a file descriptor for the serial port. This can be done simply with
gpsFd = open("/dev/cu.usbserial", O_RDONLY | O_NOCTTY | O_NONBLOCK);
You will also need some of the structures and functions included in termios.h, the POSIX terminal definitions, in order to set the appropriate terminal settings.
struct termios options; struct termios origPortOptions; //Get the existing options so they can be restored tcgetattr(gpsFd, &origPortOptions); bzero(&options, sizeof(options)); //Set the BAUD rate to NMEA specifications cfsetospeed(&options, B4800); options.c_cflag |= (CLOCAL | CREAD); //Settings equivalent to 8N1 options.c_cflag &= ~PARENB; //Disabled parity options.c_cflag &= ~CSTOPB; //Set 1 stop bit (| would give us 2 stop bits) options.c_cflag |= CS8; //Set character size to 8 bits options.c_cflag |= CRTSCTS; //Enable hardware flow control options.c_oflag |= (OPOST | ONLCR); //Processed output and mapping of newlines to CR-LF pairs tcsetattr(gpsFd, TCSAFLUSH, &options); //Flush buffers and apply the new settings
After that, you can read from gpsFd like any other file descriptor. If you want to get the number of bytes waiting in the buffer to be read, you can use ioctl() as follows:
int bytesInBuffer; //Get the number of bytes waiting in the serial buffer ioctl(gpsFd, FIONREAD, &bytesInBuffer);
I have attached a simple library (with NmeaLib included) that you can use in your own projects (assuming your serial or USB GPS device uses the same data settings). To use it, you simply call initializeGps(), then get the most recent GPS info by calling getGpsInfo() (which returns an NmeaLib structure). Once you’re finished retrieving GPS data, call closeGps() to free up the serial port and restore its previous settings.
The library uses setitimer() to install an alarm that will call a read handler that will pull all data waiting in the serial buffer and then parse it using NmeaLib. You can change the update frequency if you like, but it is already much faster than it really needs to be, and I’d recommend just leaving it alone as it is very low overhead.
I’ve also included a test program that shows how to use the code in gps.h/.c. Its output looks something like the following:
Sample GPS Data
Yeah so now you know where I live, but I suppose a determined individual could get that from a domain registrar anyway.
Feel free to reuse this code however you see fit, although if you do, some credit is always appreciated. Have fun building those autonomous spy blimps.
How to Monitor Parallel Port Interrupts in User Space in Linux
DISCLAIMER: A computer is not a cheap device and home-made electronics are not always reliable. I take no responsibility for damage caused by you sticking shit into your parallel port or anywhere else on your computer to see what happens. I also take no responsibility for any side-effects of the following code. That said, if you’re careful, the parallel port can be a very useful device for interfacing your computer with external devices, and the following code is working fine for me.
Anyway, I’m guessing you want to install an interrupt handler for the parallel port, but aren’t a kernel hacker and don’t want to read a ton of documentation? Well, fortunately I had the same issue and was able to get something similar working. Unfortunately dealing with the parallel port in user space isn’t exactly the same as writing a kernel module, and there are a few important things to remember:
- Code which accesses the parallel port must be run as root
- Only one piece of code which uses this method may listen for interrupts at a time
- The parallel port cannot be sharing an IRQ (although this shouldn’t be an issue since the parallel port usually has a dedicated IRQ anyway, number 5 or 7 most of the time)
So without further ado, here is what I’ve got:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 | #include <linux/ppdev.h> #include <linux/parport.h> #include <stropts.h> #include <stdio.h> #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> #include <sys/ioctl.h> #include <sys/select.h> #define PP_DEV_NAME "/dev/parport0" int main() { //Get a file descriptor for the parallel port int ppfd; ppfd = open(PP_DEV_NAME, O_RDWR); if(ppfd == -1) { printf("Unable to open parallel port!\n"); return 1; } //Have to claim the device if(ioctl(ppfd, PPCLAIM)) { printf("Couldn't claim parallel port!\n"); close(ppfd); return 1; } while(1) { //Set up the control lines for when an interrupt happens int int_count; int busy = PARPORT_STATUS_ACK | PARPORT_STATUS_ERROR; int acking = PARPORT_STATUS_ERROR; int ready = PARPORT_STATUS_ACK | PARPORT_STATUS_ERROR; char int_value; ioctl(ppfd, PPWCTLONIRQ, &busy); //Let ppdev know we're ready for interrupts ioctl(ppfd, PPWCONTROL, &ready); //Wait for an interrupt fd_set rfds; FD_ZERO(&rfds); FD_SET(ppfd, &rfds); if(select(ppfd + 1, &rfds, NULL, NULL, NULL)) { printf("Received interrupt\n"); } else continue; //Caught a signal //Fetch the associated data ioctl(ppfd, PPRDATA, &int_value); //Clear the interrupt ioctl(ppfd, PPCLRIRQ, &int_count); if(int_count > 1) printf("Uh oh, missed %i interrupts!\n", int_count - 1); //Acknowledge the interrupt ioctl(ppfd, PPWCONTROL, &acking); usleep(2); ioctl(ppfd, PPWCONTROL, &busy); } return 0; } |
As you can see, what you’re essentially doing is just opening the parallel port device like any old file and then calling select() to wait until an interrupt (or some other signal) happens. Here all I’m doing is writing a line to the console whenever an interrupt is received, but of course you can do anything (so long as the interrupt handler is fast enough to deal with your interrupt frequency). There are also a few ioctl() calls for claiming the port and clearing interrupts, but for the most part, the comments are self-explanatory and the code can just be copied into your project.
There is of course one fundamental issue with this code, and that is that it blocks until an interrupt is received. My suggestion, and the way I use this code, is to launch off another thread that runs this code and just sits dormant until an interrupt occurs. This seems to be relatively low overhead and pretty reliable. I’ve avoided giving the sample code in a threaded example so that it’s easy to extract and use in your own projects. Feel free to email me if you have a question or suggestion.
Also, in case you’re wondering how to trigger a parallel port interrupt, it’s triggered on the rising edge (or on some boards the falling edge) of a signal on pin 10, so just short pin 10 to ground (pins 18-15) and you should see an interrupt triggered (it may be triggered when you unshort it).
Here is a zipped copy of the code for your viewing/programming pleasure:
Sample Code for Parallel Port Interrupt Handling in Linux
Clebsch-Gordan Coefficient Calculator
I was trying to find a calculator for Clebsch-Gordan tables online the other day, but couldn’t find anything that produced tables of a nicely printable format. In particular, I was looking for something that provided output like these tables. As a result, I was forced to write my own, which gave me some decent experience in working with the Python Imaging Library (PIL). After a little bit of playing around, I was able to produce tables that looked decently similar
Anyway, I figured that people might find the script useful, so I’ve decided to upload it. It requires Python 2.5. You will also need the PIL installed in order to use this. Just run the program like
python ClebschGordan.py
and follow the onscreen instructions. The script should be fairly easily adaptable to other applications as well (for instance if you wanted to modify it to write to a spreadsheet instead or something), you’ll just need to add a new render method to the tableWedge class.
I DO NOT guarantee the accuracy of the outputted values, although I’ve tested it against all the values of the linked page above, and it seemed to work fine. Please let me know if you find any issues and I’ll try to fix them.
Enjoy.
P.S. Yes, I’m aware of the recursion relations that can be used to calculate these values. I decided against using them to calculate the coefficients though because I think it would make the code far more complex, not to mention, computing power is cheap. I was able to calculate a table for 13/2 X 13/2 in just a few seconds.
keep looking »