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

Offline deltaMass

  • Full Member
  • ****
  • Posts: 955
  • A Brit in California
  • Liked: 671
  • Likes Given: 275
If a space-based test is to merely indicate whether an EmDrive provides thrust, then all that's required is to establish a time correlation between drive power on/off activity and measured acceleration.

Offline Prunesquallor

  • Full Member
  • *
  • Posts: 174
  • Currently, TeV Brane Resident
  • Liked: 157
  • Likes Given: 73
If a space-based test is to merely indicate whether an EmDrive provides thrust, then all that's required is to establish a time correlation between drive power on/off activity and measured acceleration.

Maybe, if the differences are (once again) outside the environmental "noise".  If the expected thrust is an order of magnitude or two above the somewhat unpredictable (and sometimes variable) drag effects, great.  If not, then it's not clear it was worth the effort.

Edit: typo
« Last Edit: 07/20/2015 01:08 am by Prunesquallor »
Retired, yet... not

Offline ElizabethGreene

  • Member
  • Posts: 69
  • Nashville, Tennessee
  • Liked: 138
  • Likes Given: 3

I find it laughable to even talk about spaceships and missions without even having an established and widely accepted, repeatable science behind it. It baffles me to read time and again that Mr. Shawyer is sitting on the holy grail of propulsion, but doesn't seem to be willing to publicly present a current device that produces Newtons of thrust, as claimed by him since quite a long time now.

I respectfully disagree on both points.  Regarding hypothetical mission profiles, I've been reading about https://en.wikipedia.org/wiki/Alcubierre_drive Alcubierre Drives for two decades.  Mars Direct mission profiles based on uninvented but plausible technology have been around a very long time as well.  Add to this uncountable hours of fantasy around warp drives, wormholes, and other means of faster-than light travel.  How is this substantively different or less outrageous than hypothetical emdrive mission profiles based on thrust levels within a few orders of magnitude of what you can build in your own garage with microwave oven parts?  Without these dreams space is just a big expensive empty place.

To your second point, Mr. Shawyer has been shouting from rooftops for a decade about patented working and demonstrable technology.  He has been conspicuously ignored, laughed at, and called charlatan fraud.  On this very forum are people who, despite zero effort in replication, deride emdrive technology as an impossible unworkable fools errand.  Parallel to this you have the folks over at the Cannae drive shop who have managed to patent core emdrive technology that stomps all over over Mr. Shawyer's existing IP.  If SPR believes it is in their best interest to not publish any more data or share their newest work then that is their hard earned and battle-won prerogative.

Respectfully.

Offline Prunesquallor

  • Full Member
  • *
  • Posts: 174
  • Currently, TeV Brane Resident
  • Liked: 157
  • Likes Given: 73

I find it laughable to even talk about spaceships and missions without even having an established and widely accepted, repeatable science behind it. It baffles me to read time and again that Mr. Shawyer is sitting on the holy grail of propulsion, but doesn't seem to be willing to publicly present a current device that produces Newtons of thrust, as claimed by him since quite a long time now.

I respectfully disagree on both points.  Regarding hypothetical mission profiles, I've been reading about https://en.wikipedia.org/wiki/Alcubierre_drive Alcubierre Drives for two decades.  Mars Direct mission profiles based on uninvented but plausible technology have been around a very long time as well.  Add to this uncountable hours of fantasy around warp drives, wormholes, and other means of faster-than light travel.  How is this substantively different or less outrageous than hypothetical emdrive mission profiles based on thrust levels within a few orders of magnitude of what you can build in your own garage with microwave oven parts?  Without these dreams space is just a big expensive empty place.

To your second point, Mr. Shawyer has been shouting from rooftops for a decade about patented working and demonstrable technology.  He has been conspicuously ignored, laughed at, and called charlatan fraud.  On this very forum are people who, despite zero effort in replication, deride emdrive technology as an impossible unworkable fools errand.  Parallel to this you have the folks over at the Cannae drive shop who have managed to patent core emdrive technology that stomps all over over Mr. Shawyer's existing IP.  If SPR believes it is in their best interest to not publish any more data or share their newest work then that is their hard earned and battle-won prerogative.

Respectfully.

