Advice on approach please

Mind Matter Interaction
1

I’m in the early stages of creating mobile apps for iOS and Android. Among other things, I plan for it to have the ability to allow users to perform psi trials. Users can attempt to influence random numbers during a discrete time window, during which probability is calculated in real-time and they are provided real-time feedback, probably something like a spinning cube, changing audios signals, and maybe a bar chart with variable fill level - just like I created in the code I shared awhile back - example (but note that this example is two-tailed not one-tailed). I imagine also gamifying this through the use of a global leaderboard where users can see how their results compare to others.

I’m working through the technical aspects of this. Of course, I need access to some truly random numbers and requiring users to have a physical device is not feasible. My initial thought entailed using the API provided by Australian National University Quantum Numbers (AQN). The random numbers are generated in real-time in their lab by measuring the quantum fluctuations of the vacuum and then made available via API. For example you can pull request 5 random numbers between 0-65535 by calling this endpoint:

https://api.quantumnumbers.anu.edu.au?length=5&type=uint16

Initial desire was to do 20 minute sessions, pulling a new set of numbers once per second. The instructions would be for the user to attempt to generate more even numbers than odd numbers. The numbers pulled each second would then be simply evaluated to see if a given set contained more evens than odds (the degree to which there were more would not be considered). These cumulative results are then fed into a simple one-tailed binomial test to produce a probability value, which is what’s fed back to the user for real-time feedback and also used in overall score evaluation.

Technically speaking, 100% doable and actually not that complicated. The core problem, however, comes in the fact that AQM API calls cost $0.005 each. So for what I described above it would come to $6 per trial, which is way too high. I would expect to charge for this app in some manner, maybe a small monthly subscription fee that covered all app functions, not just the psi part. But racking up $6 per trial, with people doing one or more possibly more than one trials per day would be too expensive.

I’ve contacted them about custom pricing, but haven’t heard back.

  • What if I did only 5 or 10 minute trials, and pulled numbers only every 5 seconds? Is it enough to get meaningful data?

  • Is there a better way for me to be generating numbers in a cheaper way? I’m of course aware of the MED Farm that @WanderingIshiki runs, but in its current state I think it’s lacking some important features around security, concurrency, and scale. Also, I’m aware that Scott has not approved either his devices or algorithms for commercial use, which, even though this app is being built and delivered by a non-profit organization that I run, and is aimed primarily at covering the costs of running the app, it would still be charging users money.

  • Is there a better algorithm to be using than the one-tailed binomial test I described?

  • Any thoughts on the influencability of the AQN API? In my own limited previous trials I found difficulty in influencing these numbers with psi, and seem to recall anecdotal reports of others facing the same challenges. Is this a viable random number source to be using?

@ScottWilber @WanderingIshiki @nplonka , whoever else - would love to hear your thoughts on this.

Perhaps not directly related, but I also like the idea of later doing data analysis on this psi data, looking for correlations with people who have the most successful outcomes. Do they correspond to certain geographic locations, certain solar / geomagnetic conditions, or perhaps certain demographic details (that the user can optionally provide)? That’s for later, but could be some interesting possibilities there.

2

You could develop your own MMI server system. I have a large number of MMI generators, and I believe we can come to a simple and equitable agreement for their use, as well as a license for the IP. You may be able to work with @WanderingIshiki to beef up his setup or develop a super server system by collaborating. I would be happy to support any reasonable option.

I am developing other algorithms for use with my new A.C.E. system. I will share when I have had a chance to test them. Otherwise, the advanced processing methods I described are the best I know of. Multiple advanced methods can be used to process the same data to achieve slightly better results, but this raises the computational overhead.

The people at ANU running the random generator system told me, 1) their numbers have been deterministically post-processed and, 2) they cannot be sure the numbers are current or “real-time”. These are two issues that can decrease the responsivity of an MMI system. More importantly, generators that output bits without some type of bias amplification are vastly more difficult to get significant results with. (note, we now have substantial test data from many subjects showing the high bitrate bias-amplified data is significantly more responsive) There is no practical way to stream raw bits (words) and apply bias amplification algorithms at the user location. The MED100Kx8 generates 1.024 Gbps and the bias amplification algo brings this down to 100Kbps – a 10,000:1 reduction in data rate. Preprocessing at the generator location with attention to latency (in this context, latency is the time between data generation and the result of using the data being displayed for user feedback) seems to be the reasonable approach. At some point, special MMI chips may be included in many devices, but that’s a while away.

