Appreciate the heads-up from someone who has been there before! Like you I was a bit surprised by how much the integration bled across subsystems. I like the egg analogy.
> isolate the inverter and motor and make them believe they are still in the original vehicle by replaying CAN messages, ZombieVerter is a project with that approach
For sure, great tips. This is what I've been working towards - at the time of that post I was spoofing the minimum number of CAN messages (still quite a lot), but in the months since I've been gradually replacing modules with spoofed signals by reversing them one at a time. Some of the follow-up blog posts have details about this.
I'm approaching the point of only needing the original motor stack (inverter, charger, etc), the original BMS, and all other modules spoofed out via CAN messages and a few discrete wired signals. The OEM BMS might turn out to be too hard to re-integrate once the battery pack gets split apart, but can cross that bridge when I come to it.
More blog posts (and open hardware & software) to come, I hope!
If you're interested then click the link in my first reply (which is to a newer post). The first video shows the working car reaching 8000rpm (about 80km/h) around six seconds after the accelerator was released. The second video shows the speed creeping steadily from 38km/h to 44km/h (~2600rpm) after switching to Neutral (before we got nervous again and touched the brake).
(I don't really understand it, but I also haven't managed to think of a safety issue here for normal car use: the broken driveshaft is just a bit scary as the motor spins unloaded at >10,000rpm for a while. The only other time this seems likely to happen is if a mechanic puts the car in Drive on a hoist, and it'll stop as soon as they tap the brake.)
> I think you were emulating the ABS module right? In that case, the spinning out of control is actually probably your fault. If you had not emulated this, the system would realise there is an ABS fault (from the messages not being present) and not use the ABS reported speed. It might even fall back to motor speed automatically.
That's a reasonable expectation, and this got left out of the follow-up post I linked, but in the "full car with wheels off the ground" tests we actually tried unplugging the brake module of an otherwise working car and it didn't change anything (including the gradual constant rpm increase in Neutral). If anything the behaviour might have gotten a little more aggressive with the brake module missing.
Have now observed similar behaviour for all three of "spoofed brake messages with 0 wheel speeds and emulated checksums", "fully operational car with wheels off the ground", and "car with wheels off the ground and ABS/brake module unplugged". ¯\_(ツ)_/¯
> Re: shaft scenario, if the motor shaft is broken the safety risk is pretty minimal because the torque wont actually cause the car to move.
>
> I guess this is what they arrived to in the FMEA.
Fair enough, that makes sense. I guess if that's the case then the other behaviour is outside of the scope of what they need to care about.
> So wheel speed sensors drop out and the car will accelerate uncontrollably?
No, I don't think any of my bench tests suggest that for this car. The torque is minimal throughout, so if the motor was pushing an actual car then it might not move at all. If it did move, even a light touch on the (mechanical) brake pedal would stop it.
My problem is that I had a bench setup with no load on the motor and no mechanical brake. I could have pulled the safety interlock (all EVs have these for emergency first responders) but this stops the motor at all costs - wasn't sure of potential damage to the motor controller circuitry from back EMF.
I appreciate the insight from someone who's worked on this kind of thing formally, thanks.
> Most likely what’s happening is that the creep torque is applying a constant small torque and the wheel sensors are reading 0 continuously, so it continues to apply a constant small torque.
This was also my hypothesis at the time of the post. Turned out it's less constrained than this, a fully operational car with the drive wheels off the ground will also run away to high rpm (even in Neutral): https://www.projectgus.com/2024/04/unremarkable/#on-car-test...
There's still minimal torque, as you say, so a small press on the car's brake pedal is all it takes to stop. However I think if a driveshaft broke on a real car then it'd be spinning fast for a minute or two... It kind of makes sense that the control loop is tuned for a heavy car with a fixed drive ratio, though.
I am still hopeful there will be a way to stop this behaviour via a control signal (rather than pulling the safety interlock and slamming the contactors open). Have left the problem aside until I have a mechanical brake to use for testing! If that doesn't work out then it's still usable I think, provided any EV conversion is single speed fixed gear just like the Kona.
If you have any other insights on this then I'd be very interested to hear them, though.
You're spot on about the PLL stage, a few people on Reddit pointed the same thing out when I first posted it. Makes sense, although I still think it's interesting they added it internally to an otherwise (apparently) cloned design.
You're also right that USB CDC does provide the option for a generic USB Ethernet device, however this silicon is ASIX-specific (not just the USB IDs.) ASIX's Windows drivers include their own system driver binaries, and the ASIX Linux driver has a lot of ASIX-specific stuff in it.
I think it's kind of possible ASIX made this themselves as some kind of no-name branded unadvertised market segmentation effort. I can't understand what their rationale would be exactly but hardware companies do unusual things sometimes...
I haven't tried any of their other products, but the iMX6 has a very large detailed technical manual (publicly available, not under NDA) and their Linux kernel trees are updated in public via git (presumably not everything is public but it's a lot more transparent than the occasional tarball source drop approach), plus they have people involved in yocto development. Better than many/most of the ARM SoC manufacturers.
The only undocumented/secret squirrel business AFAIK is the Vivante GPU. And that's universal across ARM Soc GPUs, sadly.
Freescale i.MX6 is a really nice platform. Shame it hasn't gotten broader traction, I think because it is moderately more expensive than its competition.
Since May I've been using an imx6 based gk802 ($70 quad core "Android TV" stick) as a personal server (email, RSS, VPN, etc.) Has worked really nicely considering. (Blog post about installing debian on it: http://projectgus.com/2013/05/debian-installer-for-zealz-gk8... )
Rather than "open sourced" all I see is "a bit open specced". Yes, the "hacker guide" has details of what chips are on the board, and how they are connected:
http://developer.sonymobile.com/services/open-smartwatch-pro...
... and there's a separate page with a guide to putting it in DFU mode to upload a firmware.
Which is cool, but the chip names could have been found by the people who'd already done teardowns and the pinouts could be found by buzzing one out (possibly sacrificially by removing chips.)
The chip datasheets they link were all all already publically available, the Cypress touch sensor one is even a link to alldatasheet.com(!)
Probably the biggest letdown is the Bluetooth/FM chip made by Sony, arguably the most useful and most complex device aside from the MCU. That link is to Sony's marketing specs page with a block diagram and not much technical info that I can see. I can't find any information about the chip made available to the public by Sony.
Ironically enough there is a longer 6 page Sony datasheet leaked on datasheet sites, but even this doesn't have pinouts or begin to explain how the SPI interface to Bluetooth/FM functionality actually works.
I think it's good that a major company like Sony released even this small amount of information, although it's worth noting that reverse engineers have found more information on similar products acting entirely by themselves (take for instance the PS3 Move controller: http://eissq.com/ps3_move/ )
On the other hand I think it's very bad that most people will glance at this and see Sony "open sourcing" something when they appear to be open sourcing nearly nothing. The RTOS they used is probably proprietary property of a third party so they can't open source that, but they could release their application source code for the smartwatch - allowing people to see how they communicate with the Bluetooth/FM chip, for instance. That kind of source could be ported to an open source RTOS.
The optimist in me hopes that detailed technical information will be forthcoming over time, but the pessimist in me thinks this is the feel-good last gasp of an end-of-life product. :/
I agree anyone seriously wanting to host that many photos will not want to split accounts, but FWIW statistics (current Pro feature) don't seem to be offered at all any more.
A number of things - the Z axis seems loose, the other axes skip steps (possibly the stepper drivers overheating), general issues with bed adhesion and warping.
All common 3d printer issues, though some are exacerbated because I bought a cheap kit from an unknown supplier. I got to a point where every time I fixed I problem I'd notice two other ones, and put it down and haven't picked it back up.
Good advice for people getting 3d printers is to decide if you want a printer as a tool for design/prototyping, or 3d printing as a hobby. I told myself I wanted the second as a path to the first, but after many hours of printer building I concluded that I really just wanted the first.
(If there's not one nearby, you could always start one... when I cofounded a hackerspace I met a lot more than 15 new people who wanted to share 3d printers and the like!)
Google disabled access to /proc/config, which makes the process of building a vaguely compatible kernel all the more like guess-and-check.
Is there really no .config in their GPL release? AFAIK compile-time config is a GPLv2 requirement as part of the "scripts used to control compilation" (Gpl-Violations FAQ specifically mentions Linux .config files.) I'd hope there's either a .config or a defconfig that applies to Glass as-shipped.
(NB: I don't mean to dispute your overall point by this, just wondering.)
FWIW I have access to an Eagle license but prefer to use Kicad whenever I can. In no small part because of the Linux app being clunky (also because Kicad is FOSS.)
The annoying thing about using both is they're both similar-but-different in lots of little ways (like the other comment says, all EDA apps are weird.) Learning one once you're used to the other is a pain, but it's not impossible.
Appreciate the heads-up from someone who has been there before! Like you I was a bit surprised by how much the integration bled across subsystems. I like the egg analogy.
> isolate the inverter and motor and make them believe they are still in the original vehicle by replaying CAN messages, ZombieVerter is a project with that approach
For sure, great tips. This is what I've been working towards - at the time of that post I was spoofing the minimum number of CAN messages (still quite a lot), but in the months since I've been gradually replacing modules with spoofed signals by reversing them one at a time. Some of the follow-up blog posts have details about this.
I'm approaching the point of only needing the original motor stack (inverter, charger, etc), the original BMS, and all other modules spoofed out via CAN messages and a few discrete wired signals. The OEM BMS might turn out to be too hard to re-integrate once the battery pack gets split apart, but can cross that bridge when I come to it.
More blog posts (and open hardware & software) to come, I hope!