Page 3 of 6

Re: Software On ELM Street - OBD2 Software Development

Posted: Tue May 19, 2015 1:49 pm
by Jayme
also note if you send the PID 20, since it is supported on E38, it will list the PID 21-40 supported, which includes things like O2 lambda, fuel rail pressure, pedal position, ethanol % .... all shit like that. which are all SAE and can add to my ADX if it is supported. just request PID 20,40,60,80 and send me the return packet and ill decode it into the list of supported SAE pid's.... be good to get stock wideband logging since E38 has lsu 4.9 sensors built in !!!

Re: Software On ELM Street - OBD2 Software Development

Posted: Tue May 19, 2015 1:58 pm
by Tazzi
Jayme wrote:I was under the impression the AVT baud speed didnt do anything anyway and it always runs at max speed! either way I havent touched any baud settings other than turning up the tunerpro baud setting to 512000

ill do a new ADX and put all the E38 SAE PID's into it :D that should get more attention than the shitty old alloytec one.
Ahhh I misread the baud.. I thought it was at 57600 lol.. its 512,000... just a tad faster.
Yeah that technically would be faster than the E38's bus!
Jayme wrote:also note if you send the PID 20, since it is supported on E38, it will list the PID 21-40 supported, which includes things like O2 lambda, fuel rail pressure, pedal position, ethanol % .... all shit like that. which are all SAE and can add to my ADX if it is supported. just request PID 20,40,60,80 and send me the return packet and ill decode it into the list of supported SAE pid's.... be good to get stock wideband logging since E38 has lsu 4.9 sensors built in !!!
PID 20,40,60,80.. yeeeeeeep. Should be able to do that.

Got to get the good ol ELM out for that :thumbup:

Re: Software On ELM Street - OBD2 Software Development

Posted: Tue May 19, 2015 2:03 pm
by Jayme
if I get really bored one night ill map out all 128 or so bits of pid's 20-80 into the check pid's function of my adx for other vehicles and maybe testing between E38 OSID's

Re: Software On ELM Street - OBD2 Software Development

Posted: Tue May 19, 2015 2:36 pm
by Tazzi
Jayme wrote:if I get really bored one night ill map out all 128 or so bits of pid's 20-80 into the check pid's function of my adx for other vehicles and maybe testing between E38 OSID's
I think I recall chucking up a full list of supported PID's for the E55.. didnt like many of the SAE PIDs. Mainly had enhanced PID's to choose from.
Will need to do the same on the E38.

But its a good start! Cant complain about 160Hz! :D
Thats razor sharp needle movement there!

Re: Software On ELM Street - OBD2 Software Development

Posted: Tue May 19, 2015 2:50 pm
by antus
the serial speed doesnt do anything, the FTDI runs at USB speed, and the 'serial' side of it is not used. I think it sources data from an i2c bus or something like that out of the AVTs cpu. To prove as much set the serial speed as slow as it'll go and i expect you'll still get 160hz.

160hz is quite possibly the laptop limit. They tend to start choking at about that speed and tunerpro stalls down and cant smash out the requests to the pcm any faster. Might be worth adding a short delay to the main macro so the laptop isnt peaking constantly while logging on battery.

Re: Software On ELM Street - OBD2 Software Development

Posted: Tue May 19, 2015 3:04 pm
by VL400
Dont forget its 160Hz per frame sent/received, ie it took about 6.25ms to send and receive one item. Its not 160hz update for every item, if you log say 50 items and one is RPM then that would update at 160/50 or 3.2Hz.

As an example, logging engine and trans messages on a VR is a max of around 6Hz per logged item (get an engine data frame 6 times per second plus a trans item frame 6 times per second, or 12 frames sent and received per second). Thats with almost no free bus time, flatout at 8192 baud bus speed verified on a scope. TunerPro reports over 10Hz... add in a small frame (say chatter disable) between each engine and trans frame and it increases to over 20Hz even though you are now getting less engine and trans data throughput. Its the average time the frames are being sent and received.

Re: Software On ELM Street - OBD2 Software Development

Posted: Tue May 19, 2015 3:08 pm
by Jayme
the main loop has 11 PID's so that should be around 14 frames per second. pretty good! imagine if we implemented a DPID adx and brought that down to 2 data frames per loop!

Re: Software On ELM Street - OBD2 Software Development

Posted: Tue May 19, 2015 3:09 pm
by VL400
Yeah doing that would get some nice data :D

Re: SAE CAN ADX for AVT cables

Posted: Tue May 19, 2015 3:35 pm
by Jayme
actually im thinking now... I wonder would any of this extra load on the E38 PCM by logging so fast will cause any issues while driving. I vaguely remember reading someone on a forum somewhere saying at a certain logging speed threshold whatever pcm he was using (mitsu or subi using tactrix cable I think) started to do funny things to fuelling and spark when logging.

Re: SAE CAN ADX for AVT cables

Posted: Tue May 19, 2015 3:47 pm
by Tazzi
Jayme wrote:actually im thinking now... I wonder would any of this extra load on the E38 PCM by logging so fast will cause any issues while driving. I vaguely remember reading someone on a forum somewhere saying at a certain logging speed threshold whatever pcm he was using (mitsu or subi using tactrix cable I think) started to do funny things to fuelling and spark when logging.
Hmmm not sure.
I know that the E55 really pumps frames out quickly when using DPID's.

Ill test with the ELM later and see if anything funny goes on while cruising around. Will also try the AVT.