cwhite951 Posted January 2, 2019 Report Share Posted January 2, 2019 Has anybody configured the CAN BUS to work with the Stack ST9918? I just picked up one of these dashes for the track car and now need to get it up and running - any help woudl be appreciated! Quote Link to comment Share on other sites More sharing options...
Adamw Posted January 3, 2019 Report Share Posted January 3, 2019 their documentation says vipec is supported with a pre-configured template in their software. so set the dash protocol to vipec and set the speed to 1Mbit. set the ecu to transmit generic dash, baud 1Mbit and id 1000. if that doesn't work then attach your dash and ecu configs and I'll take a look. Quote Link to comment Share on other sites More sharing options...
cwhite951 Posted January 3, 2019 Author Report Share Posted January 3, 2019 Vipec is not listed in the pull down menu for ECU Protocols - here is the protocol editor, it seems to be pretty flexible BTW - better to use the CAN connection in the D harness or one of the com ports?: example for Electromotive TecS I have quite a bit of info going into Thunder that I would like to datalog on the Stack dash as well. usual engine data as well as wheel speed (ABS) and shock pots. thanks Quote Link to comment Share on other sites More sharing options...
cwhite951 Posted January 5, 2019 Author Report Share Posted January 5, 2019 So here is where I am at so far - a screen shot showing the Link can set up and the Stack can editor with the first couple of lines configured. I think I am going in the right direction - any comments? Also - any thoughts on number of bits per channel? It I get too much info (like all 16 bit) will it slow down communication if i have 30 channels? I am new to Can Bus to any thoughts/ help woudl be appreciated. Quote Link to comment Share on other sites More sharing options...
Adamw Posted January 6, 2019 Report Share Posted January 6, 2019 here is an example including rpm, press, temp, speed and a low res analog channel. Quote Link to comment Share on other sites More sharing options...
cwhite951 Posted January 7, 2019 Author Report Share Posted January 7, 2019 thanks Adam....a couple more Q's (because I get fixated on figuring stuff out!) When to use 8 b it vs 16 bit - I see in your example you used 16 bit for oil pressure. I woudl have guessed that 256 points would have been sufficient for a 0-100 scale. Does upping the detail in all the channels to 16 bit eventually choke the speed of the can bus? If its fast enough not to be an issue then we could 'default' to 16 bit for all data, if not I can 'dumb down' the resolutions to 8 bit for many items (pretty much all temps / pressures). I also saw that you used the bit bandwidth for the min/max values. In other example I notice that the min/max listed was the actual psi/temp/whatever that was being transmitted (I hope I don't zing the engine to 65,535 rpm!) - what is the correct approach? Does the 'file' name on the Stack editor make any difference? : BTW - I hard wired the can bus to the D connector on the Thunder ECU using Can 1 - seemed like the best way to do that - right? one last Q - every time I try to sign in I get an incorrect password notice. I reset the password to the same password and I good for that session. Odd. thanks Quote Link to comment Share on other sites More sharing options...
Adamw Posted January 8, 2019 Report Share Posted January 8, 2019 On 1/8/2019 at 7:21 AM, cwhite951 said: When to use 8 b it vs 16 bit - I see in your example you used 16 bit for oil pressure. I woudl have guessed that 256 points would have been sufficient for a 0-100 scale. Does upping the detail in all the channels to 16 bit eventually choke the speed of the can bus? If its fast enough not to be an issue then we could 'default' to 16 bit for all data, if not I can 'dumb down' the resolutions to 8 bit for many items (pretty much all temps / pressures). This just depends on the resolution and range of values you need to cover. 8 bit gives you 0-255, 16bit gives you 0-65535. It'''s not so much about choking the bus but more about fitting all the data you want to send into the minimum amount of frames. Our software only let's you set up 6 different message ID's, you can only fit 4 x 16 bit channels into a frame so that means you could only send 24 channels of data. There are ways to send multiple frames with a single ID but I don't see the point of sending more data with most of it being zeros. All data is sent in native metric units so oil pressure is Kpa. cold start you might see 600kpa so that's why we need 16 bits for oil press. for damper position, I would expect 1mm resolution would be fine and assuming we are not talking about a stadium truck then probably 255mm will be enough range, so 8bits is all we need. On 1/8/2019 at 7:21 AM, cwhite951 said: I also saw that you used the bit bandwidth for the min/max values. In other example I notice that the min/max listed was the actual psi/temp/whatever that was being transmitted (I hope I don't zing the engine to 65,535 rpm!) - what is the correct approach? I don't know how stack use the min max value. in some systems its just used to reject invalid data, in others me may also be used to scale the min/max value on the tachometer gauge for example. On 1/8/2019 at 7:21 AM, cwhite951 said: Does the 'file' name on the Stack editor make any difference? If you are talking about the 0x3E8, that is the message ID in Hexidecimal. Stack use Hex, Link uses Decimal. 0x3E8 = 1000 decimal. On 1/8/2019 at 7:21 AM, cwhite951 said: BTW - I hard wired the can bus to the D connector on the Thunder ECU using Can 1 - seemed like the best way to do that - right? yep, good. On 1/8/2019 at 7:21 AM, cwhite951 said: one last Q - every time I try to sign in I get an incorrect password notice. I reset the password to the same password and I good for that session. Odd. Make sure you are logging in with your username, not your email address. Quote Link to comment Share on other sites More sharing options...
cwhite951 Posted January 9, 2019 Author Report Share Posted January 9, 2019 16 hours ago, Adamw said: This just depends on the resolution and range of values you need to cover. 8 bit gives you 0-255, 16bit gives you 0-65535. It'''s not so much about choking the bus but more about fitting all the data you want to send into the minimum amount of frames. Our software only let's you set up 6 different message ID's, you can only fit 4 x 16 bit channels into a frame so that means you could only send 24 channels of data. There are ways to send multiple frames with a single ID but I don't see the point of sending more data with most of it being zeros. OK, I'm learning stuff one 'bit' at a time! I see that there is a 6 channel/stream limit but it seems to allow unlimited frames per stream - is there a limit of frames per stream? perhaps I need to fully understand the channel/stream/frame structure limitations - the G4+ CAN set up is allowing me to have unlimited streams and frames! 16 hours ago, Adamw said: All data is sent in native metric units so oil pressure is Kpa. cold start you might see 600kpa so that's why we need 16 bits for oil press. for damper position, I would expect 1mm resolution would be fine and assuming we are not talking about a stadium truck then probably 255mm will be enough range, so 8bits is all we need. My experience with other ECUs is that the native sensor range (say 0-5v) is divided by the resolution allowed by the bit count- so it would be .0196v per bit. if you had a 150psi sensor you would get .588v psi per bit (acceptable resolution). Same example for MAP sensor says that a 3 bar MAP sensor should give me .17 psi per bit - I level of detail that I am also comfortable with. I would think almost all data should be OK at 8 bit resolution - even RPM (8k limit) gives you 31rpm per bit vs 1.77 RPM per bit at 16 bit (OK- maybe 16 bit woudl be better for RPM!) 20 hours ago, Adamw said: I don't know how stack use the min max value. in some systems its just used to reject invalid data, in others me may also be used to scale the min/max value on the tachometer gauge for example. here is a more detailed example of the Stack input editor (input from a Porsche GT3 ECU as an example): I would assume that the output from the ECU is 0 to 16 bar and at 8bit you get the .0627 resolution. The 'output' becomes the info for the stack display. I really appreciate the help. I will be doing installs for others so I want to get all the details right on this one! Quote Link to comment Share on other sites More sharing options...
Adamw Posted January 10, 2019 Report Share Posted January 10, 2019 11 hours ago, cwhite951 said: My experience with other ECUs is that the native sensor range (say 0-5v) is divided by the resolution allowed by the bit count- so it would be .0196v per bit. if you had a 150psi sensor you would get .588v psi per bit (acceptable resolution). Same example for MAP sensor says that a 3 bar MAP sensor should give me .17 psi per bit - I level of detail that I am also comfortable with. I would think almost all data should be OK at 8 bit resolution - even RPM (8k limit) gives you 31rpm per bit vs 1.77 RPM per bit at 16 bit (OK- maybe 16 bit woudl be better for RPM!) FYI, you can use the test calculator in pclink to see how each parameter is stored and used in the firmware. Example for TP below. 0-100% with a resolution of 0.1%, so you need 1000 "bits". If you weren't worried about the 0.1% resolution then you could just use a divider of 10 and send it as an 8bit value. Quote Link to comment Share on other sites More sharing options...
cwhite951 Posted January 10, 2019 Author Report Share Posted January 10, 2019 that pretty handy to know about - thanks! Quote Link to comment Share on other sites More sharing options...
cwhite951 Posted January 10, 2019 Author Report Share Posted January 10, 2019 OK, so the last detail to get the Stack and Link configured is matching up the data transfer 'channels' Stack is looking for channels and each channel has a separate CAN id and each channel is limited to 8 bytes @ 8 bits each. its a little confusing that the stack has a very limited amount of data per channel but it looks little the Link is happy to fit in huge amounts of data per 'channel'. here is what I have set up so far: Link (under generic dash/user defined) has 6 channels each with what seems to be unlimited streams and each stream with unlimited frames. Link so far: to make it a little easier I am using the Link data with out modification to get it up and running (16 bit stays 16 bit). I can always play with that later. again - many thinks for guiding me thought this! the end result will be worth it. BTW - the Stack 9918 is a very cool dash/data system. I have to admit that the AIM (I have worked with their dataloggers quite a bit) is fine technically but i just don't like the aesthetics of the dash and the graphics. Some cool screens for the Stack: Yes - thats a dashboard screen that you can configure with any 4 scrolling data graphs! Race Dash. great predictive lap timing features Many more possibilities and they are all very editable to fit your needs. You can even set up a lat/long G force circle for driver coaching. and it very large....size is important (!) Quote Link to comment Share on other sites More sharing options...
Adamw Posted January 11, 2019 Report Share Posted January 11, 2019 With a standard CAN message you can only send a single frame per ID. Typically this is 8 bytes, Link allows longer frames but I don’t think the stack does (sometimes called DLC or data length code). To allow multiple frames to be sent with a single ID you use a compound message, in a compound message you use byte 0 as an index or indentifier. Stack call this a multiplexer. You can research how to construct a compound message yourself, there are examples in the help file such as the generic dash stream. Quote Link to comment Share on other sites More sharing options...
cwhite951 Posted January 11, 2019 Author Report Share Posted January 11, 2019 thanks. to get this all up and functioning I can live with the one frame per ID - that gets me 6 channels with 4 data items (at 16 bit). i'll play with converting to 8 bit and/or multiplexing when I need to (later) So if I am correct I should only have 1 stream with 1 frame per channel with each stream associated with a specific address Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.