Archive for the ·

Arduino

· Category...

2013-05-20 12:12

How to make an LED Cube

2 comments
by havard    in Arduino

User “fruitkid101″ has a short and to-the-point video up on YouTube on how to construct a 3×3x3 LED cube, and drive it with an Arudino. What distinguishes his video from the hundreds of other LED cube videos out there, is that he explains step by step how to arrange the LEDs and route the wiring. Secondly, as it’s only three layers and nine columns, he needs no other components (save for resistors and three transistors), and all twelve wires are hooked directly up to the Arudino.

Another interesting and instructive video is Kevin Darrah’s on a 8×8x8 RGB cube. (Unfortunately, it wont show in HTML5 yet, but can be downloaded with the Video DownloadHelper Firefox plugin). He explains how to construct the towers which make up the cube, and also goes into detail on testing the LED and connections along the way. Much more work, of course, but also looks very cool.

tags: , ,
2 comments!
2013-02-19 02:38

Home automation with Arduino and Android

Comments Off
by havard    in Arduino

Last year I made the first progress towards a DIY remote for my home automation light switches (using the Everflourish RF based system). The goal was to use the 433.92 MHz radio transmitter and an Arduino to control the switches. Furthermore, the Arduino would receive control commands from my always-on computer, with Bash command line control (’cause that’s the way I like it). Finally, a custom Android app was developed as yet another option for remote control. The project is now fully operational, with a few adjustments here and there remaining. The figure below shows a high level overview.

From left to right, the mobile phones run Android apps which present a simple interface to control the lights. Each light can be turned on and off individually, or by some pre-sets (e.g. everything on or off, “good morning”, or “movie time”). The application has hard-wired the IP address of my always on server / PC on the local network. There is of course nothing stopping me from connection to a public IP (and port-forward), however, I don’t need away-from-home control at this point. The phone app simply sends a “light switch command” to the PC, which forwards it directly to the Arduino (see details below).

In this setup, the server is only a proxy, however, it could of course also be used to implement pre-programmed settings. E.g. daily rhythm commands when we’re away on holiday, or other automated functions. Since this box is also my PC, I can also send commands directly to the Arduino over serial /dev/tty; I have some convenience bash-scripts for that. For the phone app, it only does the forwarding on a hard-wired port:

while true; do nc -l 1234 > /dev/ttyUSB0; done

Maybe that bit could be improved in the future. Especially, since there are occasionally a few hiccups in the phone to PC communication. For example, the switch from 3G to local Wifi connection might be delayed as we enter the house, so commands will buffer up, and then suddenly sent en masse. Also, this would be a natural place to expand the system with pre-programmed actions. It should also be noted that to get this to work, I had to enable communication on the port 1234 both on the Wifi router, and the local server firewall.

Finally, the Arduino, connected via USB, accepts the incoming serial messages. The encoding is simple: A two digit code where the first digit is the index of the light, and the second is 0 or 1 for off or on (see the loop() method in the source listing below). So, “11″ will turn on the first light, while “10203040″ turns off all four lights. (Note that in the code below, to make things clearer for myself, index 0 is skipped).

The code below is all there is the the Arduino part. It hard-codes the Everflourish messages and timings. It should be noted that the messages as found in the previous article, are most likely some form of Manchester code, as there are always pairs of 01 or 10. Thus, the hard-coded messages could have been shortened, but this would have added (a bit) to the complexity of the code, so I left it.

The main loop waits for incoming bytes on the serial USB connection, and sends the according light switch command to the RF transmitter on pin 2. Here there is probably also room for some improvements, to avoid illegal numbers, stuck states, etc. Once a valid code is received, the transmitted signal for that button is repeated four times, just as seen with the original remote control.

(Download source)

#define OUT_PIN 2

// Timings in micro seconds
#define SHORT_UP_0 567
#define LONG_UP_1 1134
#define DOWN_SPACE 680
#define UP_END 15000

const int PREAMBLE = {0x00};
const int OFF[] = {0x55};
const int ON[]  = {0xaa};

