In car multigauge

What are you developing?
Post Reply
User avatar
BennehBoy
Posts: 420
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: In car multigauge

Post by BennehBoy » Sun Feb 12, 2017 4:23 pm

RogerClark wrote: And integer maths is a lot faster than floating point. So if I only need 2 or 3 decimal points of accuracy, I multiply the original input by 100 or 1000, and use integer maths (as long as the value will fit in an integer), then split out the integer and decimal point parts when I display the value.
Does anyone know whether something like matlab can output the integer equivalent of a floating point calc?

I tried for about an hour to convert these relatively simple calcs to use scaled integers and unceremoniously failed on all counts - I wasn't very studious during any of my mathematics education :D
-------------------------------------
https://github.com/BennehBoy

User avatar
RogerClark
Posts: 6388
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: In car multigauge

Post by RogerClark » Sun Feb 12, 2017 9:33 pm

Its not essential to do interger maths, its just a lot faster on MCUs like the F103 that does not have a built in maths co processor.

You could always post your equations here, and see if anyone has any ideas

User avatar
BennehBoy
Posts: 420
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: In car multigauge

Post by BennehBoy » Wed Feb 15, 2017 8:20 pm

Does anyone have any examples of command/response queuing using FIFO's?

When I get above a few OBD requests per 250ms the simulator (and I assume real ECU's) begin to queue the commands internally and the responses come back asynchronously.

I think I need to issue commands based upon the speed that the data is likely to change, eg RPM I'd probably want to update every 250m/s but coolant temp could be a few seconds or longer interval.

I'll update my state machine to have a few different levels of data frequency requirements and then pop the requests in a queue.

I need to be able to issue the commands either batched up or on a regular interval, so it seems the best way to achieve this is to have a couple of FIFO's

Naturally I need to make sure the queue doesn't get overun.

One for outbound commands.

Another to store responses - this would be populated using a serial event. main code loop would then iterate over all the responses in the queue and process them.
-------------------------------------
https://github.com/BennehBoy

User avatar
BennehBoy
Posts: 420
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: In car multigauge

Post by BennehBoy » Mon Feb 20, 2017 1:25 pm

So it looks as though the asynchronous responses from the ELM327 simulator are erroneous.

The data sheet for the 327 states that it will only perform synchronous processing, anything sent to it whilst it is processing the current command is ignored unless it contains a carriage return - in this scenario is aborts the current process.

I still want to decouple the response processing from the command calls - currently the command calls spin in a while loop until a response comes back. This can take anything up to 200ms. Clearly this is a waste of cpu cycles. So with this in mind a FIFO for the responses may be of use.

What I need to figure out is whether the core serial buffer will hold enough response from the ELM for me to go on to doing other work and only processing the serial responses via serial.event which I believe happens every main program loop. I guess that serial handling is interrupt driven so this ought to work (I've not checked the core source yet to ascertain the default buffer size).

I think given use of a buffer in my serial.event code, and reading in all characters, I should be able to check if the ELM command prompt has been issued.

Assuming it has a simple case statement can be used to check the response type and populate my array of sensors with the appropriate results. I can also set a flag 'ELM_AVAILABLE' or similar which can be used to prevent further commands being issued in my loop if it is false.

All of this will probably rely quite heavily on the main loop being optimised.
-------------------------------------
https://github.com/BennehBoy

User avatar
rexnanet
Posts: 190
Joined: Wed Mar 16, 2016 10:34 am

Re: In car multigauge

Post by rexnanet » Mon Feb 27, 2017 11:04 am

Hi,

I'm also making an "onboard car computer" initially using ELM327.

Quickly found that ELM327 clones don't support all the AT commands (i.e. ATIB XX will be equal to ATI) so ditched that option.
My car is an Audi A4 and it uses the K-Line protocol. I've found an example code online (KW1281) and I'm modifying it to work on my ECU.
It's still WIP but I'm making progresses.

What protocol does you car use? Maybe ditching the ELM327 can be an option if you have so many problems...
I also got times where BT connection would go down and had to reboot the ELM and the HC05 too...

User avatar
BennehBoy
Posts: 420
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: In car multigauge

Post by BennehBoy » Mon Feb 27, 2017 11:50 am

My car uses a very early draft of the same protocol, ISO 14230.

I'm working on porting some code that talks using this protocol and have got it to work with an ecu emulator. I'll be fabbing up the actual K-line circuitry this weekend using an L9637D line driver, but I need to get my hands on a plug for the OBD port (I may butcher an ELM 327 that I have).

It may be that this port (which is partially functional now) would be a good start point for you -> https://github.com/BennehBoy/td5opencomstm32

The only finicky bits that will likely differ is that my vehicle expects a key response to a seed, you might need to hack that bit out of the code. It also has some strict timing to start the initialisation (300ms K-line held active), and 25ms delays between responses.

The emulator is also in the archive so that too might be a good place to look.

If you have a logic analyser I'd strongly recommend that you sniff the k-line on your vehicle, probably best done in conjunction with a working diags unit (which sort of defeats the purpose!).

Happy to help with any queries you might have.

To be clear....

I have working ELM327 code that happily reads generic diag info from an ELM327 emulator. My ELM clone also does not support k-line so it fails to work with this, however it will read the same PIDS from CAN vehicles.

I _also_ am working on a K-line based port of a diag system that is for my actual vehicle, the intention is that I will either directly integrate the code into my other project, or more likely I'll make an ELM327 translator that my other project will connect to via bluetooth.
-------------------------------------
https://github.com/BennehBoy

User avatar
rexnanet
Posts: 190
Joined: Wed Mar 16, 2016 10:34 am

Re: In car multigauge

Post by rexnanet » Mon Feb 27, 2017 11:58 am

That's exactly how I diagnosed the code running on the STM32:
- stripped the OBD USB adapter and connected wires to RX, TX and GND.
- plugged the logic analyser and made some reading.
- Captured the waveforms, decoded it all with the software and exported to CVS file :)

I got the 5-baud init to work and got the ACK ok but now the code doesn't recognize the stream that the ECU sends with the name string.
Have to debug that.

I stripped one of my ELM dongles to connect it to the K-line but I also have some MC33660 that I am still experimenting on.

What does the td5 mean? Will the code work on ISO9141?

User avatar
BennehBoy
Posts: 420
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: In car multigauge

Post by BennehBoy » Mon Feb 27, 2017 12:40 pm

TD5 is the Land Rover engine code (Turbo Diesel 5 cylinder), it uses a bespoke ECU developed by Lucas (MC68836 CPU32 based).

I doubt the code will work with 9141, I suspect all the command/PID id's will be different. Although, isn't 9141 just the K-line transport layer? With 14230 being the protocol layer sitting atop it?
-------------------------------------
https://github.com/BennehBoy

User avatar
rexnanet
Posts: 190
Joined: Wed Mar 16, 2016 10:34 am

Re: In car multigauge

Post by rexnanet » Mon Feb 27, 2017 3:45 pm

From what I read they are both protocols and both use K-line (L-line as optional)
https://en.wikipedia.org/wiki/On-board_diagnostics
They seem to refer to the lower layers of the OSI model (maybe physical and link layers).
From the Wiki the ISO 14230 is "Physical layer identical to ISO 9141-2".

KW-1281 and KWP2000 specify the application layer. So maybe the diference is only there...

User avatar
BennehBoy
Posts: 420
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: In car multigauge

Post by BennehBoy » Mon Feb 27, 2017 4:00 pm

Squonk42 wrote:I explored the subject of IMUs not a long time ago, and here are the results (beware, lot of links below, but very useful!).

I recommend using Sparkfun's MPU9250 Arduino library from Github instead:
https://github.com/sparkfun/SparkFun_MP ... no_Library
So I hooked up the 9250 and tried the sparkfun code.

Pitch and roll work fine, but yaw (compass heading) is just plain wrong.

I'm going to retry using no headers and copper wire only to the breakout board, but I thought the calibration pahse of waggling it about in the air would sort out the local iron issues :(

I can see the compass being dumped at this rate.
-------------------------------------
https://github.com/BennehBoy

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest