Project Logs

Collapse

• Log 9: Time's up

  Arthur Admiraal • 09/14/2015 at 20:06 • 0 comments

  I will get straight to the point: due to spending a lot of time on my school research project and difficulties with this project, I've stopped working on the squidpad.

  Difficulties

  I have been unable to program the MSP430F5514 microcontroller using my launchpad. Due to this chip being amongst the first DFN chips I have soldered and my unfamiliarity with the code composer studio toolchain, I am unable to pinpoint the problem. The console reads "No valid device detected", and I'm not seeing any oscillation on either of the crystal pins.

  At this point, the problem may be any of the following:

  • A problem in my design. I tried as best as I could to follow the datasheet, but I could have easily made a mistake.
  • The pins not being connected correctly due to poor soldering. I have given them a visual check and re-reflown the chip, but all to no avail.
  • The chip being damaged because of high temperatures during soldering. I normally find IC's to be pretty resilient to excessive amounts of heat, but I may have pushed it too far when trying to solder it, as this was my first stencilled design.
  • A problem with my programming setup. I have tried using the Spy-Bi-Wire, even flipping the test and data pins, but I may have connected something wrong. Or perhaps, contrary to what I've read, this chip didn't come pre-programmed with the USB bootstrap loader, and it doesn't have the correct fuse settings.

  It would take quite some time to rule out all these factors, which is a constrained resource at the moment, because...

  School

  As I mentioned in the precious log, I am currently in my final year of high school. In the Netherlands, all high school students are required to do a research or design project to finish their school. I want to investigate whether the flow speed of an ionic solution has any effect on its specific resistance. This is fairly challenging to do, and because I want to do it properly, its sucking up a lot of my time.

  Because of this, I don't have the time to finish this project at the moment. That being said though...

  Going forward

  If I were to pick up this project again, I would make a breakout board for the TQFP version of the MSP430F5514. Then, I could rule out the soldering problems, as I do have experience soldering TQFP IC's. I could also more easily test and improve my design. Furthermore, different programming configurations would also be a breeze to set up.

  After gaining experience with that, I could either redesign the squidpad, or design the different submodules in a similar fashion. This would allow me to correct any errors in the design with ease, and be confident in the functioning of the final design.

  Conclusion
  

  Although this project may have ended, I still had fun doing it, and even learnt some things along the way. In particular, that experimenting with your microcontroller in advance is not that bad of an idea. I might decide to pick up this project again in the future. If I do, I will be sure to post an update here.

  In the mean time though, if you liked this project and happen to be interested in overly complex science projects, from looking for obscure effects on the specific resistance of ionic solutions to melting icecubes in hypergravity, you may want to have a look at my site.

  Thanks to anyone interested in this project, so long and thanks for all the fish!
  

• Log 8: I’m doing electronics and I’m still alive

  Arthur Admiraal • 08/27/2015 at 10:40 • 0 comments

  Look what just arrived last Saturday:

  That’s right: the final parts arrived, being the PCBs. I of course went to work immediately on soldering the prototype together. This was my first stencilled design, so there were some irregulaties during soldering, but after re-reflowing most of them could be resolved.

  I only had real trouble with soldering the connector for the e-ink display. In fact, I broke it in the progress. Luckily, I ordered two just in case. I have decided to wait with soldering this part until I have the microcontroller actually up and running, just to prevent my self from going insane because of one annoying connector.

  In the end I got the following result:

  Errata

  I found that the io-voltage of the e-ink power chip was hooked up to the raw input voltage of the system, and not the regulated 3.3V. As a consequence, the microcontroller could receive a relatively high voltage on its input pins, which could blow it up. Because of this, I cut the trace leading to it (in two spots for good measure) and soldered a bodge wire from the 3.3V output capacitor to the input capacitor of the chip.

  Also, some passives had a too small or too large footprint, or were to close together. Furthermore, some chips had too much solder paste on them. These faults in the PCB design were propably the main cause of the need to re-reflow a lot of stuff, having to sometimes wick up extra solder.
  

  Powering it up

  I have done a quick power-up test, feeding in an about 10mA current-limited 5 volt into the USB bus, and I measured the 3.3V line to be a nice 3.4V at no load. Even after increasing the current-limit to 1A, the magic smoke didn’t escape.

  My next step is to see if I can program the board via the USB boot loader that is programmed into the MSP430F5514 by default from the factory. I haven’t had time to do this yet as school has begun again here. Being in my final year, I also need my time for some school-related research projects. This is also the reason this post is so late. I think that I can spend some time in the weekends on this project though, so expect some updates in the weekends.

  Hopefully I will be able to tell you all about programming a MSP430F5514 via the USB boot loader next time.

