|
Do you use SRT Performance Pages at all? I'm associated with the team that builds and tests the app for all of the SRT brands. We've had some real struggles with the capabilities of the UI libraries available in the app framework, but keep trying to find little performance tweaks as we can. Is the gauge representation still noticeably laggy?
|
#
¿
Jul 2, 2015 22:29
|
|
|
|
| # ¿ May 13, 2024 19:58 |
|
|
Das Volk posted:I do use them, and yeah it's a little slow. One problem I have is that you guys capped the power meter, it maxes out at 650hp while the gauge in the cluster will read 740-750hp with a favorable DA, so it just sits at 650hp for 1/4 of the rev range at WOT. How is the car's power measured by the way? I noticed that the meter seems very accurate, lower DA will result in a significant power loss and it's represented well on the power/torque readout. I can talk for eons about this stuff. It's a little late here for an effort post (I'll make a longer post later), but the short answer is that pretty much any CAN signal you're seeing in Performance Pages is a direct representation of the value from the instrument cluster. I'd have to go back and check the specs to be sure, but I'm relatively positive everything comes from the IC. I'm not sure about the horsepower thing. I'll ask around next week. Maybe you found a defect for us  The main reason the apps take so long to load is because it's loading every single image asset into memory when you're launching the app. That's part of the limitation of the UI framework. I'll talk about it more in-depth when I have more time to post in the next couple days.The Spotify thing is a whole different clusterfuck, but the next generation of head units from FCA will support CarPlay and Android Auto which should remedy that. Unfortunately it won't be backwards compatible, at least as far as I know.
|
|
#
¿
Jul 3, 2015 06:26
|
|
|
I don't necessarily mean to continue the hijack here, I quite enjoy the Laguna Seca videos. I've been meaning to effort post here about the UI stuff but (funnily enough) I've been running around lately dealing with the hack you guys are talking about. Obviously I have to use a lot of discretion when talking about this kind of thing, but the short and skinny of what happened here is a complete breakdown of defense in depth. There were a few small vulnerabilities (and one BIG one) that allowed them to do what they did. I'll wait until official reports come out to talk more specifically, but essentially there was a version of the VP3/4 firmware that was released that listened for incoming connections on a non-standard port. The radio would allow bindings for a certain application protocol that allowed external access to the unit. This was the big security vulnerability that enabled the whole thing. Again, waiting for the official statements, but the affected port(s) have been blocked on the network side of things, and for now they would not be able to exercise this vulnerability from the network again. I have no idea how they gained access to the CAN microcontroller on the radio, though. That, in my opinion, is the hardest part of this and I'm glad they're not going to publish how they did that. I have no idea how that version of firmware passed quality control. I'm guessing somebody is getting fired over this one. The good news is that none of the stuff that my team built was a part of the break  we're smarter than that, we get our stuff pen tested! We're actually drafting a statement right now basically saying "it's not our fault" with FCA's concurrence. But this is all pretty bad. It just sucks that it happened to the solution I'm involved with.There are actually proposals for CAN security, but it's tough to get automakers to change something like CAN that's been around forever. I read and reported on a proposal from an academic journal a few years ago proposing the use of CBC-MAC (cipher block chaining with message authentication code) with CAN messages. It would certainly make this type of exploit much more difficult at the vehicle network, but it'd also have pretty major implications for aftermarket device manufacturers. Here's a nice write-up illustrating some of the considerations: https://kabru.eecs.umich.edu/papers/publications/2013/manuscript_ICCPS_rev1.pdf. On pretty much every FCA vehicle I've worked with, the radio sits on both the CAN-I (interior) and CAN-C (powertrain) busses. On the UI front, at the very beginning of the generation of radios (VP3/4), sometime in 2012, the radio manufacturer integrated a proprietary Java virtual machine as the application framework. That version of the JVM was essentially a beta version from the supplier who wrote it. The supplier was never able to get the radio manufacturer to integrate a production-ready build into the overall firmware build. The entire UI framework is built on top of LWUIT, but the version that eventually made it to production didn't properly integrate UI transformations. This really isn't a big deal for most of the Uconnect apps (Storefront, via mobile, Assist) - they're all relatively static pages with very well-defined page transitions. But the Performance Pages app is a completely different story. When the application renders a page, there are generally multiple gauges associated with that page - it's even worse now if you go drive a Hellcat Challenger or Charger since they have boost gauges. So whenever any of the CAN datapoints changes, it has to repaint the entire gauge rather than transforming existing assets. As you could imagine, this taxes both the built-in GPU and CPU pretty heavily. And it's super slow since it's constantly dipping into RAM (and sometimes even flash storage) instead of caches. This is sort of a high-level look at the problem - I'm actually not a Java developer by trade, I just work with them every day. There might even be some creative ways to work around the problem. I'm leaving the company shortly so I've sorta checked out from all of it anyway v  v
torb main fucked around with this message at 20:19 on Jul 23, 2015 |
|
#
¿
Jul 23, 2015 20:15
|
|