On 12/29/2023 12:11 PM, Dan Purgert wrote:
> I know the multiplexing code will (generally) work thanks to a bit of

The issues you will (or have!) discover with muxing LEDs are:
- loss of intensity (vs static drive)
- visual artifacts (if you switch controls while current is flowing)
- costs of intensity control (faster refresh rates; higher losses)
- viewer induced artifacts (e.g., saccades)

[You might also want to consider Charlieplexing the displays to get
more mileage from your I/Os]

When I modeled the multiplexed vs. "lots of MCUs" approach, it was
the silly loading that intensity control placed on the processor
as you have to have the ability to control the duty cycle of the
individual lamps, finely.

I modeled 16 (equally spaced) levels using a display cycle decomposed
into 4 unequal periods. Lamps could be turned on/off at:
t=0
t=8
t=12
t=14
t=15(=0)

So, for each of the 4 periods in a display cycle:
0 8 12 14 15=0
0 OFF OFF OFF OFF OFF...
1 OFF OFF OFF ON OFF...
2 OFF OFF ON OFF OFF...
3 OFF OFF ON ON OFF...
4 OFF ON OFF OFF OFF...
5 OFF ON OFF ON OFF...
6 OFF ON ON OFF OFF...
7 OFF ON ON ON OFF...
8 ON OFF OFF OFF OFF...
9 ON OFF OFF ON OFF...
10 ON OFF ON OFF OFF...
11 ON OFF ON ON OFF...
12 ON ON OFF OFF OFF...
13 ON ON OFF ON OFF...
14 ON ON ON OFF OFF...
15 ON ON ON ON OFF...

Note that the shortest interval is that starting at t=14
and it is 15 times shorter than the full display period.
But, the other intervals are notably longer; in particular,
there is no need for 15X display rate just to get 15 different
duty cycles.

[Note that "OFF..." represents the start of the NEXT display
period so the state of the controls would be determined by how
they should NEXT appear]

*IF* the display has to be updated via software, then
reducing the rate has merit.

Likely, an ISR is used for that (which always smells bad, to me).

If, instead, you double-buffer the drives and use the same hardware
signal that generates the IRQ to transfer the holding registers'
contents into the output registers IN HARDWARE, then you have the
entire remaining interval to prepare the NEXT values to be
transferred (instead of having to rush to transfer THESE values).

[I experimented with rearranging the order of the "subintervals"
but tossed out the whole approach when I looked at the cost of
scaling it to thousands(!) of lamps]

[[You may also want to make the multiplex "nonsequential" so
you don't perceive "waves" of updates washing across the
screen. It's amazing what your eyes will perceive, despite
all the "theory".]]

It's worth carefully examining how you will be changing the
state of the controls as the display will likely want to be
forcibly blanked during this interval to minimize visual artifacts.
E.g., if you are shifting data into the display drivers, then the
outputs of those can cause unintended lamps to flicker, albeit
briefly.

And, if the shift-clock is software derived, then there is a
possibility that it may vary based on conditions in the
processor (e.g., if interrupted by another process/ISR).

Finally, variations in the period/dead-time will be
noticeable if they end up being periodic.

