Lesing av AMS/HAN uten spenningsforsyning ("The complicated way")

[ArnieO]

 

46 minutes ago, Marius-H said:

The tibber module uses supercaps as energy storage and the  probably do some clever sleep, temp data storage on the esp to make it work with the esp32 they are using.

The module we're working on is using a 1 F super cap.

Hardware is OK, the challenge is to tune the firmware to consume in average no more than 30 mA over a full 10-second cycle (Kamstrup sends data each 10 sec).

 

And when this is solved there is an additional challenge that the Kamstrup each hour sends an additional data telegram that contains accumulated kWh-reading. This telegram does not replacement of a 10-second telegrams, but is sent inbetween. Assumed to be manageable by exploiting time data sent as part of the telegrams - and some careful programming.

Endret 2. desember 2019 av ArnieO
Added table that illustrates how hourly List 2 telegrams are sent inbetween 10-second List 1 telegrams

[Marius-H]

5 minutter siden, ArnieO skrev:

, ca 15

The module we're working on is using a 1 F super cap.

Hardware is OK, the challenge is to tune the firmware to consume in average no more than 30 mA over a full 10-second cycle (Kamstrup sends data each 10 sec).

 

And when this is solved there is an additional challenge that the Kamstrup each hour sends an additional data telegram that contains accumulated kWh-reading. This telegram does not replacement of a 10-second telegrams, but is sent inbetween. Assumed to be manageable by exploiting time data sent as part of the telegrams - and some careful programming.

 

Cool. I just saw your GITREP just now. Could you share the schematics as a PDF?

[ArnieO]

@spenceme made the electrical design and PCB based on some of my initial ideas. The documentation is on his Github: https://github.com/dakarym/AmsToMqttBridge

 

I have not checked but believe/assume the attached schematic corresponds to the KiCAD files on his Github.

schematic.pdf

[spenceme]

7 hours ago, ArnieO said:

@spenceme made the electrical design and PCB based on some of my initial ideas. The documentation is on his Github: https://github.com/dakarym/AmsToMqttBridge

 

I have not checked but believe/assume the attached schematic corresponds to the KiCAD files on his Github.

schematic.pdf 117.27 kB · 1 download

 

That should be the current schematic.  

[tronde]

Med utgangspunkt i kretsen til ArnieO:

 

Det bør gå an å spare bort forbruket til TSS721. Den skal ikke være nødvendig når det ikke er mer enn en master og en slave, og det kun er lesing av slaven som gjelder. Jeg vet at det ble gjort noen forsøk i den andre lange tråden med OP-amper og zenerdioder, og at det ikke funket helt. 

 

Jeg har gjort en papirøvelse som jeg mener burde funke som erstatning. Der bruker jeg en kondensator og en treg tidskonstant for utlading  for å "huske" maks spenning på bussen. Den deles ned til ca. 1V og brukes som referanse til en OP-amp koplet som komparator. Det kan være at man bør legge inn en liten hysterese. En dedikert komaparator kan selvfølgelig også brukes. Det finnes ultra low power OP-amper for 3V3 som har rail-rail utgang som bør funke.

 

Hvis maks spenningen endrer seg over tid, vil også referansespenningen endre seg tilsvarende slk at omslagspunktet mellom høy og lav vil være prosentvis likt.

 

D1 er den samme som i den opprinnelige kretsen. R5 er for å (eventuelt) hindre at kondesatoren suger bussen tom ved oppstart. Det er ikke store kondensatoren som skal til med 10M i utladeveien. Litt finpuss på R2 og / eller R4 bør gi et brukbart spenn mellom høy og lav som holder støy unna. De viste verdiene bør gi ca. 16,5V som omslagspunkt ved 24V inn. Det eneste man må passe på, er at spenningen på OP-ampens innganger ikke går over dens drivspenning.

[ArnieO]

15 hours ago, tronde said:

Med utgangspunkt i kretsen til ArnieO:

 

Det bør gå an å spare bort forbruket til TSS721.

Det har du nok rett i, og en Opamp-løsning vil helt sikkert fungere.

Men TSS721 har et neglisjerbart forbruk, så jeg anser det som enklere å bruke den.

Smak og behag!

[tronde]

Den er ikke neglisjerbar på Kamstrup. Det er ikke chipens egetforbruk som teller. TSS721 er konstantstrømlast på bussen. Du kan senke strømmen ved å øke R13, men ikke helt til null.

[Steve0]

Litt enig i @tronde sin kommentar. Mistenker også at dette designet ikke oppfører seg ihht M-Bus standarden, dersom helheten ikke oppfører seg som konstant strømlast?

 

