Show Posts
Pages: 1 2 [3] 4 5 6
31  Forum 2005-2010 (read only) / Interfacing / Re: SHT15 Humidity/Temperature Tutorial on: April 06, 2008, 01:43:57 pm
Glacial_Wanderer, have you seen ? It sounds a lot like what you're trying to accomplish, and it appears to be written for arduino  smiley-wink
32  Forum 2005-2010 (read only) / Interfacing / Re: SHT15 Humidity/Temperature Tutorial on: April 05, 2008, 09:24:43 am
Nice. Have you seen the other code how-to's around for the same sensor? I realize using someone else's code may not be as educational as doing it yourself - that's what I did. It does look like your code is more elegant & less sloppy than the code I wrote.

Regardless of the source, I think we should have a library for using this line of sensirion sensors. Also, it would be good to have a guide for the different kinds of sensors. I see you used sparkfun's breakout board for the SHT15. I used a parallax 28018 which is essentially the same thing. The SHT7x series are these sensors but with leads (not SMT), and I have found they are typically less expensive than the breakout boards.

One thing I noticed which your code does not appear to support, is the ability to turn on/off the sensor's internal heater. There are high-humidity applications which can make use of the heater to evaporate condensation build-up.

If a library is made it should probably support all the features of the SHT sensors. Maybe a second version could have CRC, but I've found CRC is not required and may be an unnecessary use of sketch space.
33  Forum 2005-2010 (read only) / Interfacing / Re: Arduino as PS/2 Keyboard on: March 31, 2008, 07:47:33 pm
You might also want to check out if you're on windows (or maybe possibly with other OS), accessibility options.

In windows XP there is an accessibility option to use an external input device. This interfaces to a COM port so if you turn this option on and select the COM port of your arduino, any letters sent from the arduino to the PC will be treated as keyboard input.

Keep in mind this is only for text entry, ie when an "a" is sent, the window in focus receives "a" as a keystroke. Normally on a keyboard there is a window message and keycodes to indicate when a key is pressed, and also when it is released. So, if you need to be able to sense key press/release, the windows feature would not suffice.
34  Forum 2005-2010 (read only) / Interfacing / Re: Receive X10 signals using a PSC05 on: April 01, 2009, 12:47:55 pm
Oh snap! How well does it work? Rest assured, I will be one of your first beta testers. I'll keep an eye out for the lib, and my PSC05 is wired and ready to go!

Next step: Extended x10 protocol support! yay! hehe
35  Forum 2005-2010 (read only) / Interfacing / Re: Receive X10 signals using a PSC05 on: March 31, 2009, 04:39:12 pm
Yes! I am absolutely still interested. In the past few weeks, health issues have gotten the better of me. But I am getting progressively better, especially in the past day. Once I catch up with all of the backlog of work missed whilst bedridden, my work on these projects will absolutely resume.

Thus far, I have read a bit regarding the x10 protocol. I believe it will be possible to do this, however some design considerations must be... considered:

Asynchronous communication - a sketch will have to allot some microprocessor time to checking for incoming data. I believe it would be possible to multitask within a sketch, since the Rx code only needs to check for bits every zero-cross or 60hz*2, to detect a bit and process it. This could be tricky to time while doing other things in a sketch, but the only other option is to allow the receive function to take full processor usage for the duration of a full message (which could be up to a second if i'm not mistaken).

Even then, if a message is intercepted mid-stream, it'd have to be dropped, unless it was during the first of the pair (as non-dim codes are sent in pairs)

Just throwing that out there. I'll pop back in once I have made more progress. I want to get started ASAP but I'm also overdue for updating my simple RF transciever librarie to be 0014-compatible - and some interested people are waiting on me for that.

"master procrastinator!" - if it weren't for life throwing me hardballs regularly, this would be finished!
36  Forum 2005-2010 (read only) / Interfacing / Receive X10 signals using a PSC05 on: March 04, 2009, 08:59:02 pm
Hi all,
I mostly work on my arduino projects sporadically, starting something new, working on it furiously and sometimes adding code to the repository, 'till I lose interest and drop it alltogether.

This time I've jumped into X10 stuff again (in '03 I toyed with it a little). I was thrilled to find that a cheap PL513 was all that was needed to start, and there was already an x10 library. On the Arduino X10 page appears