> protoboard, LEDs and resistors, but for all I know, I've oversized the
> snap-in (LED-Carrier) PCB's by 0.010" (~0.25mm), or likewise gotten the
> spacing wrong on these "testing carriers" (I spaced them at ~2.050" /
> 52mm; but maybe they need another 0.020" / ~0.5mm).
>
> That's kinda the downside of 3-d printing, the three samples I took the
> measurements off of were done a couple of months ago, and in the
> intervening time the printer's been re-adjusted / calibrated because I
> noticed it was starting to drift (circles were ... well, oval) . But
> was it drifting when those samples were printed ...? (I don't think so,
> but Murphy will see to it that the new "dimensionally accurate" game
> tiles are now perfectly accurate, meaning I run into problems).

Hmmm... I hadn't realized this was an issue with 3D printers.
I assumed any variation would be related to thermal issues
(variations) in the heater and material being printer.

> And then there's the problem that maybe I get it perfect for *my*
> printer, but someone else who likes the idea's printer is off (unless I
> become the production-house here, and ... ouch ;)).
>
>> - manufacturing/test (to start building fixtures and
>> developing a "process")
>
> This is where I'd imagine "mess with the model" would step in; since
> yes, having the printer do the work is loads easier. But first I want to
> make sure the idea is generally sound (as in "oh, yes, with a 2.5mm hole
> in the middle of the space, the holes don't take away from the look of
> the spaces, AND there's enough indicator-light to make the effect
> visible").

You may be able to modify the "plastic bits" to enhance the
appearance/fit of the lamps. Or, relocate them away from
their "theoretical" locations in the center of each square.
E.g., if a wall eats up half of a "grid square", moving the
lamp that occupies that square a bit farther from the perimeter
may have value.

(This would be a problem for tiles where there is NO wall...
"Why are the lamps in such weird locations?")

> May well be the case that the hole needs to be too big, and the whole
> thing is a nonstarter; which is what I NEED to figure out before I
> commit to anything more complex (expensive).

But, you should be able to do that just with "plastic pieces" and
lamps -- even driving them statically.

>> No, I don't buy "10,000" injection molded parts. But, I will
>> likely buy 1,000 (given that there are 288 devices in *a*
>> deployment).
>
> Sure, and when I've finished my proofs, THEN I can go order a ton of
> things / mess with the gcode/stl files (possibly ... there might be other
> challenges there).
>
> Suffice to say, I've only gotten essentially "minimum order qty" worth
> of the PCBs to play with / verify reality (and manufacturing tolerances)
> match my expectations, and have enough tiles to prove moving to
> "production" is viable (at least PCB-side).

I've taken the approach of increasing the number of each "type"
of design I need. E.g., I have a "CPU board" in each module.
And, a "power supply board". So, I can order 300 of each.

OTOH, I only have ~20 "camera I/Os", *one* "weather station" I/O,
etc. So, they get more costly. (The enclosures are the things
that eat my lunch, hence the desire to explore the enclosure
requirements for as many different modules as possible -- if I
can use one mold for N different modules, then I can increase
the quantity of those and reduce the number of different molds)

> Granted, I did order way more LEDs / resistors than are necessary for
> the proof; but when AREN'T you going to find a use for those :)
>
>>>> [Imagine the consequences if a user had to declare each tile
>>>> and its orientation -- possibly incorrectly. Would you add a
>>>> "validation" step whereby the game could repeat this information
>>>> back to the user to ensure it knows what is where? Or, would
>>>> the user discover it in the middle of gameplay when an effect
>>>> showed up in the wrong place, etc.?]
>>>
>>> Good news, with multiplexing, the tiles literally don't care what
>>> orientation they're in.
>>
>> But the "controller" needs to be aware of it as the "plastic
>> bits" imply an orientation to the viewer.
>
> Somewhat, but remember that ultimately the (to be designed) base is only
> providing a grid of 4x4 sockets (with only 180 degree symmetry at this
> immediate moment). In turn, each socket controls four spaces (i.e.
> SOCKET {0,0} contains SPACES {{0,0},{0,1},{1,0},{1,1}}; likewise socket
> {3,3} contains SPACES {{6,6},{6,7},{7,6},{7,7}).

I would explore options to eliminate the "base". I.e., stitch
the tiles together directly, with connectors on their edges.
(easier said than done -- exercise left to the reader)

I had one of these, as a kid:
<https://en.wikipedia.org/wiki/Raytheon_Lectron>
It differed from the radio shack "spring-and-wire" connected
kits of that era by allowing you to piece together a circuit
using contacts on the EDGES of the tiles.

> With the assumptions that
>
> (1) The LED isn't dead / soldered the wrong way about AND
> (2) I didn't mess up the rotational symmetry on the connector AND
> (3) any requisite jumpers between the various modules aren't crossed
>
> It is physically impossible to have the effect show up where it's not
> expected.
>
> The only "real" problem becomes if an effect crosses a boundary (e.g. a
> wall) ... but you have that anyway with paper templates, so it's not a
> problem I'm really going to worry about :)

On 2023-12-30, Don Y wrote:
> On 12/29/2023 12:11 PM, Dan Purgert wrote:
>> I know the multiplexing code will (generally) work thanks to a bit of
>
> The issues you will (or have!) discover with muxing LEDs are:
> - loss of intensity (vs static drive)
> - visual artifacts (if you switch controls while current is flowing)
> - costs of intensity control (faster refresh rates; higher losses)
> - viewer induced artifacts (e.g., saccades)
>
> [You might also want to consider Charlieplexing the displays to get
> more mileage from your I/Os]

Yep. Proving the general idea works is my main concern at this
juncture, downsides and all. As I mentioned, using the other LED
options (e.g. "smart" LEDs, or tens of MCUs, etc) wasn't initially
making sense for a "tile-able" design. But as I mentioned further down
yesterday, it all clicked :)

>> [...[
>> That's kinda the downside of 3-d printing, the three samples I took the
>> measurements off of were done a couple of months ago, and in the
>> intervening time the printer's been re-adjusted / calibrated because I
>> noticed it was starting to drift (circles were ... well, oval) . But
>> was it drifting when those samples were printed ...? (I don't think so,
>> but Murphy will see to it that the new "dimensionally accurate" game
>> tiles are now perfectly accurate, meaning I run into problems).
>
> Hmmm... I hadn't realized this was an issue with 3D printers.
> I assumed any variation would be related to thermal issues
> (variations) in the heater and material being printer.

There's that too -- but they're "just" driven by rubber timing belts (so
they do wear out, just like the belts in our cars) ... or the belt
slipped a tooth or whatever else causes the things to lose a bit of
dimensional accuracy over the course of 5 years ;)

>
>> And then there's the problem that maybe I get it perfect for *my*
>> printer, but someone else who likes the idea's printer is off (unless I
>> become the production-house here, and ... ouch ;)).
>>
>>> - manufacturing/test (to start building fixtures and
>>> developing a "process")
>>
>> This is where I'd imagine "mess with the model" would step in; since
>> yes, having the printer do the work is loads easier. But first I want to
>> make sure the idea is generally sound (as in "oh, yes, with a 2.5mm hole
>> in the middle of the space, the holes don't take away from the look of
>> the spaces, AND there's enough indicator-light to make the effect
>> visible").
>
> You may be able to modify the "plastic bits" to enhance the
> appearance/fit of the lamps. Or, relocate them away from
> their "theoretical" locations in the center of each square.
> E.g., if a wall eats up half of a "grid square", moving the
> lamp that occupies that square a bit farther from the perimeter
> may have value.

Yep, but then we've gotten into "special" PCBs -- which may well be
unavoidable, but for now it's acceptable loss. More LEDs would also
probably help, but there's only so small that we can go there.

>
> (This would be a problem for tiles where there is NO wall...
> "Why are the lamps in such weird locations?")
>
>> May well be the case that the hole needs to be too big, and the whole
>> thing is a nonstarter; which is what I NEED to figure out before I
>> commit to anything more complex (expensive).
>
> But, you should be able to do that just with "plastic pieces" and
> lamps -- even driving them statically.

Yes, which is why I ran with this multiplex-able design -- it still
allows for static driving of the LED --> just hook up 5 volts to the
anode and pick a cathode to illuminate.

>>>> [...]
>>>> Good news, with multiplexing, the tiles literally don't care what
>>>> orientation they're in.
>>>
>>> But the "controller" needs to be aware of it as the "plastic
>>> bits" imply an orientation to the viewer.
>>
>> Somewhat, but remember that ultimately the (to be designed) base is only
>> providing a grid of 4x4 sockets (with only 180 degree symmetry at this
>> immediate moment). In turn, each socket controls four spaces (i.e.
>> SOCKET {0,0} contains SPACES {{0,0},{0,1},{1,0},{1,1}}; likewise socket
>> {3,3} contains SPACES {{6,6},{6,7},{7,6},{7,7}).
>
> I would explore options to eliminate the "base". I.e., stitch
> the tiles together directly, with connectors on their edges.
> (easier said than done -- exercise left to the reader)

Yeah, that's the problem, there aren't any good edge-contact options
that wouldn't need a few dozen iterations of "does this stick out far
enough to allow connectivity; but not TOO far that the tile spacing is
all wonky?"

And then you REALLY run into problems of "where is 0,0" and "what's my
rotation" and "where's the end of a row".

>
> I had one of these, as a kid:
> <https://en.wikipedia.org/wiki/Raytheon_Lectron>
> It differed from the radio shack "spring-and-wire" connected
> kits of that era by allowing you to piece together a circuit
> using contacts on the EDGES of the tiles.
>
>> With the assumptions that
>>
>> (1) The LED isn't dead / soldered the wrong way about AND
>> (2) I didn't mess up the rotational symmetry on the connector AND
>> (3) any requisite jumpers between the various modules aren't crossed
>>
>> It is physically impossible to have the effect show up where it's not
>> expected.
>>
>> The only "real" problem becomes if an effect crosses a boundary (e.g. a
>> wall) ... but you have that anyway with paper templates, so it's not a
>> problem I'm really going to worry about :)
>
> So, in the "paper and pencil" version, when an effect is "invoked",
> do you take a predefined template (for THAT effect) and hold it
> over the gameboard and "mark" the players that have been impacted?

Yep. There are only like a dozen different shapes (and half of them are
the difference between a "cone" being laid out in line with the grid, or
45 degrees to the grid. They ("cones") are defined as a 90 degree arc
from their point of origin (which is the grid intersection between 4
spaces), so either look like:

0 0 0 0 0 0 0 0 0 0 0
0 0 1 1 0 0 0 1 1 1 0
0 0 1 1 0 0 OR 0 1 1 0 0
0 1 1 1 1 0 0 1 0 0 0
0 0 0 0 0 0 0 0 0 0 0

>> [...]
>> Four channels would be easy enough, I think:
>>
>> ch1 = tiles 0-31 ({0,0} to {3,7}
>> ch2 = tiles 32-63 ({0,8} to {3,15})
>> ch3 = tiles 64-91 ({4,0} to {7,7})
>> ch4 = tiles 92-127 ({4,8} to {7,15})
>>
>> Each channel is further subdivided into "A" and "B" grids ("A" being
>> equivalent of {0,0} to {3,3} in that channel). Since we're using four
>> discrete serial busses, each CHANNEL will only ever think it is a
>> solitary 4x4 (or 4x8) grouping of tiles.
>>
>> [a] ((ADDR & 0x60) >> 2) goes out to an address decoder that is in
>> turn tied to the ENABLE pin of the line driver.
>> [b] ((ADDR & 0x1F) is the address byte that's kicked out on the wire.
>>
>> "A" and "B" just need to be differentiated by a DIP switch that either
>> leaves the 5th bit alone (addresses 16-31), or drags it to ground
>> (addresses 0-15). Addresses "0" or "16" mark the upper-left tile; "15"
>> or "31" the lower-right.
>
> Do as much configuration *in* the "plugging" of the modules/tiles.
> E.g., ground a wire in the socket that the tile mates with, etc.

Yep, that's essentially the plan -- i.e. a tile's address is defined by
where it's plugged in. Not 100% sure which variant approach (as far as
pullups / downs / etc.) will work out "best" in terms of me not pulling
my hair out :)

>
>> Although the full size would absolutely dominate a normal dining room table
>> (remember, each coordinate there represents a 2" by 2" tile piece, so as
>> laid out up there, you're talking a 32x32" playing surface ... bit big
>> for a standard 36" wide table ;) -- but one could use channels 1,3 (or
>> just the first halves of 2,4) to have something that fits).
>
> You're going to find the update rate limits you. Note that you can
> evaluate this without having all of the tiles present -- just set
> the update rate to 32X and only drive *one* tile for one update period.
> If not bright enough, then having 32X more of them isn't going to be
> any better.

On 12/30/2023 7:23 AM, Dan Purgert wrote:
>>>>> Good news, with multiplexing, the tiles literally don't care what
>>>>> orientation they're in.
>>>>
>>>> But the "controller" needs to be aware of it as the "plastic
>>>> bits" imply an orientation to the viewer.
>>>
>>> Somewhat, but remember that ultimately the (to be designed) base is only
>>> providing a grid of 4x4 sockets (with only 180 degree symmetry at this
>>> immediate moment). In turn, each socket controls four spaces (i.e.
>>> SOCKET {0,0} contains SPACES {{0,0},{0,1},{1,0},{1,1}}; likewise socket
>>> {3,3} contains SPACES {{6,6},{6,7},{7,6},{7,7}).
>>
>> I would explore options to eliminate the "base". I.e., stitch
>> the tiles together directly, with connectors on their edges.
>> (easier said than done -- exercise left to the reader)
>
> Yeah, that's the problem, there aren't any good edge-contact options
> that wouldn't need a few dozen iterations of "does this stick out far
> enough to allow connectivity; but not TOO far that the tile spacing is
> all wonky?"

The MCU approach has an advantage in that you only need to pass data
down one axis; having to connect to the tiles "above" and "below"
means you'd have to disassemble the entire grid each time you
wanted to change anything *in* it.

My application inherently avoids this as:
- patch panels don't "change"
- expansion can always occur "at THE end"

> And then you REALLY run into problems of "where is 0,0" and "what's my
> rotation" and "where's the end of a row".

The MCUs can deduce this by noticing "is there anything off to my left"?
And, reporting this to a controller who can sort out who's at the top, etc.

>> So, in the "paper and pencil" version, when an effect is "invoked",
>> do you take a predefined template (for THAT effect) and hold it
>> over the gameboard and "mark" the players that have been impacted?
>
> Yep. There are only like a dozen different shapes (and half of them are
> the difference between a "cone" being laid out in line with the grid, or
> 45 degrees to the grid. They ("cones") are defined as a 90 degree arc
> from their point of origin (which is the grid intersection between 4
> spaces), so either look like:
>
> 0 0 0 0 0 0 0 0 0 0 0
> 0 0 1 1 0 0 0 1 1 1 0
> 0 0 1 1 0 0 OR 0 1 1 0 0
> 0 1 1 1 1 0 0 1 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0

If the "pretty lights" aren't just cosmetic, then, presumably,
the locations of players relative to the lights is significant?
I.e., "if a red light appears UNDER you, then you have been
"effect-ed" [sic]?

My point is, do you need to make the lamps UNDER players
visible? Should players be made of clear acrylic so they can
"glow red" (yellow, blue, etc.) when "effect-ed"?

Or, do the players lift their "tokens" up to see if
there is a lamp that is lit UNDER them?

[The graph paper overlay avoids this issue]

>> Do as much configuration *in* the "plugging" of the modules/tiles.
>> E.g., ground a wire in the socket that the tile mates with, etc.
>
> Yep, that's essentially the plan -- i.e. a tile's address is defined by
> where it's plugged in. Not 100% sure which variant approach (as far as
> pullups / downs / etc.) will work out "best" in terms of me not pulling
> my hair out :)

I suspect players would be annoyed (discouraged!) if they had
to "fix" the game midplay. So, anything the hardware can do
*for* them is likely a win for the UX.

>>> Although the full size would absolutely dominate a normal dining room table
>>> (remember, each coordinate there represents a 2" by 2" tile piece, so as
>>> laid out up there, you're talking a 32x32" playing surface ... bit big
>>> for a standard 36" wide table ;) -- but one could use channels 1,3 (or
>>> just the first halves of 2,4) to have something that fits).
>>
>> You're going to find the update rate limits you. Note that you can
>> evaluate this without having all of the tiles present -- just set
>> the update rate to 32X and only drive *one* tile for one update period.
>> If not bright enough, then having 32X more of them isn't going to be
>> any better.
>
> Eh? By the time I got to this idea here; I was already seeing the way
> out of using multiplexing --- IF AND ONLY IF

You need to refresh that entire "array" ~100 times a second to give the
illusion of a static display. So, if (for example) you do a 32-way multiplex
(32 "columns" of N lamps), then each column has to be refreshed at ~100 Hz
so your "controller" is running at 3200 hz. Each column is "enabled"
for 1/3 millisecond (3200Hz) out of every 10 milliseconds (100Hz).

If you mock up a bit of code that turns on an LED for 1/3ms and then
turns it off for 9+2/3 ms (10-1/3), you'll get an idea of how DIM
the lamps will be. I.e., you don't need to set up 32 lamps and
illuminate each one for 1/3ms to see the consequences.

The MCU approach fixes (makes invariable) the number of "ways" that
it needs to multiplex the lamps. E.g., I use an 8-way mux -- I
enable one of 8 lamps (each with 3 LEDs) at a time. I do this
at 1KHz so each lamp is lit for 1ms out of every 8ms.

Regardless of how many lamps are present! (because the next group of
8 lamps will have its own MCU running ALONGSIDE this one).

[I synchronize the MCUs so I can synchronize the displays from one
group of 8 to the next; it's annoying to see one set of lamps blinking
ON... OFF... ON... and the next set blinking OFF... ON... OFF...
or some other phasing]

> (a) multiplexing "16 tiles" (8x8 spaces) looks okay, or if not
> (b) driving the LED hard on looks okay
>
> If neither of those work out, then the idea's entirely a nonstarter from
> the getgo.

You can look for "high efficiency" LEDs to try to get more light
out of less duty cycle/drive.

You can also overdrive them, a bit, knowing that they will only be
"on" for 1/N-th of the frame (but, then you can't let your
multiplexing/refresh "stop" as it can toast a column if you've
overdriven them too hard.

These sorts of problems are delightful in their APPARENT
simplicity. Once you start looking at the details, you discover
they aren't really all that simple!

On 2023-12-30, Don Y wrote:
> On 12/30/2023 7:23 AM, Dan Purgert wrote:
>>>>>> Good news, with multiplexing, the tiles literally don't care what
>>>>>> orientation they're in.
>>>>>
>>>>> But the "controller" needs to be aware of it as the "plastic
>>>>> bits" imply an orientation to the viewer.
>>>>
>>>> Somewhat, but remember that ultimately the (to be designed) base is only
>>>> providing a grid of 4x4 sockets (with only 180 degree symmetry at this
>>>> immediate moment). In turn, each socket controls four spaces (i.e.
>>>> SOCKET {0,0} contains SPACES {{0,0},{0,1},{1,0},{1,1}}; likewise socket
>>>> {3,3} contains SPACES {{6,6},{6,7},{7,6},{7,7}).
>>>
>>> I would explore options to eliminate the "base". I.e., stitch
>>> the tiles together directly, with connectors on their edges.
>>> (easier said than done -- exercise left to the reader)
>>
>> Yeah, that's the problem, there aren't any good edge-contact options
>> that wouldn't need a few dozen iterations of "does this stick out far
>> enough to allow connectivity; but not TOO far that the tile spacing is
>> all wonky?"
>
> The MCU approach has an advantage in that you only need to pass data
> down one axis; having to connect to the tiles "above" and "below"
> means you'd have to disassemble the entire grid each time you
> wanted to change anything *in* it.
>
> My application inherently avoids this as:
> - patch panels don't "change"
> - expansion can always occur "at THE end"

I mean the baseplate plan operates in that manner today -- the XY axis
is inherent to the base, and has nothing to do with the tiles
themselves. So popping out any one tile doesn't affect the others.

>
>> And then you REALLY run into problems of "where is 0,0" and "what's my
>> rotation" and "where's the end of a row".
>
> The MCUs can deduce this by noticing "is there anything off to my left"?
> And, reporting this to a controller who can sort out who's at the top, etc.
>
>>> So, in the "paper and pencil" version, when an effect is "invoked",
>>> do you take a predefined template (for THAT effect) and hold it
>>> over the gameboard and "mark" the players that have been impacted?
>>
>> Yep. There are only like a dozen different shapes (and half of them are
>> the difference between a "cone" being laid out in line with the grid, or
>> 45 degrees to the grid. They ("cones") are defined as a 90 degree arc
>> from their point of origin (which is the grid intersection between 4
>> spaces), so either look like:
>>
>> 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 1 1 0 0 0 1 1 1 0
>> 0 0 1 1 0 0 OR 0 1 1 0 0
>> 0 1 1 1 1 0 0 1 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0
>
> If the "pretty lights" aren't just cosmetic, then, presumably,
> the locations of players relative to the lights is significant?
> I.e., "if a red light appears UNDER you, then you have been
> "effect-ed" [sic]?

Yep.

>
> My point is, do you need to make the lamps UNDER players
> visible? Should players be made of clear acrylic so they can
> "glow red" (yellow, blue, etc.) when "effect-ed"?

That'd be fun too, and would potentially help visibility-wise.

>
> Or, do the players lift their "tokens" up to see if
> there is a lamp that is lit UNDER them?

That's the easy aproach.

>
> [The graph paper overlay avoids this issue]

But adds the issue of knocking them over :)

ULTIMATELY, the main concern is the outline of the effect (everything
"inside" that outline gets hit with it) -- and the nice thing with the
LED things here is that you can just move it +/- 1 square to check
without lifting a figure.
>
>>> Do as much configuration *in* the "plugging" of the modules/tiles.
>>> E.g., ground a wire in the socket that the tile mates with, etc.
>>
>> Yep, that's essentially the plan -- i.e. a tile's address is defined by
>> where it's plugged in. Not 100% sure which variant approach (as far as
>> pullups / downs / etc.) will work out "best" in terms of me not pulling
>> my hair out :)
>
> I suspect players would be annoyed (discouraged!) if they had
> to "fix" the game midplay. So, anything the hardware can do
> *for* them is likely a win for the UX.

Happens all the time -- Remember, the "standard" approach is a cardboard
(or vinyl) mat with erasable markers creating the rooms, etc. Or even
just "Theatre of the Mind".

These plastic tile-sets would more be "set-piece" things -- you plop it
down on the table for a "climactic scene" (e.g. The battle between the
Nazgûl and the hobbits / Aragorn on Weathertop); and when the scene is
over, it goes away.

>
>>>> Although the full size would absolutely dominate a normal dining room table
>>>> (remember, each coordinate there represents a 2" by 2" tile piece, so as
>>>> laid out up there, you're talking a 32x32" playing surface ... bit big
>>>> for a standard 36" wide table ;) -- but one could use channels 1,3 (or
>>>> just the first halves of 2,4) to have something that fits).
>>>
>>> You're going to find the update rate limits you. Note that you can
>>> evaluate this without having all of the tiles present -- just set
>>> the update rate to 32X and only drive *one* tile for one update period.
>>> If not bright enough, then having 32X more of them isn't going to be
>>> any better.
>>
>> Eh? By the time I got to this idea here; I was already seeing the way
>> out of using multiplexing --- IF AND ONLY IF
>
> You need to refresh that entire "array" ~100 times a second to give the
> illusion of a static display. So, if (for example) you do a 32-way multiplex
> (32 "columns" of N lamps), then each column has to be refreshed at ~100 Hz
> so your "controller" is running at 3200 hz. Each column is "enabled"
> for 1/3 millisecond (3200Hz) out of every 10 milliseconds (100Hz).
>
> If you mock up a bit of code that turns on an LED for 1/3ms and then
> turns it off for 9+2/3 ms (10-1/3), you'll get an idea of how DIM
> the lamps will be. I.e., you don't need to set up 32 lamps and
> illuminate each one for 1/3ms to see the consequences.

