Unconventional electrolysis

Bruce__H

Currently Central European Time (CET) or UTC+1.

Hopefully this is informative too. After trying to debug why I would get slightly less (about 2-3% overall) "clicks" than the what the Geiger counter displays, I found that the analog pulse output actually appears to not show as many pulses as reported, or at least this is from what I could see by counting them manually on the computer screen.

This is how a pulse usually looks like:

The pulses (which are all positive) usually have a width of 120-150 samples at 192 kHz. I'm simply detecting them by applying a negative bias to the audio signal and counting the zero crossings. Every pulse should add exactly two crossings.

Perhaps the counter uses a different counting method?

In the lengthy debugging session I improved the script to retrieve and log the pulses, which is now in a shareable state. Also posting here for backup purposes.

Attached are a typical .csv log (renamed to .txt), console output showing timestamp, total counts and counts per tick (1 second) in a sort of semi-graphical manner. As the log uses a slightly different format, I'm not using this right now, I'm waiting until current measurements are finished to switch.

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
"""
Created on Sun Oct 28 11:34:37 2018
@author: can

This program reads in fixed chunks from stdout the microphone output through
of the program "arecord", calculates the number of pulses per chunk (typically
one second) and periodically logs it into a csv file.

These operations work as independent processes.

"""

import subprocess
import multiprocessing
import datetime
import audioop
import queue
import time
import csv

def producer(buf):
    '''Operates as a separate process to continuously retrieve streaming
    audio data in chunks and fill a shared buffer.'''
    
    # Open for streaming audio from the microphone. Provide ample buffer time
    command = ['arecord', '--rate=384000', '--format=S16_LE', '--buffer-time=2000000']
 
    # Note: very important: subprocess.popen should have system buffer set, or
    # one set up to a large value)
    record = subprocess.Popen(command, stdout=subprocess.PIPE, bufsize=2000000)
    
    # Skip WAV header: we're only interested in raw data
    record.stdout.read(64)
    
    while True:
        # Fill N seconds of buffer and only then write. The longer the buffer,
        # the less likely we'll lose data due to overheads. If data is lost
        # then it means that there is a problem elsewhere

        data = record.stdout.read(768000+32)
        buf.put_nowait((datetime.datetime.utcnow(), data))
        

def consumer(buf, write_buf):
    '''Operates as a separate process to consume audio data from the shared
    buffer and compute the number of pulses. Multiprocessing.queue objects have
    inherent lcoks and semaphores which inherently make this process to wait
    until more data is available without adding more logic here. The processed
    data is eventually sent to another queue.'''
    
    counter = 0
    
    while True:
        # The wave data is composed of mostly positive pulses of equal amplitude
        # and roughly, but not necessarily equal length. If we apply a negative
        # bias we can compute the number of zero crossings and retrieve the
        # number of pulses with crossings/2. However keep in mind that sometimes
        # a pulse might not terminate or not begin in the current data chunk.
        
        timestamp, data = buf.get()
        data = audioop.bias(data, 2, -2000)
        crossings = audioop.cross(data, 2)
        counter += crossings/2
        
        print(f"{timestamp} | {counter} \t {'#'*int(crossings/2)}")
        write_buf.put((timestamp.isoformat(), counter, crossings/2))


def writer(write_buf, interval):
    '''Periodically logs processed Geiger counter data into a file'''
    
    # Skip the first instance. This could be useful for example if the program
    # inadvertently executed while another is running
    time.sleep(interval)
    
    while True:
        # Fill a local list with the write buffer, stopping when it is emptied
        data = []
        try:
            while True:
                # Do not wait for more data if unavailable, using get_nowait()
                data.append(write_buf.get_nowait())
        except queue.Empty:
            # No more data, nothing left to do.
            pass    
             
        with open('geigerclicks4.csv', 'a', newline='') as csvfile:
            writer = csv.writer(csvfile, quoting=csv.QUOTE_NONE)
            writer.writerows(data)
        
        #print('\bW', end='', flush=True)
        time.sleep(interval)


if __name__ == "__main__":
    buf = multiprocessing.Queue()
    write_buf = multiprocessing.Queue()

    pr = multiprocessing.Process(target=producer, args=(buf,))
    pr.start()

    c = multiprocessing.Process(target=consumer, args=(buf, write_buf))
    c.start()
    
    w = multiprocessing.Process(target=writer, args=(write_buf, 25))
    w.start()

I noticed that the Geiger tube was mounted with the incorrect polarity:

According to this website this causes the tube to operate inefficiently:

http://uvicrec.blogspot.com/20…0-geiger-muller-tube.html

Quote

The tube is clearly marked with a "+" on one of the terminals. But theoretically it should collect charge on either terminal. So what happens if you reverse it?

[...] Overall appears to be less efficient and works under a much narrower range. Presumably GM tubes are optimized for positive voltage though so maybe it could be improved a lot if you intentionally tried to design a negative center GM tube. In any case, the biggest takeaway is that under standard 400 V operation the tube works. This is actually unfortunate as you might not notice you installed it backwards (mechanically possible).

So I tried reversing it and indeed, I'm now getting a significantly higher CPM reading: currently 100+ CPM which is almost twice what I was previously getting. However, are SBM-20 tubes supposed to be this sensitive? I will post an updated graph soon but this will invalidate my long term background readings.