• Log 7: PCB Design

  Arthur Admiraal • 08/17/2015 at 18:58 • 4 comments

  I thought it would be fun to tell a bit about my PCB design process.

  I start out by loading in all the parts in the PCB editor. Often, my schematic is not complete at this stage, but I like to experiment with parts placement in advance.

  I then group parts by function. For example, the input amplifier is one small group.

  After that, I try to place the parts in such a way that the rats-nest wires are as short as possible.

  The next step is the actual routing. I often change the parts placement during routing, because I see a better way.

  While routing, I still keep the power connections in mind, but I don't worry about it too much, as I often add a ground plane. I later add jumpers for any signal I couldn't route without them.

  As a last step, I beatify the silkscreen, so that it is actually readable.

  I delete all values of the components, as I can easily look them up in the schematic, or I could create a list for them. I set the text size to .8128mm (0.032"), which I think is the smallest silkscreen size that is still relatively readable when produced by cheap PCB fabs. I also switch the font to vector, as it is fixed and the fab won't change it from my design. I also sort of like its look. I keep the ratio at 8%.

  Challenging parts

  Prior to this project, I had actually never lain out a switching converter, so I stuck to the application notes as close as possible, and tried to make everything as compact as possible. I tried to keep the analog section as far away of the switching converters as possible, to minimize noise coupled into them from the relatively high currents in the converters. All the modules were joined to each other with big buses of wires.

  I actually changed the signal net connections to the microcontroller to hugely simplify the routing.

  Fitting everything together

  Because of the need to pack a lot of parts as close together as possible, it was sometimes challenging to route. To solve this, I briefly used thinner traces in some place. This technique is know as necking. Also, I rotated some parts 45 degrees to further assist in routing.

  Signal integrity

  I haven't done much in the way of signal integrity in the past. This is the first project that I have actually consciously thought about it. I can't say that I'm an expert, but I tried some basic things to achieve better signal integrity.

  Apparently it is important to minimize the loop area of your traces. You see, the amount of energy picked up by a coil is proportional to the loop area. Switching power converters with their coils will generate quite a magnetic field. So, by minimizing the loop area, you minimize the noise picked up on the line.

  Now, the loop area is the area between your signal trace and it's return path to ground. I've used some slits in my ground plane to hopefully force the current to go a certain way, in order to minimize the loop area. (Edit (24-april-2017): as pointed out by K.C. Lee in the comments below, forcing the current to go a certain way is not necessary for good return paths, but having the return path close to directly under the signal traces is, something which I have completely forgone on the right side of the picture below. He also suggested solving the problem using stitching vias. See his comment for more information.)

  Looks like there might be a lot of noise on that power bus, guess I should have added some via's.

  Other edits

  After getting all the circuitry perfectly laid out, I add my logo. I actually spend three full evenings getting my logo on the PCB. At first, I tried to use the svg2poly ulp, but because it doesn't support import of curved svg files, I had to subdivide the curves a bunch of times to make them look decent. Since eagle doesn't support polygons with a hole, I had to carefully divide my logo in multiple pieces. After two evenings of carefully assembling them, I sent my file to OSHpark, only to encounter a timeout. It turned out the svg-files had become too large. So I had to import my file as a bitmap and manually trace every detail...

  Read more »

• Introductory video and system design document

  Arthur Admiraal • 08/16/2015 at 22:39 • 0 comments

  Before continuing the logs, I thought it might be a good idea to actually fulfill the requirements of the competition.

  Introductory video
  

  Script
  

  Hello world!

  My name is Arthur Admiraal and I am a 16-year-old electronics hobbyist from the Netherlands.

  In this video I’m going to tell you a bit about my entry to the Hackaday prize: the Squidpad.

  Ever tried to draw something on a computer? When I did, the user experience was cumbersome at best. On most devices, you can’t lay down your hand on the device as you do with paper, the accuracy is terrible and booting up just takes far too long.

  For that reason, I find myself falling back to paper whenever I need to make a quick sketch to organize my thoughts, do some quick math or draw a schematic.

  Paper is messy though. Serious effort is needed to organize it, and it isn’t natively searchable. Also, it doesn’t have the same advanced functions that digital media has. Ever tried to resize something on paper? Not easy, I can tell you that.

  There are of course devices that make drawing on a computer easier, but they are either really expensive, lack a screen, are not mobile, or don’t fully fulfill my requirements.

  In my opinion, a device is needed that is specifically designed to replace sticky notes and scraps of paper scattered around the average household. It should have the same ease-of-use as paper, but add the advanced functionality of digital media to it, such as searchability and semi-automatic drawing tools.

  I’ve spent the last few weeks designing such a device and I have dubbed it the Squidpad. It will feature a 6” e-ink display, a CNC-routed 5.2mm thin aluminium enclosure, accurate localisation of the stylus using ultrasound signal trilateration, a USB compatible interface to download your drawings saved on the internal micro-SD card to your computer and between 20 and 200 hours of battery life depending on how good I am at low power design. I have ideas for other, more advanced features, but I want to get these basics working first.

  As of creating this video, the electronics design is done, and I’ve been documenting it while waiting for the parts to come in. Because of this, I haven’t been able to build a prototype and test anything yet.

  Apart from documentation, I’m currently working on designing the enclosure.

  I have made all files available on GitHub under a CC-BY-NC-SA license.

  Well, I hoped you liked that quick introduction to the Squidpad, feel free to check out the logs in which I describe the project in more detail, as there is only so much that you can explain in a two-minute video.

  System design document

  Here is a high-level block diagram of the device:

  I've described how the ultrasound delay measurement works in log 6. I still have to explain the basic operation of the other electronics. So, without further ado, here is a high-level explanation of the typical operation.

  The stylus sends out an ultrasound pulse. As I haven't designed any part of the stylus yet, I haven't included it in this diagram. During testing I will just be using an ultrasound transducer hooked up to a signal generator. The ultrasound pulse reaches the microphones. The delays between the pulses hitting the microphones are measured via the procedure described in log 6. The micrcontroller now reads out these these delays, and calculates the position of the stylus with them, as described in log 2. It then calculates the pixel which need to be marked to form a line between a current position and the last position. These, and only these pixels are marked on the e-ink display. By forgoing a full update, the power consumption is lowered and any problems with the low refresh rate are mitigated. These pixels are also marked on a bitmap file stored on the micro-SD card which also serves as a frame buffer, in case anything needs to be erased. The microcontrollers RAM would be too small for such a full frame buffer. The micro-SD card is connected to a separate SPI-bus so that a SPI signal to other chips won't...

  Read more »

• Log 6: Capturing the ultrasound signal

  Arthur Admiraal • 08/15/2015 at 18:21 • 0 comments

  Now for the tricky part: accurately measuring the delay between the incoming ultrasound signals on the microphones. First, I amplify the signal using some cascaded negative feedback opamp circuits.

  There is actually only so much gain you can get of an op-amp at a given frequency. The gain-bandwidth product has to remain constant. To get around this, you can cascade them. That is what I did here, to increase the overall amplification.

  I’m only interested in the presence of the signal. Amplifying the negative peaks of the signal would be a duplicate of amplifying the positive peeks, just in the other direction. I don’t bother with that, and just clip those. To accomplish this, I have ground as the reference level of my amplifier. Everything above that will become higher, everything below will become lower. The negative-going peaks will become more negative, but since the output of the amplifier can’t go below the negative supply voltage, which is ground in our case, the output will just stay at ground.

  The second amplifier is then hooked into a peak detector circuit.

  When the amplifier detects the ultrasound signal, it steers its output pin to V+. This signal then charges a capacitor through a diode. When the signal dips down to GND again, the capacitor can’t discharge because of the diode. I get to why this continuous high signal is important in a bit.

  I’ve connected the feedback pin of the second opamp beyond the diode, to mitigate the forward voltage of the diode. It will try to compensate for the voltage drop in the diode, ensuring that the signal is always amplified correctly.

  I then pass the signal to a comparator. It has a lower threshold than the microcontroller, so it will detect the signal more easily. This reduces the need for amplification.

  After all the delays have been measured, the capacitors can be discharged for the next cycle. I’ve hooked each up to a pin of the microcontroller. I didn’t want to connect them together using diodes, in case the leakage current would be so high that one capacitor could charge up the others. The microcontroller pins can stay in a high impedance state, until it is time to discharge the capacitors. Here comes a flaw in my design: I didn’t think to put resistors between the capacitors and the pins. Because of this, if I’m not careful when programming, I can short out power lines, if the output of the opamp happens to be at V+ when I pull the microcontroller pin low. To avoid this I have to only have the pins in either a high impedance state or switched to the internal pull-down resistors.

  Measuring the delays

  I wanted to have a decent resolution on the position of the stylus. I drew some letters, as small as I could, and measured the height of them. They were about 2mm tall. I figured that 16 data points in the height would be enough, so that gives a resolution of 0,125mm. I read here that the speed of sound in glass is about 4000 m/s, but since I will be using tempered glass, which is harder, I can only expect the real speed to lie a bit above that, so I scaled it up to about 5000 m/s. To calculate the time we want to discern, we just have to divide these:

  Wow. That’s very little. And let’s also calculate the maximum value we need to register, assuming the maximum distance is about 20cm:

  The frequency that would be needed to capture such small intervals would then be:

  The number of bits needed to store the range of values then is:

  At first I wanted to use some counter logic IC’s, attached to a fixed clock. The first pulse would enable them, and the second disable them. The amount of pulses could then be read in from their outputs., probably using shift registers. Of course, the chips had to be special high-frequency logic chips, such as the Fairchild 74VHC4040MTCX. This could’ve worked, but I’m not really comfortable with such frequencies yet.

  So I set out to look for some kind of stopwatch IC, that would start counting on one pulse, and stop on the next, and have some nice...

  Read more »

• Log 5: Detailed electronics design

  Arthur Admiraal • 08/14/2015 at 19:33 • 0 comments

  High-level design choices are nice, but they still need to be translated into circuitry. I reckoned that it should be possible to have the electronics mostly be 1mm thick (excluding the 0,8mm PCB of course). If any parts extended a bit past that, a pocket could be milled out in the bottom of the case.

  Driving the e-ink display

  As mentioned before, I closely followed the design of Petteri Aimonen of essential scrap. However, I didn’t like the amount of power supply circuitry, so I decided to use the Texas Instruments TPS65185RGZR, which is a dedicated power management IC. I just carbon copied the typical application circuit in the datasheet. I briefly considered replacing the thermistor that is being used to detect the display overheating with a fixed resistor, as I don’t really need to monitor the temperature, but I went ahead and used it anyway.

  Cost optimization

  As mentioned earlier, I try to put some thought into design for manufacture. The TPS65185 had some quite stringent requirements on parts, which increased the number of parts on the BOM quite a bit. Because of that, I reused a coil and a bunch of resistors and capacitors in the design. This way fewer feeders would be needed when assembling this design using pick-and-place machines, which would decrease manufacturing costs.

  Filtering

  As this design uses multiple switching power converters that introduce a lot of noise in the system, it is important to thoroughly filter the power lines. I’ve got small .1uF capacitors on every IC, and bigger capacitors on the converters themselves.

  Choosing a rechargeable battery

  I needed a thin lithium battery to power the design. I found a company called Powerstream that makes really thin ones. However, shipping to the Netherlands would be about $86, I guess because of precautions that need to be taken against exploding batteries.

  I didn’t like the idea of spending so much on a battery, so I decided to pull off the same trick I used to get a cheap e-ink display: to free-ride along with the buyers of big quantities of electronics. Smartphones are getting thinner by the day, and so are their batteries. Replacements can be bought cheaply of the shelf. So, I went to a PDA replacement part shop, and looked for thin stuff. I ended up on an iPod nano V7 battery, but I couldn’t find the footprint of the connection pads on there. So I looked at other iPod nano batteries, and eventually, I found the ideal battery. I’m talking about the iPod nano V5 battery. It has a nice, big 240mAh of capacity, it’s footprint (being a simple .1” land pattern) is easily guessed with some pixel-measuring techniques, it’s thin, and best of all: for only €12,95 it’s shipped to my doorstep in a day! I found its pinout printed on the silkscreen layer on the back of the flat flex cable on some picture of some online store. I hope to be able to get 200 hours of drawing time out of it, but I’m certain that I can at the very least get 20.

  Finding tiny ultrasound microphones

  If the electronics is only going to be 1,8mm thin, what ultrasound microphone is going to fit in there? I scoured the Internet for parts. I began my search with looking for small electret microphones, but all of them were just too thick. I then looked into using piezo elements, but their frequency responses didn’t seem good enough. At some point I discovered that MEMS microphones are really tiny, albeit a bit on the expensive side. Knowles seems to be the first to make an ultrasonic MEMS microphone. However, I found the power consumption of 5mA a bit prohibitive. Then I found out that and ultrasound transducer was basically what I was looking for. It is behaves sort of like a piezo element, in that it converts ultrasonic sound pressure into electrical signals. However, the only SMD ultrasonic transducer I could find was some unreleased part of Murata. I eventually found this weird small part, that I couldn’t seem to buy anywhere. I later realised that this is the transducer that...

  Read more »

• Log 4: Choosing PCB software

  Arthur Admiraal • 08/13/2015 at 17:02 • 3 comments

  I have only ever used eagle to design my PCB’s. It has suited me fine for the three years that I’ve worked with it, but its limitations bundled with the lack of advanced functionality, such as push and shove routing is starting to get on my nerves. KiCad has been looking more and more promising by the day ever since CERN got involved with it, but the stable release will arrive just to late to be able to design the project on it in time, so it sadly wasn’t an option. I might try it in the future though.

  Altium Circuitmaker did arrive in time though, and its feature set looks just plainly terrific, so I went ahead and installed a copy. I wish I hadn’t. I had of course heard about the cloud-only nature of the software, but since this is an open project, I didn’t expect this to be a problem.

  So I start up the software, fiddled around with it, and get a bit lost. You know, the typical routine when using a new tool, nothing that can’t be fixed by some practice and a few tutorials. But as I struggled to create my first custom component, it dawned upon me that everyone could see and import this part. Every error I made could upset a lot of people. This made me feel quite uncomfortable. Also, I couldn’t pick the license myself, and didn’t have control over my source files. All of the above made the barrier to entry really large, too large in fact.

  So I’m basically stuck with eagle for the time being. It is the tool I’m familiar with, and the tool I’m going to use for this project. It’ll probably come back to bite me in the long run.

• Log 3: Overall mechanical design

  Arthur Admiraal • 08/12/2015 at 21:20 • 0 comments

  The only real mechanical part of this project is the enclosure. As mentioned before, I want to make it waterproof. Also, it needs a glass plate for the stylus localisation.

  When trying to write on a device, you hand may be positioned next to it, which could put stress on you hand. To alleviate this, I want to make the device as thin as possible. This calls for a strong, solid material. Because of the small physical size, I had to make a rough case design before actually laying out the PCB to know the space constraints.

  I want the design to be openable, so that it can be serviced. I came up with a host of ideas to achieve this, but only one was practical.

  At first I considered making a case entirely out of glass, with one open side. Because the glass is already transparent, all functionality of the case could be put in this one part, which made it easy to waterproof it: the electronics would be shoved in, after which the whole would be potted. However, I didn’t like the idea of not being able to service the design. This is where the openability requirement was born.

  After that, my mind turned to aluminium. Aluminium is strong enough for such a thin design, is easy to work with, and its high thermal conductivity makes it feel nice to the touch.

  I’ve never worked with aluminium before, but I know that for an intricate enclosure, a 3D CNC router is the tool for the job, so I went on to design it with that in mind. I have fiddled around with freecad in the past, but I deemed it too unstable for this project, so I tried working with Blender, but that wasn’t really the tool for the job, so I ultimately ended up using designspark mechanical. It isn’t an open tool, but at least it’s free.

  I considered milling a pocket out of a block of aluminium, and putting an O-ring on the top of the walls. The glass plate could then be placed up on that, after which a vacuum could be formed through a small hole that would then be plugged, preferable by some easily removable means (although not to easily).

  Because this would be quite challenging to make, I came up with another idea. I would keep the same design for the bottom half of the case, but glue little pieces of aluminium to it, along the sides of the case. These could then be screwed to the side of the case (from the outside), to keep the glass plate in place, and the O-ring seal under pressure. These pieces would, of course, need O-ring seals around the screws as well, since else water could leak through the screw holes into the design, as the screws leave just a little gap open. This would take up a lot of space, not to mention the difficulty of assembly.

  Apart from the assembly, the other big problem with these designs is the stress put on the fragile, thin glass plate. This is where the fourth and final design was born. By splitting up the aluminium enclosure in a top half and bottom half, the glass can get the much-needed support. By having a cut out for the screen in the top part of the case, the design is kept thin. Gluing the glass to the top part of the case ensures a waterproof cut out. The screen may have to be glued to the glass plate for added support. An O-ring seal can be made halfway in the walls (see picture above (note: the bottom should come down and touch the two 'teeth', but I am not done designing the enclosure yet)). If the screws are placed only around the perimeter, the O-ring can loop around them, so water wont leak in via the screw holes. To prevent the aluminium from rusting, the parts can be anodized.

  There are some potential problems with this design though. The speed of sound in anodized aluminium could be higher than that in tempered glass. Because of this, the aluminium could absorb part of the signal, and get it to the ultrasound microphones quicker then the glass could, which would mess up the calculations. Also, if the bond between the glass plate and the aluminium top part of the case is too strong, the aluminium could end up absorbing too much of the signal...

  Read more »

• Log 2: Overall electronics design

  Arthur Admiraal • 08/11/2015 at 20:03 • 0 comments

  Before I actually started to ponder the nitty-gritty details of the hardware and software design for the project, I thought up some overall solutions to the problems.

  First and foremost, accurate localisation of the tip of a stylus without detection of hands is arguably the most important part of this project. When looking over Wikipedia’s list of touchscreen technologies, I couldn’t really find anything suitable. All technologies would detect either specifically human hands, or all objects that touch their surface.

  So, I tried to think up something better. Eventually, I figured that a system using trilateration could be used to determine the position. If you haven’t heard about trilateration before, it is the calculation that is used to localize GPS modules.---------- more ---------

  It works like this: you have a number of base stations with a known location. The number depends on the number of axis on which you want to localize. Now, you measure your distance to these stations. You don’t use a long piece of measuring tape of course, but rather you can calculate your distance to a base station by measuring the propagation delay.

  You see, the speed of sound or light through a certain medium is mostly constant. So if we give both the device that needs to be localized and the base station synched clocks, we can send a signal to a base station, and then time how long it takes the signal to reach it. We can then just calculate the distance between the objects using a simple formula, which may look familiar if you have done any physics at a high school level or higher:

  In which d is the distance between the objects in m, v is the speed of the signal through the medium in m/s and t is the time it took the signal to reach the base station in s.

  So now we’ve gotten a few distances. So what? Well, we can use these distances to construct imaginary circles around our base stations (or spheres if you’re doing this in 3D), like in the picture below.

  The device is at the intersection of the circles. That is how trilateration works in a nutshell. The more you know.

  So my idea is to put a small ultrasound transducer in the stylus, which will vibrate the tip. It must be ultrasound so that the device won’t annoy people too much. Now if the stylus is placed on some medium – I guess it has to be glass since you need to be able to see a screen under it – the sound wave will be coupled in to it. If I place some ultrasound microphones around the perimeter of the glass plate, I can trilaterate the position of the source of the ultrasound signal from the data I get from them. They’re basically the base stations in the above example.

  Of course when I googled my idea, I found that it had existed for a long time and that currently versions are being integrated in tablets. This is also when I found out about drawing tablets, and with them the technology that enables them. But that didn’t stop me from pursuing this design, as it seems like it is the easiest to implement of all the drawing tablet designs.

  There are two catches with this design. Firstly, you need to know the time at which the stylus emits the signal. Secondly, the glass plate needs to be really thin, or else you’ll need to do more complicated 3D calculations.

  Normally I would’ve implemented an rf communications link from the squidpad to the stylus, on which a signal could be sent to let the stylus emit an ultrasound signal. Because the speed of light is much higher then the speed of sound, any latency on the signal would be negligible in the calculation. But doing this would necessitate some rf design, which I’ve not done yet. It would make everything quite complicated. Instead, I think it is possible to let the stylus periodically emit the signal, and then calculate the exact time at which it was emitted.

  You may know that to solve a system of equitations, you need to have as much equitations as variables that you want to solve for. Since the stylus only needs to be located on two axis, two...

  Read more »

• Log 1: Initial commit

  Arthur Admiraal • 08/10/2015 at 20:11 • 2 comments

  About myself

  I guess it would be a good idea to introduce myself, as this is my first post. I’m a sixteen-year-old electronics hobbyist from the Netherlands. I have always been interested in science and technology, but ever since my parents gave me an Arduino three years ago, I have been hooked. Yes, I’m one of them Arduino kiddies. (I hope you don’t find my code and PCB layout too appalling.)

  Anyhow, on to the project.

  Intention

  Some years ago I had an odd job at a high-tech company, programming an embedded system. It was quite challenging to come up with algorithms sometimes, you really needed to be able to visualise them. Normally, I would have sketched it out on a piece of paper to kind of control my thought flow. However, this just so happened to be a paperless company, so I had to find another means to do it. Suffice it to say that MS Paint didn’t really cut it.

  I think there is a need for a device that replaces scraps of paper, sticky notes and the like. It should have the same ease of use as paper, but not be as messy. Since digital devices have some more possibilities than paper, the experience should also be enhanced. For example, the device should have the ability to save your drawings as vector files for documentation and do some semi-automatic things, such as making your wrangled lines straight. Also, it would arguably be more environmentally friendly than paper in the long run.

  Read more »

View all 10 project logs