TxDuino: Custom PC Controlled RC Transmitter
Posted by cheshirekow in TxDuino on October 31, 2009
In our lab we have some very light weight foam aircraft that we do control work with. In order to keep the weight down, we use micro RC receivers that generate PWM signals for each of the servos that deflect one of three control surfaces: ailerons, elevator, and rudder. Note that both ailerons are linked and are together controlled by a single servo (a common setup for these lightweight foam planes). A PWM signal is also sent to control the throttle of the propeller. The glowing little spheres are reflective features to aid in motion capture which we use for estimation of the vehicle’s state.
The trick, however, is to get our control codes, running on a PC somewhere in the room, to actually change the deflection of the airplane’s control surfaces, or the throttle of the propeller.
The TxDuino project aims to create a single device that allows a PC to control an RC vehicle. At the time of starting this project, the only option for doing this was a device from here that could be plugged into the trainer port of a transmitter. An arduino has been used to achieve this same setup as described here. Going through the handheld transmitter, however, is a huge hassle for a number of reasons so I set out to create a simple single device that could accomplish this. As it turns out, so did the guys at Tom’s RC, their solution being this guy here. Anyway, since the work is done, I’ll share the results.
The easiest way that I figured to pull this off is to work with a modular RC transmitter, and interface directly with the module. For instance this is a transmitter
And this is the module that plugs into the back of the transmitter
The handheld part creates some kind of signal that it sends to the module, which does something, and then sends something else to the antenna. If I can figure out how to recreate that signal, then the “somethings” aren’t very important. The modules are cheap enough and easy enough to find that there isn’t much of a need to re-engineer that part.
To begin with, I needed to do some investigation. There are 5 pins on the back of the transmitter. It was easy enough by tracing the module circuit to find the source, ground, and RF out (antenna) pins, but what about the other two? I was hoping one of them was the control signal in a not too esoteric form, and I had no idea what the last would be. I managed to find the control signal with a little probing. Here is a little video showing the transmitter (Tx) hooked up to the module, via some wires with alligator clips which made it easy to investigate things.
After figuring our a little of what was going on, I found this forum post that had a pretty good discussion of the pinouts on this particular module. In particular, this post I found to be accurate and helpful.
Basically, looking at the back of the transmitter (or the top of the module, when the cover is off) the pins are
1 2 3 4 5 . . . . . left side #1 PPM #2 V+ #3 RF check #4 ground #5 RF out right side |
Of particular importance is the note on that post that the hand-held part is actually pulling the line low to make the pulses, and that the PPM line is at 2.5 volts.
I found a description of the PPM signal here. While the measurements I made using the oscilloscope did not match the information on that page exactly (I measured a 4us pulse between channels), using the signal description from that page has had good results. The details of the PPM frame are repeated here.
- complete PPM-Frame has a length of 22.5 ms.
- consists of an overlong start segment combined with 8 analog channels.
- stop pulse of 0.3 ms follows every channel’s impulse.
- The length of a channel’s impulse ranges from 0.7ms to 1.7 ms
Below is a video of the PPM signal from the transmitter. You can see the impulse length for each channel changes as I manipulate the control sticks on the handheld part of the transmitter. I apologize for the poor light sensing on my crappy little digital camera. Also, note that channel 5 jumps up and down because it is a flip switch (see the photo above) and only has two possible positions.
Ok, now that I know what is happening, I need a way to recreate that PPM signal using some kind of device that I can connect to my PC. Hey, the arduino is easy to develop with, comes with a USB controller, and has a nice software library that handles the PC interface stack. It’s also built around an Atmel microcontroller (my decimila specifically uses a ATmega168L) which has some pretty sophisticated features. It runs at 16Mhz, has three timers that can be used for generating interrupts, and comes with a (relatively) standard C / C++ compiler for writing code. Furthermore, the arduino’s bootloader means that I don’t even have to worry about messing with a programmer to get something up and running.
I wont go into all the gory details of the TxDuino design, but I will point out some of the relevant considerations.
The 168L has three timers. Timer1
is a 16-bit counter, Timer0
and Timer2
are 8-bit counters. Timers 0 and 1 share a prescaler, Timer2 has it’s own. The prescaler is a component that reduces the update rate of the timer, so we can scale the 16Mhz system clock to some fraction of it’s rate. Using an 8-bit counter would be extremely limiting because scaling the clock down enough that the counter capacity is sufficient would provide a counter resolution that is too coarse for the fine control we need to generate our waveform. This means I want to use Timer1
. However, Timer0
is used by the serial stack. I want to be able to send commands from the PC to the TxDuino which will require use of the serial interface. Thus, the serial baud rate will dictate the prescale factor used by Timer0, and thus used by Timer1… meaning that my choices are limited to whatever the serial stack allows.
A simple arduino test program, however, quells this dilemma.
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 | int inByte = 0; // incoming serial byte //define the Timer1 overflow interrupt service routine ISR(TIMER1_OVF_vect) { // print out the current value of the timer control register B which // contains the timer prescale value, set when the serial BAUD rate // is defined Serial.print("Timer1: "); Serial.print(TCCR1B, HEX); Serial.print("rn"); } void setup() { // set Timer1 to operate in "normal" mode TCCR1A = 0; // activate Timer1 overflow interrupt TIMSK1 = 1 << TOIE1; // start serial port at 9600 bps: Serial.begin(9600); } void loop() { // if we get a valid byte, read analog ins: if (Serial.available() > 0) { // get incoming byte: inByte = Serial.read(); Serial.print(inByte, BYTE); Serial.print("rn"); } } |
This program sets the serial baud rate to 9600 bits/sec, and then prints out the value of the Timer1
control register. A subset of the bits in that register indicate what the prescaler is set to, and thus what the prescale factor is. Running this program, and looking at the datasheet, I was able to determine that the prescale factor is set to 64. This means that the timer resolution for Timer1
is
And the 16-bit timer has a range of zero to
Since our frame length is 22.5 ms, we have plenty of range to work with. Also, the range on the individual servo channels is 1000 us, so that gives us 1000/4 = 250 possible steps for each channel (251 possible discrete positions). That gives us a resolution of better than +/- 0.5% for each channel, which is quite acceptable.
Also, since the PPM signal pulls the voltage on the line low, we cannot just use digitalWrite()
like we usually do when writing to a pin with the arduino. Instead, we need a way to drive the voltage to zero when we want to pull the line low, and a way to basically “do nothing” when we want the line high. We can do this by setting the pin voltage to LOW
, and then switching between INPUT
and OUTPUT
using pinMode()
The last consideration is the serial packet format. I decided to keep things simple. Since each channel can only have 251 possible values, I used an unsigned 8-bit integer ( possible values for an 8-bit number) for each channel, with values 0-250, and reserving 0xFF (255 in decimal) as a end-of-packet identifier.
Here is a little test code to demonstrate the use of pinMode()
to set the voltage of the line high / lo. It listens for either an 'a'
or 'b'
character over serial, and sets the line high or low depending on what is sent. If you want to play with this, you can use the terminal from within the Arduino software to send the commands.
int inByte = 0; // incoming serial byte int ppmPin = 2; // pin to make the waveform on // to setup the device, we will initialize all the channels, and initialize the // timer settings void setup() { // start serial port at 9600 bps, note that this also sets the Timer1 // prescaler, so we need to ensure that we don't change it later; a test // using a previous program showed that 9600 baud set the prescaler to 64 // or the Timer1 control register B to 0x03. Serial.begin(9600); // we configure the signal pin as an input; not that the signal actually is // an input but we modify the signal by pulling it low when we need to pinMode(ppmPin, INPUT); // then we set the inital state of the pin to be low digitalWrite(ppmPin, LOW); } // the main routine monitors the serial port, and on receipt of a completed // packet will recalculate the compare points for the specified signal void loop() { // if there's a byte available on the serial port, then read it in if (Serial.available() > 0) { // get incoming byte inByte = Serial.read(); switch(inByte) { case 'a': pinMode(ppmPin, OUTPUT); Serial.print("setting pin lown"); break; case 'b': pinMode(ppmPin, INPUT); Serial.print("setting pin highn"); break; default: break; } } } |
Here is a photo of the arduino hooked up with a resistor from the PPM pin to ground which allows me to look at the signal as I’m testing. The wire from the right side of the resistor to the ground terminal on the arduino is hidden behind the black probe. The other things connected to the breadboard are the transmitter module (the thing in the metal shield), and the back circuit board from the transmitter (the green thing; the pins from that board are plugged into the breadboard). The red thing is the battery for the transmitter.
Well that’s pretty much it as far as background and design. Here is the final code that I used to generate the desired waveform. I wont describe it much here since it’s heavily commented already. Basically it uses two compare match interrupts with Timer1
. The two interrupts leap-frog each other and signal either a rising edge or a falling edge. The counter is not cleared when the interrupts are serviced, until the last falling edge is serviced.
int inByte = 0; // incoming serial byte int ppmPin = 2; // pin to make the waveform on int chan[8]; // 8 channels encoded as 250 * (percent range) int compA[9]; // 9 compare points for Timer1 int compB[9]; // 9 compare points for Timer2 int iCompA = 0; // compare point index for currently active int iCompB = 0; // compare point index for currently active // the 0xFF byte will serve as a packet delimeter, we don't want to read // garbage from the serial so we'll start as soon as we get one of those but // not before int bDelimReceived = 0; // we don't want to write to any of the compare registers unless we have to // so we'll only do so at the end of a frame if that frame involved a change // in the current signal int bSignalChanged = 0; // index for which channel is next to read in int iChan = 0; // define the Timer1 compare match interrupt service routine for the rising // edge ISR(TIMER1_COMPA_vect) { // to set the line high, we switch the pin mode to "INPUT" pinMode(ppmPin, INPUT); // if this is not the last rising edge if( iCompA < 8 ) { // then we change the compare register to issue an interrupt at the next // rising edge, by incrementing the compare point counter iCompA++; // and then setting the compare register OCR1A = compA[iCompA]; } // if this is the last rising edge then we need to set the compare // register to be at the time of the rising edge following the start // frame else { // first, if the signal has changed since while writing the last frame // then we need to update the compare points if( bSignalChanged ) { compA[0] = 3550; for(int i = 0; i < 8; i++) compA[0] -= chan[i]; // the end of the first pulse is 75 ticks (300us) after that compB[0] = compA[0] + 75; // and then the rest of the compare points depend on the value of // each channel for(int i = 1; i < 9; i++ ) { compA[i] = compB[i-1] + chan[i-1] + 175; compB[i] = compA[i] + 75; } bSignalChanged = 0; } // then we set the compare point to match the end of the start segment iCompA = 0; OCR1A = compA[0]; } } // define the Timer1 compare match interrupt service routine for the falling // edge ISR(TIMER1_COMPB_vect) { // to set the pin low we open the collector pinMode(ppmPin, OUTPUT); // if this is not the last falling edge if( iCompB < 8 ) { // then we change the compare register to issue an interrupt at the next // rising edge, by incrementing the compare point counter iCompB++; // and then setting the compare register OCR1B = compB[iCompB]; } // if this is the last falling edge else { // then we wrap around to the beginning iCompB=0; // and set the compare register OCR1B = compB[iCompB]; // and we also need to reset the timer because this is the end of the // frame TCNT1 = 0x00; } } // to setup the device, we will initialize all the channels, and initialize the // timer settings void setup() { // initialize all eight channels to be at 125, or neutral for(int i=0; i < 8; i++) chan[i] = 125; // initialize the throttle to be "full left" which is actually "full stop" chan[2] = 0; // start serial port at 9600 bps, note that this also sets the Timer1 // prescaler, so we need to ensure that we don't change it later; a test // using a previous program showed that 9600 baud set the prescaler to 64 // or the Timer1 control register B to 0x03. Serial.begin(9600); // set Timer1 to operate in "normal" Mode, and set the // prescaler to 64; the default mode is one of the PWM modes so we need to // set this TCCR1A = 0; // note: Timer0 and Timer1 share a prescaler, and Timer0 is used by the // serial lines. Therefore, we cannot pick the value of the prescaler, // rather it is determined by the baud rate we want. A simple program has // shown that setting the baud rate to 9600 involves setting the prescaler // to 64 Serial.print("Timer Control Registers: n"); Serial.print(" A: 0x"); Serial.print(TCCR1A, HEX); Serial.print("n"); Serial.print(" B: 0x"); Serial.print(TCCR1B, HEX); Serial.print("n"); // set the Timer1 output compare register A to 3550 ticks, which corresponds // to 14,200us with the prescale set to 64; the math goes like this: // with the prescaler set to 64, the Timer1 period is 64/16e6 = 4us // want an interrupt issued after 22.5ms - 8*700us - 9*300us = 14,200us // means we want an interrupt issued after 14,200/4 = 3550 ticks compA[0] = 3550; OCR1A = compA[0]; // set Timer1 output compare register B to something 300us/4us = 75 ticks // after the first compare point for timer A compB[0] = compA[0] + 75; OCR1B = compB[0]; // we can go ahead and initialize all the other compare points as well, we // know that all the channels are set to zero, but I'll do this the long // way because it'll match code that we use elsewhere in this program for(int i=1; i < 9; i++) { compA[i] = compB[i-1] + chan[i-1] + 175; compB[i] = compA[i] + 75; } // activate Timer1 output compare interrupt with compare register A and // compare register B by setting the Output Compare Interrupt Enable bits TIMSK1 = 1 << OCIE1A | 1 << OCIE1B; // we configure the signal pin as an input; not that the signal actually is // an input but we modify the signal by an open collector so to make the // signal high we enable a 20K pull-up resistor, and to make the signal // low we open the collector pinMode(ppmPin, INPUT); // then we set the inital state of the pin to be low digitalWrite(ppmPin, LOW); } // the main routine monitors the serial port, and on receipt of a completed // packet will recalculate the compare points for the specified signal void loop() { // if there's a byte available on the serial port, then read it in while (Serial.available() > 0) { // get incoming byte inByte = Serial.read(); // if the byte is a packet delimiter, then start recording the new // packet by resetting the channel indexer if( inByte == 0xFF ) { bDelimReceived = 1; iChan = 0; } // otherwise, if we've recieved at least one packet delimiter and the // current channel index is valid, then record the chanel value; else if(bDelimReceived && iChan < 8) { // we can save some processing time by only updating the stored // values if the incoming command has changed, so we'll condition // the calculations on the fact that the byte is different than // what is already stored if(inByte != chan[iChan]) { // the protocol is defined to send values between 0 and 250 // inclusive, for 250 distinct values; the timing increment is // between 0 and 250 so we simply store the value chan[iChan] = inByte; // since the signal changed, we need to raise the flag bSignalChanged = true; } // then we increment the channel index so that we're ready for // the next byte that's sent iChan++; } } } |
In order to test this, I wrote this little program to send a sinusoidal input to the TxDuino. Note this code is specific to windows.
/** * file serialTest.cpp * date: Oct 27, 2009 * brief: * * detail: * This is a simple test program that demonstrates how to connect to and * write commands to the arduino transmitter interface using windows. * * the TxDuino is an interface into the futaba FP-TP-FM transmitter module, * which accepts an RC PPM input. This signal contains a maximum of 8 * servo channels. */ #include <iostream> #include <iomanip> #include <cmath> #include <windows.h> #define PI 3.14159265 int main( int argc, char** argv ) { using std::cout; using std::endl; using std::sin; using std::setw; // check to ensure that the command line included a device to open if( argc < 2 ) { cout << "Usage: serialTest.exe [Device Name]n" " where [Device Name] is the name of the COM port file onn " " windows (i.e. \\.\COM8), or the name of the serialn " " device on *nix (i.e. /dev/tty8)n" << endl; return -1; } // grab a pointer to the device to open char* strDevName = argv[1]; // open the file using the windows API HANDLE hComPort = CreateFile( strDevName, GENERIC_READ | GENERIC_WRITE, // access mode: read and write FILE_SHARE_READ|FILE_SHARE_WRITE, // (sharing) NULL, // (security) 0: none OPEN_EXISTING, // (creation) i.e. don't make it 0, // (overlapped operation) NULL); // no template file // check to make sure the file open succeeded if( hComPort == INVALID_HANDLE_VALUE ) { cout << "FATAL, Invalid device name: " << strDevName << "n" << endl; return -2; } // get the current settings on the com port DCB dcb; GetCommState( hComPort, &dcb ); // change the settings, the TxDuino uses a BAUD rate of 9600 dcb.fBinary = 1; dcb.BaudRate = CBR_9600; dcb.Parity = NOPARITY; dcb.ByteSize = 8; dcb.StopBits = ONESTOPBIT; // set the new settings for the port SetCommState( hComPort, &dcb ); // allocate the data buffer for sending over serial unsigned char data[9]; // set the last byte to be the stop byte data[8] = 0xFF; // send a sinusoidal input on all channels (except for channel 3, which is // usually the throttle) for 10 seconds for(int i=0; i < 1000; i++) { for(int j=0; j < 8; j++) data[j] = (unsigned char)(125.0 + 75.0 * sin( 2.0 * PI * i / 100.0 )); data[2] = 0; data[8] = 0xFF; for(int j=0; j < 8; j++) cout << setw(3) << (int)data[j] << " | "; cout << endl; DWORD bytesWritten; BOOL retVal = WriteFile( hComPort, // output handle data, // buffer of bytes to send 9, // number of bytes to send from buffer &bytesWritten, // pointer to a word that recieves number of // bytes written NULL); // pointer to an OVERLAPPED struct Sleep(1); } // close the device CloseHandle( hComPort ); return 0; } |
The result of running this test program with the probes attached to the arduino is below.
Then I disconnected the line from the handheld part of the transmitter to the module, and connected the arduino’s output instead. This is shown below.
By connecting the oscilloscope probes like this
I was able to test the output, which is shown here.
Everything looks good at this point. The next thing to do is connect the voltage and ground pins of the module directly to the batter, they RF out line to the antenna, and the RF good line to ground through a resistor. This is shown below. Note the module is underneath the little breadboard.
And when running the test program, this is what the airplane does.
And here you can see the waveform generated by the completed TxDuino prototype
And that’s that.
Installing Ubuntu 9.04
Posted by cheshirekow in Software Notes on October 19, 2009
These are my install notes for installing Ubuntu 9.04 on a Dell XPS with two NVIDIA 7900 GS cards in SLI and three monitors. Some of this is quite specific to this setup.
I did a no-cd install using the method described here
To install ubuntu without an install CD, I used the net installer. This was done on a system currently using windows XP, that already had an additional partition for linux.
The first thing I needed to do is download the linux kernel and the net installer. These are in two files linux.bin
and initrd.gz
. I got them from
For future versions, replace “jaunty” with the nickname of the current distribution. After downloading these two files in windows, I placed them in C:boot. This directory didn't exist yet, so I created it.
The next thing I needed was a boot loader that will allow me to choose which operating system to boot into. I used the open source GRUB for windows. I got it from the sourceforge page at http://sourceforge.net/projects/grub4dos/. The installer wasn't necessary. Instead I downloaded the grub4dos-0.4.4.zip file from the download page http://sourceforge.net/projects/grub4dos/files/. Then I extracted "gldr
" into "C:
" and extracted "menu.lst
" into "C:bootgrub
".
Next, I opened menu.lst
with a text editor (notepad++). At the very bottom I added the following
title Ubuntu Installer (hd0,1) kernel (hd0,1)/boot/linux vga=normal ramdisk_size=14972 root=/dev/rd/1 rw initrd (hd0,1)/boot/initrd.gz |
Note that the numbers above refer to the physical drive and logical partition, so this may change. Check the drive that you're working with.
The next thing I did was I edited boot.ini
so that the windows boot loader would give me the option of loading GRUB instead of windows xp. To edit boot.ini
run msconfig
and click on the edit button for boot.ini. Then I added this line at the end
C:gldr="Start GRUB" |
Then I restarted the computer. It stopped after the POST and gave the option of booting into windows or GRUB. I selected GRUB and hit enter. When GRUB loaded I went down to the last optionm "Ubuntu Installer" and hit enter. It then booted into the Ubuntu Net Installer
The installer attempted to use DHCP to connect to the internet. It then asked for a hostname so I put in the static IP address for this machine.
In the last step of the installer it said something about "only the base system is installed" and it asked what other parts to install. I selected something and hit "enter" but that didn't select the item for install, it just advanced to the next step. Thus I ended up with a base installation and just a console prompt. So I installed the rest of the desktop OS with
sudo apt-get install ubuntu-desktop |
Then I rebooted to get the desktop. When I was logged in, there was a little green circuit icon on the top right of the desktop. When I clicked this, it prompted me to install the closed-source nvidia drivers. I accepted that and rebooted. I had some problems with the multiple monitors though so I had to edit xorg.conf. Next time, don't reboot, but first open xorg.conf
for editing.
sudo gedit /etc/X11/xorg.conf |
Then I opened a separate terminal and run
sudo lspci | grep VGA |
The first column of what prints out is the "Bus Id" and I used that in xorg.conf
need that in a minute. Back in xorg.conf
and I edited it as follows.
# nvidia-settings: X configuration file generated by nvidia-settings # nvidia-settings: version 1.0 (buildd@palmer) Sun Feb 1 20:21:04 UTC 2009 Section "ServerLayout" Identifier "Layout0" Screen 0 "Screen0" 1680 0 Screen 1 "Screen1" RightOf "Screen0" Screen 2 "Screen2" LeftOf "Screen0" InputDevice "Keyboard0" "CoreKeyboard" InputDevice "Mouse0" "CorePointer" EndSection Section "Files" EndSection Section "Module" Load "dbe" Load "extmod" Load "type1" Load "freetype" Load "glx" EndSection Section "ServerFlags" Option "Xinerama" "1" EndSection Section "InputDevice" # generated from default Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/psaux" Option "Emulate3Buttons" "no" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" # generated from default Identifier "Keyboard0" Driver "kbd" EndSection Section "Monitor" # HorizSync source: edid, VertRefresh source: edid Identifier "Monitor2" VendorName "Unknown" ModelName "DELL 2007WFP" HorizSync 30.0 - 83.0 VertRefresh 56.0 - 76.0 Option "DPMS" EndSection Section "Monitor" # HorizSync source: edid, VertRefresh source: edid Identifier "Monitor0" VendorName "Unknown" ModelName "DELL 2007WFP" HorizSync 30.0 - 83.0 VertRefresh 56.0 - 76.0 Option "DPMS" EndSection Section "Monitor" # HorizSync source: edid, VertRefresh source: edid Identifier "Monitor1" VendorName "Unknown" ModelName "DELL 2007WFP" HorizSync 30.0 - 83.0 VertRefresh 56.0 - 76.0 Option "DPMS" EndSection Section "Device" Identifier "Device2" Driver "nvidia" VendorName "NVIDIA Corporation" BoardName "GeForce 7900 GS" BusID "PCI:1:0:0" Screen 1 EndSection Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" BoardName "GeForce 7900 GS" BusID "PCI:1:0:0" Screen 0 EndSection Section "Device" Identifier "Device1" Driver "nvidia" VendorName "NVIDIA Corporation" BoardName "GeForce 7900 GS" BusID "PCI:6:0:0" EndSection Section "Screen" Identifier "Screen2" Device "Device2" Monitor "Monitor2" DefaultDepth 24 Option "TwinView" "0" Option "metamodes" "DFP-1: nvidia-auto-select +0+0" SubSection "Display" Depth 24 EndSubSection EndSection Section "Screen" Identifier "Screen0" Device "Device0" Monitor "Monitor0" DefaultDepth 24 Option "TwinView" "0" Option "TwinViewXineramaInfoOrder" "DFP-0" Option "metamodes" "DFP-0: nvidia-auto-select +0+0; DFP-0: 1600x1024 +0+0; DFP-0: 1440x900 +0+0; DFP-0: 1400x1050 +0+0; DFP-0: 1360x768 +0+0; DFP-0: 1360x768_60_0 +0+0; DFP-0: 1280x1024 +0+0; DFP-0: 1280x1024_60 +0+0; DFP-0: 1280x960 +0+0; DFP-0: 1152x864 +0+0; DFP-0: 1152x864_75_0 +0+0; DFP-0: 1152x864_70 +0+0; DFP-0: 1152x864_60 +0+0; DFP-0: 1024x768 +0+0; DFP-0: 1024x768_70 +0+0; DFP-0: 1024x768_60 +0+0; DFP-0: 960x600 +0+0; DFP-0: 960x540 +0+0; DFP-0: 896x672 +0+0; DFP-0: 840x525 +0+0; DFP-0: 840x525d70 +0+0; DFP-0: 840x525d60 +0+0; DFP-0: 840x525d60_0 +0+0; DFP-0: 832x624 +0+0; DFP-0: 800x600 +0+0; DFP-0: 800x600d60 +0+0; DFP-0: 800x600_75 +0+0; DFP-0: 800x600_72 +0+0; DFP-0: 800x600_60 +0+0; DFP-0: 800x600_56 +0+0; DFP-0: 800x512 +0+0; DFP-0: 720x450 +0+0; DFP-0: 680x384 +0+0; DFP-0: 680x384d60_0 +0+0; DFP-0: 640x512 +0+0; DFP-0: 640x512d60 +0+0; DFP-0: 640x480 +0+0" SubSection "Display" Depth 24 EndSubSection EndSection Section "Screen" Identifier "Screen1" Device "Device1" Monitor "Monitor1" DefaultDepth 24 Option "TwinView" "0" Option "metamodes" "nvidia-auto-select +0+0" SubSection "Display" Depth 24 EndSubSection EndSection |
Then I needed to install flash in Firefox. I opened a terminal and typed.
sudo apt-get install flash-nonfree |
But then I needed to fix a few things because flash is buggy and closed source. I opened a terminal and typed the following.
# Flash also looks for /usr/lib/libesd.so.1 sudo ln -s /usr/lib/libesd.so.0 /usr/lib/libesd.so.1 # Flash expects /tmp/.esd/socket to exist. sudo mkdir -p /tmp/.esd/ sudo touch /tmp/.esd/socket |
And this enabled sound in flash pages.
Equation for the Line of Night on a Map of Earth
Posted by cheshirekow in Math on September 6, 2009
Recently a friend of mine expressed an interest in knowing what the equation was for the night/day line on a rectangular map of the earth. For example:
The line of night is generated by a projection of the Sun’s light onto the Earth, which we will consider to be a perfect spheroid with semi-major axis of and semi-minor axis of . If viewed from the “side” the line of night will appear to be a line with slope equal to that of the axial tilt (a.k.a obliquity) of earth. This is the inclination angle of Earth’s planetary rotation axis in relation to its orbital plane, usually denoted by
A typical map of the earth is a projection from spherical coordinates onto a cylindrical plane. This is done by drawing a rectangular image where the latitude () is mapped to the x-axis and the longitude () is mapped to the y-axis (contrary to the coordinate system used by the digital imaging industry, here we describe the origin as being in the center of the image, with the positive x-axis being to the right, and positive y-axis being up).
Consider then a plane that is perpendicular to the earth’s plane of orbit, and perpendicular to the vector pointing from the center of the earth toward the sun, and that intersects the earth at it’s center. The line of night is the intersection of this plane with the Earth. From this observation we can develop an equation for the line of night in terms of and .
If we place a coordinate system on the surface of the earth, centered at the intersection of the line of night with the equator with the positive x-axis corresponding to positive and positive y-axis corresponding to positive we can describe the line-of-night plane as
where the slope is related to the obliquity as
where is the inclination of the axial tilt of the Earth’s axis at solstice () scaled according to the position of the Earth in it’s orbit
The inclination of the earth’s axis at solstice is
From the parameterization of a spheroid, we know that
Combining these with the equation above for the line-of-night plane we see that
Plotting the value of the longitude against latitude over a range of axial inclinations from to , and assuming results in the following:
Which has exactly the shape we were looking for.