Show Posts
Pages: [1] 2 3 ... 30
1  Using Arduino / Programming Questions / Re: Programming XBee to transmit and receive data on: Today at 03:52:20 am
Continued... (exceeded posting limit...)

One thing a bit confusing in your conversion code is you use both datatypes double and float. With Arduino both of those datatypes are the same thing. I would use only one of the two to help keep things clearer. (I usually just use float so I had to look up double...)

Because of how I have the synchronization set up, the only place you need to put any delay is in the transmitter code.

If you count characters sent by the transmitter you will see that each data point actually transmits 7 characters (the start character, two characters each for data_high and data_low, and the println() tacks on a carriage return character and a line feed character). Because of how the receiver is structured, it sees the start character, reads the next 4 characters as data and then ignores any further characters until a new start character. As a result, the carriage return and the line feed are ignored. Clever, isn't it?

Also, I'll be visiting with family today (Saturday). I may not get back to you until Sunday.
2  Using Arduino / Programming Questions / Re: Programming XBee to transmit and receive data on: Today at 03:50:30 am
You are getting close. Nice try with the synchronization, but there are several problems.

Lets start with some minor issues. Lots of your variables are bigger than they need to be. There is only 2K of SRAM available on our 328s. Think about the expected values and use the smallest datatype that will fit. For example, data_low and data_high only ever get 1 byte of data, but you are allocating 2 bytes each. There are many others, but I'll leave that as an exercise for you to find.

You are calculating a new temperature every time through loop(), not when you have a new value to calculate. You should probably have another flag (call it newReading or something similar and give it a datatype of boolean) that you set once you finish reading both data_low and data_high. Only calculate the temperatures when that flag is true and set it false once done calculating and sending the result to the hardware serial port.

The synchronization flag is a good try, but you are setting it's value to zero at the beginning of loop() every time. You should move the declaration and initialization of flag (and change it's name to something more descriptive of it's function so you understand why it exists when you look back at this code in 2 years) to the global variable area.

This section has lots of problems:
Code:
    if (mySerial.available() && flag<2)
     flag = flag+1;
{
if ((flag%2)!=0)
{
data_low = mySerial.read();
}

else if ((flag%2)==0)
{
data_high = mySerial.read();
}
}

First, get used to using the auto-format function of the IDE. That would help you spot one of the issues here... After auto format this is what it looks like:

Code:
 if (mySerial.available() && flag<2)
    flag = flag+1;
  {
    if ((flag%2)!=0)
    {
      data_low = mySerial.read();
    }

    else if ((flag%2)==0)
    {
      data_high = mySerial.read();
    }
  }

Notice that the indenting helps you see that the only thing the first if statement will do is increment flag when the conditional is met. The following if...else statement is always done whether mySerial has data available or not. Moving a single open-brace would get this:

Code:
 if (mySerial.available() && flag<2)
  {
    flag = flag+1;
    if ((flag%2)!=0)
    {
      data_low = mySerial.read();
    }

    else if ((flag%2)==0)
    {
      data_high = mySerial.read();
    }
  }

Now, you also have the incorrect syntax for if...else. Either change else if ((flag%2)==0) to just simply else, or comment out if ((flag%2)==0) on that line. Not only is it incorrect syntax (but probably would work), that second if is redundant. Flow would only get to the else if (flag%2)==0.

This is probably closer to your intent. But wait... there is another issue. flag<2 will only be true for the first two reads because you never reset it back to zero when you are done reading both bytes.

All these changes would get your synchronization method to work. Unfortunately, there is a fundamental conceptual error being made here. If the receiver starts after the transmitter then you are not guaranteed to capture the correct byte order. There is a chance that the receiver would start listening between the transmission of the first and second bytes, so it would think the second byte is the first and vice versa.

Remember what I said in a previous post about using a start byte? Here is some pseudo code for you to try to understand by implementing: (Note that some pseudocode lines can result in multiple lines of code, and vice versa.)

TRANSMITTER
Code:
#include required libraries

