Sv: LEAF Manager - Android app til LEAF med klima-timerkontroll

[Lynet]

Så vidt jeg forstår kobles OVMS rett inn på CAN-bussen. Hva da med inn og utgangene som går rett inn på RAC?
Hvordan løses det på OVMS, har den ekstra inn- og utganger som kan konfigureres?

Tror airbaglampa styres via CAN-bus til RAC som igjen sender et signal til kontrollampeboksen.

[BauDemo]

Så vidt jeg forstår kobles OVMS rett inn på CAN-bussen. Hva da med inn og utgangene som går rett inn på RAC?
Hvordan løses det på OVMS, har den ekstra inn- og utganger som kan konfigureres?

Tror airbaglampa styres via CAN-bus til RAC som igjen sender et signal til kontrollampeboksen.

OVMS does not have extra in/out pins exposed. There are some pins on the PCB though that could be used for airbaglight function, but this is something I decided not to do.

I considered carefully and then I made a separate box that I call airbaglamp ecu. It just plugs in the place of the RAC unit and reenables the airbag lamp function as it was designed - when there is a problem with the airbag or related (pretensioners, etc) the lamp will turn on.

This airbaglamp ecu uses automotive grade MCU and takes care of only this particular function.
Installation is plug and play - takes max 15 min, and the most time consuming part is disconnecting the connector from the RAC unit. The RAC unit does not need to be removed.

I can sell airbaglamp ecu for around 3700 NOK.

[Lynet]

Hmmm, 3700,- for å få slukket lampa!! Da trur jeg at jeg bruker et annet alternativ: ta ut pæra 
Det er jo bare å lese ut eventuelle feilkoder med ujevne mellomrom 
(ingen feilkoder nå, selv om lampa lyser....)

[elektrolux]

I Sverige er det ikke så enkelt. Fungerer ikke lampen slik den skal, blir bilen avskiltet. Da er plutselig 3700 kr som småpenger å regne.

Og da er det godt å ha kapasiteter som Nicolay som kan gjenopprette riktig funksjon på disse kretsene.

[hma]

I considered carefully and then I made a separate box that I call airbaglamp ecu. It just plugs in the place of the RAC unit and reenables the airbag lamp function as it was designed - when there is a problem with the airbag or related (pretensioners, etc) the lamp will turn on.

I can sell airbaglamp ecu for around 3700 NOK.

From an isolated point of view the price seems quite high.
On the other hand, I know you have put a lot of effort in the project. The hw-components are also very expensive (especially when doing prototyping or low volume production), so taken to consideration that this is the only product on the marked which solves this critical issue, it's probably a fair price.

[Lynet]

I den Norske utgaven av EU-kontroll er ikke airbag nevnt. Airbag er et viktig sikkerhetstiltak for å redusere skader, men er ikke påbudt. Og om lampen lyser på Thinken er det ikke airbagsystemet som har feil, det er RAC som har hengt seg opp.
Det er ikke ment som kritikk av BauDemo at fiksen koster 3700,- men for min del blir det uaktuelt å bruke så mye for å få slukket pæra.
Har full forståelse for at hardware koster, og jeg har full forståelse for at BauDemo vil ha litt igjen for alt arbeidet han legger ned på Thinken.

Bruker heller noen tusenlapperpå OVMS 

[BauDemo]

This is really off-topic, and maybe we should create a new thread if you want to discuss price and functions in the airbaglamp ecu.

I do not mean to defend the price I set - and I fully understand if you someone wants to choose a different strategy to solving the problem - timer, short, connecting to another lamp just to name a few. None of these was a something I would be comfortable with in my car... so here is the solution, again, for myself. I would have paid that price for that function if such device existed.

The hardware is the cheapest part of this project - the price I set barely covers the assembly and parts procurement time. If I have to calculate research and development time and cost, it would probably end up costing 25 000 kr. This was made for my personal use and I just mentioned that I can provide a limited quantity to anyone willing to part with this amount of money.

Back to topic - how many have ordered ovms?

[Lynet]

Back to topic - how many have ordered ovms?

OVMS bestiller jeg så snart vi får vite om du er rimelig sikker på at det går an å lage program for Think City, og hvilke funksjoner som det blir mulig å legge inn.
Men hvis det er ønskelig at flere bestiller for testing så bestiller jeg.

[jahnarne]

Back to topic - how many have ordered ovms?

Da er OVMSen og SIM-kort på plass. Ser for meg å montere den med GPS og mobilantenne i Thinken til helgen.

