1) Go to Horizons and get the spice kernel
telnet ssd.jpl.nasa.gov:6775
type 2012 DA14, and say yes to do a name search. Once it finds it, type s to get an SPK kernel. Give the following answers:
SPK text transfer format [ YES, NO, ? ] : n
SPK object START [ t >= 1900-Jan-01, ? ] : 2013-Feb-01
SPK object STOP [ t <= 2101-Jan-01, ? ] : 2013-Mar-01
Binary SPK will be created, you will be asked to add more objects, say n.
Now you will get a download link, copy it to your browser and save it. It will be named something like wld17761.16.
2) Install Celestia
3) Create an extra for Celestia
Create a text file 2012_DA14.ssc in the extras folder and create a data folder within that folder. I needed to run a text editor as administrator to do this.
In the text file, paste the following text:
"2012 DA14" "Sol"
{
Class "asteroid"
Texture "asteroid.jpg"
Color [ 1.000 0.960 0.919 ]
BlendTexture true
Radius 0.025
SpiceOrbit
{
Kernel "2012_DA14.bsp"
Target "3599602"
Origin "SUN"
Beginning "2013 2 13"
Ending "2013 2 17"
BoundingRadius 1.5
Period 1.0
}
UniformRotation
{
Period 5.918
}
Albedo 0.048
}
4) Copy the spice kernel wld12345.16 to the extras/data folder and rename it 2012_DA14.bsp
5) Start up Celestia and look for 2012 DA14 in the solar system browser. It should be the last item under Sol. If it's not there, use ~ to bring up the debug screen and up and down to scroll it, and see if there are any errors for 2012 DA14.
Closest observed distance is just under 30000km. It travels from south to north past the night side of Earth.
Friday, February 15, 2013
Friday, February 8, 2013
Gem of the Week - On-Demand Printing
The Big One, by Stuart Slade. World War II went very differently, with England basically surrendering after Dunkirk, immediately drawing the USA into the war. With the Western front secure, Germany was able to focus on the Russian front. They captured Moscow (and killed Stalin, good riddance) but were stopped short of the Urals by the combined Russian and American armies, where they stalemated for five years.
One day in 1947, that changed. On that day, over a thousand planes were launched from bases all along the East Coast of the United states, carrying over 200 Mark III atomic bombs. These were upgraded from the Mk3 used in our timeline, with a typical yield of 35kT instead of the 20kT of Trinity and Fat Man. The main bombers were B-36s, with four bombs each. Each bomber had two escorts, also B-36s.
Interestingly, once the bombers were over Germany, they turned on Salvage Fuses, which would set the bombs off once they reached 2000ft, even if still in the plane. So even shooting down a bomber won't save you. In fact, the second blast was due to this very effect. That's just mean...
One hundred fifteen bombs are accounted for in the book, including twelve for Berlin, eight for Munich, and twenty-five between Dortmund and Bonn. Two were in the Frankfurt area, one in Koblenz, one in Heidelberg, but none in Rothenberg. Estimated casualties are twenty million immediate fatalities and probably that many again from radiation, lingering injuries, illness, and the collapse of civilization and famine caused thereby. The population of Germany was about 60 million in 1945, real world timeline.
It's an interesting story, but it has some holes in it, like how in the world did General Groves keep Manhattan secret for two additional years while they built up the stockpile? I got the book largely to see the answer to that question, but I didn't find it. Also, I am surprised they didn't base in Russia. However looking at the map, it is almost as far from the Front to Germany as it is all the way from America.
But none of that is the Gem. I found out about the Big One on the TV Tropes Wiki in late January, and after failing to find the story in free form on the net, I decided to shell out and buy the book on Friday, 1 Feb 2013. The last page of the book is marked:
One day in 1947, that changed. On that day, over a thousand planes were launched from bases all along the East Coast of the United states, carrying over 200 Mark III atomic bombs. These were upgraded from the Mk3 used in our timeline, with a typical yield of 35kT instead of the 20kT of Trinity and Fat Man. The main bombers were B-36s, with four bombs each. Each bomber had two escorts, also B-36s.
 |
