Complicated question around replacement stereo...

My Nissan Leaf Forum

Help Support My Nissan Leaf Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

defiancecp

Well-known member
Joined
Aug 16, 2010
Messages
367
Location
Little Rock
So I haven't messed with the canbus much, but I think this might be possible (though probably quite difficult...) - The question seems unrelated at first, but bear with me :)


So I've been working on my audio system, with the hope/intent to stick with the factory head because of all the integration.

It's driving me nuts though :) The factory head drives into clipping at different points in the volume range at different frequencies, and dropping below the point where any clipping is in effect leads to an unacceptable range of adjustment steps (if amps adjusted to be good volume, each remaining volume bump is a huge change). Not to mention there are countless systems out there in the aftermarket with *SERIOUSLY* better interfaces.

So I started making a checklist of what would be lost by replacing the factory unit with an aftermarket. First, things that probably would not be lost:

- Audio: Aftermarket will replace no problem (much better)
- Nav: Aftermarket will replace no problem (probably better interface)
- Handsfree: Aftermarket will replace no problem
- Steering wheel controls: Aftermarket interfaces with nissan steering controls- unconfirmed it will work with the leaf, but proably ok
- backup camera: need to dig into the service manual, but 90% chance video is encoded in standard composite format, meaning could interface with aftermarket no problem

