sverreb

Knapt noen har noe problem med -30C i varmesystemet, men at varmepumpen har noe betydelig bidrag med en dT på 50K (I.e. en kabintemperatur på 20C) det er noe helt annet.

Da bruker de sannsynligvis en av de andre magnettypene. 200C er langt over der en standard neodyniummagnet sier takk og farvell. Spørmålet blir da mest på hvilken avveining mellom kostnad, levetid og effekttetthet de velger.

Rotoren med permanentmagnetene vil ta irreversibel skade (under antagelsen at den bruker normale neodyniummagneter) over ca 80C. AlNiCo magneter tåler mye mer temperatur men er noe svakere og blir lett demagnetisert av fysiske sjokk og eksterne magnetiske felt, men kan også brukes i motorer (men er ikke veldig vanlig i den applikasjonen meg bekjent, både sjokk og eksterne felt er en realitet i motorer så de er derfor noe utfordrende å bruke) Ferittmagneter vil også tåle temperaturen men er vesentlig svakere|. SaCo magneter kan også være en kandidat men igjen svakere. Høytemp neodyniummagneter er mulige å lage og er da gjerne det (teknisk) beste valget for en slik applikasjon

Mange biler, BMW inklusive (see teksten sitert fra BMW ovenfor) utveksler varme med andre systemer i bilen som batteri og motor. Dette er ikke unikt. Dette har heller ingenting med varmepumpens virkninggrad å gjøre. Når man høster varme fra andre komponenter så fungerer de som resistive varmeelementer, og når tesla bruker motoren som varmeelement så brenner de av elektrisitet i denne for å konvertere elektrisk energi til varme 1:1, akkurat slik man gjør det i en PTC*. Så det er ikke riktig at de ikke bruker varmeelement. *) Det er som vanlig noen kompromisser, max temp er nødvendigvis lavere siden permanentmagneter i rotoren ikke må bli for varme noe som øker nødvendig varmeveksleroverflate og varmemengden påvirker enten kompleksiteten til kjølesløyfen i motoren (dimensjoneres opp for å ta opp mer varme, en EV motor vil normalt ikke utvikle 10kW varme over tid), eller så har man mindre varme tilgjengelig

Varmepumpe er en funksjon av luftkondisjoneringsanlegget. Når vi snakker om varmepumpe i bil betyr det at luftkondisjoneringsanlegget som i praksis alle har for å kjøle kupeen om sommeren også kan reverseres og varme kupeen når det er kaldt. I prinsippet er den eneste forskjellen en ventil. I praksis er det en del andre designbetraktninger som gjør at systemet må designes for å ha varmepumpefunksjon, men det er altså ingen separat komponent, man bruker den samme kompressoren og de samme varmevekslerne som det alminnelige luftkondisjoneringsanlegget.

Det var en ny påstand. Hva mener du egentlig med det, og hva mener du er unikt for deres varmepumpe? Den fysiske realiteten er at alle varmepumper mister virkningsgrad når dT øker. Det betyr ikke at de ikke kan produsere varme men de blir etter hvert ikke bedre enn et resistivt varmeelement. Om du skal være noe mer enn en pedant her trenger du å vise at tesla har en meningsfull virkningsgrad i varmepumpen uansett dT, for praktisk jordiske temperaturer vel å merke, jeg bryr meg ikke om 0K. Dette strekker seg helt til 60-80K i temperaturdifferanse. Jeg imøteser dokumentasjon på at tesla kan opprettholde en virkningsgrad i varmesystemet på COP signifikant over 1 for en dT på si 70K

Man kan nok ikke uten videre sammenligne oppgitte forbrukstall nei. Noen oppgir med og andre uten ladetap. (I.e. hvor mye energi gikk ut av batteriet vs, hvor mye du må bruke for å lade batteriet opp igjen.)

Kommer litt an på hva du regner som 'BMS'. BMS er ikke en boks eller en softwaremodul alene. BMS består av * Overvåking og bypasskontrollere. Disse er fysisk koplet til hver enkelt celle, måler individuell cellespenning og kan shunte cellen (strømbegrenset via en resistor) for å balansere cellene. Typiske slike kretser kan overvåke opp til 16 celler, så man har flere av de i en bil. * Datainnsamling: Dette er kontrollsystemet som samler data fra overvåkningskretsene og så kommuniserer videre til styresystemene, denne sitter gjerne også i batteripakken. * Styresystem: Dette er i hovedsak software som instruerer laderegulatorer om ønsket ladespenning, informerer om maksimal belastning, styrer shunting av cellene og som bestemmer når kontaktorer lukkes og åpnes.

