Okay, runs on my win7 computer. Tried reset and start/stop as well as the counts of 1s button. All seem to work. Not sure what the two modes of counts of 1s means. The MED serial number is displayed in the lower left corner.
I also ran it on a win10 machine. Of course microsoft “defender” tries to block it several different ways and report my activities to their headquarters, but I got it to work anyway.
Thanks for checking. I’ll go ahead and make the changes. I can’t remember myself what Ones Count is. I need to see what I was doing there…
Lol on Windows 10…
@ScottWilber
I’d like to get some clarification on the above requirements.
Assuming for the moment we’re doing a single trial, continuous that the user presses start and then stop to do the trial run. We have 2 MEDs connected.
Is that understanding correct?
It’s not possible to do a proper comparison with a single trial and the best comparisons are made with a number of trials of a fraction of a second initiated by a keypress or mouse click.
If you are determined to use continuous mode, the active generator is still chosen at random without the user knowing which generator is active. When the user ends that trial, only the results from the active generator are displayed – without revealing which generator was active. Then another like trial (with another random selection of the active generator) is initiated and ended by the user, and so on until a sufficient number of trials have been accumulated. The data displayed during the whole series of trials is from the active generator, which means it is a composite of the data from both generators while they were active.
Only when the series – a number of separate trials – is finished does the data for each of the generators get compiled separately and displayed with the identity of each labeled. The data from the inactive generator can be saved, but it is not really used in the comparison. It can be useful to also display the separate inactive generator results after the series is finished, but only to show that the results for each inactive generator are not as good as for the active generators which were used to provide user feedback.
Thank you.
This is just an initial mockup of the UI I’m thinking about.
Any questions/suggestions on this approach?
Sorry, I always try to respond to every post I have information about – I guess I overlooked this one.
The organization is improved but it’s hard to say much since real comparison testing is so dynamic. The single most important point when comparing two generators is that the user cannot know which one is the active one. That is, until the series of trials is completed. For continuous testing the same applies. There should be only one plot displayed during the trials (or series of trials for continuous mode) that is composed of points from both generators alternately selected at random for each trial while the test is ongoing. When the user decides (or when reaching a pre-selected number of trials) to end the series, the results from each of the two generators is then assembled and displayed as two separate plots, as you show in your message (but, only the points from each generator when it was the active generator are used to produce these plots and produce the statistical results for the two separate generators – see additional clarifications below). There should be two basic modes: Test and user feedback results (one plot composed of randomly selected results, only from the active generator) and Comparison results (two plots composed of all the active results from each of the two generators) Note, the active generator is the one that is used to provide the user feedback point in the plot and the accumulated statistical results in Test mode. To be very clear, there is only one active generator at a time: only a single trial result (from one of the generators) is displayed or added to the display at a time.
The reason for this bit of extra housekeeping is because the best results are always achieved from the generator that produces the output used to give real-time user feedback. If both results are displayed, the user will choose one or the other, or switch back and forth, to focus intention. This will never give an unbiased comparison of two entropy sources/processing methods. This conclusion is based on thousands of test series trying to decide which of two generators is working better.
Realizing that the effect of user feedback was overwhelming any attempted comparison, I designed a method to allow truly independent comparisons. If one generator/processing method were 10 times as large as the other, it might be enough to work with both results displayed at the same time. However, there is never that much difference between two concurrently available technologies. Usually it is more like 50% more or less, which requires special care to determine.
Thank you. I’ll work on the above.
I am working on both better processing methods and more responsive generator types. A colleague and I are working on an MMI generator comparison tool, but we cannot get multiple generators connected on the same computer.
Could you please point out your best code for connecting to multiple MED100Kxx generators. That would be a great help, thanks.
Great to hear. I must apologize that I’ve hardly had any progress on this particular project for a long time…
The source code of the simplest implementation (in C++) of the MeterFeeder C++ library is here: MeterFeeder/meterfeeder.cpp at master · vfp2/MeterFeeder · GitHub
This is also the repository where the source code for the library itself resides.
You can find pre-compiled executable binaries (also along with library binaries as well) for Mac, Linux and Windows here:
An abandoned Python implementation (called Parking Warden) with graphed output is here:
(I abandoned it because the graph rendering in Python was horrendously slow).
On-and-off for the past year or so I’ve been working on C#/Unity implementation (also called Parking Warden), example here:
All it’s really capable of doing at the moment is displaying output from any connected MED in realtime, along with a PRNG for “comparison”. None of the discussions like user-initiated mode with active generator been made unknown to the user etc. have been implemented yet. “Output” was the latest thing I was working a few months ago and that was to graph the cumulative z-score from each device. (I don’t think the Random Walk/Ones Count toggle button does anything at the moment).
Related source code code:
Thank you so much. My friend, who is a skilled programmer, got the code compiled and taking data from two generators. I’ll let you know when we have a full-blown comparison application. This application can also be used to compare data processing methods to see which is better.
That’s great to hear. Can’t wait to try out the application.
