Author Topic: Implementing PixelNet, a couple questions  (Read 1446 times)

Offline ptone

  • Sr. Member
  • ****
  • Posts: 107
Implementing PixelNet, a couple questions
« on: January 16, 2011, »
Not being a PC user, I'm going to be doing a little extra work to get SS up and running.  Originally, I was going to just wait for the PixelNet Dongle since E1.31 is something I have working now, but without knowing when that might become available, I decided to go ahead and get a couple Lynx dongles ordered in the current coop.

In doing some preparatory research (I'm using the Python programming language), looks like I should be able to address the dongle in one of several ways.  There is a libftdi project out there (with python bindings) which is a library to talk directing to the FTDI chip in the dongle - this would not require any driver, as it communicates direct over USB.  The other option is to use the Virtual Com port driver (which is cross-platform) and use the pyserial library.  So I hope to be providing another way to communicating with PixelNet hardware.

My questions:

Is there any chance that the source code to the current plugins (Vixen, LSP) could be made available as sample code.

It is not clear from the spec, whether it is possible to get higher refresh rates by sending less than the full 4096 channel/bytes of data.  Does the hardware just look for the 170 marker byte, or does it also count out to a full packet?

I've used this approach to get some experimentally high refresh rates out of DMX - by limiting the Universe to 128 channels instead of 512.  What is the refresh rate limit of the pixel string protocol itself?

-P
--
budding channel wrangler

Offline RJ

  • Administrator
  • Sr. Member
  • *****
  • Posts: 8519
Re: Implementing PixelNet, a couple questions
« Reply #1 on: January 16, 2011, »
I normally keep technical talk out of the forums and move it to pm or chat at DLA. I do this to keep from having new members feel like DIY is out of their abilities. They do not often understand it is nothing they need to be concerned with and that we handle it in the background for them.

With that said it is not very technical at this point. I will answer but if we need to go farther please pm me.

You do not need to send all 4096 channels of data. The vixen plugin does not if the seqence is less it sends the amount of channels in the seqence.

But with that said you have no control over the refresh rate. The dongle does. No matter what you do you can not effect it in any way other than to delay changes to make it look slower.

It is  ~ 30 updates per second same as video. I figure if it is good enough for my avatar movie it's good enough for my light show.

Remember PixelNet and DMX has nothing to do with each other. I have seen pixelnet explianed as DMX with more channels and ect.

It is just channel data, dmx is a formatting standard. It does not relate to 512 channels it is just 4096 channel which can be divided by 512 equally.

The Hub makes DMX for you from pixelnet as a convienance to run other things. 

As far as drivers the dongle is expecting a Virtual com port so you would be better off using it. Do not worry about speed limits as the FTDI drivers for the chip I use ignores the setting and puts data out as fast as the usb port can do it. (faster than we need)

Just open a com port at 115k 8 n 1 and send  (170) then channel 1 ..... last channel you have up to and including 4096.   Just make sure you move any 170 values to 171 to prevent problems.

repeat when ready.

RJ

Innovation beats imitation - and it's more satisfying