BMS arkitekturen er ikke anneledes for LFP vs NMC. Ladekurver og diversse parametre er anneledes, men det er bare en softwareendring unna. Men man kommer ikke til å bytte kjemi i en allerede produsert bil.

Se forøvrig: https://lovdata.no/dokument/SF/forskrift/1999-03-11-302

'Spørsmålene' dine var kun vage uspesifikke klager som koker ned til at du ikke forstod det som ble skrevet og ikke hang med på diskusjonen. Da hjelper det ikke å svare deg på nytt når det bare innebærer å gjenta meg selv. Har du konkrete spørsmål på noen av elementene i det jeg diskuterte så skal jeg forsøke å klargjøre, men disse uspesifikke klagene dine forteller meg ikke hvor du mistet tråden.

Tydelig det, det er derfor jeg ber deg lese på nytt siden forklaringen står der. Du får heller spørre om det er noe konkret som er uklart.

Da har det jo null effekt. Du kan naturligvis velge å la serverens instillinger bli nye standardinstillinger neste gang man starter bilen, men det er knappest fjernstyring av instillinger vi har snakket om, det er fjernstyring av noe som skal skje i bilen som var tema. Bilen aktiverer hovedbatteriet om det er nødvendig. De fleste bilprodusenter vil unngå at dette skal bli nødvendig annet enn når bilen lades eller når den kjøres noe som så setter begrensinger på hva applikasjonen kan tillates å gjøre. Les en gang til du. Som sagt man ønsker å minimere, helst elliminere at batteriets kontaktorer skal lukkes annet enn når det er strengt nødvendig. Dette har jeg nå sagt flere ganger. Dette setter designbegrensinger på hva man kan tillate seg å gjøre f.eks så må man optimere for minimum energibruk når bilen ikke er i bruk noe som tilsier at man må minimere hvor ofte bilen vekkes opp av fjernkontrollkommandoer.

Skal jo sies at man kan sitte i timesvis på i405 eller i75 uten å ha kommet mange kilometrene og uten å ha kommet ut for noe som er utfordrende for en adaptiv CC. Man kjører stort sett minimalt i gatene i amerikanske byer.

Det er selvsagt. Bilen og serveren synkroniseres når bilen er aktiv, det er aktiveringen i seg selv som gjerne er energimessig kostbar, ikke datautvekslingen som så skjer. At bil og server er synkron er imidlertid ikke videre relevant for diskusjonen, for interaksjonen som diskuteres er når appen oppdateres, ikke bilen. Denne oppdateringen skal presumptivt reflekteres i bilen så da må man ha en metode for at bilen skal vekkes og oppdateres. Denne metoden initieres av appen/serveren, og da må den ha et kriterie for å gjøre dette. Det kan enten være en eksplisitt bekreftelse fra brukeren, eller så må appen anta på et tidspunkt at brukeren er ferdig med å endre instillinger, noe man må bruke en timeout til og så oppdatere uten bekreftelse. Det er valgene man har. Så kommer realitetene for hvordan man lager biler inn: Man forventes å ha et svært bevisst og konservativt forhold til sikkerhet. Biler er noe av de farligste maskinene vi omgir oss med i forhold til kompetansekravene vi ilegger brukerne. Bilprodusentene gjør derfor en FMEA (Failure Mode and Effect Analysis) på hver minste komponent for å identifisere hva som kan gå galt og hvordan man minimerer risiko og konsekvens, og man har lært at man kan ikke uten videre anta en fornuftig bruker, systemet må altså lages så idiotsikkert som mulig. Derifra får vi et ønske om å minimere hvor mye energi bilen bruker mens den er inaktiv, for bruker man for mye må man gjøre tiltak som f.eks å aktivere bilens hovedbatteri, og det øker risiko. Så driver vi dette kravet over på applikasjonsutviklerne, og da kommer det ut av den prosessen at det å vekke bilen uten tydelig instruks fra brukeren dermed gir et negativt bidrag på sikkerhet p.g.a. unødig bruk av hovedbatteriet eller gir et negativt bidrag på brukeropplevelse ettersom bilen til sist må stenge for fjernkommandoer for å unngå å aktivere bilens hovedbatteri. Så blir spørsmålet hvordan man jobber seg rundt de kravene for å gi en best mulig brukeropplevelse. Man kan velge å ta seg friheter på risikoanalysen, men erfaringer tilsier at det kommer før eller siden og biter bilprodusentene bak. Det er derfor ikke uventet at bilprodusenter som har vært med en stund velger mer konservative løsninger. De som ikke lærer av andres erfaring vil måtte regne med å måtte lære av egen erfaring istedet...

