Posts with «i2c» label

Doing Logic Analysis To Get Around The CatGenie’s DRM

The CatGenie is an amazing device to watch in action, basically a self-cleaning litter box for cats that even does away with the need to replace the litter. It’s comparable to what the indoor flush toilet is for humans compared to maintaining a composting toilet. However, there is a problem. It uses costly soap cartridges which have to be replaced because an RFID reader and a usage counter prevent you from simply refilling them yourself.

CatGenie and Arduino

[David Hamp-Gonsalves] reverse engineered the electronics so that he didn’t have to pay for the cartridges anymore. This has been done before and one of those who did it created a product called the CartridgeGenius, but it’s made and sold as a parttime project and there were none in stock. The cartridges have an RFID tag and another solution which we’ve covered before is to replace the RFID reader board with an Arduino. That’s the solution [David] adopted. So why write this post if this isn’t new?

The RFID reader board communicates with the rest of the CatGenie using I2C and he needed to know what was being transmitted. To do that he learned how to use a cheap logic analyzer to read the signals on the I2C wires, which makes this an interesting story. You can see the logic analyser output on his blog and GitHub repository along with mention of a timing issue he ran into. From what he learned, he wrote up Arduino code which sends the same signals. He and his cat are now sitting pretty.

What he didn’t do is make a video. But the CatGenie really is amazing to watch in action as it goes through its rather complex 30-35 minute process so we found a video of it doing its thing, shown at 3.5x speed, and included that below.  If you’re into that sort of thing.

[via Adafruit]

Hack a Day 04 Sep 09:00

A Crash Course In Reliable Communication

It’s probably fair to say that anyone reading these words understands conceptually how physically connected devices communicate with each other. In the most basic configuration, one wire establishes a common ground as a shared reference point and then the “signal” is sent over a second wire. But what actually is a signal, how do the devices stay synchronized, and what happens when a dodgy link causes some data to go missing?

All of these questions, and more, are addressed by [Ben Eater] in his fascinating series on data transmission. He takes a very low-level approach to explaining the basics of communication, starting with the concept of non-return-to-zero encoding and working his way to a shared clock signal to make sure all of the devices in the network are in step. Most of us are familiar with the data and clock wires used in serial communications protocols like I2C, but rarely do you get to see such a clear and detailed explanation of how it all works.

He demonstrates the challenge of getting two independent devices to communicate, trying in vain to adjust the delays on the receiving and transmitting Arduinos to try to establish a reliable link at a leisurely five bits per second. But even at this digital snail’s pace, errors pop up within a few seconds. [Ben] goes on to show that the oscillators used in consumer electronics simply aren’t consistent enough between devices to stay synchronized for more than a few hundred bits. Until atomic clocks come standard on the Arduino, it’s just not an option.

[Ben] then explains the concept of a dedicated clock signal, and how it can be used to make sure the devices are in sync even if their local clocks drift around. As he shows, as long as the data signal and the clock signal are hitting at the same time, the actual timing doesn’t matter much. Even within the confines of this basic demo, some drift in the clock signal is observed, but it has no detrimental effect on communication.

In the next part of the series, [Ben] will tackle error correction techniques. Until then, you might want to check out the fantastic piece [Elliot Williams] put together on I2C.

[Thanks to George Graves for the tip.]

Push it to the Limit: SSD1306 at 150 FPS

A good deal of the projects we cover here at Hackaday are not, in the strictest sense, practical endeavors. If we required that everything which graced our digital pages had a clear end result, the site would be in a rather sad state of affairs. Sometimes it’s enough just to do something for the challenge of it. But more often than not, you’ll learn something in the process which you can use down the line.

That’s precisely what pushed [Laurence Bank] to see how well he could optimize the frame rate on the popular SSD1306 OLED display. After several iterations of his code, he was able to achieve a blistering 151.5 FPS, with apparently still some room for improvement if he’s feeling up to the challenge. But considering his first attempt was only running at 5.5 FPS, we’d say he’s already more than earned his hacker cred on this one.

A few different tricks were used to achieve such incredible performance gains. To start with, while the official I2C specification says you’re supposed to wait for an acknowledgment back from the device when communicating with it, [Laurence] realized the SSD1306 didn’t actually care. He could continuously blast commands at the display without bothering to wait for an acknowledgment. He admits there are problems with this method, but you can’t argue with the results.

