Synchronization and Implementing hamming code on Software Serial

Question

I want to learn and use Hamming Code. Would it be wise to alter the Software serial library to do this or just change the data being transmitted in the actual Arduino sketch?

Also, for means of better synchronization, what would be the best method with regards to these tx/rx modules working with the Arduino using Software Serial. Am I constrained to using the built in synchronization from the library or may I also implement other forms of synchronization, like manchester and NRZ coding? If so, any guidance here?

EDIT

For implementing Hamming code, what if the interference occurs on the parity bit? Is there a way around this problem?

Answer 1

You can use this info and code: Hamming(8,4) with Arduino.

There's a PDF with documentation about the process of creating a class that implements hamming(8,4) and a link to the source code.

You can use any class that derives from Stream (like Serial or SoftwareSerial).

Edit: If you want to implement a Hamming ECC in a Arduino it would be useful to precompute all the possible message values (you'll find more info at the link above). In a Hamming(8,4) your message is 1byte = 4bits + parity 4 bits; so you must divide your bytes in nibbles. It would be better to put all that stuff (code, decode, manage the upper/lower part of the byte, etc...) in a class. An example using the Hamming class from the link above:

Tx:

#include <hamming.h>

Hamming hamming(&Serial);
char message[] = "Hello World!!";

void setup()
{
  Serial.begin(9600);
  delay(100);
}


void loop()
{
  hamming.write(message);
  delay(1000);
}

Rx:

#include <hamming.h>

Hamming hamming(&Serial);
char message[Hamming::SIZE];

void setup()
{
  Serial.begin(9600);
  delay(100);
}

void loop()
{
  if(hamming.isMessageReady())
  {
    hamming.read(message);
    Serial.println(message);
  }
}

If you need to send other kind of info: a float, integer... you can do it, but I think it's a better idea to tokenize/detokenize your information and handle it like a "string".

P.S. You can use any kind of physical layer insofar as it's a child of Stream: Serial, SoftwareSerial...But I've only tested over Serial.

Answer 2

Could look something like this:

class HammingStream : public Stream {
public:
  HammingStream(Stream& ios) : m_ios(ios) {}
  virtual size_t write(uint8_t byte);
  virtual int read();
  virtual int available();
  virtual void flush();
protected:
  Stream& m_ios;
  uint8_t encode4(uint8_t nibble);
  uint8_t decode8(uint8_t code);
};

size_t HammingStream::write(uint8_t byte)
{
   m_ios.write(encode4(byte >> 4));
   m_ios.write(encode4(byte & 0xf));
   return (1);
}

int HammingStream::read()
{
  if (available() == 0) return (-1);
  uint8_t nibble = decode8(m_ios.read());
  return ((nibble << 4) | decode8(m_ios.read());
}

int HammingStream::available()
{
  return (m_ios.available() / 2);
}

void HammingStream::flush()
{
  m_ios.flush();
}

Then you could:

HammingStream HammingSerial(SoftwareSerial);
HammingSerial.println(F("hello world"));

The above leaves out the encoding/decoding but also error detection. Hamming decoding can capture up to two bit errors and do one bit correction (on 4-bit data).

An example of implementation of the coder may be found in Cosa. Here Hamming(8, 4) is used to improve VirtualWire performance. Please note that the coder table is adjusted for RF and avoiding DC signal (i.e. long periods of zero or one).

Cheers!

Answer 3

The SoftwareSerial can only transmit and receive EIA-232 formatted packets. That is what it is written to do, and that is what it does.

It cannot transfer any other format.

If you want to use other encoding techniques you will have to use a different method than SoftwareSerial.

That might involve writing your own bit-banging routines in your sketch or in your own library, or using SoftwareSerial as a basis to adapt into your own library.

Note that the SoftwareSerial library is written in such a way that EIA-232 packets are a requirement - the falling edge of the start bit triggers reception of one packet - any other encoding that doesn't have that kind of start bit arrangement would require some completely different method of arranging the reception.