Billigaste laddboxen med installation?

[ChristerSjo]

Som sagt. Det går helt att skippa detta om du vill ha noll vampire drain (iaf. den som är orsakad av Tibber).

Tibber guidar dig då till att lägga till en annan koppling i Tibber-appen som inte bygger på att du använder Tesla-integreringen.

Denna alternativ generiska kopplingen har då ingen som helst koppling mot Teslas moltjänst, och därmed ingen som helst direkt koppling mot Teslan heller. Därmed så kan Tibber heller aldrig orsaka någon vampire drain. Blir tekniskt omöjligt utan en sådan koppling.

Detta är inget som du måste göra. Ville bara tipsa dig, i all välmening, att ett sådant alternativ existerar (även om det ännu inte är officiellt).

Om man inte har koppling till Tesla så hur vet man då statusen?

Teslafi.com löser det ju och vissa använder deras API i stället men det är ju en betaltjänst.

Jag använder mig av Homey och den Tesla App som finns där (hade också problem att den väckte bilen men det är åtgärdat nu) + Tibber appen om jag vill ha avancerad styrning. Men som sagt i 98 fall av 100 är det billigaste att ladda mellan 00-06 och för det krävs ingen smart styrning.

[martinot]

Som sagt. Det går helt att skippa detta om du vill ha noll vampire drain (iaf. den som är orsakad av Tibber).

Tibber guidar dig då till att lägga till en annan koppling i Tibber-appen som inte bygger på att du använder Tesla-integreringen.

Denna alternativ generiska kopplingen har då ingen som helst koppling mot Teslas moltjänst, och därmed ingen som helst direkt koppling mot Teslan heller. Därmed så kan Tibber heller aldrig orsaka någon vampire drain. Blir tekniskt omöjligt utan en sådan koppling.

Detta är inget som du måste göra. Ville bara tipsa dig, i all välmening, att ett sådant alternativ existerar (även om det ännu inte är officiellt).

Om man inte har koppling till Tesla så hur vet man då statusen?

Enligt Tibber så låter de då Easee-boxen provladda bilen en kort stund, och då får de status och aktuell SoC hos bilen genom Typ2-kontakten (IEC 62196-2) och det protokoll som löper över den (SAE J1772), och som bilen använder när den pratar med laddboxen (Easee i detta fallet).

[root]

Som sagt. Det går helt att skippa detta om du vill ha noll vampire drain (iaf. den som är orsakad av Tibber).

Tibber guidar dig då till att lägga till en annan koppling i Tibber-appen som inte bygger på att du använder Tesla-integreringen.

Denna alternativ generiska kopplingen har då ingen som helst koppling mot Teslas moltjänst, och därmed ingen som helst direkt koppling mot Teslan heller. Därmed så kan Tibber heller aldrig orsaka någon vampire drain. Blir tekniskt omöjligt utan en sådan koppling.

Detta är inget som du måste göra. Ville bara tipsa dig, i all välmening, att ett sådant alternativ existerar (även om det ännu inte är officiellt).

Om man inte har koppling till Tesla så hur vet man då statusen?

Enligt Tibber så låter de då Easee-boxen provladda bilen en kort stund, och då får de status och aktuell SoC hos bilen genom Typ2-kontakten (IEC 62196-2) och det protokoll som löper över den (SAE J1772), och som bilen använder när den pratar med laddboxen (Easee i detta fallet).

Detta är nog en liten missuppfattning. Den här informationen finns inte att tillgå via laddkontakten.

Bilen kan kommunicera till laddboxen att laddkontakten sitter i och att bilen vill ha ström, dvs bilen ber laddboxen sluta reläet, eller reläerna, så det kan komma fram ström.

Laddboxen kommunicerar att det är OK för laddboxen att fråga efter att sluta reläerna och även hur mycket ström bilen maximalt får dra.

Inget annat, förutom vissa feltillstånd.

Laddboxen kan alltså inte få reda på tex SoC eller bilens identitet via laddkontakten.

J1772 är egentligen en amerikansk standard. Produktstandarden som täcker in laddboxar heter IEC 61851.

[kenjon]

SuC kan väl läsa av viss information, annars skulle ju vem som helst kunna ladda där?

[martinot]

