IR / RF 433 MHz blaster with SD card or I2C EEPROM memory

[lasso]

Hi,
I would like to make IR / RF 433 MHz Sensor with EEPROM / SD card memory.
Features of this sensor:

• Sending out and getting codes:
  • IR codes using IRLib or IRremote libraries.
    I have UPC Philips PVR decoder. IR codes from remote of this decoder are not recognized by IRLib and IRremote libraries and are saved as RAW codes. These RAW codes take up much space. Problem is that IRLib and IRremote can't save long RAW codes. This problem is described in Martin's blog. Martin has edited IRremote library to get long IR signal. I managed to do the same with IRremote library and I could getting long raw codes from my remote. Code which I received I send out using IR LED and IRLib. Here is the sketch. I tried to get long RAW codes with IRLib but without success, because I can get only the first half of RAW code. The second half of the code which is copy of the first half of the code is not received. Even I tried to introduce some change in IRLib.cpp, but it does not change anything. Diff of IRLib.cpp is here. Maybe I have to make other changes in code?
  • RF 433 MHz codes to turn on/off sockets like this using that library. I wrote this sketch with Hek’s help. Using this sketch I can get and send out codes from/to remote to turn on/off sockets. Example of this code is: “356428203”, where 3 last digits are period of sending code.

I would like to keep RAW IR codes on the side MySensors node. I wonder if use EEPROM memory 24LC512 or micro SD card with this adapter.
24LC512 EEPROM memory VS SD card:

• Pros for 24LC512 EEPROM:

• I2C interface
  SD card uses SPI interface like NRF24L01. It may causing conflict with NRF24L01.

• Library for I2C EEPROM takes less memory than SD library

• EEPROM is cheaper than SD card and adapter.

• Pros for SD card:

• Faster than EEPROM

• Easier to use, because don’t need to implement more complex algorithm for EEPROM memory management.

• It is possibility to easy access data from SD on PC. For example to make a backup.

• Much more space than EEPROM (e.g. 2 GB vs 64 KB. One RAW code is about 250 bytes)

I think about communication between gateway – IR/RF node.
There will be 3 scenarios:

• IR/RF node -> gateway
  Received new code from IR/RF sensor
  Message structure:
  radioID; childID; messageType; subType; payload
  IR/RF node ID; childID; Set Variable; V_IR_RECEIVE; 0 - RAW/1 - NEC/2 - Sony/3 -RC5/4 -RC6/5 - JVC/6- NECx,7 - Panasonic_old, 8 – RF433 code, Code_length, code
  If type of code is RAW, sending code is hash.
• Gateway -> IR/RF node
  Send out IR/RF signal.
  Message structure:
  radioID; childID; messageType; subType; payload
  IR/RF node ID, childID; Set Variable; V_IR_SEND; 0 - RAW/1 - NEC/2 - Sony/3 -RC5/4 -RC6/5 - JVC/6- NECx,7 - Panasonic_old, 8 – RF433 code, code
• Gateway -> IR/RF node
  Save last received RAW code to node’s memory
  radioID; childID; messageType; subType; payload
  IR/RF node ID, childID; Set Variable; V_IR_SAVE; 0
• Gateway -> IR/RF node
  Erase specific RAW code from node’s memory
  radioID; childID; messageType; subType; payload
  IR/RF node ID, childID; Set Variable; V_IR_ERASE; code

Data stored on a node’s memory:

• Hash of RAW code
• Code

Data stored in Ago Control’s json database:

• nodeID
• childID
• Internal ID of virtual device, e. g.: TV Samsung, AV receiver, air conditioner…
• Code type: 0 - RAW/1 - NEC/2 - Sony/3 -RC5/4 -RC6/5 - JVC/6- NECx,7 - Panasonic_old, 8 – RF433 code
• Code(if RAW – hash of code)

In Ago Control I plan to add IR/RF plugin. Using this plugin I could:

• Adding and removing devices (e. g. TV) with push buttons
• Learn codes from getting messages
• Saving and removing RAW codes from node’s memory (Not directly but when push button with RAW code is added or removed from ago control database)

Currently I’m more inclined to use SD memory, but I doubt if SD library fits to Arduino flash memory. In addition, I wonder if there will be SPI interface conflict between SD card and NRF24L01.

What do you think about my idea?

[steets250]

Please let me know if you have any success with Vera using my sensors to send an IR command. I tried for a while. but had no luck. Part of the topic got removed in the forum crash, but hopefully this will help you get started. http://forum.mysensors.org/topic/146/building-an-ir-blaster/

[Zeph]

@lasso said:

Currently I’m more inclined to use SD memory, but I doubt if SD library fits to Arduino flash memory. In addition, I wonder if there will be SPI interface conflict between SD card and NRF24L01.

How many codes do you need, and how long are their RAW values?

You might be able to fit them into PROGMEM using less space than the SD library would take, and far less RAM.

If you need external memory I'd consider something like this http://www.digikey.com/product-search/en?mpart=W25X40CLSNIG&vendor=256

It's very cheap, pretty fast, has plenty of memory for this application (or 8 Mbit for 43c), and has predictable timing. One problem with SD cards is that they are so busy behind the scenes, you can have unexpectedly long delays at unpredictable times.

It is SPI, but as I understand it, that can be dealt with by (1) seeing that both the radio and the device use the same mode, or being sure to reset the mode appropriately when starting to use one or the other, and (2) being careful about using SPI inside interrupts. Either don't do it, or be sure the other SPI device inhibits problematic interrupts while it's doing SPI transactions. That goes for SD as well.

[steets250]

@lasso Instead of storing raw codes, you could also try using pronto codes for some of your IR devices. The pronto codes will take up less space than the longer raw codes.

[Zeph]

@steets250 said:

Instead of storing raw codes, you could also try using pronto codes for some of your IR devices. The pronto codes will take up less space than the longer raw codes.

First, the long form Pronto codes and the irRemote library raw buffer both use 2 byte values to store on and off times, so they should in most cases be approximately the same length (Pronto codes have 8 bytes of additional header). (Of course if you stored Pronto codes in hex format they'd be much longer).

And in order to use irRemote to send the pulses, it will need the raw buffer values in its expected format.

I suspect one could translate stored Pronto codes into raw values in the sensuator node before calling the library, but if the Pronto code is no shorter, why not simply store the raw codes instead?

It might even be possible to modify the irRemote library to send values using timing directly from PROGMEM, and not even need the RAM to buffer the raw codes (when only sending).