const int light_array[][5] = {
  {},
  // main
  {0x65, 0xa9, 0x46, 0x95, 0x67, },
  {0x65, 0xa9, 0x46, 0x96, 0x96, },
  {0x65, 0xa9, 0x46, 0x99, 0xa3, },
  {0x65, 0xa9, 0x46, 0x9a, 0x61, },

  // aux
  {0x65, 0xa9, 0x46, 0x95, 0xaa, },
  {0x65, 0xa9, 0x46, 0x96, 0x53, },
  {0x65, 0xa9, 0x46, 0x99, 0x62, },
  {0x65, 0xa9, 0x46, 0x9a, 0xa1, },
}; 

void setup() {
    Serial.begin(9600);
    Serial.println("setup");

    pinMode(OUT_PIN, OUTPUT);
}

void loop() {
  if (Serial.available() > 1) {
     int light_id = Serial.read() - '0';
     int on = Serial.read() - '0';
     Serial.print(light_id);
     Serial.println(on);

     for(int i = 0; i < 5; i++) {
       send(light_array[light_id], on);
     }

     //delay(500);
  }
}

void send(const int *light_data, boolean on) {

  digitalWrite(OUT_PIN, LOW);
  delayMicroseconds(LONG_UP_1);

  send_bytes(PREAMBLE, 1, 4);
  send_bytes(light_data, 5, 8);
  send_bytes(on ? ON : OFF, 1, 8);

  digitalWrite(OUT_PIN, HIGH);
  delayMicroseconds(DOWN_SPACE);

  digitalWrite(OUT_PIN, LOW);
  delayMicroseconds(UP_END);

  digitalWrite(OUT_PIN, HIGH);
}

void send_bytes(const int *bytes, int len_bytes, int len_bits) {
  for(int b = 0; b < len_bytes; b++) {
    int data_byte = bytes[b];
    for(int i = len_bits - 1; i >= 0; i--) {
      digitalWrite(OUT_PIN, HIGH);
      delayMicroseconds(DOWN_SPACE);

      digitalWrite(OUT_PIN, LOW);
      int data_bit = ((data_byte >> i) & 1);
      if (data_bit == 0) {
        delayMicroseconds(SHORT_UP_0);
      } else {
        delayMicroseconds(LONG_UP_1);
      }
    }
  }
}

tags: , , , , , ,
Comments Off
2013-01-27 11:56

Small DIY keypads

Comments Off
by havard    in Arduino

Looking for a simple remote control solution, I came across these small 4×4 button keypads seen in the pictures below. The first two are similar in that they are simple discrete digital circuits with a 8-pin (4×4) output. The only difference is the direction of the pins. The third uses an analogue signal to determine which button is pressed, thus only a single free analogue pin is needed on the Arudino.


(Images link to the Deal Extreme product pages)

Gerhard Schmidt has posted a nice article on how to read these keypads (his examples are with 3×4 keypads, but the principles are of course the same). For the digital 8-pin versions, reading is very simple, and you can even get away with no extra components, if you are willing to spend 8 IO ports on your micro controller. For the analogue based board, voltage thresholds are used to distinguish which key is pressed. Those boundaries will of course depend on the implementation of the board. Deal Extreme links to one circuit diagram, and on Waveshare’s product page (they seem to be the original manufacturer) an overview of voltage ranges for both 5V and 3.3V can be found.

tags: , , ,
Comments Off
2013-01-19 15:20

Arduino on Fedora 17

2 comments
by havard    in Arduino

Working with the Arduino on a changing Fedora environment is a bit of a challenge. For every release or update, there’s something new and exciting which breaks the Arudino IDE, programmer, or serial connection. Here’s what I’ve collected for Fedora 17 and previous versions.

The basic setup for the programmer is to let the rxtx module have access to the lock file system. This is one way of achieving that: (note the new location of the lock files)
sudo usermod -a -G uucp,dialout,lock $USER
sudo chgrp uucp /run/lock
sudo chmod 775 /run/lock

Next, the gpsd daemon might still be in the way. One or more of the commands below should take care of it:
sudo systemctl stop gpsd
sudo systemctl disable gpsd
sudo killall gpsd
sudo yum erase gpsd

