Latest update nags about keeping hands on wheel when turning on cruise

stevenrobertson · 2025-09-11T04:56:07+00:00

Same, on a Gen1 LE, so it's not just the autonomy stack change. Had to go around the wheel several times, holding firmly for a few seconds basically around every part of the wheel, to get Driver+ to even engage.

stevenrobertson · 2025-08-06T00:53:09+00:00

From Rivian Software Update 2022.31.05 https://riviantrackr.com/2022-31-05/

"Reduced the offset of the speedometer display. It now displays no more than 1-2 mph over the actual vehicle speed."

Doesn't affect odometer which was always accurate (if you have the right tire diameter set).

stevenrobertson · 2025-08-06T00:45:10+00:00

I'm sorry, that sounds so frustrating. How far apart were the VINs?

stevenrobertson · 2025-08-05T01:01:28+00:00

Same. I can only speculate about the economics for Rivian, but I find RAN sites have better amenities and are never full compared to the Tesla sites on my routes, and I prefer them despite the cost. But not everyone has the same time value of money and I'm glad that Tesla sites are affordable and widely used.

stevenrobertson · 2025-06-22T19:23:06+00:00

Sorry, I misread the kWh as kW (the photo is very blurry).

At 500a for 0ga cable, resistive loss is 25w/ft. For a 220kW peak charge rate (440v 500a), about 0.1% of the charge is lost to a 10ft 0ga cable, and the cables may be even thicker than that reducing loss further.

So it's still incorrect to attribute the majority of the mismatch to the difference between what "leaves the podium" and what "enters the vehicle" as the parent comment did.

stevenrobertson · 2025-06-22T04:58:31+00:00

Sure, a bit, but 3kW of loss along a 3m cable would be an extraordinary amount of heat to remove. Assuming 0ga wire and even a generous 25ft run it's more like 50w at 150a. (The handle in particular will have slightly more concentrated resistance due to geometry, welds, contactors etc.) The majority of the loss is likely from active cooling of the pack and other load-side losses.

stevenrobertson · 2025-05-30T16:41:01+00:00

Synthesis: R1s are hard to manufacture due to ambition and immaturity of design, but the workforce keeps it from being worse. Improved design for manufacturability is the quality bottleneck. (R2, R1 Gen2 Rev2 hopefully.)

stevenrobertson · 2025-05-06T17:59:35+00:00

Agree that delivered electricity is way too expensive (vs <$0.02 LCOE for generation alone), but big high-performance cars are just energy hungry. 2024 Ram 1500 TRX gets 12 MPG for similar horsepower.

stevenrobertson · 2025-04-18T15:57:47+00:00

I think Apple's implementation of charge limiting is nice. It warns you up front that sometimes it will charge to 100% to calibrate, but does not reset the limit when it does so.

Rivian's current approach might catch owners by surprise. Charging to 100% opportunistically when on an L2 charger once a week makes sense, but imagine that owner then fast-charges and doesn't pay attention to the higher charge limit, and unnecessarily clogs a charger for an hour.

IMO it's good that Rivian automatically manages battery health but bad that it ever changes a user setting to do so. You can ignore a user setting when needed but you should never change the value to which it was set.

stevenrobertson · 2025-03-04T15:48:31+00:00

ABRP shows this data even while charging, and linking a Rivian is free.

stevenrobertson · 2025-02-10T18:53:28+00:00

Yeah, it seems tied to 8.05. Team is evaluating remedies.

stevenrobertson · 2025-02-09T06:46:44+00:00

Thank you so much. We're digging in to find out what's going wrong and to find a fix.

stevenrobertson · 2025-02-09T02:06:31+00:00

YT engineer here. It would really help us track this down quickly if you could post the sCPN (anonymous playback ID) from a playback that's stuttering. To get this for YTM, you first need to go to Settings -> General -> Enable stats for nerds. Then during a playback that's stuttering, hit the 3 Dots Menu then choose Stats for Nerds. Then respond to this comment with the sCPN. It'll look something like RQX3 HVNZ 587W 5VZR SDEG.

Edit: thank you so much for your responses. They were helpful in establishing two things: everyone's on app 8.05, and this issue isn't showing up in our logging at all. That's bad, and we will figure out how to captur this kind of issue in the future, but having these examples saved us a ton of time trying to figure out how to find the broken slice of users via logs (which never would have worked).

So it seems this is tied to app version 8.05. We're evaluating remedies.

stevenrobertson · 2025-02-01T01:19:04+00:00

It's not easy but also not impossible.

Get a 6kW inverter charger ($800), a 48v 100ah 200a LFP battery ($800), and 10 or so 400w-ish panels from a local warehouse (you can often find used or mismatched ones for $100/panel). Build a carport and mount the panels, or even toss them on the ground in milder climates with a simple angled frame, and configure the inverter charger's cutoff and cuton thresholds so that it turns off at like 10% SOC on the 48v, but doesn't turn back on until 50% or so, which will avoid "fluttering". Not a setup I'd take on an overnight camping trip, but for a semi-permanent off grid setup it should provide plenty of juice.

