You won't get a good picture with 64 pixels.

with the 40° version @2m distance you'll get a horizontal view of 1,46 mt, so about 9 squared centimeters per pixel
with the 60° version @2m distance you'll get a horizontal view of 2,31 mt, so about 14 squared centimeters per pixel

I'm not familiar with lenses for this type of sensors, so nothing I can say about this could help you... I just know that the mlx90620 works just fine without them. I don't know if particular lens exists and could help to narrow the FOV

Hi all
I am trying to communicate using SPI protocol between two arduino uno boards. I have writthen a very simple code to transfer a single character from master. The code is as following

#include <SPI.h>
#include "pins_arduino.h"

void setup (void)
{
}


void loop (void)
{

 
  digitalWrite(SS, HIGH);  // ensure SS stays high

  SPI.begin ();

  delay (5000);  // 5 seconds delay to start logic analyser.
 
  // enable Slave Select
  digitalWrite(SS, LOW);    // SS is pin 10
 
  // send test string
    SPI.transfer ( 'c');

 // disable Slave Select
 digitalWrite(SS, HIGH);

 // turn SPI hardware off
 SPI.end ();
 
 while (1);  //loop
}

Please correct the code if its not right. And I really want to know that how to recieve that character on arduino uno in slave mode. There is a command SPI.transfer() to send data on SPI where as I haven't seen any command to recieve it.

Thanks and regards

Hi, wrong topic...

Hi,

anyone who can tell me if i should use the 60° or 40° FOV??
And should i need a Lens?


Thanks a lot.

Cu kami

it depends on your intended application, and which one you can find (I was looking for the 40° version but futureelectronics had only the 60° one, so I bought that...)

yes, of course

Now I'm going to paste here your code modified, with some comments here and there.
It's far from being perfect, but now it seems to work a lot better, at least for me 

Code:

/*
 * Attention! I commented out the alpha_ij array, so if you're going to compile the sketch you'll get for sure an error.
 * You should replace all 64 values with the alpha_ij calculated using the values stored in your MLX90620's EEPROM.
 * I suggest you to make an EEPROM dump, print it on the Serial port and store it in a file. From there, with the help of a spreadsheet (Libreoffice, Google Docs, Excel...) calculate your own alpha_ij values.
 * Please also pay attention to your emissivity value: since in my case it was equal to 1, to save SRAM i cut out that piece of calculation. You need to restore those lines if your emissivity value is not equal to 1.
 */

#include <i2cmaster.h>

int freq = 16;  //Set this value to your desired refresh frequency

int IRDATA[64];
byte CFG_LSB, CFG_MSB, PTAT_LSB, PTAT_MSB, CPIX_LSB, CPIX_MSB, PIX_LSB, PIX_MSB;
int PIX, v_th, CPIX;
float ta, to, emissivity, k_t1, k_t2;
float temperatures[64];
int count=0;
unsigned int PTAT;
int a_cp, b_cp, tgc, b_i_scale;

int a_ij[64];
int b_ij[64];
//float alpha_ij[64] = {1.591E-8, 1.736E-8, 1.736E-8, 1.620E-8, 1.783E-8, 1.818E-8, 1.992E-8, 1.748E-8, 1.864E-8, 2.056E-8, 2.132E-8, 2.033E-8, 2.097E-8, 2.324E-8, 2.388E-8, 2.161E-8, 2.155E-8, 2.394E-8, 2.353E-8, 2.068E-8, 2.353E-8, 2.633E-8, 2.708E-8, 2.394E-8, 2.499E-8, 2.778E-8, 2.731E-8, 2.580E-8, 2.539E-8, 2.796E-8, 2.871E-8, 2.598E-8, 2.586E-8, 2.801E-8, 2.830E-8, 2.633E-8, 2.609E-8, 2.894E-8, 2.924E-8, 2.633E-8, 2.464E-8, 2.778E-8, 2.894E-8, 2.673E-8, 2.475E-8, 2.737E-8, 2.796E-8, 2.679E-8, 2.394E-8, 2.708E-8, 2.714E-8, 2.644E-8, 2.347E-8, 2.563E-8, 2.493E-8, 2.388E-8, 2.179E-8, 2.440E-8, 2.504E-8, 2.295E-8, 2.033E-8, 2.283E-8, 2.295E-8, 2.155E-8};  //<-- REPLACE THIS VALUES WITH YOUR OWN!
//float v_ir_off_comp[64];  //I'm going to merge v_ir_off_comp calculation into v_ir_tgc_comp equation. It's not required anywhere else, so I'll save 256 bytes of SRAM doing this.
float v_ir_tgc_comp[64];
//float v_ir_comp[64]; //removed to save SRAM, in my case v_ir_comp == v_ir_tgc_comp