Sitter selv og tenker på hvordan dette kan forbedres. Kanskje legge til en 'current sink' med målemotstand som måler strømbruk direkte fra M-Bus, og en mosfet/transistor for å bruke forskjellen mellom DCDC-ens strømtrekk og en konstant 6mA last?

[tronde]

5 timer siden, Steve0 skrev:

Litt enig i @tronde sin kommentar. Mistenker også at dette designet ikke oppfører seg ihht M-Bus standarden, dersom helheten ikke oppfører seg som konstant strømlast?

 

Sitter selv og tenker på hvordan dette kan forbedres. Kanskje legge til en 'current sink' med målemotstand som måler strømbruk direkte fra M-Bus, og en mosfet/transistor for å bruke forskjellen mellom DCDC-ens strømtrekk og en konstant 6mA last?

.

Nei, den er ikke etter standarden, men jeg kan ikke se at det behøves heller når det kun skal leses fra en kilde. Det er kun ment som en mulig løsning for å spare noen verdifulle milliwatt.

 

Spenningen på porten ser ut til å svinge ubelastet, i alle fall på Aidon som jeg har. Poenget med konstantstrøm er jo at M-bus faktisk er en ekte buss hvor flere enheter kan være aktive, og at konstantstrømmen gjør den veldig robust med hensyn til elektrisk støy.

 

Jeg har ikke ultra low power op-amp i huset, men kan prøve å kople opp noe for å se om det er liv laga.  Nå ser det jo ut som om Kamstrup har mer energi tilgjengelig enn først antatt, så behovet er kanskje ikke så stort.

[Steve0]

26 minutter siden, tronde skrev:

Nå ser det jo ut som om Kamstrup har mer energi tilgjengelig enn først antatt, så behovet er kanskje ikke så stort.

Har jeg gått glipp av noe? Dokumentasjonen dems tilsier vel max 6mA / 4 slave units?

[tronde]

44 minutter siden, Steve0 skrev:

Har jeg gått glipp av noe? Dokumentasjonen dems tilsier vel max 6mA / 4 slave units?

Se noen av de siste innleggene fra 28. nov og ut. Marius-H fant ut at det er en plugg til på Kamstrup.

[ArnieO]

42 minutes ago, Steve0 said:

Har jeg gått glipp av noe? Dokumentasjonen dems tilsier vel max 6mA / 4 slave units?

Fra Mbus ja - det stemmer. Men det kom et veldig interessant tips fra @Marius-H i "maratontråden" om at man kan koble seg rett på Kamstrup-måleren, foran HAN-modulen som plugges inn. Der er det tilgang på mer effekt: 75 mA @ 4,15V

 

[tronde]

Jeg har gjort en kjapp test på OP-amp kretsen hvis noen vil prøve den. Den grunnleggende logikken er OK. Jeg har testet en litt annen utgave mot Aidon hvor jeg forsyner OP-ampen fra bussen, men det kan ikke være noe som hindrer den i bli bygget slik jeg viste tidligere hvor drivspenningen kommer fra 3,3V,. Det kan sikkert lønne seg å justere litt på motstandene for å få et godt omslagspunkt.

 

Forutsetningen for at kretsen skal ha noe for seg i en selvforsynt komplett sender, er at man velger en OP-amp med lavest mulig egenforbruk. Hvor mye nytte det gir, avhenger av hvor presset man er på tilgjengelig energi. Den kretsen jeg viste tidligere bør bruke mindre enn 10uA fra bussen pluss egenforbruket i OP-ampen som ikke er mange uA fra 3,3V regulatoren hvis man velger en extra low power type. LM358 som jeg brukte vil vel brenne ca 4-5mW fra 3,3V. Det går an få det mye lavere med andre kretser.

En annen fordel er at den koster en del mindre enn M-bus chippen.

 

Jeg legger ved den kretsen jeg testet med nå i kveld. Der er inngangene på OP-ampen krysset fordi den driver en optokopler som inverterer signalet. Kretsen tåler maks 36V, men Aidon sier selv at de gir ut maks 24. Hva de to andre gir ut aner jeg ikke. Jeg vet heller ikke om de krever at slaven faktisk trekker strøm slik standarden egentlig krever. Aidon er helt tydelig +24V / +15V som spenning.

 

Løsningen som er lagt ved her bruker mer enn en M-bus chip, men det er ikke noe problem hvis man ikke skal mate senderen fra bussen. 

HAN-adapter_for_Aidon.pdf