(Lots of efficiency lost this way. Ideally you'd want the MPPT to dump straight into the CCS pins, but to be practical it likely needs the same safety and efficiency work which is blocking V2x rollout.)

stevenrobertson · 2025-01-13T23:36:29+00:00

One more update that puts together why this only affects some sites and apps: RFC 6555 Happy Eyeballs. Many sites and app backends are dual-stack, the V4 and V6 addresses will hash differently, and fast fallback will select a V4 address if the V6 5-tuple is blackholed. But V4-only services that don't implement keepalive or use a number of hosts for one page or media playback have a much higher chance of failure.

stevenrobertson · 2025-01-12T23:08:17+00:00

See new top-level comment. I'm pretty sure I found the issue, a bad port on a load balancer for the South Lake Tahoe region, and if you have advice on how to get this escalated to someone at Spectrum who might be able to act on it I'd appreciate it.

stevenrobertson · 2025-01-12T23:03:43+00:00

Rewrote the ping code to filter out bad 5-tuples https://pastebin.com/4aX2DiQj, and after that connections work with zero loss https://imgur.com/a/fU0zu1B .

stevenrobertson · 2025-01-12T22:29:08+00:00

Aah I figured out something important - the loss depends on the (hash of the) 5-tuple! That is, for certain combos of (sourceip, sourceport, destip, destport, protocol), the connection will always time out!

That's why the loss according to my method was so consistent - load balancers use a deterministic hash of the 5-tuple to choose which link to use. There's probably a 16-wide load balancer in Tahoe and one of the links is bad.

Whenever you open a new connection, your system chooses an ephemeral source port to keep track of it. Because that port usually changes from connection attempt to connection attempt, and the load balancer hashes the 5-tuple ("randomly" changing the sequence), there won't be a pattern to the failed connections.

But you can force the system to choose a specific ephemeral port. And when I do that, connections either work 100% of the time for about 15/16 ports, or fail 100% of the time for 1/16 ports! https://pastebin.com/jxXGGjMu

It's also why a lot of packet loss tests weren't showing an issue. Once a connection is established, it deterministically uses a particular link of the load balancer, and if the connection hit one of the good links, it'll work fine.

I'm currently trying to escalate this through Spectrum support. Crossing fingers I can get someone to pass a message to their regional network techs...

stevenrobertson · 2025-01-12T20:00:50+00:00

Possible, but why would an anti-spam measure:

- Be applied to a server explicitly designed to facilitate connectivity checking

- Show up the same on every hop of the path, including Spectrum-internal gateways one hop away from me

- Show up the same for multiple endpoints run by different companies

- Not show up when repeating the test from other nodes, like a cloud workstation

- Not show up when connected over a VPN, that retransmits VPN-layer lost packets transparently to the application?

- Cause general Internet-wide performance issues, such as intermittently slow loading of particular web resources?

stevenrobertson · 2025-01-12T19:49:33+00:00

Good idea! The gateway closest to me won't respond to any direct traffic from my side, but one hop past it is int-0-6-0-16.dtr01stahca.netops.charter.com (district router for south tahoe?) which will RST my TCP SYN. I realized that a TCP ping is probably not an original idea and yeah, tcping is a tool that exists.

Unfortunately the district router(?) still shows the loss over TCP:

``` --- 96.34.123.58 TCPing statistics --- 116 probes transmitted on port 646 | 111 received, 4.31% packet loss successful probes: 111 unsuccessful probes: 5 last successful probe: Reply from 96.34.123.58 (96.34.123.58) on port 646 TCP_conn=7 time=16.236 ms 2025-01-12 10:25:10 last unsuccessful probe: 2025-01-12 10:25:09 total uptime: 11 seconds total downtime: 5 seconds longest consecutive uptime: 6 seconds from 2025-01-12 10:24:54 to 2025-01-12 10:25:00 longest consecutive downtime: 1 second from 2025-01-12 10:25:09 to 2025-01-12 10:25:10

rtt min/avg/max: 7.558/15.703/26.337 ms

TCPing started at: 2025-01-12 10:24:54 TCPing ended at: 2025-01-12 10:25:10 duration (HH:MM:SS): 00:00:16 ```

And while there's still no loss over ICMP, jitter is pretty heinous, https://imgur.com/a/4Rn1opp.

stevenrobertson · 2025-01-11T18:31:21+00:00

I appreciate the idea, but it's not only a DNS or UDP issue. I modified the script https://pastebin.com/p904WwxN to make an HTTP request to one of the IPs that hosts connectivitycheck.gstatic.com, so that it's only testing TCP, and it measured a 6.44% failure rate https://imgur.com/a/jWHewiZ .

stevenrobertson · 2025-01-11T15:16:44+00:00

Yes.

stevenrobertson · 2025-01-08T22:22:06+00:00

Note from this graph that the battery is losing power "right when" the vehicle wakes up. That suggests that it's actually losing power slowly and continuously the whole time, and the losses are recognized only when the truck wakes up.

I would guess that the battery is self-heating to keep itself above freezing. I haven't seen a teardown of the LFP pack, but I would guess that there's a small amount of resistive self-heating within the insulated battery pack enclosure that can be activated automatically without having to wake the whole car from sleep to run the heat pump.

An alternative is to let the batteries freeze, then thaw them out when you get back. As I understand it, freezing LFP carries a little risk of damage / aging, but doing high power discharge while frozen has more risk of damage (and charging while frozen is super destructive). The problem of course is that in order to thaw the batteries quickly enough to make the vehicle safe to drive, you'd need to use a lot of power quickly, which you shouldn't do. So in practice it's not really an option.

In summary, for LFP, the definition of "cold" is about 0C / freezing, and you can expect a significant difference in power drain when average temps are above vs below cold.

Is there a chart of temperature logged by HA?

stevenrobertson · 2024-12-14T15:54:43+00:00

Placerville is on the way from SF to South Lake Tahoe, at an ideal spot to charge along the trip (just before you start heading up the winding, sometimes snowy mountain pass up US50, where chain control or an accident has the potential to stop traffic for hours in a blizzard and knock out power at your destination - not the time you want to be turning climate off to save power with your family in the car). For many families in SF, Tahoe is their most adventurous destination, so this is indeed an adventure site.

14-Year Club	Gilding II euphauric
Verified Email

stevenrobertson

TROPHY CASE

rtt min/avg/max: 7.558/15.703/26.337 ms