More recently, the ModemManager (for 3G and other modems) might interfere with the serial connection. However, NetworkManager depends on the the former, so it cannot just be removed. The hack below should take care of it though (lest you want to hack around with udev exception rules).
sudo chmod 0000 /usr/sbin/modem-manager
sudo killall modem-manager

Finally, an incompatibility been a system / GCC library and some older versions of the Arduino IDE seems to have been introduced. It manifests itself at compile-time, with the errors “error: expected identifier or ‘(’ before ‘double’” and “error: expected ‘)’ before ‘>=’ token”. Although most likely just a temporary issue until next upgrade, it can be fixed by commenting out the following line in hardware/arduino/cores/arduino/wiring.h

file: .../hardware/arduino/cores/arduino/wiring.h

// #define round(x) ((x)>=0?(long)((x)+0.5):(long)((x)-0.5))

And that’s it. Now you’re all set to program the Arduino on Fedora 17.

tags: ,
2 comments!
2012-11-14 23:32

Arduino adapter shield for the RPi

Comments Off
by havard    in Arduino

The H recently wrote about the AlaMode board which lets you use Arudino compatible shields with the Raspberry Pi. The board connects to the GPIO headers of the RPi, and exposes the familiar pin-set of the Arudino Uno on top. The AlaMode board also contains a real time clock, which it can provide as an add-on to the RPi which as none.

In fact, from the picture, it looks like the board is a full fledged Arudino itself, with an Atmel 328P chip on top. It should mean that you can program it on-board, directly from the RPi.

The board is selling for $45, but is out-of-stock at SeeedStudio.

tags: , ,
Comments Off
2012-09-02 22:06

Home Automation on 433.92 MHz with Arduino

1 comment
by havard    in Arduino, electronics

Last year I wrote about my plans with the RF Link Transmitter, Receiver, and Everflourish home automation system seen in the pictures below. The idea was to replace the remote with my own system, and control the switches using the RF transmitter and an Arduino. However, the problem was to first decode the bespoke message sent from the remote so I could reproduce it. Initially, I was concerned that the RF receiver was giving a too noisy signal; only reading its value from the Arduino and printing to Serial.out did not yield anything useful. It was not before I took the Arduino out of the loop, and connected the receiver directly to a oscilloscope that things started to look more promising.

On the oscilloscope, I could see the message very clearly. Now I just had to write it down, and analyse the code for all different buttons and remotes. Here the problem was that each button sends a rather long message, 52 bits in total, and the old oscilloscope I tried did not have much memory to store recordings to. Also, it wasn’t mine, so was not so convenient to access and work with. Enter the real break-through of this story: Dave Houston brilliant idea and post about a poor man’s oscilloscope – your sound card! He works with various X10 systems himself, and has more interesting information on his site. For the sound-card hook-up, any audio-wire will do; if using a stereo wire and mono recording, figure out which side is which, add some resistors (39k and 10k was suggested; I ended up with one 1 k Ohm and another at 100 Ohm, which worked just as well). David also points out that the line-in should be used, rather than the microphone plug.

The next bright idea came from Ray, who has done exactly the same project as I wanted to do, but with a different remote control system. He shows how the open source audio tool Audacity can be used to record and analyse the message. I found that Audacity also had a neat feature in that you could add a Label Track, that made it easy to write down the code, and later export it, as seen below.

The screenshots below show a recorded signal in Audacity, first at an overview, then zoomed in, labelled, and finally marking the length of each segment. Notice in the first picture how there is a lot of noise before the remote button is pushed, but that it is very clear where a signal comes in (repeating four times). Also, as seen from the second picture, the signal is strong and clear, without much noise as all, which speaks for the quality of the RF receiver, I guess. In the third picture, the segments has been labelled; see below for how to extract that, and further details about the code.

Click on the pictures for larger versions.

