Dash Lambda

Just gonna put this here in case anyone else runs into a similar issue: The cause was that I had hardware acceleration disabled in Firefox. Turning it on got rid of all the strange behavior.

Yup, didn't change the behavior.

Hello! I'm having a rather confounding issue. When I run my 4K TV off my GTX 980ti, I get screen tearing everywhere --desktop, YouTube, everywhere. I've also noticed that YouTube videos are choppy-looking in the small player but smooth in fullscreen. Both of those behaviors go away in 1440p and lower. My desktop has a 1700X, 32GB of RAM, and two GTX 980ti's (SLI disabled, ML stuff). The TV is a Sony Bravia XBR70x850b. Things I have tried: Tried running the TV off my laptop It worked perfectly with no tearing at 4K. My laptop is an X1 carbon G10 with the i7-1280p. I used the same cable for both my laptop and desktop. Both my desktop and laptop are on Windows 10. Tried many combinations of resolution and refresh rate in Windows display settings and Nvidia control panel Only lowering the resolution solves the problem Tried different cables and different TV-side ports No dice, but given that the laptop is fine with the same cable and port this isn't surprising Tried different picture modes on the TV Some of them introduced other artifacts or weird stuttering, but all showed tearing I'm using "original" game mode Tried updating graphics drivers Nada I checked "clean install", though I haven't resorted to DDU yet Tried taking out my secondary GPU No dice Tried closing background applications Happens regardless I'm at a loss. The 980ti has more grunt than the 1280p's integrated GPU so I figure it has to be a compatibility thing. Been banging my head against this on and off for a while, I figure if anyone knows what's going on they'd probably be here.

