Show Posts
Pages: 1 ... 123 124 [125] 126 127 ... 248
1861  Using Arduino / LEDs and Multiplexing / Re: Help needed for 7 Segment LED and 74hc595 shift register countdown project on: November 07, 2012, 07:18:25 am
OK, well as ever, GIYF, but here's the deal. If each digit is driven directly, eight connections (seven segments plus decimal point) are needed to each digit. To make a four-digit display, 32 individual connections must be made. In a multiplexed display, the corresponding segments (a-g, dp) are all connected together, but only one digit is illuminated at a time by individually controlling the common pin for each digit in addition to the segment pins. This only requires 12 connections (8 segments plus 4 digits). Each digit is illuminated in turn, very rapidly (hundreds of times per second) and persistence of vision makes it appear that all are lit. Adding more digits only requires one more connection per digit.

A multiple-digit multiplexed display can be built from several single-digit parts, but a multiplexed display like the one you have cannot be driven directly as all the corresponding segments are connected together internally. Note on the datasheet for the four-digit display, there is only one set of segment pins A-G, where in the circuit you linked there are two sets of A-G connections.

It's important to control the current when powering an LED. The simplest way to do this is with a resistor. Each individual LED needs a resistor. So in the direct-drive situation, a four-digit display would require 32 resistors (8 per digit), where a multiplexed display requires only 8, regardless of the number of digits.

The circuit you linked is a poor example in that it tries to take a shortcut to reduce the number of resistors by putting them in the common line for each digit instead of the segment lines. This will result in uneven brightness, i.e. the individual segments will be brighter for digits like "1" where fewer segments are illuminated than for digits like "8". Here is a better schematic showing how to connect direct-drive vs. multiplexed displays with proper resistors.

You'll also want to understand the difference between common-cathode and common-anode displays.

Hope this helps. Pick up a couple single-digit units to work with that circuit. Once you've conquered that, give multiplexing a try. There are several ways to do it. It can be done directly from an Arduino, through shift registers, or with a dedicated multiplexing chip like the MAX7219 or MAX7221.
1862  Community / Gigs and Collaborations / Re: Aloha! Will trade Tiki Mugs/Tiles for coding help on: November 06, 2012, 11:12:00 pm
These might simplify things:
http://evilmadscience.com/component/content/article/189
1863  Using Arduino / LEDs and Multiplexing / Re: Help needed for 7 Segment LED and 74hc595 shift register countdown project on: November 06, 2012, 11:00:57 pm
The circuit and code are designed to drive two individual single digit 7-segment displays. The 4-digit display linked from Mouser must be multiplexed. Do you understand the difference?
1864  Community / Exhibition / Gallery / Re: Warning! One Million Ohms on: November 06, 2012, 08:23:08 am
How long will the batteries last? (2xAA) +/- ?

Of course it depends on how much use it gets. The circuit goes into power-down mode after five minutes, but I'd guess at least several months with frequent use, could be a year or more with less use.  With the power-down logic disabled, i.e. running 7x24, it will run 2-3 weeks on a fresh pair of alkaline cells. (The power-down logic can be disabled by holding the button down while inserting the batteries.)
1865  Community / Exhibition / Gallery / Re: Warning! One Million Ohms on: November 05, 2012, 10:09:03 am
Sweet, thanks for the update. I'd seen those small LiPos and they look pretty nice. So you use the same charger that you would have for the bluetooth headset?
1866  Using Arduino / Networking, Protocols, and Devices / Re: Finally taking a look at the XBee library on: November 02, 2012, 07:54:00 pm
Turned out to just be bad parameters. Actually I don't know why it worked at all, but it seems ok now.
1867  Using Arduino / Networking, Protocols, and Devices / Re: Finally taking a look at the XBee library on: November 02, 2012, 03:44:07 pm
The Digi KB article I linked above mentioned that. Hadn't thought about it, but makes sense I guess, for the same reason that API nodes can talk to AT nodes. The interface mode (AT, AP=1, AP=2) describes how the XBee communicates over its serial interface, not how it communicates over the air to other nodes. The latter is always the same.

I've got a weird one this afternoon. One XBee will not communicate from my basement workshop to my upstairs office, even with another node only feet away. If I bring it upstairs it seems OK. Another is fine in the workshop. Do not believe I'm anywhere near the edge of the range but a range test is probably in order just to rule that out.
1868  Using Arduino / Networking, Protocols, and Devices / Re: Finally taking a look at the XBee library on: October 31, 2012, 10:57:30 pm
Good stuff to know. So bottom line, with AP=1, the XBee watches for the start delimiter, then collects however many bytes are indicated by the length. If bytes get dropped in transmission, then the next packet can be lost too since its start delimiter may then be considered to be part of the first packet. With AP=2, any time a start delimiter is received, whether the prior packet is complete or not, it's considered to be a new packet, and so one bad packet does not cause the next potentially good one to be lost.

Why XON/XOFF are required to be escaped with AP=2 is still a bit of a mystery. You have shown that it is not for the benefit of the XBees. So perhaps for other uses. The product manual could certainly stand to be clearer on this. Good discussion, thanks!
1869  Using Arduino / Networking, Protocols, and Devices / Re: Finally taking a look at the XBee library on: October 31, 2012, 12:59:59 pm
This seems to hint that the XBee in mode 2, will respond to the XOFF and stop sending stuff.

Exactly, I agree. But I can't find any such thing described in the product manual.