What does this help prove? Multiplexing everything from a single
controller is only ever going to be for this proof-of-concept (64
LEDs).

I'm quite confident the concept will pan out, and warrant moving to a
more complex design. There are already enough avenues for mistakes that
minimizing the potential problems in the circuitry made sense for a
"first real world test".

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 12/31/2023 7:51 AM, Dan Purgert wrote:
>> [The graph paper overlay avoids this issue]
>
> But adds the issue of knocking them over :)

But, at 1"x1", it doesn't seem like it would be that tedious to re-place
them? Or, do they tend to *fill* a single cell?

> ULTIMATELY, the main concern is the outline of the effect (everything
> "inside" that outline gets hit with it) -- and the nice thing with the
> LED things here is that you can just move it +/- 1 square to check
> without lifting a figure.

>>>> Do as much configuration *in* the "plugging" of the modules/tiles.
>>>> E.g., ground a wire in the socket that the tile mates with, etc.
>>>
>>> Yep, that's essentially the plan -- i.e. a tile's address is defined by
>>> where it's plugged in. Not 100% sure which variant approach (as far as
>>> pullups / downs / etc.) will work out "best" in terms of me not pulling
>>> my hair out :)
>>
>> I suspect players would be annoyed (discouraged!) if they had
>> to "fix" the game midplay. So, anything the hardware can do
>> *for* them is likely a win for the UX.
>
> Happens all the time -- Remember, the "standard" approach is a cardboard
> (or vinyl) mat with erasable markers creating the rooms, etc. Or even
> just "Theatre of the Mind".
>
> These plastic tile-sets would more be "set-piece" things -- you plop it
> down on the table for a "climactic scene" (e.g. The battle between the
> Nazgûl and the hobbits / Aragorn on Weathertop); and when the scene is
> over, it goes away.