void config_MLX90620_Hz(int Hz){
  byte Hz_LSB;
  switch(Hz){
    case 0:
      Hz_LSB = B00001111;
      break;
    case 1:
      Hz_LSB = B00001110;
      break;
    case 2:
      Hz_LSB = B00001101;
      break;
    case 4:
      Hz_LSB = B00001100;
      break;
    case 8:
      Hz_LSB = B00001011;
      break;
    case 16:
      Hz_LSB = B00001010;
      break;
    case 32:
      Hz_LSB = B00001001;
      break;
    default:
      Hz_LSB = B00001110;
  }
  i2c_start_wait(0xC0);
  i2c_write(0x03);    
  i2c_write((byte)Hz_LSB-0x55);
  i2c_write(Hz_LSB);  
  i2c_write(0x1F);  
  i2c_write(0x74);  
  i2c_stop();
}

void read_EEPROM_MLX90620(){
  byte EEPROM_DATA[256];
  i2c_start_wait(0xA0);    
  i2c_write(0x00);
  i2c_rep_start(0xA1);
  for(int i=0;i<=255;i++){
    EEPROM_DATA[i] = i2c_readAck();
  }
  i2c_stop();
  varInitialization(EEPROM_DATA);
  write_trimming_value(EEPROM_DATA[247]);
}

void write_trimming_value(byte val){
  i2c_start_wait(0xC0);
  i2c_write(0x04);
  i2c_write((byte)val-0xAA);
  i2c_write(val);  
  i2c_write(0x56);  
  i2c_write(0x00);  
  i2c_stop();
}

void calculate_TA(){
  ta = (-k_t1 + sqrt(square(k_t1) - (4 * k_t2 * (v_th - (float)PTAT))))/(2*k_t2) + 25; //it's much more simple now, isn't it? :)
}

void calculate_TO(){
  float v_cp_off_comp = (float) CPIX - (a_cp + (b_cp/pow(2, b_i_scale)) * (ta - 25)); //this is needed only during the to calculation, so I declare it here.
  
  for (int i=0; i<64; i++){
    v_ir_tgc_comp[i] = IRDATA[i] - (a_ij[i] + (float)(b_ij[i]/pow(2, b_i_scale)) * (ta - 25)) - (((float)tgc/32)*v_cp_off_comp);
    //v_ir_comp[i]= v_ir_tgc_comp[i] / emissivity; //removed to save SRAM, since emissivity in my case is equal to 1.
    //temperatures[i] = sqrt(sqrt((v_ir_comp[i]/alpha_ij[i]) + pow((ta + 273.15),4))) - 273.15;
    temperatures[i] = sqrt(sqrt((v_ir_tgc_comp[i]/alpha_ij[i]) + pow((ta + 273.15),4))) - 273.15; //edited to work with v_ir_tgc_comp instead of v_ir_comp
  }
}


void read_IR_ALL_MLX90620(){
  i2c_start_wait(0xC0);
  i2c_write(0x02);      
  i2c_write(0x00);    
  i2c_write(0x01);      
  i2c_write(0x40);      
  i2c_rep_start(0xC1);
  for(int i=0;i<=63;i++){
    PIX_LSB = i2c_readAck();
    PIX_MSB = i2c_readAck();
    IRDATA[i] = (PIX_MSB << 8) + PIX_LSB;
  }
  i2c_stop();
}