Digi says AP=2 provides increased reliability, especially in noisy environments, while AP=1 is easier to implement software for. Meh. OK, maybe a little easier.
http://www.digi.com/support/kbase/kbaseresultdetl?id=2199
1870  Using Arduino / Networking, Protocols, and Devices / Re: Finally taking a look at the XBee library on: October 31, 2012, 11:54:39 am
Ah, great, thanks, I am with you now! Never tried it, but I knew XBees would do RTS/CTS flow control, and I thought I remembered that they also did XON/XOFF flow control, but I can't find that in the doc. More CRS I guess. But given that, what would be the reason for escaping XON/XOFF? I still wonder why there are two API modes. Evidently it's not for the XBee's benefit, so then it must be for other devices that the data may be passing through, that might respond to XON/XOFF. Would you agree?

Maybe Rapp insists on AP=2 for the same reason.

I would certainly agree that the XBee product manual is vague about this, and especially about why the two modes exist. Your dissertation smiley-wink seems solid enough, I'm still a bit fuzzy though on what the product manual is telling us and whether it is saying the same thing. Actually a test might not be all that hard, and I'm just crazy enough to try it. It would just take two XBees connected to two instances of X-CTU, and entering a short packet in hex, so not terrible. Will report back if I try it! Thanks again, may all your checksums add up smiley-lol
1871  Using Arduino / Networking, Protocols, and Devices / Re: Finally taking a look at the XBee library on: October 31, 2012, 08:18:50 am
Jack, I must be misunderstanding something because in AT mode, everything going in the serial port goes out the transmitter (except commands), and if you're using API mode, you can't see it unless you piggyback off the serial pins for something to monitor.

Correct, it can't be seen because it doesn't go out over the air, and that is exactly what I do, piggyback on the serial pins. That is a node-at-a-time scenario of course. I do remember the approach of using broadcast for everything and then being able to monitor all network traffic from a single XBee. Cool idea, at least until the network chokes from lack of bandwidth.

Quote
And regarding API mode 1, we've had this discussion twice now.  The digi document is somewhat vague and people constantly misread it.  I've even shown you code that works regardless of the data sent in API mode 1.   Remember this thread a while back where I showed you working code under API mode 1?  http://arduino.cc/forum/index.php/topic,76591.0.html

Wow, that was a year ago! Now I do suffer from a condition called CRS, which is a side-effect of too many birthdays, but I did review that thread and the product manual again, and I'm evidently still misreading it. Please try me again because I really would like to understand your point.

I'll try again too, here is the way I see it:

The illustration from that thread seems abundantly clear to me: If AP=2, then everything after the 0x7E start delimiter, including the length bytes and checksum, needs to be escaped. EDIT: And, if AP=1, then certain characters cannot be sent because they interfere with frame sequencing. These are 0x7E (frame delim), 0x7D (escape), 0x11 (XON), 0x13 (XOFF).

The example you showed was just that, an example, a special case that just happens to work. But here's what I don't understand: What if the packet length had been 0x13, a value that needs to be escaped? What if unicast mode was being used and the destination node had 0x7E as part of its 64-bit address, as in the case of the OP in the other thread? I do not see a general case where AP=1 can always be counted upon to work (i.e. have no bytes that need escaping).
1872  Using Arduino / Networking, Protocols, and Devices / Re: Finally taking a look at the XBee library on: October 30, 2012, 08:48:13 pm
The additional traffic (debug messages) don't make it onto the network, the XBee ignores them. But on a very active node it can be hard to pick things out. My data rates are quite low, but even so, a terminal program with capture-to-disk capability is often very helpful.

Regarding API mode, when using it, I only use AP=2. I have yet to figure out why a person would use AP=1, or indeed why it even exists. Rapp specifies that AP=2 should be used with his library anyway.
1873  Using Arduino / Networking, Protocols, and Devices / Re: Finally taking a look at the XBee library on: October 30, 2012, 06:09:39 pm
I will have a look as well, but just off the top, I don't get it. I've used Andrew Rapp's library with S2 XBees in API mode for some time now, exclusively on ATmega328Ps, and it is really useful. For debugging purposes, I just write debug messages to Serial exactly as I might without an XBee in the picture. As long as the debug messages don't include the 0x7E start delimiter (easy enough to avoid, yes?), the XBee ignores them. Sure, on the serial monitor I see the XBee traffic as interspersed gobbledegook, but it is debugging after all.
1874  Using Arduino / Microcontrollers / Re: ATTiny85 run at 1Mhz When I Program "delay(1000)" does not give 1 second? on: October 30, 2012, 10:23:36 am
So I can run it at 16mHz with no external crystal...? Cool!

Yes, I do believe that is true!

Looks like these chips still have a few surprises left... It seems weird that I never saw 16mHz mentioned anywhere and there's no option for it in any of the Tiny85 IDE add-ins I've seen.

Arduino-Tiny comes with a boards.txt entry to run at 16MHz using the PLL.
1875  Using Arduino / Microcontrollers / Re: ATTiny85 run at 1Mhz When I Program "delay(1000)" does not give 1 second? on: October 30, 2012, 09:17:16 am
16MHz divided by 8 = 2MHz
Yeah but the PLL when used as system clock source is nominally a 64MHz clock, so divided by 8 gives 8MHz.

While I haven't actually actually tried this clock option myself, the way I read it is that setting CKSEL[3:0] configures a 16MHz system clock by dividing the 64MHz PLL by 4. Now on top of that, lfuse=0x61 sets the CKDIV8 bit, which further causes the clock prescaler to divide by a factor of 8 on top of that.
Pages: 1 ... 123 124 [125] 126 127 ... 248