The Future of the Helix 2013

G

gmbartlett

New member
In the past I've developed the Helix pretty much on my own. Most of the features/capabilities I added were suggested by one or two users or were something I wanted specifically. Now that there is a larger Helix user base I would like to get more users involved with the development. Currently the Helix does almost everything that I want it to do. However, I've had several emails recently requesting changes. I would like to bring those requests to the forum and eventually have the Helix users prioritize the development. There are some resource constraints (both time and money) that will probably preclude developing all of the requests and some may be too costly to do it all. I will provide my estimate of the level of resources required for each request. When the requests start to level off, or in about two weeks, I'll post a consolidated list that we all can vote on. From there I'll try my best to get the top requests implemented this year.

So please post any requested updates to this thread.
 
My Resources Legend

Time:
+: Low Time Requirement
++: Med Time Requirement
+++: High Time Requirement
++++: Very High Time Requirement

Cost:
-: No Cost Requirement
$: Low Cost Requirement
$$: Med Cost Requirement
$$$: High Cost Requirement
$$$$: Very High Cost Requirement

This is the list of "Must Do's", i.e. I plan/have to do these this year no matter what

Helix MP3 Player (Time: ++) (Cost: $)
Helix Main Board Update (Time: ++) (Cost: $$)
Helix LEDTriks-C (Time: +) (Cost: -)

This is the list of proposed upgrades for this year (in no particular order)

Helix sACN Node (Time: ++++) (Cost: $$$$)
Helix Network Supervisor Troubleshooting Capability (Time: +) (Cost: -)
HLS Support (Time: ?) (Cost: -)
Vixen V3 Support (Time: ?) (Cost: -)

My original plan was to vote on which of these upgrades I would work on for this year but since the list is fairly short and the RGB/HLS/Vixen V3 requirements are sort of all tied together, I will attempt to accomplish all of them this year. The biggest unknowns for me are the time constraints for HLS and Vixen V3. The ideal solution would have the Helix Network Supervisor support the native output of these two sequencers. An intermediate solution would be to transform the outputs of these sequencers into the Vixen V2 format. So if anyone has details/the ability to assist with this transformation that would help out a lot.
 
Last edited:
I'll start off with a couple of things I will be doing this year due to logistical reasons.

I plan to create my own MP3 player so the Helix isn't at the mercy of SparkFun. I've already designed the circuit and acquired the parts. I need to prototype the circuit and test it out. From there I will order the initial batch of PCBs and give it a final test. This new board will also require an update to the Helix firmware. So the estimated resources cost is:

Time ++ (medium effort)
Cost $ (low cost)

Another thing I have to do this year is make a small modification to the Helix Main Board. The microSD card socket I use is no longer available. I have enough on hand for 25 more boards. After that I will need to acquire more stock of a new socket that has a different pad layout. This will force me to update the Main Board. This is the only major change I plan to make to the board. There will be a couple of smaller changes (correcting some references on the silk screen and moving the EEPROM a little further away from the Propeller chip) but no new hardware capabilities or features. The estimated resources cost is:

Time ++ (medium effort, PCB design is minor but the building and testing of the new board take time)
Cost $$ (medium cost, new boards are expensive to create and I will have to build a test version)

The final thing I want to do this year for sure is add an LEDTriks driver (technically a Triks-C driver). This is something I should have done a long time ago. The estimated resources cost is:

Time + (low, most of the R&D has been done but still need to integrate)
Cost - (none, no monetary costs associated with this development)
 
I had planned to create a Helix Network Node type board that would support sACN (E1.31) so the Helix could drive E68x (and similar) smart pixel boards. However, after some initial research into this I'm not sure it would be economically feasible. My initial plan was to have a single Ethernet port and be able to drive up to four E68x boards. But from what I understand the E68x boards use 6 DMX universes, with plans to support 8 in the future, each with its own multicast UDP address. This requires 6 (to 8) dedicated sockets be established. Since the Wiznet Ethernet modules only support 8 simultaneous sockets this would mean that the Helix board would either have one Ethernet module and be able to support only a single E68x board or would have four Ethernet modules and support four E68x. The first option would have an approximate cost of $90-100. The second option would have an approximate cost of $175-200. When I thought I could drive four E68x boards via Option 1 I was satisfied with the cost. However, I think it would be too expensive for a single E68x board. Option 2 is cheaper per E68x board but still fairly expensive.

