Finding a Simple IR send and receive

I need to send a small set of integers over IR, say, {17, 1, 2, 3, 2, 1, 9}, between two identical devices.
(it could be a string if it has to be, or a set of characters, anything! I'll sort that out)

I've been using IRLib2 (the newer IR remote rewrite)

I've experimented with the rawSend and rawRecv functionality, as well as the Sony and NEC protocols, I've read much of the library documentation, forums, and the issue requests.

It doesn't need to work with a television, or remote, or anything, just another of itself. I'm toggling the [.enableIRIn();], it can send, things, receive things, but never what was actually sent.

What is the the simple, reliable, way to encode a set of integers into timing logic... and decode them on the other side!?

I've been at this for several months now, what is the correct approach? :confused:

This Serial IR thread may help.

...R
Serial Input Basics - simple reliable ways to receive data.

There's some great information in those, but I'm not sure they'll work. Namely, I'm not trying to run a continuous serial link or anything complicated, but it does need to be two ways.

I've slimmed up the hardware/firmware to show where I'm coming from:

Those devices each have an IR LED and an IR receiver.
The LED is on Digital Pin 3
The Receiver is on Digital pin 11

(IR LED's seem to need to be on Pin 3 on an Uno for most IR Libraries)

Here's a code snippet for what I'm working with:

//Some of these are redundant, but I'll cull that later, I guess
#include "IRLib2.h"
#include <IRLibSendBase.h>
#include <IRLibRecvPCI.h> 
#include "IRLibRecv.h"
#include <IRLib_HashRaw.h>
#include <IRLibCombo.h> 

// IR System Config
const int infraredRecieverPin = 11; // Signal Pin of IR receiver to Arduino Digital Pin 11
IRrecv irrecv(infraredRecieverPin);     // create instance of 'irrecv'
IRsendRaw irsend;
IRdecode infraredResults;      // create instance of 'handle_results'


//This is the Package, it seems to behave better when its bigger
//So I made it bigger for now
#define RAW_DATA_LEN 100
uint16_t rawData[RAW_DATA_LEN]={
1, 2, 3, 4, 5, 6, 7, 8, 9, 
10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 
20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 
30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 
40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 
50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 
60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 
70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 
80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 
90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 
100};




void setup()
{
  // Initiate Communcation with Bluetooth card and Debug device
  Serial.begin(9600);
  irrecv.enableIRIn(); // Start the receiver
  
    Serial.println("Starting Up!");
}


void loop()
{
  //////////////////////////
  ///// SENDING /////
  /////////////////////////
  if (Serial.read() != -1)
  {
    //send a code every time a character is received from the 
    // serial port. You could modify this sketch to send when you
    // push a button connected to an digital input pin.
    irsend.send(rawData,RAW_DATA_LEN,38);//Pass the buffer,length, optionally frequency
    
    delay(1000);//Wait a moment before listening again
    irrecv.enableIRIn(); // Restart the receiver
    
    Serial.println(F("Sent signal."));
  }

  //////////////////////////
  ///// RECEIVING /////
  /////////////////////////
  if (irrecv.getResults())
  {
    Serial.println("Incoming IR: ");
    
    for(bufIndex_t i=1;i<recvGlobal.recvLength;i++) {
      Serial.print(recvGlobal.recvBuffer[i],DEC);
      Serial.print(F(", "));
      if( (i % 8)==0) Serial.print(F("\n\t"));
      delay(100); //Slows down the print out, just in case there's buffer shenanigans
    }
    
    Serial.println("<END>");
    irrecv.enableIRIn();
  }  
  
}

I tend to get radically different numbers than go in, sometimes getting one large number, rather than the set. I'm just trying to find a method to get consistently good IR transmissions.

Update here:

After some tweaking with the values for the rawSend function, it now sends a set of data (yay!). And gets it pretty wrong, each time (aww). for instance:

This:
1234567890, 5678, 9100, 6666, 1, 2, 3, 4,
500, 600, 500, 650, 450, 650, 500, 600,
500, 1700, 450, 650, 500, 600, 500, 600,
500, 600, 500, 1700, 500, 1700, 500, 600

Magically became:
650, 5750, 8950, 6750, 450, 650, 450, 750,
350, 700, 450, 650, 450, 1800, 350, 700,
450, 700, 400, 700, 400, 700, 400, 1800,
450, 1750, 450

Super long, and super short numbers all get squished. The last number gets dropped, and it really likes 3-4 digit numbers that end in 50. Is this a bit thing? why is it so close, and so... consistent in its wrongness?

In raw send you don't specify values to be transmitted,
but you specify the length of each LOW and HIGH that will be transmitted.

There are a couple of encodings for the real data that gets transmitted, like Sony or NEC.

Transmit your values one after anuther using such a protocol, drop the "raw send all at once" idea.

Loremage:
There's some great information in those, but I'm not sure they'll work. Namely, I'm not trying to run a continuous serial link or anything complicated, but it does need to be two ways.

None of the examples assumes a continuous link. Just send data when you want to.

If you need two-way communication then you MUST have a sender and receiver at both ends.

...R

Well, you were both absolutely right, I'm using NEC encoding now, it's the better way to do it. My failure was that I didn't recognize that this "0x61a0f00f" is a 32 bit Hexadecimal code. Now the built in timing protocols make way more sense.

I'm sure I can figure out converting the hex back and forth.

Thanks so much for the help!