[Sean] and his team at Adobe were asked to build “something new” for the Children’s Creativity Museum in San Francisco, so in several months they managed to build a digital/physical environment for kids called “Sense It”.
Part of this project involved designing and building a pressure-sensitive electronic floor which could detect if children were sitting, walking or running. As a camera based detection system couldn’t give them the type of precision they wanted, [Sean] decided to use pressure-sensitive resistors placed under MDF panels.
There are a total of twenty-one 2’x4′ tiles, each one including 8 pressure-sensitive resistors and an ATtiny84 based platform. All the microcontrollers digitize their 8 sensor signals and send their conversion results to a beaglebone over a shared i2c bus in a RJ45 CAT5 cable. As it is [Sean]’s first project, we will cut him some slack but several design mistakes have been made in our opinion:
- Using i2c instead of RS485 / CAN for long distance data transmission
- Digitizing the sensor voltages so far from them, as noise is added before the ADC
- Sending the +5V required by the ATtiny in the RJ45 cable instead of a higher voltage (which would involve putting an LDO on the platforms)
- Separating the digital and analog ground planes as the platform current consumption is low and transmission speeds slow
But the children who can now play with the complete system certainly won’t care. And you… what do you think of [Sean]’s work? Don’t hesitate to let us know in the comment section below.
Hey now, leave the nitpicking to the comment section Mathieu.
I tried to be light in my comments ;)
1) This is exactly why we have 485/CAN, so I’m also wondering why he choose I2C. However I2C does handle data flow control with multiple nodes on the first layer and allows the master to determine system reporting charastics. CAN/485 would take a bit more code on the slaves/master.
2) I looked at the pictures and the layout seems resonable for the slow sample rate (relatively speaking). Keeping the sensors closer to the boards = more boards needed, more logistics overall.
3) Good practice would lean to using a higher voltage and regulating it at each board, but as he says each node only draws 10mA I can see how he got away with it.
4) An example of when good practice is overkill, but if doesn’t hurt it why not?
You beat me to the punch. I2C is more than good enough for something like this.
Also why is the writeup passing so much judgement? Whatever happened to just presenting the project with a nice writeup. Flamebait.
“Also why is the writeup passing so much judgement?”
I actually like this new write-up style, though approach may need polished. Fosters discussions on design choices, which is always a discussion I like to be part of, and I think many projects featured on HAD lack the why in the build log. Like this one for example never said why he choose I2C. Even if not to satisfy my own curiosity, a healthy discussion on design choices can also serve to educate the (non-formally educated ) hobbyists in the readership.
But as always the trolls can ruin the party and discussions like this usually attract their kind.
You make a good point, and I don’t disagree. Re-reading the summary, I think this is where I got annoyed:
“As it is [Sean]‘s first project, we will cut him some slack but several design mistakes have been made in our opinion:”
“Cut him some slack”? harsh. “several design mistakes” says who?
It could have at least been softened:
“As it is [Sean]‘s first project, we think he did great. We can think of a few ways this could be improved for the next revision. Here is a list of our thoughts:”
Not sure I would want to submit a post if HaD is going to demolish it for “design mistakes”. Maybe they would cut me some slack too?
Enough. This is a fine project and Sean did a great job. Sean, you da man, no matter your “mistakes”. Pat yourself on the back my man.
Be cool, build cool things.
“It could have at least been softened:”
I agree with you too, which is why I said “though approach may need polished. “
Yes you are absolutely right. It is all about style.
I think this site is about encouraging as many as possible to engage ind hacking, tinkering and making.
I have a few projects on my desk that I have been thinking about submitting to this site. But when I read this article I felt like this site was all wrong for me. Where was the positive inspiring attitude?
I agree that it usefull to have discussions about alternate designs to inspire everyone. But it has to be handled with very gentle gloves.
This is a hobby site – or did I get it wrong? Therefore one can not assume that all project desicions are optimal. Many projects are the result of many hours of work, and is just about the best the hacker could do. Going public, and proudly presenting your results should not be scary. Pointing out details that could have been done differently really needs to be done with care, to keep the inspiring spirit alive.
– I really hope this was a one off, and not a pointer to the future of my favorite hacking website.
I would never see myself as a troll, but I need to say this, sorry (and I promise, it is actually not about trolling anyone). You said, you felt this site was all wrong for you. For me this site would be wrong, if all of its participants thought your way. My point is, that I really cannot imagine a true hacker in a very gentle gloves. Come on! There is always a risk, that your work may be unduly lowered to the ground, especially over the Internet. You cannot expect all the people to be gentle, you have to relay on your own self-confidence and resistance to the brutal world.
The fact, that Sean and his team got mentioned here is already a reason to be proud of. I would envy him the same, even, if there was a real devastation in the write-up. But there was just an opinion (as you probably see, I am not native English, so I cannot really say if it was unpleasant or not). Anyway, plenty of people around the world had a pleasure to see his job, he has the pleasure of his job being discovered by people.
I understand all your intentions, however this kind of feedback (even if its harsh a bit) is really much more meaningful than just over-sweeten hints. It simply means that somebody got through the details, thought about it and helped by revealing possible improvements, all this instead of simple “WOW” or an bald report. I would even say, that over-sweeten Hack a Day would be LESS encouraging than the harsh one. It is a basic instinct, that you are afraid to be pointed out as bad one within all the perfects. And in the end, what is the coolness and pleasure of being warmly praised if exactly each one is?
But it is just me and please do not feel offended! I simply prefer the straightforward “oh man, nice, but you screwed >thatthis< way next time", than "hey! this is waaay more then awesome, however if you don't mind, I would be honoured to say something".
So sorry, something went wrong in the last paragraph. It supposed to be: (…) I simply prefer the straightforward “oh man, nice, but you screwed _that_ up, you gotta do it _this_ way next time” (…)
@Filip Jaskólski
As long as the message is the same, diplomacy is better than being a blunt asshole. “I believe such-and-such would be a better solution,” is always better than saying, “You dun screwed up: this is what you should’ve done, newbie!”
Yeah, I think it’s mainly a style thing. There’s a way to frame an opinion piece, even a scathing one, without presenting yourself as the dispenser of ultimate judgement, without assuming the mantle of teacher and offering your lessers the gift of your expert eye.
Criticism is good; condescension is not.
Blue Footed baby, eloquently put.
For those of us with minimal knowledge on these subjects and also an insatiable appetite to learn them, the criticisms are AWESOME. I was shown the practical differences between the various options. I even learned about an LDO (low-dropout regulator). I don’t know exactly what it is, but now I know it exists.
ALWAYS encourage and embrace constructive criticism. This was not nitpicking, it was extremely helpful.
Exactly. I have a project that uses ATtinies in a similar way and never considered power drop out on the grid. The crticism, however, harsh taught me something new.
I’ve implemented an RS-485 RTU stack for ATmega processors with MAX485 converters, and it works fine for ATmega168 and 328 processors. I tried porting it to an ATtiny85 and ran into problems. I think the code is too large as it stands. I don’t doubt that a less-general pared-down interface could be made to work with the Tinies.
Interesting to know. Is the stack source available somewhere?
Since it’s from Adobe, I’m surprised the kids don’t have to rent each footstep.
I can only imagine the smiles when “You need to upgrade your floor” is presented with every step.
I agree with Ginge, seems like the Author hasn’t been laid in a while or somfin.
His “Opinion” is just that, Opinion. An equally as valid “Opinion” would be creative use of available resources without over-engineering.
it highlights other options that the less-informed of us may consider when embarking on our next project. It’s actually very helpful.
Helpful and obnoxious aren’t mutually exclusive.
Regardless of whether or not the best possible implementation was used, it’s a completed project!
It’s more impressive than ten technically brilliant projects still on a drawing board somewhere.
good work. But rather than a variable resistor, I’d have used some tinfoil with foam between it, for a kind of capacitive sensing.
I’ve figured out a pretty simple way of offloading a fair bit of the work of a capacitive sensor into pretty simple hardware built from 3 discretes- shouldn’t be difficult to dead bug. In addition it also protects the uC from certain bad habits that capacitor sensing can exhibit.
each sensor module has 2 connections. Signal is sent as an active low on the power connection somewhat akin to that of the one wire bus. so I’d call those two lines sig and ground. Sig connects to PUT’s gate via a diode. sig connection to PUT’s anode via main timing resistor. PUT’s anode to capacitor +. capacitor’s negative terminal to PUT’s cathode. PUT’s cathode to ground. you need to play around with the component values to see what works.
To get the module running. connect the variable capacitor up to the PUT module, and sig to +5V via a weak pull up. and ground to 0V.
when circuit first powered, the signal line rises pretty sharply towards 5V as there’s not much current draw. The main timing resistor begins to charge up the sensor cap. The LED provides 5V minus the LED’s forward voltage onto the PUT’s gate, and the PUT don’t conduct until the anode exceeds that voltage, by a threshold. I’ve used an LED fr the diode because I thought it would be nice to have a visual indication that the circuit is working, and I’ve found the different voltage drops for different colour LEDs to be pretty useful.
As soon as the PUT triggers the resistance between gate and cathode drops to very low levels, allowing (the pull up limited) current through the LED, and discharging the the tiny capacitance of the signal line, dropping the signal line’s voltage. At the same time the voltage across the timing capacitor is discharged. But once the difference between the PUT’s gate and anode falls below a threshold, the PUT ceases to conduct in any way, and the gate voltage jump back up for the cycle to repeat.
Anyway that means the voltage on the signal line exhibits sharp dips at a frequency controlled by the timing resistors and capacitor value. Like all digital signal’s it’s the dip rather than intensity that conveys the information, and so as long as that dip remains intense/wide enough to be detected the actual wire length shouldn’t matter too much
By connecting the signal line to a single uC input pin it’s then possible to measure the period between pulses on the sig line.
It’s also possible to share a uC between several sensor modules, making for slightly more efficient use of uCs but then it’s probably not the best idea to use internal pull up,. If all PUTs happen to discharge at the same time the total current draw from the pins might be excessive.
This would be a cool idea for a safe.. for example: stand a certain way + enter correct combo to open
Obligatory: http://youtu.be/r9vQOreB2SQ?t=7s
Precisely!
As for the criticism included, as always, take a deep breath and recite the Bene-Gesserit benediction against project trolls:
The simple project that I could build and did will always be better than the perfect project that you could have built, but didn’t.
Does it work? Yes? Then mission accomplished.
Maybe next time you guys can do the work and make it perfect.
I think HaD could use a role reversal once in a while. Have the
“Editors” do their R&D and present their own project and let others
critique them and see how the fare.
Great idea! I hope they don’t require Flash or some other proprietary Adobe software to put it to good use.
Interesting project some things I don’t fully understand.
I am running attiny85’s on a 25 meter long I2C bus (Cat5) cable without any amps or extenders. I can understand it’s needed in most case, if you sent larger volumes of data, or that’s my assumption really.
With the attiny’s you would have 4 ACD ports to use for the 4 sensors not sure why he needs 4 attiny’s for this.
I’m only using 1 ATtiny per board. The other chips are the MUX and op-amps.
Hey all – Thanks for the feedback. Quite frankly, I don’t mind the constructive criticism and won’t take it personally. In fact, I welcome it because it will help me learn a few things for future projects. I’m a software developer by profession, and an electronics hobbyist only. I don’t claim to know what I’m doing when it comes to this kind of project :) If you look through my previous projects, they’ve mostly been nixie and numitron clocks and other digital things that are relatively straightforward builds with plenty of prior examples to draw from. The floor was unexplored territory for me.
But the floor does work well and has been running for a few weeks already with constant uptime and no problems. I’d call that a success! The real challenge with this project was taking the data and doing something interesting with it in software.
To address the various concerns:
1) I’d never heard of 485/CAN until today, so I’ll read up! Why I2C? Because I knew it would work (I’d researched and found people using it up for distances far longer than mine ~100m) and because it would be easy to implement and I knew how to do it.
2) Digitizing the voltages close to the sensors would’ve been too complex given their 1′ spacing. At 168 sensors this would’ve involved a lot more additional assembly than I would’ve liked.
3) Probably should’ve put higher voltage on the cable. I admit this was a rookie mistake – fortunately current draw was low enough that it was a non-issue, but a few more tiles and I think it would’ve become a problem.
4) “Separating the digital and analog ground planes as the platform current consumption is low and transmission speeds slow” Can you explain why this is a problem with low speeds? Why is this ever a bad idea if it can easily be done?
If you goes beyond the I2C spec maximum capacitance of 400pF (due to
lengths of wiring), you might need to run the I2C bus at a slower speed,
increase pull up current or partition the bus.
I2C does have problems of locking up if the slave decided to pull down
the dataline and crashed as it is a shared bus, so partitioning the bus
is what you should look into for a large and “critical” design.
At a slower speed and low current, you actually have less of issues with
ground bounces etc. The person that say otherwise have some serious
explaining to do.
As for the practice of partitioning ground etc., there are no definite
answers. Our group had worked with non-partitioned ground on multilayer
PCB. We had a very dense PCB that have critical 3GHz signals on same
ground plane as the rest of the digital circuits. We spent a lof of time
looking at the eye diagrams and it works fine.
I have also measured and documented conductive EMC issues because a
different group like to partition their grounds, but failed to do it
correctly on one board. In doing so, they actually forced the ground
return path to go the long way and picked up noise from the power
supply. I gave them the before and after measurements of joing the
ground at the right location which allowed the return current to bypass
the area. That was a lot more specific than their EMC “expert” general
list of “good practices”.
My experience tell me:
1) Good solid unbroken ground (and ground planes) if you can do so.
2) Partition ground if you don’t have solid ground planes and you really
understand how current flow and its corresponding return path works.
3) Half ass effort can make a design worse if you don’t understand the
why and how.
#2 can be better _ONLY_ if you know what you are doing.
“If you goes beyond the I2C spec maximum capacitance of 400pF (due to
lengths of wiring), you might need to run the I2C bus at a slower speed,
increase pull up current or partition the bus.”
Yes – this is what I did: partition the bus into 3 equal sections using I2C extender chips.
Thanks for the info on partitioned and non-partitioned ground planes.