Jump to content
Light-O-Rama Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About rmcjfrank

  • Rank
  1. Yeah, mine was fixed most of the time...but not 100%. I abandoned the AlphaPix for the PixLite because of that.
  2. Try the 1.04 firmware. It fixed most of my issues. I have runs of 40+ feet that work great with the Pixlite.
  3. All, an update: I did the firmware update, and the lag was significantly diminished, but still exists. Both with a few of the regular outputs AND the DMX outs to some dumb controllers. Essentially, lights will occasionally just stay on in the last color (complete strip) for several seconds, and then will "catch up" to the sequence. I put the Pixlite back in for the season -- it was almost plug and play, but had to switch up the pin outs for the connectors. It is working flawlessly! Certainly disappointed with the AlphaPix -- going to request a full refund -- with all the money I have spent with Holiday Coro, I sure hope they do the right thing and take this back.
  4. Unfortunately, this forced me to spend another $200 because it is already mid-Nov with no fix in place and way to close to the season. Worse, as stated above, it is beyond "warranty" so I won't get my money back (bought it about 4 months ago) -- very disappointed in Holiday Coro's decision to switch to these (underdeveloped) boards. Fortunately I got a PixLite 16 from the very helpful Advatek folks. Everything is in and running with no issues with the Pixlites. No need for null pixels either -- up to 40 feet on a couple of runs with no problems. I do understand and appreciate they are trying to get it resolved -- just unfortunate for me (financially). Maybe I can get Holiday Coro to take this board back and give me a refund, but not holding my breathe.
  5. Thanks all, I considered the PixCon16, but since I knew the PixLite 16 was good for my setup, and my timeline was short, I ordered one from Advatek -- very responsive company and one is on the way. I hope I can return the AlphaPix at this point -- I have had it about 3 months, and don't know if HC will take it back. I suppose if the firmware fixes the issue, I can use it next year for an expanded display.
  6. I had previously posted about Null Pixel help, but turns out my problem is not due to the lack of null pixels -- rather it is the AlphaPix 16 controller. I verified by swapping out a Pixlite 16, which ran smooth as silk. With the AlphaPix 16 (v1) using LOR S4 Pro, there is serious lag issues, as well as some strips staying on randomly, etc. Super frustrating. I reached out to HolidayCoro with the issue, and he said they are releasing v1.04 of the firmware - estimated to be Mid-Nov - that fixes lag issues with "certain sequences." My concern is if this doesn't fix my problem I will be absolutely scrambling so close to the start of my show season. I am considering dropping another $200 on a Pixlite 16 straight from Advatek...but really don't want to do that (including buying a new enclosure, cords, etc...and building it). Questions: 1) Anyone else have this issue? 2) Does anyone have a fix or setting change that helps? 3) Seems this is an LOR unique issues -- if so, is there something I should do to my sequence? 4) Does anyone believe this new firmware will fix this type of issue? -- Rob
  7. UPDATE: so, I still don't have null pixels installed, and when I ran the Halloween show last night, I was having whole strips staying on or not responding correctly -- no matter how far from the controller (some are only a few feet). Got me thinking about another troubleshooting step. So, I pulled out my Pixlite 16 from last year's mega tree, and put it in place of the Alphapix 16 -- worked like a champ! The issue seems to be the Alphapix 16 controller - anyone have similar issues with this controller, and any recommendations? I have the latest firmware (1.03 -- 1.04 isn't posted yet).
  8. Thanks! Interesting enough, without the null pixel, ALL of my runs "work" without flicker -- however, I think some of the data isn't getting to the right place at the right time when a sequence is running. For strips, I am injecting power for runs over 50, but for the bullets, I have runs of 70, 80, and 90 without any power drop-off (and am told that I don't need to power inject those unless runs are over 100). It seemed so weird that without a null pixel, the 50 pixel run 20 feet away from the controller worked fine in test mode, but with the null pixel placed halfway down, it flickered in test mode. I thought maybe it was my soldering work, but it happened the exact same way on more than one. Do you think that a distance of 10 feet from one pixel to the next is too far? Would I be better with putting in two for a run of 20 feet? (one every 6.6 feet to the first set of "real" pixels).
  9. Hi all, I have been working with LOR equipment for years, but have taken the DMX plunge over the last two years. This year I got ambitious and decided to outline my house with lights. OK, so everything worked good in test mode, but during some sequences, from time to time a few runs of smart pixels wouldn't turn off or change color like they should have (the entire strip, and it was random from from one run of the show to the next). I realized I didn't have any null pixels, and a few of the strips had long lead lines (to get from the box to the first pixel) -- upwards of about 30-40 feet. So I decided to add null pixels to all the runs 20 feet or longer -- that is where the problem came in. Equipment involved with the problem (most from HolidayCoro): PC w/Windows 8.1 LOR S4 software (songs converted to Intensity Files - smaller file/remove lag), sequence being run from the sequence editor TP-Link 10/100 5 port switch (from HolidayCoro) AlphaPix16 Controller (E1.31 network) - approximately 50 feet from computer Light strips: 12v/2811 pixel strip (50 segments) Pixels: 12v/2811 bullets, w/8" spacing (80 bullets) Extension wire: 18ga/3 wire black jacketed extension wire (like the pigtail connectors) I soldered in a null pixel about halfway (10 feet down a 20 foot leader line) -- of two different props, one a strip, and the other a run of bullets. When I turned on the box, they weren't working right and were flickering. I changed the setting on the AlphaPix to account for the null pixel, and now they were only flickering (in white, some colors don't flicker). When I cut out the null pixel, the flickering stops -- put it back, it returns. I am using spare 12v/2811 bullets as my null pixel for both the strip and the group of bullets. Both have the same problem. I even successfully fried one of the output chips (my carelessness), but now have it back to not having a null pixel anywhere. Here are my questions: 1) do I need null pixels in this situation -- better yet, how do I know if I need a null pixel? 2) what would make it flicker like that with the null pixel? 3) the only other thing I can think of is that a signal can go a good distance to the first pixel, but once a pixel gets the signal and has to forward it, there is a limit to how far it can send one -- does anyone know if that is the case? I would appreciate any help/advice! Hopefully the new output chip arrives soon as well!. -- Rob Springfield VA
  10. I modified an SE file with PE (imported the prop data, then deleted the original SE data) in a particular directory on my computer. At that time, it created video files for each prop, and the preview played fine. I since have reorganized, and moved my files to another folder. Problem is, the preview doesn't show unless those video files are left in the original directory when I created the PE version of this sequence. How can I move a sequence to another file location, and still get the preview to work?
  11. Today, it loaded just fine -- must have been some sort of operator error!
  12. I am trying to open a file (that I just got done working with), and it is taking seemingly forever to load. A dialogue box labeled "Processing" is up, and the bar is very slowwww....is it me, or do other have this sort of issue? It happened after I clicked the green play button. It took about 5 minutes to finally "play". A little stuttering when it plays too.
  13. Update: my workaround was to "reassign" the channels in SE - tedious, but it end up being strip 1,2, & 3. I just reclicked the same info on each one -- one-by-one -- and it finally lined up 2400 for 2400. All of the channels were correctly listed, but clicking the same info (actually, I only had to reselect "DMX" for each one, and that fixed it).
  14. Same problem, and all of my channels are in Track 1. I am trying to import a mega tree, and it lists channels that "don't exist" in SE...yet they do. It needs to import 2400 channels, and it says only 2079 SE Channels exist -- yet all 2400 exist in SE. Also, a problem for a possible future fix - when you click "more info" to see what channels have the problem. The box that pops up has a fixed width, and goes beyond the screen (below), but you cannot scroll. In short, I can't see more than about 100 of the 321 channels that are in error.
  15. When I created objects in Pixel Editor as "Dumb Pixels" (in this case, two wreaths), they didn't show on the import list. The only workaround I could find was to make them temporarily "Smart Pixels" (1 pixel, 3 channels), imported the channels, then changed them back. Is there an easier way, or is this an issue with the Pixel Editor? This is my first week working with the program...had a few challenges and errors along the way so far.
  • Create New...