On your first point, I agree.  I remember early comments (not on this forum) of the perceived minuscule thrust levels that were reported for the NASA experiments and how they had no practical implications.  The NASA IEEE paper in particular I think illustrates that milli-g acceleration can be quite impressive.  YES there are CoM issues, YES there are CoE issues.  YES we don't know the operational characteristics (if any) of EM Drive.  I think there is value in discussing POSSIBILITIES to put the potential in perspective, otherwise we are adrift.

Edit: Comment added for emphasis.
« Last Edit: 07/20/2015 01:10 am by Prunesquallor »
Retired, yet... not

Offline kdhilliard

  • Full Member
  • ****
  • Posts: 1082
  • Kirk
  • Tanstaa, FL
  • Liked: 1572
  • Likes Given: 4080
The Space Show has posted this coming week's newsletter, and:

* Tuesday, July 21, 2015; 7-8:30 PM PDT (10-11:30 PM EDT): Dr. JIM WOODWARD back to update us on his work with a Mach effect drive impulse engine and gravitational physics.

~Kirk

Offline rfmwguy

  • EmDrive Builder (retired)
  • Senior Member
  • *****
  • Posts: 2205
  • Liked: 2713
  • Likes Given: 1134
Meepers...here's a video that describes my antenna placement in NSF-1701:


Offline Rodal

  • Senior Member
  • *****
  • Posts: 5911
  • USA
  • Liked: 6124
  • Likes Given: 5564
For a comparison of time to reach "steady state" from a completely different model of the EM Drive, here is Dr. White's Quantum Vacuum code calculations (last slide I remember seeing):



Notice:

                              Dr. White QV code        Meep rfmwguy "NSF 1701"
Time step                7.17 picoseconds           2.001 picoseconds
Max time run           1.076 microseconds       0.013 microseconds
Max # steps run       150,000                       6,527


That's a hundred times longer than what Meep has been run up to now.  We see the recurring theme that one needs to run a simulation to at least 1 microsecond duration.
« Last Edit: 07/20/2015 01:17 am by Rodal »

Offline ZuluMoon99

  • Member
  • Posts: 11
  • UK
  • Liked: 7
  • Likes Given: 35
I notice that the Aachen boys have gone quiet.

deltamass

when I checked on Thursday they were in the middle of a redesign - their old setup was causing too many measurement problems.


Offline Prunesquallor

  • Full Member
  • *
  • Posts: 174
  • Currently, TeV Brane Resident
  • Liked: 157
  • Likes Given: 73
According to present data, testing the EMDrive with input powers at or above 1 MW is necessary to reach a thrust that can actually be experienced without doubt of measurement errors.

Achieving a thrust level high enough to lift an object would (as done by Goddard with chemical rockets) finally convince people to adequately fund R&D in this area.

Let us gather enough supporters to send an E-Mail to Mythbusters.

They definitely have the money and means to use a Gyrotron, Klystron or a similar powerful microwave source and build a simple truncated cone microwave resonator to see whether they can achieve a level of thrust high enough to convince people to fund adequate R&D in this area.

And in exactly what way is a show that throws together a demonstration in a week with the ultimate goal of blowing it up if it doesn't work going to advance the cause?
Retired, yet... not

Offline rfmwguy

  • EmDrive Builder (retired)
  • Senior Member
  • *****
  • Posts: 2205
  • Liked: 2713
  • Likes Given: 1134
The Space Show has posted this coming week's newsletter, and:

* Tuesday, July 21, 2015; 7-8:30 PM PDT (10-11:30 PM EDT): Dr. JIM WOODWARD back to update us on his work with a Mach effect drive impulse engine and gravitational physics.

~Kirkz
Interesting...bet if he followed this thread, he could book lots of guests. Probably been a while since there was grassroots/collaborative space research efforts such as what we have here...perhaps never ;)

Offline LasJayhawk

We see this a lot. Someone at the test site is playing with a high power S band transmitter. Could be almost anything, including EM drive testing

http://s1365.photobucket.com/user/LASJayhawk/media/c860b277-9e8c-4a21-9c00-3c113f89c159_zpst4vaiem9.jpg.html

http://i1365.photobucket.com/albums/r745/LASJayhawk/c860b277-9e8c-4a21-9c00-3c113f89c159_zpst4vaiem9.jpg

X marks the spot.
« Last Edit: 07/20/2015 01:04 pm by Chris Bergin »