SuC kan väl läsa av viss information, annars skulle ju vem som helst kunna ladda där?

Absolut. Har även sett Ionity läsa och visa bilars SoC (kika på Teslabjörns videor).

[kenjon]

Alla ställen jag har laddat på har faktiskt visat SOC...

[martinot]

Som sagt. Det går helt att skippa detta om du vill ha noll vampire drain (iaf. den som är orsakad av Tibber).

Tibber guidar dig då till att lägga till en annan koppling i Tibber-appen som inte bygger på att du använder Tesla-integreringen.

Denna alternativ generiska kopplingen har då ingen som helst koppling mot Teslas moltjänst, och därmed ingen som helst direkt koppling mot Teslan heller. Därmed så kan Tibber heller aldrig orsaka någon vampire drain. Blir tekniskt omöjligt utan en sådan koppling.

Detta är inget som du måste göra. Ville bara tipsa dig, i all välmening, att ett sådant alternativ existerar (även om det ännu inte är officiellt).

Om man inte har koppling till Tesla så hur vet man då statusen?

Enligt Tibber så låter de då Easee-boxen provladda bilen en kort stund, och då får de status och aktuell SoC hos bilen genom Typ2-kontakten (IEC 62196-2) och det protokoll som löper över den (SAE J1772), och som bilen använder när den pratar med laddboxen (Easee i detta fallet).

Detta är nog en liten missuppfattning. Den här informationen finns inte att tillgå via laddkontakten.

Bilen kan kommunicera till laddboxen att laddkontakten sitter i och att bilen vill ha ström, dvs bilen ber laddboxen sluta reläet, eller reläerna, så det kan komma fram ström.

Laddboxen kommunicerar att det är OK för laddboxen att fråga efter att sluta reläerna och även hur mycket ström bilen maximalt får dra.

Inget annat, förutom vissa feltillstånd.

Laddboxen kan alltså inte få reda på tex SoC eller bilens identitet via laddkontakten.

J1772 är egentligen en amerikansk standard. Produktstandarden som täcker in laddboxar heter IEC 61851.

Enligt Tibber så kan de läsa både bilens SoC och status gällande att ta emot laddning på detta sätt.

Har även sätt laddstationer (inte Tesla SuC) med skärmar som visar detta. Senast jag laddade hos Lidel på deras ABB-laddare så visade de vår Tesla M3 SoC exakt.

[martinot]

SuC kan väl läsa av viss information, annars skulle ju vem som helst kunna ladda där?

Absolut. De läser av biles unika ID för att checka att du har rätt att ladda. De checkar både att det är en Tesla, och om du är en Tesla, så checkar de att du har kredit att ladda (eller aktivt kreditkort kopplat till ditt konto).

Samma sak med Porsche som kan läsa ID och göra liknande check hos Ionity (även om det inte är helt färdigutvecklat sist jag checkade).

[Klintan]

Som sagt. Det går helt att skippa detta om du vill ha noll vampire drain (iaf. den som är orsakad av Tibber).

Tibber guidar dig då till att lägga till en annan koppling i Tibber-appen som inte bygger på att du använder Tesla-integreringen.

Denna alternativ generiska kopplingen har då ingen som helst koppling mot Teslas moltjänst, och därmed ingen som helst direkt koppling mot Teslan heller. Därmed så kan Tibber heller aldrig orsaka någon vampire drain. Blir tekniskt omöjligt utan en sådan koppling.

Detta är inget som du måste göra. Ville bara tipsa dig, i all välmening, att ett sådant alternativ existerar (även om det ännu inte är officiellt).

Om man inte har koppling till Tesla så hur vet man då statusen?

Enligt Tibber så låter de då Easee-boxen provladda bilen en kort stund, och då får de status och aktuell SoC hos bilen genom Typ2-kontakten (IEC 62196-2) och det protokoll som löper över den (SAE J1772), och som bilen använder när den pratar med laddboxen (Easee i detta fallet).

Detta är nog en liten missuppfattning. Den här informationen finns inte att tillgå via laddkontakten.

Bilen kan kommunicera till laddboxen att laddkontakten sitter i och att bilen vill ha ström, dvs bilen ber laddboxen sluta reläet, eller reläerna, så det kan komma fram ström.

