master/slave raspberries

[Paul Dunn]

Just for the topic we've already started discussing in email and to start moving it here in response to Sean:

quick overview:

if you set --broadcast=on all that the master does is setup a socket and then in the section where the pins are actually turned on/off/pwm it builds a string
channel=brightness  
then that data is sent out on the socket, port 8888 as dgram broadcast.
that's it on that end.

then on the slave end, if you set --slavemode=on
it ignores everything else (freq calcs, fft etc) and just opens the network and starts reading from port 8888
so it gets channel=brightness
split on the "=" so i = channel and brightness of course = brightness then just hand that off to the same section of code that says
if hc.is_pin_pwm(i):
and it blinks the lights ;-)

so in one direction that portion would be easy if the channel number read from the network is > gpiolen, ignore it.

[chrisausey]

So correct me if I am wrong but as I understand the code. The master broadcasts the pin and the brightness (per say), the slaves listen for the broadcast and act accordingly.  As I see it the slave is acting on the pin correct?  

If I am not correct in my assumption of how this works correct me.  Instead of broadcasting the pin maybe setup a network_channel_mapping setting? and have that broadcast instead of pin. My thinking with this is networking could be used for more than just mirroring a show, it could actually be used to extend the show / GPIO.  Her is an example that may clarify my thinking.

MASTER PI:

# the master only needs to know about its GPIO

gpio_pins = 0,1,2,3,4,5,6,7

# network channels lists all channels defined in network_channel_mapping across all devices. if the device is a slave it doesn’t need anything defined

networked_channels = 1,2,3,4,5,6,7,100,101,102,103,104,200,201,202,203,204

# custom channel mapping tells the device what channel it needs to act upon, all others it ignores, this should map 1:1 with gpio pins for that device

network_channel_mapping = 1,2,3,4,5,6,7,8

SLAVE PI 1:

gpio_pins = 0,1,2,3,4

# network channels lists all channels defined in network_channel_mapping across all devices. if the device is a slave it doesn’t need anything defined

networked_channels = slave

# custom channel mapping tells the device what channel it needs to act upon, all others it ignores, this should map 1:1 with gpio pins for that device

network_channel_mapping = 100,101,102,103,104

SLAVE PI 2:

gpio_pins = 0,1,2,3,4

# network channels lists all channels defined in network_channel_mapping across all devices. if the device is a slave it doesn’t need anything defined

networked_channels = slave

# custom channel mapping tells the device what channel it needs to act upon, all others it ignores, this should map 1:1 with gpio pins for that device

network_channel_mapping = 200,201,202,203,204

** With these settings the master would base the amount of channels to use based on the total channels defined in the networked_channels list and not the amount of channels defined in the gpio_pins.  When the stream starts it would broadcast the channel to act upon based on the network_channels_setting along with its brightness (per say).  the program would have logic see the incoming channel, check to see if it is in the network_channel_mapping and map the channel 1:1 if so, otherwise ignore it.

This is a really quick idea on my part and it could def be flawed !!!! I don’t know exactly how the streaming work so Im just putting this out there, please feel free to shoot it down, comment, etc

[chris usey]

If networking is not enabled, then the program would go against gpio_pins instead of the networked_channels .

With all that said, this would be an advanced setting !!

--
You received this message because you are subscribed to the Google Groups "LightshowPi Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lightshowpi-d...@googlegroups.com.
To post to this group, send email to lightsh...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lightshowpi-dev/3f52ae68-09bc-4347-a9b8-bf61b2dd5682%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Dunn]

hmmmm.. so let's say combined total for all raspberries, you have 48 channels. we could have it split the channels apart based on something like 16 on the master 8 on slave1 and 2 and 16 on slave3. Then do custom mapping for frequency range and which channels on which raspberry.
I like it!
might be a really advanced setting and for super users (or something) as it might be easiest to just go with a port expander with 48 channels directly on a single pi ;-)

[chris usey]

Exactly, It would be quite advanced, and by default if a user chooses to enable it, you can simply mirror the channels on each device by default if they are not comfortable doing all the mappings.  And you are right, it would be much easier to just setup some port expanders, but in my case I have a large front yard and I have to run some very long extensions to reach all my lights. It would be a cleaner setup and much less expensive for me to have 2 pi’s serving different parts of the yard instead of running so many extension cables.  I also have a neighbor that wants to get into the hobby, it might be cool to have both of our houses work together !