Offline tidux

  • Member
  • Posts: 13
  • Sol III
  • Liked: 6
  • Likes Given: 3
Meepers...here's a video that describes my antenna placement in NSF-1701:



Here's the output of h5totxt -t 13 -0 -y -0  ex.h5 for both the "standard" NSF-1701.ctl (centered antenna, small end) and for the small end offset as shown in the video.  I'm still working out how to modify the antenna placement variables to put it on the larger end, but once that's done I'll run those and upload the output as well.

http://borg.moe/data/NSF-1701-normal-zCopper-exy.csv
http://borg.moe/data/NSF-1701-asymmetrical-zCopper-exy.csv

I still have the h5 files on disk for these runs, so if you need a different set of data, or even the raw files, I can tar/zip them up and copy those to my webserver directory in a matter of seconds.

Offline leomillert

  • Member
  • Posts: 34
  • Liked: 21
  • Likes Given: 12
For a comparison of time to reach "steady state" from a completely different model of the EM Drive, here is Dr. White's Quantum Vacuum code calculations (last slide I remember seeing):



Notice:

                              Dr. White QV code        Meep rfmwguy "NSF 1701"
Time step                7.17 picoseconds           2.001 picoseconds
Max time run           1.076 microseconds       0.013 microseconds
Max # steps run       150,000                       6,527


That's a hundred times longer than what Meep has been run up to now.  We see the recurring theme that one needs to run a simulation to at least 1 microsecond duration.

tidux can get the current meep model done in about 45 minutes with 8 threads out of his 12 threads. Considering it scales linearly, he could get a performance of 30 minutes.
So, <0.5 hour / 0.013 microseconds>. So it would take tidux's server just a little bit over 2 days to complete 1.3 microseconds, which is completely reasonable on my opinion. Do you believe it would be a good use for his server, Doctor Rodal? And what do you think, Mister tidux?

Offline tidux

  • Member
  • Posts: 13
  • Sol III
  • Liked: 6
  • Likes Given: 3
For a comparison of time to reach "steady state" from a completely different model of the EM Drive, here is Dr. White's Quantum Vacuum code calculations (last slide I remember seeing):



Notice:

                              Dr. White QV code        Meep rfmwguy "NSF 1701"
Time step                7.17 picoseconds           2.001 picoseconds
Max time run           1.076 microseconds       0.013 microseconds
Max # steps run       150,000                       6,527


That's a hundred times longer than what Meep has been run up to now.  We see the recurring theme that one needs to run a simulation to at least 1 microsecond duration.

tidux can get the current meep model done in about 45 minutes with 8 threads out of his 12 threads. Considering it scales linearly, he could get a performance of 30 minutes.
So, <0.5 hour / 0.013 microseconds>. So it would take tidux's server just a little bit over 2 days to complete 1.3 microseconds, which is completely reasonable on my opinion. Do you believe it would be a good use for his server, Doctor Rodal? And what do you think, Mister tidux?

It's not quite half an hour at 12 threads, it's closer to 35 minutes, but that's close enough to linear scale for our purposes.

I'm willing if Dr. Rodal thinks it would provide useful data.  The system is located in a datacenter, not my home, so there aren't any issues with noise, heat, or power failures from running a two day job.

Offline deltaMass

  • Full Member
  • ****
  • Posts: 955
  • A Brit in California
  • Liked: 671
  • Likes Given: 275
Good for you

Online Eer

  • Full Member
  • ****
  • Posts: 624
  • Liked: 466
  • Likes Given: 913
Alright - here we go.

With help from tidux and leomillert I am reporting my results of running meep-mpi against the NSF-1701.ctl file attached.

The zCopper-exy.csv that I produce is different from the file I've been comparing it to from Aero - I took it from https://drive.google.com/folderview?id=0B1XizxEfB23tfmkxNm1Ha1YxR1NZU2ZjUUpBUVVGV0M4QUVxaGYySEVFam5jVzdRYy0tSWs&usp=sharing the file zCopper-exy.csv.

Aero's file has 247 rows, and mine produces 245.  Aero's file has jd columns, mine has ja. 

However, I get the same results as tidux.