| That smaller plane to the left is a B-29. To put it mildly, the B-36 is a large aircraft. |
Interestingly, once the bombers were over Germany, they turned on Salvage Fuses, which would set the bombs off once they reached 2000ft, even if still in the plane. So even shooting down a bomber won't save you. In fact, the second blast was due to this very effect. That's just mean...
One hundred fifteen bombs are accounted for in the book, including twelve for Berlin, eight for Munich, and twenty-five between Dortmund and Bonn. Two were in the Frankfurt area, one in Koblenz, one in Heidelberg, but none in Rothenberg. Estimated casualties are twenty million immediate fatalities and probably that many again from radiation, lingering injuries, illness, and the collapse of civilization and famine caused thereby. The population of Germany was about 60 million in 1945, real world timeline.
It's an interesting story, but it has some holes in it, like how in the world did General Groves keep Manhattan secret for two additional years while they built up the stockpile? I got the book largely to see the answer to that question, but I didn't find it. Also, I am surprised they didn't base in Russia. However looking at the map, it is almost as far from the Front to Germany as it is all the way from America.
But none of that is the Gem. I found out about the Big One on the TV Tropes Wiki in late January, and after failing to find the story in free form on the net, I decided to shell out and buy the book on Friday, 1 Feb 2013. The last page of the book is marked:
Made in the USA
Lexington, KY
02 February 2013
The book was made after I ordered it. It seems that it was literally made for me.
Saturday, February 2, 2013
Gem of the Week - EEPROM I2C Memory
Of course I am designing a Rocketometer around the Propeller. How could it be otherwise?
In doing so, I have to get my own parts. The Sparkfun breakout is an interesting jumping-off point, but they don't even use bypass caps, so I added a set of those. Also one thing which concerns me about this whole endeavor is that all the memory is limited. Each cog gets 2kiB, for a total of 16kiB, but the images for each cog must be stored in main memory, which has 32kiB of RAM and 32kiB of ROM. There is no way that I am going to be able to get the program source code embedded with that little amount of memory.
This brings us back to the EEPROM on the breakout board. The bootloader burned into the Propeller knows how to bit-bang an I2C interface and read a memory on the bus. It treats the memory as a 32kiB byte-addressable memory with auto-increment, so it can set an address once, then read and read and read and fill main RAM. The Propeller documents say to use a 24LC256 or similar, so I got to looking at Digikey to see if they had that chip, and perhaps more interestingly, if there was a bigger chip which would still work. It turns out that the design of the EEPROM is the gem of the week.
First, the hardware. The 24LC256 is a 256kib memory organized as a 32ki x 8 (byte-addressable) memory. It is in a kind of large package, a whopping 5mm wide, with 8 pins. This is a lot for a device which is I2C and could in principle work with only 4 pins. But here is the cleverness. The device has three address pins, allowing the 7-bit I2C address to be anything in the range 0x50-0x57. So, you could just stack up to 8 devices on the bus, with only the address pins different, and get 32x8=256kiB of memory, at the cost of using 8 devices.
The 32kiB space is addressable with 15 bits, but the I2C protocol is byte-oriented, so you have to send 16 bits, of which only A0-A14 are considered, and A15 is ignored.
These facts work together to allow the address space to be easily extended. First, a 64kiB part is doable just by considering A15 in the address. Next, a device can internally answer more than one address, for instance by ignoring the A0 hardware pin and answering both 0x50 and 0x51. This of course means that you have to readdress the device when you cross from the address space covered by 0x50 and the one covered by 0x51. You would have to do that anyway if there were multiple real devices.
This all adds up to the STMicro M24M02, which appears to be compatible with the 24LC256, in that if you talk to an 'M02 like a '256, it will answer like a '256. So, you can use the larger device and the bootloader should happily just work. However, it is a 2Mib memory organized as 256ki x 8 (256kiB), eight times as much memory as the reference design, and approaching comparability with the LPC2148 and its 512kiB of Flash. Then when your application takes over, you can use your own bit-bang to access the full chip.
The 'M02 still has one address pin, so in principle you could make a 512kiB memory in 1 chip without changing anything. Going beyond this will break the nice de-facto protocol going on here.
In doing so, I have to get my own parts. The Sparkfun breakout is an interesting jumping-off point, but they don't even use bypass caps, so I added a set of those. Also one thing which concerns me about this whole endeavor is that all the memory is limited. Each cog gets 2kiB, for a total of 16kiB, but the images for each cog must be stored in main memory, which has 32kiB of RAM and 32kiB of ROM. There is no way that I am going to be able to get the program source code embedded with that little amount of memory.
This brings us back to the EEPROM on the breakout board. The bootloader burned into the Propeller knows how to bit-bang an I2C interface and read a memory on the bus. It treats the memory as a 32kiB byte-addressable memory with auto-increment, so it can set an address once, then read and read and read and fill main RAM. The Propeller documents say to use a 24LC256 or similar, so I got to looking at Digikey to see if they had that chip, and perhaps more interestingly, if there was a bigger chip which would still work. It turns out that the design of the EEPROM is the gem of the week.
First, the hardware. The 24LC256 is a 256kib memory organized as a 32ki x 8 (byte-addressable) memory. It is in a kind of large package, a whopping 5mm wide, with 8 pins. This is a lot for a device which is I2C and could in principle work with only 4 pins. But here is the cleverness. The device has three address pins, allowing the 7-bit I2C address to be anything in the range 0x50-0x57. So, you could just stack up to 8 devices on the bus, with only the address pins different, and get 32x8=256kiB of memory, at the cost of using 8 devices.
The 32kiB space is addressable with 15 bits, but the I2C protocol is byte-oriented, so you have to send 16 bits, of which only A0-A14 are considered, and A15 is ignored.
These facts work together to allow the address space to be easily extended. First, a 64kiB part is doable just by considering A15 in the address. Next, a device can internally answer more than one address, for instance by ignoring the A0 hardware pin and answering both 0x50 and 0x51. This of course means that you have to readdress the device when you cross from the address space covered by 0x50 and the one covered by 0x51. You would have to do that anyway if there were multiple real devices.
This all adds up to the STMicro M24M02, which appears to be compatible with the 24LC256, in that if you talk to an 'M02 like a '256, it will answer like a '256. So, you can use the larger device and the bootloader should happily just work. However, it is a 2Mib memory organized as 256ki x 8 (256kiB), eight times as much memory as the reference design, and approaching comparability with the LPC2148 and its 512kiB of Flash. Then when your application takes over, you can use your own bit-bang to access the full chip.
The 'M02 still has one address pin, so in principle you could make a 512kiB memory in 1 chip without changing anything. Going beyond this will break the nice de-facto protocol going on here.
Subscribe to:
Posts (Atom)