After spending a few days pondering, admiring, and salivating over this,

Archive FastLED Archive
41

I thought (and drew) some more today, but in electricals … It’s been suggested that an ATTiny85 be added to each individual pod to locally control the encoder (as opposed to trying to multiplex hundreds onto a master controller), that’s trivial. Controlling the RGB LEDs, while I can do that with PWM signals, that means three pins, whereas if I use a driver such as a WS2801, LPD8806, or even use APA102 LEDs, I only need two wires. And for those who can live without the clock line, that’s a single wire. Me? I prefer that clock line. Two it is.

So let’s break it down:
Using (up to) 12V input means adding a regulator. Then there’s the ATTiny85, the sensor, and the output for the LED driver (regardless of which).

the ATTiny85 will be crowded on all pins:

PIN1 - RESET
PIN2 - Sensor output A Interrupt - PCINT3
PIN3 - Sensor output B
PIN4 - GND
PIN5 - MOSI
PIN6 - MISO
PIN7 - CLOCK
PIN8 - VCC

The only pin that will be available is the MISO pin. The only time it gets used is when you need to program the ATTiny85 itself. After that it can be used for whatever. And if you prefer sticking with a 1-wire driver, that means the CLOCK pin is also available.

Notice there is no crystal/resonator listed. That’s because I’ll be using the internal clock.

Moving on, the WS2801 has three output channels and the LPD8806 has six. However, the WS2801 is much slower than the LPD8806 … But then, thinking about space, it doesn’t make sense to use an external driver, so I’ll stick to the APA102. It just means sending out more data for the entire “string” inside the pod.

For the sensor there needs to be a 4-wire connector, VCC, GND, A, and B. For the LEDs, another 4-wire connector, VCC, GND, DATA, CLK. Then you need the ICSP port broken out so you can actually program the ATTiny85. A few discreet parts like capacitors and resistors and you’re done.

There’s still the issue of how to disable the local controller in favor of the master controller when it takes over and starts sending data down the line to everything. he one thing I like in the video is that the pods seem to systematically shut off, not all of them at the same time. I like that, it gives it some fluidity. But that’s not easily done unless you can address each pod individually and there just aren’t enough pins available on the ATTiny85 for that kind of communication.

So … we keep brainstorming. For now we have two bundles of wires for each pod:

  • a pair for VCC and GND
  • a group of five that gets daisy chained: DATA_IN + DATA_OUT, CLOCK_IN + CLOCK_OUT, and another to act as common GND.
42

Oh, something just came to mind. The ArduSat Payload Processor Module has 16 ATMega328p on board, and one “supervisor” processor. There’s a mechanism in place to reset each individual processor. This makes me wonder … if you take the I2C bus from the master, put a couple of I2C-to-GPIO expanders on it, you can then send a signal to each individual pod, since you can now address them through I2C. use a GPIO pin on the expander, connected to the MISO on the ATTiny85 to send a HIGH or LOW signal. Then, when the ATTiny85 senses this, it … does something, like shut off the LEDs.

What say you?

43

And another “puzzle” to solve (is anyone still reading? ) Referring back to the original Everbright video, at one point someone pushes what I would call a ‘reset’ button which clears the board completely. Awesome, following my previous comment of using I2C expanders, one could essentially send a HIGH/LOW signal to each individual node.

But let’s expand on a possible setup here: let’s say the display is on and has been sitting for a bit without anyone touching it. It would be nice for it to automatically reset and go into an ‘auto-run’ mode where it just displays ‘stuff’, like animations. Then, when someone walks up and spins one of the pods, it would instantly reset the whole board and go into ‘user control’ mode. And when the user is done playing, after an appropriate timeout, it goes back into auto mode.

This now tells me you would need some sort of two-way communication. If the master is displaying animations, it needs to somehow detect that a pod has changed. Since we only have one available pin left, and it is potentially being used to RECEIVE a signal from the master, we’d need a way to send something back to the master. Errrr, we’re out of pins.

Suggestions anyone?

44
  1. Use the one line for bidirectional communication. Somehow.
  2. Have each pixel time out independently after a few minutes.
  3. Measure the current draw of the whole thing and if it doesn’t change for 5 minutes, reset.
  4. One set of proximity sensors in front of the whole installation. If no one there for 5 minutes, reset.