[ArnieO]

Til dere som følger tråden: Dette prosjektet er avsluttet for min del; det ble for komplekst å få til.

 

Erstattes av nytt prosjekt (skreddersydd for Kamstrup måler) i denne tråden:

 

[tronde]

Det er nok mest fornuftig med en skreddersydd når muligheten er der, ja. Det har uansett belyst en del interessante problemstillinger, så det er ikke bortkastet selv om resultatet ikke ble som ønsket.

[Steve0]

Til de som skulle fortsatt fulgt med dette topic her, så har jeg tatt opp prosjektet igjen. Fikk plutselig masse ledig tid i juleferien 

 

Utgangspunktet mitt er at jeg lager en adapter som 'snakker' Z-Wave. Måleren min henger utenfor huset, fritt tilgjengelig, og fra et sikkerhetsperspektiv liker jeg ikke særlig å ha dingser hengende ute som inneholder adgangskoder til mitt wifi-nett. Jeg har en del Z-Wave i huset fra før av, dermed prøver jeg meg på det istedenfor å skaffe enda et nettverk (Zigbee) og kjøpe Develco sin dongle (dog, det hadde sikkert spart en del tid det).

 

En annen fordel med Z-Wave er at den bruker såpass lite strøm, at selv Kamstrup-målere burde være fornøyde med mating over m-bus, og det helt uten bufferkondensator. Jeg har målt maks strømtrekk til ca 14mA på 3V3, som er 46mW. Kontinuerlig/gjennomsnitt ligger på ca. 10mA. Kamstrup sin grense ligger på 6mA * 24V = 144mW. Så det er fortsatt veldig mye å gå på, såfremt spenningen forsynes av en DCDC og ikke bare LDO'es ned.

 

Status etter snaue to dager er at jeg har Z-Wave biten fungerende, samt en ren C parser som klarer å hente ut måleverdier fra data som jeg mater inn manuelt over seriellporten (tatt fra litt diverse kilder rundomkring). Det er så langt jeg kommer i prototypingen uten å starte å snekre sammen litt hardware.

 

Tenkte å sette i gang med det snart og ta utgangspunkt i designet som tidligere ble lagt ut her. Unless you still have a spare PCB somewhere for me to prototype on, @spenceme?

[Moskus]

7 timer siden, Steve0 skrev:

Utgangspunktet mitt er at jeg lager en adapter som 'snakker' Z-Wave.

Åh, dette hadde vært fantastisk!  

[stigvi]

18 minutter siden, Moskus skrev:

Åh, dette hadde vært fantastisk!

Er det egentlig det? Da må zwave nettet hvert 2,5 sekund overføre en datapakke. Hva slags konsekvens har det for zwave nettet? Vil det påvirke andre enheter på nettet. Zwave og zigbee er jo definitivt ikke lagd for store datamengder. Men hva er mye? Er det som HAN porten leverer, mye?

Endret 23. desember 2020 av stigvi

[Steve0]

20 minutes ago, stigvi said:

Hva slags konsekvens har det for zwave nettet? 

Only one way to find out :)

 

Det blir jo definitivt konfigurerbart rapport-interval, for folk har forskjellige forventninger om hvor kjappe oppdateringer man skal få. Ikke alle målere klarer å levere hvert 2.5s heller (Kamstrup rapporterer hvert 10.).

Jeg personlig kunne godt levd med å få minutt-oppløsning istedenfor 24 oppdateringer i minuttet. Og jeg kan godt tenke meg at det er noen som ikke nødvendigvis trenger å spore effekt, men bare logger utviklingen i total levert energi, som uansett ikke oppdateres fra måleren oftere enn 1 gang i timen...

[Steve0]

Da har jeg lært meg KiCAD i samme sleng... Jeg kan egentlig Eagle fra før (er en del år siden, gitt), men de har tydeligvis gått over til betalende lisenser siden Autodesk-oppkjøpet. Anyway, PCB'en er designet og jeg satser på å sette den i bestilling ila morgendagen. De feirer vel ikke jul i Kina, så tipper jeg får dem levert rett over nyåret

 

Har prøvd meg på å legge til en 'billigere' variant av HAN-signal-konvertering. Siden 3V3 uansett trenges til SoC'en, og HAN signalene er 24V i idle og spenningen faller når data kommer på bus, burde det gå an å bare ha en opamp-comparator med spenningsdeler og fast referansepunkt. Når jeg setter en deler på 1/12, og legger referansepunktet på 1.7V, så burde den detektere alt der bus'en er idle i 21V~36V området, og bitsene sendes i 10V~19V området. Siden referansen er en vanlig spenningsdeler, er det lett gjort å endre på den om det trenges.

 

