Q Light Controller+

Hi everybody,
i have raspberry pi 2b and a pi 3b running with the latest image of QLC+ (20160306) both work very well with QLC+ projects that contain even about 500 channels. My litle problem is a project with 800 channels that i am going to use via SPI which leads to visible "steps"/"jumps" when i fade over between the scenes. My oscilloscope shows that the SPI (at 1MHz) needs 12ms to transmitt all data (thats good) but it only starts the transmition of the data every 115ms. So the refresh rate is only around 10Hz. The cpu usage at this time is only around 5% so it does not seem to be a performance problem of the cpu. Its the same behavior on raspberry pi 2 and 3.
Now i am looking for a possibility to tune QLC+ a little bit

Does anybody now parameters in the sources of QLC+ that influence how often dmx channels are calculated or how often the SPI plugin is executed?
I have found something but i am not shure if it is the right way and if the result will be worth the effort to setup the whole toolchain and to compile QLC+ myself.

In "qlcplus-4.10.3\engine\src\mastertimer.cpp" there ar the two variables "uint MasterTimer:_frequency = 50;" and "uint MasterTimer:_tick = 20;" and a call of "doc->inputOutputMap()->dumpUniverses();" in "MasterTimer::timerTick()".

Does anybody know what influence a varation of these two variables would have on the SPI plugin AND the other parts of QLC+? Maybe there is an easier way to increase the refresh rate? 20Hz would be fine

Best regards!
falken

The SPI plugin can transmit at higher rates (2MHz, 4MHz, etc) so you should try that first.
It has a dedicated thread to send data, but if the SPI line is set at a slow speed, it will keep the transmission call busy for too long and it will loose new data during that time.

Changing the Mastertimer frequency is in general not a good idea

Looking at the SPI plugin source (https://github.com/mcallegari/qlcplus/b ... thread.cpp)

- writeData() computes m_estimatedSleepTime which is used to adjust sleep time in run(). There is hard coded assumption that 512 bytes at 1Mhz takes ~80ms, which is translated to 70 ms wait time after data is sent to spi device.
this formula gives for 800 channels something around 109 ms wait time, which is quite close to your observation.
- if your 12ms is about right, replace double(70000) with double(7680).

massimo: line 106: usleep(m_estimatedSleepTime - nMilliseconds); should read usleep(m_estimatedSleepTime - nMilliseconds * 1000);
it may be useful to use some better counter than QTime for which they do not claim even ms precision...

janosvitok wrote:There is hard coded assumption that 512 bytes at 1Mhz takes ~80ms, which is translated to 70 ms wait time after data is sent to spi device.

I think it was hardcoded after reading some real tests done by the OLA guys. See here: http://opendmx.net/index.php/OLA_LED_Pixels

janosvitok wrote:massimo: line 106: usleep(m_estimatedSleepTime - nMilliseconds); should read usleep(m_estimatedSleepTime - nMilliseconds * 1000);
it may be useful to use some better counter than QTime for which they do not claim even ms precision...

Ouch. usleep is definitely in microseconds...
I need to fix the line speed setting anyway, and soon I'll start testing SPI on the new Jessie-based RPi image, so I'll fix it all. Thanks for spotting

Note: I know almost nothing about SPI.

Hey thanks a lot for the detailed responses!
In my opinion the waittime is a very good parameter to to increase the refresh rate. I will try that at the weekend (if i get it compiled). I am more specialised in mikrocontrollers so i know how the SPI works but until now nothing about how to use it under linux or how to compile a porject like QLC+. May be i can help a little bit to test the SPI massimo

I know the post of the OLA guys but i dont understand how they came to these results. My measurement shows that it is much faster (12ms) and if i calculate it manually 800Bytes at 1MHz SPI speed could theoretically be transmitted in 6,4ms.
For calculation i used teh periodic time of the spi clock that is 0,001ms at 1MHz. So 0,001ms x 8bit x 800byte = 6,4ms. In the screenshot the yellow graph shows state of the chip enable of raspberrys SPI. Data is transmitted when this pin is low.
Changing the SPI speed in the GUI or Webinterface is not possible in the actual image 20160306 (see: viewtopic.php?f=7&t=9643). I havent found the errot yet.

falken wrote:Changing the SPI speed in the GUI or Webinterface is not possible in the actual image 20160306 (see: viewtopic.php?f=7&t=9643). I havent found the errot yet.

Not true.
When you change the speed from the plugin configuration dialog, it is actually applied.
The issue is that when you re-open the dialog, it always displays 1MHz instead of the correct frequency

hm... i retested it and i observed the following behavior. The default setting of 1MHz in the configuration produces a frequency of 625kHz (in the screenshots den yellow line is the clk pin of raspberrys spi when data is transmitted). When i change the setting in the configuration dialog to 2, 4 or 8 MHz and click "ok" the frequency changes to 1Mhz for one or two seconds and then changes back to 625kHz. When i reopen the dialog i see a setting of 1Mhz no matter what i set befor. The strange thing is that the frequnecy changes again to 1Mhz for on or two seconds and then changes back to 625kHz.

Again, there was an issue with the configuration dialog, which I fixed earlier today.

Try this BEFORE enabling the SPI line:
- open config
- set 2MHZ and hit OK
- enable the SPI line

It has to work.
In any case, I reworked a few things of the SPI plugin and I am about to enter the test phase of a new RPi image, so I will test the SPI as well.
I hope to be able to provide a test image in the next few days

Ah you mean you fixed it in the sources. I was stil using the official image because i did not get it compiled yet. i am still working on it...

Hi!
Long time but finally i made it! I crosscompiled QLC+ myself and have it running on Raspberry Pi3 with a Jessie Image. For reasons you can read at the beginning of that thread I changed a timing constant in the source of the SPI plugin and it is running perfekt
But two days later Massimo released his latest offial QLCplus image (20160529). It works (nearly (i have some problems with the gpio plugin that i will write in another thread) perfekt too. I prefer to use the official image but i want to have my "tuned" spi plugin so i tried to exchange the libspi.so which is located in /usr/lib/qt4/plugins/qlcplus/. It works fine! I atached it to this post if somebody wants to use it. The only difference to the original lib is the changed constant for the wait time. I replaced 70000 by 20000 in https://github.com/mcallegari/qlcplus/b ... thread.cpp . Maybe massimo will adopt it in future releases...
Here two screenshots to demonstrate the increased refresh rate of the data output via spi. The yellow line is the CE line of the SPI. SPI is transmitting while this line is low. At my 800 Channels the refresh rate increased from about 8Hz to 33Hz.

By the way massimo was right. The SPI plugin (even the official one since 20160529) now also works fine at speeds of 2, 4 and 8 MHz! With my "tuned" spi plugin 1Mhz is fast enough for me because the wait time wastes more time than a higher spi clock speed can reach.