If you’re at all into medical hacks, you’ve doubtless noticed that the medical industry provides us with all manner of shiny toys to play with. Case in point is a heart-monitoring IC that’s so brand new, it’s not even available in all of the usual distributors yet. [Ashwin], who runs a small prototyping-supplies company, ProtoCentral, has been playing around with the new MAX30003 ECG chip, and the results look great.
The punchline is that the four-to-five dollar chip does everything for you, including analog filtering, wander removal, and even detecting the pulse rate. Using the chip is simple: you plug in two electrodes on one end, and you get the waveform data out over SPI on the other, with little or no work to do on the microprocessor side. The Arduino in the examples is just passing the SPI data straight to the laptop, with no processing going on at all.
[Ashwin] is selling these as breakout boards, but everything is open source, from the hardware to the GUI, so check it out if you’re interested in building your own. In particular, the circuit is just a voltage regulator and five volt level shifter.
Everything we know about electrocardiography projects, we learned from this presentation, and it looks like the devil is in the (many) details, so it’s nice to offload them to custom silicon whenever possible. We just think it’s awesome that we can scoop up some of the giant medical industry’s crumbs to play around with.
Adjust the phase current, crank up the microstepping, and forget about it — that’s what most people want out of a stepper motor driver IC. Although they power most of our CNC machines and 3D printers, as monolithic solutions to “make it spin”, we don’t often pay much attention to them.
In this article, I’ll be looking at the Trinamic TMC2130 stepper motor driver, one that comes with more bells and whistles than you might ever need. On the one hand, this driver can be configured through its SPI interface to suit virtually any application that employs a stepper motor. On the other hand, you can also write directly to the coil current registers and expand the scope of applicability far beyond motors.
Last month, we took a closer look at microstepping on common stepper driver ICs, but left out the ones that we actually want to use: the smart ones. Trinamic provides some of the smartest stepper motor drivers on the market, and since the German hacker store Watterott released their SilentStepStick breakout boards for the TMC2100 and TMC2130, they are also setting a new standard for DIY 3D printers, mills and pick-and-place robots. I recently acquired a set of both of them for my Prusa i3 3D printer, and the TMC2130 with its SPI configuration interface really caught my attention.
The TMC2130 SilentStepStick should not be confused with the — far more popular — TMC2100 variant. As the name suggests, it comes as a StepStick-compatible breakout board, and just like it’s famous sibling, features a Trinamic IC on the bottom side of the little PCB. Several vias and copper spills conduct heat away from the IC’s center pad, allowing a heatsink on the top side to effectively cool the driver.
However, unlike the TMC2100, this one won’t let your motors spin right away. You’ve got two options: Hard-wire it in stand-alone mode, which practically turns it into a TMC2100, or hook up to its SPI-interface and dial in if you want your stepper motor shaken or stirred. In fact, plentiful configuration registers make the TMC2130 an extremely hackable chip, so I’m not even thinking about bridging that solder jumper on the SilentStepStick’s bottom side that activates the stand-alone mode.
As said, before the driver does anything, it wants to be configured, and it’s worth mentioning that all configuration registers are naturally volatile, so if I want to use them in my 3D printer, I need to configure them as part of the printers startup routine.
The RAMPS 1.4 on my 3D printer breaks out the hardware SPI interface of the underlying Arduino through its AUX3 pin header, along with two additional digital pins (D53 and D49), which I used for the cable select signals. After crimping a cable to connect two TMC2130’s to the AUX3 header, I could start digging into the software part.
Watterott provides an example sketch, which writes a basic configuration to the driver’s registers and spins an attached stepper motor. Great stuff, but the datasheet describes 23 configuration registers waiting to be finely tuned, and 8 more to read diagnosis and status data from. So, I wrote a little Arduino library that would make the numerous configuration parameters available in a more practical way. From there, I could just include my library into the Marlin-RC7 3D printer firmware I’m using. Luckily, the current Marlin release candidate already features support for TMC26X drivers, so I could reuse some of its code to put together a Marlin fork that includes 59 of the TMC2130’s parameters in its define-based configuration files. And then, I could take the little buddies out for a spin.
Taking Them For A Spin
With the hardware set up and the software working as supposed, I ran a few sanity tests: toggling parameters on and off and checking how the driver’s behavior changes during printing. Since the TMC2130 let’s you tune almost everything it’s doing, that’s a good first step that helps to eliminate some variables and picking others that are worth a deeper look. Most of the settings can be changed on the fly and mid-print, however, not all parameters can actually be safely changed while the motors are running.
To actually tune the drivers for a certain application, Trinamic provides a quick start guide in the datasheet, as well as detailed information on each parameter, and on how they interact. Basically, the first step is adjusting the RMS coil current by using the onboard potentiometer on the SilentStepSticks. Then, we need to chose the analog input pin as a current scaling reference to actually make use of the potentiometer. The mentioned library lets me do this through a simple method:
myStepper.set_I_scale_analog(1); // 0: internal, 1: AIN
The running and holding current are the first real parameter that should be tuned, with the running current typically at the desired maximum current, and the holding current at 70% of this value. The delay between a stillstand and the transition from running current to holding current can be adjusted between 0 and 4 seconds, and for now, I set it to 4 seconds, practically disabling the current reduction while the 3D printer is running. The three values share one write-only register, so the corresponding method call looks like this:
and sets the running current to 100% (≙ 31), the holding current to about 70% of this value (≙ 22), and the delay between the two to 4 seconds (≙ 5).
I want torque, so I can leave stealthChop disabled. The datasheet suggests some starting values for configuring the chopper’s off time and the comparator’s blank time settings, but since it’s a key tradeoff between switching noise and torque, it makes sense to iterate through other values as well. The library methods for the two values look like this:
I have yet to walk through the entire tuning procedure, which includes monitoring the coil current on the scope and eliminating distortions in the zero crossing, but I’m getting a clue of the driver’s potential.
It’s maximum continuous RMS current of about 1.2 A per coil (at least in the QFN package on the SilentStepSticks) lets it look like a low-current driver, inferior to the common A4988 and DRV8825. In practice, it outperforms both of them by making intelligent use of a 2.5 A peak current margin. This gives it more than enough torque for 3D printing. I wouldn’t recommend pushing them over 0.9 A RMS though since the IC will momentarily pull more current if it needs more. For SilentStepStick users, that’s a Vref of 0.88 V. Through the SPI-interface, you can choose how much current you want to send through the motor coils when it’s spinning, and when it’s idling. You can choose after how many seconds it will start to decrease the current to a lower holding current when the motor is in standstill, and then to an even lower idling current. And, of course, you can also set it to squeeze out the maximum juice for everything.
Shifting The Gears
Where it starts getting interesting are settings like the high-velocity mode. Above a configurable velocity threshold, the driver offers you to automatically switch the chopper to a faster decay time to squeeze out some extra speed. You can also literally shift the gears by letting the driver internally switch from microstepping to full-step mode once it’s up to speed.
Choosing a finer microstepping resolution smoothens the stepper’s movement, reduces vibrations and sometimes even increases the positioning accuracy. However, it also multiplies the load on the microcontroller, which has to churn out 16, 32 or 256 times more step pulses per second. The TMC2130 lets you pick an input resolution between 1 and 256 microsteps per full-step, and then gives you the option of interpolating the output resolution to 256 microsteps. This allows for smooth operation even on increasingly retro 8-bit AVR motion controllers, which cannot deliver high step frequencies. Also, by configuring the TMC2130’s interface to double-edge step pulses, you can at least double the step frequency at almost no cost. Given that the modern IC still features the classic step/direction interface and even an enable pin, those few additional features actually make it a sweet drop-in upgrade for less-recent CNC and 3D printer electronics.
Just like the TMC2100, the TMC2130 features two efficient and silent drive modes: spreadCycle, and stealthChop. The former delivers high torque at relatively low noise emissions, the latter one is almost inaudible but delivers a dramatically reduced torque. The flexible IC also allows you to tweak the chopper yourself to find the right balance between torque, noise, and efficiency for your application. One of the more noteworthy options in this regard is the possibility of randomizing the chopper’s off time. Since most of the audible noise is released due to dubstep the chopper busily switching the stepper motor’s coils, this option spreads the noise over a wider frequency range to subjectively silence the stepper motor.
The TMC2130 notices when the motor is stalled and losing steps by measuring the motor’s back EMF. Along the way, it counts missed steps, allowing the controller to compensate for otherwise irreversible step-loss. It’s also a great way to react to obstacles rather than running into them full-force and, of course, the feature can be used as an axis endstop. Trinamic calls this feature StallGuard, and just like anything else in this motor driver, it’s highly configurable.
Instead of letting the motor driver handle everything for you, you can also choose the direct mode. This mode practically turns the driver into a two-channel, bipolar constant-current source with SPI interface. You can still use it as a motor driver, but the possibilities reach far beyond that. It’s worth mentioning that the datasheet might be a bit confusing here, and the corresponding XDIRECT register actually accepts two signed 9 bit integers (not 8 bit) for each coil and operates as expected within a numeric range of, naturally, ± 254 (not ± 255) to vary the current between ± Imax/RMS..
About half a year after the release of Watterott’s breakout board, the potential of smarter stepper motor drivers piqued the curiosity of the 3D printing community, but not much has happened in terms of implementation. Admittedly, it takes some effort to get them running. If you’re still busy dialing in the temperature on your 3D printer, you surely don’t want to add a few dozen new variables, but if you’re keen on getting the best out of it, the TMC2130 has a lot to offer: low-noise printing, high-speed printing, print interrupt on failure and recovery from lost steps. Because the driver IC is so hackable, it’s clearly intended to be tuned in to accommodate specific applications. Throwing it on a general purpose test bench probably won’t yield meaningful, general purpose results.
I hope you enjoyed taking a look at a smarter-than-usual stepper motor driver, as one of the new frontiers of DIY 3D printing, and as an interesting component with many other applications. If you’re thinking about experimenting with this IC or breakout board in your 3D printer, feel free to try my Marlin fork to get started. If you’re building something entirely different, the underlying Arduino library will help you out. Who else is using this part? I’ll be glad to hear about your ideas, applications, and experiences in the comments!
[Lewin] wrote in to tell us about a high speed library for Arduino Due that he helped develop which allows interfacing OLED displays that use the SSD1306 display controller, using DMA routines for faster display refresh time.
Typically, displays such as the Monochrome 1.3″ 128×64 OLED graphic display , are interfaced with an Arduino board via the SPI or I2C bus. The Adafruit_SSD1306 library written by [Limor Fried] makes it simple to use these displays with a variety of Arduinos, using either software or hardware SPI. With standard settings using hardware SPI, calls to display() take about 2ms on the Due.
[Lewin] wanted to make it faster, and the SAM3X8E on the Due seemed like it could deliver. He first did a search to find out if this was already done, but came up blank. He did find [Marek Buriak]’s library for ILI9341-based TFT screens. [Marek] used code from [William Greiman], who developed SD card libraries for the Arduino. [William] had taken advantage of the SAM3X8E’s DMA capabilities to enable faster SD card transfers, and [Marek] then adapted this code to allow faster writes to ILI9341-based screens. All [Lewin] had to do was to find the code that sent a buffer out over SPI using DMA in Marek’s code, and adapt that to the Adafruit library for the SSD1306.
There is a caveat though: using this library will likely cause trouble if you are also using SPI to interface to other hardware, since the regular SPI.h library will no longer work in tandem with [Lewin]’s library. He offers some tips on how to overcome these issues, and would welcome any feedback or testing to help improve the code. The speed improvement is substantial. Up to 4 times quicker using standard SPI clock, or 8 times if you increase SPI clock speed. The code is available on his Github repo.
If you want to take a photograph with a professional look, proper lighting is going to be critical. [Richard] has been using a commercial lighting solution in his studio. His Lencarta UltraPro 300 studio strobes provide adequate lighting and also have the ability to have various settings adjusted remotely. A single remote can control different lights setting each to its own parameters. [Richard] likes to automate as much as possible in his studio, so he thought that maybe he would be able to reverse engineer the remote control so he can more easily control his lighting.
[Richard] started by opening up the remote and taking a look at the radio circuitry. He discovered the circuit uses a nRF24L01+ chip. He had previously picked up a couple of these on eBay, so his first thought was to just promiscuously snoop on the communications over the air. Unfortunately the chips can only listen in on up to six addresses at a time, and with a 40-bit address, this approach may have taken a while.
Not one to give up easily, [Richard] chose a new method of attack. First, he knew that the radio chip communicates to a master microcontroller via SPI. Second, he knew that the radio chip had no built-in memory. Therefore, the microcontroller must save the address in its own memory and then send it to the radio chip via the SPI bus. [Richard] figured if he could snoop on the SPI bus, he could find the address of the remote. With that information, he would be able to build another radio circuit to listen in over the air.
Using an Open Logic Sniffer, [Richard] was able to capture some of the SPI communications. Then, using the datasheet as a reference, he was able to isolate the communications that stored information int the radio chip’s address register. This same technique was used to decipher the radio channel. There was a bit more trial and error involved, as [Richard] later discovered that there were a few other important registers. He also discovered that the remote changed the address when actually transmitting data, so he had to update his receiver code to reflect this.
The receiver was built using another nRF24L01+ chip and an Arduino. Once the address and other registers were configured properly, [Richard's] custom radio was able to pick up the radio commands being sent from the lighting remote. All [Richard] had to do at this point was press each button and record the communications data which resulted. The Arduino code for the receiver is available on the project page.
[Richard] took it an extra step and wrote his own library to talk to the flashes. He has made his library available on github for anyone who is interested.
[Paul Stoffregen], known as father of the Teensy, has leveraged the Teensy 3.1’s hardware to obtain some serious speed gains with SPI driven TFT LCDs. Low cost serial TFT LCDs have become commonplace these days. Many of us have used Adafruit’s TFT LCD library to drive these displays on an Arduino. The Adafruit library gives us a simple API to work with these LCDs, and saves us from having to learn the intricacies of various driver chips.
[Paul] has turbocharged the library by using hardware available on Teensy 3.1’s 32 Freescale Kinetis K20 microcontroller. The first bump is raw speed. The Arduino’s ATmega328 can drive the SPI bus at 8MHz, while the Teensy’s Kinetis can ramp things up to 24MHz.
Speed isn’t everything though. [Paul] also used the Freescale’s 4 level FIFO to buffer transfers. By using a “Write first, then block until the FIFO isn’t full” algorithm, [Paul] ensured that new data always gets to the LCD as fast as possible.
Another huge bump was SPI chip select. The Kinetis can drive up to 5 SPI chip select pins from hardware. The ATmega328 doesn’t support chip selects. so they must be implemented with GPIO pins, which takes even more time.
The final result is rather impressive. Click past the break to see the ATmega based Arduno race against the Kinetis K20 powered Teensy 3.1.
To prevent data corruption when using multiple SPI devices on the same bus, care must be taken to ensure that they are only accessed from within the main loop, or from the interrupt routine, never both. Data corruption can happen when one device is chip selected in the main loop, and then during that transfer an interrupt occurs, chip selecting another device. The original device now gets incorrect data.
For the last several weeks, [Paul] has been working on a new Arduino SPI library, to solve these types of conflicts. In the above scenario, the new library will generate a blocking SPI transaction, thus allowing the first main loop SPI transfer to complete, before attempting the second transfer. This is illustrated in the picture above, the blue trace rising edge is when the interrupt occurred, during the green trace chip select. The best part, it only affects SPI, your other interrupts will still happen on time. No servo jitter!
This is just one of the new library features, check out the link above for the rest. [Paul] sums it up best: “protects your SPI access from other interrupt-based libraries, and guarantees correct setting while you use the SPI bus”.
When a Lexmark inkjet printer stopped working, [Mojobobo] was able to claim it as his own. He quickly realized that the machine was flooded with ink and not worth repairing, but that didn’t mean he couldn’t still find a use for it. When he learned that the printer’s firmware was not only upgradable but also unprotected, he knew he should be able to get the printer to do his own bidding.
[Mojobobo] started his journey with the motherboard. The unit still powered up, but it was asking to insert a “duplex module” before it would boot any further. [Mojobobo] first tried to find a way to trick the duplex module sensor, but was unsuccessful. His next step was to search for some kind of serial communications port. He didn’t have an oscilloscope, so instead he used a speaker with a wire probe. In theory, if the wire was pressed against an active serial port, he would be able to hear varying tones through the speaker. Sure enough, he found some interesting tones after probing around some ports next to a “JTAG” label. He looked up some information about the nearby chip and found that it included an SPI bus.
After some internet research, [Mojobobo] learned enough about SPI to have a rough idea of how to use it. Having limited tools available to him, he decided to use his Arduino to try to communicate with the motherboard. After wiring up a simple circuit, (and then re-wiring it) he was able to dump the first 4096 bytes of the motherboard’s boot loader to the Arduino via the SPI interface.
[Mojobobo's] next steps will be to find a faster way to dump the boot loader. At 9600 baud, he grew tired of waiting after three hours. Once he has the full boot loader he intends to search for a way to bypass the duplex sensor and get the board to finish booting. Then he may just use the printer for its scanning functions, or he might find other interesting uses for it.
In this tutorial we’ll explain how to use the GPIO pins of the Arduino implementation in the pcDuino v2 and v3. As the v3 is now available you can use it as well, and it’s interchangeable with the v2. Although the pcDuino v2 is Arduino-compatible, there are a few differences that you need to be aware of – in order to make your projects a success and also to avoid any costly mistakes.
This tutorial builds on the knowledge from the initial review, so if pcDuino v2 is new to you please review this article before moving on. In this instalment we’ll run through the following:
ADC (analogue to digital)
Digital input and outputs
PWM (pulse-width modulation)
Using ADC pins
Just like an Arduino Uno or compatible, the pcDuino v2 has six ADC pins, in the expected locations:
Using the pcDuino v2’s ADC pins is quite straight forward, however you just need to remember a few things about the hardware – that the maximum input voltage on A0 and A1 is 2V – and 3.3V for A2~A5.
Although there is an AREF pin on the board, this function isn’t supported at the time of writing. From the software perspective A0 and A1’s values have a 6-bit resolution and can fall between 0 and 63 (0~2V), otherwise the others have a 12-bit resolution and thus return values between 0 and 4095 (0~3.3V). Using the ADC pins is simple, and demonstrated in the following sketch:
… which results with the following in the console:
The pcDuino v2’s implementation of digital outputs aren’t anything out of the ordinary – except that you are limited to a maximum voltage of 3.3V instead of the usual 5V. Furthermore you can only source 4mA from each pin. However if you have some 5V-only shields that you must use with your pcDuino v2 – there is a Voltage Translation board that can be used to solve the problem:
However using 3.3V for new designs shouldn’t be an issue – new sensors, ICs and so on should be 3.3V-compatible. And with the pcDuino v2 you get an extra four digital I/O pins, located next to the SPI grouping as shown below:
These are simply addressed as D14~D17. Now back for a quick demonstration with the typical LEDs. As the current sourced from each GPIO pin cannot exceed 4mA, you need to use a resistor to keep things under control. Using the LED wizard, by entering a 3.3V supply, 2.1V forward voltage for our LEDs and a 4mA current – the resistor value to use is 330Ω.
If you’re having a lazy attack and use 560Ω, the current will be around 2.5mA with acceptable results. We’ve done just that with the following demonstration sketch:
When using the digital pins as inputs, just treat them as normal except they have a maximum input voltage of 3.3V for HIGH. Again – just keep thinking “3.3V”.
Using the I2C data bus
The I2C bus (or “two wire interface”) is a common serial data bus used for interfacing all manner of devices with a microcontroller. You can find a background on the I2C bus and Arduino tutorial here. Just like an Arduino Uno R3, the I2C bus pins are both A4 and A5 (for SCL and SDA) and can also be found up near D13, for example.
The limitations for the pcDuino v2’s version of I2C bus are few – the maximum speed is 200 kHz, it only uses 7-bit addresses and you can’t use the pcDuino in slave mode. However there are 2.2kΩ pullup resistors which can save using them with external circuitry.
We demonstrate the I2C bus by writing data to and reading it from a Microchip 24LC256 EEPROM (which is handy in itself as there isn’t any EEPROM function on the pcDuino v2). This is demonstrated with an Arduino Uno in part two of our I2C tutorials.
Connection is very easy – pins 1 to 4 of the EEPROM are connected to GND, pin 5 to SDA, pin 6 to SCL, pin 7 to GND and pin 8 to 3.3V. Finally a 0.1uF capacitor is placed across 3.3V and GND.
The sketch to read and write values to the EEPROM is simple, and apart from the #include <core.h> for the pcDuino all the other functions operate as normal.
// pcDuino I2C demonstration
#include <core.h> // for pcDuino
#include <Wire.h> for I2C
#define chip1 0x50 device bus address for EEPROM
// always have your values in variables
unsigned int pointer = 69; // we need this to be unsigned, as you may have an address 32767
byte d=0; // example variable to handle data going in and out of EERPROMS
Wire.begin(); // wake up, I2C!
void writeData(int device, unsigned int add, byte data)
// writes a byte of data 'data' to the chip at I2C address 'device', in memory location 'add'
Wire.write((int)(add 8)); // left-part of pointer address
Wire.write((int)(add & 0xFF)); // and the right
byte readData(int device, unsigned int add)
// reads a byte of data from memory location 'add' in chip at I2C address 'device'
byte result; // returned value
Wire.beginTransmission(device); // these three lines set the pointer position in the EEPROM
Wire.write((int)(add 8)); // left-part of pointer address
Wire.write((int)(add & 0xFF)); // and the right
Wire.requestFrom(device,1); // now get the byte of data...
result = Wire.read();
return result; // and return it as a result of the function readData
for (int a=0; a10; a++)
for (int a=0; a10; a++)
printf(Pointer %d holds %d.\n,a,d);
… which results with the following output in the console:
As you now know, using I2C isn’t hard at all. A lot of beginners shy away from it – or run screaming for the nearest library for their part. You don’t need libraries – spend a little time now learning about I2C and you’re set for life.
Using the SPI data bus
Again we have some SPI tutorials for Arduino, so check them out first if the concept is new to you. Writing to an SPI device with the pcDuino v2 isn’t tricky at all, you have the 3.3V hardware limitation and the SPI pins are in the same location (D10~D13) or in a separate group on the board:
Furthermore the maximum SPI speed is 12 MHz and the pcDuino v2’s implementation of SPI can only work as a master. However in the sketch there are a few differences to note. To demonstrate this we’ll control a Microchip MCP4162 digital rheostat via SPI to control the brightness of an LED. Here is the circuit:
And now for the sketch. Take note of the fourth line in void setup() – this is used to set the SPI bus speed to 12 MHz. You can also reduce the speed with other multipliers such as 32, 64 and 128 to slow it down even further. The other point to note is the use of SPI.transfer(). With the pcDuino v2 there are two parameters – the first is the data to send to the SPI device, and the second is either
if there is another byte of data following immediately, or
if that is the last byte for that immediate transfer. You can see this use of the paramters within the function setValue() in the demonstration sketch below.
When using the SPI bus, relevant data will appear in the console, for example:
And finally the demonstration video to show you it really works – you can see the output voltage from the rheostat and the matching LED brightness.
Receiving data from the SPI bus is equally as simple, however at the time of writing we don’t have an SPI device to demonstrate this, so please refer the SPI part of the pcDuino guide. Finally, you can’t use PWM on D10 or D11 when using the SPI bus in your sketch.
You can simulate analogue output using PWM with a pcDuino v2 – however there are two types of PWM pins available. The first is found on digital pins D3, D9, D10 and D11 – they are simulated PWM – and have a low range of zero to twenty at 5 Hz. There are two hardware PWM pins – D5 and D6, which run at 520Hz and have the full range of 0~255 available in analogWrite(). Once again – they output 3.3V. Furthermore, you can’t use pinMode() functions or the SPI bus if using D10 and/or D11 for PWM.
Now you should have an understanding of the features and limitations of using GPIO pins with your pcDuino v2 Arduino sketches. And finally a plug for my own store – tronixlabs.com – offering a growing range and Australia’s best value for supported hobbyist electronics from adafruit, DFRobot, Freetronics, Seeed Studio and much more.
Have fun and keep checking into tronixstuff.com. Why not follow things on twitter, Google+, subscribe for email updates or RSS using the links on the right-hand column, or join our forum – dedicated to the projects and related items on this website.
As more and more people get a Pi they are asking how to interface it to their robot. I do not own a Pi but I looked at the GPIO pins available for interfacing. Apart from general digital I/O pins you have I2C, SPI and Serial interfacing available. I assume there is a library or something that allows these pins to be easily access from within the Linux operating system.
So the question becomes do you just use another MCU such as an Arduino to provide the necessary I/O functionality or do you use a custom shield?
Brian Schiffer and Sima Mitra, from Cornell University, propose a very nice wristwatch that allows you to keep track of your time perception, using a method known as duration production: TicTocTrac.
Human perception of time is typically distorted, due to the different amount of information and experiences acquired everyday. TicTocTrac lets you to estimate your own perception, first by signaling the perceived duration of a given event and, then, by comparing it with the actual event duration. Finally, all the information can easily be saved to a micro SD card.
The hardware is based on a Atmega32u4, a DS3234S real-time clock and several leds to display time, while the software part is mostly based on Arduino’s DS3234S RTC library.