Personally, I’d go for Option 2 or 4, and yes I’m still reading :slight_smile:

45

For #1 … yeah, trying to figure out how is easier said than done.
#2 is possible, however what would that timeout be in terms of the master? How would it know? it needs to someone how that all of them have timed out …
#3 and #4 … errrr … yeah no. :slight_smile: Not that they’re impossible, just adds more to the setup.

46

Here’s my wacky brainstorming idea. No idea if an arrangement like this is possible.

On the master MCU, one pin for TX and one for RX with diode(s).
Switch the pin on attiny85 to output when needed using port registers and have it send some sort of signal.
On master MCU have it regularly listen for in incoming signal each time around the loop to catch an incoming signal (but have the receiving pin only listen when not sending).

https://www.arduino.cc/en/Reference/PortManipulation

or…
maybe an upgrade to attiny44?! :stuck_out_tongue:

47

#1.1: flip to output and make an RF signal on the line sending pixel ID. Master has RF receiver that listens…

Overengineering FT…W?

48

Well, the pods don’t need to send IDs back to tell the master to shut up. Any one of them can do that, so an ID isn’t necessary.

So what I’m thinking is something like this. I have no idea if this will work but that’s what we’re here for, to brain storm.

Since I can’t think of any other way, I’m going to consider the usage of I2C-to-GPIO expanders on the master to communicate with umpteen pods. One wire to each pod.

When the unit is first turned on, the expander ports are all INPUTs (I believe this is a default state for most expanders anyway.) The master controller will go into a constant scanning loop.

The pods all have their pin set to INPUTs as well. On the master, during each loop it will scan all of the ports on all expanders, listening for a pod to squeak.

On the pods, every time one of them gets touched, it will flip its pin to OUTPUT and send a ‘shut up’ message to the master, and then switch back to INPUT again.

Each time the master receives one of those ‘shut up’ messages, it resets a timer. Eventually people will stop playing with the pods and the timer will reach 300 seconds. At that point the master will flip all the expander ports to OUTPUT and send a ‘master control’ signal back to each pod. When the pod receives this, they will reset and hand over control.

As soon as it’s done sending that signal, the master switches back to INPUT and scans all ports for a squeak again while also sending animation data down the line. When it received a ‘shut up’ squeak from a pod, it will send a reset down the line, reset the timer, and the individual pods now have control again …

Make sense?

49

Makes me want to draw a state diagram with dotty.

And I might do it differently, because I think (too much) in software, but I think you’re on a workable track.

The reason I want a state diagram is to map out the various failure and desynchronization possibilities, and make sure they all had a path to recovery.

But basically: yah!

50

Yeah, I hear you. Of course as soon as I re-read that I’m thinking … that one faithful moment when signals get crossed … now what. Oh! Big red reset button! :slight_smile:

But yes, a state diagram would make sense to figure out what each pod is doing. And when working with expanders, you already know what port any given pod is on. You have the expander’s address, and the actual port numbers, so in a sense that’s already a unique ID for each pod.

51

@Mark_Kriegsman Our vendor for Acrylite responded with ‘the price will make you fall over, do you still want a quote’? Now, I’ve known this woman for a few years and when she says something like that, she’s not joking. It means that a) Acrylite will not sell us a sample piece, and b) the full sheet will be in the thousands … Um, yeah no, not going to happen.

52

Fun enclosure test: I 3D printed all the pieces, including the bearing (so nice to be able to get STEP files for those) … put the whole thing together sans electronics and the front lens … only to realize that once it’s put together, there is no disassembling it. Unless you break it. Yep, that’s me … make something that can only be put together once. After that you’re screwed. :slight_smile:

Now to come up with a solution.

53

How is the everbright project going? Any updates?

54

Was just thinking about that the other day. I haven’t touched it since I got the laser cutter, which ironically was purchased so I can cut custom encoder wheels and the front covers. Instead I ended up doing a bunch of other projects with it. But it is being brought back to the table. I already have revisions to be made to the design … Now if I can only find more time.