Attached is the NSF-1701.ctl file I used, and a three-sheet spreadsheet (zCopper-exy-eer1p.ods) holding (a) my zCopper-exy-eer1p sheet, (b) tidux' NSF-1701-normal-zCopper-exy sheet, and (c) a Delta sheet calculating the difference of each cell of (a) and (b).  There are no differences.  The value in the Delta cell A247 is the max(a1:ja245), which is zero.

So - tidux and I match.  Either I am comparing to the wrong csv file from Aero, or we're out of sync in some other way.

For comparison, a second spreadsheet - zCopper-exy-aero.ods - compares my zCopper-exy-eer1p to Aero's zCopper-exy-aero sheets in a Delta sheet.  There, cell A249 shows the max of the absolute value of cell differences to be 0.004464033.

Please advise whether my results are accurate enough to contribute further.

I also suggest we get into a pattern of reporting results with a copy of the control file used and whatever output files we provide, all associated in some way (in a directory or zip file) noting a name or description of the run, who ran it, and when it was run (perhaps those things should be recorded on a data description sheet also included with the control run and output files).

Configuration management is about to be important, here, tracking inputs, outputs, and the configurations used to perform them (so they can be reproduced upon need).

Surely there are experimental data procedures already defined and well used by various communities for such things.

Note - I'm uploading ods format spreadsheet files because (a) we're all using Linux and so Open Office in one form or another is readily available to us all there, (b) when I tried to save in xls format - the older Excel format - it seems there were too many columns to be saved, so I switched to ods.  I believe that current Excel product from Microsoft can read ods files.

Ed
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 aero

  • Senior Member
  • *****
  • Posts: 3628
  • 92129
  • Liked: 1145
  • Likes Given: 360
Alright - here we go.

With help from tidux and leomillert I am reporting my results of running meep-mpi against the NSF-1701.ctl file attached.

The zCopper-exy.csv that I produce is different from the file I've been comparing it to from Aero - I took it from https://drive.google.com/folderview?id=0B1XizxEfB23tfmkxNm1Ha1YxR1NZU2ZjUUpBUVVGV0M4QUVxaGYySEVFam5jVzdRYy0tSWs&usp=sharing the file zCopper-exy.csv.

Aero's file has 247 rows, and mine produces 245.  Aero's file has jd columns, mine has ja. 

However, I get the same results as tidux.

Attached is the NSF-1701.ctl file I used, and a three-sheet spreadsheet (zCopper-exy-eer1p.ods) holding (a) my zCopper-exy-eer1p sheet, (b) tidux' NSF-1701-normal-zCopper-exy sheet, and (c) a Delta sheet calculating the difference of each cell of (a) and (b).  There are no differences.  The value in the Delta cell A247 is the max(a1:ja245), which is zero.

So - tidux and I match.  Either I am comparing to the wrong csv file from Aero, or we're out of sync in some other way.

For comparison, a second spreadsheet - zCopper-exy-aero.ods - compares my zCopper-exy-eer1p to Aero's zCopper-exy-aero sheets in a Delta sheet.  There, cell A249 shows the max of the absolute value of cell differences to be 0.004464033.

Please advise whether my results are accurate enough to contribute further.

I also suggest we get into a pattern of reporting results with a copy of the control file used and whatever output files we provide, all associated in some way (in a directory or zip file) noting a name or description of the run, who ran it, and when it was run (perhaps those things should be recorded on a data description sheet also included with the control run and output files).

Configuration management is about to be important, here, tracking inputs, outputs, and the configurations used to perform them (so they can be reproduced upon need).

Surely there are experimental data procedures already defined and well used by various communities for such things.

Note - I'm uploading ods format spreadsheet files because (a) we're all using Linux and so Open Office in one form or another is readily available to us all there, (b) when I tried to save in xls format - the older Excel format - it seems there were too many columns to be saved, so I switched to ods.  I believe that current Excel product from Microsoft can read ods files.

Ed

As I wrote in reply to you in PM, I expect that you both have good installs. Chances of both being identically bad installs aren't worth considering.
As for comparing csv files with different number of Rows or columns, don't do that. They're different, and there is no "close enough."

Attached find a current copy of NSF-1701. I think you'll find it a little easier to work with because you will have to modify it. It is a control file after all, and if you make two runs in a row with the same control settings, something isn't working.

As for data control measures. Yes we need something like that, and we need a mechanism for the physicist and DIYers in our  community to request data, in a hard numbers sort of way. After all, building the cavity is an engineering job, and building a model of the cavity requires engineering data too. Maybe not as many numbers but they are needed just as badly. We need a mechanism to communicate the need for data to the meeper generating the data.

