I found myself designing smaller and smaller HABs and after the radio cutout on HABEXpico1 (suspected to be due to cold temperatures) I decided it would be a good idea to create an environmental chamber that would replicate the conditions of nearspace.
The conditions of nearspace aren’t too kind to electronics. Air temperature can be anywhere from -60C to +40C, the air pressure at the average burst altitude of 30,000m (100,000ft) is 1% of the pressure on the ground. Electronics dependent on convection for cooling can easily overheat, and the cold temperatures can shut down electronics if they are not rated for those conditions and if the insulation isn’t sufficient.
Expected environmental conditions:
•Air Temperature: -60C to +40C
•Pressure: 0.01atm (1010Pa) to 1atm (101325Pa)
•Winds: 0mph – 100mph
•Forces: up to 10g
•Humidity: 0% – 100%
•Solar Heat (Irradiance): 180 W/m^2 - 340 W/m^2
Heat Transfer Diagram:
The goal was to build a thermal/vacuum chamber for $100-200 capable of testing and answering the 3 following questions:
1) Can your HAB survive the expected temperatures?
2) How well does your insulation work?
3) Does your HAB overheat? (Do your parts need cooling?)
Now you can attempt to do thermal modeling… but that gets tricky. You can save time and get good results by just testing it.
For each environmental condition you can replicate the follow conditions using the following:
•Air Temperature -60C to +40C: Dry Ice, Hair Dryer
On the left is a vacuum pump connected to a schedule 40 PVC tee with 1/2″ thick polycarbonate lids sealed by silicone rubber. Outside you can see a light bulb facing the window which is used to replicate the expected solar flux. In the original design, a peltier cooler was interfaced with a copper rod running from the outside into the chamber was used to cool the HAB inside. Due to a large thermal gradient across the copper rod this cooling system was scraped. The new cooling system was not only cheaper, but more effective. The solution was to wrap a small flat piece of dry ice with cloth and tape it to one side of the hab then hang the hab from fishing string inside the chamber. This would result in one side of the HAB getting very cold (-40C or so). This however requires you to run the pump continuously since the dry ice sublimates creating CO2 gas. If you were to turn on the light bulb, you would notice one side getting warmer while the sides in the shadows remain cold.
Dry Ice & cloth taped on one side…
You can see the light bulb, chamber, and the HAB inside..
I ran kaynar wire through the top plate and filled it with epoxy. Holds up under pressure!
These were the results. The one side facing the “sun” got to about 28C (RED), while the cold side facing “deep space” aka dry ice got the outside of the insulation to about -40C (BLUE), and the inside of the HAB slowly moved down to about 10C (GREEN). Not bad, but not great. The problem with this setup is the fact that the dry ice is thermal interfaced with by conduction, rather than radiation. In a proper thermal vacuum chamber a shroud with liquid nitrogen tubes is run through the walls to produce cold walls. The walls are coated with a material such as black paint (high absorptivity), this forms good radiative thermal coupling. One could improve the design by having this and even placing it on a lazy susan to allow the hab to rotate and spin while the sunlight is applied. However, the setup would cost more than the original budget of “under $200″. Please note that this a “build at your own risk” project. I’m not responsible if your chamber implodes or hurts anyone. Also, do not cool down the PVC itself, that could make it very fragile.
So as the journey toward creating a HAB that you can accidentally breath in continues… I finally got HABEXpico4 working! Seeing how HABEX1 weighed 6.00lbs, HABEX2 weighed 4.00lbs, and HABEXpico1 weighed 250g, it’s pretty amazing to see HABEXpico4 around 12g with battery/insulation/antennas. So what happen to HABEXpico 2 and 3? HABEXpico2 was scrapped after the boards were made because it couldn’t be light enough or power efficient, and HABEXpico3 was small but not small enough and used software serial (very stupid). After messing around with the design, I realized it’s better to just merge the design with M0UPU‘s PAVA8 which used the real hardware serial ports. The only difference now is that my design uses a Si4464 which can transmit and receive data. Plus this means shared code! So any improvements software wise would help others. So huge thanks to M0UPU for his help in all this.
The boards were manufactured by Hackvana who made an insanely good offer… $21 for 10 of these 0.8mm/white HAB pcbs! Totally recommend them for a good quality low cost PCB run.
We have all heard by now that Curiosity, JPL/NASA’s new rover, has successfully landed on mars and is now roving the surface http://www.jpl.nasa.gov/msl/
Here’s the thing with mars though.. time is kept differently there. This is because mars itself rotates a little slower than earth. Rather than a solar day taking 24 hours like it does here on earth, mars has a solar day of 24 earth hours 39 earth minutes and 35 earth seconds. This proves to be a pain when it comes to timekeeping. If you set your normal earth watch to the exact mars time at that moment, you will lose a mars second every 36 seconds on your watch. This is because earth seconds and mars seconds are different. Since you want to have a 24 hours day (Sol) you must scale the 24 earth hours, 39 earth minutes and 35 earth seconds into 24 mars hours. This redefines a second: 1 mars second = 1.0274912510416665 earth seconds. Side note: a mars day is called a “Sol”.
Now who really needs this? The answer is the mars rover team. In order to have an efficient day driving on mars, the rover driving team lives on mars time. From what I can tell, it seems painful. However, I wouldn’t mind doing it if it was for the opportunity to drive a rover on mars Although I don’t live on mars time and am not involved in the driving process, I still have this odd fascination with keeping track of mars time. I remember back in 2004 a local jeweler has figured out how to make analog mars watches: http://marsrovers.jpl.nasa.gov/spotlight/spirit/a3_20040108.html This was too cool! I realized I couldn’t dish out $300 (a lot of money for a kid back then) to get a watch I wouldn’t need. Most of the people who bought them were apart of the mars team anyway.
Fast forward 8 years and now we have a new rover on the surface of mars, and all though I had a very very small role in the mission I’m still no where near having to live on mars time, but who says I can’t have a mars watch anyway?
With the knowledge of keeping time on mars and a good background in embedded systems I figured it shouldn’t be too hard to modify a digital watch. I searched around and found the perfect watch for this project:
The watch comes loaded with features: rf communication, timers, alarms, accelerometer, barometer, and a temperature sensor.
The watch also comes with an rf to usb module, usb programmer/debugger, and a screw driver. For $50, it’s a steal. I looked over the example code before purchasing it and discovered that I could modify the timer that controls watches master timer. So I put in the order, rewrote the timer code (which I go into detail below) and modified the date files to keep track of sol’s rather than days.
So lets dive right in.
First off, if you want to develop, you will need to download Code Composer Studio (http://processors.wiki.ti.com/index.php/Download_CCS ) which will come with the default watch firmware (also available here: http://www.ti.com/lit/zip/slac341 ). If you just want to flash the watch with the mars watch firmware scroll down to the “Firmware:” link and follow instructions below. So anyway, the processor on the watch is based on the TI MSP430 and has several timers. The default program (ez430_chronos) that keeps track of the time is located in clock.c, clock.h, timer.c, and timer.h. The first thing we need know is that the clock source is a 32.768khz internal crystal. This internal clock is connected to Timer 0. The code in the function void Timer0_Init(void) found in timer.c configures the timer to count continuously up to 32768 (TA0CCR0 register) which takes exactly 1 second to reach. Once the timer reaches 32768 it triggers an interrupt which calls the function void clock_tick(void) in clock.c which takes care of the clock logic (when to increment hours, minutes, and seconds). Since the Sol is 24 mars hours the logic will remain the same and we will mess with the timer that triggers the mars second. What we want is the timer to go off every 1.0274912510416665 earth seconds so that it would be the equivalent to 1 mars second. So you essentially want to scale up and count that extra 0.0274912510416665 earth seconds. Which means you need to increase the TA0CCR0 register value. This requires some really simple math:
Here we do some basic scaling and discover the new TA0CCR0 register value to be 33668.83… but we have a problem now.. the register isn’t a decimal value it’s a 16bit value. So that means we can either choose 33668 or 33669 to count to. So I decided to calculate the error for each value, expecting less error if I went with 33669. The error for 33668 is losing 1 mars second every 0.4 Sols and the error for 33669 is gaining 1 mars second every 1.3 Sols. Makes sense since 33669 is closer to 33668.83 than to 33668. So I began to wonder how bad does this drift really become? To drift 1 mars minute it would take about 78 Sols and to drift 8.57 mars minutes would take about 1 martian year (approx 668.6 Sols).
As for calculating Sol, I modified date.c and date.h so that when 24 hours is reached it increments 1 Sol rather than day and month. The Sol is displayed below the time. The Sol tracking works just fine but the back end code is a little messy so I will clean that up asap.
After some testing and comparing against the mars24 and mars clock programs I concluded that the clock drift isn’t too bad and could easily be changed by going into the time set menu by holding the “*” button. You can also set the Sol by holding the “#” button. Worst case, 2 years from now you may get 5 minutes late to something if you relied on the watch.
This all took me about 5 hours to figure out, write, and test. Plus another hours to write this blog. The code is not very complete, but is a work in progress. I would say that it has the essentials to a mars watch, and that the bells and whistles will come late. In the coming weeks I will try to see if I can build in some compensation for the drift or modify the timer some how to get a more accurate reading. I will also clean up the sol code and make it so that you can track both earth and mars time in one watch. I figured it’d be nice to get the code out there so others who want to modify their watches into mars watches can do so.
UPDATE: Jon Hollander made a comment on hackaday with a very elegant solution to loosing that 0.833 in 33668.883. Rather than just picking 33669 and dealing with the loss of 0.166 he recommended switching between 33669 and 33668 until you average 33668.883. Turns out if you replace the TA0CCR0 += 33669; in Timer.c with the following code below you can greatly increase the accuracy. The code below will count 33669 5 times then 33668 1 time thus averaging out the counting to 33668.833. Hooray for minimizing error!
To upload the firmware you can select the firmware txt file and upload it using the Chronos Control Center software that comes with the watch or download the software here http://www.ti.com/lit/zip/slac341 . The connection is established through the USB wireless access point (included with the watch).
3) Click “Unlock Bootloader”, Select “All Other Supported Models”, then click “Begin Unlock Bootloader”, accept everything and get to page 3 where you have to input the Token, leave this window open.
4) Connect your ninja phone to the computer, and run the “One V 1.1.exe”
5) Select “3. Get Token ID”, click “Go”. This will get the Token for you, right click on the cmd and select “mark” then select all of the token, this copies the token (instructions are given during the “Begin Unlock Bootloader” process). Close the cmd.
6) Go to the htcdev site where you should have window open to page three, and paste in that tokin into the field, click “Submit”.
7) You will receive an email with the “Unlock_code.bin”, download and move that file into your data folder (/One_V_All-In-One_Kit_v1.1/Data/)
8 ) Run the “One V 1.1.exe”, Select “5. Unlock Bootloader”, click “Go”. Then select yes (select with volume button, press power to OK it) when prompted for unlocking the bootloader. You should see this:
9) This voids your warranty.. lol?
10) Congrats, you’re unlocked!
Onward to Backing up:
1) Put a microSD card inside
2) Open up ”One V 1.1.exe”, Select “ClockWorkMod”, Click “Flash Recovery”. This will replace a part of the recovery partition on the phone allowing you to use the tool to recover the phone.
3) Once that’s done, the phone will automatically reboot. Mine froze up when rebooting, but after holding the power button and resetting it it was fine.
4) Open up ”One V 1.1.exe”, Select “Boot into Recovery”, Click “Do Command”.
5) This will reboot the phone into recovery mode.
6) Look at the phone, the phone should have some options, select “Back up and restore”.
7) Look at the phone, once that’s done, it will give you a “Reboot” option, select that.
8) You’re done! Everything is on the sd card now!
You can feel free to screw around with the phone now. I’m not responsible for any of you screw ups
So aside from the hush hush projects, I’ve recently picked up a new project on the side that I can talk about
This project has been started at Nullspace Labs working along with charliex and mmca.
I’ve always wanted an army of loyal robots to follow me around.. what better than a 6 legged crawler!
The goal has been to create a new and simple hexapod design that can be easily laser cut and assembled in one night. Oddly enough I’ve been CAD and rebuilding one each night at NSL. The process from design, to cad, to laser cut and assembled can take about 4-5 hours.. which is just mind blowing fast.
Here’s a shot of the original design from CAD to real life prototype:
It’s crazy to see it come together so quickly.
Now, the prototypes design has several flaws.. For example the joints are very wobbly. So to help this I fit the servo mount into the acrylic body to make a tight fit. Then I brought the boards closer together to decrease the bending at the joints.
So with the design slightly improved I’m going to move on to making a much more sturdy base. The base is currently the most wobbly part. Once the base is fixed up I’ll be ready to add the electronics / servo controller. Lots to do, but I figured I’ll give a quick peak at one of the things I’ve been working on.
Gonna keep on prototyping.. more to come! I’ll post CAD files when the design isn’t changing every 5 minutes
Woo! Haven’t been blogging much since most of my recent projects have required me to keep quiet until they are done.. it sucks not to be able to share a lot of what’s going on
Anyway, with more to come I thought I’d share a recent project that was completed within a few hours of tinkering and hacking.
But first a quick back story, I had the great pleasure to be running the Hardware Hacking Village this year at Layerone 2012 along side with Krs, Charliex, and Mmca of Nullspace Labs. Layerone is a security conference that covers everything from computer security to lockpicking and hardware hacking. Each year since last year, Layerone has had electronics badges and has provided a working space for attendees to build and hack their badges. What happens is we pretty much pack up most of our equipment at the Nullspace Labs Hackerspace in Downtown LA and bring it down to the conference. This year we had 12 metcal solder stations and 10 microscopes along with many tools such as heat guns and tweezers to help you build and hack your badge. Charliex, Krs, and Mmca spent the last 2 week designing, revising, ordering, testing, and building them (along with some help of a few NSL members, fiances, and myself). With only 4 hours and 45 minutes left to spare, we all arrived at the Layerone hotel at 4:15am.. good times.
This years badge was a bullet proof pcb that was half an Arduino and half an RC car controller (with traces running between them allowing you to control it with the Arduino). When you bought the kit to populate the boards you also received an RC car which you could interface with your badge. I felt that human control was fun, but thought it would be awesome if my badge could just follow me and avoid obstacles so I wouldn’t have to carry it around my neck
I, knowing ahead of time what the badge would be, decided to order a few parts a week in advance so when I had some time I could build and hack my own badge. I should note that there was a badge hacking competition held at the conference, and very fairly, I was disqualified due to prior knowledge no problem though, I have an awesome car that drives itself! I should note that you should check out Charliex’s blog which has a much more in depth write up about the badge hacking competition. Mad props to Jason who made a morse code keyer and Funsized who made an EL-wire/IMU based badge.
What I decided to make was an autonomous car that would use the badge as a base/brain, the car as the controls, and the ultrasonic sensor on top of a servo for finding and avoiding obstacles.
I ended up naming it “Stanley Jr” after the notorious “Stanley” DARPA Grand Challenge car built by Stanford’s team. I will take this moment to note that if you are a GoogleX Labs employer (or know of one) and are looking for someone madly obsessed with self-driving cars to work on your team, I will gladly send you my resume I build robots too!
So between helping others build their badges for the con, I was able to piece together the hardware in under an hour. After some troubleshooting I had a non-continuous hour of coding. The results aren’t great by a long shot when it comes to autonomous vehicles, but I do plan to improve the code and make Stanley Jr smarter. As of right now, the ultrasonic pans in three positions, left 45deg, center 90deg, and right 135deg. Since the steering is practically trianary (left, center, right) I figured it’d be best to sweep the three directions it had available, move a small step, and then repeat. After solving a few bugs and fixing other peoples badges I had some working code. The goal the vehicle is given is to drive in the direction in which it sees the furthest distance. If the distances on all three options is too small, it will not make any moves to avoid accidents. Improved code that is currently in the works has a mode where it backs up in the direction it came in and then picks the alternative direction from that previous move.
The proper way to go about this control system would be to have a smooth sweeping of the ultrasonic sensors to obtain a more accurate model of the world. The car would then be given the goal of “drive forward and don’t hit anything”. Then rather than “sweep, stop, think, act, repeat”, it would be constantly moving at a regulated speed based on how far it can see. Once objects to its center get close it will pick the furthest distance out and go in that direction with the intention to return to wheels center. So lots to come
Stanley Jr is pretty stupid at this point, but not bad for about 2 hours of work. I plan to drastically improve the code and eventually move to a wheelchair base system that can drive around a beer keg delivering beer to bystanders while using a Microsoft Kinect to both recognize people and avoid objects.
Here’s a video and few pictures of the car:
Be warned, I wrote this code in a rush, it’s no where near complete or smart. Here’s the code:
I made a really quick hack while back where I replaced the terrible battery connector they use with a deans connector (http://www.wsdeans.com/products/plugs/ultra_plug.html). So now I can connect the helicopter batteries I have lying around. It allows me to put in higher mAh batteries for longer flight time, which is always good
For the past few weeks the Nullspace Labs hackerspace has been holding a gaming night every Thursday starting 8pm. The games range from some of the most modern games such as Starcraft II to some of the oldest games in existence such as Go. The first night was a great hit, we had a Starcraft II tournament resulting in much friendly yelling and exciting matches.
Interested in joining the NSL Gaming Night?
It’s simple, just show up! Bring your laptop, power brick, and game face.
Before I start, I’d like to note that this is my first reverse engineering project.
So the story here starts with me taking a class that required me to purchase one of these iClicker’s ( http://www.iclicker.com/Products/iclicker/ ), otherwise I wouldn’t get “participation” points in class :/ So I purchased one and booted it up during lecture to “participate”. It was neat to see some tech in the classroom, but the material wasn’t any more interesting, so I decided to tear this thing apart… I busted out my utilikey and tore it apart mid-lecture.
At this point the professor noticed all the students were “participating” except me. She then walked up to my desk and noticed the iClicker completely torn apart and asked “What are you doing?” to which I responded “Opening this thing up..” and she responded with ”This is not apart of the lecture, you shouldn’t be doing this in class. This is very important you should be paying attention.” I figured it’s time to protect my grades so I said I would clean it up right away, and did so.. (unhappily)
I snapped a few shots of the tear down before doing so..
Here we see the Buttons “A” ”B” ”C” ”D” ”E” and “ON/OFF”.
I later got to my setup at Nullspace Labs ( http://032.la/ ) and soldered on a 6pin header for the ICSP line. Then connected my AVR Dragon and attempted to dump the firmware and EEPROM from the ATMega8A with an external power supply connected to the power leads for the battery. As soon as I attempted the read, the iClicker reset itself. So I figured the power management must be doing some funky things, so lets by pass all that and go directly to the ATMega8A’s VCC and GND line. I soldered on some kynar wire to pin 4 (vcc) and pin 5 (gnd) and attempted the read again..
Success!! The security bit was never set! So now that I could communicate with the chip, I decided dumped the firmware and EEPROM. (Reversing in IDA to come in Part 2)
At this point I realized the hardware ID must be in the EEPROM, so I went exploring looking for “3300B586″ which is the hardware ID written on the back of the device:
I noticed at line 0 column A the sequence “3300B5″, huzah! At this point I could just modify this and change the hardware ID of the iClicker!
Next I decided to listen to the communication between the ATMega8A and XE1203F by sniffing the SPI bus, following the datasheets I soldered up some wire to the SPI lines. Once the wiring was done I used my handy AnnaLogic to sniff the SPI bus.
Once I powered up the iClicker (note: it’s not connected to an instructor machine) I began the sniffing and pressed the following sequence of buttons: A B C D E . I noticed that there was only data on the Slave Input lines, which makes sense since there is no instructor machine to send data back. Between each button I pressed only one byte was changed, and it doesn’t seem to be as intuitive as ‘A’, ‘B’, ‘C’,'D’,'E’. Instead A = 177 (0xB1) , B = 181 (0xB5), C = 189 (0xBD), D = 190 (0xBE), E = 186 (0xBA).
Next I need to capture some traffic between my iClicker and the instructor machine to see a full cycle of registering the iClicker to the instructor machine, voting and receiving confirmation that the vote went through.. I’ll leave that for Part 2.
Please note that I will NOT be doing this packet capture in the classroom (it’s no place for learning anyway), I’ve decided to purchase an instructor base station to prevent any issues with my school. Plus it gives me control to test and try out things I normally wouldn’t be able to do.
For the mean time I need the clicker for lectures so I’ve poked a hole into it.. totally looks normal
Next up.. reverse engineering the firmware in IDA, stay tuned for Part 2:
So far the only defeat has been spoofing other iClicker hardware ID’s by reprogramming the EEPROM (thankfully iClicker never set any security bits ) It’s not much yet, but next up is to reverse the firmware and figuring out how the packets are sent, handled and then to create a new firmware with some extra features. A few new features I’ve thought of are listening in to other iClickers, submitting and spoofing as other iClickers, and making a general purpose ISM band radio.
So a few weeks ago Nullspace Labs got an old pick’n'place and decided it was time for a renovation with much newer technology. Charliex and mmca for the past few weeks have been working non-stop on rebuilding this thing. It went from a busted old computer running CP/M with “ok” precision to a higher precision, computer control/vision machine which controls the pnp with an Arduino! Charliex’s blog explains the process it has gone through is great detail (it is a must read): http://charliex2.wordpress.com/tag/juki/
I have been fortunate to have had a small role in this project by drafting up/CADing some of the new parts designed by mmca for the machine! Here are a few pictures from the Solidworks files for what is to come!
Here is a plate with an adjustable height where components are placed for the pnp to pick them up!
Here is the new head plate adding the capability of 360 component rotation, camera mount, and a pneumatic solder paste applier!