To really wring all the performance out of the system he could, [Laurence] donned his Assembly Cap and examined how the Arduino IDE compiler was interpreting his code. He identified a few areas where changing his C code would force the compiler to generate faster output. He notes that this wouldn’t normally be required when working with more advanced compilers, but that the Arduino toolchain needs its hand held occasionally.

This isn’t the first time we’ve seen somebody try and push more pixels through the very same OLED display, and it’s interesting to see the two very different approaches to the same goal.

DIY I2C Devices with ATtiny85

[Pawel] has a weather station, and its nerve-center is a Raspberry Pi. He wanted to include a light sensor but the problem is, the Pi doesn’t have a built-in ADC to read the voltage off the light-dependent resistor that he (presumably) had in his junk box. You can, of course, buy I2C ADC chips and modules, but when you’ve already got a microcontroller that has ADC peripherals on board, why bother?

[Pawel] wired up a tremendously simple circuit, downloaded some I2C slave-mode code, and added an LED for good measure. It’s all up on GitHub if you’re interested.

Bright by Day, Dark by Night!

We’re covering this because we rarely see people coding for I2C slave devices. Everyone and their mom uses I2C to connect to sensors, for which the Arduino “Wire” library or “i2c-tools” on the Pi do just fine. But what do you do when you want to make the I2C device? [Pawel]’s project makes use of TinyWireS, a slave-mode SPI and I2C library for AVR ATtiny Arduino projects.

Here, [Pawel] just wanted a light sensor. But if you’re building your own devices, the sky is the limit. What’s the most esoteric I2C sensor that you can imagine? (And is it really the case that we haven’t seen an I2C slave device hack since 2010?)


Filed under: ATtiny Hacks
Hack a Day 07 Nov 09:00

Three Arduinos, Sixteen Square Waves

[Folkert van Heusden] sent us in his diabolical MIDI device. Ardio is a MIDI synthesizer of sorts, playing up to sixteen channels of square waves, each on its separate Arduino output pin, and mixed down to stereo with a bunch of resistors. It only plays square waves, and they don’t seem to be entirely in tune, but it makes a heck of a racket and makes use of an interesting architecture.

Ardio is made up of three separate el cheapo Arduino Minis, because…why not?! One Arduino handles the incoming MIDI data and sends note requests out to the other modules over I2C. The voice modules receive commands — play this frequency on that pin — and take care of the sound generation.

None of the chips are heavily loaded, and everything seems to run smoothly, despite the amount of data that’s coming in. As evidence, go download [Folkert]’s rendition of Abba’s classic “Chiquitita” in delicious sixteen-voice “harmony”. It’s a fun exercise in using what’s cheap and easy to get something done.


Filed under: musical hacks
Hack a Day 03 Aug 16:30
arduino  i2c  midi  music  musical hacks  

Arduino Stroboscope Animation


This tutorial will show you how to build your own Stroboscopic Animator using Magzor's Mechanotronic Design Portal as a starting point. Magzor Corporation is a business in California that is trying really hard to simplify robotic design. They want to enable users with little to no engineering experience to design and manufacture a custom robot by themselves in a matter of hours.

What is a stroboscope? A stroboscope is an instrument that uses a strobe light to make a moving object look stationary… We will use this feature to create an interesting 4 picture animation on a rotating disk.

 


 
Have a look at the video below to see the project in action, and the MDP process walk-through:


 

Video



 
 

Parts Required:


 

Magzor Schematic Diagram

Click to zoom ...

 

Further build instructions can be obtained by selecting the components in the Mechanotronics Design Portal within the Magzor website. Generating the build, and then selecting "Setup Instructions" tab at the top of the page. See video above to see this process in action.
 
 

Arduino Sketch


Make sure to copy and paste the following code into your Arduino IDE. It doesn't seem to work directly from the browser. You also need to install the Arduino Magzor I2C library ( http://magzor.com/downloads/ )


 

Putting it together


 

Arduino MEGA


 

Magzor I2C board


 

MIC Boards


 

MIC Boards Assembled


 

Sensors, Modules and Shields - all put together


 

Motor with Bracket and Wire


 

Picture lined up with magnet on disk


 

Stroboscopic Animation


 