Create a software serial object named XBeeTX, pin 2 as RX, pin 3 as TX

Initialize globals and constants:
  constant dev as a byte with value 0x5A shifted to the left 1 bit
  constant data_start as a char with value '*' (or choose another one based on the criteria I outlined in a previous post)

setup()
{
  Initialize hardware serial at 9600 baud
  Initialize XBeeTX at 9600 baud
  Initialize I2C and enable pullups
}

loop()
{
  Initialize local variables:
    data_low as a byte (it will default with the intended value of zero)
    data_high as a byte
    pec as a byte (we are not actually using this for anything (yet) but it still needs to be read)

  Fetch a reading from the temperature sensor via I2C

  Use the print method to send data_start to both hardware serial and XBeeTX
  Use the print method to send the hex representation of data_high to both hardware serial and XBeeTX
  Use the println method to send the hex representation of data_low to both hardware serial and XBeeTX

  Pause for 1 second
}

RECEIVER
Code:
#include required libraries

Create a software serial object named XBeeRX, pin 2 as RX, pin 3 as TX

Initialize globals and constants:
  constant data_start as a char with value '*' (or what ever was used in the transmitter code)
  newReading as boolean and initialize as false
  readPosition as byte
  data_low as byte
  data_high as byte

setup()
{
  Initialize hardware serial at 9600 baud
  Initialize XBeeRX at 9600 baud
}

loop()
{
  if at least 1 byte is available at XBeeRX
  {
    Read 1 char from XBeeRX
    switch on readPosition
      case 0
      {
        if the char read in is equal to data_start, set readPosition to 1
        // otherwise it is extraneous data to be ignored so do nothing
      }
      case 1
      {
        // the read char is the ASCII representation of the upper nybble of data_high
        call HexCharToValue function with the read char as an argument
        put the returned value into data_high and shift to the left 4 places
        set readPosition to 2 (either directly or by incrementing by 1)
      }
      case 2
      {
        // the read char is the ASCII representation of the lower nybble of data_high
        call HexCharToValue function with the read char as an argument
        add the returned value to data_high
        set readPosition to 3 (either directly or by incrementing by 1)
      }
      case 3
      {
        // the read char is the ASCII representation of the upper nybble of data_low
        call HexCharToValue function with the read char as an argument
        put the returned value into data_low and shift to the left 4 places
        set readPosition to 4 (either directly or by incrementing by 1)
      }
      case 4
      {
        // the read char is the ASCII representation of the lower nybble of data_low
        call HexCharToValue function with the read char as an argument
        add the returned value to data_low
        we are done reading data so set readPosition to 0
        we have read in a full dataset so set newReading to true
      }
  }

  if newReading is true
  {
    Use the print method to send data_start to hardware serial
    Use the print method to send the hex representation of data_high to hardware serial
    Use the println method to send the hex representation of data_low to hardware serial
    // This line printed in serial monitor should be the same as what the transmitter printed to it's serial monitor. This is your check that the transmission completed correctly.

    Convert to an actual temperature and print to the hardware serial
    set newReading to false
  }
}

