Show Posts
Pages: 1 ... 3 4 [5] 6 7 ... 248
61  Using Arduino / Networking, Protocols, and Devices / Re: XBee question on: April 01, 2014, 09:58:32 pm
It wasn't a huge LED, but it was a fairly high output white one.  I saw that it claimed internal pull-up resistors, so I didn't think I needed one.  Plus the circuit in the Series1 tutorial didn't use one.  Ugh.  There was a time when I would have never considered not using one, but I've seen more and more examples of not needing them lately that I got sucked in.

Size doesn't matter  smiley-wink much, even a small LED will draw a lot of current given the chance, the V/I curve is pretty much exponential. Lots of bad practices out there, some in books even.

I can't do anything more than ask the gate to open via the relay, but still like the idea of the heartbeat.  I guess I can use a mini arduino on the sending side to keep things small.

Or just set the XBee up to transmit once a second or something. No MCU needed then.

Anyway, great insight.  Thanks.  My life would have been a lot easier if I had never seen those series 1 tutorials, but I think you got me straight.  Again, many thanks.

You bet. Good luck again, hope your XBees are OK. I'd start by reloading firmware then checking them out. Great little devices.
62  Using Arduino / Networking, Protocols, and Devices / Re: XBee question on: April 01, 2014, 08:30:18 pm
I'll test that broadcast/coordinator ID chat again soon.  I assumed it was going to work and was a bit surprised when it didn't, but didn't dig further.  The only settings that had been touched were PAN ID and the Destination addresses, but maybe I screwed something up there and just didn't notice.

PAN ID doesn't matter, as long as they are both the same of course. But be sure DH and DL are set to their default values, OR set DH and DL to zero for the router (which is the default) and set the coordinator's DH and DL to those of the router. That'll get things into a unicast situation which is what I would want anyway.

I wasn't trusting the pinouts of the Series1 articles in any way, just using them as a guide.  I know I connected power/ground correctly from my 2xAA battery pack.  The only other thing I connected was on one of them a switch that was pulling an input pin to ground (DIO pin 0 configured as a digital input) and on the other DIO pin 0 was connected to the long leg of an LED with the other end connected to ground and it was configured as "digital output HIGH".  I assumed the HIGH/LOW part was just what state to put it in as bootup and that from then it would flip it however it was told to.  (And I was using two Sparkfun breakout boards, which have the pinouts labeled where you can see it easily over the breadboard.)

Given that, I can't see how I could have hosed them.  I would think it would be especially odd to hose them such that they both APPEARED to work fine as far as XCTU was concerned but simply wouldn't talk over the radio.  I would have assumed total annihilation, or just for the input/output pin itself to quit working.  But obviously with these things anything is possible, I guess.

Always, always, always use a series current-limiting resistor with an LED.  Further, the XBee I/O pins have very limited current source/sink ability, only a few mA. I usually use a 1K resistor for LEDs with XBees. If the LED was still working, maybe things are OK, maybe not.

So my application is pretty simple.  I'd like to make a long range gate trigger.  I could probably drop back and punt to Series1 devices, but I was hoping to use Series2 in case I need to put a router in to extend my range.  I own a lot of property BEFORE you get to the gate I want to trigger (which only needs to close a relay on the receiving side, so that's dead simple), so I could get a router further out.  Basically the gate is SLOW and I'm impatient.  I can actually open the stupid thing with my cellphone already, but that's not reliable due to cell coverage in the area.

And I was HOPING to do it without an Arduino in the mix, since it's really a simple button press on one end to flip a relay on the other.  I'm guessing I can still do it, but it sounds like it's a good bit more involved using Series 2, and may be easier to just add the Arduino on the receiving end (I do want to have multiple senders and was planning to add the encryption layer for security).

Very much doable and straightforward with the ZB modules. The difference is at least one microcontroller will be required, which may not be the case with the 802.15.4 modules. Just off the top, having just an XBee at the gate, and an Arduino/XBee combo for the control should work fine. Basically the Arduino would just send a remote command to set a pin high or low on the gate XBee.  Add an Arduino at the gate and then it could transmit its status back to the control node. Actually that might be doable without an MCU too, just by enabling periodic I/O transmissions. That would be cool because as soon as the control was in range of the gate you could have a notification of that fact, plus the current status of the gate, i.e. open or closed. Add a limit switch to tell when the gate is really closed and it could be a fairly robust system.