What *would* be lost:
-body control settings (auto lights, lock behavior, etc)
-power consumption (live kw consumed/regen'd, climate control, other)
-temperature output from climate control (just the numeric temp output)
-Charging timer controls


So here's my question - just from fiddling with things, it really seems like the stereo doesn't store or control those functions - (for example, locks, climate, and charge timers work fine in pre-selected mode with stereo disconnected; the stero is only needed to 'change' the settings)

So my thought is, if the unit is just an interface to change settings in the ECU/BCU, it's probably passing and reading these settings over the CANbus, right?

if so, would it not be possible to take the concept of the soc meter, and expand it to include output of all these settings as well? And possibly add a couple buttons and a UI to make it also capable of actually changing these settings?
 
defiancecp said:
on my audio system, with the hope/intent to stick with the factory head because of all the integration.

It's driving me nuts though :) The factory head drives into clipping at different points in the volume range at different frequencies, and dropping below the point where any clipping is in effect leads to an unacceptable range of adjustment steps (if amps adjusted to be good volume, each remaining volume bump is a huge change).

Why not just set the factory system at the highest setting before any clipping occurs and then use an amp with a remote gain control ? My old Phoenix Gold M100 had one, just a remote pot and small cable. You'd then have a traditional volume control, easy to mount somewhere. No steering wheel control for volume though.
 
Steering controls are one reason - another is choosing between an unsightly extra knob sticking out of the dash or giving up the ergonomics of the console - another is the factory radio's general low output quality even when you do get below clipping - etc.etc... Both my amp and processor currently have remote gain adjustment options, but for the reasons above I fund that solution unsatisfactory. And even if I did like it, I still don't get around the lack of UI quality...

Suffice to say I huge amount of effort (and no small amount of money) into trying to integrate with the factory audio system, and it is simply not acceptable to me. Frankly, at this point, I might be willing to give up adjustment of charging timers (they're set like I like them now anyway) or body settings (ditto) to get reasonable sound.
 
Shouldn't be too hard to suss out. Hook up Gary's logging device to the correct CAN bus, and log messages while changing each of the settings. The hardest part will be creating a unit with a big enough touchscreen to do a decent job, and finding a good way to mount it.
 
Now what would be **REALLY** awesome would be something like an android app for control installed on a double-din touchscreen android device, interfaced to canbus via an adaptor to usb... Not possible yet since I don't think android distributions have usb host support yet, but it's been talked about as coming...

Anyway, in the short term I don't think it would have to be touch screen - something like a 20x2 text lcd display with a button-driven menu would do the job for most stuff (other than power display, which it could do, but only numeric and not large enough to use while driving)
 
defiancecp said:
Now what would be **REALLY** awesome would be something like an android app for control installed on a double-din touchscreen android device, interfaced to canbus via an adaptor to usb... Not possible yet since I don't think android distributions have usb host support yet, but it's been talked about as coming...
A wired connection would be a little annoying, plus using wireless would let you do things from outside the car. You could use Bluetooth (might be annoying if you want to use BT for audio), or WiFi. BTW, I always thought it was extremely short sighted that we couldn't change most of these setting through the owner's website.
defiancecp said:
Anyway, in the short term I don't think it would have to be touch screen - something like a 20x2 text lcd display with a button-driven menu would do the job for most stuff (other than power display, which it could do, but only numeric and not large enough to use while driving)
Very short term, I'd say. Most of the menus aren't too bad, but I wouldn't want to have to change my charge timers very often with that interface. Plus I use the energy screen a LOT and would want the solution to display the data in a way I could easily read while driving.
 
The integration of the "Audio/Nav/Control/Status" functions make meaningful replacement of the "Nav/Audio" seem very difficult to do.

Start my making a detailed list of all the LEAF-specific functions on every control and every screen. General categories are:

1. Charging Station Locations ...
2. Energy usage ...
3. Backup turn radius ...
4. Carwings functions ...
5. GPS-derived data that the LEAF might use to work properly ...

Are you announcing that you are going to do some detailed analysis of the messages on the AV-CAN bus?

If not, "How do I replace the Nav/Audio unit?" probably does not even belong in the "Leaf CANbus" subforum.
 
The sound quality is going to also be limited by source content and the D/A converter in the unit for digital files and it seems to be somewhat poor. If you use a CD it seems better than hi-res MP3 or FLAC. Since the CD is easy to navigate as it is limited in length then the interface is not an issue. One potential way to avoid the onboard amps is to go straight to the low level by going into the unit (soldering) and then RCA out to your amps. I have already replaced my speakers with some JL separates but I need to put the JL amp on in the described manner.
 
garygid said:
The integration of the "Audio/Nav/Control/Status" functions make meaningful replacement of the "Nav/Audio" seem very difficult to do.

Start my making a detailed list of all the LEAF-specific functions on every control and every screen. General categories are:

1. Charging Station Locations ...
2. Energy usage ...
3. Backup turn radius ...
4. Carwings functions ...
5. GPS-derived data that the LEAF might use to work properly ...

Are you announcing that you are going to do some detailed analysis of the messages on the AV-CAN bus?

If not, "How do I replace the Nav/Audio unit?" probably does not even belong in the "Leaf CANbus" subforum.


I'm not announcing I'm going to do anything, I'm opening discussion about whether I'm on the right track that this information would be communicated via canbus. Perhaps that could eventually lead to detailed analysis of messaging. the question of "how do I replace the nav/audio unit" is integrally tied to the can bus messaging, what the car can and cannot function without, what functions have potential negative impacts, and how to work around those impatcts. If you feel discussion of whether something is handled via can bus messaging should go elsewhere, please feel free to suggest :D

As you can see in the body of the initial post of this discussion, the list you've suggested is started - thank you for the additional suggestions ( I hadn't included charging station locations, and the overlay of backup turn radius I failed to mention). That's also a good ppoint, that the car could potentially use GPS data for other functions, though I'm not sure what...

I may just have to try disconnecting the unit entirely for a period of time and documenting what is missing, first to be certain that other vehicle functions are not impacted, and second to ensure I haven't forgotten some functionality.
 
defiancecp said:
garygid said:
The integration of the "Audio/Nav/Control/Status" functions make meaningful replacement of the "Nav/Audio" seem very difficult to do.
>>>>
5. GPS-derived data that the LEAF might use to work properly ...

Are you announcing that you are going to do some detailed analysis of the messages on the AV-CAN bus?
>>>>
That's also a good ppoint, that the car could potentially use GPS data for other functions, though I'm not sure what...

I may just have to try disconnecting the unit entirely for a period of time and documenting what is missing, first to be certain that other vehicle functions are not impacted, and second to ensure I haven't forgotten some functionality.
It would seem to me going from what the SOC meter is now, which is only listening to the busses to taking over functions that require you to generate your own bus messages is a very big step, with lots of associated risks.

In principle, it would be nice to have a GPS that generated an altitude profile for an intended route and used this to calculate a more accurate SOC for your destination. However, the GPS data base has no reason to store altitude data now, and I see no reason why there would be any bus traffic related to the GPS. It would seem that this enhancement, like better audio, would best be done completely separate from the present built-in components.
 
Alright, so I've finally got some time to really jump into this process. I've got some history with AVR and found PIC to be a bit of a painful transition, so rather than the beloved Arduino I'm using a Minimus AVR ( http://minimususb.com/" onclick="window.open(this.href);return false; ) and a homebuilt can sniff system with mcp2551 and mcp2515 chips. Just about finished with that.

From poring over the service manual, I don't think the AV Can bus is really going to be much use; since it pretty much just connects the buttons around the unit to the unit with no other connections, all it would likely contain would be button press data. Certainly something I plan to take advantage of, but not really critical functionality.



I've done a bit more extensive testing of the vehicle functions with the AV Nav out-of-system, and have my list of things I need to sniff out refined somewhat. Found some interesting tidbits, too... For example:


-With AV disconnected, Guess-o-meter turns to "---" even with a full charge. This one shocked me, since based on the service manual's list of comms, there's basically nothing sent from the nav relating to the range estimate - it's supposedly all sent from the vcm. The only thing I can think of is that the VCM considers one of the info bits from the TCU to be critical, and the TCU - which is connected to the nav via USB instead of CAN - fails to send whatever that signal is when it is not connected (note: since the TCU to AV connection is a dedicated plug, I plan to test this theory further by disconnecting ONLY the TCU to see if the range estimate goes away)
If I'm correct about this, it could either be a huge hurdle or a golden opportunity. CANbus isn't a major ordeal to reverse engineer, sure - but a proprietary USB connection may be a problem. I suppose it may be as easy as the TCU USB connection functioning as a serial communications device and just passing messaging back and forth, but I wouldn't bet on it. Having said that, if AV to TCU communications is deemed not needed, and if the messaging related to the Guess-o-meter can be identified, and if that messaging - as I suspect - simply ceases when the AV is disconnected, it leaves us with the opportunity to replace it. With something like, oh, maybe % charge? :)



Anyway, most of the messaging I'm interested in is documented in the service manual, and I'm still looking through all the work already done in this board but I bet lots of it has already been identified. For example, according to the SM the only thing the AV actually sends out over the bus is the current time, so that should be relatively easy to duplicate I think. However, there are a few things not documented that absolutely must be on the can bus:

-auto light sensitivity
-door lock behavior
-climate control details (fan speed, mode, temp, etc.)
For both of these, in the service manual, it doesn't really even acknowledge they can be set in the nav or are displayed on the nav - the settings refer to the setting being changeable by CONSULT. But in both cases, the only connection between the target system and the nav is the vehicle can bus, so it must happen; similarly the can bus is the only connection to climate control system, so again it must travel though that bus. I thought initially this latter detail may be on the av bus, but looking further it doesn't connect - the buttons connected to the bus do not include the climate control buttons; they're completely separate. Anyway, All systems work (at current settings) with the nav removed, so it must be a case of the nav sending a can message across the primary vehicle bus to the BCM with the current setting (probably in a manner identical to consult). I'll just have to do some logging while I change the settings... (*edit* - hac-15 confirms the VCM sends the data via vehicle CAN bus to the AV, so that's confirmed)



And also, one that might not be on the can bus... charging timers. Since the NAV is not in any way connected to the EV bus (which surprised me...), I might be able to make some guesses. To get from NAV to EV bus, the most likely path is via USB to the TCU, so I think it's logical to conclude that's the control path taken. However, that leaves the biggest question: what intelligence resides where? I mean, theoretically the decision-making process could reside entirely in the Nav: the VCM sends charging status data to the TCU via can, which could simply be acting as a dumb link, passing the info to the Nav, then the nav could apply its info and timers to tell the TCM to send start/stop charging signals. However, I think that unlikely - the service manual lists only 3 messages transmitted by the TCM - remote charging start (as in, sms/android/web requested), remote climate start, and vcm sleep. We know there are some messages not listed in the manual, but it seems inconsistent that the manual would list *remote* charging messaging, but not normal charging messaging. Also, those remote charging signals are sent from the TCU to the VCM, not the OBC - meaning the VCM then has to do something extra to initiate charging. My belief is that the VCM uses the "maximum charge power signal" (along with all the fault override signals) to control when the OBC is allowed to charge to 80%, 100%, or not at all - so the it's likely that either the NAV sends the timers in a data packet to the vcm (I consider this to be the least likely of the two), or continuously sends the VCM details about what behavior is called for based on current timers (I believe this more likely). How it sends that data is another question, since it's connected to VCM either by vehicle can bus or via TCM + EV Can bus.

My hope is that it sends the VCM a constant signal via primary can bus with no involvement of the TCU. Easy way to test - set timers to no charge and plug in a charger. With all as normal it should not charge. If I'm right that the VCM relies on a continuous signal, when the nav is disconnected it will default to 100% charge when the appropriate nav signal is disconnected (so if the TCU is disconnected and it still follows the scheduled no charge, but the primary bus is disconnected it defaults to 100% charge, that would give some further credit to my theory).

If that all turns out to be correct, I'll take 4 polls of the vehicle bus - one with nav disconnected, one with it connected and timer set to off, one with it connected at 80%, and one with it connected at 100%. Theoretically there should be a conspicuously missing signal in the first, which will be at 3 different values in the other 3. Talk about best of all worlds, that would allow for an extremely customizable charging control/timer system :)

Anyway, the more I find out the more I find I need to investigate. Just wanted to update that I did decide to press forward with this.
 
Ok, quick correction to the above - the GOM *does* work with the nav out. Before, I apparently had the TCU itself disconnected in addition to the nav. With it disconnected, the GOM is blank (but the orange "!" car indicator is on too, so not really a workable solution :) )

But the good news there is, functionality loss by disconnecting the TCU from the Nav (but leaving it connected to the car) is pretty minimal. The only things I found that ceased to function were the remote charging and remote charge status functions. The remote A/C even still worked, surprisingly enough.

Also, charging timers are stored and controlled from the nav, and this communication takes place on the main vehicle bus. Charging timers work fine with TCU disconnected. The results I was got seemed inconsistent at first... Problem was how the car seems to handle charging. Basically:
-With no timer info from nav AT ALL - the car goes into 'default' timer mode (100% charge, all the time).
-When power is disconnected from the nav, the timers are still recorded, but they revert to 'off' - meaning when you put the nav back in, it just goes to 'ready to charge' mode (sequential blue light blinks) and doesn't charge at all.
-Also, the charging system apparently gets its 'plan' for timer-related charging at the start of the charge cycle and doesn't change. So if you have a timer set, start the charging, then disconnect the nav, it does not revert, it chugs along with its initial plan (apparently).

the "comfort and convenience" functions all still work brilliantly with the nav out, and the settings can still be changed with the TCU diconnected; they only cease to be able to change when the vehicle bus is disconnected. So those settings are definitely transferred via main bus.





So in summary, here's what actually goes away with the nav out, as well as prospects for replacement.

-sound system - a no brainer, it will be replaced of course.

-nav - multiple options available.

-handsfree - not a problem

-Remote charging and remote charge status - this gets lost when the TCU can't communicate with the nav anymore. This functionality itself probably can't be duplicated, but it may be able to be replaced with similar functionality since the replacement unit will need to control charging timers anyway, and will likely need some form of communication anyway. A replacement solution will likely be far superior as well.

-ability to change 'comfort and convenience' - this will be tricky to replace, as it means sniffing out undocumented can bus communication. However, given that we can specifically trigger the communications we want to sniff, very likely doable.

-climate control display - Similar to comfort and convenience, since this comm doesn't seem to be detailed at all in the service manual - however, similarly, we can manually trigger the events.

-Energy screen - Much of the work for this one has already been done, in the form of already identifying energy consumption message id's. And we can probably add a great deal of community knowledge to the calculations behind it as well.

-SOC - interestingly, the nav -which is the master control for charging timers - has no direct connection to the EV bus :) So this will require an extra cable output to somewhere. We already know it can be gotten from the OBD plug, but there are probably places that wouldn't require an external connection.

