Well, the firmware's finally done. Bill asked to see the source code, so here it is. Floating around in the blogosphere just for you. 1,000 lines of unadulterated, partially-commented assembly language: TableCode.doc
Next step: soldering the boards! Once we wire up the boards we can finally start integrating the electrical and mechanical systems, which means we'll actually be able to use the iButtons to activate the sliding platforms. Get excited!
PK
Saturday, August 25, 2007
Wednesday, August 22, 2007
Sup Fresh? It's our turn baby.
Man, no updates in a week and a half. Guess we lost all our loyal readers... hahaha. Good one, Chris.
Work did slow greatly with Paul out of town much of last week/weekend. We're at the point where we either need his electronics expertise or two sets of hands to complete most tasks. We've still made progress, see pictures.
Mounted the motor into place. This took a while to get all lined up and everything, but it fits well and works great. PS, I'm too lazy to rotate that picture 90 deg clockwise, but imagine it. When driven, the motor pulls down on the rod long enough to pull the pins and release the sliders. It is then returned to the up position.

This is what the inner part of the table looks like. Our initials spell out an acronym which is so nerdy I can't even come to say it here. After finishing the letters (which Paul beautifully painted by hand), we have applied many layers of polyurethane finish to give it water proof (and shiny!) protection.

We also are in the process of adding oak tops to our sliders. This will make them look a lot nicer, and also bring the slider surface closer to the bottom of the table. We've been debating what to put on the sliders, here is a short list of ideas: painting swords/dragons/shields/other cool round table junk, staining to look like top surface, allowing people to paint random shit on there when they come over, hobbes references or anything else. Thoughts?
Much of the work has been on getting the electronics up and running. We're getting it all wired on protoboards before making anything permanent, and we've made good progress. Just hammering out small issues with the code now.

Paul said he'd post the code at some point, stay tuned. Also, if you know of where we could score some cheap rings, let me know.
Work did slow greatly with Paul out of town much of last week/weekend. We're at the point where we either need his electronics expertise or two sets of hands to complete most tasks. We've still made progress, see pictures.
Mounted the motor into place. This took a while to get all lined up and everything, but it fits well and works great. PS, I'm too lazy to rotate that picture 90 deg clockwise, but imagine it. When driven, the motor pulls down on the rod long enough to pull the pins and release the sliders. It is then returned to the up position.
This is what the inner part of the table looks like. Our initials spell out an acronym which is so nerdy I can't even come to say it here. After finishing the letters (which Paul beautifully painted by hand), we have applied many layers of polyurethane finish to give it water proof (and shiny!) protection.
We also are in the process of adding oak tops to our sliders. This will make them look a lot nicer, and also bring the slider surface closer to the bottom of the table. We've been debating what to put on the sliders, here is a short list of ideas: painting swords/dragons/shields/other cool round table junk, staining to look like top surface, allowing people to paint random shit on there when they come over, hobbes references or anything else. Thoughts?
Much of the work has been on getting the electronics up and running. We're getting it all wired on protoboards before making anything permanent, and we've made good progress. Just hammering out small issues with the code now.
Paul said he'd post the code at some point, stay tuned. Also, if you know of where we could score some cheap rings, let me know.
Sunday, August 12, 2007
Another Post?
That's right, another table post. Still no videos, but wait for it. We (Paul mostly/entirely) fixed the code this afternoon with the help of an oscilloscope, all the timing was off by a factor of 2. Nerd Alert!!!
These first two pictures show the latch system we have on the inside. The sloped piece in the middle is pulled down by the circular pins to release the sliders. A rod will be attached between the two pins so that they are pulled down by the motor in unison.


This is a shot from underneath the table, with the slider all the way in. You can see the extension spring is under tension and ready to deploy. If you look closely, you can see other holes on the bottom of the slider. This is from where we tried to mount the spring before choosing this location. This spot was ideal because it extends the spring as far as possible without permanent stretching, and also doesn't lock the spring out when it is all the way compressed (as happened with the set of holes on the far right). The spring doesn't extend the sliders the full 24" of travel because the spring pivots and hit the 2x4 support (half painted black). We decided this isn't a big deal, and the users can pull the sliders the additional 2" to fully extend the sliders.

This is me taping off and painting the divisions on the undersurface of the table. You can see the holes for the ibutton readers all ready to go. Paul should be painting initials into the sections later to complete the painting of this part of the table.

