Jump to content
Did you know?
  • The original Rudolph did not have a red nose. In that day and age, red noses were seen as an indicator of chronic alcoholism and Montgomery Ward didn’t want him to look like a drunkard. To complete the original picture, he was almost named Reginald or Rollo.
  • The Christmas wreath was originally hung as a symbol of Jesus. The holly represents his crown of thorns and the red berries the blood he shed.
  • The three traditional colors of most Christmas decorations are red, green and gold. Red symbolizes the blood of Christ, green symbolized life and rebirth, and gold represents light, royalty and wealth.
  • Tinsel was invented in 1610 in Germany and was once made of real silver.
  • The oldest artificial Christmas trees date back to the late 1800s and were made of green raffia (think grass hula skirts) or dyed goose feathers. Next the Addis Brush Company used their machinery that wove toilet brushes to create pine-like branches for artificial Christmas trees that were less flammable and could hold heavier decorations.
  • ‘Jingle Bells’ – the popular Christmas song was composed by James Pierpont in Massachusetts, America. It was, however, written for thanksgiving and not Christmas.
  • Coca-Cola was the first company that used Santa Claus during the winter season for promotion.
  • Hallmark introduced their first Christmas cards in 1915.
  • The first recorded date of Christmas being celebrated on December 25th was in 336, during the time of the Roman Emperor Constantine. A few years later, Pope Julius I officially declared that the birth of Jesus would be celebrated on that day.
  • Santa Claus's sleigh is led by eight reindeer: Dasher, Dancer, Prancer, Vixen, Comet, Cupid, Dunder (variously spelled Donder and Donner), and Blixem (variously spelled Blixen and Blitzen), with Rudolph being a 20th-century inclusion.
  • Outdoor Christmas lights on homes evolved from decorating the traditional Christmas tree and house with candles during the Christmas season. Lighting the tree with small candles dates back to the 17th century and originated in Germany before spreading to Eastern Europe.
  • That big, jolly man in the red suit with a white beard didn’t always look that way. Prior to 1931, Santa was depicted as everything from a tall gaunt man to a spooky-looking elf. He has donned a bishop's robe and a Norse huntsman's animal skin. When Civil War cartoonist Thomas Nast drew Santa Claus for Harper's Weekly in 1862, Santa was a small elflike figure who supported the Union. Nast continued to draw Santa for 30 years, changing the color of his coat from tan to the red he’s known for today.
  • Christmas 2018 countdown has already begun. Will you be ready???
  • Why do we love Christmas? It's all about the traditions. In this chaotic world we can miss the "good old days." Christmas reminds us of that time.


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About jstjohnz

  • Rank