-backup camera - easy - the video signal is a standard protocol video signal.

-steering wheel/dash button controls - The steering wheel controls are resistor multiplexed. There are inexpensive devices already on the market that read multiplexed buttons and convert the output to an HID-compliant USB device. The dash buttons are on their own little mini-can bus, so I just need to devote a can sniffer circuit to them - no problem.

-carwings - My nav still has the old firmware, so I get no carwings data anyway. But I think it's safe to assume that if the nav firmware can make it fail to send anything, the nav not being there would be that much worse :) This is probably not replaceable, though an alternative setup could be built; the hardware would be all in place already, the system has to be on all 3 buses already, so it's just a matter of making the software to log the info.

It'll probably be a week or so before I make much more direct progress - I think this is as far as I can go without a working can logger. I got the device constructed today, but I've got to actually code it now :)


Incidentally, I think for those of you not afraid of a soldering iron, this might be one of the easiest ways out there to get a can monitor set up. The minimus is available for less than $10, then you need can interface chips that total up to $3.10 from digikey, you need a couple of resistors and a $2 breadboard from radio shack, and the OBD cable. Less than $30 all in, and it's USB. Once I've got the firmware finished up, that is - til then I'm just talking smack :) Actually, it probably makes sense to make it a single-unit triple-channel reader... haven't done the math to determine if that would run into bandwidth limitations, but even if it did run into theoretical limits it probably wouldn't hit real-world limits with what we're doing... and I can think of situations where it would be useful to have a multi-channel log.
 
