[Windell Oskay]

Hi Jim,

I’m sorry to hear about the trouble.  If the power is good, then you’re right that the chips should be the next suspect.  I’m not sure what could have happened– could be power surge related, for example. 

 The one other thing that you might try is to reprogram the clock, and see if it will accept that, either with an AVR ISP programmer or an FTDI type interface.  (Since you were thinking of reprogramming it, I suspect that you have one or both of these interfaces available.)

Otherwise, if you’re willing to, I’d ask that you return the chip set to us so that we can test them here, figure out what happened, and replace/reprogram/return them in working condition– please contact our store directly by e-mail or with the contact form. 

-Windell

[Windell Oskay]

Also, check the orientation of the phototransistors and the two diodes.  Any of those backwards would cause this condition.

[Windell Oskay]

Running the LED display takes a certain amount of CPU time, as would running spectrum analyzer code, so while I am certain that it can be done, I am not certain *how fast* it would be. 

You might begin by looking at the Peggy2 library for Arduino and the existing FFT spectrum analyzer code out there; here’s an example that might be a good starting point to look at: http://blog.arduino.cc/2010/11/16/arduino-realtime-audio-spectrum-analyzer-with-video-out/

[Windell Oskay]

Essentially, you need to duplicate the functionality of the program to send the data to one Peggy to send it to the other as well. It may be easiest to generate two separate 25×25 arrays in the Processing sketch, and duplicate the existing code that sends the 25×25 array to a single Peggy.

[Windell Oskay]

While there is an SPI hardware interface available, there is no software presently implemented to receive commands or codes over SPI– the code would have to be written to do that.

[Windell Oskay]

Yes, the SPI interface is available.   

Also, the Octolively already has 8 sensors onboard– to operate those IR sensors –and 5 additional digital I/O lines normally connected to the neighbors.  That’s up to 13 lines, 8 analog/digital, 5 digital.  Depending what you’re trying to sense, the easiest option may be to repurpose some of the existing lines. 

[Windell Oskay]

LED D2 is controlled by pin PD6/OC2B.  LED D1 is controlled by pin PD7/OC2A.

The definitions and functions of TCCR2A and TCCR2B are given in the ATmega644’s datasheet.  

The default code to configure those two registers is as folows: 

 TCCR2A = (_BV(WGM20) | _BV(COM2B1)); // PWM, phase correct, top: FF, overflow at bottom 

 // Drive output OC2B (nightlight) with value OCR2B 

 TCCR2B = (_BV(CS20)); // System clock w/o prescaler.
// so overflow happens at 16 MHz/2*256 = 31.250 kHz

I would suggest *not* changing the clock source bits of TCCR2B, as those select the clock source used by the PWM subsystem, not which outputs are enabled.

If you do look at the datasheet, it will tell you what the different bits actually do.

In TCCR2A, the enabled bits are WGM20 and COM2B1.   

* WGM20 being enabled (Without WGM21 or WGM22) sets the mode of the timer to “Phase correct PWM.”   You don’t need to change that.   

* COM2B1 (without COM2B0) is a command to set Clear OC2B on Compare Match when up-counting, and set OC2B on Compare Match when down-counting.  This is what actually hooks the timer to the output pin. 

For a proper analogy, we should set OC2A to behave the same way, by enabling bit COM2A1, as follows: 

TCCR2A = (_BV(WGM20) | _BV(COM2B1) | _BV (COM2A1)); 

Why don’t you give that a try, and see how it does.

[Windell Oskay]

They’re custom machined out of Delrin.  They slide directly on the wood, and the friction is generally negligible compared to the rest of the system.  We verify this by turning it upside down, and seeing that it doesn’t change much. ;)

There are some polargraphs made with the EBB– that’s how quite a few of them got started. 

[Windell Oskay]

That definitely sounds like a problem with one channel of the EBB.  Please contact our store directly about getting a replacement:  http://shop.evilmadscientist.com/contact

[Windell Oskay]

I would second that!

[Windell Oskay]

The current design of the WaterColorBot frame does not permit vertical operation.  The rods glide on sliders that are held down to the frame by gravity.  It would be possible to design new rod-end sliders that would constrain the rods vertically, in which case vertical operation would be possible.

For the originally intended application– using watercolor paints — only horizontal operation is suitable, as we also assume that the water in the little dishes can be held down by gravity. ;)

[Windell Oskay]

I’m sorry to hear that you’re still having trouble with it.  However, it is likely that the kits are both recoverable, should you decide to look into it again.

[Windell Oskay]

Hi Glenn,

You do not have to program the microcontroller at all– it comes preprogrammed, and it *is* working correctly if you see one of the LEDs lighting up now and then.  (If you do have a reason to reprogram it, you’ll need an AVR ISP programmer.)

First, try to figure out what’s wrong with the other LED.  There is *very* little that can go wrong here.  The LED is connected on one side to the pin of the chip and to the resistor, and on the other to ground.    Either, the LED is backwards, or there is a missing connection at one of those points. 

Trace the wires and connections, and try to see where they go and match them to the circuit diagram.  At every connection, look to see if you can physically observe how the parts– either wires, solder joints, or copper traces on the circuit board –are connected, to make sure that the diagram is actually implemented.  (And, if you have access to a multimeter, use that to verify connections between those points.)  

If you can verify that all of the connections are correct, it could be that the LED is soldered in backwards.  You can check this by disconnecting one of its leads (desolder one of the two wires that touches the leads of the LED, and touch it one way or the other across the leads of the working LED.  That should tell you if the LED itself is good, and connected with the correct orientation.

For the servo, follow the same basic procedure, however note that there are now three wires, not two, to trace.

With regards to the other kit, with the damage to the socket, it’s not beyond repair, so long as you haven’t actually torn off any of the pins.  Strictly speaking, a socket is not needed, and you can wire the relevant pins– there are only six of them that matter –directly to the circuit board with a little extra wire if needed.

[Windell Oskay]

Sorry– didn’t see your message until you had already found the answer.  The “canonical” guide is the Sanguino:  http://sanguino.cc/hardware

[Windell Oskay]

So my best guess as to the root cause: You pressed the bent-over LEDs down to the board *really well,* enough so that the little barbs just below the lens plastic cut through the solder mask, and into the traces below, causing some sort of short circuit.  It may have damaged the IC, or the LEDs– not sure.  I don’t see any other signs that point to a possible cause.  Your soldering job was impeccable, and all of the components *seemed* okay otherwise.  

And again, this is a new failure mode for us to see– we’ll obviously keep an eye out for things like this in the future.

[Author]

Posts