The average more than doubled, actually.

The photo is a bit blurry but shows the tube now mounted with the correct polarity.

Bruce__H

I think some instrumentation might be directional. For example from the file named g15_epead_p1ew_8s_20181025_20181025.csv, from the public directory for the current month:

float P1E_UNCOR_FLUX(record);

P1E_UNCOR_FLUX:description = "Average flux of 2.5 MeV protons from the B detector that faces either East or West depending on the yaw flip of the satellite with no correction applied to remove electron contamination ";

P1E_UNCOR_FLUX:long_label = "protons-1-B (2.5 MeV) flux";

P1E_UNCOR_FLUX:short_label = "p1B fx";

P1E_UNCOR_FLUX:plot_label = "p1B(2.5 MeV)";

P1E_UNCOR_FLUX:lin_log = "log";

P1E_UNCOR_FLUX:units = "p/(cm^2 s sr MeV)";

P1E_UNCOR_FLUX:format = "E10.4";

P1E_UNCOR_FLUX:nominal_min = "1.0000E-03";

P1E_UNCOR_FLUX:nominal_max = "1.0000E+05";

P1E_UNCOR_FLUX:missing_value = "-99999";

However there is no such indication in the X-ray flux files.

On the other hand, I don't know how the orientation of the satellite changes over time.

Perhaps I could try looking if other data better correlates with the observed changes. I just tried plotting the "Average total magnetic field measured by magnetometer-1" from the file g15_magneto_512ms_20181028_20181028.csv (and previous days): without time shift it seems to better align with my data (however here I applied Y scaling+offset to make the plot clearer)

EDIT: attached the Geiger clicks I logged so far, also for backup purposes.

magicsound

I hadn't considered the possibility of selective electroplating; so far I assumed that for the most the layer formed contained partially oxidized iron plus other constituents from the alloy.

If the black layer is allowed to dry completely under mild heating (by joule heating) it eventually turns reddish-brown. I thought this could be due to iron carbonates or red iron oxide forming.

I don't have photos of this occurring, but I have a few which might show such reddish residues on both electrodes. The second one also shows the fine layer formed when current is low.

It might be worth stressing that the gap between both electrodes/plates is typically so short (less than 150-200 micron) that cavitation from the noticeably boiling water (which also produces vibrations that get transmitted through the metal pieces holding them together) probably significantly affects the processes that would normally occur under ordinary conditions.

More than chemical effects could even be occurring: for example some researchers have reported neutron emission from ultrasonic cavitation of iron chloride or nitrate solutions. I have wondered if cavitation from water boiling in a constrained space in the presence of a dispersion of fine particles would produce similar conditions, which is mainly what prompted me getting a Geiger counter in the first place (mostly to check for activation of nearby materials rather than real-time effects).

http://aflb.ensmp.fr/AFLB-342/aflb342m669.pdf

I'd like try with a NaCl water solution at some point, but I would need first equipment to dispose of the HCl and Cl gas that would get produced, among other things. Electrolysis of brine makes the environment smell like bleach or pool and even in limited amounts it irritates the lungs.

magicsound

I sacrificed the coating of a couple samples and attempted the test you suggested. It seems that the powder obtained responds positively to one of the magnets I often used in these tests (EDIT: it's attracted to the magnet). The video unfortunately is rather blurry.

https://streamable.com/0m9ue

Since my steel samples are moderately ferromagnetic I suspect they're made of ferritic stainless steel, which most often contain little to no nickel. Also, since nickel tends to increase alloy costs manufacturers might prefer to avoid using it unless necessary.

https://en.wikipedia.org/wiki/SAE_steel_grades

I tried putting twice for a period of about 10 minutes of time the paper with powder residue from the steel pieces on top of the Geiger tube (à la JohnyFive), and although initially it appeared as if counts slightly increased for a while (also see CPS), it's very difficult to tell whether this wasn't just the oscillation of the background signal coincidentally giving this impression.

EDIT: as a further odd coincidence, it seems there was a short spike in CPS readings when I removed the deposition layer from the steel pieces to obtain the (later found to be ferromagnetic) iron/iron oxide/carbonate powder. I indicated this with a dotted vertical blue line in the graph. This seems to agree with EXIF data from one of the previously posted photos:

Bruce__H

I realize it's clutching at straws, but there was a suggestion of a potential correlation with solar emissions in reported working LENR experiments (e.g. by Russ George et al) and the changes I'm observing so far do not seem to be due to temperature or other usual environmental changes. If LENR can be affected by solar emissions, background radiation probably can too.

RobertBryant

Perhaps by limiting the range studied to low energy gamma radiation it might be possible to use a Geiger tube for that. By lowering the operating voltage, these tubes can be brought to the so-called proportional region where pulse height depends on the energy of the incoming radiation. They might be too slow and have a too low signal SNR for this to be actually useful in practice, but in theory it should work. Unfortunately I do not have yet a suitable serial interface to change the voltage setting in my counter and try this.

Some links:

https://en.wikipedia.org/wiki/Proportional_counter

http://drmichelleboyce.net/cubesats/apctheory/index.html

http://uvicrec.blogspot.com/20…0-geiger-muller-tube.html