My new option is to create a Helix Network Node type board that would directly drive the smart pixel strings. This board would only be able to operate within a Helix Network controlled by a Helix Network Controller. The number of initial types of strings supported probably won't be as many as the E68x series. I will need help identifying the most popular versions of the stings and with coding the communication protocols if this is something that we decide to pursue. The estimated resources cost is:

Time ++++ (very large effort, it would be a new design from the ground up and I have little knowledge of smart pixel strings)
Cost $$$$ (very large cost, I don't have any strings, power supplies or any other test boards)
 
Hi Greg,
Let me know if there is anything you need help with at all. Between my Father (45 yrs Electronics Engineer) and myself (15 yrs Software devleopment) i'm sure we'd be able to help out with a few things.

Also i have ordered some inteligent pixel string for this years display, but am happy to send some of them over if you need some for testing to keep the costs side down a bit.

Keep up the good work.

Ryan
 
Relating to E1.31, Vixen or LOR doesn't care or know what type of pixels you have, it's handled by the E68x.
Why would the Helix need to deal with pixel type if it's going to run the E68x?

Brian
 
Skunberg said:
Relating to E1.31, Vixen or LOR doesn't care or know what type of pixels you have, it's handled by the E68x.
Why would the Helix need to deal with pixel type if it's going to run the E68x?

Brian
Click to expand...

I think he is referring to the second paragraph in post #4 - "My new option is to create a Helix Network Node type board that would directly drive the smart pixel strings. This board would only be able to operate within a Helix Network controlled by a Helix Network Controller."
 
I believe making some kind of daughter board would be the way to go..Make the Helix modular is the easiest way to make this into the stand alone system that does everything.If using another board as a network node is the solution the cost of such a board is not that huge as compared to changing systems.I believe this is heading in the right direction for Helix users.1 thing I am unsure of is simply making a Helix plug in for the triks.Not sure if I understand this exactly but is this idea to remove the triks c board and use the Helix or is it to use the triks c with the Helix plug in >> If it is the first ( Meaning to take out the triks c and use another board that interfaces with the Helix better then go for it)if it is not this approach then I don't see the point as this was already working...With the sd cards and their respective slots for them...Wouldn't it be better to use a compact flash type card for speed as well as how they are held in place...A compact flash card holds onto the holder better and I have not heard of the issues that have been presented with them..Those issues being the micro sd cards going buggy on occasion..By buggy I mean not registering by the Helix ( like what happened to me once) or having corrupt data when your computer can read it fine and having to reformat the sd card which holds your show back if you had the case like me where you had one show ready to go but had 2 or more almost finished do to modifications that had to be done cause of other issues ( I had programmed too many channels that I never used as I ran out of extension cords)..So I had to scale it back as a result..In doing so I used 2 cards that were working perfectly...I had to email Greg with an issue and this was also a known issue to him..So maybe a new card might rid us of this issue in the future...
 
I would like to see a way of stopping and starting a show, and playing an individual sequence. Also it would be great to have a test channel function like Vixen. I use test channel function extensively in years past to troubleshoot my display before a show runs.
 
Also, will the new mp3 board have a line level output. I finally got good sound from my board but wasn't totally satisfied with it or the solutions.
 
Skunberg said:
Relating to E1.31, Vixen or LOR doesn't care or know what type of pixels you have, it's handled by the E68x.
Why would the Helix need to deal with pixel type if it's going to run the E68x?

Brian
Click to expand...

Budude is correct, if the Helix is to drive pixel strings then it would have to do it directly, not via the E68x boards.

I'm in no way putting down Jim's E68x boards. I think they are a really nice system. My general philosophy is if someone has already invested time and money into R&D then I don't need to reinvent the wheel. My original plan was to interface the Helix with the E68x boards but the limitations of the Wiznet Ethernet modules (only 8 sockets) and the way the E68x is implemented (using multicast) makes it somewhat uneconomical to do that. I had originally thought that I could just setup a unicast socket between the Helix and the E68x board and send the six DMX universes in six different messages with the universe number encoded in the header. However, since the E68x uses multicast this isn't possible. Jim has obviously spent a lot of time developing this and I'm not going to second guess his design. It is what it is so if the Helix is to drive pixel strings then I will need to design my own board to do it.

Since Jim and I both have the same limiting factors (we both use the Propeller chip) then the two boards will probably be very similar. The big differences will be instead of the Wiznet Ethernet port on the E68x board, the Helix will have a XBee port and an RS485 port (like the V3 Main Board). The Helix board will also have a microSD card socket for the firmware, config file and sequence data. One other difference would be the Helix board wouldn't have a 5V output port since it doesn't have a need to power an external switch.
 
kiowamike said:
I would like to see a way of stopping and starting a show, and playing an individual sequence. Also it would be great to have a test channel function like Vixen. I use test channel function extensively in years past to troubleshoot my display before a show runs.
Click to expand...

These are great suggestions that I've been meaning to implement for some time. The framework is in the Helix Network Supervisor (HNS) application and most of the code is in the firmware. I just need to enable it all and test it. The biggest problem I've encountered is with the "Stop" button. When the Helix is running a show it is sending a six byte message out for every event (usually every 50ms or 20 times/second). While to me this doesn't seem too much, the XBee radio doesn't seem to receive the stop message from the HNS. I've had some success with the wired RS485 port receiving the message but I had real problems with the XBee port. This is something that will need to be worked on to try and get it reliable.

The estimated resources cost is:

Time +
Cost -
 
kiowamike said:
Also, will the new mp3 board have a line level output. I finally got good sound from my board but wasn't totally satisfied with it or the solutions.
Click to expand...

It probably won't have a true line level output but I plan to try and optimize the output for operation with the FM-02 transmitter.
 
The main thing I would like to see is a way to drive pixel strings. I don't have any pixels currently so I don't really have any input on what types it should be able to drive.
 
Greg,

You've already implemented my most requested item, the triggers. And the new diagnostic LEDs and the test switch have been very helpful. I did notice that the test switch didn't operate my RGB floods. So if pixels are implemented a test switch that would make all of the pixels turn on would be very helpful.

And the new design of the HNS is great. Much easier, especially the integration of copying the files to the microSD card.

Now at the risk of sounding selfish, I would really like to go towards pixels before I invest too much more in LEDs or dumb RGBs. I know there aren't any promises, but it is time to start planning for Christmas 2013 and the pre-sales are on, so I'll need to decide if I want to gamble and get pixels, or settle for dumb RGBs for now. So pixel control would be my number 1, 2 and 3 choice.

I haven't explored LEDTriks much but I'm sure I could put it to use even though I have a nice sign done by a graphic artist friend.

I'd like to come up with something to provide a little bit of interactivity with the viewers. Maybe allow them to change the color of a certain channel, or to tweet a message to the LEDTriks. I might use an Arduino for that, but future plans and just food for thought here.

Even if I go dumbRGB for now, I'll pick up at least a couple of pixel strings and maybe even a E68x board. And to help you keep your cost down I'd be more than willing to lend those to you for testing.

You probably enjoy the board building as much as I do, but if it helps you with some time constraints, I'd also be more than willing to do the first build for you and send it back for you to test.

Basically, anything that I can do to help with the Time++++ and the Cost$$$$ just let me know and I'll try to help.

Exciting times. Thanks Greg
 
While to me this doesn't seem too much, the XBee radio doesn't seem to receive the stop message from the HNS. I've had some success with the wired RS485 port receiving the message but I had real problems with the XBee port. This is something that will need to be worked on to try and get it reliable.
Click to expand...
Would it be possible to use one of the unused gpio pins on the radio as a system interrupt for starting and stopping?
 
I have a few comments which I'll address in separate posts to avoid confusing myself.

Firstly the LED Triks. If there's little effort required and there are Helix users who desperately need it, I say go ahead. But the way pixels are heading, the LED Triks can only be regarded as "legacy" lighting gear, and if the demand is not there, don't bother - we'll all have pixel panels soon!

Just a personal perspective - feel free to ignore this one.

Dave
 
This one's just a minor point too, but if you're making changes to the main board, maybe look at the placement of the voltage regulators. U2, the 3.3V regulator only seems to need a small heatsink, whereas the large slide-on heatsink required by U1 is a really tight fit - on my boards, it touches the MP3 board and slightly overlaps D2 which prevents it from seating properly. Although the only one I could source locally in Australia may be a touch bigger than the recommended Mouser part.

It looks like R1, R15, D6 and C15 could easily be moved closer to IC3 to allow U2 to be placed on the edge of the board next to the RJ45 of Channel Bank 4 where it could use a smaller bolt-on heatsink. U1 could then be moved to keep its heatsink well clear of D2 and the new MP3 player (assuming a similar footprint). Moving it away from the power transformer a little may allow use of a more readily available bolt on heatsink too.

Dave
 
And now for the biggies! First of all, I like the Helix because:

(1) standalone when it comes to show time,

(2) powerful within its own right,

(3) but interoperable with other controllers, which significantly magnifies its power,

(4) these "foreign" controllers can be driven (almost) directly from your computer for developing and testing (both display hardware and sequencing),

which brings me to:
Pixel capability is essential for the future, and E1.31 is the way to go - IMHO. 10 to 20 universe displays are becoming more common each year - I know of one locally that uses about 40 universes - and we've all seen the videos of the massive projects that obviously top the 100 universe mark. Although that's extreme, we shouldn't be thinking small - pixel prices are coming down.

As much as I like the Helix concept, I don't like the idea of being locked in - a genuine E1.31 Helix Node would open up the project and expand it's appeal, whereas the inability to operate with E68X, j1sys and possibly other controllers would lock it down tight and discourages people with existing pixel inventory.

The Wiznet spec. makes it fine for a pixel controller like the E68X, but even there, the design maxes out at 8 universes.

I believe that the j1sys pixel controllers use Microchip PIC processors for their E1.31 interface. Someone suggested that it may be the PIC32MX795F512H but there are about a dozen variations all around the $6 mark for the chip. Using an ethernet-capable PIC on the Helix node would add the complication of another surface mount component and would no doubt require significantly more coding effort, but there's a lot of support on the Microchip web site (takes a while to dig out though), and it would not have the socket limitation of the Wiznet. It would, in fact, with sufficient compute-power behind it, help future-proof the Helix against further E1.31 developments. This would be my top priority by a big margin, but I'm conscious of the development complexity and the need to keep the final product affordable.

If this proves to be not feasible, and a Helix dedicated pixel driver eventuates which effectively mimics an E682, I'd suggest looking into the possibility of adding a Wiznet input capability so that it could also be used independently from the Helix network - see note above about development and testing convenience. An ethernet connection into the overall system could possibly have other uses too - for HNS maybe? I suspect you may be able to get some help from Jim if you take this route.

Dave
 
And the final big issue for me, especially in the light (pun intended) of large pixel displays, is the need to interface with more-powerful sequencing software. Vixen 2 will no doubt still be used for a number of years, but there seems to be some momentum building with the development of Vixen 3.

The V3 architecture is quite different from V2 and it would be next to impossible to simply translate file formats. However, the system uses output modules/controllers to translate the sequencing "intent" into actual, physical, timed channel data, which with a custom Helix output module, could no doubt be written to a file as the sequence is being played in real time, instead of being sent to hardware. The translation for Helix use would then be possible.

Ability to use other sequencers such as HLS, LSP, LOR etc. would also be a bonus, but Vixen 3 is the important one from my perspective.

And I think I'm done ..... for now!

Dave
 
You must log in or register to reply here.
Back
Top