Author Topic: EM Drive Developments - related to space flight applications - Thread 3  (Read 3126331 times)

Offline TheTraveller

Some time back I sent EW a paper on maintaining active tune resonance using a microwave PLL. I don't imagine anyone here has the resources for that, though. Which is why using very high Q is going to be problematic.

Which is why I will be using active frequency control based on monitoring the real time VSWR from my Rf amp and constantly adjusting frequency (in +-1kHz steps) for lowest VSWR, which will keep my frequency right in the middle of the cavity sweet spot, even if it heats up and moves around a bit.
It Is Time For The EmDrive To Come Out Of The Shadows

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5911
  • USA
  • Liked: 6124
  • Likes Given: 5564
Assuming that the control algorithm can adequately predict the future behavior of the actual process based on historical feedback.  Control operates based on feedback, which implies a time lag between feedback input and actuator output.  Whether the control will be successful is predicated on how well can the control algorithm model and actively adapt to the process without being unstable or lagging.
« Last Edit: 07/20/2015 05:42 pm by Rodal »

Offline TheTraveller

Charging again without substance?

Annus Veritas means the year in which we will find out the truth:

1) You are the one that claimed "all doubts will be removed" this year (you referring to the re-publication of Shawyer's 2014 Conference paper)

2) With the great testing set-up of rfmwguy, SeeShells and others, I have great expectations that we will learn a lot from rfmwguy, SeeShells  and others.

3) You have claimed that you will be reporting on tests too

4) With Prof. Tajmar reporting tests in a vacuum we will now have two prestigious institutions (NASA and TU Dresden, Germany) reporting on EM Drive tests in vacuum (something that neither Shawyer or Yang ever reported: not a single test in vacuum)

5) Hopefully NASA will report later in the year as to the progress of their tests?

So I expect 2015 to be an important year to learn about the EM Drive, yes, "Annus Veritas"

I'm Ok with others doing static Force measurements.

My test data will be based on long time acceleration data, well long time if you allow 15 minutes continual acceleration time as a long time, going from 0 RPM to around 120 RPM at various Rf amp output and table masses.

This will allow data collection as the initial cavity fill energy is converted into accelerative KE of the rotary tables 20kg mass, and then further data collection as additional energy is backfilled by the Rf amp to achieve a steady state cavity energy state. Balancing increased accelerative cavity energy losses to KE as against new energy inflow from the RF amp, with the cavity working at a lower loaded Q due to increased cavity losses.
It Is Time For The EmDrive To Come Out Of The Shadows

Offline TheTraveller

Assuming that the control algorithm can adequately predict the future behavior of the actual process based on historical feedback.  Control operates based on feedback, which implies a time lag between feedback input and actuator output.  Whether the control will be successful is predicated on how well can the control algorithm model and actively adapt to the process without being unstable or lagging.

No worries. Have built many such systems. All control systems have hysteresis loops that need to be dealt with. Just need to get it running to characterise it's loops so can handle corner turns and keep the VSWR as low as possible. My spreadsheet analysis suggests a +-5kHz range, in 1kHz steps should keep the excitation frequency very close to the ideal.
It Is Time For The EmDrive To Come Out Of The Shadows

Offline ElizabethGreene

  • Member
  • Posts: 69
  • Nashville, Tennessee
  • Liked: 138
  • Likes Given: 3
Are Photons Degraded after they:

1) bounce off a non moving end plate, EMDrive in Idle mode?

...

The energy in the system should not change unless work is performed.  For a system that is not doing work (accelerating) the loss in the system should be decay from surface losses (controlled by Q) and what is lost to impedance mismatch reflection.

For a system doing work accelerating towards the little end you have the same lost energy plus the work done by the light.  Mr. Shawyer models this as doppler shift, but I'm not convinced that fits properly.  The net is the same, the frequency of the light inside the cavity will decrease as it does work.  Interestingly, the light's frequency should increase when it strikes the big end in an accelerating system.  The difference between these two is based on the difference in the index of refraction on each end.  (n changes based on the dielectric constant of the media or by group velocity.)

Generator mode is problematic for me.  I doubt that an emdrive being accelerated backwards will spontaneously create microwaves from nothing.*  If however there is a signal in the cavity already the frequency of that light should increase.  There will be a limit to how far the increase can go.  The limit comes from two factors.  One limit can be that the frequency slides out of the bandwidth of the cavity.  Limit two happens when the wavelength is short enough so that that Vg(little) goes to C causing no difference in n between the two ends.  (1/2 lambda_{free} > a)