Laddboxen kommunicerar att det är OK för laddboxen att fråga efter att sluta reläerna och även hur mycket ström bilen maximalt får dra.

Inget annat, förutom vissa feltillstånd.

Laddboxen kan alltså inte få reda på tex SoC eller bilens identitet via laddkontakten.

J1772 är egentligen en amerikansk standard. Produktstandarden som täcker in laddboxar heter IEC 61851.

Enligt Tibber så kan de läsa både bilens SoC och status gällande att ta emot laddning på detta sätt.

Har även sätt laddstationer (inte Tesla SuC) med skärmar som visar detta. Senast jag laddade hos Lidel på deras ABB-laddare så visade de vår Tesla M3 SoC exakt.

Det måste varit med CCS DC-laddning...

[Elmil]

Som sagt. Det går helt att skippa detta om du vill ha noll vampire drain (iaf. den som är orsakad av Tibber).

Tibber guidar dig då till att lägga till en annan koppling i Tibber-appen som inte bygger på att du använder Tesla-integreringen.

Denna alternativ generiska kopplingen har då ingen som helst koppling mot Teslas moltjänst, och därmed ingen som helst direkt koppling mot Teslan heller. Därmed så kan Tibber heller aldrig orsaka någon vampire drain. Blir tekniskt omöjligt utan en sådan koppling.

Detta är inget som du måste göra. Ville bara tipsa dig, i all välmening, att ett sådant alternativ existerar (även om det ännu inte är officiellt).

Om man inte har koppling till Tesla så hur vet man då statusen?

Enligt Tibber så låter de då Easee-boxen provladda bilen en kort stund, och då får de status och aktuell SoC hos bilen genom Typ2-kontakten (IEC 62196-2) och det protokoll som löper över den (SAE J1772), och som bilen använder när den pratar med laddboxen (Easee i detta fallet).

Detta är nog en liten missuppfattning. Den här informationen finns inte att tillgå via laddkontakten.

Bilen kan kommunicera till laddboxen att laddkontakten sitter i och att bilen vill ha ström, dvs bilen ber laddboxen sluta reläet, eller reläerna, så det kan komma fram ström.

Laddboxen kommunicerar att det är OK för laddboxen att fråga efter att sluta reläerna och även hur mycket ström bilen maximalt får dra.

Inget annat, förutom vissa feltillstånd.

Laddboxen kan alltså inte få reda på tex SoC eller bilens identitet via laddkontakten.

J1772 är egentligen en amerikansk standard. Produktstandarden som täcker in laddboxar heter IEC 61851.

Enligt Tibber så kan de läsa både bilens SoC och status gällande att ta emot laddning på detta sätt.

Har även sätt laddstationer (inte Tesla SuC) med skärmar som visar detta. Senast jag laddade hos Lidel på deras ABB-laddare så visade de vår Tesla M3 SoC exakt.

Ja, men då handlar det väl om DC-laddare?

CCS/Chademo/SuC har alla kommunikation med bilen, men det har inte J1772 som root skriver. J1772 har bara "signalering" som är till för att hantera vilken lastström bilen får dra från nätet.

[martinot]

Om man inte har koppling till Tesla så hur vet man då statusen?

Enligt Tibber så låter de då Easee-boxen provladda bilen en kort stund, och då får de status och aktuell SoC hos bilen genom Typ2-kontakten (IEC 62196-2) och det protokoll som löper över den (SAE J1772), och som bilen använder när den pratar med laddboxen (Easee i detta fallet).

Detta är nog en liten missuppfattning. Den här informationen finns inte att tillgå via laddkontakten.

Bilen kan kommunicera till laddboxen att laddkontakten sitter i och att bilen vill ha ström, dvs bilen ber laddboxen sluta reläet, eller reläerna, så det kan komma fram ström.

Laddboxen kommunicerar att det är OK för laddboxen att fråga efter att sluta reläerna och även hur mycket ström bilen maximalt får dra.

Inget annat, förutom vissa feltillstånd.

Laddboxen kan alltså inte få reda på tex SoC eller bilens identitet via laddkontakten.

J1772 är egentligen en amerikansk standard. Produktstandarden som täcker in laddboxar heter IEC 61851.

Enligt Tibber så kan de läsa både bilens SoC och status gällande att ta emot laddning på detta sätt.