The Arduino MEGA microcontroller listens for the hall effect sensor to be triggered by the south facing side of the magnet on the underside of the rotating disk. As the magnet moves over the hall effect sensor, the sensor is triggered and the Arduino instructs the LED to blink for a fraction of a second. By manipulating the delay after the trigger time, we can get the LED to blink when one of the four images on the rotating disk is towards the front position. And if we get the timing right, we can make a simple animation.
 
If you watch the video above, you will see that the image bounces around a little bit. The duration of each frame is determined by the speed of the rotating disk (or motor), and the number of LED flashes per frame. Any changes in rotation speed will affect the position of the picture when the LED blinks. My rotating disk is not completely semetrical or centred correctly, and therefore a bit jumpy… but you get the idea. Bold images with high contrast seem to work best… Precision is key for this type of project. And if you can get the disk to rotate at a constant speed, you could probably do away with the hall effect sensors and magnets… however, in my case, these were essential in getting the project to work as intended.
 
This project is a lot of fun. You can really get creative by making your own pictures or 3 dimensional models (for a stop motion effect). Try different colours. It really is quite cool.


Concluding Comments


I would like to thank Magzor for supplying the components used in this tutorial, and letting me try out their MDP process. I really like the concept, the one stop shop which looks after you from beginning to end. Providing everything I needed to get the project off the ground. The point of this exercise was to go through the entire process of selecting the parts, build the project, and get it up and running. And I have done that in no time at all.
 
There is only one library to download and install, and the good thing is that you don't have to go hunting for it. The latest "correct" working version of the library is easy to find, right there on the Magzor website… Speaking of the Magzor website, please make sure to take a quick look around. It is quite impressive.



If you like this page, please do me a favour and show your appreciation :

 
Visit my ArduinoBasics Google + page.
Follow me on Twitter by looking for ScottC @ArduinoBasics.
I can also be found on Pinterest and Instagram.
Have a look at my videos on my YouTube channel.


 
 
             

This project would not have been possible without the collaborative effort from Magzor Corporation.
Please visit their site and check out the MDP.



However, if you do not have a google profile...
Feel free to share this page with your friends in any way you see fit.

Arduino Stroboscope Animation





UPDATE: Magzor has just started a Kickstarter campaign. Please check it out to get a good package deal on many of their components. Many of which were used in this tutorial.
 
This tutorial will show you how to build your own Stroboscopic Animator using Magzor's Mechanotronic Design Portal as a starting point. Magzor Corporation is a business in California that is trying really hard to simplify robotic design. They want to enable users with little to no engineering experience to design and manufacture a custom robot by themselves in a matter of hours.
What is a stroboscope? A stroboscope is an instrument that uses a strobe light to make a moving object look stationary… We will use this feature to create an interesting 4 picture animation on a rotating disk.

 

 
Have a look at the video below to see the project in action, and the MDP process walk-through:


 

Video




 
 

Parts Required:





 

Magzor Schematic Diagram

Click to zoom ...

 
Further build instructions can be obtained by selecting the components in the Mechanotronics Design Portal within the Magzor website. Generating the build, and then selecting "Setup Instructions" tab at the top of the page. See video above to see this process in action.
 
 

Arduino Sketch


Make sure to copy and paste the following code into your Arduino IDE. It doesn't seem to work directly from the browser. You also need to install the Arduino Magzor I2C library ( http://magzor.com/downloads/ )



 

Putting it together


 
Arduino MEGA


 
Magzor I2C board


 
MIC Boards


 
MIC Boards Assembled


 
Sensors, Modules and Shields - all put together


 
Motor with Bracket and Wire


 
Picture lined up with magnet on disk


 

Stroboscopic Animation



 


 


The Arduino MEGA microcontroller listens for the hall effect sensor to be triggered by the south facing side of the magnet on the underside of the rotating disk. As the magnet moves over the hall effect sensor, the sensor is triggered and the Arduino instructs the LED to blink for a fraction of a second. By manipulating the delay after the trigger time, we can get the LED to blink when one of the four images on the rotating disk is towards the front position. And if we get the timing right, we can make a simple animation.
 
If you watch the video above, you will see that the image bounces around a little bit. The duration of each frame is determined by the speed of the rotating disk (or motor), and the number of LED flashes per frame. Any changes in rotation speed will affect the position of the picture when the LED blinks. My rotating disk is not completely semetrical or centred correctly, and therefore a bit jumpy… but you get the idea. Bold images with high contrast seem to work best… Precision is key for this type of project. And if you can get the disk to rotate at a constant speed, you could probably do away with the hall effect sensors and magnets… however, in my case, these were essential in getting the project to work as intended.
 