3

Your post reminds me a lot of the early days of Randonautica dev which led to one of the members finding Scott and the starting of this forum. It’s really exciting to see your interest and passion in designing and developing what you’ve outlined.

ANU was the original QRNG source for The Fatum Project which a lot of it was about the kind of psi experiments you mention, then also it was used by Randonautica back when it was all free (but now they use one of Scott’s devices I believe). The fact that ANU now charge for it and that it has the deterministic post-processing, wouldn’t make it the best source for what you’re attempting now. And like you mention, the MED Farm I’m running is really just at a hobby-level with no security or concurrency or scale built into it.

I’ve been slowly working on a enterprise-level RaaS (randomness as a service) business which I’ve talked briefly with Scott about. It’s main intent is not for MMI use-cases (but more enterprise focused) but if I do figure out a more stable (other than just having an old computer at home plugged in) way of hosting the RNGs, I want to consider having devices/infra set up for experimenting. No promises as to when this will be ready sorry, but I’d be glad to let you use that (if and when that day comes;-))

A few years ago I did start working on an Android/Java driver so you could plug a MED right into your phone. I got some basic I/O going but it was buggy and the input stream wasn’t working well. If you’re interested I can try and find the code.

Meanwhile if you have any technical questions, MMI or not, even just app development questions, feel free to fire away on this board. There’s a lot of super talented people on this forum.

Good luck!

4

Thank you both for the responses. @WanderingIshiki any way to expedite this effort, or do something slightly different, that I could use soon? What about improving the MED Farm? I can compensate for your time.

5

I have a few MMI generators with internal bias amplification and an output rate of 1Mbps. A number of 128Mbps generators without internal bias amplification and no deterministic postprocessing are also available (note, none of my generators use deterministic postprocessing, except the crypto generator, which I would not use for MMI work).

6

Having your psi tester available as an app would be great

1 Like
7

What does it mean to have internal bias amplification? And wouldn’t I want slower generation rate rather than faster? I know when using the med100kx8 device it was a struggle to get code going fast enough to use all the bits - what’s the generation rate of that device?

What if I created a farm of more available RNGs, like the TruRNG3 (even though it generates all kinds of characters, not just numeric, could convert to binary)? I would like to have at least 10 running in parallel with the ability to increase as needed, though I doubt I’d ever need to exceed 100.

8

I’m a bit too tied up with my other jobs and projects sorry to be devoting time to the med farm.

9

What I mean by “internal bias amplification” is, the hardware that generates the random numbers also performs bias amplification before anything is output for use. The MED100Kx8 (100Kbps output rate) generates random bits at 1.024Gbps, which is bias amplified by a factor of 101, bringing the output rate to 100.382 Kbps (1.024Gb/101^2).

There are only a few currently known factors that significantly affect the responsivity (measured in effect size) of A.C.E. or MMI systems: 1) the larger the number of bits or samples used to calculate results, the higher the responsivity. The increase is generally proportional to the square root of the number of samples used, compared to a single sample; 2) the greater the quantumness, that is, the degree the measurement of the entropy source is determined by quantum mechanics, the more responsive the system; 3) efficient processing algorithms, meaning those that best increase the signal-to-noise ratio of the signal of interest, are essential. In this case, minimizing computational overhead may also be part of the “efficiency;” 4) user feedback that is engaging, informative (communicates results clearly, easily and rapidly) and preferably in real time, is essential.

The readily available RNGs were not designed with MMI in mind, nor were their designs based on a deep understanding of random number generation and randomness. 100 TruRNG3s have an aggregate generation rate of 40Mbps, only 4% of a single MED100Kx8. In the same measurement period, compared to all 100 generators producing an output, one MED100Kx8 would provide results with about 5 times higher effect size.