I did it in CADQuery, figured may as well clean it up a little and share it here both as an example solution and as a "hey look at CADQuery it's awesome!" thing: import cadquery as cq from math import radians, sqrt, cos, sin ## Parameters export = True # Export to STEP and STL sleeve_rad = 9 # Radius of sleeve wall_thickness = 1 # Width of sleeve wall slot_angle = 70 # Angle subtended by the arc (i.e. angle between legs) (degrees) unlock_length = 11 # Length of unlocked side of slot lock_length = 1 # Length of locked side of slot slot_offset = 1 # Distance between slot cutout and edge of sleeve slot_width = 3 # Width of slot cutout interp_points = 100 # Number of points to use along curve when building the J hook spline ## Calculated arc_height = sleeve_rad*radians(slot_angle)/2 # Radius of hook of arc sleeve_height = (max(unlock_length, lock_length) # Total length of sleeve + arc_height + 2*slot_offset + slot_width) ## Helper Functions def makeFullCurve(wp, r, h, a, N): # Create a wire defining the wrapped path of the hook of the J # wp: Context workplane # r: radius to wrap # h: Max height of arc # a: Slot angle (degrees) # N: Number of points to use for spline # Function defining the curve of the arc def curveFunc(t): theta = t*radians(a) x = r*cos(theta) y = r*sin(theta) z = h*sqrt(1 - (2*t - 1)**2) return (x, y, z) arc = cq.Edge.makeSpline( wp._toVectors( (curveFunc(n/N) for n in range(N + 1)), includeCurrent = False), tangents = [ cq.Vector(0, 0, 1), cq.Vector(0, 0, -1)], scale = False) return (cq.Workplane().copyWorkplane(wp) .add(arc) .toPending() .consolidateWires() .wires()) ## Plugins def _showDebugDynamic(self): # Used to show context solid with current working features overlayed for debug if self.solids().size() > 0: show_object(self) else: try: base = self.findSolid() show_object(base) debug(self) except: show_object(self) return self cq.Workplane.showDebugDynamic = _showDebugDynamic def _isolateStartPlugin(self, id=0): # Used to set a checkpoint for isolate-combine workflow return self.solids().tag(f'isolated_unit_plugin_checkpoint_{id}').end() def _isolateUnionPlugin(self, id=0): # Used to combine current solid with checkpoint solid into a new solid return self.union(self.solids(tag=f'isolated_unit_plugin_checkpoint_{id}')) def _isolateCutPlugin(self, id=0): # Used to cut current solid from checkpoint solid return self.solids(tag=f'isolated_unit_plugin_checkpoint_{id}').cut(self) cq.Workplane.saveCurrent = _isolateStartPlugin cq.Workplane.recombine = _isolateUnionPlugin cq.Workplane.recombineCut = _isolateCutPlugin def _makeArcCutter(self, r0, r1, h, a, w, ul, ll, N, combine=True, fudge=0.01): # Create the solid needed to cut the J # self: Workplane object # r0: Inner radius # r1: Outer radius # h: Max height of arc # a: Angle between legs of slot (degrees) # w: Width of slot cut # ul: Unlock leg length # ll: Lock leg length # N: Number of points to use for spline # combine: Whether to combine with the parent solid # fudge: How far to go past tangent points to prevent errors sagitta = r0 - sqrt(r0**2 - (w**2)/4) # Sagitta of arc made with cutter and inner wall, used to determine cutter depth path_arc = makeFullCurve(self, r1, h, a, N) # Path along which to sweep cutter cross-section aux_arc = makeFullCurve(self, r0 - sagitta, h, a, N) # Secondary path to constrain the cross-section's orientation along sweep cutter_depth = abs(r1 - r0) + sagitta + 2*fudge # Depth of cutter cross-section return (self ## Arc ## Make a rectangle for the cutter ## cross-section and sweep it along the ## curve to make the hook of the J. .center((r0 + r1 - sagitta)/2, 0) .rect(cutter_depth, w) .sweep(path_arc, auxSpine = aux_arc, combine = combine) ## Unlock Slot ## Select the unlock-side bottom face, ## make a wire from the face's edges, ## then extrude the straight slot. .saveCurrent("pre_unlock_slot") .faces("-Z").faces(">X") .tag("slot_base") .workplane(centerOption="CenterOfBoundBox") .faces(tag="slot_base") .edges() .toPending() .consolidateWires() .extrude(ul, combine = False) ## Unlock Slot Cap ## Cap the slot with a half-circle ## (Cadquery doesn't like it when you ## try to do a total fillet, so I just ## manually make the semicircle) .faces("-Z") .workplane() .transformed( offset = (cutter_depth/2, -w/2, 0), rotate = (0, -90, 0)) .sagittaArc((0, w), -w/2) .close() .extrude(cutter_depth) .recombine("pre_unlock_slot") ## Lock Slot ## Do the same as the unlock-side slot ## but for the lock side. .saveCurrent("pre_lock_slot") .faces("-Z").faces(f'>({cos(radians(a)):f}, {sin(radians(a)):f}, 0)') .tag("lock_base") .workplane(centerOption="CenterOfBoundBox") .faces(tag="lock_base") .edges() .toPending() .consolidateWires() .extrude(ll, combine = False) ## Lock Slot Cap ## Do the same as the unlock-side cap ## but for the lock side. .faces("-Z") .workplane() .transformed(rotate = (0, 0, -a)) .transformed( offset = (cutter_depth/2, -w/2, 0), rotate = (0, -90, 0)) .sagittaArc((0, w), -w/2) .close() .extrude(cutter_depth) .recombine("pre_lock_slot")) cq.Workplane.makeArcCutter = _makeArcCutter ## Constructed sleeve = (cq.Workplane("XY") ## Base ## Extrude a hollow cylinder with open ends. .circle(sleeve_rad) .circle(sleeve_rad - wall_thickness) .extrude(sleeve_height) ## Slot Arc Cut ## Make a cutter and use it to cut the J. .saveCurrent("body_pre_cut") .faces("+Z") .workplane(offset = unlock_length + slot_width/2 + slot_offset - sleeve_height) .makeArcCutter( sleeve_rad - wall_thickness, sleeve_rad, arc_height, slot_angle, slot_width, unlock_length, lock_length, interp_points, combine=False) .recombineCut("body_pre_cut") ## Show Object ## Render solid in preview window (if using CQ-Editor), ## and if there are pending wires, selected faces, ## or other in-progress features, show them as ## debug objects. .showDebugDynamic()) if export: ## If enabled, automatically export to both STEP and STL. cq.exporters.export(sleeve, "bolt_action_sleeve.step") cq.exporters.export(sleeve, "bolt_action_sleeve.stl") I went through a couple approaches, best one ended up being to directly define the path of the cutter and sweep a cross-section along it. CADQuery lets you do that pretty easily, so it ended up being a --relatively-- simple script. It's also fully parametric, so you can play around with the dimensions and whatnot if you want. I recommend CQ-Editor. While you can define the shape exactly mathematically, I don't think most BREP (boundary representation) standards let you define surfaces directly as functions, so most CAD software can't technically represent the shape exactly. This isn't really that significant though, since you can use splines to approximate the curve. The difference between a spline through points on the curve and a direct realization of the mathematical curve, especially for simple shapes like this, ends up being purely academic. You could probably define it exactly with FREP (functional representation), since its whole deal is operations on volumes. You can't represent any curve exactly in OpenSCAD though, and most other FREP tools are even more niche and clunky. I might take a stab at Curv, I think that lets you do exact representation.