Har även sätt laddstationer (inte Tesla SuC) med skärmar som visar detta. Senast jag laddade hos Lidel på deras ABB-laddare så visade de vår Tesla M3 SoC exakt.

Ja, men då handlar det väl om DC-laddare?

CCS/Chademo/SuC har alla kommunikation med bilen, men det har inte J1772 som root skriver. J1772 har bara "signalering" som är till för att hantera vilken lastström bilen får dra från nätet.

I CCS, så har du samma signaleringspinnar för både DC och AC. Informationen att Easee kan kommunicera på detta sätt kommer från tekniker på Tibber (som borde ha koll) som jag pratat med.

Skulle misstänka att de kan kommunicera med ett mer intelligent protokoll över dessa kommunikationspinnar för de bilar som stödjer det. Har dock själv varken byggt eller programmerat något kring detta, så skall själv låta både detta (är spekulation från min sida hur det kan förklaras) och detaljerna vara osagt.

Nästa gång jag är på Lidel skall jag testa att ladda AC 11 kW på samma laddare med informationsskärm som jag laddade DC 50 kW på. Kan återkomma i tråden med resultat när jag fått chans att prova detta (kan dock dröja 1-2 veckor).

Då alla ABB-laddare hos Lidel har både CCS DC Typ2, CHAdeMO, och AC Typ2, så är det lätt för vem annan som helst att testa under tiden. Kul att se vad resultatet blir!

[root]

Det jag beskrev var hur en enkel laddbox för hemmabruk fungerar.

Tesla SuC har ett eget protokoll. De kommunicerar med bilen och måste få reda på bilens ID. Det är egentligen det enda de behöver. I övrigt vet jag inte hur Teslas protokoll funkar.

Som flera andra påpekat är det lite annan värld i med CCS, där finns kommunikation på högre nivå, spelar ingen roll om det är AC eller DC. Man brukar inte ha CCS som hemmaladdare..

[martinot]

Det jag beskrev var hur en enkel laddbox för hemmabruk fungerar.

Tesla SuC har ett eget protokoll. De kommunicerar med bilen och måste få reda på bilens ID. Det är egentligen det enda de behöver. I övrigt vet jag inte hur Teslas protokoll funkar.

Som flera andra påpekat är det lite annan värld i med CCS, där finns kommunikation på högre nivå, spelar ingen roll om det är AC eller DC. Man brukar inte ha CCS som hemmaladdare..

Det är inte bara Tesla, utan det finns en ISO-standard kring protokollet som jag inte minns namnet/numret på (såg ett blogginlägg av en norsk utvecklare som jobbade med det). Det är detta ISO-protokoll som Porsche och Ionity använder (och som utvecklaren jobbade med).

I CSS så har du just samma pinnar för datakommunikationen, men olika pinnar för AC- och DC-strömmen. Detta till skillnad från CHAdeMO som är helt separat kontakt, och som kör med CAN-bussen.

[martinot]

Det är inte bara Tesla, utan det finns en ISO-standard kring protokollet som jag inte minns namnet/numret på (såg ett blogginlägg av en norsk utvecklare som jobbade med det). Det är detta ISO-protokoll som Porsche och Ionity använder (och som utvecklaren jobbade med).

I CSS så har du just samma pinnar för datakommunikationen, men olika pinnar för AC- och DC-strömmen. Detta till skillnad från CHAdeMO som är helt separat kontakt, och som kör med CAN-bussen.

Googlade lite och det verkar som det protokollet heter ISO 15118-1 (finns en från 2013 som jag tror är den som används i fordon idag, och en ny från 2019).

https://www.sis.se/produkter/fordonstek ... 511812015/

[root]

Det är inte bara Tesla, utan det finns en ISO-standard kring protokollet som jag inte minns namnet/numret på (såg ett blogginlägg av en norsk utvecklare som jobbade med det). Det är detta ISO-protokoll som Porsche och Ionity använder (och som utvecklaren jobbade med).

I CSS så har du just samma pinnar för datakommunikationen, men olika pinnar för AC- och DC-strömmen. Detta till skillnad från CHAdeMO som är helt separat kontakt, och som kör med CAN-bussen.

Googlade lite och det verkar som det protokollet heter ISO 15118-1 (finns en från 2013 som jag tror är den som används i fordon idag, och en ny från 2019).