Each of the remote control systems have their own proprietary encoding for the messages sent, and the Everflourish system I have has a very different code from Ray’s Stanley equipment. Each bit in the message is expressed by a high with varying length followed by a low of common length. In the last picture above, these segments have been labelled, and as can be seen, the long high is twice the length of the short (50 vs. 25 samples) while the low space is at 30 samples. That’s using a sample rate of 44100 Hz. Ray points out that you can zoom all the way in, and count the individual samples. Another way is to use the unit selection in Audacity (at the bottom of the window), and select the highest precision unit “hh:mm:ss + samples”, and then select the area of one segment. The start and end timing is then shown at the bottom of the window, and it’s a matter of simple subtraction to find the length. Much easier than counting 50 samples.

For the Everflourish code, only the highs matter then, so I recorded one button, cut out the relevant message, copy/pasted it to a new Audacity project, added a Label Track as seen from the menu above (Tracks -> Add New -> Label Track) and went through and labelled the highs with 0 for short and 1 for long. That was just an arbitrary choice. Once done, the new project was saved with a descriptive name of the remote and button, and the labels could be extracted from the XML project file with something like this. (As a bonus, the digits are split into 4-bit nibbles.)

cat remote1_button2_off.aup | grep label.*title | cut -d '"' -f 6 | tr -d '\n' | sed "s/\([01]\{4\}\)/\1 /g"

Below, the messages from three different remotes (with 4 + 4 + 8 = 16 buttons) are listed, but in the interest of space and simplicity, only some are shown. From this I conclude that only a few parts of the message are consistent between the different remotes. First, it always starts with a 0-nibble. The ON and OFF buttons are consistent and reversed across all buttons. Beyond that, it’s hard to tell what is encoded. There is possibly a marker in the middle, at the seventh nibble, marked in gray, but it could be a coincidence. The third nibble is also the same for all three remotes. As can be seen, the two first remotes share data in the first part, and one could be led to believe that this was a common preamble, but this must be rejected when looking at the third advanced remote.

That seems to go against what is assumed in the the source code from TellDus. There they assume a “house” and “unit” (button) key on the last nibbles before the on/off code, but that does not match what I see across my remotes. There seems to be nothing identifying a specific remote, but rather all buttons are unique, and there is possibly some kind of general batch (as opposed to unique serial) number at the beginning of the message.

Simple 4 button remote

1 - OFF : 0000 0110 0101 1010 1001 0110 0110 1001 0101 1010 1010 0101 0101
1 - ON  : 0000 0110 0101 1010 1001 0110 0110 1001 0101 1010 1010 1010 1010

2 - OFF : 0000 0110 0101 1010 1001 0110 0110 1001 0110 0101 0101 0101 0101
2 - ON  : 0000 0110 0101 1010 1001 0110 0110 1001 0110 0101 0101 1010 1010

3 - OFF : 0000 0110 0101 1010 1001 0110 0110 1001 1001 0110 0110 0101 0101
3 - ON  : 0000 0110 0101 1010 1001 0110 0110 1001 1001 0110 0110 1010 1010

Simple 4 button remote

1 - OFF : 0000 0110 0101 1010 1001 0101 0110 1001 0101 0110 1001 0101 0101
1 - ON  : 0000 0110 0101 1010 1001 0101 0110 1001 0101 0110 1001 1010 1010

2 - OFF : 0000 0110 0101 1010 1001 0101 0110 1001 0110 1000 1000 0101 0101
2 - ON  : 0000 0110 0101 1010 1001 0101 0110 1001 0110 1000 1000 1010 1010

3 - OFF : 0000 0110 0101 1010 1001 0101 0110 1001 1001 1010 0101 0101 0101
3 - ON  : 0000 0110 0101 1010 1001 0101 0110 1001 1001 1010 0101 1010 1010

Advanced 8 channel remote

1 - OFF : 0000 1010 0101 0101 0101 1010 0110 0101 0101 0110 0110 0101 0101
1 - ON  : 0000 1010 0101 0101 0101 1010 0110 0101 0101 0110 0110 1010 1010

2 - OFF : 0000 1010 0101 0101 0101 1010 0110 0101 0110 1001 1001 0101 0101
2 - ON  : 0000 1010 0101 0101 0101 1010 0110 0101 0110 1001 1001 1010 1010