Profile Information

  • My favorite Christmas story
  • Location
    , ,
  1. Sorry, tardy response, and a lot has already been covered, but... Q1) If I am outlining eight different windows with RGB rope lights, in relation to a LoR controller, this would take up 8 channels. However, from what I've read, every RGB strip needs three channels - am I correct in thinking this means the eight windows would need 24 channels in order to run on RGB via the LoR Showtime PC CTB16PC controller? If you have RGB rope lights that run off of 240V you could run them from a LOR controller that was also set for 240V. Q2) I have read that I need a separate DMX controller of sorts to control the RGB via the LoR controller - is this correct? What cable is needed to do this, and what DMX controller is recommended? I have a memory, of an E-something DMX I think, but again I got a little lost and confused at this part of the research. This gets into 'dumb' pixels vs 'smart' pixels, and even that terminology is poor. The term 'dumb' refers to lengths of RGB leds where the entire string lights the same color. Typically these operate off of low voltage DC, and that's where the controller comes in. The controller inputs DMX signals (either directly from the show PC using a USB to DMX 'dongle', or via an E1.31-based controller or converter that can convert E1.31 DMX to standard 2-wire DMX). it's also connected to low voltage DC power supply, and it outputs the 3 DC voltages to control the R, G, and B elements of the string. Q3) I am aiming to do some arches this year (probably four) - and some mini trees (probably eight). Preferably all in RGB lighting. Do I need a number of DMX controllers to have various RGB items on the display, or does one control them all? Arches are typically done with 'smart' RGB pixels in order to be able to do dramatic effects. These are pixels where you can control each light individually, as opposed to the 'dumb' lights where the entire string must light the same color. Smart pixels are usually controlled using E1.31 aka SACN, a protocol that allows the control of a very large number of pixels by sending multiple DMX universes over a single ethernet cable. The ethernet cable connects to one or more E1.31 pixel controllers, and they convert the ethernet signal to the proper signals and voltage to drive the pixel strings. This is where your channel counts can grow rapidly because each individual pixel uses 3 channels, or 1 RGB channel if your sequencing software supports that. If you're running a mix of dumb and smart pixels, you can either run an E1.31 cable for the smart pixels, and one or more wired DMX universes for the dumb pixels, or you can run everything off of E1.31. To do that you would need either a converter that converts E1.31 to standard DMX, or a pixel controller that can output standard DMX in addition to controlling smart pixels.
  2. That makes we want to put a scope on the end of the line and see what's happening to the waveform. There are 2 variables for 2811 timing, the width of the bit cell, and the points in the bit cell where the data line transitions from 1 to 0, early in the cell for a 0, late in the cell for a 1. If the 1-0 transitions occur near the edges of the bit cell then that would allow for a wider range of speeds to be accepted by the pixel with the tradeoff being that you are having to send higher frequency pulses down the line, and IIRC that's what's recommended in the 2811 data sheet, something like transitioning at 20% for a 0 and 80% for a 1. Positioning the 1-0 transitions nearer the center of the bit cell reduces the allowable timing variation but also reduces the bandwidth requirement on the line. By slowing down the data rate you are pushing the 1-0 transition for a 0 bit closer to the time when the data is sampled by the chip. In theory, if the code is set to divide the bit cell into 5 increments, you could operate anywhere from about 350kbps to about 1200kbps. If you've experimented with it, is this about the speed range that you can operate at?
  3. OK, I have to ask. Since most 3-wire pixels, and this for sure applies to the 2811s, are designed to run at one specific data rate (800khz in the case of the 2811), what is to be gained by adjusting the speed?
  4. @jeremy lawton: You can download the assembly manual from the web site, that will give you a good idea of what's involved in the assembly. @DSE: I use a combination of LOR and madrix in my own display. LOR handles the music and general sequencing. I have a large pixel matrix, 48x84, and I use Madrix to display various 'scenes' on the pixels. A few channels of LOR are used to remote-control madrix, that way it's easy to bring up the right effect at the right time. You should download the Madrix demo and play with it, you will be amazed at the incredible effects that you can produce with very little time. @Clyde Lindsey: There will be a new firmware release soon for the E682s, also applicable to earlier boards that have been upgraded with the new ethernet module. The new software supports unicast as well as multicast, and bumps the universe count up to 7 (1,190 pixels) if using multicast and 12 (>2,000 pixels) for unicast.
  5. It sounds like you have a few bad pixels. If you can exchange them I would do that. If you can't exchange them you may have to sacrifice the last few pixels from one of your strings to replace the bad pixels in the other strings.
  6. Beta testing is going well. I'm going to try to ship a few ELORs next week, full availability by the end of the month. The latest boards have a single standard RS485 DMX universe output in addition to the E1.31, basically functions like an iDMX1000 except that all channels are "smart" channels. Right now the DMX port mirrors the last E1.31 universe, although it may be possible to make it a separate 5th universe at some point.
  7. Possibly as early as mid-March. That's when boards will be here.
  8. Pretty much anything that uses 'smart' pixels, in other words the pixels that have built-in controller chips. 'Dumb' pixel strips that light up the whole strip the same color require a different type of controller.
  9. If the E681s are fully populated with pixel strings, then yes. One ELOR board will be able to control 680 pixels. Those 680 pixels could be split among multiple pixel controllers. Also, it hasn't been determined yet what the practical limitation is in terms of just how many channels of pixels you can run on an LOR network before the network becomes overloaded. And that depends on a lot of factors, but mainly what you're trying to do with the pixels. Basically 2 boards are required to drive pixels from LOR. The ELOR board that just converts the LOR network protocol into the E1.31 DMX/Ethernet protocol that the pixel controllers understand, and a pixel controller. Any pixel controller that supports E1.31 should work. LOR NETWORK ->> ELOR ->> PIXEL CONTROLLER ->> PIXELS
  10. I smoked the chip in the LOR USB/RS484 adaoter that puts power on the LOR network.
  11. 2 boards going out to beta testers today. Updated user manual on the sandevices.com site downloads page. Advice of the day: Don't plug a LOR network cable into an ethernet socket.
  12. I received the revised boards yesterday and have built up all 3. They seem to be working fine, although I haven't checked the RS485 DMX output yet.
  13. The prototype seems to be operational at this point. I am able to control pixels from the LOR software using the converter and an E681 pixel controller. A bit more testing/tweaking to do, but it's close.
  14. Bandwidth on the LOR network may be an issue, depending on the type of activity going on with the pixels. It's comparable torunning 4 DMX1000s except that all channels are smart channels. The E681 has better line driving capability (5V vs 3.3v) so it's capable of driving longer distances between controller and pixels. Also it can run from any supply voltage between 5 and 24 volts. It has a regulated 5VDC output for powering a small ethernet switch. Reverse polarity protection on pixel power, greater current capacity on pixel power inputs, and the string connectors are much easier to deal with since the connectors for the pixel strings use screw terminals rather than crimp. Also it will mount directly into a CG-1500 enclosure. Those are the major points.
  15. I hear from a lot of folks that are frustrated by not being able to run E1.31 (ethernet DMX) based pixels from LOR. And, yes, I know that LOR has promised E1.31 support at some point. For those who want instant gratification, I have a hardware solution. It's a controller that plugs into your LOR network (and can be powered from the LOR network), and to LOR software it appears as 4 iDMX1000s at consecutive IDs. Controller ID can be set via the LOR hardware utility, and when you scan your network with the hardware utility you will see 4 DMX1000s, with version number 9.x to distinguish them from standard LOR hardware. Coming out the other end is an ethernet port that provides 4 universes of E1.31 (DMX over ethernet) data. This is compatible with the E680/E681 or any other E1.31-based pixel controller. All 2,048 channels will be 'smart' channels, supporting twinkle, shimmer, and fades. I'm planning on having a 'pixel' mode where twinkles for the RGB channels of a single pixel would always be in sync, to avoid color changes when twinkling pixels. It's in the final testing/debugging stage right now, I expect that it will need another week or so of software development time before it's fully functional. If there's interest, I'll do a run of boards and add the product to the Sandevices web site.
  • Create New...