1. Would you please detail your list of parts for your USB-connected CAN logger?

2. What would you do to log (3 or 4) CAN buses simultaneously?

3. The car resets (loses) some variables when 12v power is removed (a Power Off/On re-booting). The Timers are such values.

4. The LEAF seems to function fairly normally (no Carwings functions, of course) with the TCM (TCU?) removed from the car.

5. Does the AV-CAN bus connect to the VCM?

Please keep us posted.
I would like to find the Battery Pack Temperature,
and the Tire Pressures.
 
The can logger I just put together is basically just a minimus development board with a mcp 2551 and 2515; the only additional components are a resistor to function as a simple reset circuit for the 2551 and a resistor to vcc for vref on the 2515. The clock from the minimus is shared with the 2551. I'll get pics of that if you'd like. Not pretty, but functional. For multi-bus logging, I plan on upgrading it to have three of each can input circuits (SPI supports multiplexing, I'd just have to assign one pin to act as the CS line for each of the additional chips and program a handler for chip selection when messaging is input). For full logging basically all messaging would be appended with a single-byte flag indicating which bus it came from, then sent as a serial transmission to the USB for logging on the PC - then the PC will then just bulk saves everything. Like I said though, it's all talk til I get the firmware written :) logging one will be easy, but I'm very hopeful that getting simultaneous 3-bus logging will not be much more difficult...
The reset of variables is what I had guessed was happening with the strange charging behavior, I just wasn't sure.