* Any low frequency light in the cavity with lambda > resonator cutoff can't propagate.

(I've not put any thought at all into amplitude changing instead of frequency.  I don't think that's possible because of quantization.)

Offline tidux

  • Member
  • Posts: 13
  • Sol III
  • Liked: 6
  • Likes Given: 3
..

To be clear:

2) Agreed. New results needs to be able to be matched to previous runs.  The issue with different number of rows and columns was to document a disconnect in specifications of what version of file output I was attempting to compare my runs against - it seems the file I thought I was supposed to use was not, in fact, a comparable run, and as a result I spent three days trying to make my output match the previous one.  Thus my suggestion that control files used to create output files always be provided with those output files in the future.  That, at least, should allow follow-on efforts to re-run the control file and verify the output files associated with it.

3) Agreed.  However, the use of files other than csv formats may be necessary when collecting multiple output files into a single package file to support direct comparisons of cell values across runs.  It's clumsy, but better than using file references for links between multiple csv files.  So consider it an artifact of the post-processing analysis like any other tool you might use.  CSV is a simple, easy to review, widely supported standard data interchange format that we should use for sharing data among researchers.  The alternative is to use versions of MEEP/HDF5 which store binary data in canonical format that is not machine independent, and I think that's not worth while.

Ed
I agree that it would be helpful to have unadulterated MEEP INPUT control files used to create OUTPUT files  be provided with output files.

The Meep input control file controls the Meep analysis, thus it is all one needs to run the analysis, "it is all you need".  More or different is not better because it would be subject to interpretation.   Same as providing numerical data in engineering drawings: redundant information is not better.  Extra information should be provided as comments. The Meep input control files could explained, with comments, as much as necessary but they should  never be substituted by any other type of input description that may be subject to interpretation or translation issues.



Ditto for the MEEP OUTPUT information.  To post-process the data, the actual output information from Meep is needed:

* the total Meep time (the computer run time is completely irrelevant to post-processing),
* the total number of Meep time slices
* the total number of Meep time steps

etc.



It would be helpful to have both the MEEP INPUT control file and the MEEP OUTPUT file information referred to above be provided as .txt files in the same Google Drive folder where the csv files are provided, for easy reference to understand what is the input and output associated with the csv files.

This is all part of formalizing a collaboration between multiple parties.

Eer, aero, and I have already confirmed that our meep installations are getting the same csv output bit-for-bit from the same input control file.

I do not recommend using Google Drive for this.  We'll be dealing with small text files (typical csv output size is 1.4MB, control files are only a few K), possibly hundreds of them.  A source control repository is a much better solution for our use case.  I can set up a git repository on my server if everyone is comfortable using git and SSH with public key logins, or we can use github.  If I do host it on my server, I have registered the domain name emdrive.science for our purposes.

In terms of organizing the repository, we have a ton of flexibility.  My initial suggestion is to organize the filesystem by drive type, then by antenna location, then by time run.

So, for example the root of the repository could look like:

$ ls -F $REPOSITORY_ROOT

NSF-1701/
SeeShells/
TheTraveller/
Yang/

And then drilling down, we'd have:

$ cd NSF-1701
$ ls -F

big-end-asymmetrical/
big-end-centered/
small-end-asymmetrical/
small-end-centered/

$ cd big-end-asymmetrical/
$ ls -F

0.013-microsec/
1.3-microsec/

Then within each of those directories we'd have the input and output files, kept in version control for successive runs rather than needing to generate unique human readable names or UUIDs for each new run.

Another advantage of using git over Google Drive is that in case of connectivity failure to the internet you still have a complete working copy of the data thus far.  Some of us live in areas prone to intense thunderstorms this time of year, and home networking equipment is squirrely at the best of times.

We could also use the Fossil SCM if that's more to people's tastes, but I have less experience with it so it would take longer for me to set up at first.
« Last Edit: 07/20/2015 06:59 pm by tidux »

Offline rfmwguy

  • EmDrive Builder (retired)
  • Senior Member
  • *****
  • Posts: 2205
  • Liked: 2713
  • Likes Given: 1134
Rotating, levitating "dust" ring around magnetron...semiconductor deposition stuff, but thought it was interesting:

http://www.researchgate.net/publication/230647596_Rotating_dust_ring_in_an_RF_discharge_coupled_with_a_dc-magnetron_sputter_source._Experiment_and_simulation

Offline saucyjack

  • Member
  • Posts: 21
  • San Francisco
  • Liked: 34
  • Likes Given: 1
...

