Von Rennenkampff vs Mick West: Syria UAP Video Debate
- Source: X/Twitter thread
- Date: ~May 1, 2026
- Participants: @MvonRen (Marik von Rennenkampff), @MickWest (Mick West)
- Retrieved: 2026-05-08 via fxtwitter API
@MvonRen (opening)
@MickWest BREAKING:
UAP ‘DEBUNKER’ MICK WEST CAUGHT CHEATING
West falsified data from the Syria UAP video to make the object’s instantaneous acceleration APPEAR to be an artifact of camera movement.
His 3D sim deviates from the true data the instant the UAP accelerates.
SHAMEFUL.
@MickWest (response)
@MvonRen You continue to either misunderstand or misrepresent this. Maybe both.
@MvonRen
@MickWest Your 3D sim deviates significantly from the data the instant the object accelerates.
(Pre-acceleration deviation is ~1-2. Post-acceleration, it’s 11.)
You’ve been caught cheating red-handed.
Not only do the data prove instant acceleration, background motion does too.
@MickWest (detailed response)
It’s unfortunate that Marik would take his misunderstanding of this numerical difference and immediately say I’m “cheating”.
The sim, in this case, is driven by the number on the on-screen display in the video. The two numbers are the “Easting” and “Northing” positions, at meter resolution, within a square of terrain. The system lacks a DEM (a Digital Elevation Model), and is locked at assuming the ground is at 1725 feet. That virtual point derived from the OSD (On Screen Display, the numbers on screen) and the 1725 feet (actually 2000 feet underground) is used to calculate a line of sight from the MQ9, and that’s what drives the camera. That’s what creates the zip-off. No cheating there.
The numbers in the sim differ because the OSD numbers are not the true numbers. They only change every few frames. We see the camera move continuously; it does not jump and then freeze every few frames. The motion is not jerky or stepped; it’s a smooth curve. Marik shows four frames where the OSD is at 92948, but the sim numbers go from …49 (frame 1203) to 56 (frame 1206). This is because at frame 1208, the OSD changes to 60, so in between it must PHYSICALLY be increasing from 48 to 60. That’s what the sim does, to try to be as accurate as possible. You see this in the graph in the attached image, frame 1206 is selected, and it’s between 1203 and 1208, so the value is interpolated.
This is much closer to the physical reality than stair-stepping through the values, which Marik seems to be suggesting.
But it’s not even the most accurate. The true reality of the situation is lost, and we only have these imperfect recordings. You see I’m doing a straight line interpolation, which still has improbable discontinuities. The real motion would be more curved, and we can’t say exactly what those curve values were because we have an imperfect recording using imperfect equipment.
A slightly better recording exists. We know that @JeremyCorbell has a full recording at the original framerate (still terrible quality, but better than what we have), but he refuses to release it.
We’ll probably get a version from the government, thanks to @RepLuna, but that will almost certainly have the OSD redacted and not be very useful. So hopefully Jeremy will release what he has, and then I can do a more precise analysis.
@MvonRen
@MickWest False, @MickWest, and you know it.
The camera/background moves vertically only AFTER the object begins accelerating. See below.
Your manipulations aside, this is confirmed 100% in the data.
Causality 101: Effects (acceleration) cannot precede causes (change in camera motion)
@MickWest
@MvonRen That’s an entirely different claim from the first one. One thing at a time, please.
I assume you are retracting your claim that I was falsifying data? You understand now why the numbers on-screen are different?
@MvonRen
@MickWest Absolutely not, @MickWest.
Your “interpolation” consists of falsified data to fit your preferred conclusion.
We can prove that you falsified data:
Background/camera motion changes the instant the MGRS “northing” data jumps.
UAP accelerates BEFORE camera motion changes.