Ingen brukere bryr seg om hva en server vet. Det er effekten i bilen som betyr noe. Jeg ser ikke at du ha kommet med noen forklaringenr som gir noen som helst innsikt som leder meg til andre konklusjoner. Jeg forventer faktisk at du er i stand til å delta i diskusjonen og forklare din posisjon ikke bare be andre om å kaste bort tid. Om du ikke er i stand til å komme med noe bedre enn RTFM, da kommer vi ikke videre.

Det er en overforenkling. I noen kontekster gir det mening at brukeren bekrefter instillinger fremfor at de underliggende systemene bruker bilens resurser på å implementere kommandoer som kanskje brukeren ikke ønsker, i.e. om du skal justere instillinger som kanskje skjer i mange trinn og kan innebære at en bruker endrer mening flere ganger, slik det gjerne er om instillingene har noe mer enn en av på knapp. I andre hvor det er entydig hva som ønskes som f.eks å velge en snapp som betyr start forvarming gir det mening at den sendes med en gang. Om du har et system hvor du gjør instillinger og forventer at de skal ha effekt i bilen uten at du skal bekrefte de kommer du ikke unna at UI må oppdatere bilen innen kort tid uten at den kan vite at instillingene var endelige for at bilen ikke skal oppleves uresponsiv, noe som betyr at mange kommandoer som kanskje aldri var meningen å sende vil ta effekt før de så igjen blir kansellert av brukeren. Som sagt magi finnes ikke, om du ikke ber om en bekreftelse på at et sett instillinger skal ta effekt kan du som applikasjonsutvikler ikke gjøre annet enn å anta at de skal det slik de momentant står. Applikasjonen kan velge å vente på noen sekunders inaktivitet, men neppe særlig mer.

Jeg håper du forstår at 99.9...% av brukerne aldri kommer til å skrive sin egen app, det er i realiteten kun hva den offisielle appen gjør som er relevant for brukerne, uansett hva det underliggende APIet gjør.

Da vil m.a.o. forvarmingen aldri starte. For alle formål vil da appen ikke virke. Det later ikke til å være et praktisk valg. Dette koker uansett ned til at når du har et UI som aldri forventer du skal bekrefte noe så må den oppdatere serveren med hver endring i UI og sende vekkekommandoen etter maksimalt en liten timeout for at bilen ikke skal oppleves som uresponsiv.

At du beskriver det som 'magi' tyder ikke på at du vet hva som foregår. Men hvis du skulle vite noe om hvordan serverne bestemmer når bilen skal oppdateres om det ikke er en timeout så beskriv det gjerne. Du kan godt bruke tekniske termer.

Så det er altså basert på en timeout slik jeg beskrev først, da kan du jo referere til det igjen. Magi finnes som kjent ikke. Du antar vel mye...

Så du må sende en våkne kommando for at endringene faktisk skal ta effekt? Hvordan er i så fall det forskjellig fra å trykke send?

Det er ikke egentlig ønskelig å lukke kontaktorene når bilen ikke lades eller er i bruk. Ikke at det er noen stor risiko, men det er alltid en noe høyere risiko for at feil skal få store konsekvenser når kontaktorene er lukket siden du da har høy spenning på langt flere punkter i bilen. Derfor vil man gjerne minimere tiden de er lukket og begrense det til når det er absolutt nødvendig som når bilen lader eller den kjøres. (Det er tross alt grunnen til at kontaktorene er der i første omgang) Derfor er det et rimelig kompromiss å heller være aggressiv på å spare energi når bilen ellers er passiv, selv om det medfører en og annen brukerbekreftelse, enn å la 12v batteriet tappes unødig.

Serveren må synkronisere status mot bilen. Man kan vente litt for å samle opp endringer, men siden brukeren ikke forventes å bekrefte med en 'send' kommando kan ikke serveren vente særlig lenge, maks noen sekunder, om det ikke skal gi en dårlig brukeropplevelse. I mellomtiden kan brukeren sitte og fikle i appen uten egentlig noen intensjon om å egentlig gjøre noe og holde bilen våken uforvarende. som enten resulterer i at 12v batteriet tappes ned unødig eller at hovedkontaktorene må lukkes uten at bilen lades eller at noen er til stede (som ikke er ønskelig)

Handler nok vel så mye om å ikke vekke opp bilen i tide og utide.