BauDemo: ser du ikke har lagt ut noe kode på GitHub-repoet - betyr det at du kun jobber lokalt? Så opprinnelig for meg å kjøre en logg av CAN-bus-meldinger for å ha noe å starte med, men det har du kanskje alt gjort?

[BauDemo]

Back to topic - how many have ordered ovms?

Da er OVMSen og SIM-kort på plass. Ser for meg å montere den med GPS og mobilantenne i Thinken til helgen.

BauDemo: ser du ikke har lagt ut noe kode på GitHub-repoet - betyr det at du kun jobber lokalt? Så opprinnelig for meg å kjøre en logg av CAN-bus-meldinger for å ha noe å starte med, men det har du kanskje alt gjort?

I am having trouble understanding the windows client for GitHub, and was planning to sync back this weekend.
If you are super eager I can see if I can send you the think file that you can copy/paste and build.

[hma]

Ovms, Pickit3, antenna adapters and obdII-d9sub ordered.

[hma]

I have received my ovms-unit and antenna adapters, but have not had time to do anything, other than study the source code at GitHub https://github.com/thinkcity/Open-Vehicle-Monitoring-System/tree/master/vehicle/OVMS.X

I can see author 'markwj' have made a very small (example)file for Think City (vehicle_thinkcity.c) containing two interesting parts:

1) 'car_type' = TC (Think City)
BOOL vehicle_thinkcity_initialise(void)
  {
  char *p;

  car_type[0] = 'T'; // Car is type TCxx (with xx replaced later)
  car_type[1] = 'C';
  car_type[2] = 0;
  car_type[3] = 0;
  car_type[4] = 0;


The parameter 'car_type' is the code referred to as 'Vehicle Type' in the userguide https://github.com/markwj/Open-Vehicle-Monitoring-System/raw/master/docs/OVMS_UserGuide_TeslaRoadster.pdf page 19, when setting up the OVMS module via SMS/app.


2) Calculation of car_soc
Message 301, DOD is pulled from the CAN, but I wonder if this is correct? Maybe this was the error when BauDemo got got into 2nd of January 2013?
http://elbilforum.no/forum/index.php/topic,6755.msg73010.html#msg73010

    case 0x301:
      car_SOC = 100 - ((((unsigned int)can_databuffer[4]<<8) + can_databuffer[5])/10);


If the OVMS module is flashed with latest fw v.2.3.2 (e.g. V2_production.hex or V2_experimental.hex)
https://github.com/thinkcity/Open-Vehicle-Monitoring-System/tree/master/vehicle/firmware
it might present SOC "out of the box" to both SMS and the app.

The code of vehicle_twizy.c is much richer, containing tons of features, and some of them could be reused in the code of vehicle_thinkcity.c.
However we then need some Think-owners with programming skills (in C++)

Anyone who volunteers?

It would also be nice if BauDemo could give an explanation how the can-data in the different messages are pulled. I've been looking at the autorun.bas-file (from the new Nikometer) to compare with the methods in the ovms vehicle files, but I don't fully understand how data from each can-channel is read.

For the Think, my opinion is that SOC and a 'charge status message' are the most important parameters at a starting point.

[BauDemo]

It would also be nice if BauDemo could give an explanation how the can-data in the different messages are pulled. I've been looking at the autorun.bas-file (from the new Nikometer) to compare with the methods in the ovms vehicle files, but I don't fully understand how data from each can-channel is read.

Do you need more info on how can data is pulled in the "autorun.bas" or in the "vehicle_thinkcity.c"?

[hma]

Do you need more info on how can data is pulled in the "autorun.bas" or in the "vehicle_thinkcity.c"?

Both would be nice, but only if it's ok with you :)
Maybe we should comment vehicle_thinkcity.c in this post and autorun.bas in the post for "new nikometer"?

