MFMP: Automated experiment with Ni-LiAlH

    can,

    Very cool plot. You can see that visually the residual (spectrum with average subtracted) looks pretty zero mean. You will see the RMS noise increase where the raw signal is higher because the noise is proportional to sqrt(measurement). Thus, you will see the amplitude of the zero mean noise increase where there were higher measured values, like at the 137Cs line and the 40K line, and of course in the high counts at lower energy from Compton scattering.


    If there is a signal in any of the raw plots, looking at the calibrated plot with the average (median combination better) subtracted is the best way to see a real signal and it will show in its real spectrum. I have some ideas for doing deconvolution to remove the wide bandwidth of the NaI detection (6-7% FWHM) and its corresponding Compton scattering.


    Thanks very much for the Python tips.

    The generally used package stack is, as Murray says in the excerpt above, Python + iPython/Jupyter + SciPy + NumPy + Pandas + Matplotlib. They're all listed on the main scipy.org home page.


    And here's a list of Python distributions bundled with them https://scipy.org/install.html


    I personally first learned about Pandas when I needed something to read a large amount of .csv files efficiently.


    BobHiggins

    Thanks for your tips so far.

    Unrelated, but I noticed you still need to add information in the shared folder on how to decode certain columns in the .csv files.

    Not strictly related with the experiment, but by using a Java decompiler called JD-GUI I discovered that the code of the MCA Software from Spectrum Techniques is visible. I've found the function that read .spu binary files. This should in principle allow to create code in other languages (e.g. Python) that can read binary .spu files directly exactly like this program does.




    can,

    That's really cool. I would be interested in hearing more about that, particularly if you develop a function for reading that file. I have not heard anything from Spectrum Techniques about the bug I reported that you noted in the time stamp. I am going to have to call them.

    BobHiggins

    I was already reading files from binary .spu files, but in a sort of reverse-engineered way that wasn't very good. I hope to be able to correct that.

    Being able to read directly from binary files is better and faster than processing ASCII text, so do keep saving spectra in that format.

    Thanks for contacting them for the bug(s) (there's also the filename one, which is not really a bug but it's annoying).


    Hopefully if they'll correct the bug(s) they won't change the file format and/or obfuscate the program code.

    BobHiggins

    Basically I'm done with the binary .spu reading script and now I can read all attributes that the USX software outputs, but it's still a work in progress (for example, no calibration is performed even when calibration coefficients are present). Below is a debug output of values read from GammaSpec_PreStartWarmup.spu (channel:count values omitted) with it. After comparing these values to those from the log of the USX program - which only shows when the program is directly started from its .jar file from the command prompt - they all appear to be correct; some calculations will have to be done to obtain the real/actual ones displayed in the GUI. However, the most important data such as channels, counts, start/end time and live/real time don't need any further processing.


    can,

    I have gotten a first response from Spectrum Techniques. They only answered 1 question, whether it is possible in the multi- spectrum sequence to change the date format to 24 hour mode and he replied "no" to that. I pointed out that without at least the time stamp in 24 hour mode or adding the AM/PM indicator that the timestamp is wrong. In fact if one of these 5000s integrations starts at 11:50 AM, the end time for it will seem to be before the start time. I re-asked for the bug repairs, and I also asked for the data format specification for the .spu files.


    Unfortunately, from your decoding above in this thread, it looks like the .spu files are being timestamped with the same bug.

    BobHiggins

    I don't know the context but from what you're writing it seems they misunderstood the question and thought you asked them if the date format can be changed by the user within the USX program. I don't recall seeing that either.


    The problem is that program saves the date in the .spu in an incorrect format, and since it's in plain text and not for example a value representing the seconds from a given date, it cannot really be fixed upon loading with a script.


    But I actually found the bug for them.


    In the class ActionControl.class in MCA_Stand_Alone.jar there is a function called getTime which builds a date-time string. They write:


    Code
    if (format_type == 2) {
        formatter = new SimpleDateFormat("MMMM dd, yyyy, hh:mm:ss");


    The problem is here:

    Code
    MMMM dd, yyyy, hh:mm:ss


    Putting aside the fact that they could very easily make it in ISO 8601 format, the way they build the string formatter leaves the am/pm indicator out, according to the Java API documentation here:


    https://docs.oracle.com/javase…ext/SimpleDateFormat.html

    can,

    Yes, that was one of the questions I asked them - whether there was an option to have it stored in 24 hour format and they said no. They didn't answer the other questions, so I sent another email asking in more explicit detail. After I read what you said above, I copied out the part beginning at "In the class..." and emailed that to them as well.


    But it strikes me ... :) if you can de-compile like this, can you just fix their code and re-compile?

    BobHiggins

    It can be likely done, but I don't currently know how to do it, I'm not a Java expert and haven't studied the subject. Furthermore, it's not even clear if the code was actually supposed to be publicly readable and subsequently redistributable in a modified form.

    Quote from BobHiggins

    can,

    Which version of their USX code have you installed and are examining?


    The version is 1.2.00B USB (released June 19th, 2014).


    By the way, if was curious and I checked. The task of re-compiling from disassembled code doesn't look to be easy; either the disassembler doesn't do a proper job or the code is weird, and I don't know enough Java programming to fix it properly.


    I'm confident that the date issue highlighted above is real and fixable by Spectrum Techniques, however (along with other ones).

    Quote from can

    The version is 1.2.00B USB (released June 19th, 2014).


    By the way, if was curious and I checked. The task of re-compiling from disassembled code doesn't look to be easy;


    I was able to hack the binary to change the time format to 24-hour. I also changed the version number to 1.2.24H. Download the file here:

    https://drive.google.com/open?…xJkjesxe4kUl9INklBbzNiREU


    Rename the original file for backup, then put this one in its place. Let me know if this substitution works - if not, I will post the entire folder.

Subscribe to our newsletter

It's sent once a month, you can unsubscribe at anytime!

View archive of previous newsletters

* indicates required

Your email address will be used to send you email newsletters only. See our Privacy Policy for more information.

Our Partners

Supporting researchers for over 20 years
Want to Advertise or Sponsor LENR Forum?
CLICK HERE to contact us.