Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations waross on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Miami Beach, Champlain Towers South apartment building collapse, Part 06 131

Status
Not open for further replies.
Replies continue below

Recommended for you

@3DSoftwareDev - great post and thanks for this, as actually some of your thoughts I had also had - and it was your initial analysis that prompted me to finally get off my behind and look at this video in detail which I'd meant to do for days, so thanks :)

I suspect you are right on the flash of light. Clearly in terms of cause/effect, if indeed the first image is a bug/still image, then I 100% concur this is what it is. Perhaps I have tried to make the image fit the theory too much on this specific element.

I do have an issue with the table/credenza thought though, as again this was something I had thought about quite a bit. Couple of reasons. First of all - people. If such a unit (which would even if small be of reasonable size) was in place, the occupant would have placed this unit in front of the large glass doors (or part of them) leading to the balcony. Now my feng shui isnt top notch (!) but this feels like a very odd thing to do. More likely is that this is a much smaller table (or shelf) that is tucked into the corner. Just from an aesthetics in the video perspective also, that far left pillar looks identical to the wall - it looks like plaster not furniture, albeit this is obviously hard to define well. Also, for such an amount of vibration and movement in the room, the camera (an inherently light item) is unbelievably still and consistent in relation to the furniture if not fixed to it. Its obviously not beyond the realms of possiblity that the camera has been secured to the tabletop, but again its not a "natural" thing for someone to do, especially in a $700k condo. The jolt at 7 seconds was significant enough not only to move the tv box, but the three boxes beside - it just doesnt feel right to me that the camera wouldnt move a cm or so if resting. I also dont think whatever it is resting on has any kind of "top" as otherwise the debris couldnt fall as far back as it does (probably).

Perhaps the killer piece - the brighter object to the left casts a shadow from the sensor from the camera. The pillar above does not, which implies it is further away than appears in the video, hence the view that it is the wall or door frame inside angle (that definitely exists in that location in that condo).

Could all be wrong. But all in all I really dont see this being "freestanding" furniture. I also struggle to believe that the box and this "table" would be the lightest two items in that room to move, especially compared to the stools sitting on smooth tile, and the glass sitting on the table.

That black object (fridge?) on the right is also troublesome. It (I think reasonably clearly) starts to develop a gap between the top of it and the wall. That doesnt fit with a downward to the right slope. It would fit with downward to the left, or with a right wall deformity where the top of the wall is moving further to the right - which could(?) tie in with the "bar" to the left of the camera being a wall and also moving to the right.

Feels like minutae detail - and it is. But you are right that if the far left "bar" is part of the furniture not part of the condo then a lot of my interpretation is off. But it just doesnt seem it to me, if it is then actually for me it creates many more questions than it answers (for example - if the room is tilted enough for that table to start to slide, theres no way in my view that the lighter boxes just in front, or the TV, dont start to tip or slide).
 
C41BE719-60B0-4196-8F21-6DEAA51DDEE4_psf5oi_fyvylb.jpg
 
@jbourne8 half a second delay is massive for humans, I think most people can detect audio delay from video under 150ms without too much issue.

I don't work with audio too much though, I mostly work with stuff where latency must be under 16ms and something like 50ms is considered a long time to me though so....

Keep in mind the very first frame of that external video where the electricity is on will have lasted ~30 to ~50ms, so for ~50ms while it was falling the electricity was still on.
 
Penagwin, yea.. you're right. I think I got complaints from customers anytime it neared 200-300ms. Any sort of intermittency (different latency times in packet arrivals) tends to really mess up those streams too and makes them hard to understand. That ones nice and clear though.

In that video I made I lined up the ring video so it was about 100 ms before that section lost power, just to see where it would fall - And yea.. perhaps it's off by 50ms or so, I didn't get that fine tuned really. Getting latency under 20-30ms is next to impossible though btw, unless your company has a backbone directly and is right in the city. I was giving latency times from a typical line that you'd have at home.

Also, the video was only 8.5 fps.. so one frame every 175ms or so btw.
 
@jbourne8 - thanks for that. Yes sorry I was probably being a little overly simplistic - you are dead right in the SIP/RTSP piece of course.

However, the rest I disagree with a bit, or at least I havent explained myself properly (more likely).

Agree that RTSP can transmit both audio and video. However, more often than not it is split these days as the human sense perception of drops in video vs drops in audio is significantly different, as is the relative importance on audio. In addition, UDP you are right as a Layer 3 protocol does not retransmit. However Layer4-7 can implement retransmit (or more technically appropriate a request for a retry). For a recording video/audio, vs live stream, it is much more likely that a retransmit is built in (although far from nailed on, or even more likely than not, I agree).

