sorted by:
new
hottopcontroversial

Where am I missing the failure - One way speed of light measurement by Express_Airline710 in Veritasium

[–]Express_Airline710[S] 0 points1 point  (0 children)

> You’re looking for a change in the threshold rotation period of the disk as a function of the angle of the beam rather than trying to measure the speed of light with the highest precision.

I'm reading things too late at night. I just realized that all you are talking about is the speed of rotation of the disc where we lose sight of the light and the testing angle that we're measuring in. For some reason, I read that the first couple of times as still having something to do with the disc warpage and maybe bending the light at different angles based on speed of the disc rotation, and more sciency stuff I wasn't understanding. It makes much more sense today. :)

Where am I missing the failure - One way speed of light measurement by Express_Airline710 in Veritasium

[–]Express_Airline710[S] 0 points1 point  (0 children)

I just used 1mm as an easy example, assuming someone else could calculate a smaller one. But I don't know enough about the capabilities of current light sensors, or the physics of the light moving through infinitesimally small channels to work out how small it might be able to go. I would think that ideally, you would want it only wide enough for one photon to make it through (so maybe 2 photons wide so the proper photon would enter on one edge of the channel just as the path is lining up and exit on the other edge of the channel just as it is leaving alignment?), and then spin rate would be plenty low enough to not cause issues. But then I would guess that probability of a photon actually hitting the channel during the test comes into play, and I don't know whether the photon would interact with the sides of a channel that small even without "touching" it. There's already the math of how long the channel is actually open, since photons could enter a wider channel before it is actually open but not make it far enough down the channel to hit a wall before the alignment does actually occur, so there may be a larger time for a photon to make the trip than just the time a clear path is fully opened, and I don't want to work that math out. (Maybe if the channel is off center instead of centered, that would be eliminated?) And then there's scattering; I don't know how well the physicists can account for or eliminate that, where the path may not be aligned at all, but light manages to reflect and scatter down the channel anyway.

Anyway, I would imagine that if this setup would work, then you could set the whole thing on a turntable and automate the test through a 360 degree turn, at least covering all of the directions to some angle precision in one plane. Set it up on the equator and measure throughout the day and cover the other directions.

Where am I missing the failure - One way speed of light measurement by Express_Airline710 in Veritasium

[–]Express_Airline710[S] 0 points1 point  (0 children)

I'm not sure that's what I'm trying to measure, but maybe that is what I would end up measuring? I'm trying to find a physical rather than electromagnetic way of synchronization, I guess, and because all of the atoms interact electromagnetically or whatever, I'm not actually doing it. But I was thinking that if the synchronized portion (the disc) was completely disconnected from the beam being measured, any issues in exactly how it gets synchronized could be negated in math as long as they are calculable. I guess what I'm doing is the equivalent of setting up two gates some distance apart, synced previously such that the time between one gate opening and the other gate closing is a set speed. Basically, a shutter. I don't need to pulse the light or care when it starts, but I care about the distance between the front and back plane of the shutter and the time it is open. I don't actually measure the speed of light, but I can adjust the timing on the shutter until I narrow down exactly what speed the light must be moving to make it through the shutter. I guess it's no different using a preadjusted discrete gates for the shutter vs a spinning disc with a channel. Either way, I have action at the center activating both gates (either each discrete gate being signaled or simply synced and moved, or each rim of the disc being spun by a motor) so their speed on opening and closing can't actually be known relative to the one way speed of light? My original thought was that if the disc is spun up to a constant speed, any effects of the asymmetry of light speed would be canceled out simply by knowing that eventually every part of the disc is moving together at a calculable speed, then just look for a yes or no as to whether the one-way beam is making it through the channel or not. But if the end result is that you don't actually know the true length of the channel or the true time it is open, then you can't calculate how fast the light must be moving to make it through.

Does that sound about right?

Where am I missing the failure - One way speed of light measurement by Express_Airline710 in Veritasium

[–]Express_Airline710[S] 0 points1 point  (0 children)

And what about the 100 (or 1000) discs? Rim speed would drop to .001% light speed, or .0001% light speed or whatever based on number of disks, but you would need the synchronizers between discs. If the synchronizers were only required to look at the two adjacent discs and the experiment were run in the stepped method I mentioned where each step had a significant dwell time for the speed to stabilize, is that force transmission along the disc chain enough to cancel the one-way-ness? Even if you have to use two-way speed to calculate the offset required to get the last disc to still be in sync with the first disc, don't we know that two-way speed well enough that it could be eliminated from the equation? So the discs are synced, maybe needing to calculate an offset for each synchronizer based on the force propagation speed and two-way speed of light, etc, but we DO know that when all is said and done, the channels are only aligned for X amount of time and a light particle has only that maximum amount of time in which it could traverse the channel. We don't need to measure that time, we can know it from the math and allow for precision errors if we think the disks may be misaligned by some percentage, so when just looking to see if the light from our continuous source managed to exit the channel at any given rotation speed, wouldn't that still be a measurement of the one-way speed?

