Bli medlem i Norsk elbilforening og støtt driften av Elbilforum. Som medlem får du i tillegg startpakke, medlemsfordeler og gode tips om elbil og lading. Du blir med i et fellesskap som jobber for mindre utslipp fra veitrafikken. Medlemskap koster 565 kroner per år. elbil.no/medlemskap

OVMS for Think

Startet av BauDemo, onsdag 19. desember 2012, klokken 16:09

« forrige - neste »

Lynet

#15
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.
Trondheim:
Tesla X100D 2019 modell.

BauDemo

#16
Sitat fra: Lynet på fredag 11. januar 2013, klokken 16:47
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.

laddplats? -www.uppladdning.nu
nikometer? - www.evmonitor.info

Lynet

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

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. ;)
Stavanger:

Selger utstyr for EV lading og energieffektivisering via http://elbilhjelpen.no AS

Har for tiden Tesla S85, Smart ED, BMW C- evolution, Carver S+, Monotrazer MTE-150, Citroen C1 EVie, div. Think og PSA Classic og City 2010 model, Chin 3 hjuler Pickup, Buddy M9 samt Vectric scooter. Venter på Microlino og Aptera #2246

Daglig leder i Elbilhjelpen.no

hma

Sitat fra: BauDemo på fredag 11. januar 2013, klokken 17:58
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.
- Toyota Rav4 EV 2000 NiMH (06/2010), Hyundai Ioniq 5 P45 (08-2021)
   (tidl.: Think 2000 NiCd (06/2009-05/2012) - Think City 2010 Zebra (03/2012-10/2012) - Think City 2009 Zebra (05/2012-05/2014)  - Tesla Model S85 2014 (06/2014-09/2017) - Nissan Leaf 2018 LE 40kWh (04/2018-12/2018) - Tesla Model S75D (12/2018-06/2021) )
- Trondheim (Trøndelag Elbilforening 02/2012-04/2014)
- Ariens AMP 24 to-trinns snøfreser 48V litium 52,5Ahr (10/2012)

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  :D
Trondheim:
Tesla X100D 2019 modell.

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?
laddplats? -www.uppladdning.nu
nikometer? - www.evmonitor.info

Lynet

Sitat fra: BauDemo på mandag 14. januar 2013, klokken 15:24
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.
Trondheim:
Tesla X100D 2019 modell.

jahnarne

Sitat fra: BauDemo på mandag 14. januar 2013, klokken 15:24
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

Sitat fra: jahnarne på onsdag 23. januar 2013, klokken 19:25
Sitat fra: BauDemo på mandag 14. januar 2013, klokken 15:24
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.
laddplats? -www.uppladdning.nu
nikometer? - www.evmonitor.info

hma

Ovms, Pickit3, antenna adapters and obdII-d9sub ordered.
- Toyota Rav4 EV 2000 NiMH (06/2010), Hyundai Ioniq 5 P45 (08-2021)
   (tidl.: Think 2000 NiCd (06/2009-05/2012) - Think City 2010 Zebra (03/2012-10/2012) - Think City 2009 Zebra (05/2012-05/2014)  - Tesla Model S85 2014 (06/2014-09/2017) - Nissan Leaf 2018 LE 40kWh (04/2018-12/2018) - Tesla Model S75D (12/2018-06/2021) )
- Trondheim (Trøndelag Elbilforening 02/2012-04/2014)
- Ariens AMP 24 to-trinns snøfreser 48V litium 52,5Ahr (10/2012)

hma

#26
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.
- Toyota Rav4 EV 2000 NiMH (06/2010), Hyundai Ioniq 5 P45 (08-2021)
   (tidl.: Think 2000 NiCd (06/2009-05/2012) - Think City 2010 Zebra (03/2012-10/2012) - Think City 2009 Zebra (05/2012-05/2014)  - Tesla Model S85 2014 (06/2014-09/2017) - Nissan Leaf 2018 LE 40kWh (04/2018-12/2018) - Tesla Model S75D (12/2018-06/2021) )
- Trondheim (Trøndelag Elbilforening 02/2012-04/2014)
- Ariens AMP 24 to-trinns snøfreser 48V litium 52,5Ahr (10/2012)

BauDemo

Sitat fra: hma på tirsdag 23. juli 2013, klokken 01:17
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"?
laddplats? -www.uppladdning.nu
nikometer? - www.evmonitor.info

hma

#28
Sitat fra: BauDemo på tirsdag 23. juli 2013, klokken 23:16
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?
- Toyota Rav4 EV 2000 NiMH (06/2010), Hyundai Ioniq 5 P45 (08-2021)
   (tidl.: Think 2000 NiCd (06/2009-05/2012) - Think City 2010 Zebra (03/2012-10/2012) - Think City 2009 Zebra (05/2012-05/2014)  - Tesla Model S85 2014 (06/2014-09/2017) - Nissan Leaf 2018 LE 40kWh (04/2018-12/2018) - Tesla Model S75D (12/2018-06/2021) )
- Trondheim (Trøndelag Elbilforening 02/2012-04/2014)
- Ariens AMP 24 to-trinns snøfreser 48V litium 52,5Ahr (10/2012)

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.

Sitat fra: hma på torsdag 25. juli 2013, klokken 02:39
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%.

Sitat fra: hma på torsdag 25. juli 2013, klokken 02:39
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

Sitat fra: hma på torsdag 25. juli 2013, klokken 02:39
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.

Sitat fra: hma på torsdag 25. juli 2013, klokken 02:39
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)?
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.

Sitat fra: hma på torsdag 25. juli 2013, klokken 02:39
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.
laddplats? -www.uppladdning.nu
nikometer? - www.evmonitor.info

© 2024, Norsk elbilforening   |   Personvern, vilkår og informasjonskapsler (cookies)   |   Organisasjonsnummer: 982 352 428 MVA