I'm sorry, but come on... look how cute he is. We're currently trying to figure out ways to put a Hobbes reference into the table. Either with painting a reference into the crest, or something else. We'll see.
These first two pictures show the latch system we have on the inside. The sloped piece in the middle is pulled down by the circular pins to release the sliders. A rod will be attached between the two pins so that they are pulled down by the motor in unison.
This is a shot from underneath the table, with the slider all the way in. You can see the extension spring is under tension and ready to deploy. If you look closely, you can see other holes on the bottom of the slider. This is from where we tried to mount the spring before choosing this location. This spot was ideal because it extends the spring as far as possible without permanent stretching, and also doesn't lock the spring out when it is all the way compressed (as happened with the set of holes on the far right). The spring doesn't extend the sliders the full 24" of travel because the spring pivots and hit the 2x4 support (half painted black). We decided this isn't a big deal, and the users can pull the sliders the additional 2" to fully extend the sliders.
This is me taping off and painting the divisions on the undersurface of the table. You can see the holes for the ibutton readers all ready to go. Paul should be painting initials into the sections later to complete the painting of this part of the table.
I'm sorry, but come on... look how cute he is. We're currently trying to figure out ways to put a Hobbes reference into the table. Either with painting a reference into the crest, or something else. We'll see.
Alright, I've been called out...
It's true, I haven't visited this site until now...sorry about that. Gotta say I'm impressed now that I've finally read through it though. Really does justice to all the hard work behind the magic. Hopefully with his thoroughness and inspirational storytelling Chris has somehow managed to whet your appetite for an inside look at the hardware and firmware that make up the electronic subsystem - or what I like to call the Serial User-authenticated Power Ring Identification System (SUPRIS). If not, come back later and hopefully I'll have a picture up.
Overview:
The main goal of the electronic subsystem is to communicate with the iButtons and release the sliding platforms when all five iButtons have been locked in. It will be battery operated so that the table doesn't have to be plugged in and it can be switched to manual mode so that the sliders can be released with the push of a button in the event that one or more of the iButtons are missing.
Hardware:
The core of the electronic subsystem is a PIC 16F690 programmable microcontroller. In a small dip package, this bad boy packs a shit-load of features including 15 I/O ports, which is enough to cover our 5 iButton data lines, 5 output LEDs, motor driver, manual override switch and release button inputs. The I/O pins can source or sink 25mA, which is enough to drive our LEDs directly. And since it was a leftover from an old project, it also has a nice little board with a 5V regulator and Molex connectors all wired up.
The PIC extracts the serial number from the iButtons via one line serial communication. It issues commands by raising or lowering the data line for precise periods of time as brief as 15 microseconds. Once the iButton has been initialized, it reports its unique 64 bit serial number one bit at a time.
The motor that drives the spring-loaded latches is a small geared DC door lock motor that you might find in a small car. It is controlled via a half-bridge motor driver chip.
Power for the electronic subsystem is provided by a 7.2V rechargeable NiCd battery.
Basically, we don't have to do to much design on the electronics. We've got all the pieces and we don't need any fancy circuits - it's just a matter of testing it and wiring it up.
Firmware:
The one major downside of most low-cost PICs is that they must be programmed in assembly language. Once you get used to it, assembly isn't that bad, but it's definitely more time-consuming than programming in C. In any case, the firmware for the microcontroller was designed using the classic "events and services" structure. What that means is that after some initialization, the microcontroller runs continuously through a loop in which it checks to see if a new event has occurred (new iButton detected, input switch flipped, timer expired, etc.) . If there is a new event, then the microcontroller services the event depending on the "state" that it's currently in and continues checking for new events. In our case the state diagram is really simple - basically just two main states: Manual Mode and Waiting for Rings.
All the real complexity of the code is associated with the iButtons. They need a pretty precise, clean signal before they'll talk. I have old code that successfully communicates with the iButtons, but it requires fine tuning to accommodate the changes in our hardware and code. So for now, I'm pretty much stuck until I can get access to an oscilloscope.
That's the story. I can't wait till it's done so we can start integrating the hardware with the table itself. Come back soon for pictures.
PK
Overview:
The main goal of the electronic subsystem is to communicate with the iButtons and release the sliding platforms when all five iButtons have been locked in. It will be battery operated so that the table doesn't have to be plugged in and it can be switched to manual mode so that the sliders can be released with the push of a button in the event that one or more of the iButtons are missing.
Hardware:
The core of the electronic subsystem is a PIC 16F690 programmable microcontroller. In a small dip package, this bad boy packs a shit-load of features including 15 I/O ports, which is enough to cover our 5 iButton data lines, 5 output LEDs, motor driver, manual override switch and release button inputs. The I/O pins can source or sink 25mA, which is enough to drive our LEDs directly. And since it was a leftover from an old project, it also has a nice little board with a 5V regulator and Molex connectors all wired up.
The PIC extracts the serial number from the iButtons via one line serial communication. It issues commands by raising or lowering the data line for precise periods of time as brief as 15 microseconds. Once the iButton has been initialized, it reports its unique 64 bit serial number one bit at a time.
The motor that drives the spring-loaded latches is a small geared DC door lock motor that you might find in a small car. It is controlled via a half-bridge motor driver chip.
Power for the electronic subsystem is provided by a 7.2V rechargeable NiCd battery.
Basically, we don't have to do to much design on the electronics. We've got all the pieces and we don't need any fancy circuits - it's just a matter of testing it and wiring it up.
Firmware:
The one major downside of most low-cost PICs is that they must be programmed in assembly language. Once you get used to it, assembly isn't that bad, but it's definitely more time-consuming than programming in C. In any case, the firmware for the microcontroller was designed using the classic "events and services" structure. What that means is that after some initialization, the microcontroller runs continuously through a loop in which it checks to see if a new event has occurred (new iButton detected, input switch flipped, timer expired, etc.) . If there is a new event, then the microcontroller services the event depending on the "state" that it's currently in and continues checking for new events. In our case the state diagram is really simple - basically just two main states: Manual Mode and Waiting for Rings.
All the real complexity of the code is associated with the iButtons. They need a pretty precise, clean signal before they'll talk. I have old code that successfully communicates with the iButtons, but it requires fine tuning to accommodate the changes in our hardware and code. So for now, I'm pretty much stuck until I can get access to an oscilloscope.
That's the story. I can't wait till it's done so we can start integrating the hardware with the table itself. Come back soon for pictures.
PK
Saturday, August 11, 2007
Welcome to the China Club
Sorry faithful blog followers for taking so long to post. Part of the reason is that we spent the first half of the week waiting for parts to come in the mail, the other reason is that I have misplaced my camera. I'll give a brief rundown of progress and then find my camera to put up pics and vids. Yes, you got it right, videos. Videos imply dynamics, and we've got some pretty great dynamic motion right now.
We attached latches to the the sliders so they will stay locked in when they're not in use. Why would they have to stay locked in you might be asking? Because the sliders are now attached to springs that propel them outwards if not latched down. This whole system took a long time to get in place because the springs can be a little finicky and "lock" if not positioned correctly. This will all make more sense with pictures, I promise. The motor mount is almost all the way done, just have to cut some all-thread to use as attaching bolts.
We also attached the two particle board pieces together with brackets. This enabled us to begin painting that surface. It's white, with black radial arms dividing the space into 5 parts (1 for each ibutton). Each section should have initials to identify which ibutton is which.
Paul has been plugging away at the code and electronics, all designed to read the ibuttons and drive the motor. I would love to give an accurate description, but I don't know what the hell he has been doing. All I know is he's mostly done and now debugging the code. He can feel free to write an electronics update anytime he wants, but since I'm pretty sure he has never visited this site, I doubt that will happen. Prove me wrong Paul, prove me wrong.
Boomslam.
We attached latches to the the sliders so they will stay locked in when they're not in use. Why would they have to stay locked in you might be asking? Because the sliders are now attached to springs that propel them outwards if not latched down. This whole system took a long time to get in place because the springs can be a little finicky and "lock" if not positioned correctly. This will all make more sense with pictures, I promise. The motor mount is almost all the way done, just have to cut some all-thread to use as attaching bolts.
We also attached the two particle board pieces together with brackets. This enabled us to begin painting that surface. It's white, with black radial arms dividing the space into 5 parts (1 for each ibutton). Each section should have initials to identify which ibutton is which.
Paul has been plugging away at the code and electronics, all designed to read the ibuttons and drive the motor. I would love to give an accurate description, but I don't know what the hell he has been doing. All I know is he's mostly done and now debugging the code. He can feel free to write an electronics update anytime he wants, but since I'm pretty sure he has never visited this site, I doubt that will happen. Prove me wrong Paul, prove me wrong.
Boomslam.
Sunday, August 5, 2007
Jason Bizzul, God Among Men?
Thanks for the comment Biz, it's nice to know someone cares. Ladies, for those who care, Jason is a strikingly handsome Chindian fellow with a knack for pleasing. Jason asked for pictures, and I'm happy to oblige.
This shows how our frame changed after the redesign. The wood colored parts are where we took off the long platforms that the bottom-mounts would have attached to.

