serial.write to send a hex buffer?

Can I send an arbitrary array of bytes via serial.write(array,len), or is it always treated as character data? Here is why I ask. Say I declare

byte outByte[BLEN];

then go and fill it with some data

byte uTemp = byte( (outTemp & 0xFF00)>>8);
  byte lTemp = byte(outTemp & 0xFF);
  outByte[4]=TEMPVAL;
  outByte[5]=uTemp;
  outByte[6]=lTemp;
  outByte[7]=0x0d;

Then send it as a buffer with serial.write(

Serial.write(outByte,BLEN);

If I change the outByte[7]=0x0d; to outByte[7]=0x11; it gets read on the other end as zeroes??? So that goes back to my original question. Is the 0x11 getting stripped out because it is an unsupported ASCI control code, or something like that? What is the correct way to send a packet of hex data across the wire?

If somebody can help out I would seriously appreciate it.

thanks
James B
arudino duemilanove running arduino 0017

full code follows

const byte BLEN = 16;
const byte BADPAC =    0x02;
const byte DATAPAC =   0x05;
const byte DATAREQ =   0x07;
const byte TEMPVAL =   0x0d;
byte inByte[BLEN];
byte outByte[BLEN];
int outCount = 0;
int outTemp = 0;

void setup() {
  Serial.flush();
  pinMode(13,OUTPUT);
  outCount = 0;  
  Serial.begin(9600);
  initBuffers();
}

void loop() {
  initBuffers();
  if (Serial.available() > 15) { 
    for(int i = 0; i<BLEN;i++){ inByte[i]=Serial.read(); }   
//    for(int i = 0; i < BLEN;i++) {outByte[i]=inByte[i]; }
    if ((inByte[1]==DATAREQ) && (inByte[BLEN-1]==receivedChkSumCalc())) {
      outByte[1]=DATAPAC;
      insertTemp();
    }
    else  {
      outByte[1]=BADPAC;
    }
    delay(100);
    sendOutbuf();
    delay(100);
    Serial.flush();
    delay(100);
  }
}
void initBuffers() {
  for (int i=0;i<BLEN+1;i++) {
    inByte[i]=0;
    outByte[i]=0;
  }
}

void insertTemp() {
  outTemp = analogRead(5);
  byte uTemp = byte( (outTemp & 0xFF00)>>8);
  byte lTemp = byte(outTemp & 0xFF);
  outByte[4]=TEMPVAL;
  outByte[5]=uTemp;
  outByte[6]=lTemp;
  outByte[7]=0x0d;
}
void sendOutbuf()  {
  outByte[0]      = BLEN;
  outByte[BLEN-1] = chkSumCalc();
  Serial.write(outByte,BLEN);
  outCount +=1;
}

byte chkSumCalc() {
 byte chkSum = 0;
 for(int i = 0; i < BLEN -1; i ++) { chkSum+=outByte[i];   delay(100); }
 chkSum = ~chkSum;
 chkSum = chkSum + 1;
 return(chkSum);
}

// /////////// hands off /////////////////////
byte receivedChkSumCalc() {
 byte chkSum = 0;
 for(int i = 0; i < BLEN -1; i ++) { chkSum+=inByte[i]; }
 chkSum = ~chkSum;
 chkSum = chkSum + 1;
 return(chkSum);
}

If I change the outByte[7]=0x0d; to outByte[7]=0x11; it gets read on the other end as zeroes???

0x11 is the ASCII code XON, which is usually interpreted as a "soft" flow-control character.
If the remote end of your serial link is operating in XON/XOFF mode, then the actual code will be absorbed by the device driver, and not passed to the application.
You need to disable all flow control at the receiver.

Thanks boss. It works. That had been wreaking havoc with my checksums, buffer lengths, and general mental health. Everything else was working, so can start using this to monitor the temp in my kiln and start firing my first batch of pottery. Next step is to drive a solid state relay to actually control the kiln temp, but I need to get a feel for how to do that manually first.

  • James B

Controlling the kiln temp is not a simple matter of heat on/ heat off. You need to anticipate when the rising temperature will reach the desired temperature, and turn the heat off before then. You need to anticipate when to turn the heat on, before the temperature falls too low.

The PID library will help you with that.

Yeah, I studied control system theory in school so I have a good idea what has to go on. I'll be sure to check out the PID library, sounds useful. But then with pottery, there is the extra consideration of hitting a specific cone. You likely already know, but the a slower ramp can hit the same cone with a lower temp than if you ramp fast. There are tables around for how much heat an Orton cone has to absorb (based on ramp) to bend over. Implementing the controls should be more fun than trying to get a serial messaging protocol working.

The kiln that a friend has has an auto shutoff feature using a cone (or cone like material) that melts and allows the auto shutoff contact to open. I would think most kilns would have this.

Zoomcat, my kiln has a 'kiln sitter' like your friend. You put a bar of compressed glaze (same as they make cones out of) that becomes elastic and slumps under it's own weight at a specific temperature, then allows an arm resting on the bar to trip the main power. Except the ceramic and alloy thing that holds the bar up is busted off of mine, so I wanted to roll my own digital version rather than track down a spare part for a 20 year old kiln.

I have a propane blacksmith forge I made, and all the parts to make a heat treating oven, so I'm hoping to use the same thermocouple for multiple applications. My VB temp monitoring app seems to be (knock wood) pretty robust so far. The data request and response are checksummed, and it does retries and resets the com ports if too many bad packets go either direction. I stuck in something to make a .csv file of temp versus time so I can plot my results. The quick support from this forum helped make it all possible.

  • James B