--
You received this message because you are subscribed to the Google Groups "LightshowPi Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lightshowpi-d...@googlegroups.com.
To post to this group, send email to lightsh...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lightshowpi-dev/1dba8614-ecc3-4a6f-8eaf-18ab50fbf0a4%40googlegroups.com.

[chris usey]

Im also thinking a little further than just the Pi.  With the right code on an arduino it could become part of the show !

On Nov 6, 2014, at 4:08 PM, Paul Dunn <dunn...@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "LightshowPi Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lightshowpi-d...@googlegroups.com.
To post to this group, send email to lightsh...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lightshowpi-dev/1dba8614-ecc3-4a6f-8eaf-18ab50fbf0a4%40googlegroups.com.

[Todd Giles]

I really like this idea Chris!

[chris usey]

Thanks ! 

I have been looking at Paul’s code and it doesn’t look like it will take much more code to implement, the structure is mostly there ! I Really like the code Paul ! 

On Nov 6, 2014, at 4:35 PM, Todd Giles <todd....@gmail.com> wrote:

I really like this idea Chris!

--
You received this message because you are subscribed to the Google Groups "LightshowPi Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lightshowpi-d...@googlegroups.com.
To post to this group, send email to lightsh...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lightshowpi-dev/9ecf49d5-96b5-4a08-948e-f7437f905df0%40googlegroups.com.

[Paul Dunn]

don't sweat it Chris. it's actually quite simple code. but it is my own protocol (I just taught my students about protocols a few weeks ago)..
LSP?  LightShow Protocol ;-)

anyway, sync'ing with your neighbor's house would be really cool. and with just a couple more lines of code, you could have the master pi also stream the audio. So both raspberries would "play" the music and both would blink lights in sync (any network latencies notwithstanding.)

I think for the current code, I will basically implement somewhat as-is so that it can stay within Todd's original plan of keeping things simple and functional out-of-the-box.
I will test what I have and move forward with it. still need to add logging and to have streaming start when the lightshow is launched with start_music_and_lights (either script or cron job)

[Paul Dunn]

LSSP   LightShow Streaming Protocol

I'll have to submit to IEEE ;-)

[Todd Giles]

We'll know it's official once wikipedia is updated ;)

On Thu Nov 06 2014 at 5:02:00 PM Paul Dunn <dunn...@gmail.com> wrote:

LSSP   LightShow Streaming Protocol

I'll have to submit to IEEE ;-)

--
http://www.lightshowpi.com/
---

You received this message because you are subscribed to the Google Groups "LightshowPi Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lightshowpi-d...@googlegroups.com.
To post to this group, send email to lightsh...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lightshowpi-dev/f50b802e-7171-4189-93c6-96989a83714b%40googlegroups.com.

[Paul Dunn]

been thinking about this a little and trying to figure out a bit on how to make it work.
Would you think that you would still use 8 FFT bins?
Just trying to think where the mapping would be better, on the master or on the slave.  In the stream I am sending, you could see it as channels (and it is) or you could just look at it as the frequency bins from the FFT calcs. If a show were running with say 32 channels of lights, I can't imagine you would want to have 32 frequency ranges (or maybe you would, but those ranges would be really small)
I would think you would leave the frequencies at 8 and then do channel maps. So the master could stay as-is, just sending out data for each of the FFT bins, then use your idea to do custom mapping on each PI depending on how many channels and what you want to see.

at the same time, I have not had enough coffee yet for how late I stayed up last night, so I might not be seeing this clearly.

[chris usey]

Hmmmm,

I have not had my coffee either, but I think I understand where you are coming from.  Im going to have to step back a bit in order not to fully unleash my ideas on how I think channels should be managed in the future, so we can concentrate on this issue, because that would be a conversation in and of itself.  In the interest of the community and the varied uses they may find for this project, would we want to limit their frequency to channel choices? Personally I like 8 channels and think the show looks great with only 8 defined and mirror those channels, but I can def see uses for defining 32 channels, especially if one is creating something like a mega tree and driving it with a single device.  

With that said I do like your idea of streaming the frequency, that may simplify the number of lists that have to be managed.  IE if a user decides they want 30 channels, and to divide the frequencies between 3 devices, then they would only need a way to say that device one responds to the first 10 frequencies,  device two may respond to a specific 5 frequencies and for the hell of it device 3 can respond to all 30 frequencies if it wishes.  Its very flexible and that may be able to be achieved with lists that we already have instead of creating all new lists.  That may also simplify the soon to be famous LSPP (Light show pi protocol) :)…