I do not recommend using Google Drive for this.  We'll be dealing with small text files (typical csv output size is 1.4MB, control files are only a few K), possibly hundreds of them.  A source control repository is a much better solution for our use case.  I can set up a git repository on my server if everyone is comfortable using git and SSH with public key logins, or we can use github.  If I do host it on my server, I have registered the domain name emdrive.science for our purposes.

@tidux-
+1 for this, I've been clamoring to use source control for the MEEP assets for awhile.  While for folks who haven't used Git before there might be a small learning curve, the payoff in having everything 100% organized, backed up, and annotated with a complete history, will far outweigh that.

I have a Gitlab Community instance already running on the http://emdrive.wiki server so we can alternatively set up a public repo there - for access PM me.  But frankly Github might be the best option as it would be a bit harder for the Men In Black to take that offline when they finally decide to.  :)


Offline leomillert

  • Member
  • Posts: 34
  • Liked: 21
  • Likes Given: 12
@tidux
Sounds great!
Concerning the revision control software to be used, I think it boils down to what you prefer, since I believe you would be the one dealing with it more than others. Git, mercurial, fossil, anything goes. (as long as it's not svn, obviously).
It would also be good to have a folder for post-processed data (from Doctor Rodal) and observations/conclusions from such data (mostly also from Doctor Rodal). Maybe it could be even in an HTML format, so it's more accessible for readers. You could teach him to edit it directly.
These are great times, contribution is getting really organized and tidy. Good work, everyone.

@saucyjack
Users who have never used git and don't have the time/desire to learn it can continue uploading their files as attachments here on the forum and we commit it to the emdrive.science repository. (Although ideally they would learn to use the revision control system of choice).
There could be a github mirror of emdrive.science's cgit for backup, if you are worried about "Men In Black", but I really don't see a reason to be.
« Last Edit: 07/20/2015 07:27 pm by leomillert »

Offline flux_capacitor

  • Full Member
  • ****
  • Posts: 708
  • France
  • Liked: 860
  • Likes Given: 1076
I suspect everyone has seen some version of Escape Dynamic's microwave-powered shuttle at this point, but just in case, here's a short (and badly written) article that includes a nice bit of embedded animation. It's only vaguely related, but hey, it is a spacecraft proposal, and it is using microwaves, so... here you go.

http://www.engadget.com/2015/07/20/escape-dynamics-microwave-spacecraft/

As several people have pointed out, the energy losses in using the kind of microwave sources that ED is proposing would seem to be pretty daunting. Of course, much could be solved if they could instead smack their shuttle with Masers.

Side benefit: developing the requisite high Q-factor microwave cavities necessary for building all those big Masers might give an opportunity to test... some other theories.
http://escapedynamics.com/technology/hpm-2/
500 KW CW @92 GHz good enough?  :P

It reminds me of Leik Myrabo's Lightcraft. A propellantless concept based at the beginning on firing a laser from the ground onto a metallic disk shaped like a citrus squeezer. The concept evolved into a magnetohydrodynamic saucer powered by microwaves emitted from the ground. Besides onboard electric power generation through a "rectenna", the microwaves were also aimed to ionize the air surrounding the aircraft, to create a plasma on which Lorentz forces could act upon, for propulsion (MHD slipstream accelerator) and also focused ahead of the aircraft through parabolic microwave reflectors to create a "plasma air spike" mitigating and deflecting the front shockwave. Myrabo wrote a book about that concept, entitled Lightcraft Flight Handbook LTI-20: Hypersonic Flight Transport for an Era Beyond Oil. Interesting lecture…



I wonder if a space launch platform lifted by EmDrives could be powered by microwaves emitted from the ground. Instead of converting the microwaves to electric power onboard through lossy rectennas, the microwaves would be directed into the cavities. No electric conversion!
« Last Edit: 07/20/2015 07:40 pm by flux_capacitor »

Offline leomillert

  • Member
  • Posts: 34
  • Liked: 21
  • Likes Given: 12
I have a further suggestion: make all files public-domain. Specially all .ctl files.
That way anyone can benefit from the work without any kind of bureaucracy.
Public-domain helps the advancement of science.
« Last Edit: 07/20/2015 07:31 pm by leomillert »

Offline saucyjack

  • Member
  • Posts: 21
  • San Francisco
  • Liked: 34
  • Likes Given: 1
I have a further suggestion: make all files public-domain. Specially all .ctl files.
That way anyone can benefit from the work without any kind of bureaucracy.
Public-domain helps the advancement of science.

Completely agree - repo should be publicly browseable, with accounts only needed for people committing.  And ignore my "Men In Black" bad joke...

If you want me to set this up on the wiki server, let me know; would just take a few minutes.

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5911
  • USA
  • Liked: 6124
  • Likes Given: 5564
...I do not recommend using Google Drive for this.  We'll be dealing with small text files (typical csv output size is 1.4MB, control files are only a few K), possibly hundreds of them.  A source control repository is a much better solution for our use case...
It depends on what one means by better.  If the files go into the Google Drive, and I have share permission for the drive, they go automatically into my Google Drive, and the program I wrote in Wolfram Mathematica can access them and process them without intervention from me.   Due to my daily job I wouldn't have the time to go click and download files from a place where human intervention is required to find the files and download the files.

So, unless the csv files are available such that they get automatically into my computer drives (*), without me having to click and download files (which is the case for Google Drive, because they go directly into my several computers) I would not be able to process the csv files.


(*) or that the files are in a server with the files accessible by http (no passwords !!) in a structured way that I can program into Mathematica- that would also work, as I can have  Mathematica automatically download from http  (no passwords !!)
« Last Edit: 07/20/2015 07:51 pm by Rodal »

Offline leomillert

  • Member
  • Posts: 34
  • Liked: 21
  • Likes Given: 12
I have a further suggestion: make all files public-domain. Specially all .ctl files.
That way anyone can benefit from the work without any kind of bureaucracy.
Public-domain helps the advancement of science.

Completely agree - repo should be publicly browseable, with accounts only needed for people committing.  And ignore my "Men In Black" bad joke...

If you want me to set this up on the wiki server, let me know; would just take a few minutes.

tidux will do most heavy computing,  so I think it would be better to have it set up on his emdrive.science. (but let's wait to see his opinion).
Maybe we could use the wiki to detail the structure of the repository (its folders and files), how someone can commit, etc. What do you think?


Offline leomillert

  • Member
  • Posts: 34
  • Liked: 21
  • Likes Given: 12
(*) or that the files are in a server with the files accessible by http (no passwords !!) in a structured way that I can program into Mathematica- that would also work, as I can have  Mathematica automatically download from http  (no passwords !!)

That's possible with both cgit, cvs and mercurial.

Here are examples of all 3 of them in action for other projects:
http://git.zx2c4.com/cgit/tree/ (files in black, folders in blue)
http://cvsweb.netbsd.org/bsdweb.cgi/?only_with_tag=MAIN
http://hg.savannah.gnu.org/hgweb/octave/file/131ce8cfaa80

All folders and files are accessible and downloadable from http.
I think most people are used to git (and its web-interface, cgit).
« Last Edit: 07/20/2015 08:12 pm by leomillert »

Offline Rodal

  • Senior Member
  • *****
  • Posts: 5911
  • USA
  • Liked: 6124
  • Likes Given: 5564
Could you clarify why in the Wiki page it shows NWPU Prof. Juan Yang's test showed TE012 mode and in this you state mode TM11?

Nice piece of work Aero and Dr. Rodal!!!
Was the antenna placed to excite a TM (transverse magnetic) mode instead of trying to excite a TE (transverse electric mode)?


I'm not sure about the M here, I'm pretty sure about the 11


My understanding is that the antenna is identical to rfmwguy except the placement

Quote from: aero
Same antenna, 58 mm in the y direction, Ez excitation.

(set! antlongx 0)                               ; direction vector of dipole antenna SI units
(set! antlongy 0.058)                           ; = 58 mm
(set! antlongz 0)


Many modes nearby, which mode you excite has a lot to do with the antenna placement.

Shell, I have verified that the mode that was excited in the Yang/Shell model discussed in my stress and force calculations (http://forum.nasaspaceflight.com/index.php?topic=37642.msg1406306#msg1406306 and http://forum.nasaspaceflight.com/index.php?topic=37642.msg1406307#msg1406307 and http://forum.nasaspaceflight.com/index.php?topic=37642.msg1406309#msg1406309) was TM11, transversely magnetic m=1, n=1.  The "Mexican Hat" [no, I'm not Mexican :)  , but Alcubierre is Mexican] shape of the stress tensor at the small end



 is exactly the shape of the normal stress component one expects for mode TM11 (under steady state standing waves).   The fact that the stress at the big end does not have the two crescent patterns at the periphery must be due to the close proximity of the antenna to the big end disturbing the standing wave formation.

As to why TM11 was excited instead of TE01 that you were expecting, my understanding is that this is due to the fact that the antenna was placed to excite a TM (transverse magnetic) mode.
« Last Edit: 07/20/2015 08:30 pm by Rodal »

Offline Eer

  • Full Member
  • ****
  • Posts: 619
  • Liked: 460
  • Likes Given: 909
I have a further suggestion: make all files public-domain. Specially all .ctl files.
That way anyone can benefit from the work without any kind of bureaucracy.
Public-domain helps the advancement of science.

Completely agree - repo should be publicly browseable, with accounts only needed for people committing.  And ignore my "Men In Black" bad joke...

If you want me to set this up on the wiki server, let me know; would just take a few minutes.

tidux will do most heavy computing,  so I think it would be better to have it set up on his emdrive.science. (but let's wait to see his opinion).
Maybe we could use the wiki to detail the structure of the repository (its folders and files), how someone can commit, etc. What do you think?

I concur on git, and suggest a clone on two sites is a good idea.  Time I learned git.

I'd still like to see a file/directory/test-run naming convention.  The hierarchy proposed is a good start down that direction, but a uniform naming convention makes sense when there are multiple providers as well as multiple consumers.

One question I have - who is expecting whom to hack on control files?  How will the modifications be validated / verified against test objectives?  I don't feel qualified, at either the lisp, the scheme, the meep script, nor scientific or engineering basis to make ANY sort of valid judgments as to how things should be coded.
From "The Rhetoric of Interstellar Flight", by Paul Gilster, March 10, 2011: We’ll build a future in space one dogged step at a time, and when asked how long humanity will struggle before reaching the stars, we’ll respond, “As long as it takes.”

Offline saucyjack

  • Member
  • Posts: 21
  • San Francisco
  • Liked: 34
  • Likes Given: 1
tidux will do most heavy computing,  so I think it would be better to have it set up on his emdrive.science. (but let's wait to see his opinion).
Maybe we could use the wiki to detail the structure of the repository (its folders and files), how someone can commit, etc. What do you think?

Good idea, I am happy to document this on the wiki once the repo is in place.

To @Rodal's point, I believe you were trying to avoid downloading files manually.  While what @leomillert said is correct (depending the server software that will be used; Github for example has web access built in), you won't need to access the file URLs via that mechanism if you don't want to.

By switching to Git, you'll be able to pull down all the updates on-demand via a single 'git pull' command, which will sync everything to your local directory (just like Google Drive does automatically).  You won't have to download anything manually.  I will add a quick primer on Git to the wiki, but that command is really almost all you'd have to know to be up and running.  There are also a number of GUI clients you can use if you'd rather not use a DOS or Mac terminal window.

Offline leomillert

  • Member
  • Posts: 34
  • Liked: 21
  • Likes Given: 12
I have a further suggestion: make all files public-domain. Specially all .ctl files.
That way anyone can benefit from the work without any kind of bureaucracy.
Public-domain helps the advancement of science.

Completely agree - repo should be publicly browseable, with accounts only needed for people committing.  And ignore my "Men In Black" bad joke...

If you want me to set this up on the wiki server, let me know; would just take a few minutes.

tidux will do most heavy computing,  so I think it would be better to have it set up on his emdrive.science. (but let's wait to see his opinion).
Maybe we could use the wiki to detail the structure of the repository (its folders and files), how someone can commit, etc. What do you think?

I concur on git, and suggest a clone on two sites is a good idea.  Time I learned git.

I'd still like to see a file/directory/test-run naming convention.  The hierarchy proposed is a good start down that direction, but a uniform naming convention makes sense when there are multiple providers as well as multiple consumers.

One question I have - who is expecting whom to hack on control files?  How will the modifications be validated / verified against test objectives?  I don't feel qualified, at either the lisp, the scheme, the meep script, nor scientific or engineering basis to make ANY sort of valid judgments as to how things should be coded.

It's very easy to open the .ctl file and change single values for sensitivity analysis, anyone can do that.
However, I believe only aero has a good understanding of the model as a whole so far.
Maybe we should, once the repository is set-up and all the .ctl files in place, post about this on the MEEP mailing list ( http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss ) and see if we find more experts on the field interested in contributing. Let's see, time will tell.

Offline deltaMass

  • Full Member
  • ****
  • Posts: 955
  • A Brit in California
  • Liked: 671
  • Likes Given: 275
annus veritas for the EM Drive
Sorry: you need the genitive singular of the feminine gender (3rd declension) noun for "truth" (veritas) - hence: Annus veritatis

Tags:
 

Advertisement NovaTech
Advertisement Northrop Grumman
Advertisement
Advertisement Margaritaville Beach Resort South Padre Island
Advertisement Brady Kenniston
Advertisement NextSpaceflight
Advertisement Nathan Barker Photography
1