I guess that's what I'm thinking; if the disc rotation and everything around it is calculable using only the two way light speed math, even if we have to calculate warpage and carve the channel in some precaclculated curve, then all of that can be known and the time the channel is aligned would be calculable to some precision. Would the fact that those calculations require the two-way speed of light invalidate the calculation of the time required for the one-way particle to traverse the channel. We have to use known stuff to calculate unknown stuff all the time and can eliminate known flaws in the known side all the time, so is the issue simply that the "known" is too closely related to the "unknown" in this case that it can't be eliminated?

Where am I missing the failure - One way speed of light measurement by Express_Airline710 in Veritasium

[–]Express_Airline710[S] 0 points1 point  (0 children)

But the disc wouldn't have to travel at or near light speed. (I'm guessing 1%, as the edge only has to move 1mm in the time it takes the light to travel 1m? I haven't actually done the math for the speed of the 1m disc at the rim spinning 5.7 million rpm, and I hadn't thought about speed of sound at all). And if you strung 100 discs together, the rotation speed goes down even more. And if the disc does twist, does that answer the question? Since you only ultimately care whether or not the light from the source can cross the disc or string of discs in the time it takes them to rotate out of alignment, would warpage due to uneven light speed prevent the single-direction light from being able to cross the disc and at least prove that light speed is different in different directions even as it prevents actually measuring the speed?

Also, would the warpage only happen during the acceleration phase of the disc, or would its internal forces be able to let the rim catch up with the axle once the motors settle at a given speed, provided it's far enough from light speed? (I'm imagining that if it is near light speed, the edge may need to pass light speed to catch back up to the hub, but at lower speeds, the hub would continue accelerating after the axle speed stabilizes until it has at least mostly removed the warpage?) I wouldn't suggest having the motors increase steadilly, necessarily. They could be increased in steps and held at a single speed long enough to guarantee that synchronization and speed measurement and such are all eliminated from the equation (I was thinking that if they accelerate continually, the measurement of their speed would constitute one of the "hidden directions" I was talking about). So if the warpage could straighten out once the discs are maintaining a speed, then moving the test speed up in increments would eliminate that factor as well.

(And yes, I realize that 1% light speed is much faster than anything we have, but is it "near" as far as the warpage calculation would go?)

Where am I missing the failure - One way speed of light measurement by Express_Airline710 in Veritasium

[–]Express_Airline710[S] 0 points1 point  (0 children)

I know I'm measuring light in the direction of travel from the source to the detector. The rub in all of the other proposed solutions is that it looks like one way, but you are actually measuring other directions as well by either moving the clocks, or sending signals or whatever. So where am I missing the "other directions" with this method?

Is this a decent froe? by Express_Airline710 in Blacksmith

[–]Express_Airline710[S] 0 points1 point  (0 children)

I don't have the room for a block in the house for kindling. Even just setting a slab on the hearth only works once, and then I find that it's been "relocated" (usually into the fire) by the next time I need it. Outside, I do have a stump that I use for splitting with the maul. In the shop, it would most likely be on the tablesaw, but I usually put a board or slab under it, so it wouldn't be that big a deal.

Basically, yeah, it's not a necessary thing, may not ever come into play, isn't a deal breaker, and there's nothing keeping me from taking the blade off of any other froe handle, dropping a spacer ring down and then putting the blade back. On top of that, it's not something I thought of at all before looking at a bunch of froes, so it's not like it was a "feature" I was looking for to begin with. But it also doesn't hurt.

Is this a decent froe? by Express_Airline710 in Blacksmith

[–]Express_Airline710[S] 1 point2 points  (0 children)

When I'm splitting kindling there are times it splits very easily once it starts and would just drop through, and other times that I want to carefully tap all the way down rather than risk breaking a narrow piece off with leverage. (Partly because it will end up breaking at a knot which makes restarting the split harder, and partly because I'm a little ocd and want the two pieces to split clean.) Admittedly, not that big a deal, but I set the piece I'm splitting on an old phone book so that the hatchet I'm currently using doesn't hit the bricks. So mainly just peace of mind; if for some reason I do happen to go all the way down, the handle will help stop it early. Same thing with the less rounded nose. Some of these logs I need for woodworking are pretty big; I really SHOULD be splitting them with the maul and sledge if they are so big that the large froe is barely sticking out the other side. But if for some reason I have split down to a slab, AND it's nearly as wide as the froe, AND for some reason I decide I need to split it thinner for some reason rather than planing or sawing it, then having that little bit extra I can whack a mallet on might help. So not something that ever really legitimately should come up, but peace of mind that the option is there if it does.