The RNG interface software on the CoreInvention website (https://coreinvention.com/wp-content/uploads/2022/08/qng360_setup.zip) can input data at up to 128Mbps. The MED100Kx8, and all my past generators, should be compatible with that interface. In any case, it’s possible to input data at very high rates.

10

Thanks Scott, very useful. It certainly sounds like using MED100Kx8 devices is superior to using TruRNG3 devices. What’s the max number of MED100Kx8 devices you could make available to me (as you mentioned, happy to come to some licensing agreement here)?

Also, in the text below, these are NOT MED100Kx8 devices, right? Sounds like the output rate of 1Mbps is higher than the MED100Kx8. Is the MED100Kx8 ultimately the best option for what I’m trying to do?

“I have a few MMI generators with internal bias amplification and an output rate of 1Mbps. A number of 128Mbps generators without internal bias amplification and no deterministic postprocessing are also available”

Perhaps an additional option would be for me to use the devices currently allocated to the MED Farm, as they don’t seem to be actually getting used by anyone. So, I’m suggesting hosting these somewhere else and building out more infrastructure around them. I’d ideally like to have more devices than just the seven allocated there, but at minimum I think that could suffice. (@WanderingIshiki - something you’re open to if needed? …basically shuddering the MED Farm and re-allocating these devices…)

11

I wouldn’t want to see the MED Farm shut down, even if it’s not currently being used as much as it could. People can come back around for a spurt of development when they have time, or if the tech – and interest – heats up significantly.

I made 5 of MED100KQ16 and 4 of MED1MQ16, both are in small desktop enclosures like the PQ4000KS RNG. Both have internal generation rate of 2.048Gbps. The MED100KQ16 has bias amplification of 143 (42% higher than the MED100Kx8, with output rate 100.152Kbps) and the MED1MQ16 has bias amplification of 45 (55% lower than the MED100Kx8, with output rate 1.01136Mbps). I made the 1M devices if a higher output rate is better for the app, and the 100K devices because the 2.048Gbps is the highest generation rate (hence the most responsive) that fits in already existing hardware without significant firmware reprogramming.

I have many MED100Kx8 generators, and I can make available as many as would be in active use. I think the first step is to make sure you can use the RNG interface software so interfacing is not a problem. However, there may be an issue connecting more than one device via that software. I believe it’s possible to adapt it because many instances of the RNGMeter can be simultaneously opened to test many generators, as many as the computer’s speed can handle. A balance of all factors suggests one 1Mbps MMI generator (MED1MQ16) may be the basis of a prototype system, but an MED100Kx8 could be used to build and test the design.

Simple computers are available for $150, or much less for barebones versions. Example: Robot or human?. A network of these computers could be used, each supporting a single generator. This would be easily and incrementally extendable as needed.

12

Thanks Scott, this is sounding promising, though it will be a big investment for me to create, stand up, and maintain the infrastructure for hosting the devices. I should be able to manage that.

It sounds like using MED100Kx8 generators is the way to go, and I think starting with 10 would be more than sufficient. I would not intend to use any of the CoreInvention software. Instead I would largely leverage the Python code I’ve created to interact directly with the devices without the use of drivers. In broad strokes, I’d envision the use of a beefy host-machine with RNGs connected via USB-hub. Each RNG is managed in an individual Docker container running on the host machine, with each Docker instance running my Python code, and the cluster of containers managed by Kubernetes. Authentication is done via OAuth 2.0 or JWT (JSON Web Tokens). WebSocket Secure (WSS) is used to securely stream data between a Docker instance and a user’s mobile app. Would also need to manage tokens, sessions, and implement middleware (such as passport.js or Django’s authentication system) in the server application that checks for valid authentication tokens in each request.

That’s how I’m thinking about it.

13

Hi Dan,
I can send you two MED100Kx8, which is enough to build your system and see how everything works. Plus, you already have one, which would allow you to test with three simultaneously. I just need you to PM me your address, which has disappeared in the mountain of papers in my office.

I should mention, I spent about a year and huge amount of cash building an ultra sophisticated online MMI system (on MindEnabled.com) with several apps and testing algorithms, history/progress tracking, leader board, forum, etc. Although it was capable of supporting up to 1000 simultaneous users, I doubt that there was ever more than one online at once. From this I learned it’s wise to start small and build up as actually needed. At the same time, it’s a good idea to design a system that can be expanded incrementally.

For best performance, each user should be granted exclusive access to a single MMI generator. That avoids any issues with multiple users working at odds with the same physical generator, and it also provides sufficient generating power to allow several different processing methods. On the other hand, a single 1Mbps generator could support multiple users, and allow testing even more advanced processing methods. There are pros and cons either way, but in principle, I agree with your multiple MED100Kx8 generators suggestion.