Helix and the FPP

[gmbartlett]

This thread will be used to discuss the possibility of using the FPP to act as the Helix Network Controller in a Helix Network. The MP3 players used on the Helix Main Board have been discontinued by SparkFun and suitable replacements haven't been found. It is possible that a FPP could be used as the Helix Network Controller and current Helix users could still use their Helix equipment and save their investment. It would also provide a transition plan off of the Helix platform and onto more current equipment.

 

[gmbartlett]

I agree, it sounds like connecting to daughterboards would be too complex and resource intensive.6

I am slowly converting parts of FPP to C++, and one of the things in the back of my mind has been to make the FPP MultiSync code based on a base class and a "FPP MultiSync" class similar to how I am doing in other parts of the code such as the channel output and media output areas.

If there is interest, and you have anything describing the sync protocol, I could keep helix in mind when I get to converting this part of FPP and could try to make FPP control helix nodes.

The attached document is the Helix Configuration Control document that I started several years ago. It isn't complete but it describes the message format and several of the messages that the Helix uses. For the FPP the only messages that you would need to be concerned with are:

1. Send Beacon Message: Needs to be sent once a second whenever the player isn't playing a sequence (This is basically a keep alive message for the XBee radios)
2. Start Sequence Message: Needs to be sent at the beginning of a sequence. (The current Helix firmware sends the message twice since the XBees haven't been shown to be very reliable)
3. Next Event Message: Needs to be sent every event period and requires a 16 bit number that corresponds to the current event number. (Again this is sent twice for every event)
4. End Sequence Message: Needs to be sent at the end of the sequence to tell the Helix Nodes to go back to idle mode.

Let me know if you have any questions about the document or the basic protocol.

 

[PRD]

I would like to thank Greg Bartlett and CaptainMurdock for discussing a way forward from the Helix system to a Pi/fpp control that might extend usage of the current Helix boards until a transition to a RGB pixel display can be made. If it is possible for fpp to talk to the Helix system I would be interested. At the very least it would allow me to budget for the future and get to pixel display where I now want to be. A pixel based system opens up a wonderful vista of ideas and I can't wait to get there. Again, thanks!

 

[blantrip]

I would like to thank Greg Bartlett and CaptainMurdock for discussing a way forward from the Helix system to a Pi/fpp control that might extend usage of the current Helix boards until a transition to a RGB pixel display can be made. If it is possible for fpp to talk to the Helix system I would be interested. At the very least it would allow me to budget for the future and get to pixel display where I now want to be. A pixel based system opens up a wonderful vista of ideas and I can't wait to get there. Again, thanks!

I second that!

I'd also like to thank Greg for his original system that in my opinion was ahead of the times. Thanks to him also for all of his support along the way. I'm sure I'm not the only one that had many questions (some probably stupid and basic) that he spent many hours answering by email and even on the phone.

I'd love to see Helix live on and commend him for sharing his design and code. It's people like him and CaptainMurdock among many others that make this community thrive.

 

[CaptainMurdoch]

3. Next Event Message: Needs to be sent every event period and requires a 16 bit number that corresponds to the current event number. (Again this is sent twice for every event)

Great, this looks simple enough and corresponds pretty much with what FPP MultiSync does already.

I think the only question I have currently is about the event period. Is a period a frame of data or an amount of time like 1 second? Sorry if it is in the doc and I missed it, I browsed the PDF from my phone. FPP currently uses frame number sync packets sending a sync packet every 16 but I can extend this to allow sending one every frame if that is what helix uses.

 

[gmbartlett]

Great, this looks simple enough and corresponds pretty much with what FPP MultiSync does already.

I think the only question I have currently is about the event period. Is a period a frame of data or an amount of time like 1 second? Sorry if it is in the doc and I missed it, I browsed the PDF from my phone. FPP currently uses frame number sync packets sending a sync packet every 16 but I can extend this to allow sending one every frame if that is what helix uses.

The Helix was designed around Vixen v2.x. In that version the sequence was divided into fixed, equal time periods called events. The time period was user adjustable but most people used a 50 ms or 100 ms period though some used 25 ms. The way the Helix Network Supervisor works is it takes the Vixen 2.x saved file and parses the event data out and saves it to a file that is loaded on a microSD card. When it is displaying a sequence it reads an event's worth of data off of the file and displays it on the channel banks. So as the Helix Network Controller (what the FPP would be replacing) is playing the music and controlling it's channels, it also sends the Next Event message, every event period, to all of the Helix Nodes so they can display their next event's data also.

I'm not sure how that corresponds with how Vixen v3 works but I would hope it does something similar.

 

[CaptainMurdoch]

Ok, sync once per frame.

It also sounds like your helix file format is similar to the fseq format where it stores channel data an event/frame at a time so it can just read in a block of data with all channels for that instance in time. Do you have your file format documented somewhere? I would probably make sense to try to get it added to xLights file format converter which would also allow FPP to convert from .fseq to your sequence file format since FPP includes a copy of the file format converter from xLights.

 

[gmbartlett]

Ok, sync once per frame.

It also sounds like your helix file format is similar to the fseq format where it stores channel data an event/frame at a time so it can just read in a block of data with all channels for that instance in time. Do you have your file format documented somewhere? I would probably make sense to try to get it added to xLights file format converter which would also allow FPP to convert from .fseq to your sequence file format since FPP includes a copy of the file format converter from xLights.

The Helix sequence file format is very simple. It is a binary file with a four byte header and the data for each event/frame period. The first two bytes (word) are the number of events/frames in the sequence with the high byte stored first (big endian). The second word is the event period in milliseconds (again big endian). Then the byte data for each event/frame stored lowest channel to highest channel. As mentioned before the file name must be in the 8.3 file format and by Helix convention the extension should be .SEQ.

I'm not familiar with xLights but I'm sure it has some way to map the sequence channels to the hardware. The Helix is very flexible in how it is configured. Each Helix Node has four channel banks that can be individually configured. If they are configured to drive Helix Daughter boards then they can each have 1-32 channels. Each channel bank can also drive Renards or DMX controllers. If it is Renards then it can be 1-286 channels. If it is DMX then it can be 1-512 channels. xLights will need to account for these various possibilities when it generates the sequence file (the data for each event/frame for Channel Bank 1 first, then Channel Bank 2, 3, then 4).

There is one other type of file that each Helix Node will need. It is the Configuration file that tells each Node how each of its Channel Banks should be configured, whether it should use the XBee or RS485, and the XBee configuration commands. I normally create all of the necessary files using the Helix Network Supervisor application. If the plan is to have xLights create the files then we need to determine if it can create the config files also. I've attached an example of a Helix Configuration file. Normally it has the file name CONFIG.HLX but I converted it to a .TXT so it can be uploaded. It is a simple text file with the configurations starting in the first column then at least one space followed by an comment that explains the purpose of the configuration. I did this so the Helix users could understand the purpose of each line and manually change them if they needed.

 

[CaptainMurdoch]

It sounds like that might be more suited for a FPP plugin since each node needs its own sequence file. XLights knows about controllers but doesn't have any mechanism for splitting files up. We have tossed around the idea of having a splitter in FPP to allow putting a partial sequence file on a FPP remote but haven't coded one up. If we make a fseq splitter then that could be used for helix files as well probably since it would need to know about the remotes whether they are FPP or Helix.

 

[Rjlangley]

As I still have Helix hardware and working on transitioning to newer hardware, I’m curious if anything (a plugin for instance) came of this?
I’m working on a solution to use some of my existing standard AC lights as I transition/Upgrade over the next two years. But, I’m also trying to put more of my money into pixels (lights and controllers).
If something exists, which can help out, I’d appreciate it.
Otherwise, I’ll continue on with the transition.
By the way, I’m also transitioning from Vixen to xLights. In case that info helps.


Sent from my iPhone using Tapatalk

 

[Rjlangley]

By the way, if possible, it would be great if a FPP in slave mode could be used to control one of the Helix main boards. Personally, the value in it would be for the 32 channel SSRs. Since they use the Helix format.
I already have a solution for all of the SSRNeon-G2-LEDs I have in my show. I’m going to use Pi’s with FPP as slaves and use the GPIO pins to control each channel.


Sent from my iPhone using Tapatalk

 

[CaptainMurdoch]

No additional work was ever done on this. If there is some control protocol info I could take a look at it but I couldn't guarantee any compatibility this year given other priorities.

 

[Rjlangley]

No additional work was ever done on this. If there is some control protocol info I could take a look at it but I couldn't guarantee any compatibility this year given other priorities.

Okay, Thank you for the reply. That’s all I needed to know. I understand.


Sent from my iPhone using Tapatalk