MIZUNO REPLICATION AND MATERIALS ONLY

    Quote from Paradigmnoia

    I don’t mind the IDE. For some strange reason it is like there is a separate clipboard for the IDE, so one can cut and paste within the IDE, but try and copy from another page and paste to the IDE and whatever was copied or cut from the IDE last time pastes instead.


    Anyways everything was working smoothly until I tried to read the RS232 signal (2 wire only!) from my usual data logger, in order to incorporate that into the sketch data log. I have an RS232 to TTL level shifter, wired everything thing up, checked the Tx and Rx wires end to end, and nothing happens. There should be a 16 bits-long word but nothing comes out in either single bits or strings and with only two wires (Tx and ground), there is no way to poke the RS232 side into action. It is possible that the level shifter doesn’t like only one signal wire. So today’s diagnostics involves plugging in an RS232 to USB cable and seeing if the laptop can see it working...

    Or get an old computer circa 1988 with an RS-232 port.

    I followed with interest all the debates concerning these replications.

    From my point of view, the only relevant thing that I retain is the relative hardness dispersion of palladium.

    It should be understood that these samples are made by stretching. So temperature balance during process is important. This brings us back to P&F and all the dispersion they have seen in their own palladium. Concerning Mizuno R20 if palladium is torn off by friction, this is because samples are in a plastic phase . This has a huge impact on Pd crystal lattice, which contrasts with elastic phase which come back by relaxing strain constraint.

    This creates a lot of voids at atomic sizes.

    I'm not convinced that R20 Pd onto Ni mesh remains the best solution to drive sizes dispersion for voids created.

    To finish, i don't think these voids are enough for XH however heater heat tends to move these voids, all in an environment rich in protons immersed in a sea of electrons. It's on this side that i suggest to looking for.

    First calibration of Cell3 with H2 went well, other than a few data system issues. I included a calibration of the new Baratron instrument against the MKS convection (Pirani) gauge, which may be useful to other replicators. Images from the Optris camera are available, but the actual data isn't getting saved properly yet.


    So today I got new RSR232 cable info ... which disagrees seriously from the manual (page 15).

    Now the 3.5 mm jack base is the signal (rather than the tip), there is no RS232 ground connection, and 3.5 mm jack tip goes to a new terminal, neither of which the Rx and Tx wires go to .

    wtf

    Edit: tested and this works. The user manual is BS.

    The Sparkfun RS232 - TTL level shifter (with or without the female DB9 connector) has only circuit board connections to three pins of 9: Tx, Rx, and Ground.

    Currently, this only works on a RS232 to USB on a laptop serial monitor but at least I can see the data enough to work out decoding it now.

    The revised DB9 wiring utilizes a neat voltage level manipulation circuit but seems odd without a real ground, and so the TTL shifter needs re-wiring, and there a bazillion suggestions on the Internet for tying DB9 pins one way and another with zener diodes to sort through ...

    The 3.5 mm jack has the base tied to the cable jacket foil, but will be carrying 5V at the jack tip, unreferenced to the receiving side ground except at the power supplies.


    Edit2:

    In case someone else runs into this, since it is unusual, the Reed Datalogger uses a DTR asserted signal from the receiving end, normally supplied by a PC DB9 serial port. This is typically a +9 to +12 V positive signal with some very weak current carrying capacity (about 35 mA). This DTR voltage goes up the RS232 adapter cable to the Reed datalogger, where (inside) it connects to the base of a signal transistor. The high logic RS232 signal then comes back out of the datalogger, (using this voltage supply, through the internal transistor), and goes back down the cable to the Tx pin of the adapter cable, and ultimately to the Rx pin of the (RS232) receiving end. (Negative voltage signals are also sent down this same output signal wire, as well as a zero V (neutral) idle signal.)


    It seems that this DTR voltage can be high enough, even at +5V, to operate (most of) the RS232 to TTL level shifter/inverter devices typically available. However, a resistor (and possibly a diode) should be installed in series to prevent trouble if wired up wrong somewhere along the way. So, in theory, the DTR line can be supplied (with caution) by the +5V Arduino voltage output, and (with more caution) possibly by an Arduino +5V digital output pin set to high logic. The Tx signal from the datalogger connects to the receiving RS232 Rx pin as usual. The ground wire is not connected to anything on the datalogger end. [This is an output only system, and it is unclear if the DTR signal is being used by the data logger for its intended purpose also. However, it seems technically impossible for the datalogger to send any signal without the voltage supplied by the receiver end DTR +voltage signal.]
    (Not all devices connected this way can necessarily use the low +5V at DTR, and may require more voltage, up to +12V, in order to output the RS232 signals properly, especially over any great cable lengths.)


    It is still unclear if the RS232 DTR logic low (negative voltage!) is required in this case, but it seems not.


    Apparently some anemometers output two wire RS232 using this system.


    There are some devices that use the RS232 RTS logic low (negative voltage, as low as -12V) combined with the RS232 DTR logic high (positive voltage) to make a large voltage differential (up to 24V) to supply some circuits.


    EDIT3:

    Finally the RS232 data comes out other than zeros and a few random other bits. I found a manual for a device using the same base circuit board which has an extra connection.

    See B&W image below. Compare this to the WRONG page 15 version of the REED manual. (Ignore some data byte info that are for an anemometer only).

    Without the additional 2.2k resistor, basically only zeros (00) are sent to the serial plug.

    .

    Good job Paradigmnoia!

    Quote from anonymous

    Good job Paradigmnoia!

    I snuggled in the 2.2 k resistor into a new RS232 header along with a 1K in series with the DTR lead, and installed that into a gutted VGA header housing. Shoe Goo used to back-fill converted DB9 housing (hood) to keep the TX resistor and entire RS232 connector from pulling out of cable.


    Next a Sparkfun RS232 to TTL converter was bored for a crimped and soldered lead to the DTR pin via the perpendicular bend at the back of the RS232 DB9 connector, shrink tubed over the main board, Molex connector aligned with the 4 other pins, and supported with a blob of shoe goo.


    The Reed data logger basically sends data words non-stop. One word for each thermocouple, each apparently read at the instant before reporting the word. I was turning the DTR off, changing the thermocouple from one to another TC port, heating the TC with my fingers, and turning the DTR back on again (which turns back on the data stream). The next reading for the changed items had the changes immediately effected in the data. This seems to mean that there is no large buffer in the Reed device storing up any information long-term. There also seems to be no simple way to get the data sent from the Reed to begin with the first TC first, when receiving it, so I probably need to parse each word, update a bunch of registers, and at each time stamp event read back the most recent temperature registers in the right TC port order for the Arduino SD data log spreadsheet. It is tempting to spy on the Reed data feed to the SD drive inside of it, instead, where temperature data is already processed into the right order for its own spreadsheet.

    I don't recall if there is a thread about Saito's replication at the Hokkaido U. of Science. Anyway, here is some recent encouraging data from it. Here is a calibration curve of losses, derived from 13 tests:


    Figure 1. Calibration curve from 13 tests.



    The X-axis is Tout-T-in, the outlet temperature minus inlet temperature (temperature difference). The Y-axis is Wot-Win, watts input minus watts output. (I think the label "Wot-Win" is not right.) For example, the top left point represents a calibration with 975 W input, 687 W output, 288 W lost from the walls of the calorimeter, and a temperature difference of 39 deg C. As you see, the losses are fairly linear.


    I think the point smack in the middle of Fig. 1 is from a test with 573 W in, 395 W out, 178 W lost, temperature difference 25 deg C. Pretty sure that's the one. Shown here:


    Figure 2. 600 W calibration shown in the point in the middle of Fig. 1.



    Here is an excess heat result. I might have uploaded this earlier. Anyway, it shows about 350 W excess. This is adjusted for heat losses. If it were not, output would just about equal input. With calibration at approximately this power level (Fig. 2), output falls well below input. The fluctuations at the beginning are interesting. Some excess heat tests show them; others do not.


    Figure 3. 750 W input, ~1,100 W output, after adjusting for losses.



    Here is another example with periodic fluctuations starting about the time excess heat appears:


    Figure 4. 800 W input, ~1,100 W output, after adjusting for losses.



    [If there is a Saito thread somewhere in this mish-mash of a website, perhaps someone can transfer this message to it.]

    Quote from Alan Smith

    No Jed. This is the Mizuno replication thread. And as Saito is (presumably) replicating, it is the right place to publish his results.


    I uploaded some other data from Saito and his undergrads . . . Was it here? If it was somewhere else, this goes with it. But leave it here. I just now pointed to it from Vortex, which does not allow graphics. Kinda obsolete.

    What is the inlet and outlet temperature doing at the area of the bump just after Wout > Win?

    Quote from Paradigmnoia

    What is the inlet and outlet temperature doing at the area of the bump just after Wout > Win?

    The graph is all I have, so I don't know the details. However, the ambient temperature in this lab is much more stable than Mizuno's, and the equipment is better, so I assume inlet temperature was quite steady and the outlet was bouncing around as shown in the graph. As you know, the graph actually plots outlet minus inlet temperatures, with a fudge factor to convert that value into watts. It is not actually watts measured directly. So, that bump has to be the outlet temperature. I assume it reflects an actual change in power, rather than an instrument glitch. I could be wrong, but I expect they would have found a glitch and tossed out the data. They wouldn't have sent the graph.

    Quote from JedRothwell

    The graph is all I have, so I don't know the details. However, the ambient temperature in this lab is much more stable than Mizuno's, and the equipment is better, so I assume inlet temperature was quite steady and the outlet was bouncing around as shown in the graph. As you know, the graph actually plots outlet minus inlet temperatures, with a fudge factor to convert that value into watts. It is not actually watts measured directly. So, that bump has to be the outlet temperature. I assume it reflects an actual change in power, rather than an instrument glitch. I could be wrong, but I expect they would have found a glitch and tossed out the data. They wouldn't have sent the graph.

    I don’t assume that it is some sort of problem. I am just curious as to what the temperature is doing, since the heat fluctuations are presumed to be caused by a reaction.

    Sometimes the reaction (or whatever) seems to start right away, with no fluctuations, and other times there are these sinusoidal periods.

    I wonder what the difference is.

    Quote from Paradigmnoia

    I don’t assume that it is some sort of problem. I am just curious as to what the temperature is doing, since the heat fluctuations are presumed to be caused by a reaction.

    If there is no problem, then the temperature is doing exactly what you see there. That graph is the temperature. So I don't understand why you ask what the temperature is doing.


    Quote from Paradigmnoia

    Sometimes the reaction (or whatever) seems to start right away, with no fluctuations, and other times there are these sinusoidal periods.

    I wonder what the difference is.

    Yes, the fluctuations are sometimes there, and sometimes absent. I have no idea why. Mizuno also observed this.

    Quote from JedRothwell

    If there is no problem, then the temperature is doing exactly what you see there. That graph is the temperature. So I don't understand why you ask what the temperature is doing.

    The graph is the delta T, mixed with a whole bunch of other stuff, some measured, some calculated, so it is more like a diluted temperature plot.
    The actual temperature traces may contain more information.

    If there is no problem, I don’t see any need to keep the temperatures secret.

    Quote from Paradigmnoia

    The graph is the delta T, mixed with a whole bunch of other stuff, some measured, some calculated, so it is more like a diluted temperature plot.

    The only "other stuff" is the air flow rate. It is stable. Unchanging. So it has no effect on the graph. There are only three parameters with this method: inlet and outlet temperatures, and the air flow rate. Things like relative humidity and the air pressure can be added but they make no measurable difference. If I posted two graphs superimposed, one with three parameters, and one with five extra stuffed in, the lines would be on top of one-another. You can't see the difference.


    The only thing calculated is the fudge factor from the graph in Fig. 2 to adjust for heat losses from the box. You can remove it easily. Just move the output power line down.


    Quote from Paradigmnoia

    If there is no problem, I don’t see any need to keep the temperatures secret.

    Nobody is keeping secrets, but they didn't bother to send the spreadsheet for this graph. Just the graph. I have the spreadsheets for a few others.


    Once you establish that the other parameters make no measurable difference, you don't need to keep establishing that again and again.

    Quote from JedRothwell

    Here is an excess heat result. I might have uploaded this earlier. Anyway, it shows about 350 W excess. This is adjusted for heat losses. If it were not, output would just about equal input. With calibration at approximately this power level (Fig. 2), output falls well below input. The fluctuations at the beginning are interesting. Some excess heat tests show them; others do not.


    Figure 3. 750 W input, ~1,100 W output, after adjusting for losses.


    I wonder what the time course for cooling looks like. That could be pretty diagnostic. This group must have turned off the input power at some point and I would have expected then to see some interesting stuff.


    Overall, this isn't what I would expect to see from a system with a source of excess-heat that is, itself, activated by increased in temperature. There should be an inflection point as the excess heat production starts to create a positive temperature feedback to engage even more excess heat. I see no a hint of anything like that. The breaking of the feedback when the input power is shut off should be quite distinct (another inflection) which is why I am hoping for a cooling curve.


    What else should this group expect to see? There should be temperature bistability, making it hard to achieve some intermediate temperatures. There should be hysteresis such that different power outputs are possible for the same input power depending on the recent history of the reactor. I wonder if they see any of that.


    Actually, if you look closely at the thin temperature trace it does seem to have an inflection point at about 140 degC. It is hidden a bit by the thick green trace.

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.