Live Video Feed from MFMP, Feb 5th — Experiments Planned [Update #2: Bang! (in HD)

I am adding here a YouTube embedded video of a live feed from the Martin Fleischmann Memorial Project. I chatted with Bob Greenyer and he explained upcoming tests that they plan to do:

Here’s what he said:

“Ryan and alan are putting fuel in 3 cores, one for a Parkhomov-style leak test in a glass jar, if that works – we will put a core in the SiC element.”

“We then have two GlowSticks one will be fueled and the other not I will post some images of the glowsticks
One will be a control for the other.”

“We hope to do two more live experiments, One will be the Parkhomov Leak test – if that works (ie no H2 is seen in the glass jar when we go to 200C – then we will show a radically easier way for people to build reactors
Also – if it works – we will then run a separate core in the SiC element that is currently doing a low temp calibration”

Bob said the first test will be the Parkhomov leak test. Not exactly sure when that will begin. The second test is partially dependent on the first.

Anyway, here is the YouTube link:

And below is the video stream:

UPDATE: (Feb 6, 2015) The experiment abruptly ended when there was an explosion in the reactor after it was heated to over 1000 C. You can follow the event at about 1 hour before the end of the video above. Here’s a blurry screenshot of the data:


UPDATE #2: (Feb 6, 2015)

Here’s a higher definition video of the Bang!

  • Bob Greenyer

    We should have filled in dry air not Argon. The O2 and N2 would be combined with Aluminum to form refractory compounds in the breakdown of LiAlH4 – the argon cover gas when we filled it would not.

    If we added a little Zirconium, that would getter and sequester any CO and CO2 and would also adsorb the H2 from the LiAlH4 – We could then regulate the H2 by thermally reversible dis-adsorbtion adsorption from the Zirconium

  • Bob Greenyer

    Basic construction of a *GlowStick*

    []=Project Dog Bone=[]

    In this video, Alan Goldwater discusses his sealing method during construction of the *GlowStick* pressure tester and reactors and the test core for the SiC element.

    • artefact

      So the sealing is done just with aluminium rings? that is easy and inexpensive.

      • Bob Greenyer

        Yes, making a *GlowStick* takes about an hour if you have things on hand and is a dry process that requires no kiln.

    • Axil Axil

      On vortex. James Bowery accused MFMP of invalid video presentation as follows:

      “The video frame of the BANG has 3 different video streams merged into different sections of the frame.

      It is likely that the video stream containing the VI display was in sync with the audio and the video stream of the white hot dogbone was ahead of the audio stream as well as the video stream containing the VI display.

      Yes, if this is the case, someone _really_ screwed up this video – very badly.”

      Axil’s response was as follows”

      “It is hard to believe that the video feeds are the best part of a second out of sync. This dereliction of instrumentation would be a mortal sin against science. We must understand that such a problem can get people to follow false leads and waste tons of time trying to figure out a pressure related problem that does not exist or the opposite. This is just as bad as water in the steam type issue that we have spent days and days talking about. This is a shot at process that naysayers can use to discredit LENR experimentation as science.

      The video is an important scientific tool to understand what is happening in an experiment. It must be calibrated as rigorously as the heat sensors.

      At this moment, I trust MFMP has setup the video properly and the fault is a hot spot failure of the core.”

      Can you assure the world that the video feed of the experiment is completely trustworthy?

      • Bob Greenyer

        Hi Axil.

        If I had my way and we had the budget, I would have used one or other of Newtek’s TriCasters for the live feed. That was not on the table however.

        These are the facts of how the LIVE composite stream was made.

        Until we had the failure that caused the demise of the Optris camera, we used an ASROCK gaming PC (Whose motherboard died in the same event.

        After that, we used a new Lenovo quad core laptop as the machine to composite the elements of the live stream.

        In both cases, we used many cam from to composite the various feeds and to provide switchable sources to the Google live stream. For the money, it is an amazing piece of software.

        In the previous tests we did before, the dog bone heat up with TCs and the pressure fuelled test, I only had access to the public HUGNetLab data stream in Czech that was sometimes as much as 15 minutes behind real-time. So for the recent tests we wanted to make that far better.

        What we did was, we linked to the web server on the machine that was directly connected to the HUGNetLab data acquisition board. Essentially we had the most recent data. However, as I understand it, there is still a small delay posting live aggregate data to the database from which the graphs are drawn. You can see this in the live feed as a periodic “chunk” of data being graphed. Someone with a keen eye could work out what that gap between refreshes is, indeed there is a refresh in the course of the “Bang!” video at the point where I am noticing that the K and B type Thermocouple readings are converging.

        The data from the PCE-830 software is sampled every 2 seconds (that is the smallest time difference permitted by the software). Additionally, the software would not run on the more modern machines without crashing them, so to avoid bringing the whole stream down, we had a separate older and compatible laptop capturing the feed from the PCE-830 and we ran a remote desktop session to that laptop to capture the screen. This was composited into the live feed in ManyCam. Additionally, with the PCE-830 clamp set to 100A the W resolution was not so high. There was therefore at least a 2 second delay in the sampling and probably a little more by the time the remote desktop session was captured and in the composite.

        In the Swagelok sealing Live Streamed video of over 4.45 hours, which included the failure of the SiC heated core, we had one cheap webcam trained on the Williamson IR, one roaming camera (which was my Galaxy Note 2 phone) a Microsoft 720p webcam (which disconnected a few times because of the 2 long USB extension leads when we were moving from the glass jar to the SiC element). The HUGNet data and the PCE-830.

        The clock is a function of the ManyCam software and used the web-set clock on the Laptop as reference showing local time in Minesota, USA. HUGNet lab uses UTC, by comparing the time on the clock and that on HUGNet, you should be able to sync up the data precisely.

        We have many photos and other videos taken during the recording from scores of angles, we will post those in a gallery as soon as possible. All will be consistent.

        In addition, because the bandwidth was low out of HUG, I had set the frame rate to 10FPS (or even 5, but I think 10) I decided to use ManyCams ability to record its feed. I did this with ManyCams default settings on quality, in hindsight, I would have liked to up the data rate (I also wish I had 30fps after the event but it would have made the YouTube stream worse). Indeed, it may be the act of setting ManyCam to stream 10fps from 30fps feed that causes any audio/video off-set.

        ManyCams recording function only allows snapshots OR videos to be made. Therefore, I chose to video – until a key point, when I stopped the video recording, took snapshots into the common real-time shared folder that was available to all during the night at 1080p resolution, and then I switched back to the video recording function. This had the added advantage of splitting the video to avoid total loss from a system failure – there were though small drops in the higher quality captures, but I felt that youtube was recording the whole sequence, so that would not be a disaster.

        The Microsoft webcam was about 1.5m from the SiC assembly and the image was zoomed in ManyCam to who the region of interest.

        My personal opinion is that there should be nearly no delay from the visual fracturing of the reactor core/SiC element and the audio.

        ManyCam has the option to use any audio source for the composite stream that was available to the system. The system had the MicroSoft web cam, the other webcam that was trained on the Williamson and the laptops microphone. I am not certain which microphone was active at the time. It may be the case that in the move from the glass jar to the SiC element – where the extension leads caused several drop outs in the MicroSoft webcam, that many cam defaulted to system sound and that this is the reason for the delay in the audio.

        Additionally, you can see at the end of the full video, when I am again using my mobile, there is an “echo” because I think that ManyCam is adding the audio from its continuous source – to that of my mobile phone – therefore, there is definitely a delay on one.

        The video is exactly as it was made by ManyCam, and this feed was sent to Youtube live and recorded at the same time. If I had a whole load of professional cameras, a genlock, and introduced a forced delay of say 5-15 seconds (as most “Live Broadcasts” do) to ensure synching of all the HUGNet/PCE-830 data and a Tricaster to comp/switch everything – I would have done so – but we had neither the time, money or men at hand to do so.

        What we did was the most advance streaming of a live experiment this field has ever seen.

        I will publish the full sequences at higher quality ASAP – complete with whatever delays that ManyCam imparted on the recordings and which was reflected in the Youtube feed.

        I will also line do a post live recording version of the “Bang!” video, using the visual reference to queue the audio bang, but be aware, as the video is only 5 or 10fps from 30, I can only possibly be accurate to within 1/3 of a second if I do this work.

        I hope this clarifies the situation. I am suffering a lot of exhaustion from the past 8 weeks right now and jet lag to boot, also, a lot of back log in my real work, so please bear with me.

      • Bob Greenyer

        In addition, Ecco on our main site has noted that the actual live feed had the Audio and video in sync (or more so).

        in this video, the Bang comes before the visual, I think that you will find the visual is around 1/3 second out of sync as per my previous note indicating that the FPS on the live feed was set to 10 or 5, only this time it is the other way.

        I can only conclude that ManyCam got the audio a little off on its own recording, I now have a better reference for appropriate synching.

  • Anon2012_2014


    If you look at the geiger counter “volts” (I assume it is counts), the minimum increases during the period that the reactor is operating, and then decreases after reactor failure/burnout.

    Thus I believe we have detected a small increase in radiation coming from the device which is well below the background; IF this is not measurement error within the geiger counter.

    This is either measurement error as sending power into the device is influencing the geiger counter (or heating the geiger counter is influencing the geiger counter), or it is radiation causing the geiger counter to count.

    • Ged

      From what I, very limitedly, understand about most Geiger counters, is that heat can increase the rate of background noise in the detector. On the other hand, the counter is some distance away from the device; so the question is if the area around the counter got hotter, if so by how much, and if so how much does the baseline of the counter raise per unit temperature climb in its vicinity? It may be this obvious baseline climb is from the heat, or it could be a signature, there is just no way for me to say with the data I have, but I’d rather want to err on the side of caution and attribute it to heating in the absence of other data to the contrary.

      The 30 second averaging of the data on Hugnet may hide any rapid spiking that happened around the much shorter than 30 second boom window, too; but we must work with the data we got and not try to infill into the unknown. I believe Ecco has looked at this some and other than the rising baseline, didn’t notice a signal in the gamma detector–but then when I watch the video the gamma detector very audibly goes nuts right before and during the bang before returning to normal rather quickly after that. So, I dunno. Without the raw data, I don’t know if something was seen or not, it’s all too brief.

      • US_Citizen71

        What you hear during the failure is two things. An increased ticking of explosive gas detector the midrange sound that is regular like a metronome. The other sound is electrical arcing near the base of the heating element, you can see the blue sparks moving in time with the sound. The geiger counter does chirp right before the boom but it chirped off and on the entire time they had it on.

        • Ged

          I will have to defer to your auditory abilities on this one.

          • US_Citizen71

            I was watching live last night, when it went boom I replayed it several times via my Chromecast on my big screen and through my surround sound system. I wish it showed something else besides a pressure failure but there just doesn’t seem to be anything there to justify coming to that conclusion.

            • Ged

              It’s not surprising given the temperatures and pressures we know it can likely reach.

      • Anon2012_2014

        Download the data from hugnet with the history setting. The data is from 0 GMT to 7 GMT. The time stamp is about every 3 seconds (irregular).

        Load into excel the Geiger data vs time and plot it with a scatter plot (x vs y) with lines berween the points.

        The signal at the minimum will be clear and obvious vs the temperature of the reactor.

        Could be that IR from the alumina tube got to the GM tube.

  • Sanjeev

    Some people (the outsiders) are going to see this as a cold fusion signature (is that good or bad for CF, no idea).

    • Ged

      Bangs are thrilling and something everyone can understand. But we need thorough analysis of the event to understand why it may have occurred and how to deal with it in future tests. It’s the dramatic results the MFMP has always been secretly hoping for, so it’s quite exciting. -Something- worked, you can visibly see superheating occurring with the bang, but the question is what does that mean, and that is not yet answered till we get the MFMP full analysis, just like with the first replication attempt.

      Hopefully the public will understand that. But it still brings awareness to the MFMP, and we know they are on the right track (got that hydrogen pressure issue fixed! No more Swiss cheese stainless steel).

      • Anon2012_2014

        Download the data from hugnet with the history setting. The data is from 0 GMT to 7 GMT. The time stamp is about every 3 seconds (irregular).

        Load into excel the Geiger data vs time and plot it with a scatter plot (x vs y) with lines berween the points.

        The signal at the minimum will be clear and obvious vs the temperature of the reactor.

        Could be that IR from the alumina tube got to the GM tube.

  • Axil Axil

    At 2.29 a white spot appears in the field of scarlet but the power going through the coil is still nominal. This means that the reaction is not caused by a short circuit in the heater element. As 2:29 progresses the white spot grows in size.

    The area of white expands throughout the 2.30 timeframe and at the end of that time period, the power to the heater surges as the heater begins to short out. The exploding sound occurs at the end of 2:30. The area of white is at its maximum at the end of 2.30 and begins to return to scarlet stating at 2:31. The power going through the heater is at its maximum at 2:32 until 2.34. The power is minimized at 2:35. The heater is completely shorted at 2:55 with 0 current flow.

    • US_Citizen71

      I just watched that sequence at .25 speed (you can change the speed of playback under the settings gear) I think what is seen is a hydrogen flame. It appears to expand outwards from a split in the silicon carbide coil in the air. The white color on the exterior of the reactor in the video wasn’t visible, it is due to intense infrared making it past the built in IR filter in the camera. Even a perfect blue flame would likely show bright white with that camera.

    • Anon2012_2014


      You mean on the left of the tube. I am assuming that is purely the SiC heater element connector there as it is considerably cooler than the rest of the body pre-explosion.

      The explosion seems to me to be no synchronized in the audio and video channel — the time of the explosion on the video can be seen when the rod coming out the right of the tube move off center.

      If you look at the frames exact;u at the time of the explosion you can see white material moving from the right of the tube. I guess that is the end cap I don’t know.

      A few frames later a white tendril, maybe 1/2 cm tall, roughly triangular shaped emerges from the mid part of the tube that is white hot as seen by this camera.

      The the left part of the SiC heater element on the left of the tube appears to get very hot, all while the current spikes to 70 amps+, the voltage drops only 3 or 4 volts, and we here on the audio track what may be the transformer of the power supply vibrating from the overload current making the magnetism so large in the transformer that it is vibrating the windings or the plates within.

      Does anyone know where this “hot spot” is in the video.

      I am guessing that the unit failed somewhere in the middle, scattering alumina, thus terminating the LENR reaction. When the unit opened to the air, I would image that the hydrogen flashed in the oxygen, and that the lithium and the aluminum in the LiAl both combusted, perhaps with the nickel. I also guess that when the tube failed, it bent the SiC heating element until it shorted out mid way through, and the extra current through the now shorted out SiC was more than the input connectors could take, and that is why the left side briefly heated up during the short out.