All of that said, I'm really not talking about latency or jitter. The issue here is more regarding the packet size which for a given time period would be circa 10x the size for a video packet as an audio one. In a period of RF interference, your larger packets are both more likely to fail their error check on an Ethernet/layer 2 level, and also less likely to be retransmitted at an application layer - the throughput (or more appropriately for this the "goodput" - i.e. data transmitted after overhead) is much higher for video, audio needs very little. So it is feasible that you could lose video feed briefly but not audio basically. This is all to do with local environmentals in the property, not to do with transmission onto the internet.

However - I really dont think it makes much difference to the other elements which are the important ones, and appreciate that it really could be either or. For what its worth, I do believe on balance that this was at least extremely close in time to the "moving" part of the video. Why? The reflections on the surfaces at the back of the kitchen are in the same place accounting for the movement that has taken place (my loose presumption is this is from moonlight entering from the windows behind? Could be wrong), and the happenstance dust right in front of the camera, right where the rest starts to fall, is far too coincidental for me.
 
@jbourne8

Oh yeah I forgot security video is usually low frame rate. Also I meant the external video, I don't think it's possible to sync the external video to the internal ring video to under 1 frame because we don't know exactly when they stopped/started (We don't know if it had already captured the next frame but not sent it yet).

And yeah packet loss/packet pacing should be more noticeable than just latency alone - that's also why online video games might feel laggy even when your ping looks ok.
 
@clouditguy

I'm pretty sure the actual ethernet packets sent over wifi are all of the same size? Regardless the audio/video are part of the same packets on that level.

I do know that Layer4-7 will not retry in the context of video/audio, because generally the codecs/encoding are designed to handle it, and latency is far more important then data integrity. (a retry is likely another 100~200ms out, and like we were saying humans would notice that)

The audio and the video are encoded separately and shipped, and like you said the audio needs less throughput so it should be far more resilient to single packet drops than the video, as there's a lot more room for error correction.

tl;dr - audio/video are sent over the same physical packets so it's not that one is more likely to drop then the other. But audio codecs will be much more resilient to lost packets.

You're right that video will be the first thing to go before audio, but we would have to see the original data stream to know either way :/
 
Worth mentioning (sorry down a rabbit hole around an area of expertise :D) that even at low frame rate you are talking about circa 2MiB/s for that stream assuming a standardish compression to reduce propagation delay. Trying to push that into a "noisy" RF environment over wifi would be a challenge.

By comparison the audio stream would be at the absolute most, assuming no compression, half of that. In reality probably much much less again.

Hence my thinking (albeit I'm going to come back to the real world now as it really makes no difference !!) .
 
Hey Penagwin

Not to my knowledge. There is a minimum Ethernet packet size of 64 bytes, but otherwise the packet size is protocol overhead + user data. How the user data is defined is another matter of course.

Hmm...cant agree with you re: Layer 4-7. That is solely dependent upon how the application has been coded (albeit I should really say Layer 5 to 7 to be fair), and "latency being more important than integrity" would depend upon the use case. In this case this wasn't likely to be used as a "live stream". It may have been "near" live, but never likely to be live so that immediately puts much greater emphasis on integrity of data (comparatively).

A hugely important factor though which I completely neglected is that as a consumer grade cloud camera recording service (regardless of what specifically it is), the chances of whatever codec or protocol it is using locally being used for actual transport off device is virtually zero. Much more likely it is wrapped into HTTP traffic (therefore using TCP).

We are splitting hairs a bit though ;) myself included, given the increasing lack of relevance to the topic [glasses]
 
clouditguy said:
great post and thanks for this

The nice comments are appreciated, thanks!

clouditguy said:
That black object (fridge?) on the right is also troublesome. It (I think reasonably clearly) starts to develop a gap between the top of it and the wall. That doesnt fit with a downward to the right slope.

I actually think it could make sense:
- There's a column visible embedded in the wall, right near this object.
- Perhaps the floor has detached from the column. The floor slab may be sliding down but the column may not be.
- In this break between the two elements, the column takes a little chunk of the floor slab with it, or the floor is generally buckling around where the floor slab previously attached to the column.
- The black object moves "up" because most of the floor below it is now sliding down, but the small chunk of floor slab still attached to the column is not moving down, and that's causing this object to tilt to the left as you suggest, and also back toward the kitchen.
 
Murph 9000's hypothesis several messages above does a good job (in my non-SE opinion) of tying together the various bits of evidence with a plausible sequence of events.
 
Murph 9000

I believe, generally, that the failure methodology you described makes a lot of sense.

I have a slightly different take on this however. There is a beam constructed that acts as a transfer beam to support the changed slab level beam. This spans from Col M-11.1 and M-9.1. In pre-failure photos, this beam has appeared deflected. Photos can distort. There is a lot of water leakage in this area. I believe that this beam failed very early on and maybe it took the pool deck with it. If this failure was caused by connection to Column M-11.1 the beam could drop and it could take awhile for Column M-9.1 to fail. This makes sense with the video by the tourist through the parking door. I believe we see M-11.1 on the ground and this beam dropped. Although it is hard to discern.