This project is a lot of fun. You can really get creative by making your own pictures or 3 dimensional models (for a stop motion effect). Try different colours. It really is quite cool.



Concluding Comments


I would like to thank Magzor for supplying the components used in this tutorial, and letting me try out their MDP process. I really like the concept, the one stop shop which looks after you from beginning to end. Providing everything I needed to get the project off the ground. The point of this exercise was to go through the entire process of selecting the parts, build the project, and get it up and running. And I have done that in no time at all.
 
There is only one library to download and install, and the good thing is that you don't have to go hunting for it. The latest "correct" working version of the library is easy to find, right there on the Magzor website… Speaking of the Magzor website, please make sure to take a quick look around. It is quite impressive.
 
  UPDATE: Magzor has just started a Kickstarter campaign. Please check it out to get a good package deal on many of their components. Many of which were used in this tutorial.





If you like this page, please do me a favour and show your appreciation :

 
Visit my ArduinoBasics Google + page.
Follow me on Twitter by looking for ScottC @ArduinoBasics.
I can also be found on Pinterest and Instagram.
Have a look at my videos on my YouTube channel.


 
 
             

This project would not have been possible without the collaborative effort from Magzor Corporation.
Please visit their site and check out the MDP.



However, if you do not have a google profile...
Feel free to share this page with your friends in any way you see fit.

PJON, Fancy One Wire Arduino Communications Protocol For Home Automation

PJON, pronounced like the iridescent sky rats found in every city, is a cool one wire protocol designed by [gioblu].

[gioblu] wasn’t impressed with the complications of I2C. He thought one-wire was too proprietary, too complicated, and its Arduino implementations did not impress. What he really wanted was a protocol that could deal with a ton of noise and a weak signal in his home automation project with the smallest amount of wiring possible.

That’s where is his, “Padded Jittering Operative Network,” comes in. It can support up to 255 Arduinos on one bus and its error handling is apparently good enough that you can hold an Arudino in one hand and see the signals transmitted through your body on the other. The fact that a ground and a signal wire is all you need to run a bus supporting 255 devices and they’ll play nice is pretty cool, even if the bandwidth isn’t the most extreme.

Aside from the cool of DIY protocols. We really enjoyed reading the wiki describing it. Some of the proposed uses was running your home automation through your ducting or water pipes (which should be possible if you’re really good at isolating your grounds). Either way, the protocol is neat and looks fun to use. Or check out PJON_ASK if you want to do away with that pesky single wire.


Filed under: Arduino Hacks
Hack a Day 31 Mar 21:00

Serial vs I2C communication