The next two shots are of the same thing, just from two different angles. This shows the level issues that we had to deal with. The goal is to mount the extension drawers as high as possible, to make them as close to the bottom table as possible. As you can see in these shots, there will be a fairly large gap as it stands right now (~0.5"). You can see where we moved the long platforms, to the bottom of the frame. They don't really serve any purpose at this point, other than to provide stabilization. We moved them out slightly to butt them against the legs, which helps the wobble problem.


This is half of the bottom layer of the table top. The ibutton readers are going to be hidden under the oak crest, so a casual observer of the table will not know they are there. We drilled two holes of different diameters so the readers will sit perfectly flush with the top of the table, but their wires run from underneath. Looks pretty tight, eh?

Waiting for McMaster to ship us our springs so we can work more on the motor mount. Things are moving well.
This shows how our frame changed after the redesign. The wood colored parts are where we took off the long platforms that the bottom-mounts would have attached to.
The next two shots are of the same thing, just from two different angles. This shows the level issues that we had to deal with. The goal is to mount the extension drawers as high as possible, to make them as close to the bottom table as possible. As you can see in these shots, there will be a fairly large gap as it stands right now (~0.5"). You can see where we moved the long platforms, to the bottom of the frame. They don't really serve any purpose at this point, other than to provide stabilization. We moved them out slightly to butt them against the legs, which helps the wobble problem.
This is half of the bottom layer of the table top. The ibutton readers are going to be hidden under the oak crest, so a casual observer of the table will not know they are there. We drilled two holes of different diameters so the readers will sit perfectly flush with the top of the table, but their wires run from underneath. Looks pretty tight, eh?
Waiting for McMaster to ship us our springs so we can work more on the motor mount. Things are moving well.
Thursday, August 2, 2007
I wouldn't worry about it
No, seriously, just don't worry about it.
Paul and I spent a long ass time last night getting the extensions mounted into the frame. Initially we thought it would just take a bit of sanding. We sanded juuuuust enough off of one slider to squeeze it into place, but something didn't feel right. There was just too much friction in the sliders. Paul insisted (correctly) that this was due to the extension being too wide and compressing the sliders against the frame. So we sanded/jigsawed the extensions until they fit perfectly. This was a very iterative process that look a couple hours. Now the sliders are in and look fantastic. A little lube should have them ready to go.
Reconfigured the supports a little to try to cut down on some of the table shaking oscillations. The new configuration seems to have damped the motion, and we're pretty sure that when the table top is in place, the extra mass will help as well.
The next step is to work on the extension deployment system.... kinda wish we had a cool acronym for that. Submit something good.
Also, does anything I describe make sense if you can't see what I'm talking about? Make use of that little comment bar at the bottom. Go ahead, just try it.
Paul and I spent a long ass time last night getting the extensions mounted into the frame. Initially we thought it would just take a bit of sanding. We sanded juuuuust enough off of one slider to squeeze it into place, but something didn't feel right. There was just too much friction in the sliders. Paul insisted (correctly) that this was due to the extension being too wide and compressing the sliders against the frame. So we sanded/jigsawed the extensions until they fit perfectly. This was a very iterative process that look a couple hours. Now the sliders are in and look fantastic. A little lube should have them ready to go.
Reconfigured the supports a little to try to cut down on some of the table shaking oscillations. The new configuration seems to have damped the motion, and we're pretty sure that when the table top is in place, the extra mass will help as well.
The next step is to work on the extension deployment system.... kinda wish we had a cool acronym for that. Submit something good.
Also, does anything I describe make sense if you can't see what I'm talking about? Make use of that little comment bar at the bottom. Go ahead, just try it.
Subscribe to:
Comments (Atom)