Good luck!
63  Using Arduino / Networking, Protocols, and Devices / Re: XBee question on: April 01, 2014, 07:41:42 pm
One thing I noticed with my two working Xbees is that if you use default Router and Coordinator destination addresses (zero on the Router so it talks to the Coordinator, and FFFF on the Coordinator to broadcast), I could NOT chat both directions.  I could only get text to go from the Router to the Coordinator, but not the other direction.  But when I switched back to hard coded destination addresses, text flowed both ways (with NO other changes to the XBees or the terminal emulators).  Is that normal?

I sure would think I'd have noticed if I couldn't transmit in both directions. Is everything set to factory default values?

And that doesn't address communication using i/o pins.  Should what I describe (and what the Series1 articles I link describe) "just work" with a Coordinator AT and a Router AT?  Because in one instructional video I found, it seemed to imply anyway that one was going to need to be API and one AT, but I forget which it said.  I think the one with the switch was supposed to be API and the one with the LED could be AT.  Something about *serial* I/O being fine with both AT, but if you wanted I/O from input pins then it was going to need to send it using API frames.  I'm still a bit fuzzy on that part.

The 802.15.4 modules (fka Series 1) have a facility called "I/O line passing" that the ZB modules (fka Series 2) do not have. If you do not already have them, get the product manuals here and here.

The ZB modules can send I/O data sample frames at regular intervals. To receive these, the receiving node must be in API mode. Also, remote AT commands can be sent to control the I/O pins on a remote module (among other things). This requires the module sending the remote commands to be in API mode.

And so even if you are saying pin based I/O should work based on your article (one Coordinator AT with a single pin as "digital input" and one Router AT with the same pin as "digital output HIGH"), is there any chance I hosed my two XBees, or should they work just like the series 1's in the article above?  By that I mean with the same "circuit" on each end, I know the setup is different.

I am not saying that. Whether your modules are hosed, I cannot say but certainly there is some chance that they are. The pinouts between the two types of modules are only mostly the same, so I would certainly not wire one type of module into a circuit designed for the other without studying the product manuals and the circuit long and hard.
64  Using Arduino / Networking, Protocols, and Devices / Re: XBee question on: April 01, 2014, 06:31:54 pm
Simplest way I've found:
65  Using Arduino / Project Guidance / Re: RTC DS-1307 on: March 31, 2014, 10:23:36 pm
I've been working with the DS3231 a little bit, which is a newer, pin for pin compatible version of the DS1307.

It doesn't have the same number of pins, and doesn't come in the same packages, therefore I wouldn't call it pin-for-pin compatible.
66  Using Arduino / Sensors / Re: arduino datalogger? on: March 31, 2014, 03:49:08 pm
Jack, sounds like your data logger might work for me.  Just a few more questions?  1) How do I get the data to my PC?

A USB-to-TTL serial converter (e.g. FTDI) along with a terminal program on the PC is required. I've used Adafruit's FTDI Friend and Sparkfun's FTDI Basic and both work well. For a terminal program, I seem to use CoolTerm mostly, but TeraTerm, puTTY, or others will suffice. A "capture to file" function is good to have if there's a lot of data to download but I think most terminal programs support this.

2) How do I buy it and get it sent to me?

I'm not offering them generally ATM. I could work up a price and build you one, but there are a couple things to think about. (1) It's not a real inexpensive solution. I used two or three components that are a bit pricey but there weren't less expensive alternatives that met my requirements. Ballpark only and not an official quote, but I'm guessing $75-$85 to build one.

(2) Coding will still be required. My standard firmware isn't geared for data rates faster than one sample per second.

As I've learned more about your requirements, I'm coming to the conclusion that my logger probably isn't any better fit than just an Arduino with an SD card for logging. My logger is aimed at low-power long-term logging, neither of which are key requirements for your project.

Glad to discuss further if you like, but I don't want to lead you astray either.
67  Using Arduino / Programming Questions / Re: How to disable Arduino Environment's use of Timer0? on: March 29, 2014, 07:07:22 pm
@bobo, you are correct, what you propose is an incredibly simple solution, makes perfect sense to me and I would welcome it. The thing you are missing is that part of the demographic that Arduino is aimed at are rank beginners that don't necessarily understand computers or programming and likely haven't written a single line of code in their life. To them, at least initially, a bunch of #includes, although they can easily just be ignored, do add visual noise and I imagine that what the design team was going for was a very straightforward uncluttered environment. I can see the point, but I don't completely agree either. Another approach to the same end would be to have the IDE run in two modes, novice or expert, where the latter would behave as you describe. But that would represent added development and maintenance costs, and the argument would be that the experts can use the existing tools oriented towards experts.