So, you don't play the *whole* game on a large "board"?

>>>>> Although the full size would absolutely dominate a normal dining room table
>>>>> (remember, each coordinate there represents a 2" by 2" tile piece, so as
>>>>> laid out up there, you're talking a 32x32" playing surface ... bit big
>>>>> for a standard 36" wide table ;) -- but one could use channels 1,3 (or
>>>>> just the first halves of 2,4) to have something that fits).
>>>>
>>>> You're going to find the update rate limits you. Note that you can
>>>> evaluate this without having all of the tiles present -- just set
>>>> the update rate to 32X and only drive *one* tile for one update period.
>>>> If not bright enough, then having 32X more of them isn't going to be
>>>> any better.
>>>
>>> Eh? By the time I got to this idea here; I was already seeing the way
>>> out of using multiplexing --- IF AND ONLY IF
>>
>> You need to refresh that entire "array" ~100 times a second to give the
>> illusion of a static display. So, if (for example) you do a 32-way multiplex
>> (32 "columns" of N lamps), then each column has to be refreshed at ~100 Hz
>> so your "controller" is running at 3200 hz. Each column is "enabled"
>> for 1/3 millisecond (3200Hz) out of every 10 milliseconds (100Hz).
>>
>> If you mock up a bit of code that turns on an LED for 1/3ms and then
>> turns it off for 9+2/3 ms (10-1/3), you'll get an idea of how DIM
>> the lamps will be. I.e., you don't need to set up 32 lamps and
>> illuminate each one for 1/3ms to see the consequences.
>
> What does this help prove? Multiplexing everything from a single
> controller is only ever going to be for this proof-of-concept (64
> LEDs).