Og for å unngå at jeg må kaste PCB'ene i tilfellet det ikke skulle funke, har jeg tatt med den kjente transceiveren også. Velger input til SoC'en med en enkel loddebro

[Moskus]

På 23.12.2020 den 9.19, stigvi skrev:

Er det egentlig det? Da må zwave nettet hvert 2,5 sekund overføre en datapakke.

Man må ikke legge det opp slik, hvis man ikke vil.  Bare fordi man får data hvert 2.5 sekund betyr ikke at man må bruke det.

 

Man kan sette opp litt logikk som kjører litt stastistikk og sender data f.eks. hvert minutt eller noe slikt, med mindre endringen er så og så stor.

 

Tidligere bruke jeg "The OWL" for å lese ut strømforbruket i huset. I begynnelsen fikk vi data annenhvert minutt, og selv det var tilstrekkkelig. En firmware-oppdatering gav nye data hvert 30. sekund og logikken blir ikke nevneverdig på virket av det.

 

 

[Steve0]

4 hours ago, Moskus said:

En firmware-oppdatering gav nye data hvert 30. sekund og logikken blir ikke nevneverdig på virket av det.

 

Akkurat. Den eneste grunnen jeg kjenner til for å få såpass hyppige oppdateringer er når man skal drive med aktiv last-balansering. F.eks. redusere elbilladestrøm når panna slår seg på for å unngå at hovedsikringen ryker.

 

Men det blir fort en komplisert ting å få til for en gjennomsnitts smarthus-entusiast, samt at de fleste elbilladere jeg kjenner til som støtter ekstern signal for å redusere ladestrømmen har sine egne løsninger for dette.

 

Og på toppen av det hele, tåler hovedsikringen (og sløyfesikringene) jo en kortvarig overbelastning. Tar man utgangspunkt i en B-kurve, så kan den overbelastes med 1.5 ganger nominell strøm i 3-5 minutter før den slår ut. Så selv da holder det så absolutt med oppdateringer i minutt eller 2 minutters oppløsning.

[Moskus]

14 timer siden, Steve0 skrev:

Den eneste grunnen jeg kjenner til for å få såpass hyppige oppdateringer er når man skal drive med aktiv last-balansering. F.eks. redusere elbilladestrøm når panna slår seg på for å unngå at hovedsikringen ryker.

... og selv det kan man komme rundt med å sende oppdatering likevel hvis endringen er større enn X%. 

 

Men som du sier, sannsynligvis noe overkill i de fleste tilfeller. Hvis man må drive aktiv belastningsvurdering for å unngå at hovedsikringen ryker, så har man  sannsynligvis større problemer...

[stigvi]

1 time siden, Moskus skrev:

Hvis man må drive aktiv belastningsvurdering for å unngå at hovedsikringen ryker, så har man  sannsynligvis større problemer...

Eller effekttariff. Men det ser jo ut til å bli et lite mindretall i Norge.

[Steve0]

13 minutes ago, stigvi said:

Eller effekttariff. Men det ser jo ut til å bli et lite mindretall i Norge.

 

Gjenstår å se hva som teller som 'effekttopp' i måleren. Om effekttariffen blir avregnet på punktlast i sekundet blir det jo nesten umulig å få feedback-loopen raskt nok til å unngå toppene basert på HAN data.

 

Dersom den derimot blir beregnet etter et større gjennomsnittsvindu finnes det kanskje muligheter...

 

Om man virkelig vil skal det jo være mulig å rapportere like raskt som måleren i et Z-Wave nett... Men da må man kunne tåle litt forsinkelse i andre operasjoner på nettet  Båndbredden i Z-Wave er på 100kbit/s s lenge man ikke har noen elgamle noder, og en kjapp målerpakke med effektrapport ligger på 10 bytes (som så riktignok skal encapsuleres i MAC/PHY), men et konservativ anslag er da at man kan få ca. 500 pakker gjennom luften i sekundet. En sånn pakke skal bekreftes, så da blir det 250. Og om nettverket ditt trenger flere 'hops' mellom måleren og hub'en, skal man dele 250 tilsvarende.

 

Usannsynlig at det da i praksis blir noe stort problem, bortsett fra når man har veldig mange noder i nettet, eller har fryktelig mange hops   (Eller driver å saturere nettet ellers ved å 'polle' andre noder med hub-logikk...)

Endret 27. desember 2020 av Steve0