Author Topic: Serial Outputs on F16-B Not Working as Expected  (Read 446 times)

Offline Gary

  • Supporting Member
  • ******
  • Join Date: Jan 2015
  • Location: Chilliwack, BC Canada
  • Posts: 342
  • Kudos: 3
    • Diamond Crescent Musical Christmas Lights
Re: Serial Outputs on F16-B Not Working as Expected
« Reply #30 on: November 13, 2017, 11:25:02 PM »

1) Do nothing:  PixelNet folks should know then need to use 50ms sequences.   That's a PixelNet restriction

2) Restore the background thread for PixelNet - the result would be for 25ms sequences, every other frame sent out to PixelNet would be dropped.  However, local pixels on the F##-B controllers would still blink properly at 25ms.

3) Remove the "wait" and just copy the data to the PRU using an overwrite.   For DMX, the wait is irrelevant.   For PixelNet, what would happen is the first frame would start sending data.  About 1/2 way through, the second frame data would overwrite so the second half of each PixelNet universe would get the second frames data.   Thus, some lights would be on frame 1 and some on frame 2.   Not sure how this would look.   

Anyway, I'm not a PixelNet person at all so I have no idea what the best option would be.   Option #1 is obviously the easiest for me  :)  but I could do the others as well.

I did a test and created both a 10-second long 25 and 50 ms sequence with a timing mark created every 25 and 50 ms, respectively, and I alternated all my pixels all on at one timing mark and off at the next timing mark to manually create a maximum strobe effect. I then copied the 25 ms FSEQ file to my older image F16-B running FPP and copied the 50 ms FSEQ to my F16-B running the new image. I hooked up each F16-B to an F16v1 and ran my test sequence. The 50 ms sequence had the pixels strobe at the same rate for both controllers. The 25 ms sequence strobed incredibly fast on the F16-B, but the F16v1 flashed back and forth at a pathetically slow rate (about 18 "ons" and 18 "offs") during the 10-second FSEQ file.

You said that it takes 44 ms to output one universe of Pixelnet. That means that it takes 176 to do 4 universes? Or did you mean to say that all 4 universes on one CAT5 cable can be done in 44 ms?


