Author Topic: A thought  (Read 2317 times)

Offline charleskerr

  • Jr. Member
  • **
  • Join Date: Jun 2013
  • Location: Oak Hill, VA
  • Posts: 87
  • Kudos: 0
A thought
« on: August 24, 2013, 11:36:53 AM »
I was curious if there was a possibility to consider definite a 485 transport that the community could gather around?  Currently the Falcon items use Pixelnet, which is an example of a high density protocol.  Others have been defined.  Would it be possible to have a discussion about consolidating them to one standard?  I understand many want to reuse their investment in DLA and other hardware.  However, if one is all ready using different firmware for those devices, it wouldn't cause one to lose their investment.

For instance, I have two concerns with Pixelnet as defined in the document. 
1. THe use of a data value to mark a frame.  A standard break could easily be used (not the DMX frame break, but a standard UART break) and not lose the value.
2. The 50msec update.  This is noticeable on fads and sub beats.  I was wondering if a compromise on the baud rate, update rate, and channel count could be reached, to allow the hardware and software to be interoperable.  Just a thought. 

Once one uses their own firmware, the possibilities are there, and I thought it might be nice.  I could be (and probably am) the minority.
One is never too old to learn

Offline David Pitts

  • Administrator
  • *****
  • Join Date: Mar 2013
  • Location: Falcon, CO
  • Posts: 3,736
  • Kudos: 63
Re: A thought
« Reply #1 on: August 24, 2013, 12:13:51 PM »
I was curious if there was a possibility to consider definite a 485 transport that the community could gather around?  Currently the Falcon items use Pixelnet, which is an example of a high density protocol.  Others have been defined.  Would it be possible to have a discussion about consolidating them to one standard?  I understand many want to reuse their investment in DLA and other hardware.  However, if one is all ready using different firmware for those devices, it wouldn't cause one to lose their investment.

For instance, I have two concerns with Pixelnet as defined in the document. 
1. THe use of a data value to mark a frame.  A standard break could easily be used (not the DMX frame break, but a standard UART break) and not lose the value.
2. The 50msec update.  This is noticeable on fads and sub beats.  I was wondering if a compromise on the baud rate, update rate, and channel count could be reached, to allow the hardware and software to be interoperable.  Just a thought. 

Once one uses their own firmware, the possibilities are there, and I thought it might be nice.  I could be (and probably am) the minority.

I am interested in a conversation. What did you have in mind? In response to your concerns I do not think there is any noticeable difference between 170 and 171 or 169.  Which baud rate, update rate , and channel count do you propose. I like the fact that you can send 16384 channels down a single Cat5 cable.  Never had a problem with refresh rate 20 Hz. 30Hz or more seems to me to be a lot more data for not much benefit. I will admit I do not sequence much with slow fades where a slower refresh rate may be a problem. To increase the refresh rate we would have to decrease channel counts or increase baud rate. The baud rate is most likely at the maximum speed for small processors. Many will not even output @ 1Mbs.
PixelController, LLC
PixelController.com

Offline charleskerr

  • Jr. Member
  • **
  • Join Date: Jun 2013
  • Location: Oak Hill, VA
  • Posts: 87
  • Kudos: 0
Re: A thought
« Reply #2 on: August 24, 2013, 12:49:48 PM »
Well, I was looking at a 35Msec update, with a baud rate of 1.2Mbit.  1 stop
 Frame would start with a break (not a data value).

This to me is a reasonable trade off. It lets you get a high channel count.

As for getting the 16K down a cat 5, one can only get that if one ignores the Ground.  RS-485 isn't a two wire standard, it should be three wire (one a ground). They could share grounds.  That is a nit I guess, but I have seen issues without running a ground.

Anyway, this to me is what I was thinking. Let the discussion begine.

Offline David Pitts

  • Administrator
  • *****
  • Join Date: Mar 2013
  • Location: Falcon, CO
  • Posts: 3,736
  • Kudos: 63
Re: A thought
« Reply #3 on: August 24, 2013, 01:26:29 PM »
Well, I was looking at a 35Msec update, with a baud rate of 1.2Mbit.  1 stop
 Frame would start with a break (not a data value).

This to me is a reasonable trade off. It lets you get a high channel count.

As for getting the 16K down a cat 5, one can only get that if one ignores the Ground.  RS-485 isn't a two wire standard, it should be three wire (one a ground). They could share grounds.  That is a nit I guess, but I have seen issues without running a ground.

Anyway, this to me is what I was thinking. Let the discussion begine.

I have not had any issues so far by not using the ground wire. At 1mbs it does not seem to be a problem. Maybe as the speed gets higher a problem may arise. The Falcon16 could probably run at your proposed protocol but the amount of pixels per string (170+) would have to be lowered by up to one third. There is very few clocks cycles left when all 16 ports are configured to output 170 pixels. The microchip used in SSC's would most likely not be able to keep up with refresh rate and baud rate and many packets would get skipped. 20Hz may be the limit for that processor. 