void read_PTAT_Reg_MLX90620(){
  i2c_start_wait(0xC0);
  i2c_write(0x02);
  i2c_write(0x90);
  i2c_write(0x00);
  i2c_write(0x01);
  i2c_rep_start(0xC1);
  PTAT_LSB = i2c_readAck();
  PTAT_MSB = i2c_readAck();
  i2c_stop();
  PTAT = ((unsigned int)PTAT_MSB << 8) + PTAT_LSB;
}

void read_CPIX_Reg_MLX90620(){
  i2c_start_wait(0xC0);
  i2c_write(0x02);
  i2c_write(0x91);
  i2c_write(0x00);
  i2c_write(0x01);
  i2c_rep_start(0xC1);
  CPIX_LSB = i2c_readAck();
  CPIX_MSB = i2c_readAck();
  i2c_stop();
  CPIX = (CPIX_MSB << 8) + CPIX_LSB;
}

void read_Config_Reg_MLX90620(){
  i2c_start_wait(0xC0);
  i2c_write(0x02);
  i2c_write(0x92);
  i2c_write(0x00);
  i2c_write(0x01);
  i2c_rep_start(0xC1);
  CFG_LSB = i2c_readAck();
  CFG_MSB = i2c_readAck();
  i2c_stop();
}

void check_Config_Reg_MLX90620(){
  read_Config_Reg_MLX90620();
  if ((!CFG_MSB & 0x04) == 0x04){
    config_MLX90620_Hz(freq);
  }
}

void varInitialization(byte EEPROM_DATA[]){
  v_th = (EEPROM_DATA[219] <<8) + EEPROM_DATA[218];
  k_t1 = ((EEPROM_DATA[221] <<8) + EEPROM_DATA[220])/1024.0;
  k_t2 =((EEPROM_DATA[223] <<8) + EEPROM_DATA[222])/1048576.0;
  
  a_cp = EEPROM_DATA[212];
  if(a_cp > 127){
    a_cp = a_cp - 256;
  }
  b_cp = EEPROM_DATA[213];
  if(b_cp > 127){
    b_cp = b_cp - 256;
  }
  tgc = EEPROM_DATA[216];
  if(tgc > 127){
    tgc = tgc - 256;
  }

  b_i_scale = EEPROM_DATA[217];

  emissivity = (((unsigned int)EEPROM_DATA[229] << 8) + EEPROM_DATA[228])/32768.0;

  for(int i=0;i<=63;i++){
    a_ij[i] = EEPROM_DATA[i];
    if(a_ij[i] > 127){
      a_ij[i] = a_ij[i] - 256;
    }
    b_ij[i] = EEPROM_DATA[64+i];
    if(b_ij[i] > 127){
      b_ij[i] = b_ij[i] - 256;
    }
  }
}

void Temperatures_Serial_Transmit(){
  for(int i=0;i<=63;i++){
    Serial.println(temperatures[i]);
  }
}

void setup(){
  pinMode(13, OUTPUT);
  Serial.begin(115200);
  i2c_init();
  PORTC = (1 << PORTC4) | (1 << PORTC5);
  delay(5);
  read_EEPROM_MLX90620();
  config_MLX90620_Hz(freq);
}

void loop(){
  if(count ==0){ //TA refresh is slower than the pixel readings, I'll read the values and computate them not every loop.
    read_PTAT_Reg_MLX90620();
    calculate_TA();
    check_Config_Reg_MLX90620();
  }
  count++;
  if(count >=16){
    count = 0;
  }
  read_IR_ALL_MLX90620();
  read_CPIX_Reg_MLX90620();
  calculate_TO();
  Temperatures_Serial_Transmit();
}