https://www.sis.se/produkter/fordonstek ... 511812015/

Typ. Men högnivåsignalering, tex 15118, används inte i laddboxar för hemmabruk, i alla fall inte idag. Det kommer helt säkert att ändras i framtiden

Det närmate man skulle kunna komma är tex prylar från nuvve.

Dessutom går det naturligtvis att läsa SoC med hjälp av en app som använder Tesla-api-hacket, https://www.teslaapi.io, men inte med en hemmabox.

[martinot]

Verkar även finnas en tysk standard som konkurrerar med ISO, som heter DIN SPEC 70121, och som baseras på en tidig draft av ISO 15118.

Men den verkar inte stödja krypterad kommunikation (TLS) eller XML-baserade digitala signaturer (vilket bla. Porsche och Ionity använder för deras kommande automatiserade betallösning).

[root]

Verkar även finnas en tysk standard som konkurrerar med ISO, som heter DIN SPEC 70121, och som baseras på en tidig draft av ISO 15118.

Men den verkar inte stödja krypterad kommunikation (TLS) eller XML-baserade digitala signaturer (vilket bla. Porsche och Ionity använder för deras kommande automatiserade betallösning).

Glöm den. Det är 15118 som gäller för framtiden. Det är ett rörligt mål, fortfarande i stark utveckling. I folkmun kallas den "Vehicle to Grid", V2G" eller "Vehicle to Everything", "V2X", vilket anspelar på att man kan mata ström från bilen till elnätet.

15118 stödjer självklart kryptering. En grundtanke är Plug&Charge, dvs det vi gjort med SuC i flera år....

[martinot]

Verkar även finnas en tysk standard som konkurrerar med ISO, som heter DIN SPEC 70121, och som baseras på en tidig draft av ISO 15118.

Men den verkar inte stödja krypterad kommunikation (TLS) eller XML-baserade digitala signaturer (vilket bla. Porsche och Ionity använder för deras kommande automatiserade betallösning).

Glöm den. Det är 15118 som gäller för framtiden. Det är ett rörligt mål, fortfarande i stark utveckling.

Absolut, tyckte bara det var lite kul info! Klassisk DIN vs ISO-krig (där den förstnämnda förlorat).

Jo, det var ju därför jag nämnde och länkade till både nuvarande 2013-versionen, även och den helt nya 2019-versionen.

15118 stödjer självklart kryptering. En grundtanke är Plug&Charge, dvs det vi gjort med SuC i flera år....

Jo, det var ju precis det jag förklarade nyss.

Datan verkar f.ö. skickas genom att pulsbreddsmodulera en högfrekvent signal över CP-pinnen i CCS/Typ2-kontakten.

Jag fann denna info i en PDF från Vector (har själv tidigare jobbat inom fordonsindustrin, och med mjukvara från bla. Vector) som beskriver kommunikationen lite övergripande:

[root]

Bägge två verkar modulera en högfrekvent signal över CP-pinnen i CSS/Typ2-kontakten.

Jag fann denna sliden i en PDF från Vector (har tidigare jobbat inom fordonsindustrin) som beskriver den lite övergripande.

Nu börjar det bli liv i tråden! Kul!

I bilden ser man en komplett laddcykel inklusive att laddboxen ändrat duty cycle, dvs informerat boxen om nytt värde på maximal ström.

Se de två första punkterna:

Duty Cycle: Maximum current 0-100% (Det är inte helt korrekt, men vi låter det vara för enkelhets skull) Som exempel betyder 10% duty cycle att bilen får dra högst 6 Ampere. Frekvensen på fyrkantvågen i bilden som boxen startar är 1 KHz.
Voltage: Charging state (-12V to +12V)

Bilden visar precis det jag menade. Duty Cycle sätts av boxen för att informera om hur mycket ström bilen får dra. "Voltage" påverkas av bilen för att informera boxen om att kontakten är i och om bilen vill att boxen skall sluta reläet(erna) Sedan finns det regler för när boxen får starta PWM etc. Men inget om SoC...

Den andra bilden visar en metod att läsa spänningen i "topparna" på fyrkantvågen.

[martinot]

Bägge två verkar modulera en högfrekvent signal över CP-pinnen i CSS/Typ2-kontakten.

