Can-Bus redone with some old-school engineering

Key words: another concept design.

The car is back, the rain is washing it for around two weeks and it will keep doing that until frogs will appear everywhere. So no useful pictures. The car is dirty again - some thin layer of orange goo. At the TV they say it's sand from Sahara. Looking on hackaday prize projects, it seems people are more interested in stationary toys, flying toys and portable game toys - which will eventually solve dust gathering problems in the near future, so let's jump deep into the rabbit hole.

It's time for some serious stuff - computing system architecture:

According to the figure, the engine and the wheel mechanics under the car are monitored (through some sensors/transducers) by the Arduino, which outputs some signals to the gauges (lights and data), and to the RasPI by means of SerialUSB() encoded strings. In the drawing there's just one Arduino but there may be more - depending on the development process.

To keep things in order and to allow further development without any major headaches, here's how to do it:

- option 1: implement modern automobile standards and throw away pots of money for undocumented sensors, interfaces, central control units, meaning no more retro approach and money thrown through the window;

- option 2: (re)engineer some new standard using old-school methods still widely used today.

First, a little history lesson:

To get things done quickly, the petroleum industry engineered a great tool called Well-site Information Transfer Specification which is a communications format used for the transfer of a wide variety of well-site data from one computer system to another. This was engineered back in the days when every byte of memory was so expansive that everybody felt comfortable with just 640 kilobytes of RAM. This transfer format is still widely used to exchange data between various types of petroleum drilling equipment, and from what I learned at my work place, this was first used in drilling equipment which were sent to the moon surface.

This format is based on plain text data, something like this:

13100400[.00]!!

13130200[.00]!!

First two chars (13) is the category of the measurement (in this case, chromatography gases)

Next two chars - methane (10) or ethane (13)

next four - the value in PPM

things between square brackets: optional decimal point + decimals

"!!" - end of string

So some equipment wishes to say: Look, I want to send you CHROMATOGRAPH data - methane 400 PPM and ethane 200 PPM. I also wish to inform you that current depth is 5000 feet, the temperature in the bottom of the hole is 160 degree F, we record increased gas levels, some vibrations, increased pressure and it is possible from the calculations that the well will erupt.

Something like that.

It is documented here - see the tables.

This is widely used even today, as there are a lot of equipment built many years ago - and they were built to last forever. It is simple, easy to extend for new categories and data and it is compatible with most of the systems on the market. At work place we even have computers with 80486 processors, running various well drilling monitoring applications with help from some sort of an old Unix, upgraded to 32 megabytes RAM and they still work perfect with no flaws.

WITS negative issues:

- unable to send negative numeric data;

- unable to send more than 2 decimals after digit point;

- it is scaled to be handled by old tech systems with small amount of memory, so special care should be taken when implementing on modern systems to keep things compatible.

And many more, which the contract from my work place forbids me to disclose.

To get things done, the arduino must generate a string which looks like a bunch of chained hot-dogs and send them to the RasPI in order for it to process, log, remote monitor and perform other operations.

If more Arduinos are desirable, then they can be easily interfaced without any further modifications to the software. Just an USB hub plus some ftdi converters.

For example, my AI-based vibration processor can easily encode the vibrations into such a WITS-based string using the PIC16F84 present on the board. This can also be handled by some small tiny memory microcontrollers which could be incorporated in later sensors.

At this time, the tables below are incomplete but expandable to whatever fits the needs of the project.

The proposed syntax looks like this:

"CONTROL>hotdog1>hotdog2>hotdog3!!\n"

The "hotdogs" are separated with ">" sign, then there's "end-of-string" from the original WITS and a new line at the end.

X>AAAA>BBBB>CCCC!!

"Hotdogs" explained:

X - control (bool) - is this parameter currently under manual adjustment? (0/1)

A - unit category

B - unit position

C - unit value

!! - end of string

CATEGORY 0000 - Computer (rasPI+monitor) power controls

Position	Value
0000 (relay 0)	0 (off), 1 (on)
0001 (relay 1)	0 (off), 1 (on)

CATEGORY 0001 - measurements

