Nice work getting a Python implementation done!
Can you give me access to mmi repo?
I haven’t finished sorting all the ME Trainer and related files so I haven’t yet created a repo sorry.
Please note, there is some indication that PRDCore3.3 may not be fully functional. I recommend only using PRDCore3.0, which I know works.
I just added METrainer Instruction.pdf to Google Drive.
1 Like
I have created the following repositories and uploaded the files provided by Scott.
https://github.com/vfp2/METrainer
https://github.com/vfp2/PrdCore
https://github.com/vfp2/PCQNG
For now they are private but already have the correct LICENSE file.
A few notes;
- PrdCore is setup as a submodule in METrainer/Libraries/PrdCore
- PrdCore 3.3 is available on branch feature/3.3
- Do we also want to put libqwqng’s source/files on a repo?
- All the projects/files are just added as-was received. The instructions I wrote a while back at the top of this thread to get the METrainer project running haven’t been applied yet. Once it’s working and the projects are configured to run/build okay, then I think we can consider making the repos public instead of private.
Next step after that would be to hook up medfarm to the list of devices to choose from.
@Simurgh - I’ve added you to the 3 repos for now.
thanks.
I must admit, that C++ is harder, than I thought. Can someone compile MeT for linux, or advice, how to do it?
@Simurgh You want to run METrainer on Linux?
The FLTK (Fastlight Tookkit) that the original developers used for the GUI does seem to have cross-platform support, but from what I know the PsiTrainer/METrainer has only ever been built and run on Windows. I’m a polygot (of human languages) and avid supporter of having apps being able to run on as many platforms as possible so we could quite possibly get it running on Linux, and also Mac too. I can’t say where to start right now without looking into it myself, but I’d like to aim for that one day.
For now I’ve at least made MeterFeeder (a library to use MED devices) available on Windows, Linux and Mac. An Android version is available on a branch but not working fully.
added to Google Drive:
QWQNG seems to be the interface program for hardware, such as ComScire RNGs and MED100K as well.
PCQNG is the software-enabled TRNG that runs on Windows PCs.
That explain why I failed to run it.
I hope, you’ll manage to add cross-platform support to MeT.
Except Mac support. Apple is evil. So, people, who believe Apple shouldn’t have nice things.
I managed to build successfully(x64/86) using the modules below
CDM v2.12.36.4
PrdCore 3.0
QWPCQNG RC2
fltk-1.3.7
It’s only producing the attached error message when attaching the hardware, otherwise, it seems all fine.
What could be the reason behind it?
@cmeza-dev I see you’re new to the forum. Welcome! Do we happen to know each other from outside of here (I’m Simon/soliax) or did you come across this place from some other means?
It’s great connecting with you @WanderingIshiki
I am Christian, senior fullstack developer from Vegas, Nevada. I just happened to know Metrainer, it looks great. Great work so far!
I hope that with my work I can contribute to the effort of improving MEtrainer
Nice to meet you Christian and once again welcome. Looking forward to anything you can contribute here. Hopefully I’ll be getting the ME Trainer and related repos sorted soon properly to make them public.
I’ve made a new repo for this here:
I suspect the part of the software that connects to the hardware does not recognize the newer MED100K devices. The original hardware from about 10 years ago included the ComScire J1000KU, with serial numbers QWR1xxxx, as well as several MMI devices of the time – not sure what their serial numbers were. The MED100Kxx and PQ4000KM have serial numbers QWR4xxxx. I believe the software recognizes compatible hardware by checking the first 4 digits of the serial number. This would have been patched in the METrainer2020 version.
There must also be a table in the interface software (PRDCore.dll or QWQNG that’s probably part of the PRDCore) that matches the type of hardware with its output bit rate. The J1000KU was 1Mpbs and the MED100K is 100Kbps. The MMI generators had a variety of generation rates. Also to note again, the J1000KU rate of 1Mbps was only effectivley 875,000bps since the original MMI generators produced both a bias and an autocorrelation output stream at the same average rate, and the MSB of every output word indicated the type of output data contained in that word (Bias or AC).
1 Like
Looking over the source code it looks like METrainer was calling PrdCore which would interact directly using the FTDI driver if the device was a QWR1* device, otherwise if it was a QWR4* device it would for some reason interact with the hardware via QWQNG.dll. I haven’t even gone deep yet so my understanding of the whole is still shallow, but it seems this extra layer of DLL interfacing incurs extra buffering that could be avoided.
My C++/Windows development knowledge is rather limited so I’m still trying to figure whether it’s better to spend time in getting the current code working as is or leaving PrdCore for just the PCQNG and replacing any MED-related code with MeterFeeder.
The QWR4 type devices didn’t exist when the PRDCore was written, so there was some hack recently to make the MED100Kxx MMI generators connect to the METrainer. I expect the PrdCore has some advanced processing (neural networks), at least for the PCQNG, but also some processing for the old MMI generators and the J1000KU RNG (those are obsolete and not available).
Since the PrdCore was meant to be the primary interface tool, it would be best, if possible, to find a way to modify that code so it works with the newer hardware. There is the MED100Kxx MMI generator and another two more advanced versions that will be available. I’m not quite ready to release those yet. I have to set up a lot of equipment just to program the hardware I have on hand.
Ok, I’ll work on getting PrdCore to work with the QWR4 hardware.
I assume QWR4 interface is already implemented in prdCore3.0
Prdcore3.0/ FtdiRng.cpp
unsigned __stdcall FtdiRng::RunnerQWR4(void* self)
I am not sure why it’s getting crashed when attaching the hardware.