oops - the TCU is not where I thought - looking over the manual, looks like I was disconnecting the a/c auto amp :) looking more closely at the service manual, the TCU is further right-ward in the dash. Apparently when you disconnect the auto a/c amp, the gom breaks and you get an orange "!" car indicator, which does make sense. So ignore all I said about disconnecting the TCU directly, but disconnecting the TCU harness from the AV system does have the effects described above.

As far as I can see, the av-can bus connects ONLY to the nav, the dash buttons, and the data link. very limited function, looks like.



Incidentally, do you know if it's possible to get the mates to these connectors from any source? I can probe the pins directly from the backside of the harness for testing, but I'd like to find a permanent means of connection that involves no modification.... Connecting to the canbus via obd connector is no problem, and the main stereo wiring is not an issue as manufacturers like scoche resell the harnesses. But the big 40-pin harness also has the microphone, camera, reverse indicator, and aux input, all of which would be nice to connect to without splicing... Also there's a 4-pin plug to connect to the auxilliary USB port... I personally care little for the sat antenna, gps antenna, radio antenna, etc., but that's just me :)


Incidentally part 2 --- I'm assuming rewriting the number displayed in the gom is implausible since it's probably sent from the VCM or something not disconnectable... However, if we identify which message ID relates to it, it might still be doable; If this system reacts to any sent gom signal by re-sending its soc value masquerading as gom value, the origingal value would be 'believed' by the display for far less than 1ms before being corrected - to a human eye I bet it would be completely below the point of perception...
 
Here's the board with only one channel. The minimus used the same hole spacing as cheapo radio shack project board, so I was able to take most of the lines to the project board just by putting leads through both boards as needed ( power,gnd, int0, and the 4 spi leads). For a 3-channel version I'd need to bring out 2 more interrupts and 2 more random io to use as CS lines, then a pair of the input chips for each channel. You'll notice there's one wire soldered onto a lead on the minimus- that's the clock pin. It's the one input I needed that the minimus didn't bring out. I could run the chips on separate clocks, but I believe this will work better. *EDIT* - I later realized that the minimus can run an optional clock out on pin PC7, so I enabled that. It relies on the micro to have booted to send the clock signal though, so the normal reset circuit wouldn't work to reset the mcp chip (since it needs a stable clock to already be in place when the reset is removed) - so I've taken IO pin PC6 and brought it out to function as the mcp chip reset. The combo should be pretty stable. we'll see.
I've got the whole thing put together and it responds to programming and simple commands, but that's still a far cry from actual CAN messaging, so still a ways to go.
15493414_large.jpg



Not super pretty, but I can do a nice PCB layout if it all works fine.... But frankly as much as this minimus simplifies things, and as inexpensive as they are, I think even buidling a nice PCB I'd still make it just an add-on to the minimus. I put together a quick one in expresspcb, I'll update if needed as testing moves along and distribute once I'm confident it'll work.
 
Do you have a US source for the minimus?

I see http://www.modtraders.co.uk/" onclick="window.open(this.href);return false; has them.