It:
- shows you what your maximum brightness (of each emitter) *could* be
- shows you what secondary colors you'll end up with (tune ballasts)
- gives you a feel for how much work the controller has to do (to
update the displays "on time")
- shows you how *few* intensity levels you will have (because anything
"less" than maximum will mean a shorter display cycle)

> I'm quite confident the concept will pan out, and warrant moving to a
> more complex design. There are already enough avenues for mistakes that
> minimizing the potential problems in the circuitry made sense for a
> "first real world test".

Note that if you opt for an MCU approach, then you'd (likely) still
be multiplexing *within* a tile so the same (above) issues still
merit empirical data.

On 12/31/2023 12:11 PM, Don Y wrote:
> On 12/31/2023 7:51 AM, Dan Purgert wrote:
>>> [The graph paper overlay avoids this issue]
>>
>> But adds the issue of knocking them over :)
>
> But, at 1"x1", it doesn't seem like it would be that tedious to re-place
> them?  Or, do they tend to *fill* a single cell?

I.e., if one topples, is it likely to topple/displace others
"nearby"? Like trying to reset a domino in a field of tiles...

I assume players can remember EXACTLY where their pieces were
so recreating their positions isn't anything more than an
inconvenience (assuming you trust each other). And, there are
likely only a "few" pieces on the board (unlike a chessboard).

On 2023-12-31, Don Y wrote:
> On 12/31/2023 7:51 AM, Dan Purgert wrote:
>>> [The graph paper overlay avoids this issue]
>>
>> But adds the issue of knocking them over :)
>
> But, at 1"x1", it doesn't seem like it would be that tedious to re-place
> them? Or, do they tend to *fill* a single cell?