Determining the length of each segment to be sent is done by looking at the sample rate. I used 44100 Hz, so the duration in micro seconds for the 30 sample space segment is 30 / 44100 * 1000000 = 680 µs. For the short 25 sample high, it is 567 µs, and double or 1134 µs for the long. When sending the message, I did not need to subtract anything from that, as Ray mentioned in his post. It is worth noting the initial high before the start of the message, and also at the end. Furthermore, it both starts and finishes with a low space, so whatever for-loop you create, one of these will be before or after. However, what is intriguing, is that all this can be reversed. That is, switch HIGH and LOW in the code, and the switches will still react. I’m guessing this is a robustness measure designed into the Everflourish system, but I have to admit that goes beyond my RF knowledge.

Finally, it’s worth mentioning the All On or All Off buttons. They simply send a series of messages for each of the buttons, repeating each button message four times before moving on to the next. When using the single on/off buttons, the message is also repeated four times for a short click.

And that’s all for now. I expect to round this project up with a post on the complete system, including communication from the computer, and some kind of Android application as a remote. Other ideas include auto-triggering the lights when detecting a pre-defined Bluetooth device, and possibly switching off in the absence of any device. Possibly some programmed behaviour during holidays, and pre-set configuration for certain situations, e.g. “movie setting”, “dinner time”, etc.

tags: , , , , , ,
1 comment...
2012-08-13 20:57

Autonomous Coaxial Helicopter – Stage 1

Comments Off
by havard    in Arduino, Radio-Control

Using the Double Horse 9053 Volitation (Revell “Big One Pro”) I wrote about earlier, I’ve now embarked on a project to make it an autonomous flying and stabilizing helicopter. (First let me have a rant at the term “Unmanned Aerial Vehicle” which is being thrown around. For model RC vehicles of any kind, it goes without saying that it is unmanned. Not even if a midget would fit in your model plane would you put him in there! So, UAV is a redundant non-descriptive term for most model aircraft. On the other hand, autonomous aerial vehicle would be a better term for what most hobbyists are trying to archive with “drones”). With that out of the way, let’s look at the technical details, and what lessons to take away so far.

The first step involves the Ultrasonic Range Finder I just got, pointing downwards to give hight information. To more easily mount that, and the Arudino, I put a whole blank PCB between the landing skids and helicopter body, as seen in the pictures above. Now, it doesn’t look pretty, and is adding unnecessary weight, but this is just a prototype so far. The PCB made it easy to route and solder a few extra wires, and also add a radio transmitter: The 433.92 MHz transmitter I got a while back, seen to the right in the close-up picture below.

Although the Double Horse 9053 Volitation is a medium to big coaxial model helicopter, it does not have much extra lift power. When loaded with the essential parts already mentioned, plus an extra LiPo battery to power it all, it would barely take off, and then just bounce along the ground. First lesson learnt; an extra battery is a no-go, so I would have to share power with the helicopter RC system and motors. That’s a 2 cell 7.4 V LiPo, so works for the Arduino, but hopefully I’ll be able to move to a 3 cell 11.1 V at some point. So far I’ve just soldered an extra wire onto the original helicopter board (right hand picture above). Long term, I’m planning to replace that board entirely. That should put the balancing right again, as now the whole setup got tail-heavy, and it’s actually difficult to pitch down.

Once the Arudino, range finder and radio link was mounted, I started programming everything. At this point, it wasn’t much code required, but it revealed a new point: When the Virtual Wire library is used to transmit the height information, it interferes with the reading from the range sensor. The VW library works with an interrupt routine, so maybe I could untangle it by avoiding the interrupt. The interesting bit is that the reading from the range sensor decreases the recorded distance. Intuitively, one would maybe have expected that the added delay from the interrupt would have caused the echo timing to be prolonged, whoever the opposite happens. With only the range sensor library active, I started with a distance of about 196 cm. That went down to ~166 cm once the vw_setup() routine was activated, and further down to ~155 cm once the vw_send() was used. Finally, the setup of the VW somehow obscured the pin mode setting from the Ultrasonic library, thus I had to re-set the in/out pins for the range finder after the vw_setup() call.

On the receiving end, I simply used a second Arduino, loaded with the VW Receiver example sketch. An obvious draw-back with this setup is that communication is one-way. The next step will probably be with something like the Xbee modules, which will hopefully speed up transmission as well.