I like where this is going, I am excited about the idea of streaming (Something) and having distributed devices that we can tell, “ Hey when you see this come across you need to do this “…

- Chris

-- 
http://www.lightshowpi.com/
--- 
You received this message because you are subscribed to the Google Groups "LightshowPi Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lightshowpi-d...@googlegroups.com.
To post to this group, send email to lightsh...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lightshowpi-dev/fed73a52-5819-4b52-bfc0-b13e80953a71%40googlegroups.com.

[Paul Dunn]

Exactly, and that's where it gets complicated. I also agree on the 8 frequency bins, that gives a good amount of "blink".
Part of the confusion, I think, comes from  calling everything a channel, when it isn't necessarily so. We can have 8 discreet frequency bins but spread them out across any number of physical channels.

I need to go do some SAS deployments so will put this stuff on hold and give it some time to kind of soak into my brain.. maybe

[chris usey]

Ill do the same,  To clarify my comments earlier I agree that 8 channels produces a nice effect, but I am not sure we want to limit our users to that.  I think we should allow them to specify any number they want, sort of how it works now. I offer any opposing views to this as its just my opinion.

--
http://www.lightshowpi.com/
---
You received this message because you are subscribed to the Google Groups "LightshowPi Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lightshowpi-d...@googlegroups.com.
To post to this group, send email to lightsh...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lightshowpi-dev/58116d16-0750-406b-9808-15a3cd941112%40googlegroups.com.

[Paul Dunn]

Right. I think we're on the same page on this, I'll poke around a bit as far as setup. The original FFT bins are based on GPIOLen. but can have an override.   just need to think of ways to make it relatively easy.
I have a feeling I know where my weekend is going to be spent

[chris usey]

not sure how familiar you are with how the frequencies are distributed in relation to pins and custom channel mapping. If you are ignore me :) .. Otherwise this may help you out. if custom channel mapping is defined, the frequencies are only distributed to the max channel defined. So if i have 8 pins but the max channel defined in custom channel mapping is 4, then the program will only distribute the frequencies across 4 channels. If custom channel mapping is not defined then GPIOLen is used to specify how many channels to distribute across.


EX1 of how it works now.
In this scenario the program will evenly distribute the frequencies across 8 channels. If custom channel mapping is not defined it will map channels to frequency bins 1:1. I specified the custom_channel_mapping here but it just essentially maps 1:1. the next example explains how that works a little better.

channel 1= frequency bin 1
channel 2= frequency bin 2
channel 3= frequency bin 3
channel 4= frequency bin 4
channel 5= frequency bin 5
channel 6= frequency bin 6
channel 7= frequency bin 7
channel 8= frequency bin 8

SETTINGS:
gpio_pins = 0,1,2,3,4,5,6,7

custom_channel_mapping = 1,2,3,4,5,6,7,8 ( or if not defined just maps 1:1 with channels )

Ex2 of how it woks now:
In this scenario with the following settings we have 8 pins defined, and in custom channel mappings the max channel defined is 4, even though we have 8 total channels mapped to the pins. The program will only create 4 frequency Bins (per say) because the max channel defined is 4. So those 4 frequencies will be mapped to with custom_channel_mapping

channel 1= frequency bin 1
channel 2= frequency bin 2
channel 3= frequency bin 3
channel 4= frequency bin 4
channel 5= frequency bin 4
channel 6= frequency bin 3
channel 7= frequency bin 2
channel 8= frequency bin 1

[chris usey]

I had a big example I wrote out earlier but I scratched it as it may have been too confusing.  But taking into account the way custom channel mapping works, that principle may be able to be used on the networking side to determine the total channels to distribute frequencies across. if thats not defined then just use pins defined.

To view this discussion on the web visit https://groups.google.com/d/msgid/lightshowpi-dev/03ead87b-f466-44cc-92f9-183c70d36b56%40googlegroups.com.

[Paul]

Chris:

thanks. I had only ever used the default 1:1 and never changed anything from there and also let the code just divide the frequency range by the number of GPIO pins.

To view this discussion on the web visit https://groups.google.com/d/msgid/lightshowpi-dev/373B32C5-E50E-465B-97C5-246390E6DCF9%40gmail.com.