Existing repositories with working libraries wouldn't be penalized unless they move to this repository because they would be less "official" than the others ?

My thoughts exactly. I've put my own libraries on bitbucket.org only last week, because I've experience with Mercurial, not with Git. Other people might prefer SVN. Or Bazaar. Or none at all. Can you make sure these are deemed equally "official" as the libraries on the Git repository?

Also, and perhaps I'm not well informed, but I'd like to see a more extended and standardized way to integrate a reference of third-party libraries in the IDEs. I think that's more beneficial for the users of the library than a large GIT repository, which might be quite alien for beginners.

Finally, my project is a package of libraries, which can be used stand-alone but work nicely together. Would such package-construct fit in your ideas of the repository?

Ah, I was afraid it would be something like that :'(. Thanks for clearing it up tho!

Since Arduino is based on C++, I've tried to use some exception handling, try {} catch () {}, etc. Unfortunately, the compiler refused, suggested that I should use the -fexceptions argument. In the GCC-docs I read that exception handling usually is enabled when using .cpp-files, so I tried to put the exception handling in a .cpp-file and include it in the main sketch. Too bad, I got the same compiler-error.

There are of course drawbacks to exception handling, as it leads to larger program code, so I can understand why it is disabled. But, apart from altering the Arduino-code, is there a way to enable exception handling? Or is there something that technically prevents exception handling somewhere?

[receiving]

@Morphor: I don't have a clue why it doesn't work. If you happen to have a second arduino, you could use show_received_code to verify that the arduino-synthesized code is identical to the real remote.
An digital oscilloscope or data logger is quite handy in this kind of situations, as you can monitor the actual inputs and outputs of the transmitter and receiver.

@DARRELL: have a look at the Retransmitter-example, which simply retransmits a (recognized) received code.

For transmission you don't need special interrupts, other than the one Arduino uses for delay(). But that one is standard anyway.

Relevant code sniplet, based on the example:

#include <RemoteSwitch.h>
...
unsigned long code;
  
code = receivedCode;
code |= (unsigned long)period << 23;
code |= 3L << 20;
RemoteSwitch::sendTelegram(code,11);

This will transmit a signal on pin 11, where receivedCode and period are the values you've already found.

@Marlar:  "device", "address" etc are arbitrary terms used by the remotes themselves. They are all based on the PT2262-technique, and thus have 12 trits data words.
KaKu for example designates 4 trits for "group", and 4 trits for "device". But other marques use different trits, don't have groups at all or use the term "address".

@All:

The information in the start post is a bit outdated, but I can't edit it anymore. The current version 2.0 of the library (same link) is capable of receiving codes as well, with apart from the 433MHz-receiver no extra hardware at all! Included in the library are some examples and a photo of the (very easy) set-up.  

Its not at all clear to me what the protocol is, I wonder if fuzzilogic can say more about it.

I don't know about wireless X10 (is it standardized?), but these remotes use chips like the LP801B,  HX2262, PT2262 and M3E. The datasheet of the PT2262 explains the underlaying protocol.

Here in the Netherlands several stores sell RF remote switches, so you can switch lights etc. using a RF remote control. These remotes operate at 433MHz.

A while ago, I made a simple library to be used in conjunction with the common 433MHz RF modules to simulate these remotes, and to use an Arduino board to switch my lights. The library can simulate various remotes sold here in the Netherlands. These remote all use the same principles, and vary only in timing and specific codes. The base class can easily be extended to accomodate other (similar) remotes.

I really have no idea if these kind of products sold elsewere use the same principles. Perhaps they operate at different frequencies (868MHz?), which might work well.

Download: http://randysimons.com/overige/browsable/433MHz/ArduinoRemoteSwitchLibrary.7z

Basic setup:


Some images of compatbile devices:


I also have a sketch to receive and decode these signals on the arduino, but this requires some extra hardware. (scheme, photo). However, some comments in this code is in Dutch...

I've been experimenting with timers as well, but I couldn't get the above code to work. The reason: the code is for the Atmega8, while new Arduino boards come with a Arduino168. Slight difference.

To prevent other people who use the search to step into the same pitfall, here's the minimalistic code I came up with:

Code:

#include <avr/interrupt.h>  
#include <avr/io.h>

//Timer2 overflow interrupt vector handler, called (16,000,000/256)/256 times per second
ISR(TIMER2_OVF_vect) {
  //let 10 indicates interrupt fired
  digitalWrite(10,true);
};  

void setup() {
  pinMode(9,OUTPUT);
  pinMode(10,OUTPUT);

  //Timer2 Settings: Timer Prescaler /256, WGM mode 0
  TCCR2A = 0;
  TCCR2B = 1<<CS22 | 1<<CS21;

  //Timer2 Overflow Interrupt Enable  
  TIMSK2 = 1<<TOIE2;

  //reset timer
  TCNT2 = 0;

  //led 9 indicate ready
  digitalWrite(9,true);
}

void loop() {
}

This is for the Atmega168-arduino's! And for the record: I'm using Arduino IDE v0008, and firmware v1.15.

When run, a led (or whatever) connected on pin 9 lights directly after initalisation. When the timer fires, led 10 lights up. The timer is repetitive, it keeps firing.

I'm aware of the FrequencyTimer2 lib, but this code is a bit more compact and doesn't use the PWM-mode. People who need to generate a pulse/clock on the output should definately have a look at the FT2-lib.

Something to nag: the AVR-libc documents mention that SIGNAL(SIG_OVERFLOW0) is deprecated, in favour for ISR(TIMER0_OVF_vect).

On a sidenote: these documents are bundled with Arduino, which is great. The Arduino-reference does mention it (should have known earlier though  ), but it links to the online version of the AVR libc manual. For compatibility reasons between the actual library and the documentation, perhaps it's better to point to the bundled documents?