These small modifications made a substantial difference in the final results. I had a lot of noise before, and now it's much more precise in every reading, almost perfect!
I also got a substantial framerate improvement, from the initial 12Hz (with 50KHz I2C) to 20 Hz now.
It is possible to speed up everything by making a computer do all the calculation, and passing just the IRDATA + CPIX and PTAT info. I reached 87Hz that way!
I think this is everything, I hope it will be useful for at least someone!
Bye,
Alessandro.

Hi maxbot,
thank you very much for your code, it's been a great starting point, but I found some bugs in it.
I'll share here everything I have found, hoping that it could help other people.
I'm going to quote every piece of code and comment it, and afterwards (next post, there's 9500 char limit per post!) I'll paste a similar code with all the corrections in it.
Please don't take this in the wrong way, I'm not trying to discredit your work, I'm just trying to help someone else who could experience the same issues I had.

Code:

#include <i2cmaster.h>

int IRDATA[64];
word EEPROM_DATA[256];
byte CFG_LSB, CFG_MSB, PTAT_LSB, PTAT_MSB, CPIX_LSB, CPIX_MSB, PIX_LSB, PIX_MSB, EEDATA2;
int PIX, CPIX, PTAT, CFG;
double ta, to;
double temperatures[64];

EEPROM_DATA is an array of bytes, not words.
Let's declare it as an array of bytes, we'll save 256 bytes (on 2048 available, it makes substantial difference!)
EEDATA2 and CFG are not used inside the code, so I'm going to get rid of them.
Double and float in arduino are the same, but some functions require only floats.

Code:

void config_MLX90620_16Hz(){ //Sets the To-Refresh rate to 16Hz
  i2c_start_wait(0xC0);
  i2c_write(0x03);    
  i2c_write(0xB5);
  i2c_write(0x0A);  
  i2c_write(0x1F);  
  i2c_write(0x74);  
  i2c_stop();
}

void config_MLX90620_8Hz(){ //Sets the To-Refresh rate to 8Hz
  i2c_start_wait(0xC0);
  i2c_write(0x03);    
  i2c_write(0xB6);
  i2c_write(0x0B);  
  i2c_write(0x1F);  
  i2c_write(0x74);  
  i2c_stop();
}

Nothing wrong here. It's however possible to declare a unique function and pass the refresh rate as a parameter.
It makes the code smaller and it allows to easily choose the frequency to work with.

Code:

void read_EEPROM_MLX90620(){
  i2c_start_wait(0xA0);    
  i2c_write(0x00);
  i2c_rep_start(0xA1);
  int i;
  for(i=0;i<=255;i++){
    EEPROM_DATA[i] = i2c_readAck();
  }
  i2c_stop();
}

ok.

Code:

void calculate_TA(){
  double v_th, k_t1, k_t2;
  v_th = (double) (256 * EEPROM_DATA[219]) + EEPROM_DATA[218];
  if(v_th > 32767){
    v_th = v_th - 65536;
  }
  k_t1 = (double) ((256 * EEPROM_DATA[221]) + EEPROM_DATA[220])/1024;
  if(k_t1 > 32767){
    k_t1 = k_t1 - 65536;
  }
  k_t2 = (double) ((256 * EEPROM_DATA[223]) + EEPROM_DATA[222])/1048576;
  if(k_t2 > 32767){
    k_t2 = k_t2 - 65536;
  }
  ta = (double) (-k_t1 + sqrt(square(k_t1) - (4 * k_t2 * (v_th - PTAT))))/(2*k_t2) + 25;
  Serial.println(ta);
}

Here you're declaring v_th, k_t1 and k_t2 and calculating them in every call of calculate_TA() function.
It is correct, but computationally inefficient. Those are constants, there's no need to calulate them in every loop iteration.
 

Code:

void calculate_TO(){
  double v_ir_off_comp, v_ir_tgc_comp, v_ir_comp, v_cp_off_comp, emissivity, alpha_ij;
  int a_cp, b_cp, a_ij, b_ij, tgc;
  for(int i=0;i<=63;i++){
    if(IRDATA[i] > 32767){
      IRDATA[i] = IRDATA[i] - 65536;
    }
    a_cp = EEPROM_DATA[212];
    if(a_cp > 127){
      a_cp = a_cp - 256;
    }
    b_cp = EEPROM_DATA[213];
    if(b_cp > 127){
      b_cp = b_cp - 256;
    }
    v_cp_off_comp = (double) CPIX - (a_cp + (b_cp/pow(2,EEPROM_DATA[217])) * (ta - 25));
    a_ij = EEPROM_DATA[i];
    if(a_ij > 127){
      a_ij = a_ij - 256;
    }
    b_ij = EEPROM_DATA[64+i];
    if(b_ij > 127){
      b_ij = b_ij - 256;
    }
    v_ir_off_comp = (double) IRDATA[i] - (a_ij + (b_ij/pow(2,EEPROM_DATA[217])) * (ta - 25));
    tgc = EEPROM_DATA[216];
    if(tgc > 127){
      tgc = tgc - 256;
    }
    v_ir_tgc_comp = (double) v_ir_off_comp - ((tgc/32)*v_cp_off_comp);
    emissivity = (double) ((256*EEPROM_DATA[229]) + EEPROM_DATA[228])/32768;
    v_ir_comp = (double) v_ir_tgc_comp / emissivity;
    alpha_ij = 0.0000000232776;
    temperatures[i] = (double) sqrt(sqrt((v_ir_comp/alpha_ij) + pow((ta + 273.15),4))) - 273.15;
  }
}

Like the piece of code above, there's no need to declare and calculate a_cp, b_cp, a_ij, b_ij and emissivity on every call.
It can be done once for all in the setup() function.
I don't understand why you set alpha_ij to a constant value, it should be calculated for every pixel like a_ij and b_ij.
I see that the arduino is not capable to do calculation with such small numbers, but I really suggest to do them by hand (or with the help of a spreadsheet) and paste them into the code
This parameter influences a lot the results of the readings.

Code:

void read_IR_ALL_MLX90620(){
  i2c_start_wait(0xC0);
  i2c_write(0x02);      
  i2c_write(0x00);    
  i2c_write(0x01);      
  i2c_write(0x40);      
  i2c_rep_start(0xC1);
  int i;
  for(int i;i<=63;i++){
    PIX_LSB = i2c_readAck();
    PIX_MSB = i2c_readAck();
    IRDATA[i] = (PIX_MSB << 8) + PIX_LSB;
  }
  i2c_stop();
}

void read_PTAT_Reg_MLX90620(){
  i2c_start_wait(0xC0);
  i2c_write(0x02);
  i2c_write(0x90);
  i2c_write(0x00);
  i2c_write(0x01);
  i2c_rep_start(0xC1);
  PTAT_LSB = i2c_readAck();
  PTAT_MSB = i2c_readAck();
  i2c_stop();
  PTAT = (PTAT_MSB << 8) + PTAT_LSB;
}

void read_CPIX_Reg_MLX90620(){
  i2c_start_wait(0xC0);
  i2c_write(0x02);
  i2c_write(0x91);
  i2c_write(0x00);
  i2c_write(0x01);
  i2c_rep_start(0xC1);
  CPIX_LSB = i2c_readAck();
  CPIX_MSB = i2c_readAck();
  i2c_stop();
  CPIX = (CPIX_MSB << 8) + CPIX_LSB;
  if(CPIX > 32767){
    CPIX = CPIX - 65536;
  }
}

void read_Config_Reg_MLX90620(){
  i2c_start_wait(0xC0);
  i2c_write(0x02);
  i2c_write(0x92);
  i2c_write(0x00);
  i2c_write(0x01);
  i2c_rep_start(0xC1);
  CFG_LSB = i2c_readAck();
  CFG_MSB = i2c_readAck();
  i2c_stop();
}

