[dazq]

I am moving discussion of the canbus interface here as it seems more appropriate.
Thus far the outline spec is as follows.
3 can bus interfaces running at 250kbit/s,500 and 1m,
1 CAN conbection for obd2 and eobd data access.
1 usb for connection to Tunerstudio and firmware updates,
1 serial to connect to speeduino,
1 sd card slot for data logging,
What else?

The idea is that you connect this bridge module onto the speeduino via tx3,rx3. You connect tunerstudio to the bridge instead of speeduino.
You can see all the data and change setup on the speeduino just as before like it was connected directly,But...
Other modules can be added to the canbus's and use any data there or add there own data.if they can add to the list of data for the obd port this is added via tab in ts.
First modules under development will be
1 a vvt controller for fully variable vvt on 2 ch (speeduino vvt?),
2 a transmission controller (initially for 5r55 but could be expanded in need be (speeduino shift?)
3 a clockset replacement back panel for gm corsa dash to drive the analogue needles via the integrated micro steppers.
Wow now i type it it looks more than when i think it , but these are all things i need as part of my project vehicle build which mechanically is very near done.
I am also going to be using the canbus in car for switch gear and light clusters!!! Just for fun ( and cos i want to ).
Wiring and first basic code coming soon , please your support and thoughts always welcome.
Darren

[bradacz]

Darren,
I interested to you use in my project too, I´m design my own board with CAN support in tx3,rx3.
My borad is called stadalone speeduino. I have skills to code and design, maybe we can discuss the CAN BUS.

Bradacz

[dazq]

Hi , yes any thoughts or assistance either way is great.
I did make some experiments driving the can directly off the speeduino using a spi can module but decided on a coprocessor design after seeing how too much load it put on the main speeduino processor.
More soon

[darren.tastic]

I'm currently looking into something similar - I just want to take the analog/digital signals from my non-OBD-II vehicle's gauge cluster/sensors, and output OBD-II so I can use an aftermarket digital dash.

I will advise where I get with this.

Darren

[dazq]

Which digital dash are you using?
If yiu are running speeduino it makes sense to use prepped data from its sensors rather than adding an addtional set?

[dazq]

Just to simplify things a little i have gotten some free samples of the stn1110 obd ic. My jag modules talk scp, an iso 1850 pwm format( not can) and as i have a list of all the scp codes for all the commands this saves me building my lighting ,fuel pump etc nodes, i can just use the oem ones!!
But these ic do pose a very good expansion option as they talk all the obd formats! oh gosh looks like i need another serial port !!!!!
Code news is that i can now parse nearly all data to the speeduino ecu and back to ts via the bridge and have a basic display(a 20x4 lcd )showing some of that data via a can connection, although that part is still hard wired and not yet configurable, i am having paging issues with the eeprom i think as configurations of some things get a bit mixed up. More soon......

[PSIG]

Tuning programs can currently connect, monitor, and burn tunes via Bluetooth through TX0/RX0 directly on the Mega. Direct serial, no USB. How would this be connected with the CAN board? On the serial in/out?

David

[dazq]

Isnt rx0 tx0 the same serial that the usb interface connects via? With the can bridge you could do exaclty the same thing but you would fit the bluetooth module on the bridge instead of the speeduino ecu.
Good point well raised there something to remember when i get to do a proper pcb for the can bridge, to leave a pluggin point for a bluetooth module on tx0 rx0.

I am using serial 3 on the speeduino to connect to the can bridge, but is only active when bridge mode is enabled on the speeduino,the usb and thus bluetooth if fitted on the speedy would still work even then .

I am thinking of going to a mega for the bridge too although it is running on test ok on a nano with softserial, but space is going fast due to all the data buffering.i may have to consider external spi memory when more data needs saving.

[dazq]

So heres a dilemma. How to add non obd can devices to the obd port... My thought is to have a page similar to the one i posted in the other can thread(over in firmware section) for every added can device to associate it's data that is relevant to an obd pid,the problem with that is for 64 supported ids uses 192-256 bytes of ram!minimum!!!.
Or but not sure how, should it be scanned by the bridge somehow?
Oem devices can be scanned, as long as the bridge knows what their address is(although when should it be done or how often?), but most aftermarket or self build devices wont support obd queries natively........
I have a similar issue with my non can jag oem modules which if i want to link from scp on pwmj1850 over to the can world will have to have a lookup for pids as a) they are manufacturer specific and b) are not obd listed but device relavent only!!!!

[PSIG]

So, would a uC translator slow it down excessively? Something like an ATTINY (maybe an inappropriate example) that stands as front-end add-on to any non-CAN or native-CAN device as a proxy of-sorts, taking the processing off-board and only on stuff that 'needs' it? Just thinking out-loud.

David