#include "Ultrasonic.h"
#include <VirtualWire.h>
  
Ultrasonic ultrasonic(8,10);
  
void setup() {
  vw_setup(2000); // Bits per sec
  vw_set_tx_pin(2);
  
  // Re-set the pins for the range sensor
  pinMode(8, OUTPUT);
  pinMode(10, INPUT);
}
  
void loop() {
  long cm = ultrasonic.Ranging(CM);
  
  // Ignore invalid range readings
  if (cm > 2000) {
  return;
  }
  
  char msg[5];
  ltoa(cm, msg, 10);
  
  vw_send((uint8_t *)msg, strlen(msg));
  vw_wait_tx();
  
  delay(200);
}

tags: , , ,
Comments Off
2012-08-04 12:58

Sensors: Ultrasonic Range Finder

Comments Off
by havard    in Arduino

In yet another shipment from Deal Extreme, I picked up a HC-SR04 Ultrasonic Range Finder. It seems to be a widely used and supported component, as there are plenty of posts around, and several supporting libraries for Arduino. Usage was also dead simple, and accuracy and responsiveness is good. One data sheet claims 2 – 500 cm ranging distance, at a 0.3 cm resolution, while another mentioned only 4 meters. The results I’ve gotten seems to be in line with that.

Following Jax’ post, and downloading the small ITead Studio library, it was up and running at once. The Arudino sketch is no more than init and read in a loop:
#include "Ultrasonic.h"
 
Ultrasonic ultrasonic(12,13);
 
void setup() {
  Serial.begin(9600);
}
 
void loop() {
  Serial.print(ultrasonic.Ranging(CM));
  Serial.println(" cm");
 
  delay(100);
}

The only problem I sometimes detected, is that it will not always handle a sudden change in distance very well. Or possibly not detect the echo signal if facing a distant surface at a slight angle. However, even so, I find that it fails gracefully. The Ranging function above will output a “out of bounds” number (around 2400 cm) when it cannot detect an echo. It means there is a very clear boundary between valid readings at 2 – 400 cm and “failure code” at ~2400.

The next step, is now to mount this on to the model helicopter I just got, and see what we can get from there. Initially as a separate and independent payload, I assume, but maybe later integrated with the main control board for the motors.

For completeness, I’m including the two functions in the library above. As mentioned, it’s simple, and just implementing the timing functions described in the above data sheet.

long Timing() {
  digitalWrite(Trig_pin, LOW); delayMicroseconds(2);
  digitalWrite(Trig_pin, HIGH); delayMicroseconds(10);
  digitalWrite(Trig_pin, LOW);
  
  long duration = pulseIn(Echo_pin, HIGH);
  return duration;
}
  