Pieces have various sizes (22mm diameter base is the standard "Medium
Creature" though). But they're still easy enough to tip over.

>>> [...]
>>> I suspect players would be annoyed (discouraged!) if they had
>>> to "fix" the game midplay. So, anything the hardware can do
>>> *for* them is likely a win for the UX.
>>
>> Happens all the time -- Remember, the "standard" approach is a cardboard
>> (or vinyl) mat with erasable markers creating the rooms, etc. Or even
>> just "Theatre of the Mind".
>>
>> These plastic tile-sets would more be "set-piece" things -- you plop it
>> down on the table for a "climactic scene" (e.g. The battle between the
>> Nazgûl and the hobbits / Aragorn on Weathertop); and when the scene is
>> over, it goes away.
>
> So, you don't play the *whole* game on a large "board"?

No, not all at once anyway. The board gets re-drawn pretty constantly
throughout a 2 or 3 hour game session (or not at all, because "...
beware one of us always tells the truth and the other always lies..."
starts the players on a 3 hour discussion of "so how do we figure out
the liar?" )

>>> [...]
>>> If you mock up a bit of code that turns on an LED for 1/3ms and then
>>> turns it off for 9+2/3 ms (10-1/3), you'll get an idea of how DIM
>>> the lamps will be. I.e., you don't need to set up 32 lamps and
>>> illuminate each one for 1/3ms to see the consequences.
>>
>> What does this help prove? Multiplexing everything from a single
>> controller is only ever going to be for this proof-of-concept (64
>> LEDs).
>
> It:
> - shows you what your maximum brightness (of each emitter) *could* be
> [...]

Except I don't care what it "might" look like at 32x32 spaces, since the
project is never going to illuminate 32x32 spaces from a single MCU.
That's why I'm not understanding why you're saying to test as if I
was...

>> I'm quite confident the concept will pan out, and warrant moving to a
>> more complex design. There are already enough avenues for mistakes that
>> minimizing the potential problems in the circuitry made sense for a
>> "first real world test".
>
> Note that if you opt for an MCU approach, then you'd (likely) still
> be multiplexing *within* a tile so the same (above) issues still
> merit empirical data.

Yeah, but multiplexing / charlieplexing four LEDs (well, 12 because RGB,
but details) is going to be as bright as (if not brighter than) the 4x4
tile proof-of-concept that I'm going to build as soon as my stuff
arrives from the PCB house.

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 2023-12-31, Don Y wrote:
> On 12/31/2023 12:11 PM, Don Y wrote:
>> On 12/31/2023 7:51 AM, Dan Purgert wrote:
>>>> [The graph paper overlay avoids this issue]
>>>
>>> But adds the issue of knocking them over :)
>>
>> But, at 1"x1", it doesn't seem like it would be that tedious to re-place
>> them?  Or, do they tend to *fill* a single cell?
>
> I.e., if one topples, is it likely to topple/displace others
> "nearby"? Like trying to reset a domino in a field of tiles...

Can, if the pieces are close enough together (or usually what happens is
someone tries to catch it, and hits other things)

>
> I assume players can remember EXACTLY where their pieces were
> so recreating their positions isn't anything more than an
> inconvenience (assuming you trust each other). And, there are
> likely only a "few" pieces on the board (unlike a chessboard).

It's not too many, maybe a dozen or two at the absolute most (least that
I've seen -- it's nowhere near as insane as those military style ones
that are setup on pingpong tables)

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 12/31/2023 4:35 PM, Dan Purgert wrote:
>>>> I suspect players would be annoyed (discouraged!) if they had
>>>> to "fix" the game midplay. So, anything the hardware can do
>>>> *for* them is likely a win for the UX.
>>>
>>> Happens all the time -- Remember, the "standard" approach is a cardboard
>>> (or vinyl) mat with erasable markers creating the rooms, etc. Or even
>>> just "Theatre of the Mind".
>>>
>>> These plastic tile-sets would more be "set-piece" things -- you plop it
>>> down on the table for a "climactic scene" (e.g. The battle between the
>>> Nazgûl and the hobbits / Aragorn on Weathertop); and when the scene is
>>> over, it goes away.
>>
>> So, you don't play the *whole* game on a large "board"?
>
> No, not all at once anyway. The board gets re-drawn pretty constantly
> throughout a 2 or 3 hour game session (or not at all, because "...
> beware one of us always tells the truth and the other always lies..."
> starts the players on a 3 hour discussion of "so how do we figure out
> the liar?" )

So, you all "move together"? What's to stop me from heading NORTH
while you head SOUTH?

[I guess I just don't understand all the "rules"...]

>>>> If you mock up a bit of code that turns on an LED for 1/3ms and then
>>>> turns it off for 9+2/3 ms (10-1/3), you'll get an idea of how DIM
>>>> the lamps will be. I.e., you don't need to set up 32 lamps and
>>>> illuminate each one for 1/3ms to see the consequences.
>>>
>>> What does this help prove? Multiplexing everything from a single
>>> controller is only ever going to be for this proof-of-concept (64
>>> LEDs).
>>
>> It:
>> - shows you what your maximum brightness (of each emitter) *could* be
>> [...]
>
> Except I don't care what it "might" look like at 32x32 spaces, since the
> project is never going to illuminate 32x32 spaces from a single MCU.
> That's why I'm not understanding why you're saying to test as if I
> was...

But you will likely want to know what "half intensity" looks like
(even driven by an MCU).

*I* can't tell you what "half as bright" means -- and how it correlates
with drive current. And, I can't tell you what 100% Red + 50% Blue
looks like or how it compares to 50% Red + 100% Blue. (for me,
actual hue and intensity are important and not easily understood
from duty cycles or drive currents)

On 2024-01-01, Don Y wrote:
> On 12/31/2023 4:35 PM, Dan Purgert wrote:
>>>>> I suspect players would be annoyed (discouraged!) if they had
>>>>> to "fix" the game midplay. So, anything the hardware can do
>>>>> *for* them is likely a win for the UX.
>>>>
>>>> Happens all the time -- Remember, the "standard" approach is a cardboard
>>>> (or vinyl) mat with erasable markers creating the rooms, etc. Or even
>>>> just "Theatre of the Mind".
>>>>
>>>> These plastic tile-sets would more be "set-piece" things -- you plop it
>>>> down on the table for a "climactic scene" (e.g. The battle between the
>>>> Nazgûl and the hobbits / Aragorn on Weathertop); and when the scene is
>>>> over, it goes away.
>>>
>>> So, you don't play the *whole* game on a large "board"?
>>
>> No, not all at once anyway. The board gets re-drawn pretty constantly
>> throughout a 2 or 3 hour game session (or not at all, because "...
>> beware one of us always tells the truth and the other always lies..."
>> starts the players on a 3 hour discussion of "so how do we figure out
>> the liar?" )
>
> So, you all "move together"? What's to stop me from heading NORTH
> while you head SOUTH?
>
> [I guess I just don't understand all the "rules"...]

Nothing. :)

(although you going off on your own merry way is a really good way to
get in trouble)

If you're familiar with the Lord of the Rings movies, think the scenes
in Fellowship where Gimli keeps going on about going through Moria ;)

>
>>>>> If you mock up a bit of code that turns on an LED for 1/3ms and then
>>>>> turns it off for 9+2/3 ms (10-1/3), you'll get an idea of how DIM
>>>>> the lamps will be. I.e., you don't need to set up 32 lamps and
>>>>> illuminate each one for 1/3ms to see the consequences.
>>>>
>>>> What does this help prove? Multiplexing everything from a single
>>>> controller is only ever going to be for this proof-of-concept (64
>>>> LEDs).
>>>
>>> It:
>>> - shows you what your maximum brightness (of each emitter) *could* be
>>> [...]
>>
>> Except I don't care what it "might" look like at 32x32 spaces, since the
>> project is never going to illuminate 32x32 spaces from a single MCU.
>> That's why I'm not understanding why you're saying to test as if I
>> was...
>
> But you will likely want to know what "half intensity" looks like
> (even driven by an MCU).

Sure, but I can easily do that on this grid of 64 tiles, without
pretending to be looking at an 8x8 corner of a 32x32 grid.

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 1/1/2024 10:07 AM, Dan Purgert wrote:
> On 2024-01-01, Don Y wrote:
>> On 12/31/2023 4:35 PM, Dan Purgert wrote:
>>>>>> I suspect players would be annoyed (discouraged!) if they had
>>>>>> to "fix" the game midplay. So, anything the hardware can do
>>>>>> *for* them is likely a win for the UX.
>>>>>
>>>>> Happens all the time -- Remember, the "standard" approach is a cardboard
>>>>> (or vinyl) mat with erasable markers creating the rooms, etc. Or even
>>>>> just "Theatre of the Mind".
>>>>>
>>>>> These plastic tile-sets would more be "set-piece" things -- you plop it
>>>>> down on the table for a "climactic scene" (e.g. The battle between the
>>>>> Nazgûl and the hobbits / Aragorn on Weathertop); and when the scene is
>>>>> over, it goes away.
>>>>
>>>> So, you don't play the *whole* game on a large "board"?
>>>
>>> No, not all at once anyway. The board gets re-drawn pretty constantly
>>> throughout a 2 or 3 hour game session (or not at all, because "...
>>> beware one of us always tells the truth and the other always lies..."
>>> starts the players on a 3 hour discussion of "so how do we figure out
>>> the liar?" )
>>
>> So, you all "move together"? What's to stop me from heading NORTH
>> while you head SOUTH?
>>
>> [I guess I just don't understand all the "rules"...]
>
> Nothing. :)
>
> (although you going off on your own merry way is a really good way to
> get in trouble)

So, you have "companions" instead of "competitors"?

> If you're familiar with the Lord of the Rings movies, think the scenes
> in Fellowship where Gimli keeps going on about going through Moria ;)
>
>>>>>> If you mock up a bit of code that turns on an LED for 1/3ms and then
>>>>>> turns it off for 9+2/3 ms (10-1/3), you'll get an idea of how DIM
>>>>>> the lamps will be. I.e., you don't need to set up 32 lamps and
>>>>>> illuminate each one for 1/3ms to see the consequences.
>>>>>
>>>>> What does this help prove? Multiplexing everything from a single
>>>>> controller is only ever going to be for this proof-of-concept (64
>>>>> LEDs).
>>>>
>>>> It:
>>>> - shows you what your maximum brightness (of each emitter) *could* be
>>>> [...]
>>>
>>> Except I don't care what it "might" look like at 32x32 spaces, since the
>>> project is never going to illuminate 32x32 spaces from a single MCU.
>>> That's why I'm not understanding why you're saying to test as if I
>>> was...
>>
>> But you will likely want to know what "half intensity" looks like
>> (even driven by an MCU).
>
> Sure, but I can easily do that on this grid of 64 tiles, without
> pretending to be looking at an 8x8 corner of a 32x32 grid.

I've been trying to save you the trouble/expense of having boards
built if they weren't going to be used "in the product".

I wired an RGB LED to a pin on a microcontroller *socket*,
plugged an ICE into the socket and then twiddled the code
to see what various refresh rates, duty cycles, "color
mixes", etc. LOOKED like to get an idea for how far I could
push the multiplexing (N-way) and duty cycle (intensity levels)
before committing to a hardware design that would "bake"
those limits in place.

I could never have told you what those limits would be
just from datasheets and calculations.

[I also have a strict power budget as everything is PoE-powered
and I don't want to have to add a wall wart/local power supply
just for something as banal as a patch panel!]

On 2024-01-01, Don Y wrote:
> On 1/1/2024 10:07 AM, Dan Purgert wrote:
>> On 2024-01-01, Don Y wrote:
>>> On 12/31/2023 4:35 PM, Dan Purgert wrote:
>>>>>>> I suspect players would be annoyed (discouraged!) if they had
>>>>>>> to "fix" the game midplay. So, anything the hardware can do
>>>>>>> *for* them is likely a win for the UX.
>>>>>>
>>>>>> Happens all the time -- Remember, the "standard" approach is a cardboard
>>>>>> (or vinyl) mat with erasable markers creating the rooms, etc. Or even
>>>>>> just "Theatre of the Mind".
>>>>>>
>>>>>> These plastic tile-sets would more be "set-piece" things -- you plop it
>>>>>> down on the table for a "climactic scene" (e.g. The battle between the
>>>>>> Nazgûl and the hobbits / Aragorn on Weathertop); and when the scene is
>>>>>> over, it goes away.
>>>>>
>>>>> So, you don't play the *whole* game on a large "board"?
>>>>
>>>> No, not all at once anyway. The board gets re-drawn pretty constantly
>>>> throughout a 2 or 3 hour game session (or not at all, because "...
>>>> beware one of us always tells the truth and the other always lies..."
>>>> starts the players on a 3 hour discussion of "so how do we figure out
>>>> the liar?" )
>>>
>>> So, you all "move together"? What's to stop me from heading NORTH
>>> while you head SOUTH?
>>>
>>> [I guess I just don't understand all the "rules"...]
>>
>> Nothing. :)
>>
>> (although you going off on your own merry way is a really good way to
>> get in trouble)
>
> So, you have "companions" instead of "competitors"?

Yes, there is one "player" who acts as the narrator / rules adjudicator,
but otherwise all other players are working as a (mostly) cohesive unit
to complete the "story".

>>> [...]
>>> But you will likely want to know what "half intensity" looks like
>>> (even driven by an MCU).
>>
>> Sure, but I can easily do that on this grid of 64 tiles, without
>> pretending to be looking at an 8x8 corner of a 32x32 grid.
>
> I've been trying to save you the trouble/expense of having boards
> built if they weren't going to be used "in the product".

And I've done LEDs on a protoboard before (and changed how bright they
get, etc). Only real downside there is that they're no-name ebay
options (well, on top of being thru-hole, and thus too big for the
application anyway).

I did, of course, test the specific Cree LEDs I settled on with a bit of
home-etched PCB to run different LEDs underneath a tile (albeit these
breakouts were only 1" squares to fit under a single space)

This original lot of tiles (etc.) is proving that

(a) I got my PCB dimensions right to snap into the plastic tile
AND
(b) I got the features located on the PCB properly to accommodate
a central ~2mm hole AND
(c) The chosen LEDs are sufficiently bright on a 4x4 grid (or
mocked-up 8x8 or 12x12 grid) when shining through that 2mm hole

Or well, it will when they arrive hopefully today :)

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 1/2/2024 4:12 AM, Dan Purgert wrote:
> On 2024-01-01, Don Y wrote:
>> On 1/1/2024 10:07 AM, Dan Purgert wrote:
>>> On 2024-01-01, Don Y wrote:
>>>> On 12/31/2023 4:35 PM, Dan Purgert wrote:
>>>>>>>> I suspect players would be annoyed (discouraged!) if they had
>>>>>>>> to "fix" the game midplay. So, anything the hardware can do
>>>>>>>> *for* them is likely a win for the UX.
>>>>>>>
>>>>>>> Happens all the time -- Remember, the "standard" approach is a cardboard
>>>>>>> (or vinyl) mat with erasable markers creating the rooms, etc. Or even
>>>>>>> just "Theatre of the Mind".
>>>>>>>
>>>>>>> These plastic tile-sets would more be "set-piece" things -- you plop it
>>>>>>> down on the table for a "climactic scene" (e.g. The battle between the
>>>>>>> Nazgûl and the hobbits / Aragorn on Weathertop); and when the scene is
>>>>>>> over, it goes away.
>>>>>>
>>>>>> So, you don't play the *whole* game on a large "board"?
>>>>>
>>>>> No, not all at once anyway. The board gets re-drawn pretty constantly
>>>>> throughout a 2 or 3 hour game session (or not at all, because "...
>>>>> beware one of us always tells the truth and the other always lies..."
>>>>> starts the players on a 3 hour discussion of "so how do we figure out
>>>>> the liar?" )
>>>>
>>>> So, you all "move together"? What's to stop me from heading NORTH
>>>> while you head SOUTH?
>>>>
>>>> [I guess I just don't understand all the "rules"...]
>>>
>>> Nothing. :)
>>>
>>> (although you going off on your own merry way is a really good way to
>>> get in trouble)
>>
>> So, you have "companions" instead of "competitors"?
>
> Yes, there is one "player" who acts as the narrator / rules adjudicator,
> but otherwise all other players are working as a (mostly) cohesive unit
> to complete the "story".

So, that differs from most "games" -- which tend to be competitive.
I.e., there is no "value" to wandering off by yourself (unless
part of a coordinated strategy to quickly explore the entire game board)

>>>> But you will likely want to know what "half intensity" looks like
>>>> (even driven by an MCU).
>>>
>>> Sure, but I can easily do that on this grid of 64 tiles, without
>>> pretending to be looking at an 8x8 corner of a 32x32 grid.
>>
>> I've been trying to save you the trouble/expense of having boards
>> built if they weren't going to be used "in the product".
>
> And I've done LEDs on a protoboard before (and changed how bright they
> get, etc). Only real downside there is that they're no-name ebay
> options (well, on top of being thru-hole, and thus too big for the
> application anyway).
>
> I did, of course, test the specific Cree LEDs I settled on with a bit of
> home-etched PCB to run different LEDs underneath a tile (albeit these
> breakouts were only 1" squares to fit under a single space)

I have a bunch of 1W RGB emitters to test. Laziness keeping me from
making a jig for them (so I don't melt them)

> This original lot of tiles (etc.) is proving that
>
> (a) I got my PCB dimensions right to snap into the plastic tile
> AND
> (b) I got the features located on the PCB properly to accommodate
> a central ~2mm hole AND
> (c) The chosen LEDs are sufficiently bright on a 4x4 grid (or
> mocked-up 8x8 or 12x12 grid) when shining through that 2mm hole
>
> Or well, it will when they arrive hopefully today :)
>
>
>

On 2024-01-03, Don Y wrote:
> On 1/2/2024 4:12 AM, Dan Purgert wrote:
>> On 2024-01-01, Don Y wrote:
>>>
>>> So, you have "companions" instead of "competitors"?
>>
>> Yes, there is one "player" who acts as the narrator / rules adjudicator,
>> but otherwise all other players are working as a (mostly) cohesive unit
>> to complete the "story".
>
> So, that differs from most "games" -- which tend to be competitive.
> I.e., there is no "value" to wandering off by yourself (unless
> part of a coordinated strategy to quickly explore the entire game board)

Yep. :)

>> [...]
>> I did, of course, test the specific Cree LEDs I settled on with a bit of
>> home-etched PCB to run different LEDs underneath a tile (albeit these
>> breakouts were only 1" squares to fit under a single space)
>
> I have a bunch of 1W RGB emitters to test. Laziness keeping me from
> making a jig for them (so I don't melt them)

Chunk of steel (or aluminum) will work perfectly well there. Bit of
thermal paste to stick 'em to the test plate and you're good to go.

>
>> This original lot of tiles (etc.) is proving that
>>
>> (a) I got my PCB dimensions right to snap into the plastic tile
>> AND
>> (b) I got the features located on the PCB properly to accommodate
>> a central ~2mm hole AND
>> (c) The chosen LEDs are sufficiently bright on a 4x4 grid (or
>> mocked-up 8x8 or 12x12 grid) when shining through that 2mm hole
>>
>> Or well, it will when they arrive hopefully today :)

Update there -> 0.010" too big in all dimensions, so it's a little too
tight of an interference fit (nothing a bit of sandpaper won't fix on
this test batch...

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 1/4/2024 3:53 AM, Dan Purgert wrote:
>>> I did, of course, test the specific Cree LEDs I settled on with a bit of
>>> home-etched PCB to run different LEDs underneath a tile (albeit these
>>> breakouts were only 1" squares to fit under a single space)
>>
>> I have a bunch of 1W RGB emitters to test. Laziness keeping me from
>> making a jig for them (so I don't melt them)
>
> Chunk of steel (or aluminum) will work perfectly well there. Bit of
> thermal paste to stick 'em to the test plate and you're good to go.

The problem isn;t thermal management but, rather, trying to
evaluate the "emissions" of multiple lamps together. Driving
them at varying intensities makes it something that has no
"closed form" solution... instead, empirically evaluate which
is the best (least bad) compromise.

>>> This original lot of tiles (etc.) is proving that
>>>
>>> (a) I got my PCB dimensions right to snap into the plastic tile
>>> AND
>>> (b) I got the features located on the PCB properly to accommodate
>>> a central ~2mm hole AND
>>> (c) The chosen LEDs are sufficiently bright on a 4x4 grid (or
>>> mocked-up 8x8 or 12x12 grid) when shining through that 2mm hole
>>>
>>> Or well, it will when they arrive hopefully today :)
>
> Update there -> 0.010" too big in all dimensions, so it's a little too
> tight of an interference fit (nothing a bit of sandpaper won't fix on
> this test batch...

Removing material is always easier than *adding* it!

On 2024-01-05, Don Y wrote:
> On 1/4/2024 3:53 AM, Dan Purgert wrote:
>>>> [...]
>>>> Or well, it will when they arrive hopefully today :)
>>
>> Update there -> 0.010" too big in all dimensions, so it's a little too
>> tight of an interference fit (nothing a bit of sandpaper won't fix on
>> this test batch...
>
> Removing material is always easier than *adding* it!

Heh, the 3d printer disagrees :)

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860