Seriously, if you've appropriated all the timers to your own ends, it sounds more and more like a project that would be just as happy in WinAVR or Atmel Studio.

I've used Atmel Studio some, but not what I would call extensively. I am aware that there is an Arduino extension for it. I have not tried it, but I wonder if it wouldn't give some of the flexibility you seek.
68  Using Arduino / LEDs and Multiplexing / Re: TTL BCD-7 Segment display driver IC, problem on: March 29, 2014, 06:13:12 pm
I want to use 5 volts, so I looked in my TTL cookbook.  7447.  Ok, but it is for common ANODE displays.

What's on the next page, right after the 7447?
69  Community / Gigs and Collaborations / Re: help brother , serious project will be real with your help on: March 29, 2014, 06:07:27 pm
3) Maybe they don't have an answer.

4) Maybe they don't have a question.
70  Using Arduino / Programming Questions / Re: How to disable Arduino Environment's use of Timer0? on: March 29, 2014, 01:05:11 pm
Just to add to PeterH's reply, check out WinAVR, and also Atmel Studio,
71  Using Arduino / General Electronics / Re: another soldering quesition - perhaps incorrect use of flux? on: March 28, 2014, 09:53:35 pm
I wouldn't use solder from Radio Shack on a bet, not even for plumbing. I only use 63/37 alloy for electronics. For fairly new through-hole components, flux is not usually necessary (other than what's already in the solder). I'm a real Kester bigot. This is my favorite solder. I use this flux for SMT projects. If I need something a little more aggressive, I use this flux. I use one of these to keep the tip of the iron clean.

Brown means burned and is bad. Iron may be too hot or was on the board for too long. If the board gets burned the components can't be far behind. It shouldn't take more than a very few seconds to make most solder joints.

Vigorously scratch the hot tip with a stainless steel table knife over oxides areas then try to re-tin it.
Don't tell you wife I said to use her table knife.

The green (abrasive type) Scotchbrite works too.
72  Using Arduino / Sensors / Re: arduino datalogger? on: March 28, 2014, 09:36:18 pm
Thanks Jack.
You haven't been discovering any weird problems with data sheets lately smiley-wink

You're welcome. Yeah I've been slacking a bit, not reading enough of 'em  smiley-grin   Reading tax forms tonight  smiley-money  smiley-eek-blue  smiley-cry
73  Using Arduino / Sensors / Re: arduino datalogger? on: March 28, 2014, 07:32:42 pm
I have a datalogger of my own design (based on Arduino) that might work.
@Jack,   Is this shareable?

Actually, I hope to be sharing it in Atmel's "Simply AVR" contest soon as I can get a video made.

In the meantime, hardware design is here and firmware is here.

There's a User's Guide in the firmware repo and a photo here.
74  Using Arduino / Project Guidance / Re: Demonstration code for several things at the same time on: March 28, 2014, 07:28:03 pm
Mighty impressive project there!

Curly braces enclose a block of one or more statements. The block of statements could be the body of a function. So in the example, the function is named "f" (very original) and the outermost pair of braces enclose the function body.

The function f() expects three integers as its input arguments and its return value is likewise an integer.

Within the function we have an if statement, which if the condition (x < foo(y, z)) is true, executes a block that consists of one statement, haha = bar[4] + 5;

If the condition is false, then the else block gets executed. Within the else block is a while statement that executes a block of two statements as long as the condition (z) is true.

Sounds worse than it is when it's written out like that. Don't analyze it too much because it's just an example and a lousy one. For one thing, the function only returns a value if the else branch is taken. That's at least bad form, and likely to cause a problem, because the caller would expect the function to return an integer regardless. Another function foo() is called in two places within f(), but we don't know what it does. So again just an example.
75  Using Arduino / Sensors / Re: arduino datalogger? on: March 28, 2014, 05:58:23 pm
The Arduino analog-to-digital converter (ADC) has ten bit resolution, which means it outputs numbers between 0 and 1023. These would normally be stored as 16-bit integers (two bytes). So 512kB will hold far more samples than required here.
Pages: 1 ... 3 4 [5] 6 7 ... 248