Position	Value
0000 (gasoline level)	0 -> 4096;
0001 (engine core temperature)	0 -> 4096;
0002 (battery level)	0 -> 4096;
0003 (engine core pressure)	0 -> 4096;
0004 (speed - km/h)	0 -> 4096;
0005 (RPM)	0 -> 4096;
0006 (rads, REM/s)	0 -> 4096;
0007 (batt charging, amps)	0 -> 4096;
0008 (gasoline consumption liter per min)
0009 (gasoline instant consumption milliliters/s)

CAT 0002 manual input states (boolean)

POSITION	VALUE (bool)
0000 (visibility lights, just to be noticed)	0 / 1
0001 (short range lights)	0 / 1
0002 (long range lights)	0 / 1
0003 (rear fog lights)	0 / 1
0004 (front fog lights - projectors)	0 / 1
0005 (direction signal)	0 / 1
0006 (foot brake)	0 / 1
0007 (manual brake)	0 / 1
0008 (belt 1)	0 / 1
0009 (seat 1)	0 / 1
000A (belt 2)	0 / 1
000B (seat 2)	0 / 1
000C (belt 3)	0 / 1
000D (seat 3)	0 / 1
000E (belt 4)	0 / 1

0010 (belt 5)	0 / 1
0011 (seat 5)	0 / 1
0012 (front left door)	0 / 1
0013 (front right door)	0 / 1
0014 (rear left door)	0 / 1
0015 (rear right door)	0 / 1
0016 (trunk)	(boolean values)

CAT 0003 automatic warning states (problems signaled by sensors)

errors that can be provided by car internals; lights, windshield wiper engine fault, electric window

POSITION	VALUE (bool)
0000 (low fuel alarm)	0/1
0001 (overheat alarm)	0/1
0002 (low pressure alarm)	0/1
0003 (vent engine alarm)	0/1
0004 (?)	0/1

CATEGORY 0004 - ambient parameters

POSITION	VALUE
0001 power-state	0/1
0002 back light dial - gas gauge	0-4096
0003 pointer light - gas gauge	0-4096
0004 back light dial - oil pressure gauge	0-4096
0005 pointer light - oil pressure gauge	0-4096
0006 back light dial - battery level gauge	0-4096
0007 pointer light - battery level gauge	0-4096
0008 back light dial - engine core temp gauge	0-4096
0009 pointer light - engine core temp gauge	0-4096
000A back light dial - speed gauge	0-4096
000B pointer light - speed gauge	0-4096
000C back light dial - RPM gauge	0-4096
000D pointer light - RPM gauge	0-4096
000E pointer light - radiation gauge	0-4096
000F pointer light - charger gauge	0-4096

CAT0005 - to be determined

Following the above tables, when the Arduino sends engine core temperature to RasPi (in order to print it on screen/draw a diagram in some Alien:Isolation retro style), the encoding string looks like this:

0>0001>0001>2048!!

first 0 - this measurement is not under manual calibration (raw data)

0001 -> measurement parameter

next 0001 -> engine core temperature

2048 ( half of dial) - meaning around 40 degree Celsius, temperature too low according to engine manufacturer, so the car should stay still until the temperature reaches 90 degree Celsius - recommended temperature for this type of engine.

__________________

1>0004>000A>0001!!

1 -> unit current in manual calibration mode (adjusting from Arduino Rotary Encoder)

0004 -> ambient parameter

000A - speed gauge back light

0001 - one unit above lower limit of 0...4096 interval, meaning there's no backlight set.

________________________

0>0001>0009>001F!!

0 -> raw data (not under current manual calibration)

0001 -> measurement parameters

0009 -> gasoline instant consumption milliliters/s

001F -> hexadecimal value (31 milliliters/second)

!! -> end of string

________________________

I hope you can follow the logic.

The receiving software (RasPI side) is based on fixed length string processing. Also old-school stuff.

The software implementation of this proposed old-school standard is now work in progress.

Since I do not have any GitHub account and I don't need any (I can barely handle my bank account which is empty most of the time), I will just paste them here when they are finished and when they prove their use.

Next update in the weekend.

In the mean time I must find a new place to build a proper lab. This project requires a lot of attention and it can't be done entirely from home.

[END OF TRANSMISSION]

______________________________________

kernel panic: improbability coefficient below zero