How did FPP process it in the past because I was successfully doing 2 (not 4 like this year, mind you) universes at 25 ms with no severe lagging in December 2016? If you see the "sparkle" effect in this video (https://youtu.be/wLO6g6RuDDs?t=57s), my left garage door is on my F16-B and my right garage door is on an F16v1. They both appear to have the same response time. Was the background thread that you removed somehow helping with frame rate performance? Or simply are the extra 2 universes killing it now?

I can't help but to wonder if the background thread you now removed was causing "unreliability" issues last year for me as well because when I kept my FPP in Bridge Mode for any length of time, FPP stopped responding along the heartbeat LED on my BBB that stopped flashing. The issue hasn't occurred yet with FPP running on my new image. I suppose that the K.I.S.S. principle could be applying here.


Anyways, going forward, to answer your questions about how to deal with it, I'd say the best option is begrudgingly 1 because option 2 would seem weird to have a show where some pixels are fast and others are lagging, and option 3 would be even worse because showing 2 "frames" at a time would be like going back to interlaced video (https://en.wikipedia.org/wiki/Interlaced_video#Interlacing_problems). Ick.

...Or, I suppose that faster revisions of the BeagleBones would eventually be able to handle 4 universes of Pixelnet at 25 ms speeds?

Offline dkulp

  • Sr. Member
  • ****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 425
  • Kudos: 13
Re: Serial Outputs on F16-B Not Working as Expected
« Reply #31 on: November 14, 2017, 05:45:01 AM »
Beaglebones are plenty fast enough, but the PixelNet spec is a fixed timing.  It's 1024 kbaud.   PixelNet uses start/stop bits so 10 bits per byte sent.   So 1024K / 10bits is 102.4KB/sec.   A PixelNet universe is 4096 + 6 byte header.   Thus, 102.4K / 5002 = 20.5 frames per second is the absolute max, or just under 50ms frames.  Going faster would require smaller universes or a faster transmit speed.   Either would require all new firmware and possibly new chips and everything on the PixelNet receiver boards. 


2 vs 4 vs 8 universes is irrelevant.   The BBB code always writes out 8 universes, but they are on separate pairs of wires in the cat5's.   They are done in parallel, not one after the other. 



I went back and looked at the original code, it's actually a combination of 2 and 3 where it used the background thread and thus not block, but would overwrite data and could introduce the tearing and partial frame issues.   





Dan Kulp

Offline Gary

  • Supporting Member
  • ******
  • Join Date: Jan 2015
  • Location: Chilliwack, BC Canada
  • Posts: 342
  • Kudos: 3
    • Diamond Crescent Musical Christmas Lights
Re: Serial Outputs on F16-B Not Working as Expected
« Reply #32 on: November 14, 2017, 10:04:53 AM »

Yes, video tearing was the term I was thinking about... I was only able about to think of the word interlacing...

So, it sounds like I probably had tearing going on back in December 2016 (just didn't notice it). I suppose if it was dropping frames as well, I didn't notice it either, so 2) would be desirable behaviour for the reason that people can just use either frame speed and the FPP would just secretly drop frames and people like me can just live in ignorant bliss about what's really happening.  :D


However, I still secretly wonder if this extra sophistication was causing the unwanted lockups in Bridge Mode. I'd say that reliability (i.e. No unexplained BBF/FPP freeze-ups) should take precedent over frame rate.

Offline dkulp

  • Sr. Member
  • ****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 425
  • Kudos: 13
Re: Serial Outputs on F16-B Not Working as Expected
« Reply #33 on: November 14, 2017, 01:14:25 PM »



I just pushed a change for this....   Can you give it a test?  I don't have any pixelnet things so I'm not really confident about this.   When I looked into the code more, even the old code would have dropped frames, not introduce tearing.   Thus, this should make it behave like the old code.








Offline Gary

  • Supporting Member
  • ******
  • Join Date: Jan 2015
  • Location: Chilliwack, BC Canada
  • Posts: 342
  • Kudos: 3
    • Diamond Crescent Musical Christmas Lights
Re: Serial Outputs on F16-B Not Working as Expected
« Reply #34 on: November 15, 2017, 12:02:59 AM »
Executive Summary:
I updated to v1.9-bbb-90-g720d0a3 (bbb-stretch-v1.x branch), and it seems to work fine at 25 ms.


Here's more info, for enquiring minds:  :)

I created a different 25 ms strobe test sequence where I actually used the xLights Strobe effect for pixels to flash randomly and it was apparent that the F16-B's pixel string outputs are much faster than the F16v1's pixel string outputs. In my last 25 ms test to the F16-B running the old FPP image (where all pixels were being turned on and off at once) with output to my F16v1 that seemed to look like a pathetically slow 3 frames per second, I get a feeling what was really happening was that about 1/3 of a second's worth of the 25 ms "on" frames weren't dropped, then about 1/3 of a second's worth of the 25 ms "off" frames weren't dropped, then about 1/3 of a second's worth of the 25 ms "on" frames weren't dropped, and so on, which resulted in apparently slow flashing.


Interestingly, I was working on converting my sequences to 50 ms (I did a backup first, though, so I can compare to my original 25 ms timings), and noticed that some of the fast Garlands effects in one of my sequences didn't appear to "stack" quite right at 50 ms, so I had to change the Spacing slider to make it look more like the original 25 ms version.

Here is the song: looking at the 41-second mark on this video from last year, you can see the left garage door on an F16-B looks a bit different than the right garage door on an F16v1 that was losing 25 ms frames: (https://youtu.be/hcAIPy27fBw?t=41s). I didn't notice it back then, but now I can't unsee it!

Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 7,939
  • Kudos: 142
Re: Serial Outputs on F16-B Not Working as Expected
« Reply #35 on: November 15, 2017, 12:11:57 AM »
However, a few things are kind of weird. I noticed that the UI of FPP is sometimes a bit laggy.

I'm trying to remember your setup.  Do you have E1.31 enabled but the controllers are offline/inaccessible?
-
Chris

Offline Gary

  • Supporting Member
  • ******
  • Join Date: Jan 2015
  • Location: Chilliwack, BC Canada
  • Posts: 342
  • Kudos: 3
    • Diamond Crescent Musical Christmas Lights
Re: Serial Outputs on F16-B Not Working as Expected
« Reply #36 on: November 15, 2017, 09:27:20 PM »
I'm not exactly sure what you're asking. Under Input/Output Setup | Channel Outputs | E1.31/Artnet, the Enable E1.31/Artnet Output check box is blank, although I have 32 universes set up. The FPP Start Channel starts at 317 because 1-316 is set aside for my DMX stuff.


I access my F16-B via WiFi when I'm at home. I can't access it when I'm at work, for example.

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 3,835
  • Kudos: 81
    • Granbury Christmas Lights
Re: Serial Outputs on F16-B Not Working as Expected
« Reply #37 on: November 16, 2017, 06:42:14 AM »
I'm not exactly sure what you're asking. Under Input/Output Setup | Channel Outputs | E1.31/Artnet, the Enable E1.31/Artnet Output check box is blank, although I have 32 universes set up. The FPP Start Channel starts at 317 because 1-316 is set aside for my DMX stuff.


I access my F16-B via WiFi when I'm at home. I can't access it when I'm at work, for example.

Have you tried setting the FPP Start Channel at 1 ?  Reserving channels like that is usually counter productive.

Offline dkulp

  • Sr. Member
  • ****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 425
  • Kudos: 13
Re: Serial Outputs on F16-B Not Working as Expected
« Reply #38 on: November 16, 2017, 07:09:29 AM »
No, leave it at whatever you have it set in xLights.  Consistent across the controllers is more important.


The lag may have been for the same 25ms issue.   The main thread was blocked and thus couldn't process the status requests.   Possibly.  Not really sure.




Offline Gary

  • Supporting Member
  • ******
  • Join Date: Jan 2015
  • Location: Chilliwack, BC Canada
  • Posts: 342
  • Kudos: 3
    • Diamond Crescent Musical Christmas Lights
Re: Serial Outputs on F16-B Not Working as Expected
« Reply #39 on: November 16, 2017, 06:51:12 PM »

I had an issue where the pixels corresponding to the channel numbers assigned on the controllers in Xlights (in the Test mode, for example) were not matching the channels that were being turned on when using FPP's Test mode.


I stayed up to the wee hours of the morning to joing a Zoom session with the group of people in Australia. I was instructed to make the changes in FPP.


Refer to this link for details:
http://nutcracker123.com/forum/index.php?topic=4720.0
« Last Edit: November 16, 2017, 10:02:24 PM by Gary »

 

Back to top