This library enables you to send and receive X10 commands from an Arduino module.

but this is wrong! I still bought a PSC05, but it appears that the library does not contain code to receive X10 data from the PSC05 into an arduino.

I was wondering, has anyone done this? Judging by my searches, it looks like I'm going to be writing some code tonight that'll do this.

This time around, I'll try to stay dedicated. I'll revise the existing x10 library for asynchronous x10 receiving.

Maybe while I'm at it I'll clean up and get working my cheap wireless RF library for those of you who have inquired over the past few months. Sorry it has taken me so long!
37  Forum 2005-2010 (read only) / Interfacing / Re: RF Wireless Link - Arduino (TX) to BS2(RX) on: April 08, 2009, 06:17:15 am
Woah, looks like that library goes where I was looking to go with my lib, with strings. I'll have to do some range testing, as well as checking to see the difference in code size. All in all, the virtualwire blows my lib out of the water. It lkooks like my slacking paid off  ;D

My library may still have its uses, if you're only looking to transmit integers, or if the separate transmit/receive libraries lend themselves to better implementation in limited codespace.
38  Forum 2005-2010 (read only) / Interfacing / Re: RF Wireless Link - Arduino (TX) to BS2(RX) on: April 07, 2009, 09:43:24 am
I have fixed the code. It involved a simple error in includes. The updated library may be downloaded here
39  Forum 2005-2010 (read only) / Interfacing / Re: RF Wireless Link - Arduino (TX) to BS2(RX) on: June 02, 2008, 12:17:07 pm
As I said before, encoding is in all likeliness required to use these modules. I've taken care of the hard part and written a library. (click here!).

My code is tested and works with these modules. With quarter-wave antennas the range is great.

Edit: oops, sorry. I didn't read the part where you tried the libraries I've written. Maybe the baud rate on your modules is less? In that case please change the timing value when creating an instance of the library. It should be changed from its current value of 208, to a slower rate of 416.
40  Forum 2005-2010 (read only) / Interfacing / Re: RF Wireless Link - Arduino (TX) to BS2(RX) on: April 18, 2008, 09:43:17 am
This is interesting. I was unable to use the sparkfun RF links I bought from them a year ago, by hooking them directly to a serial port. Due to the RF link's electronics, an encoding scheme was needed. Simply hooking them up to a serial UART would not work since the data being transmitted must be relatively DC-balanced, and must oscillate. IE, holding a DC signal on a transmitter's input pin, will not result in the receiver outputting the same DC level.

Hopefully the library I wrote was not completely unnecessary. The reliability of RF has it that some error checking should be used to verify data integrity, and some kind of method needs to be used to determine valid data from static. My library uses a kind of encoding that works with my RF links, uses error checking, and has methods to recognize valid data being transmitted by an arduino using the same library. You can read all about it here.

So my question is, are you receiving the same data as you put in? How reliable is the transmission? And are the modules sparkfun is selling now, different than the ones I purchased last year?
41  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: April 22, 2008, 04:42:11 pm
I crafted a page with all of the source code on it, including examples. There is also a write up about how it works and how it is different from manchester encoding. Still, it is similar to manchester and it's purpose is the same as far as encoder-required RF transceivers. Here is the page: click
42  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: March 27, 2008, 05:45:41 pm
I also wanted to note that I scrapped the old error checking code which I spent so much time debugging  smiley-razz It seems it didn't catch all errors, and sometimes illegible data would get through.