PTAT calculation needs a fix. You declared it as an int, and arduino stores ints as two's complement, so you'll get a negative value if PTAT goes over 32767.
For the same reason, there's no need for the if statement after CPIX first assignment.

Code:

void check_Config_Reg_MLX90620(){
  read_Config_Reg_MLX90620();
  if ((CFG_MSB & 0x40) == 0){
    config_MLX90620_8Hz;
  }
}

I really didn't understand this part.
You are checking if the MSB of the 0x92 config register has the ADC reference set to HIGH, and in that case you're rewriting the configuration.
Maybe it's just a typo, in the datasheet is reported to check whether a POR occurred, and in that case, rewrite the configuration.
If you meant to write that, the if condition should be: if ((!CFG_MSB & 0x04) == 0x04)

Code:

void Temperatures_Serial_Transmit(){
  for(int i=0;i<=63;i++){
    Serial.println(temperatures[i]);
  }
}

it's ok, I don't know your intended application, but this instruction takes a lot(~32ms) and it's the bottleneck of the sketch, even with 115200 baud rate

Code:

void setup(){
  Serial.begin(115200);
  i2c_init();
  PORTC = (1 << PORTC4) | (1 << PORTC5);
  config_MLX90620_8Hz();
  //config_MLX90620_16Hz();
  read_EEPROM_MLX90620();
}

Big missing here.
You forgot to write the trimming oscillator value to the 0x93 register, after I put it into the code, my readings improved a lot!
I also put the read_EEPROM_MLX90620() function before the config_MLX90620_xxHz() functions, as suggested in the datasheet.

Code:

void loop(){
  read_PTAT_Reg_MLX90620();
  read_CPIX_Reg_MLX90620();
  read_IR_ALL_MLX90620();
  calculate_TA();
  calculate_TO();
  Temperatures_Serial_Transmit();
  check_Config_Reg_MLX90620();
  delay(500); //For 8Hz, the fastest refresh is 125ms, for 16Hz 65ms
}

I find the delay useless and counterproducting.
I tested your code and without the delay it goes at 12Hz, about 82ms per cycle, so even at 8Hz if you take off the delay, you'll get small quantities of double readings.
A good and quick improvement in the code speed is obtained setting the I2C rate at 400KHz. By default in I2Cmaster is set at 50Khz.
To do this, just go in the twimaster.cpp file and change #define SCL_CLOCK 50000L to #define SCL_CLOCK 400000L. The code now loops at 17.15Hz, enough to read the data even at 16Hz.

Ciao!
allora, non so bene nemmeno io a che livello sono, provo a darti una panoramica di quello che so fare.

conosco bene il linguaggio C, e la programmazione dell'arduino non mi spaventa.
Me la cavo anche nella programmazione non così semplificata come è quella su arduino.

