View Single Post
Old 06-28-2019, 12:49 AM   #18 (permalink)
radensb
Base Member
 
Join Date: Jan 2014
Location: California
Posts: 148
Drives: 09 Nissan 370Z GM M6
Rep Power: 6721
radensb has a reputation beyond reputeradensb has a reputation beyond reputeradensb has a reputation beyond reputeradensb has a reputation beyond reputeradensb has a reputation beyond reputeradensb has a reputation beyond reputeradensb has a reputation beyond reputeradensb has a reputation beyond reputeradensb has a reputation beyond reputeradensb has a reputation beyond reputeradensb has a reputation beyond repute
Default

Quote:
Originally Posted by ozyo View Post
Any update?
Yes actually!

I was not able to put as much time into this as I wanted over the last few weeks due to other life and work responsibilities. Adulting is lame sometimes...

While playing with the code and trying to optimize the timing, I kept running into problems due to trying to dance around the limited resources and speed of the processor. I used an Atmega 328P (same device that Arduino uses for their basic platform) but kept away from the known poor preforming core library function calls to make the system as fast as possible. After much work, I got the system working reliably most of the time ... which is not good enough. The problem is that the 328P just isn't fast enough to run the code and filter out all the CAN messages on the Z's bus in time without using interrupts. Using interrupts fixed that problem but generated another by corrupting the timing of the dial control serial stream. When the dial worked, I would lose AC state CAN messages. There would be rolling blackouts for the needed CAN messages and the dial would not properly control the AC system. Basically, I needed one more hardware UART and I didn't want to move to a huge device to get it.

Soooooo..... I moved on to another controller platform! This new device is a 32-bit ARM processor running at over 4x the speed of the 328 with much, much more hardware resources (3x hardware UARTS)! I ported over the code and returned to interrupt driven CAN servicing. So far, everything looks good! I am no longer dropping CAN messages and the dial data is perfect 100% of the time.



Top right is the original design with the 328 from the vids I posted earlier. The new design is below with the purple PCB and little blue dev board under it with some sky-wires connecting them. Next to it is my Z-Simulator that blasts it with CAN messages to test robustness while everything is running. I also put on a wire harness connector so I can plug this into the car and test (coming soon). With the success I have currently with this new processing platform, I am about ready to spin up a new PCB that supports it.

The new design will support USB and Bluetooth, so +1 feature.

Quote:
I'd love to see something like this come out for the G37, the tesla style screen SUCKS. and the metra adapter is terrible.
I bet its hardware is from the same OEM mfg in the Z (Calsonic Kansel). Hell, it might be the same system, or one that functions just like it! When I reverse engineered the Z dial module, I noticed that there is a ton of unused bits being communicated in the serial interface. I'll bet there is some proprietary protocol they made up for these systems and that space is reserved for other systems with more/different AC features (dual climate controls??). At the end of the day, my system is a CAN translator and could probably be adapted to work with other cars with a bit of code work...


Thanks for the interest!
More to come...
radensb is offline   Reply With Quote