As part of the Fatum project, we are conducting an experiment to create a stable Psi source that could have a uniform effect on the RNG, which would facilitate the testing of bias amplification algorithms. PEAR experiments are known, where it was stated that plants are able to generate Psi. There, the RNG controlled the direction of the lamp and the plants influenced it to make the lamp shine on them.
In our device, a suspension of Chlorella was taken as a plant component, since it grows rapidly and is the most unpretentious. Instead of a moving lamp, an interface has been developed on phytodiodes, the brightness of which is regulated in proportion to the accumulated deviation in the RNG.
Thus, the higher the deviation, the brighter the phytolamps shine. If the experiment shows a positive result, it will be possible to integrate the tested algorithm into the circuit and adjust the brightness of the lamps not by the deviation in the RNG itself, but by the deviation in the statistics of the result hitting the target value in the presence of the tested bias-amplifier. Thus, the test-site will be affected not by the operator, but by the Chlorella tank.
I think this is great. Looking forward to seeing how the experiment goes. Thanks for sharing 00.
Your experimental design is interesting and creative. Good luck with your testing!
How does your experiment go?
We haven’t started it yet.
Algae is loaded into a setup
video:
May I suggest that you very slowly decrease the brightness of the lights, independent of the RNG output, to prevent reaching a “saturation” level that requires no additional effects from the algae.
Accumulated deviation is being reset once in a minute. And brightness is calculated from z-score of it. Also i found, that PQ128MS overheated after 5 hours somehow and was giving zeros only until restarted.
Currently i have a repeating 1 minute loop where a 80000 bits are requested every second and deviation is added to accumulated deviation. Brightness of lamps is calculated as B = Abs((((acc_dev)/Sqrt(totalbits))/4)*255), so z-score = 4 or -4 gives maximum brightness. Loop reset is done to prevent needed amount of bits to flip from becoming too high for algae to influence.
These generators have multiple levels of continuous internal hardware testing that immediately halts the generator output (within microseconds) if two of the three redundant internal hardware generators fail, though not one has failed in 10 years of testing and customer use. In addition, these generators have been tested up to 80 deg. C without disturbing their operation, and they have been tested continuously for more than 6 months at a time.
It’s extremely improbable that all 3 internal generators failed completely and the four continuous hardware testers also failed, and with such massive failure, the hardware continued to be able to send any kind of output. I don’t say it’s impossible, but I would look elsewhere for a more probable cause first.
You might consider running the generator using the QNG meter. If you see the same type of failure (would show up in less than a second), then a hardware failure could be the cause.
When i found it returning zeros, the device was extremely hot and it smelled rubber from somewhere. I stopped the experiment and started QNGMeter. It reanimated the device somehow, it cooled down immediately and worked fine after that. The problem also can be partly in software though, since i have multiple usb devices working with ftd2xx.dll including lamps, but first 5 hours i havent seen any conflicts between them.
The software may also be the cause. I use meterfeeder.dll and it works only if i run QNGMeter at least one time before starting it.
There shouldn’t be any interference between the RNG and other ftdi interface devices, provided you are using the full driver dll from the Downloads page on CoreInvention.com. The RNG driver dll includes handshaking that recognizes the RNG hardware, and you can use multiple RNGs on one computer, though Linux always had some difficulty with multiple ftdi devices.
One issue that could come up is the current driving capability of your USB interface. Almost no USB cards (or built in connections) provide as much current as is specified in the USB standard. The PQ128MS draws almost 200mA, above the current capability of many common USB connections on standard computers, and especially laptops. If you are driving other devices from the USB voltage, perhaps you are overloading the total USB driving capability.
Try using the high-current USB connection on your computer for the RNG, if it has one. Otherwise a powered (high-speed) USB hub with full current capability (2A for 4 connections) may be necessary.
Ok, good news is that rubber smell was not from RNG but from lamps wires, because they were heating when set to maximum brightness for a long time. I use drivers that were installed with QNGMeter and MeTrainer and work through Simon’s meterfeeder.dll on Windows10. I think its most probably an FTDI problem, because i also had several issues of DMX controller hanging and being stuck until unplugged and connected back. And i use different types of usb ports (usb and usb3.0) for them, because if i plug them into similar ones, one of the devices stops working very soon.
Given the total number of bits used in these runs, the z-scores and probabilities can be calculated.
If I understand the plot, z-score = (2 deviation - total bits)/square root (total bits). I see this equation is not quite right when I tried to calculate a real z-score. I’ll have to think about it a little more.
I see you just updated the plot with a probability level. Is that the 5% level – the threshold of statistical significance?
its just Sqrt(N) line. So its like z-score = 1
I calculate z-score as (1s-0s) / Sqrt(total bits)