Show Posts
Pages: 1 ... 123 124 [125] 126 127 ... 250
1861  Using Arduino / Installation & Troubleshooting / Re: Windows 8 stops Arduino 1.0.2 from running on: November 11, 2012, 07:28:06 am
Typical, eh. Just getting started with Windows 8. Not sure what I think. Avast didn't have an issue with it so I went ahead and overruled SmartScreen. Thanks for the tip.
1862  Using Arduino / Installation & Troubleshooting / Re: I think I destroyed my SMD Uno on: November 10, 2012, 05:58:04 pm
Haven't tried it myself, have you seen this stuff called "Chip Quik"?
1863  Using Arduino / Installation & Troubleshooting / Windows 8 stops Arduino 1.0.2 from running on: November 10, 2012, 05:49:08 pm
Anyone else had this? "Windows SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk."

Ran it anyway, no blue smoke yet. No trouble with 1.0.1.
1864  Using Arduino / Installation & Troubleshooting / Re: I think I destroyed my SMD Uno on: November 09, 2012, 08:10:22 pm
Any idea what might have happened to it? I accidentally programmed the RSTDISBL fuse bit recently. That slowed the whole process right down.
1865  Using Arduino / Networking, Protocols, and Devices / Re: A story of three xbees; two emitters and one hub on: November 09, 2012, 08:02:26 pm
Expect all the data to arrive nearly instantaneously. Nope. Not going to happen (sorry, Jack).

Ummm yeah that'd be a good point, no apology necessary, Paul. That's what I get for writing untested vapor code on the fly and not thinking enough about it.

Actually, if the XBee's serial interface baud rate were slow enough, then the serial-to-RF data packetization might allow it to work. Not that that would be good design or anything smiley-red
1866  Using Arduino / Networking, Protocols, and Devices / Re: A story of three xbees; two emitters and one hub on: November 09, 2012, 04:46:24 pm
Try the following receiver code. I might also slow the transmitters down to once every two seconds, just for testing purposes.

Code:
#include <LiquidCrystal.h>

int val_read;
byte nodeID;
int average;
LiquidCrystal lcd(12, 11, 5, 4, 3, 2);

void setup()
{
    Serial.begin(38400);
    lcd.begin(16,2);
}

void loop()
{
    val_read = Serial.read();
    if (val_read == '*') {               //wait for start delimiter
        nodeID = Serial.read();
        average = Serial.read() << 8;    //msb
        average += Serial.read();        //lsb

        //message received and decoded, continue processing it...
        if (nodeID == 1) {
            lcd.setCursor(0, 0);
            lcd.print("Bike1 = ");
            lcd.print(average, DEC);
            lcd.print("   ");
        }
        else if (nodeID == 2) {
            lcd.setCursor(0, 1);
            lcd.print("Bike2 = ");
            lcd.print(average, DEC);
            lcd.print("   ");
        }
    }
}
1867  Using Arduino / Networking, Protocols, and Devices / Re: A story of three xbees; two emitters and one hub on: November 09, 2012, 01:59:11 pm
A start delimiter is just a special character of your choosing that serves to mark the start of a message. I chose an asterisk (*) but any character can be used, as long as it's not also used in the data being sent. Having said that, since we are sending binary data, we have a problem with that because there's no guarantee that a byte of "myData" in the example code above won't look like an asterisk. As as simplifying assumption, we could dispense with checking for a "premature" start delimiter, and see how things work just relying on knowing that the messages are a constant length. I'd expect that it would actually work fairly well. This is the kind of robustness that can be had with API mode. There is at least one very good library out there to help operate in API mode (here), but in sticking to transparent mode, we get to do it ourselves, or take the easy way out and live with a weaker design.
1868  General Category / General Discussion / Re: Clock Clock on: November 09, 2012, 12:52:21 pm
Separate, and they are not standard clocks. Hands on standard clocks form a 90° angle at 9:00, but not at 3:30, 9:30, etc. Pretty cool, though.
1869  Using Arduino / Networking, Protocols, and Devices / Re: A story of three xbees; two emitters and one hub on: November 09, 2012, 12:19:23 pm
And can you give me a example in code ? Having hard time understanding that with syntax

An example of what exactly?

Transmitter code might look like