long Ranging(int cm) {
  long duration = Timing();
  if (cm) {
    return duration / 29 / 2;
  else {
    return duration / 74 / 2;
  }
}

On a related note, there are plenty of range finders around, rated for different ranges and resolutions. Sparkfun has the Maxbotix ultrasonic line, as well as the commonly used Sharp IR Proximity sensors. The later are available in a wide range, from several retailers.

tags: , , ,
Comments Off
2012-07-03 20:53

Moving Parts – Part 1: Stepper motors

Comments Off
by havard    in Arduino

After the new Atmel ATMega was installed yesterday, I’m now ready to experiment with some stepper motors. First out, the Mercury Motor SM-42BYG011-25, a medium sized motor with quite a bit of torque and also half decent speed. Second, the smaller but much faster Mercury Motor ST-PM35-15-11C. Both driven by the small EasyDriver card, which really lives up to its name. After soldering on a few pins, it was literally plug & play. The eight-line example to get started could not be simpler.

There are of course plenty of experiments and tuning which can be done with this motors and the driver alone, so initially I had a look at the RPM speed. Here I was slightly puzzled to find that both performed very well, even though comments on the product page suggested the speeds I saw would be hard to reach. So if my calculations are off, please do add a comment below.

When using a 12 V power supply, and the dead simple example of write, delay, write delay (or rather delayMicroseconds()), I found that I could go as low as 90 microseconds with the bigger motor, or 180 µs for a complete pulse without it stalling. The example continues: “the Easy Driver will default to 1/8th microstep mode. That means that [for each pulse] the stepper motor will move 1/8th of a full step. So if your motor is 1.8 degrees per step, there will be 200 full steps per revolution, or 1600 microsteps per revolution”. At 180 µs per microstep, there is time for 5555 steps in a second, or 3.47 revolutions per seconds. That means 208 RPM. In summary:

1000000 µs / ( 2 * 80 µs ) / ( 360.0º / 1.8º * 8 ) * 60 = 208 RPM

Again, this seems surprisingly fast, and it’d be interesting to measure it using an external device. When I go down to 80 µs it starts to skip, and even lower it will stall.

For the smaller motor, I simply swapped the wires on the driver card (after the power supply had been turned off), and ran the same code. Here I could go as far down as 35 µs delay, or 70 µs per microstep. The motor has a step size of 7.5º, which means an RPM at 2230. It is indeed spinning very fast.

1000000 µs / ( 2 * 35 µs ) / ( 360.0º / 7.5º * 8 ) * 60 = 2230 RPM

Funny anecdote at the end: The smaller engine came pre-wired to a 4-pin plug, while the bigger simply had loose ends. When putting that together, I found myself comparing the two data sheets to get the correct wire order. Only problem being that the colour notation on the smaller was in Chinese. Luckily, the PDF had kept the text intact, including the Chinese characters. Copy/paste and Google Translate to the rescue, and I found which was which.

tags: , ,
Comments Off
2012-07-02 22:03

Burning a bootloader with the STK500v2

Comments Off
by havard    in Arduino

After picking up a few blank ATMega328P I was ready to upload the Arduino bootloader with the latest Olimex AVR-ISP500 USB STK500v2, but ran into a few issues. Here’s how it finally came together and worked: First, if programming with the chip in place in an Arudino Duemilanove, make sure the board has external DC power. Next, if burning through the Arduino IDE, amend the following sections to ../hardware/arduino/programmers.txt and ../hardware/arduino/board.txt. Finally, after restarting the IDE, make sure to select the newly added board, the correct serial (e.g. /dev/ttyACM0), and click on the newly added bootloader burn option. When failing, it took only a few seconds to give up, while the successful burn took about two minutes. Thanks to the unknown poster on the Sparkfun product page for these snippets.

programmers.txt
olimexisp.name=AVR ISP 500 Olimex
olimexisp.communication=serial
olimexisp.protocol=stk500v2

boards.txt
##############################################################
avr500atmega328.name=AVR500v2 programmer with ATmega328
avr500atmega328.upload.using=olimexisp
avr500atmega328.bootloader.low_fuses=0xFF
avr500atmega328.bootloader.high_fuses=0xDA
avr500atmega328.bootloader.extended_fuses=0x05
avr500atmega328.bootloader.path=atmega
avr500atmega328.bootloader.file=ATmegaBOOT_168_atmega328.hex
avr500atmega328.bootloader.unlock_bits=0x3F
avr500atmega328.bootloader.lock_bits=0x3F
avr500atmega328.build.mcu=atmega328p
avr500atmega328.build.f_cpu=16000000L
avr500atmega328.build.core=arduino
##############################################################

tags: , , ,
Comments Off
2011-11-05 21:19

RF Communication on 433.92 MHz

3 comments
by havard    in Arduino, electronics

I recently got a Sparkfun order on my door, so it’s time to play. In the box was a RF Link Transmitter, and Receiver. They are sold as 434 MHz radio wireless links. Others talk about 433 MHz. To be precise, it’s 433.92 MHz. That matters, because if you search for that number, you will find the so called home automation systems using that frequency, including X10, Everflourish, and many others. My plan then, is to build something similar to the TellStick from TellDus, which control these devices from my computer. Connect that up to an Android app, and I could control my lights and other appliances from any mobile phone.

First things first, though. Hooking up the bits was easy, following these two similar tutorials. Using the VirtualWire Arduino library v1.5 (1.6 released at the time of writing) by Mike McCauley (download version 1.5) transmitting data was a breeze. The library includes example code for transmitter and receiver, simply upload and go. Note that the transmitter data should be connected to pin 12 on the Arudino, and the receiver on pin 11 on the other. Data was received loud and clear, without errors. Mike’s library is well written, and covers several important aspects of RF communication, including a dedicated protocol, CRC handling, robust encoding over the air, baud rate, and to top it off, an easy to use API.

Now, of course when using my Everflourish nothing happened. Which was a good sign; it did not interfere with the Virtual Wire transmission. That remote is using a different protocol to talk to the light switches. Luckily, it has already been reversed engineered and the source code is available from TellDus. It will probably take some time to get this working. Meanwhile, some pictures.

tags: , , , , ,
3 comments!
2011-10-31 20:54

Arduino, Fedora 15, and the gpsd incompatibility

1 comment
by havard    in Arduino, Fedora

Even though the Arduino is very popular amongst makers and other electronics hobbyist, it is still a fringe platform in most settings. And even though the arduino package is available through many repositories, more testing would be welcome.

In the latest packages in Fedora 15, things have broken down in several ways. Tom Trebisky does a good job of guiding you through the pitfalls here. He has further useful notes on Arduino here.

What had me going mad was this message: “avrdude: stk500_recv(): programmer is not responding”. Everything seemed to be fine, the lights were blinking when connecting, the logs looked normal, and what’s more, all my boards worked when programmed on another system, but not on my Fedora 15 at home! Furthermore, the error seemed to be half sporadic. Sometimes it would fail at once, while other times it got a bit further before it stopped.

Tom writes: “On a hunch (having watched the messages via dmesg when I plug in my arduino) I get rid of gpsd“. And that was my problem as well. The gpsd daemon was some how conflicting with the ttyUSB device. One option to remove it would be

service gpsd stop
killall gpsd
yum erase gpsd

However, in my case I could not remove the gpsd package because it was a dependency of another application I wanted. In the end, I simply renamed the binary (/usr/sbin/gpsd), so it would not be automatically activated when I plug in the Arduino. Maybe not so elegant, but I could finally get to work with more fun stuff.

tags: , ,
1 comment...
2011-09-18 17:29

Arduino news

Comments Off
by havard    in Arduino

Some interesting news from Arudino yesterday:

  • Arduino 1.0, we finally froze the Arduino API, the IDE and the layout of the boards.
  • Arduino Leonardo, a low cost Arduino board with the Atmega32u4.
  • Arduino Due, a major breakthrough for Arduino because we’re launching an Arduino board with a 32bit Cortex-M3 ARM processor on it. We’re using the SAM3U processor from ATMEL running at 96MHz with 256Kb of Flash, 50Kb of Sram, 5 SPI buses, 2 I2C interfaces, 5 UARTS, 16 Analog Inputs at 12Bit resolution and much more.
  • Arduino Wifi Shield. It adds Wi-Fi communication capabilities to any Arduino.

Comments Off
2011-04-23 13:54

555 Contest

Comments Off
by havard    in Arduino

Evil Mad Scientist is showing some of the entries for the 555 Contest. There’s some great creations, but perhaps the most entertaining is the “Le Dominoux” (or “LED dominoes”) by Randy Elwin. Through a series of many light receivers & emitters, he creates a domino effects with lights. And when put in a loop, it “self sustains” the cascading effect. Genius!

Comments Off
2011-04-10 10:21

Teensy USB Development Board

Comments Off
by havard    in Arduino

The Teensy is a complete USB-based microcontoller development system, in a very small footprint. It is similar to Arduino boards in that it uses an ATMEGA Atmel AVR processor, however not compatible. Even so, there is a software add-on for the Arduino IDE. They claim the USB communication is faster than the Arduino, since the the later uses USB-to-serial communication. As far as I understand, that is also the case with the new Arduino Uno.

The Teensy boards are much smaller than the basic Arduino boards, but still features a mini USB port. It is also available with header pins to fit on a bread board. PJRC lists a number of fun projects using the Teensy.

tags: ,
Comments Off
Older Posts »

Bad Behavior has blocked 339 access attempts in the last 7 days.