Hi, please, can you tell me difference between I2C and Serial communication and which is the best for communication Raspberry Pi 2 with Arduino (T'Rex Controller). Thanks

Experimenting with MAX6955

MAX6955 is an interesting LED driver chip. It is the primordial charlieplexing device, being the materialization of a technique invented by Charlie Allen of Maxim Integrated. Without understanding how charelieplexing works, it is actually counter-intuitive to wire multiple (up to 8) 16-segment displays to such a driver chip. Fortunately, Maxim has great documentation on how to do it.


My experimenting actually started with MAX6954. After many failed tries due to SPI issues (Maxim uses a special interpretation of the protocol, I read), I switched to MAX6955.

MAX6955 is the I2C sibling of MAX6954 (which uses SPI). They both have identical LED driving abilities, only the microcontroller interface part of the chips differ. Once, both chips were available in DIP-40 package. Now, MAX6955 only comes in SSOP-36 (MAX6954 is still available in DIP-40). Luckily, the pin configurations for the two chips are compatible, which allows for easy swap. For this reason, I designed a breakout board (shared at oshpark), so I can use the same setup I built for MAX6954.


Beside Maxim's, there isn't much documentation on how to control these chips. One of the reasons they are rarely used by hobbyists is probably their price (about $20 at digikey), although in the same range as the wildly popular MAX72xx LED driver (available at around $10 from digikey). In "reality", for some reason, MAX72xx could be had for $1 or less on ebay, unlike MAX6954/6955. Therefore, a hobby kit designed around MAX6955 would be "extremely" expensive compared with others using different LED driving chips (e.g. MAX72xx).

MAX6954/6955 was designed to drive common cathode LED displays, like MAX72xx. But unlike MAX72xx, it cannot be used for displays with common segments (which require multiplexing), like the ones below (and used here). MAX6954/6955 requires the 14/16-segment displays to be single digit/character, because not all segments will be wired together.


Below is the Arduino sketch I wrote that works very well with MAX6955. Although it uses a minimal set of commands, it is capable of displaying a character at a given position, light up the dot, and even scroll a long message.

#include "Wire.h"

#define ID_MAX6955 B1100000 
#define NUM_DISPLAYS 6

#define max6955_reg_decodeMode      0x01
#define max6955_reg_globalIntensity 0x02
#define max6955_reg_scanLimit       0x03
#define max6955_reg_configuration   0x04
#define max6955_reg_displayTest     0x07
#define max6955_reg_digitType       0x0C

int writeMAX6955(char command, char data)
{
    Wire.beginTransmission(ID_MAX6955);
    Wire.write(command);
    Wire.write(data);
    Wire.endTransmission();
}

void initMAX6955()
{
    Wire.begin();
    // ascii decoding for all digits;
    writeMAX6955(max6955_reg_decodeMode, 0xFF);
    // brightness: 0x00 =  1/16 (min on)  2.5 mA/seg;
    // 0x0F = 15/16 (max on) 37.5 mA/segment
    writeMAX6955(max6955_reg_globalIntensity, 0x07);
    // active displays: 0x07 -> all;
    writeMAX6955(max6955_reg_scanLimit, 0x07);
    // set normal operation;
    writeMAX6955(max6955_reg_configuration, 0x01);
    // segments/display: 0xFF=14-seg; 0=16 or 7-seg;
    writeMAX6955(max6955_reg_digitType, 0x00);
    // display test off;
    writeMAX6955(max6955_reg_displayTest, 0x00);
}

void setup()
{
  // set D8 and D9 to GND (for I2C address);
  pinMode(8, OUTPUT);
  pinMode(9, OUTPUT);
  digitalWrite(8, LOW);
  digitalWrite(9, LOW);

  initMAX6955();
  delay(100);
  clear();
//  writeDisplay("HI");
//  writeChar(0, 'A', true);
//  scrollDisplay("     HELLO WORLD", 300);
  writeTime(15, 24, 39);
}

void loop()
{
}

void writeDisplay(char* msg)
{
  for (byte i=0; i < NUM_DISPLAYS; i++)
  {
    if (i < strlen(msg))
      writeMAX6955(0x25-i, msg[i]);
    else
      writeMAX6955(0x25-i, ' ');
  }
}

void writeChar(byte pos, char letter, boolean dotLit)
{
  writeMAX6955(0x25-pos, (dotLit? 0x80 : 0) | letter);
}

void clear()
{
  for (byte i=0; i < NUM_DISPLAYS; i++)
    writeMAX6955(0x25-i, ' ');
}

void scrollDisplay(char* msg, int delayMs)
{
  for (int i=0; i<=strlen(msg); i++)
  {
    writeDisplay(msg+i);
    delay(delayMs);
  }
}

void writeTime(int hours, int minutes, int seconds)
{
  char h1 = (hours/10)? '0' + hours/10 : ' ';
  writeChar(0, h1, false);
  char h2 = '0' + (hours%10);
  writeChar(1, h2, true);
  char m1 = '0' + (minutes/10);
  writeChar(2, m1, false);
  char m2 = '0' + (minutes%10);
  writeChar(3, m2, true);
  char s1 = '0' + (seconds/10);
  writeChar(4, s1, false);
  char s2 = '0' + (seconds%10);
  writeChar(5, s2, false);
}

The I2C address of B1100000 was set by grounding AD0 and AD1 (see table 5 in the datasheet on how to change that address). In my setup, these 2 pins are connected to D8 and D9. Don't forget to pull-up SDA and SCL with 4k7-10k resistors.

The left-most digit is at position 0, accessible at address 0x25. "Digit 1" is the second from left, accessible at address 0x24, and so on. This is determined by the wiring. In my case, "CC0" (in the table 1 of this application note) represents the right-most display, and it is accessible at address 0x20.