Code:
   const byte nodeID = 1;
    int myData;

    Serial.write('*');            //message start delimiter
    Serial.write(nodeID);
    Serial.write(myData >> 8);    //most significant byte
    Serial.write(myData & 0xFF);  //least significant byte

Receiver code might look like

Code:
   byte c;
    byte nodeID;
    int myData;

    c = Serial.read();
    if (c == '*') {                     //wait for start delimiter
        nodeID = Serial.read();
        myData = Serial.read() << 8;    //msb
        myData += Serial.read();        //lsb
        
        //message received and decoded, continue processing it...
    }

Checking for a premature start delimiter is left as an exercise for the reader smiley-grin
1870  Using Arduino / Networking, Protocols, and Devices / Re: A story of three xbees; two emitters and one hub on: November 09, 2012, 12:08:51 pm
Here are a few things off the top.

1. delay(100) in receiver code. Since there are two transmitters each sending every 100ms, probably the code never gets to the emitterTwo() function. I would use no delay in the receiver. It should constantly be watching for incoming data, not "sleeping" -- it can do nothing while delay() executes.

2. int(val_read) does nothing, since val_read is an int.

3. Serial.read() reads a byte. Serial.write() writes a byte. So Serial.write(average), where average is an int, may not have the desired effect.

4. In emitterTwo(), the receiver code appears to check the first byte to identify the sender. But this is not done in loop(). The code should be consistent, should treat every incoming message identically, and there should be a fixed message structure. The code should not make assumptions about which transmitter's message might be received first, or that the two will always alternate perfectly. Some sort of message start delimiter may be a good thing. Just as a starting idea, each transmitter could always send a message like "*ndd" where the * is the start delimiter, n is a single byte identifying the transmitter, and dd is two bytes representing the data sent by the transmitter. Then the receiver code could watch for "*" as the start of a message, then decode the next three bytes accordingly. If another * shows up in the next three bytes, then that is an error, but would allow the receiver to re-sync.

5. It appears you are trying to determine distance (in inches!) based on the RSSI value. This will be a gross approximation at best. Further, if these are S2 (mesh) XBees, RSSI only represents the last hop, so it's entirely possible that the furthest transmitter would route through the closer one, and the hub would see no difference in the RSSI values for the two transmitters.

Hope this helps.
1871  Using Arduino / Networking, Protocols, and Devices / Re: A story of three xbees; two emitters and one hub on: November 09, 2012, 11:50:04 am
OK I'll have a look. What kind of XBees are these? Series 1? Series 2?
1872  Using Arduino / Microcontrollers / Re: Crystal problem with 328p-pu on: November 09, 2012, 09:22:49 am
What can I do to fix the IDE so it will work.

There is no evidence here that points conclusively to the IDE. My foremost theory ATM is that the crystal is oscillating but not close enough to spec for the async communication with the bootloader to work.

Quote
Its not really practical to use avrdude all the time.

Riva++ (no absolute requirement for a bootloader)
1873  Using Arduino / Networking, Protocols, and Devices / Re: A story of three xbees; two emitters and one hub on: November 09, 2012, 06:51:09 am
How about posting the code for the receiver.
Also post a copy of the output, and explain how it is not what you expected.

My gut feel on this is that the data from the two transmitters stands to get mixed up, unless measures are taken to prevent it. The best approach might be to change to API mode. It can probably be made to work in transparent mode, but some scheme to prevent the two transmitters from transmitting simultaneously will be needed. Such an implementation stands to be relatively clunky as compared to API mode.
1874  Using Arduino / Networking, Protocols, and Devices / Re: A story of three xbees; two emitters and one hub on: November 09, 2012, 12:25:25 am
But is any single message from either transmitter intact? "One value from one emitter then another value from the other" is what I might expect, best case.

Or are characters from one transmitter intermixed with those from the other transmitter?
1875  Using Arduino / Networking, Protocols, and Devices / Re: A story of three xbees; two emitters and one hub on: November 09, 2012, 12:12:54 am
Yes, that is exactly what I was suggesting, but define "mushed". If one transmitter sends "A123" and the other sends "B999", is the receiver seeing something like "AB129399"?
Pages: 1 ... 123 124 [125] 126 127 ... 250