Are you using the Minimus AVR USB, or the AVR 32 USB version?

Thanks, Gary
 
Try to get CAN receiving going first, and send CAN-Do compatible 11-byte message records (1 sync, 2 MsgId, 8 data) back to your Mac or PC.

Then I can duplicate your work here on the PC and test it with CAN-Do.

Does the "driver" for the USB port make it look like COMM Port I/O to the PC/Mac?

What source are you using for the CAN-Interface chips?

I just ordered the Minimus, both 16 and 32 versions.
 
I got mine from foundmy - I got the 32k version... I just saw that the at90 version is <$10 so I should have gotten that (I think 16k is probably going to be quite plenty - the last time I worked with AVRs I was using 4k - but oh well :). The default driver for the atmel chips sets it up as a basic programmable device, but you can change that with a custom driver. Here's an example project using one as a serial device; I'm using that as a starting point.
http://www.pjrc.com/teensy/usb_serial.html" onclick="window.open(this.href);return false;


I'll try to get a simple pass-through single channel code written this week if possible. Ports I've designated:


pb0 - chip select for first can channel SPI comms (primary can network)
pb4 - chip select for first can channel SPI comms (EV can network)
pb5 - chip select for first can channel SPI comms (AV can network)

pb1 - SPI clock
pb2 - spi mosi
pb3 - spi miso

pd0 - interrupt from primary can channel (not sure if I'll use the interrupt or not, but it's wired if I want to)
pd1 - interrupt from EV can channel (not sure if I'll use the interrupt or not, but it's wired if I want to)
pd2 - interrupt from AV can channel (not sure if I'll use the interrupt or not, but it's wired if I want to)

pc7 - clock output - set ckout bit and this output is a simple logic-level output of the clock
pc6 - manual reset - since the mcp chips need to be reset until their clock is stable and their clock is generated by the chip, this will be set to hold them in reset until the avr is running and the clock has been operating for a few cycles.

I've got a proto built with 3 channels, but that gets messy on a breadboard like this (6 ic's = rat's nest of wires), so I'm not sure it'll work. The single channel is much cleaner so I'm just going to start with it.
 
Yes, certainly start with 1 CAN bus, either the CAR-CAN or EV-CAN bus.

Each CAN bus is a 500 kb bus.

Do the CAN chips give an interrupt when a message has been received?

If not using interrupts, you poll each channel for "Message Ready"?

How fast is the Serial transfer from CAN-chip to uP chip?

Do the CAN-chips have a several-message buffer?

I should have my Minimus boards sometime next week.

Cheers, Gary
 
Yes, they flag their interrupt pin. And I'm just thinking out loud, not decided on the prioritization.... Actually I think interrupts should be enabled - I was thinking maybe not because even if the 'higher priority' channel has an interrupt occur while receiving a message from the 'lower priority', I wouldn't want the message transfer interrupted, but the interrupt routine can be as simple as just setting a flag telling the micro that a message is waiting on another line. Then each time the micro finishes its message receive, it checks the waiting flags and picks the chip of choice based on priority (priority roughly set by utilized bandwidth; main being highest, av being lowest).

The spi is capable of 10mhz on the can chip, but this implementation will run at 8mhz due to the 16mhz clock on the micro. If data were coming from all 3 busses at max speed, that would require 1.5mbit, with bus-related overhead that probably would go past 2mbit. So I haven't put pen and paper down to calculate the absolute maximum bandwidth, but back-of-the-napkin numbers indicate we should be OK, since we should theoretically have about 4x needed bandwidth.

The chips have 3 14-byte transmit buffers. Assuming a full max-speed transfer from all busses and the prioritization described above, it would cycle through the chips sequentially (since after receiving from the 1st chip, it would have time to then receive from the 2nd and 3rd before the next message is ready on the 1st). With that in mind the buffers shouldn't really come into play, but in case I'm doing my napkin-math wrong they'd only need to store data for the time it would take to receive two other messages, so it should be fine.

Anyway, all that would come into play once I get the single-chip version running. Once I've confirmed it's working I'll probably put together a pcb and get a few prints from expresspcb or something for the 3-chip version. Just too much to connect for jumper wires on a proto board.


Also interesting is that the chips themselves can utilize a list of 'important' message ids and reject anything not on the list - obviously not what would be desirable for logging and interpreting can bus info, but for my purpose (replacing the av-nav) it would be very useful as it would dramatically reduce AVR overhead in receiving and parsing through the data.
 
Back
Top