Table of Contents
Status bar color scheme of FB4
| Color | Description |
|---|---|
| White | FB4 connected and operating normally |
| Red | controller disconnected |
| Yellow | TV mode is ON. TV mode is fixed FPS mode, and opposite to dynamic FPS mode used by default. |
| Red in TV Mode | notification about expected lost sync of refresh rate. It means – you send too many points for currently selected FPS and Sample rate. It is impossible to display such output. As example 1000 points at 100 FPS at 30K output. Such notification comes with message “Too long frames” |
| Green | FB4 Data FIFO overload. Usually consequence of network congestion, or some other kind of overload. Software manage data traffic to avoid overload. |
| Cyan | FB4 Command FIFO overload. Commands and data use different route. This color indicates of another FIFO overload. Problem has similar nature as “Green” status color. |
| Pink | Delivery delay. Delivered frame came too late. This problem may happen because of two types of problem. 1ts is CPU overload. Software cannot calculate in output time, and it leads to delayed delivery. 2nd is network congestion. Data cannot be delivered in time from PC to FB4. |
Icon Legend
| Icon | Description |
|---|---|
 | Communication indicator. All is OK. |
 | connection closed. This is normal situation, FB4 might be not connected. |
 | Connection in progress. Usually you should not see this icon. This is not error… this is indication of establishing TCP/IP connection. But, normally it takes milliseconds to do this, and you should not see it. If you do – something wrong with network |
 | onnection error (Invalid state of communication socket). This is also not expected result. Most possibly their problems with network in your computer. |
Recommended actions in case of different colors
| Font Color | Description |
|---|---|
| White | no problem |
| Yellow | If you have TV mode on then all is OK. Otherwise – disable it, and color will go back to normal white |
| Green, Cyan | contact Pangolin support, and send log files of QuickShow |
| Pink | Some delay. Open Core Monitor and see how long takes one calculation. Should be 0.1…2ms. If more then you need faster CPU, or simpler content, or you can decrease quality of output (Performance Tuning window). The other place is FB4 data transmission window. More below. |
FB4 Data transmission monitor
How to look at diagrams? Here is essentials about main parameters. Main things to understand – problem may happen and QuickShow offer tools for diagnostic. QuickShow and FB4 measure speed of data flow in all main parts, and offer you diagrams of main places.
Software speed
Laser output is real time process. However, calculation and communication takes some times. Longer time inject lag but help to avoid flickering in case of delays. In overage, simple calculation should take around 1ms, and communication 1. Calculation duration goes up as with more effects, more tracks, more projectors. Software start processing 25 ms ahead of time. This should not enough for compensation of typical delays. A healthy diagram looks like the one below:
Lines ending at range of 20 .. 25ms are OK. If you see diagram like saw tooth, then this indicator of CPU overload. CPU cannot come to calculation in time. So, you see sawtooth here instead of line – this is direct indicator of CPU.
Network speed
This diagram show time between 1st and last ethernet fragment of laser frame. Software prepare sold buffer with complete frame and send it to network by means of one WinSock function call. This is the end of software/application level. FB4 on other side assemble the data back, and measure time between arriving 1st and last packet. Normally it should take 0.1…3ms. If you see long vertical red line in this diagram, then network was busy by something else. Basically this is direct indicator of some network issue. Think for a second, software level supply solid buffer for communication. There is no segmentation at this level. At the other side FB4 compose packers into frame, and it cannot make packets arrive faster… they come as they come. So, if we send one solid block, and see huge gap between segments then something happened at delivery phase.
Network delay
Time between ending of data sending by BEYOND, and receiving the 1st packet of frame. In other words – time between ending of software part of work, and beginning of FB4 work. This time should be around zero, or 1ms. It will go up with higher network load, but should not be higher than 10ms. If you see it – you need faster network equipment.
Display shift
FB4 has special algorithm to balance between network hick-ups and smooth output. Sometimes FB4 will need to delay output, skip frame, or repeat frame (to avoid flickering). This diagram show shift between ideal conditions and where we are now. If all is OK then value should be zero. If you see high yellow peaks – this is delay. However, this is more a consequence of drops of overload, rather than indicator of a reason. If you see peaks here then this is a confirmation of known problem.
Overall
This is good to know the reason, or type of problem. Take a time to look at diagrams in studio environment, before going to the show. If you know how should diagram looks – you will detect problem quickly.