I think comparative law should be adopted to eliminate interference factors.For example cylindrical cavity load and different cavity value cavity are used to compare thrust response parameters under same frequency and power condition because interference factor outside cavity thrust is fixed.
Translation: "comparative law" means "the method of comparing against proper null tests".
Yes, that's right. Contrast is the best way to eliminate distractions.
Please, pretty please, give us some measurements. Definitive to whatever accuracy your excellent rig allows! Just move to 10% of the time spent testing, and 90% spent improving the rig, from 100% spent improving the rig...
The hope is that these newest upgrades will allow for a more seamless integration with LabView....
OK, a true story, then I'll shut up.
Some decades ago I was a software performance specialist. I was asked to measure the performance of message routing software. It was important stuff, so I spent time writing scripts, automating procedures, testing what I'd done, and generally making sure I could reproduce the work at the touch of a button. After a few days I was still at it, but a senior engineer came to me, with the data he had wanted already in hand. He was at least two, probably three grades above me, the lead for dozens of engineers. "How did you do that?" I asked politely. "I just sat with a list of tests and executed all of them by hand, and used command line functions to measure resource usage. There were only a couple of hundred tests, it took about half a day.".
I'm sure you'll do a fantastic job, but the above is worth remembering.
Quote from: Monomorphic on 04/19/2018 01:20 PM
Quote from: RERT on 04/19/2018 09:55 AM
Please, pretty please, give us some measurements. Definitive to whatever accuracy your excellent rig allows! Just move to 10% of the time spent testing, and 90% spent improving the rig, from 100% spent improving the rig...
The hope is that these newest upgrades will allow for a more seamless integration with LabView....
OK, a true story, then I'll shut up.
Some decades ago I was a software performance specialist. I was asked to measure the performance of message routing software. It was important stuff, so I spent time writing scripts, automating procedures, testing what I'd done, and generally making sure I could reproduce the work at the touch of a button. After a few days I was still at it, but a senior engineer came to me, with the data he had wanted already in hand. He was at least two, probably three grades above me, the lead for dozens of engineers. "How did you do that?" I asked politely. "I just sat with a list of tests and executed all of them by hand, and used command line functions to measure resource usage. There were only a couple of hundred tests, it took about half a day.".
I'm sure you'll do a fantastic job, but the above is worth remembering.
RERT, while I agree in concept with you on the automation vs. manual process, ( See XKCD's wonderful example:
https://xkcd.com/1319/ ) I don't think this applies in the case of Monomorphics work. Through my time lurking and seeing the results of the great DIY experiments being done here, most of the uncertainty in measurement and possible experimental error has been in not having a well laid out and repeateable process for collecting and recording data combined with non-ideal testbeds. The latter is somewhat unavoidable with DIY work, but the former can be developed and followed regardless of if the effort is DIY or professional.
Correct me if I'm wrong Monomorphic, but the whole purpose of the "rig improvement" has been in order to develop a smooth and nearly automatic process. This will allow the repeat of a single test configuration multiple times without disturbing the testbed. Then a new configuration can be set and again run multiple tests on that configuration. This is the type of rigor and correlated data the community needs.
I say keep on going Monomorphic, your rig is looking better every day, and I look forward to the glut of data you are going to produce.

Back to waiting patiently in the shadows.
MM
Please, pretty please, give us some measurements. Definitive to whatever accuracy your excellent rig allows! Just move to 10% of the time spent testing, and 90% spent improving the rig, from 100% spent improving the rig...
The hope is that these newest upgrades will allow for a more seamless integration with LabView....
OK, a true story, then I'll shut up.
Some decades ago I was a software performance specialist. I was asked to measure the performance of message routing software. It was important stuff, so I spent time writing scripts, automating procedures, testing what I'd done, and generally making sure I could reproduce the work at the touch of a button. After a few days I was still at it, but a senior engineer came to me, with the data he had wanted already in hand. He was at least two, probably three grades above me, the lead for dozens of engineers. "How did you do that?" I asked politely. "I just sat with a list of tests and executed all of them by hand, and used command line functions to measure resource usage. There were only a couple of hundred tests, it took about half a day.".
I'm sure you'll do a fantastic job, but the above is worth remembering.
Yeah, that would've been me with the data in hand.. However, I see first hand regarding testing my MEGA drives that having a superb, well shielded setup is paramount to getting any repeatable data. I thought it would be straight forward but the EM interference from the amplifier, the reaction to sound pressure on the MEGA when operating, the rate of discharge on the batteries, and the infinitesimal changes in output from my Wheatstone bridge, all added up to not being able to collect data for more than a few seconds before the system needed to be re-calibrated and adjusted back onto the screen.
Now, I have all the parts to finish it but I've been sidelined by other issues, like cracked bathtubs and sciatica. TBD when I'll be done.
Sciatica sucks, IIRC. Otherwise, shutting up as advertised....
Quote from: Monomorphic on 04/19/2018 01:20 PM
Quote from: RERT on 04/19/2018 09:55 AM
Please, pretty please, give us some measurements. Definitive to whatever accuracy your excellent rig allows! Just move to 10% of the time spent testing, and 90% spent improving the rig, from 100% spent improving the rig...
The hope is that these newest upgrades will allow for a more seamless integration with LabView....
OK, a true story, then I'll shut up.
Some decades ago I was a software performance specialist. I was asked to measure the performance of message routing software. It was important stuff, so I spent time writing scripts, automating procedures, testing what I'd done, and generally making sure I could reproduce the work at the touch of a button. After a few days I was still at it, but a senior engineer came to me, with the data he had wanted already in hand. He was at least two, probably three grades above me, the lead for dozens of engineers. "How did you do that?" I asked politely. "I just sat with a list of tests and executed all of them by hand, and used command line functions to measure resource usage. There were only a couple of hundred tests, it took about half a day.".
I'm sure you'll do a fantastic job, but the above is worth remembering.
RERT, while I agree in concept with you on the automation vs. manual process, ( See XKCD's wonderful example: https://xkcd.com/1319/ ) I don't think this applies in the case of Monomorphics work. Through my time lurking and seeing the results of the great DIY experiments being done here, most of the uncertainty in measurement and possible experimental error has been in not having a well laid out and repeateable process for collecting and recording data combined with non-ideal testbeds. The latter is somewhat unavoidable with DIY work, but the former can be developed and followed regardless of if the effort is DIY or professional.
Correct me if I'm wrong Monomorphic, but the whole purpose of the "rig improvement" has been in order to develop a smooth and nearly automatic process. This will allow the repeat of a single test configuration multiple times without disturbing the testbed. Then a new configuration can be set and again run multiple tests on that configuration. This is the type of rigor and correlated data the community needs.
I say keep on going Monomorphic, your rig is looking better every day, and I look forward to the glut of data you are going to produce.
Back to waiting patiently in the shadows.
MM
The other part that everyone is forgetting is that Monomorphic found the best time to get undisturbed data was at 3:00 in the morning when no one, including himself, was moving in his neighbourhood. If you are measuring micron level movements and do not have access to purpose built labs with isolated foundations, etc. then this is exactly what you need to do.
I am finishing up on the phase change heat sink and am not sure if I should use wax that melts at 128°F (53°C) or 119°F (48°C) or something more like 99°F (37°C).

With tests limited to about a minute each, I do not know if the amplifier will go from room temperature to 128°F (53°C) in that time for the phase change to be of use. As components should be kept as cool as possible to reduce natural convection, it may make more sense to use something like petroleum jelly (soft paraffin wax) which begins to melt at 99°F (37°C) so that the temperature rise stalls at a lower temperature.
I am finishing up on the phase change heat sink and am not sure if I should use wax that melts at 128°F (53°C) or 119°F (48°C) or something more like 99°F (37°C).
With tests limited to about a minute each, I do not know if the amplifier will go from room temperature to 128°F (53°C) in that time for the phase change to be of use. As components should be kept as cool as possible to reduce natural convection, it may make more sense to use something like petroleum jelly (soft paraffin wax) which begins to melt at 99°F (37°C) so that the temperature rise stalls at a lower temperature.
It is more appropriate to use soft paraffin wax. Is the specific heat capacity of vaseline appropriate?
It is more appropriate to use soft paraffin wax. Is the specific heat capacity of vaseline appropriate?
I think petroleum jelly (Vaseline) may be a better place to start honestly. It would be very easy to remove if it doesn't work, and can be mixed with regular paraffin wax to reduce the melting temperature. I also ran across this youtube video of someone who used Vaseline as a Phase Change Material (PCM).
It is more appropriate to use soft paraffin wax. Is the specific heat capacity of vaseline appropriate?
I think petroleum jelly (Vaseline) may be a better place to start honestly. It would be very easy to remove if it doesn't work, and can be mixed with regular paraffin wax to reduce the melting temperature. I also ran across this youtube video of someone who used Vaseline as a Phase Change Material (PCM).
So that's good. In addition, a pure load replacement cavity is required to obtain the data of the comparison test.
Please, pretty please, give us some measurements. Definitive to whatever accuracy your excellent rig allows! Just move to 10% of the time spent testing, and 90% spent improving the rig, from 100% spent improving the rig...
The hope is that these newest upgrades will allow for a more seamless integration with LabView. Without a way to automate the experiment so that tests can be performed under exactly the same conditions, then the data will be harder to process for analysis. It has also allowed me to offload the computer, which generates quite a bit of heat. The battery was also a pain as it needed to be recharged between each test. Now there will be only three main components on the pendulum: signal generator/power detector, RF amplifier, and frustum.
I also had to physically touch the pendulum two or three times to begin tests by pressing a button to turn on the on-board computer, and adding/charging the battery. This would disturb the pendulum long enough that heat from the computer was building up and causing displacement noise problems. If the liquid metal contacts work out, then the only time I will need to touch the pendulum is when centering it and when tuning the frustum. But once the frustum is tuned, it tends to stay in tune unless it gets bumped, likewise with the centering.
So what's left to do before tests can resume? I need to finish the wiring for the liquid metal contacts by running the mains and USB cables. I would like to purchase a 30A USB relay board so I can automate main power on-off as well (my current relay board is only good to 10A). Then I need to finish building the phase change heat sink for the main amplifier. That is 80% finished and I have all the materials I need here to complete. Once all of that is finished I will begin working on the LabView scripting portion. It is highly probable that I will run a few manual tests during this time, so there may be limited data during that period.
Jamie - take your time and make sure you are happy with setup before taking and publishing data - don't let any of us here pressure you . Of course we are waiting for data with worm on tongue*. But as you know and have demonstrated with your approach, experimental physics/test engineering require VERY careful methodical work. Like several others, I too am in awe over your build and efforts. But sometimes even those of us who understand quite well the demands of doing precise experimentation get impatient .
BTW - your efforts to incorporate LabView will likely be highly rewarded; my limited experience with it is quite positive.
Oh and keep twisting those wires LOL. Shielded twisted pairs are VERY good practice .
Herman
graybeardsyseng
* Bated Breath - nanu nanu
Well, my new lab is now completed and I'm in the process of moving my old lab gear from the house to the new facility, which I'm thinking about calling either the Gravity Reaction Lab or The Sorcerer's Apprentice Lab.
Apprentice Sorcerer Gravity Appliances Reaction ....hmmm help me find something for the D, so that the acronym will be ASGARD 
How about the Apprentice Sorcerer's Gravity Applied Reaction Displacer?
Brilliant DIY updates! Amazing to see the theoretical noise reduction techniques being put into practice with such vigor!
Some interesting news in keeping with the MHD and penetration talk.
https://www.sciencealert.com/scientists-cram-light-into-smallest-one-atom-space-possible-with-graphenehttp://graphene-flagship.eu/graphene-confines-lightCarry on experimenters we are all enthused with your progress.
Edit: Regarding earlier misunderstanding @Meberbs: "The current behaves anomalously because certain paths are preferential based on prior particles (decreased resistance) as relationships are established within the shape of the foam itself which then reduce resistance for massive real particles. Think of it like a horse ploughing a furrow. Rain may smooth the furrow but it still remains there for a long time."
So think of it as the chaos or energy density in the quantum foam, with continuous directional radiation the foam is smoothed allowing light and massive objects to accelerate faster when not running against furrows. The speed of information itself is dependent on the degree of interference and interaction with the vacuum. Light speed is variable depending on the orientation within the foam structure and wormholes must therefore be absences of light, tunnels in the foam if you wish. Please read up on related theories. This effect is subtle but it determines the relative speed of all particles, it also messes with observations due to our proximity with a star, but it should allow for interesting time disparities and anomalies closer to the sun!
Improved RF Measurements of SRF Cavity Quality FactorsInteresting article about measuring Q of RF cavities by Holzbauer et al.
https://arxiv.org/abs/1804.04747Do I understand it right that the 'trombone' they use (variable phase shifter) can be used instead of a stub tuner?
regards,
Peter
Improved RF Measurements of SRF Cavity Quality Factors
Interesting article about measuring Q of RF cavities by Holzbauer et al.
https://arxiv.org/abs/1804.04747
Do I understand it right that the 'trombone' they use (variable phase shifter) can be used instead of a stub tuner?
regards,
Peter
RE using the trombone for tuning: Yes it can - at least to some degree. In the paper they are using the trombone to induce a phase change in the applied signal, in order to determine behavior in the complex domain of the circulator and cavity together as a system. Some tuning will occur, but the range may not be what is often desired for a stub tuner. In many systems a stub tuner(s) are used in series with the trombone.
For more complete discussion of a somewhat complex (no pun intended) topic, here is a rather good link for how stubs, trombones etc are used in RF measurement at CERN along with some general discussion of RF measurement approaches.
Herman
graybeardsyseng
https://indico.cern.ch/event/115334/sessions/5217/attachments/50210/72213/C1_Piotr_Ex_all.pdf
The phase change heat sink for the main 30W amplifier is finally finished! Extra care was taken to make sure it is as watertight as possible. I used high temp epoxy for the seal and also 3D printed the frame for a cellulose acetate window so I can view the melting while also providing some insulation. You can see in the images below that after I have poured the petroleum jelly, one half is still mostly melted and transparent while the other half is mostly solidified and opaque. This happens fairly quickly. I also received the 8-channel USB relay which will be used to automate the experiment.
Latest images. All major components are mounted and 95% or the wiring is completed. I need to test for shorts tomorrow and then I should be ready to pour the liquid metal into the liquid metal contact reservoirs.
I've also included an image of the "Rack" where most everything off the pendulum resides (minus the main computer). This includes the sensors, DC power and relays, and 120V AC.