The Pi can now transfer 32k of channels to the Falcon FPD board @ 20Hz (The Pi can actually transfer more but FPD cannot receive more). If we increase the refresh rate the number of channels would drop proportionally. Also some software is fixed at 50ms timing like Xlights and LSP conductor format (These are the software packages i use).

I am not trying to be negative but these are the concerns that I have.

Offline charleskerr

  • Jr. Member
  • **
  • Join Date: Jun 2013
  • Location: Oak Hill, VA
  • Posts: 87
  • Kudos: 0
Re: A thought
« Reply #4 on: August 24, 2013, 01:44:40 PM »
I picked the 1.2 based on the PIC16F1455  (which does have an internal clock at 48Mhz) and can run at 1.2MBaud.  I didn't check to see what pic the FFP was using.

I guess I don't understand why the input rate changes the max pixels output.  i assumed that you store only the data needed from the input stream,and then clock those out to the pixels upon receipt of the last data one needs.  I have a PIC16F1455 that clocks out WS2811 (which I think is similar protocol to the TM chips) and I can support up to 300 pixels without (memory and timing constraints based on a constant input stream).

I may not be understanding how your firmware reads/writes the data.  No worries, it was just a thought. I had SSD(my own protocol similar to pixel net ) last year running at 2Mhz using the PIC32MX, but wanted to reduce that to try to get on a common standard. 


If it needs to run at 1Mbit, I can live with that.  Is it ok to eliminate the 170 data marker, and use a break?  Can the frame size be "up to 4096", but support less?  So if one doesn't send a full universe, one can get the faster frame rates?


Offline David Pitts

  • Administrator
  • *****
  • Join Date: Mar 2013
  • Location: Falcon, CO
  • Posts: 3,736
  • Kudos: 63
Re: A thought
« Reply #5 on: August 24, 2013, 02:06:41 PM »
I guess I don't understand why the input rate changes the max pixels output.  i assumed that you store only the data needed from the input stream,and then clock those out to the pixels upon receipt of the last data one needs.  I have a PIC16F1455 that clocks out WS2811 (which I think is similar protocol to the TM chips) and I can support up to 300 pixels without (memory and timing constraints based on a constant input stream).

How many strings does the PIC16F1455 output to. The PIC32 in the Falcon is outputting to 16 strings. It output all pixels @ 20Hz. When it receives the 8192 channels on the serial ports (it reads two RS-485 streams at same time) it will then output data to all 16 strings. It can output up to 170 pixels on each of the 16 strings before the next packet comes in. If the refresh rate increases the time to output to all 16 strings in decreased. 

Offline charleskerr

  • Jr. Member
  • **
  • Join Date: Jun 2013
  • Location: Oak Hill, VA
  • Posts: 87
  • Kudos: 0
Re: A thought
« Reply #6 on: August 24, 2013, 02:39:15 PM »
Ok, got it, I understand the strings count an the total number of pixels per string.   It was just a thought.  I know many do 50 msec, but there are some (more then just me anyway) who do have some sequencing to some sub beats and musch changes, that get missed if a 50 msec update is used.

When I do multiple stirngs, I still clock out the data in parallel (so the 16 strings are being done in parallel with shift registers, etc).  So the number of strings was a major contributor to the timing (it does factor of course).

Anyway, I understand your constraints.  It doesn't sound like a lot of room for change.

Offline David Pitts

  • Administrator
  • *****
  • Join Date: Mar 2013
  • Location: Falcon, CO
  • Posts: 3,736
  • Kudos: 63
Re: A thought
« Reply #7 on: August 24, 2013, 02:50:25 PM »
What are you going to use to be the driver for this proposed format? I am not against supporting it in the Falcon Pi/FPD. I am interested in viewing the complete spec. I would suggest not using any breaks that cannot be created with most processors (No long breaks that need another pin to create like DMX does on some processors).

Offline charleskerr

  • Jr. Member
  • **
  • Join Date: Jun 2013
  • Location: Oak Hill, VA
  • Posts: 87
  • Kudos: 0
Re: A thought
« Reply #8 on: August 24, 2013, 04:57:25 PM »
I design my pixel controllers, and use a "cheap" transport. So basically, it was solving a similar problem with to what Pixelnet was doing. I ran a high speed version of this for a few years for my own shows.  That was at 2Mbit, 1 stop, normal break to indicate start of frame.  I had the high transmission for I needed a fast refresh for my sequencing.  This year, I was looking at relaxing the transmission rate, to somewhere around the 1Mbit rate (was considering 1.2, but leaning more to 1Mbit).  I was going to back down on the channel count (from 4096 to 3072) to maintain a reasonable refresh rate.  I was going to a 35ms update rate in addition, to get a few more channels down the wire at a 1Mbit second. 

The protocol is pretty simple, it is a break, start code, and then 3037 bytes of data.

This is what I was considering anyway.

 

Back to top