I've heard of people using VMs, but I ended up just breaking out my old laptop that dual-boots with Mint. It's got ethernet, its own battery in case power goes out, seemed like a good idea. Been working really well.

A week or two ago I actually set up VPN access to my local network so I could access the NAS in the actual filesystem remotely, and I guess that was pretty good timing because I didn't even realize there was an outage. I'd honestly recommend it. Tailscale's free and really straightforward to set up for this (though dog slow if you use Windows for the server end), and using a VPN like that is way more flexible and convenient than the MyCloud portal stuff. And if you wanna avoid external VPN services too a dynamic IP service is like $2 a month. Been pretty happy with it. As for the SMB stuff, you can configure it to use any combination of 1, 2, and 3, but it's configured to only use 2 and 3 by default. And I don't remember ever having to go through a cloud portal to enable LAN access --maybe that's only a MyCloud Home thing? I still have access to all the configuration stuff and the filesystem and whatnot, never would've noticed the outage if I hadn't checked the forum.

This isn't really what you're asking about, but I have done a 3D-printed model train horn: https://www.printables.com/model/142600-nathan-k5la-train-horn I imagine that for really small models you'd probably want to do resin printing. There's lots of little details that would almost certainly be lost with a very small FFF print, at least at the scale of the model train set I got from my dad (cars are maybe 3 inches long I think?).

I was under the impression Apple uses third party sensors and lasers but makes the actual assembly themselves. I've heard a few companies named as suppliers, mainly Sony and Lumentum, but I've never heard Velodyne. I don't think anything in their product stack is relevant for such a small module. Would be nice though, I work with Velodyne hardware, it's pretty friendly. Most of the sensors I'm planning to use for this project are I2C or something similar, a very standardized, widely supported, well documented, and easy to use protocol. I'm sure it's possible to get Apple's LiDAR module working, but all signs point to it being proprietary and very poorly documented, which means it's not really an option.

I don't think I would be able to use Apple's module --I don't know what protocol it uses to communicate, and it's most certainly not well documented. Given the difficulty I've had finding any information at all on it I don't think I have the skillset to figure out how to integrate it into a different device.

Yeah, that's the rub. There are actually solid-state LiDAR modules that match or even far exceed the range and density I'd want, but they're not small enough. As the project is just a sensor platform for various applications I don't really have strict requirements, I'm just trying to find the best way to get high-accuracy 3D mapping data from a small device. Do you know of any available LiDAR components that would fit my size requirements, even if their range or resolution falls short?

Data collection/mapping from a handheld device. It's going to be combined with two different types of cameras, intended to be a sensor platform for a variety of applications. I do want high resolution, but I realize I can't expect super-high density in something so small. At this point I even wonder if what I'm looking for exists. Only suitably small component I've found is the VL53L5CX from ST, but it seems to be more for presence detection than mapping --only 8x8 with a 4m max range. I'm looking for much longer range (50-100m more like) and higher density. Several times larger would still be fine if it afforded better range and density. There are a variety of good small long-range high-density LiDAR modules available like Velabit, CygBot, etc., but they're all still too big. I might have to start looking into 2D LiDAR in case I can't find a good 3D module.

Hello! Been a while since I posted here, but I figure if anyone can help you guys probably can. So, I'm working on a project for which I really want 3D LiDAR. This project has tight space constraints, the LiDAR module would have to fit within about a cubic inch. The smallest easily-available 3D LiDAR modules I can find are closer to 2" cubed, which is simply too big. I know Apple has had 3D LiDAR integrated into the camera cluster on the iPhone and iPad for a little while now, so tiny modules do exist. Sony has a new ToF chip that they built a MEMS LiDAR device around, but that's currently only available as evaluation hardware, I'm probably not getting my hands on it anytime soon. Do any of you know of a 3D LiDAR module that fits my size constraints and is even remotely easily available right now?

As someone who has worked professionally on Linux compatibility for Unreal-based projects: It's not easy and it's very much not fun. Epic could probably make it a lot easier if they wanted to. They don't really want to. They told me. Hopefully the Steam Deck gives them a good reason.

As far as I know, the first rule of cybersecurity is if the attacker has hardware access all bets are off. This seems like an... exceptionally silly security measure to me, the situations in which locking down compatibility between specific CPUs and mobos would help can't possibly be relevant on mass-market consumer machines, right?

There's something deeply disappointing about companies making handheld PC game systems with just twin stick controls and a touch screen. Makes me immediately lose interest. If the Steam Deck didn't have Steam Controller-ish touchpads I would not have pre-ordered. ... But it does have them, so I'm excited!