[boring mode on]
avevo iniziato a sviluppare un progetto di skateboard elettrico monoruota autobilanciato grazie a giroscopio e accelerometro (una sorta di segway), che poi non ho portato a termine per un filo scoperto che mi ha fatto andare in fumo qualche centinaio di euri fra sensori e componenti. (questo probabilmente dovrà farti capire che mettermi a maneggiare l'hardware non conviene ;D)
la cpu principale era un pic serie 18, programmavo anche lì in C con C18.
[boring mode off]

conosco il funzionamento di microprocessori e come si comportano, l'utilizzo di registri, porte, adc, eeprom e via dicendo.
mi entusiasma il fatto di poterli collegare alle più svariate periferiche esterne e fare interagire il tutto.

cosa più mi piacerebbe fare? qualsiasi cosa, basta aiutare  
ho dato una breve occhiata al repository e mi sembra codice chiaro e semplice da capire, ben commentato.

ecco, se appena aggiorni l'elenco dei task che state sviluppando posso guardare e scegliere qualcosa, sarebbe perfetto  

per quanto riguarda il costruirmi il quad dipende tutto su che costi siamo, perché ho anche altre spese al momento... ho visto che solo il radiocomando che usi costa 600 euro e ciò mi spaventa non poco, quindi se i prezzi son tutti di quell'ordine di grandezza preferisco limitarmi a contribuire via software al momento  ;D

Grazie ancora, Alex.

ciao roberto, ho visto solo ora questo topic ed il tuo progetto.
ero già a conoscenza di quadcopter e l'idea di farne uno mi ha sempre entusiasmato, ma l'idea di contribuire ad un progetto interamente italiano è ancora più invogliante  

le mie conoscenze sono "di tutto un po'", mi piace sentirmi come un piccolo pico de paperis in crescita  ;D mi interessano tantissimi campi, (principalmente elettronica volta all'automazione, informatica, fotografia, meccanica/motori) e se riesco a trovare qualcosa che le raggruppa, divento come un bambino davanti ai regali di natale  
putroppo ci sono talmente tanti aspetti di questi campi che conoscerli tutti approfonditamente penso sia umanamente infattibile, ma cerco di avvicinarmi a questo livello quanto più possibile.

dopo questa noiosa introduzione, arrivo al punto: vorrei aiutarvi, qualsiasi impiego mi va bene!
per ora ho guardato solamente questo topic e adesso mi metterò a guardare i messaggi su baronerosso e le pagine su googlecode.
ho visto che sei in provincia di bergamo, non so gli altri se sono nella tua zona o cosa, comunque io sono di milano e qualche viaggetto per dare una mano di persona posso farlo tranquillamente, sono solo una sessantina di km  

scusa la precipitosità e forse anche l'invadenza, ma quando vedo questi progetti "friggo"  

Alex.

ciao, non ti offendere ma se sei ai livelli da chiedere "ogni quanti millisecondi viene attivato appunto la subroutine "loop"?", questo non è assolutamente un lavoro che fa per te.
sono sistemi che vanno studiati per bene, in quanto c'è in gioco anche la tua sicurezza, un difetto al sistema che porta ad un malfunzionamento potrebbe farti male, e non poco.

detto questo, se vuoi continuare, ti dico subito che non puoi  ;D o perlomeno non puoi con un costo contenuto.
questo perché: per fare un controllo di trazione devi poter agire o sulla frenata o sull'acceleratore, solitamente si punta sull'acceleratore. la tua moto non ha l'acceleratore elettronico ed è a carburatori, mi viene da pensare che siano a depressione, quindi collegati direttamente al filo dell'acceleratore, e non c'è modo semplice di intervenirci elettronicamente.
sulla frenata il discorso è simile, la pompa freno posteriore è comandata manualmente dal tuo piede, dovresti stravolgere tutto per poterla controllare anche elettronicamente.

ciao  

a questo punto la soluzione più immediata è la eeprom, altrimenti un'ulteriore shield per la gestione della sd, ma per quel poco che devi fare penso ti convenga affidarti alla eeprom

guarda nelle ultime ethernet shield che ho ordinato non c'è più nemmeno l'alloggiamento per la sd, ci son solo i contatti.. detto questo boh, i pin ci sono comunque e hanno le loro piste, però nella libreria non c'è nulla quindi mi sa che devi sgobbare un po' per farla funzionare

è vecchio di un mese il topic ma l'ho visto solo ora, ti rispondo ugualmente. hai provato con un client.stop() dopo il sendTCPcommand?

Code:

byte tag_verified[num_of_tags][6] = {{0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, {0x01, 0x01, 0x01, 0x01, 0x01, 0x01}}; //here put your tags

at the end of the code you found on the playground, (where it writes checksum passed or error)
put something like this:

Code:

byte i, current, verified = 0;
  for (current = 0; current < num_of_tags; current++){
    for (i = 0; i <= 5; i ++){
      if (code[i] != tag[current][i])
        break;
      if (i == 5 && (code[i] == tag[current][i]))
        verified = 1;
    }
    if (verified == 1)
      // put here your instructions
    break;
  }