Retired, working interesting problems

Offline TheTraveller

.....
Just got this looks sweet.

The SA0314 looks very interesting. Price is good.
http://www.rfinstruments.com/php/pdf/SA0314%20datasheet.pdf

You should be able to measure and record the output power bandwidth of your magnetron and if you barely insert the tip of a probe inside your frustum (good to put in some attenuation so you don't blow the input stage of the spectrum analyser), should see the acceptance bandwidth of your frustum and record. Can then compare the charts to work out which of the magnetron frequencies are being accepted by your frustum and which are being rejected.

Is that how you plan to use this?
« Last Edit: 07/20/2015 05:21 am by TheTraveller »
It Is Time For The EmDrive To Come Out Of The Shadows

Offline tidux

  • Member
  • Posts: 13
  • Sol III
  • Liked: 6
  • Likes Given: 3
Alright - here we go.

With help from tidux and leomillert I am reporting my results of running meep-mpi against the NSF-1701.ctl file attached.

The zCopper-exy.csv that I produce is different from the file I've been comparing it to from Aero - I took it from https://drive.google.com/folderview?id=0B1XizxEfB23tfmkxNm1Ha1YxR1NZU2ZjUUpBUVVGV0M4QUVxaGYySEVFam5jVzdRYy0tSWs&usp=sharing the file zCopper-exy.csv.

Aero's file has 247 rows, and mine produces 245.  Aero's file has jd columns, mine has ja. 

However, I get the same results as tidux.

Attached is the NSF-1701.ctl file I used, and a three-sheet spreadsheet (zCopper-exy-eer1p.ods) holding (a) my zCopper-exy-eer1p sheet, (b) tidux' NSF-1701-normal-zCopper-exy sheet, and (c) a Delta sheet calculating the difference of each cell of (a) and (b).  There are no differences.  The value in the Delta cell A247 is the max(a1:ja245), which is zero.

So - tidux and I match.  Either I am comparing to the wrong csv file from Aero, or we're out of sync in some other way.

For comparison, a second spreadsheet - zCopper-exy-aero.ods - compares my zCopper-exy-eer1p to Aero's zCopper-exy-aero sheets in a Delta sheet.  There, cell A249 shows the max of the absolute value of cell differences to be 0.004464033.

Please advise whether my results are accurate enough to contribute further.

I also suggest we get into a pattern of reporting results with a copy of the control file used and whatever output files we provide, all associated in some way (in a directory or zip file) noting a name or description of the run, who ran it, and when it was run (perhaps those things should be recorded on a data description sheet also included with the control run and output files).

Configuration management is about to be important, here, tracking inputs, outputs, and the configurations used to perform them (so they can be reproduced upon need).

Surely there are experimental data procedures already defined and well used by various communities for such things.

Note - I'm uploading ods format spreadsheet files because (a) we're all using Linux and so Open Office in one form or another is readily available to us all there, (b) when I tried to save in xls format - the older Excel format - it seems there were too many columns to be saved, so I switched to ods.  I believe that current Excel product from Microsoft can read ods files.

Ed

We need an accessible way to put the control files under version control, possibly on github.  Then we can use the hex hash identifying which git commit of the control file we're using to name output files.

If there's a better option that's more friendly to CAD files (git is notoriously sucky with large binaries), I could get behind that as well.

Offline SeeShells

  • Senior Member
  • *****
  • Posts: 2442
  • Every action there's a reaction we try to grasp.
  • United States
  • Liked: 3186
  • Likes Given: 2708
.....
Just got this looks sweet.

The SA0314 looks very interesting. Price is good.
http://www.rfinstruments.com/php/pdf/SA0314%20datasheet.pdf

You should be able to measure and record the output power bandwidth of your magnetron and if you barely insert the tip of a probe inside your frustum (good to put in some attenuation so you don't blow the input stage of the spectrum analyser), should see the acceptance bandwidth of your frustum and record. Can then compare the charts to work out which of the magnetron frequencies are being accepted by your frustum and which are being rejected.

Is that how you plan to use this?
That is one way and the other is to record the baseline activity inside and outside the faraday cages when it's off.

Tags:
 

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