Jag fann denna sliden i en PDF från Vector (har tidigare jobbat inom fordonsindustrin) som beskriver den lite övergripande.

Nu börjar det bli liv i tråden! Kul!

Men inget om SoC...

Som jag förstått så är det så är data som SoC och annat troligen något som förs över som digital högnivådata (kallad HLC enligt ISO) pulsbreddsmodulerad med hög frekvens (PLC; se nedan) över CP-pinnen.

ISO 15118-3 addresses how powerline communication (PLC) is used to modulate the digital information specified in ISO 15118-2 onto the Control Pilot (CP) pin inside the charging cable.

https://www.iso.org/obp/ui/fr/#iso:std: ... ed-1:v2:en

Speciellt av intresse är termen HLC som definieras i 3.34:

High Level Communication
HLC
bi-directional digital communication using protocol and messages and physical and data link layers specified in ISO 15118 series
Note 1 to entry: High Level Communication in ISO 15118 is compliant with the term digital communication in SAE J1772/2836/2847/2931.

Nu har jag tyvärr inte längre möjlighet att ladda ner alla ISO-dokument och svenska standardiseringsdokument (vilket jag kunder göra på mitt förra jobb), men fann lite information om det här:

https://www.sis.se/api/document/preview/80001760/

Här är en bild som jag googlade upp som visar hela stacken av information, inklusive digital data ISO 15118-2:

[andersd]

Absolut, tyckte bara det var lite kul info! Klassisk DIN vs ISO-krig (där den förstnämnda förlorat).

Jo, det var ju därför jag nämnde och länkade till både nuvarande 2013-versionen, även och den helt nya 2019-versionen.

Nja, inget direkt krig mellan DIN och ISO här. DIN SPEC 70121 är i princip ett tidigt utkast av ISO15118, tyskarna ville inte vänta med att bygga bilar med DC-laddning tills ISO15118, därför släppte man DIN SPEC 70121.

DIN stödjer mycket riktigt inte kryptering och inte heller AC.

Vidare så finns det än så länge endast en version av ISO15118 ute. -1 finns mycket riktigt i två versioner, men den specificerar bara olika use cases. För den första versionen av ISO15118 specificeras själva protokollet i -2. För den andra versionen (2019) så kommer protokollet att specificeras i -20, som med lite tur kommer ut i en FDIS-version till sensommaren/ hösten.

Kan för övrigt nämnas att det knappt finns någon bil på marknaden som stödjer ISO15118 för AC.

Senast vi kollade, så stödde Tesla endast DIN SPEC 70121 och inte ISO15118 ens för DC. Dock så är det ett tag sedan vi kollade det nu.

[andersd]

Som jag förstått så är det så är data som SoC och annat troligen något som förs över som digital högnivådata (kallad HLC enligt ISO) pulsbreddsmodulerad med hög frekvens (PLC; se nedan) över CP-pinnen.

ISO 15118-3 addresses how powerline communication (PLC) is used to modulate the digital information specified in ISO 15118-2 onto the Control Pilot (CP) pin inside the charging cable.

Ja,som sagt, ISO15118 (och därmed även DIN) är en IP-baserad protkollstack som körs via ett PLC-modem.

Vid DC-laddning så finns SoC med som en parameter, dock är den tyvärr inte med i AC/laddning.

SoC kommer även vara helt frivilligt för bilen att skicka i nästa version...

[root]

Som jag förstått så är det så är data som SoC och annat troligen något som förs över som digital högnivådata (kallad HLC enligt ISO) pulsbreddsmodulerad med hög frekvens (PLC; se nedan) över CP-pinnen.

ISO 15118-3 addresses how powerline communication (PLC) is used to modulate the digital information specified in ISO 15118-2 onto the Control Pilot (CP) pin inside the charging cable.

Ja,som sagt, ISO15118 (och därmed även DIN) är en IP-baserad protkollstack som körs via ett PLC-modem.

Vid DC-laddning så finns SoC med som en parameter, dock är den tyvärr inte med i AC/laddning.

SoC kommer även vara helt frivilligt för bilen att skicka i nästa version...

Tack Andersd för förtydligandet om SoC och skillnaden mellan vid DC- och AC-laddning. Jag har själv inte jobbat med 15118 ännu, är fortfarande kvar i 61851-träsket..