The new code uses a CRC check like this:
   unsigned int chkdata = curdata >> 16;
    byte chkbyte1 = chkdata;
    byte chkbyte2 = chkdata >> 8;
    byte chkbyte3 = chkbyte1 + chkbyte2;
    chkdata = (chkbyte3 * 0x100) + (255 - chkbyte3);
    if ((preamble == 150) && ((curdata & 0xFFFF) == chkdata)) {
      return(curdata >> 16);
    } else {
43  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: March 27, 2008, 05:37:58 pm
All done!  smiley

I decided to make two separate libraries as some of my projects only use the transmitter or receiver (not both), and I found combining the code into one library makes the sketch larger.

Here is an archive with the libraries for both transmit and receive, along with example sketces for both: download

I'll put the example code here as well, so you can see how it works.
All of this code is released into the public domain, I hope it helps those of you who have been looking to use these RF links for some time  smiley

#include <RFXmit.h>
RFXmit rfxmit(7, 208); // Initialize the routine
                       // use pin 7 to transmit
                       // delay 208us between level change

unsigned int curInt;   // an integer to count with

void setup()

void loop()
  for (int rpt = 0; rpt < 5; rpt++) rfxmit.xmitInt(curInt);

Please note, 208 is the delay in microseconds between oscillations, suitable for 2400bps RF links. Halve this number if yours is a 4800bps. The receive code auto-detects. The above code just counts up frm 0, transmitting a new number every second.

#include <RFRecv.h>
RFRecv rfrecv(12);  // use pin 12
unsigned int lastint; // last number received

void setup()
  Serial.begin(9600);        // open serial

void loop()
  unsigned int newint; // for storing the last received int
  newint = rfrecv.recvInt();
  if ((newint != lastint) && (newint != 0)) {
    Serial.println(newint, DEC);
    lastint = newint;

This will print to the serial port, the number received, when a valid number is received which is different than the last valid number received. It will not return any data if the data received is illegible (a simple CRC is used). It also doesn't repeat the same number twice. In the above transmit example, the current number is transmitted multiple times to allow the receiver time enough to adjust its gain.

Please post here with your questions, comments, improvements, etc.

I have tested this code with good results. No erroneous data is returned, and everything continues to work at a good distance (with proper antennas).
44  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: February 18, 2008, 01:01:11 pm
Soon I'm going to clean up the library and change the error checking, since it seems once in a while static is recognized as valid data. I'd like to write 8b/10b encoding but since it has to be done in software, this may take up more program space than I'd like. I may end up trying both just to see the difference in data rates and sketch sizes.

I haven't looked around too much, but are there any tutorials on writing libraries? I'd like to see about making one with these codecs integrated.
45  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: February 14, 2008, 06:26:16 pm
All code in this post copyleft 2008, please reproduce & reuse, and give credit where due.
Example transmit code:
int ledPin = 13;                    // LED connected to digital pin 13
int inputpin = 0;
int val = 0;                        // variable to store the read value
int sw[8];  // switches / their values
int xmitpin = 8;
unsigned int curInt;
int dlyms = 208;

void xmitByte(byte vData) {
  byte bitv = 128;
  for (int bitc = 0; bitc < 8; bitc++) {
    if (vData & bitv) {
      digitalWrite(xmitpin, HIGH);
      digitalWrite(xmitpin, LOW);
    else {
      digitalWrite(xmitpin, HIGH);
      digitalWrite(xmitpin, LOW);
    bitv = bitv >> 1;

void setup()
  pinMode(ledPin, OUTPUT);   // sets the digital pin 13 as output
  digitalWrite(ledPin, HIGH);
  int cnt = 2;                  // counter
  while (cnt <= 7) {
    sw[cnt] = 1;
    pinMode(cnt, INPUT);        // set to input
    digitalWrite(cnt, HIGH);    // enable pull-up
  pinMode(xmitpin, OUTPUT);

void loop()
  int cnt = 2;
  int vin = 0;
  cnt = 2;
  while (cnt <= 7) { // poll pins 2 through 7
    vin = digitalRead(cnt);     // poll the pin.
    if (vin != sw[cnt]) {       // has its state changed?
      sw[cnt] = vin;            // store the new state
      curInt = 0x4000 + (8 * vin) + cnt; // set number to transmit to reflect this
  for (int xbr = 0; xbr < 3; xbr++) xmitByte(0);
  xmitByte(150); // preamble
  xmitByte(curInt >> 8); // data
  xmitByte(curInt & 0xFF);
  xmitByte(~curInt >> 8); // to error check
  xmitByte(~curInt & 0xFF);
  xmitByte(0); // padding
  digitalWrite(xmitpin, HIGH);

This code turns on pins 2 through 7 internal pull-up resistor, and polls them for changes. It also continuously transmits data on pin 8, the data being an unsigned int stored in curInt. Shorting a pin (2 through 7) to ground causes this number to change, and it also changes when the pin is disconnected or its level goes high.

The data sent to indicate a switch event will always have bit 0x4000 set, and the bit with mask 0x8 indicates high or low. Bits with mask 0x7 (the three LSBits in curInt) indicates which pin the event occurred on. The number 2 in the loops above can be changed to 0 to accommodate two more pins, if one is not also using the serial port.

Receiving end:
int ledPin = 13;                    // LED connected to digital pin 13
byte amlvl = 15;
unsigned int lastint;

int waitOnlvl(byte vLvl) {
  byte wlvl = digitalRead(12);
  byte wlvl2 = wlvl;
  int lvlcnt;
  while (wlvl2 != vLvl) {
    lvlcnt = 0;
    while (wlvl2 == wlvl) {
      wlvl2 = digitalRead(12);
    wlvl = wlvl2;

unsigned int recvInt(void) {
  // check for level change
  unsigned long starttime = millis();
  int tmocyc = 0;
  byte reftm = amlvl + 40;
  byte reftm2 = reftm + (reftm / 2);
  //read potential bits
  unsigned long curdata = 0;
  unsigned int preamble = 0;
  byte lvlq = 0;
  byte cbit = 0;
  while ((preamble != 150) && (tmocyc < 5000)) {
    preamble = (preamble << 1) + (curdata >> 31);
    curdata = curdata << 1;
    cbit = waitOnlvl(0);
    if ((cbit < reftm) && (cbit > amlvl)) {
      reftm = cbit;
      reftm2 = reftm + (reftm / 2);
    if (cbit > reftm2) curdata++;
    if ((tmocyc % 128) == 127) {
      if (millis() - starttime > 1000) tmocyc = 5000;
  if (tmocyc == 5000) {
  else {
    if ((preamble == 150) && ((curdata >> 16) == (~curdata & 0xFFFF))) {
      return(curdata >> 16);

void setup()
  pinMode(ledPin, OUTPUT);   // sets the digital pin 13 as output
  pinMode(12, INPUT);
  digitalWrite(12, LOW);
  Serial.begin(115200);        // open serial

void loop()
  unsigned int newInt;
  newInt = recvInt();
  if ((newInt != lastint) && (newInt != 0) && (newInt != 65535)) {
    Serial.print(newInt >> 8, BYTE);
    Serial.print(newInt & 0xFF, BYTE);
    lastint = newInt;

The receive code simply looks for legible data coming in on pin 12, and when it sees good data and the number is different than the last one received, it prints it to the serial port. This is since, the transmitter will be continuously transmitting a number in curInt, which only changes with the line levels of pins 2-7 on the transmitting MCU.

Hopefully that works this time. I had a lot of extra function in my code that I snipped out for the purposes of this example, and I couldn't test it. But it did work before snipping out the unrelated code.

To have the loop print the received number in decimal, change the two Serial.print lines above to, Serial.println(newInt, DEC);

Please post here if you're getting results! I'll check back from time to time, and hopefully soon I'll have motivation enough to rewrite this code to use this 8b/10b encoding, and perhaps turn it all into a library.

Dustin, we must be using different modules. Mine are likely cheaper in price & quality. They certainly do not work as you described - changing the tx on one to high or low does not cause the receivers rx to do the same, unless the line level in changing rapidly. This was my whole reason for trying to implement manchester-ish encoding.

(arrgh 5500 char post limit)
Pages: 1 2 [3] 4 5 6