IF this beam to column connection at M9.1 was compromised due to reinforcing degradation (it is directly below a planter) there could be loss of restraint and, possibly, even loss of reinforcing shear capacity. This could have been a construction error and the plans are not great. This could easily be a beam that was overlooked and was added by hanging from the column instead of bearing on it (the photos look like this could be the case).

This beam failure could cause column rotation and failure of the columns on 9.1.

The question still remains on if there was some trigger that set off a serious construction deficiency in the building as a result of the activities to repair the building.

I did a shoring design of a highly deteriorated concrete column in parking structure supporting a much smaller building than this. We were concentrating on this column, which caught everyone's attention, when I noticed that all of the bar trusses supporting an exterior terrace several bays away were nearly rusted through at the bearing on a steel beam (all hidden by drywall fireproofing that had been replaced unknown to the current building manager). I, honestly, have no idea how that structure was remaining stable. All it would have taken was the forklift removing the terrace pavers to cause a progressive failure of a large portion of the support system. I freaked out and had the building evacuated and the terrace closed. But, it was just luck that I showed up when I did.

As engineers it is a difficult call to close a building during rehabilitation or, even, exploratory evaluation. Where I work, a condo unit can rent for $1000 a night. There is a lot of liability in over-reacting and a lot of risk in under-reacting. I am not saying this is the case with the consultant on this failure. I don't have knowledge of that. Just food for thought.
 
Based on the dimensions of the room and the likely lens size, there isn’t really a good fit for the camera being up against the wall. The center of the view is almost perfectly aligned with the kitchen pillar, making the camera about 36” off the left wall. The angles of the pillar in the right wall and the corner at the end of the left wall match this, and also puts the camera about 88” from the south wall. The lens is about 110 degrees.

So, most likely, the camera is sitting on a table set a few feet in from the window.

Feel free to post an alternate combination of distances and field of view.

 
I'm still struggling with the "Ring" video sliding to the right too, so tossing out a new theory that the table didn't slide to the right, but was pushed forward/possibly rotated by the exterior buckling behind it and bowing inwards.

Capture7_nwnuh6.png
 
@CE2537: If the post above yours, that the camera is 36" off the left wall and 88" off the south wall, is even remotely accurate, I don't see this theory holding up. I tend to agree with the positioning assertions that this credenza/furniture is not pushed up against either wall, so for the wall to push the credenza, it would have to deform a tremendous amount to bridge the gap either to the left or behind.

It does seem odd that the credenza would be so far away from the walls, but there are all sorts of items in here in unexpected locations. Note the couch pushed right up against the back of the chairs, for example. This unit appears to be dormant, so furniture placement may be more about temporary storage and wouldn't necessarily follow a "where the average person places furniture" paradigm.

Also, there's no indication that I see from the interior video that the table or camera has changed angle relative to the south wall. It moves almost exclusively right (and down relative to the kitchen, if you look at the cropped GIF in the middle of the thread). In the first frame-last frame GIF near the top, if the camera angled relative to the south wall I think you'd see it pretty clearly (but I don't).
 
To be honest 36" off the left wall would tie in perfectly with my original thought of the table or whatever resting against the internal angle of wall or the inside of the balcony door frame
 
hochhaul said:
I don't see spring loaded doors. It appears that the scuppers were no more than 5" above the top of the gravel/flood coat.

The detail drawing just below noted as curb detail at stairwell #1 with the spillover door. They don’t open until the water level is near the top of the opening which puts the depth at door around 8”. As the slope is in the opposite direction, Approx 10” is correct. This type would be required around the roof perimeter and UPH balcony above the pool deck and patios as it’s not allowed to have open overflow scuppers discharge unguided to common areas below.

Unless…

They are directed to a green roof with splash re-enforcement and adequate drainage. You just solved the mystery of why the planter areas were revised the way they were. Bravo.
 
One curious thing about this collapse is that there is the North building which has some identical features, one of which is the column layout in the critical collapse area. A lot of us have looked at the tic toc video to try and understand better the collapse of the pool deck and supporting columns and how that preceded the collapse of the building. Below is a comparison between the north bldg columns and the south building along with views down the respective ramps. the north building view is from google street view and the south is from the tic toc video. This may help in looking at the tic toc video and trying to determine where the columns should be located and what damage they may have sustained in this early failure before the collapse. The column that appears to be missing from the south view is circled in the plan views in red.

missing_column_north_and_south_ogokgu.jpg
 
Ok so I chanced upon this which could be useful especially for those of us looking at the security camera footage.


This is a virtual tour (with measurement tool) of 611 - the exact same condo the floor below.

I find it particularly interesting that the gap between the west wall and the balcony doors is virtually exactly 36".

Given the imagery in this video, this pretty much confirms for me that whatever the camera is sitting on is flush with the wall.
 
jbourne8 no, it is too large to be a planter at that distance. It is the column.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top