[martinot]

Som jag förstått så är det så är data som SoC och annat troligen något som förs över som digital högnivådata (kallad HLC enligt ISO) pulsbreddsmodulerad med hög frekvens (PLC; se nedan) över CP-pinnen.

ISO 15118-3 addresses how powerline communication (PLC) is used to modulate the digital information specified in ISO 15118-2 onto the Control Pilot (CP) pin inside the charging cable.

Ja,som sagt, ISO15118 (och därmed även DIN) är en IP-baserad protkollstack som körs via ett PLC-modem.

Vid DC-laddning så finns SoC med som en parameter, dock är den tyvärr inte med i AC/laddning.

SoC kommer även vara helt frivilligt för bilen att skicka i nästa version...

Tack. Då har vi det klart. Märkligt dock att bilen enligt standarden inte kan skicka SoC bara för att man laddar AC istället för DC?

Det fysiska gränssnittet är ju exakt det samma, och då tycker man att det borde gå att ha samma protokoll och datafunktionalitet (som redan finns på plats i bilen och mjukvarustacken) oavsett DC eller AC?

Men alla standarder är ju inte alltid hel logiska eller helt genomtänkta (i min erfarenhet), så helt förvånad är jag kanske ändå inte, även om det är lite märkligt.

Sedan är jag lite förvånad att man inte valt att använda CAN-bussen, som är vanlig i både bilar och båtar, som hos CHAdeMO?

Har för mig att även den kinesiska standarden även den använder CAN (eller om det var den enklare LIN).

Men det kanske handlar om att man vill minimera antalet fysiska pinnar och kontakter i CCS/Typ2.

Jo, jag har förstått att det är standard IP-paket man kör. Att tunnla vanliga IP-paket är ju smart och vettigt. Då kan man ju återanvända mycket kod från färdiga mjukvarustackar (som man gör med tex. TLC och annat), och även lätt låta bil och annan utrustning enkelt köra samma IP-stack och övrig kod över tex. trådlös WiFi istället.

[root]

Som jag förstått så är det så är data som SoC och annat troligen något som förs över som digital högnivådata (kallad HLC enligt ISO) pulsbreddsmodulerad med hög frekvens (PLC; se nedan) över CP-pinnen.

ISO 15118-3 addresses how powerline communication (PLC) is used to modulate the digital information specified in ISO 15118-2 onto the Control Pilot (CP) pin inside the charging cable.

Ja,som sagt, ISO15118 (och därmed även DIN) är en IP-baserad protkollstack som körs via ett PLC-modem.

Vid DC-laddning så finns SoC med som en parameter, dock är den tyvärr inte med i AC/laddning.

SoC kommer även vara helt frivilligt för bilen att skicka i nästa version...

Tack. Då har vi det klart. Märkligt dock att bilen enligt standarden inte kan skicka SoC bara för att man laddar AC istället för DC?

Det fysiska gränssnittet är ju exakt det samma, och då tycker man att det borde gå att ha samma protokoll och datafunktionalitet (som redan finns på plats i bilen och mjukvarustacken) oavsett DC eller AC?

Men alla standarder är ju inte alltid hel logiska eller helt genomtänkta (i min erfarenhet), så helt förvånad är jag kanske ändå inte, även om det är lite märkligt.

Sedan är jag lite förvånad att man inte valt att använda CAN-bussen, som är vanlig i både bilar och båtar, som hos CHAdeMO?

Har för mig att även den kinesiska standarden även den använder CAN (eller om det var den enklare LIN).

Men det kanske handlar om att man vill minimera antalet fysiska pinnar och kontakter i CCS/Typ2.

Jo, jag har förstått att det är standard IP-paket man kör. Att tunnla vanliga IP-paket är ju smart och vettigt. Då kan man ju återanvända mycket kod från färdiga mjukvarustackar (som man gör med tex. TLC och annat), och även lätt låta bil och annan utrustning enkelt köra samma IP-stack och övrig kod över tex. trådlös WiFi istället.

Detta med SoC över AC eller DC gäller 15118, dvs inget som hemmaladdare kommer i närheten av ännu.

Hemmaladdare kommer inte inte åt SoC från bilen, hur gärna vi än vill.