define a function called HexCharToValue that takes a char and returns a byte
{
  use the ctype.h function isxdigit() to make sure the function input is a hex digit (return zero if it isn't)
  convert the hex digit to upper case using the ctype.h function toupper() just to simplify the conversion.
  subtract 0x30 from the hex digit to get the first result
  if the first result less than 0xA then we are done and return the first result
  subtract 0x10 from the first result, add decimal 10, and return the second result
}

I'm not sure if there is a regular C++ function to do what I did in HexCharToValue does. The magic of this function is based on where digits 0-9 and letters A-F are in the ASCII table:
* If the char is '5', then the value is 0x35. So by subtracting 0x30 we are left with 0x5 which is decimal 5.
* If the char is 'D', then the value is 0x44. So by subtracting 0x30 we are left with 0x14. Because 0x14 is greater than 0xA, we then subtract 0x10 and are then left with 0x4 which is decimal 4. We then add decimal 10 to get decimal 14 which is 0xD.

Edit: copy-paste error in my pseudocode...
3  Using Arduino / Programming Questions / Re: Programming XBee to transmit and receive data on: April 18, 2014, 04:45:21 pm
Quote
That is one of the few tutorials that I've seen not using X-CTU to configure XBee modules. I think he did it that way to show people who don't use MSWindows how they can do it. But if you are using MSWindows, why do things the hard way and ignore provided tools? (If you have access to the Snap-On tool van, why use a pen-knife blade to turn screws when you can get the proper sized screwdriver?)

The serial communication that happened wirelessly tells that the XBees are configured correctly right? Do I need to worry about X-CTU now? I will certainly try using it next time though.

I agree that the serial communication that you did shows that the XBees are configured correctly. I wouldn't worry about X-CTU unless you need to reconfigure these modules for something else, or to configure new modules. At this point for what you have it's all water under the bridge.

[...snip...]
Quote
how far have you gotten reading the temperature sensor and sending data_high and data_low to the other Arduino via the XBees?

I haven't done anything since yesterday. I will be back here if I have questions. You said its better to transmit the 'data_high' and 'data_low' to the receiver side and then do the math conversions there, right?

No rush, but please keep me updated with both your successes and failures.

I just think it would be simpler to transmit the encoded two byte value that the temperature sensor transmitted over I2C. Float values are encoded within 4 bytes (so there would be at least twice as much to transmit). It can be done, but would require some more advanced techniques and not lose precision.
4  Using Arduino / Programming Questions / Re: Programming XBee to transmit and receive data on: April 18, 2014, 12:14:19 am

That is one of the few tutorials that I've seen not using X-CTU to configure XBee modules. I think he did it that way to show people who don't use MSWindows how they can do it. But if you are using MSWindows, why do things the hard way and ignore provided tools? (If you have access to the Snap-On tool van, why use a pen-knife blade to turn screws when you can get the proper sized screwdriver?)

Also, he mentions at 1:26, about configuring the XBee shields and says you have to physically remove the micro-controller and shift "these two jumpers", from the right to left position. Now the shield he had was a bit different from what I have which is XBee shield V1.1. So while configuring the XBees do I move any jumpers at all?

Actually, the shield he showed in his tutorial is completely different than your shield. Not even the same designer/manufacturer. IMHO, he kinda did his audience a disservice by not better identifying the XBee shields that he was using, and explaining what the jumper change was all about. The jumpers he moved would have the same effect as adjusting the jumpers in the zone 3 area of the XBee shield that you have. If they seemed to program ok for you (i.e. you got the proper responses as you indicated that you did) then there shouldn't be a lasting issue. Especially since you indicated that you were able to get the communication going using the software serial example sketch.
Ideally, in the future you should get (as he did suggest) a USB to XBee adapter (also called XBee Explorers) if you plan on playing with XBee configurations. Several vendors and manufacturers carry their own versions of them, but they are all pretty much identical in operation. Adafruit has one for $20USD with some assembly required, and SparkFun has two (here and here), each $24.95USD as finished units. I'm too lazy to look further, but I'm sure there are plenty more.

I have made the change of moving the jumpers so that D2 center is short with DOUT and D3 center is short with DIN. Also, I copied the "SoftwareSerialExample" code and made the modifications you said.

When the baud rate was 57600 in the void setup() method, I got some funny looking characters.  I changed the baud rate in that to 9600, and also in the other mySerial.begin. I can send and receive text messages well.

Be careful describing things. If you look carefully in the setup() you should actually see two baud rates, one for the hardware serial with serial.begin(), and one for the software serial with mySerial.begin().
Just to make sure you understand, explain where the name "mySerial" came from. Don't be afraid to get the question wrong, I'll try to help you understand it if you are wrong. I tend to value knowing why to do things slightly higher than knowing how to do things. Because if you know why then you can apply that knowledge to a different situation to come up with the appropriate (and some times unique) how.

Looking at the example and seeing which one defaults at 57600, I see that it was the hardware serial. There were two ways to correct the problem you had. The hardware serial is what is communicating with the serial monitor. You could have changed the baud rate in the code (you did), or you could have changed the baud rate of the serial monitor to 57600. Personally, I use 115200 for my serial monitor and Arduino's hardware serial baud rates so it takes less time to send diagnostic messages.

Thanks again for helping me through with this.

Sure, no problem. Helping people is why I come to the Arduino forum.

Now that you have verified that the hardware works, how far have you gotten reading the temperature sensor and sending data_high and data_low to the other Arduino via the XBees?
5  Using Arduino / General Electronics / Re: Need a battery source on: April 17, 2014, 02:15:58 pm
Quote
There is also a case a little while ago where someone's e-cig blew up in their face. Turns out the person didn't have any battery protection in his custom mod, but the news reporters neglected to mention that. Instead the spin on the story was how all e-cigs are dangerous explosion risks.

Regarding your video(s?). That 20+Gig zip file is a huge payload. Do you have a youtube/vimeo/etc link instead?
the file size is not 20 gigs

My bad. I was thinking "Meg" and typed "Gig"... I got the last letter right  smiley-sad-blue

Quote
and we allready have fire on warehouse due to faulty  lithium ion batteries.
Working with it every day let you suspicious. trust me. (12 years of experience working with such batteries)
this is why airbus prefer to keep the old sealed lead acid batteries. like me!
it's physics! lower size with higher power = higher energy density ==> approach to explosives!

A DHL plane has already got fire due to Li ion batteries freight and now the IATA ask for lot of documentations about your batteries, CE certification, tests resuls before they allow you to send the batteries by air. if they are so secure why they ask this?

Sorry if I confused things... I was just giving another example of where an unprotected lithium battery caused problems. Any e-cig manufacturer (cig-type or mod) worth their logo doesn't use a battery without protection circuitry.
6  Using Arduino / General Electronics / Re: Need a battery source on: April 17, 2014, 01:22:42 pm
tell that to boeing smiley-wink
have you seen my videos? this is what I've done for the test: 2Amp overcharge.
we've got fire in production with varta li-polymer batteries some years ago (3/4 times)
the lithium polymer are more risky because they use soft case (instead of solid metal for lithium ion) and a mechanical stress causes internal short circuit -> thermal runaway -> explosion -> fire
actually Sony make a giant battery return for their laptop....
on each pack I build i'm using electronic safety + 1 polyswitch for each cell + 1 thermal cutoff....to be sure....
and even with that, the chemistry can cause some problems. here is a pack I've got from customer.
bad spot welding causes chemistry to fail and cell thermal runaway.

There is also a case a little while ago where someone's e-cig blew up in their face. Turns out the person didn't have any battery protection in his custom mod, but the news reporters neglected to mention that. Instead the spin on the story was how all e-cigs are dangerous explosion risks.

Regarding your video(s?). That 20+Gig zip file is a huge payload. Do you have a youtube/vimeo/etc link instead?
7  Using Arduino / Programming Questions / Re: Convert String (5-byte HEX) received via Serial to uint64 for nRF24L01+ address? on: April 17, 2014, 11:25:44 am
Yeah, I know how to assign addresses using the lines you quoted from the library.
That´s not the problem...
I´m receiving the TX address via serial from a computer and
want to change the TX address before transmitting data also received from the computer via serial.
The address is not hard coded in the arduino, but can change depending on what remote device the computer wants to send data to. As several remote devices shall be used, including all addresses in the arduino code is not feasible.

The data received via serial is the TX address and the payload to transmit both in string format. The payload can easily be converted from string to byte (actually int but in a byte array). The address however is a problem as it has to be converted from string to uint64.
Would it make sense to slice the string and convert it piece by piece to an int and assemble the data to the desired format?

I wouldn't convert piece by piece as an int, but as a byte... (Remember on Arduinos an int is two bytes.) Though I suppose you may want to read from the source string as an int to get both ASCII values into one variable to then convert down to an byte (high byte converts to high nybble, low byte converts to low nybble)...

Another method might be to have your address variable as a union of the uint64_t and a byte[] array. This would eliminate the tedium of shifting a 64 bit value on an 8 bit processor... Convert each byte from the two received ASCII characters to a byte hex value and then put it in the appropriate byte[] array index. Then read the completed uint64_t value. Just be careful to watch your byte order (both in order of conversion and in location of storage). You need to think about whether you want to store the value in byte[] indexes 0-4, 4-0, 7-3, or 3-7.
8  Using Arduino / Programming Questions / Re: Programming XBee to transmit and receive data on: April 17, 2014, 10:50:23 am
I will change my code and try it again using serial commands. But coming to the jumpers first, consider the picture attached.

My jumpers were in that position while I was trying to transmit and receive. I didn't change the jumpers on D0 and D1 at any point.

I did change the the other jumpers with the "3.3V" and "JMP" label, I shorted A-B and D-E ("left" position), during configuring the XBees using PuTTY. I changed them back to the B-C and E-F ("right" positions) after that.

Why would you change those? Those are zone 5 jumpers and the datasheet seems to indicate they have to do with operating voltage. I tried to look at the shield's schematic to figure out what that does, and I can't seem to figure out how changing those jumpers effects operation for 3.3V versus 5V. Not a very good schematic... I would actually use it as a teaching tool of some things not to do in schematics.

But none of that matters for the task at hand. For what we are doing, leave the zone 5 jumpers the way you have them in your picture.

Quote
Does the position of the jumpers at DIN and DOUT imply that Pin1 is the RX and Pin0 is the TX? If this is true then would I keep the corresponding jumpers in vice-versa in the other XBee?

Well, this can get a bit confusing. The DIN and DOUT on the shield are from the point of view of the XBee module.
* DIN is data in, also could be called receive or RX, metaphorically the XBee's ear.
* DOUT is data out, also could be called transmit or RX, metaphorically the XBee's mouth.
So, yes the way they are configured right now, Pin1 of the shield is the XBee's RX and Pin0 of the shield is the XBee's TX. It is done this way so the XBee's mouth is connected to the Arduino's ear (Arduino Pin0) and the XBee's ear is connected to the Arduino's mouth (Arduino Pin1).

Quote
Like in one XBee, I have the DIN of Pin1 shorted to the center and the DOUT of Pin2 shorted to the center. Would that mean in the other one I would have  DOUT of Pin1 shorted to the center and the DIN of Pin 2 shorted to the center?

Not quite. Those pins are only for communication from an XBee to it's physically connected Arduino. I want you to connect them up the same way on both shields: DIN on pin3 and DOUT on pin2. We will then use software serial (with RX set to 2 and TX set to 3) to communicate from each Arduino to their attached XBees. (Because of the way the XBees are configured they should already communicate with each other.)

This way you can use the hardware serial to communicate back to the computer so you can monitor debugging and diagnostics with serial monitor. (Where ever I can on my designs, I avoid using Arduino pins 0 and 1 for anything so I can look at debugging information on my computer when the Arduino is connected via USB.)

If you have two USB cables (if you don't, I would highly suggest getting a second one), connect both Arduinos to your computer at the same time. Have two ArduinoIDE windows running at the same time with the "SoftwareSerialExample" sketch loaded in both. Set one to the COM port of one of the attached Arduino boards, and the other to the COM port of the other attached Arduino board. In both IDE windows, change line 30 from SoftwareSerial mySerial(10, 11); // RX, TX to SoftwareSerial mySerial(2, 3); // RX, TX. Then change line 44 (mySerial.begin(4800);) to the baud rate that your XBees are configured for. (I use X-CTU to configure my XBees, because I'm running Windows and it is easier to click buttons than to manually use lookup tables to find command and setting codes. I presume you are also running Windows because you used PuTTy which is a Windows application... Why didn't you use X-CTU?) You can also change the header comment to reflect these changes, but for what we are doing this isn't important because you don't need to save the modified sketch. Upload the sketches to both Arduinos, and open the Serial Monitor for both IDE windows. What you type in one serial monitor should show up in the other serial monitor.

Once you are sure that you are able to communicate from one Arduino to the other, you know the hardware is correct. Now it is time to start writing code that will do what you want to do. If you are having hardware problems, ignore the following until we get the hardware sussed out.

When structuring your code, the more I think about it I think the raw 2-byte code plus some unique separator from the temperature sensor is what should be transmitted via XBee, and then do the conversions on the receiver end. Transmitting and receiving a float value isn't quite as straight forward.

Take a look at how you get the data from the temperature sensor. First you send it a command requesting data. Based on the command you sent you know exactly what data to expect so you put the first byte into data_low (this should actually be initialized as byte, not int), then you put the second byte into data_high (again, should be initialized as byte), and finally you put the third byte into pec. You know what format to expect and when the first, second, and third bytes will be transmitted. But with your Arduino to Arduino communication it might be simpler to not request data and just receive the data. Because only 1 byte at a time is transmitted over the XBees, how does the receiver know which byte it received is data_high or data_low? You will need some sort of handshaking to say "the following byte is the start of the data", or "the last byte was the end of the data", or both. And, that handshaking byte needs to be some byte value that will never be part of valid data. Unfortunately, looking at the possible values of both data_high and data_low i see all the possible values that can be contained in 1 byte (0x00 through 0xFF), particularly with the data_low byte. We will need to encode the values some how. The simplest would be to transmit the ASCII characters representing the hex value. I.E for the hex value of 0x2A, you would transmit the two ASCII characters '2' and 'A'. This type of conversion is already built into the print method we will be using to send the data from the Arduino to the transmitting XBee. Based on that, we know that the individual values being transmitted will all fall into the set of values for the ASCII digits and the ASCII capital letters 'A' through 'F'. These are 0x30 inclusively through 0x39 and 0x41 inclusively through 0x46, respectively. (If you don't already have an ASCII table bookmarked, I suggest this one. I don't even have it bookmarked because the url is so easy to remember: "asciitable.com".) You have literally every other one byte hex value to choose for your start and/or stop bytes. But for ease of troubleshooting, I'd probably suggest another printable ASCII character, and would probably avoid any in the two ranges 0x30 inclusively through 0x3F and 0x40 inclusively through 0x4F. This still leaves most of the symbols, all the lowercase letters, and uppercase letters 'P' inclusively through 'Z'. This would allow you to echo all the characters received for troubleshooting/diagnostics, even if you just act on the ones your are interested in.

I would probably suggest going with a start byte only. That way when your receiver sees that start byte it captures the next 4 bytes as data. Checking to see if the 4 bytes represent the only possible valid values, and if so then convert them. If one checks each one while receiving them then you can ignore bad data sooner. (Sort of like buzzing in on Jeopardy before Alex Trebek finishes reading the clue.) Then wait for the next valid start byte while throwing away any received bytes until then. This allows you to send new line characters for your first echo tests. Because the new line characters (CR and LF) will be the 5th and 6th bytes after the start byte, your receiving code would just throw them away along with any other noise.

Receiving the ASCII representations and reconstituting the hex value might be a bit tougher, so for now just write your receiver code to echo everything back to the hardware serial port by leaving the example loaded that we used to test the hardware connection.

You don't need to be constantly transmitting. What happens if you can't receive as fast as you can transmit? It would look like the scene from the old Lucy show when she is working at the candy factory. The conveyor belt speed would be analogous to baud-rate, and the spacing of the chocolates would be how often you transmit the temperature code. Even on a fast baud-rate, spacing the transmits out would allow the receiver time to catch all the packets and do other things (like process the packets, send the result on elsewhere, etc). For now I would suggest a nice even cadence of 1 second between each transmission of temperature. You can adjust this later if needed. You should also send over the hardware serial what you are sending over software serial. That way you can verify that what you are receiving is actually what you sent (just like with the hardware configuration testing I had you do earlier).
9  Using Arduino / Programming Questions / Re: Programming XBee to transmit and receive data on: April 15, 2014, 11:28:11 pm
When I had the same thing setup with one Arduino connected to my laptop, I merely Serial printed the values to my laptop.

Now when I have the two Arduinos each with a transceiver and Xbee shield, I really don't know what command to use to transmit or receive. I merely broke the early code into two parts:

The commands that you will be using will be some sort of serial write or print to send and a serial read to receive. You said in your original post you are using UNOs. Because the UNO only has one hardware serial port, on at least the receiver that needs to talk to the computer over USB using the hardware serial that XBee will need to use software serial. To make things a little simpler, I would suggest both XBees use software serial on the same pins.

1. In the transmitter Arduino connected to the Xbee, I placed the commands that obtain the data from the temperature sensor.
2. In the receiver Arduino connected to the Xbee, I placed the commands that display it in the serial monitor.

_________________________________________________________________________
Jumpers

This is the datasheet https://www.sparkfun.com/datasheets/Wireless/Zigbee/XBee-Datasheet.pdf

Yep, that was not the datasheet I was referring to because it has nothing about the shield. The shield datasheet can be found at iteadstudio.com's web page for their shield.

I have the jumpers in the right side position now. I shifted them to the left and also short the reset and ground pins at the time I configured them. I configured it using PuTTY and got OK too. Was I supposed to leave the jumpers in the left position even during the actual operation?

Your terminology is confusing. The terms "right side" and "left side" don't mean much to me because I don't know what the reference for left and right are. My best guess is by "right side" DOUT is shorted to the center row at D0 and DIN is shorted to the center row at D1 as shown in the first diagram on page 3 of the shield's datasheet.

I would suggest shifting both jumpers (on both shields) two places so DOUT is shorted to the center row at D2 and DIN is shorted to the center row at D3. Look at the examples for SoftwareSerial library. There are several examples distributed with the IDE to look at, and also read the reference page on this site for SoftwareSerial. When setting up SoftwareSerial in sketches with the jumper configuration that I'm suggesting here, RX will be pin 2 and TX will be pin 3.

See if you can start to get things working with what I've pointed you towards now. I already see one stumbling block, but I want to see if you can get to it before I start confusing you by getting too far ahead. I guess I could foreshadow it, serial data is only read in one byte at a time and a float is 4 bytes. But lets get something (even if it isn't the eventual intended thing) to transmit from one XBee to the other. Small steps.
10  Using Arduino / Programming Questions / Re: Programming XBee to transmit and receive data on: April 15, 2014, 09:55:23 pm
Neither of your sketches actually attempt to transmit or receive anything over the pins that are connected to the XBees.

How do you have the serial communication jumpers (indicated by the datasheet for the shield as zone 3) set? I have a suggestion, but I want to first see how you have them currently configured.
11  Using Arduino / Programming Questions / Re: Arduino blocks i2c bus on: April 15, 2014, 10:12:23 am
Thanks for all the replies everyone!

Power:
The USB cable was not the power source, it was there for downloading code. The actual source was a 10v regulated bench supply to the Vin pins.

Yet if you look carefully at your dropbox picture of how things were actually wired, you have a red power wire going from the breadboard to the 5V pin of your UNOr3 (the one in the upper right of the picture). I'm not sure how you didn't release the magic smoke with twice the voltage...
12  Using Arduino / General Electronics / Re: Shift registers - only good for LEDs? on: April 15, 2014, 09:59:16 am
Thanks everyone for your replies. Unfortunately, it still doesn't answer my question !
I understand the limited current capacity on the outputs of the shift register, which is why I asked whether a transistor, or Darlington pair, could be used to pump up the current.
It seems to be perfectly capable of passing on PWM to RGB LEDs, and I have seen projects driving high powered LEDs through 595s.
I guess maybe therein lies the answer.

I'm reading your posts, are you are asking about using PWM through a '595 or similar? My first inclination is that the amount of shifting required to have a reasonable base frequency wouldn't leave much else for the Arduino to do. Then I found this thread suggesting using a TLC5940 instead of software, this thread discussing driving PWM through a normal s2p (serial to parallel) shift register with software, and finally this library for software PWM using interrupts through a normal s2p shift register for up to a 75Hz PWM on each shift register output.

LEDs are just used as examples. Lets say you have a large, complex pluming project for a fountain display. In your fountain display you have 30 valves that you need to control and want to use an Arduino UNO to run your show program. Daisy-chain four s2p shift registers and only use 3 pins on the Arduino to control up to 32 divices (valves, lights, curtains, audience zappers, etc.). You will need to have driver circuitry for each of the devices to provide the voltages and currents required to actuate them, but the actual control signal comes from the s2p shift registers. Just the first example that came to mind.

Drat... Now I have a desktop fountain display VU meter concept trying to take root in my mind. Control the height of each fountain jet based on amplitude of a frequency range. Water is (and mechanical valves are) fairly slow to respond so PWM may not be needed, just fast switching. Each fountain jet is normally illuminated with a green LED except at peak when it gets illuminated with red... Anyone else is welcome to take this idea and make an instructable out of it... smiley-wink
13  Using Arduino / General Electronics / Re: Can code be a substitute for a resistor? (noob alert!) on: April 15, 2014, 08:56:08 am
One could write an article on the frequency of homophone spelling errors appearing in these posts.

But I'm not going to.


I suspect that an in depth study relating homophone misuse to poster's nationality and primary language would be quite depressing to those of us who are primary English speakers in the US... Just remember:
Quote
Dew knot trussed yore spell cheque or two fined awl missed aches.

That said, I also suspect that most spelling and grammatical errors here are due to the poster's primary language not being English, and their grasp of my native language is much better than my grasp of any language other than English. So I give them a very big pass. (I may suggest a correction, but hopefully not in a condescending manor). Other spelling/word oddities may be region based. A few US vs. UK equivalencies: color == colour, truck == lorry, SPDT switch == SPCO switch, billion == milliard, etc.

Hmmm... what was the topic of this thread?
14  Using Arduino / Programming Questions / Re: Arduino blocks i2c bus on: April 15, 2014, 12:00:50 am
By parallel do you mean physically or electrically?

<code snipped, I'm not replying regarding code...>

And an image (link, not sure how to embbed): https://drive.google.com/file/d/0BwtZtfwjz_MwcWkwTVVxWHI0cDg/edit?usp=sharing

I keep looking at where the power wires are going. I see on the r3 you have it connected via USB and the red jumper is connected to 5V. This seems to indicate to me that you are sourcing power from the r3. Is this correct? If so, then powering 2 Arduinos only leaves about 100mA to 260mA left to power what ever is on the other end of the alligator clips. You may be experiencing brown outs if you are trying to pull more than 500mA from the USB port.

I see on the older UNO that you have the red jumper to Vin. This pin has the same restrictions as the barrel jack, in that it should be at least 2V higher than 5V, not the 5V your are feeding it from the r3 (if that is indeed the source).

Where are the alligator clipped power jumper wires going at the top of the picture? If that is the voltage source, what is that voltage source set at? If greater than 5V you may be on the way (or already have) fried your r3. If it is set at 5V (and is well regulated) you should also have the older UNO connected to it via the 5V pin for the same reason as the previous paragraph.

One further comment about your wiring... avoiding wiring mistakes (and asking us to help) would be greatly assisted if you didn't use yellow for both SDA and SCK...

(One nice thing about pictures of rats nest of wires, it is at least how things actually are wired, instead of how things are intended to be wired from a schematic or sketch. But they can sometimes be a bear to figure out, even with multiple angles...)
15  Using Arduino / Programming Questions / Re: Problems when casting some values to long, other cast just fine on: April 14, 2014, 11:11:10 pm
If your integers will never have (or never should have) negative values, try using unsigned int. Doubles the max int from (2^15 - 1) to (2^16 - 1).

Not sure how large you want f0 to go, but watch that (f0 * 400) has a smaller value than the max possible value of the datatype you want to use over the expected range of f0. See the different datatypes on the Arduino Reference page.
Pages: [1] 2 3 ... 30