In the following I will sum up some of my findings (from both files) and ask a few questions:
(sorry if those are basic stuff, it's my first look into C-programming).

autorun.bas
The function "can addrxchnl" maps one message group to one channel.
E.g. add message 301 to channel 1:
can addrxchnl 1, &h301
Then rxchnl number 1 can be used to retrieve parameters in message 301.

In message 301 we find DC current, DC voltage, DOD and temperature. All those parameters are words of 2 bytes / 16 bits, split into high- and low byte.
The data from each parameter (within the message) are pulled with the function rxData(n), where 'n' is the position of each byte (8 bits).
E.g. DOD is the 4th and 5th bye in 301-message -> rxData(4), rxData(5)

In case of parameters containing non-negative numbers (unsigned integer), like DOD or voltage, the function getU16 is used to create a 16 bits long word from a 8 bits word, by multiplying high bits with 256
e.g. 0110 0101 -> 0110 0101 0000 0000
then the low byte is added.

For parameters both negative and positive (signed integer), like DC current, the function getS12 is used to create a 12 bit long word by multiplying the high bits with 256 and then adding the low byte.
Then, if the result is a negative number, hex8000 or greater  (most significant bit is set to '1') hexFFFF is subtracted.
If (result > &H8000) Then result = result - &HFFFF

Then there is a part I don't understand. Why is the low byte divided with 10?
E.g.
_dod=getU16(rxData(4),rxData(5))/10
_dccurrent=getS12(rxData(0),rxData(1))/10


Further on, the value in the parameters are formatted and printed like this:
Print Format$(100 - _dod,"% 4.1f");
Print Format$(_dccurrent,"%6.1f");

I assume the 4.1 and 6.1 notation is describing the length of the number and how many digits behind the decimal pointer?


vehicle_thinkcity.c
In the function vehicle_thinkcity_poll0 the databytes are read into an (array?) of variables, named 'can_databuffer[n]'. It handles unsigned integers, -non-negative numbers.

As for autorun.bas, DOD are found in databyte 4 and 5.
Instead of multiplying the high byte with 256 (adding 8 zeros to the end), they use this:
can_databuffer[4]<<8
(e.g. 0110 0101 -> 0110 0101 0000 0000)
then add the low bytes by:
+ can_databuffer[5])/10)

I don't understand the usage of 'this part:
unsigned int id = ((unsigned int)RXB0SIDL >>5)+ ((unsigned int)RXB0SIDH <<3);
I assume it's about shifting the bits 5 positions right for rxb0sidl (data low), and 3 positions left for rxb0sidh (data high), but can't figure out why?

How do I read the switch-part? :
car_SOC = 100 - ((((unsigned int)can_databuffer[4]<<8) + can_databuffer[5])/10);
How can I handle signed integers (like DC current)?
In vehicle_twizy.c one find:
// POWER:
      t = ((unsigned int) (can_databuffer[1] & 0x0f) << 8) + can_databuffer[2];
      if (t > 0 && t < 0x0f00)
      {
        twizy_power = 2000 - (signed int) t;


Then I wonder if any other files have to be modified to make it work with other values in the can-messages?
I assume the value of parameter 'car_SOC' is global available in the net_sms.c , net_msg.c and diag.c, making it available via SMS and the mobile app?

[BauDemo]

For the OVMS there is a dev-list, where the guys are very quick to respond and provide info/feedback.
Here are some answers that I hope help.

Then there is a part I don't understand. Why is the low byte divided with 10?
E.g. _dod=getU16(rxData(4),rxData(5))/10

If you look closely you will see that the division by 10 is for the result of the getU16 function, and simply means that the avalue is reported as multiplied by 10.
So if the car puts 576 on the bus, it would mean that the DOD is 57.6%.

The value is the parameters are formated and printed like this.
Print Format$(_dccurrent,"%6.1f");

I assume the 6.1 notation is describing the length of the number and how many digits behind the decimal pointer?

True

I don't understand the usage of 'this part:
unsigned int id = ((unsigned int)RXB0SIDL >>5)+ ((unsigned int)RXB0SIDH <<3);
I assume it's about shifting the bits 5 positions right for rxb0sidl (data low), and 3 positions left for rxb0sidh (data high), but can't figure out why?

I can't look at the code in detail now, but I think this is to make the frame ID - so the message id (for example 301) is reported as certain bit in the two bytes.

How do I read the switch-part? :
car_SOC = 100 - ((((unsigned int)can_databuffer[4]<< + can_databuffer[5])/10);
How can I handle signed integers (like DC current)?

The above (with shifting bits) is more efficient way than multiplication.
I suspect getting signed values will work in a similar fashion as the BAS code. I am sure there is better and more efficient way though.

Then I wonder if any other files have to be modified to make it work with other values in the can-messages?
I assume the value of parameter 'car_SOC' is global available in the net_sms.c , net_msg.c and diag.c, making it available via SMS and the mobile app?

There are some values that are common. If you want other values, you would need to define them yourself and the "override" one of the methods in the common modules with a method in the specific Think module.