Gå til innhold
  • Bli medlem
Støtt hjemmeautomasjon.no!

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


Anbefalte innlegg

1 time siden, spenceme skrev:

Right now it needs testing from people with different meters who are open to a troubleshooting period.  If it gets to the point of plug and play, then I'll let you know.  What type of meter do you have?

 

Great, thanks! I would not mind participating in troubleshooting, if I can be of any help. I have an Aidon at home and a Kamstrup at my cabin. I'll be happy to help troubleshoot with either, although I will have less often access to the one at the cabin.

 

Lenke til kommentar
Del på andre sider

15 hours ago, tronde said:

Yes, but not caused by lack of constant current draw as specified in the standard for a "normal" slave.

Good point!

The spec says "Maximum current to HEMS   6mA    4 unit loads according to EN 13757-2"

Do you (or someone else here) have access to EN 13757-2?

Does specify current draw stability (inrush I assume)?

A copy of the relevant sections would be great.

Lenke til kommentar
Del på andre sider

8 timer siden, ArnieO skrev:

Good point!

The spec says "Maximum current to HEMS   6mA    4 unit loads according to EN 13757-2"

Do you (or someone else here) have access to EN 13757-2?

Does specify current draw stability (inrush I assume)?

A copy of the relevant sections would be great.

Unfortunately no complete standard. It does exist a short preview with some information on the two last pages

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

 

And something from http://www.m-bus.com/mbusdoc/md4.php

Lenke til kommentar
Del på andre sider

39 minutes ago, tronde said:

Unfortunately no complete standard. It does exist a short preview with some information on the two last pages

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

 

And something from http://www.m-bus.com/mbusdoc/md4.php

Thanks!

The first link is new for me, the second link is known and previously read. Nothing helpful here to understand current spike tolerance, as far as I can see. 

Lenke til kommentar
Del på andre sider

Found something interesting in the datasheet for NCN5150 which is a replacement for TSS721A.

 

https://www.onsemi.com/products/connectivity/wired-transceivers-modems/ncn5150

 

It can be programmed to draw up to six unit loads, and feed most of it to the slave's circuitry.

At four unit loads (6 mA) it can feed 5.4 mA. This is only 10% loss. Maybe we only get 4.8 mA, but it is still good.

 

Don't calculate while tired...?

Endret av tronde
Innholdet er feil, og gir ingen nytte.
Lenke til kommentar
Del på andre sider

31 minutes ago, tronde said:

Found something interesting in the datasheet for NCN5150 which is a replacement for TSS721A.

 

https://www.onsemi.com/products/connectivity/wired-transceivers-modems/ncn5150

 

It can be programmed to draw up to six unit loads, and feed most of it to the slave's circuitry.

At four unit loads (6 mA) it can feed 5.4 mA. This is only 10% loss. Maybe we only get 4.8 mA, but it is still good.

 

It is pulling 6ma of current at ~24v, and providing 5.4ma at 3.3v.  That's 12% efficiency.  In contrast,  the buck I'm using can provide ~35ma at 3.3v with the same 6ma input (80% efficiency).  The buck itself runs at 90% efficiency, but the TSS721 consumes ~.6ma.

Lenke til kommentar
Del på andre sider

Yes, of course you are correct. Maybe time for bed...

 

Do you have any idea about how large the current spikes you talk about are? It seem from the available documentation that a slave talking to the host will increase the current by 15 mA. Since Kamstrup says  four slaves at 1.5 mA it should give some 21 mA before the transmitter shuts off for short pulses. I assume only one slave is allowed to talk at the same time.

Lenke til kommentar
Del på andre sider

31 minutes ago, tronde said:

Yes, of course you are correct. Maybe time for bed...

 

Do you have any idea about how large the current spikes you talk about are? It seem from the available documentation that a slave talking to the host will increase the current by 15 mA. Since Kamstrup says  four slaves at 1.5 mA it should give some 21 mA before the transmitter shuts off for short pulses. I assume only one slave is allowed to talk at the same time.

 

Ignoring the initial charge current of the input caps, I see a peak current of ~14ma when the dc-dc is switching at 12v.

 

Lenke til kommentar
Del på andre sider

According to the standard, it seems like a slave can draw up to (4 x 1.5 mA) + 20 mA = 26 mA from the Kamstrup meter. This is the max curent allowed when a slave is transmitting. The time should be max 50 ms.

 

What is the frequency of your peak current?

Lenke til kommentar
Del på andre sider

Have you tried to increase the value of the resistor between pin 4 (RIDD) and ground on the TSS521? This resistor determines the constant current drawn from the meter. We don't need a constant current, and 1.5 mA is signifcant part of the available energy from the Kamstrup meter. The datasheet says RIDD max 80k, but I would try even more and see if the circuit becomes unstable.

Lenke til kommentar
Del på andre sider

2 hours ago, tronde said:

Have you tried to increase the value of the resistor between pin 4 (RIDD) and ground on the TSS521? This resistor determines the constant current drawn from the meter. We don't need a constant current, and 1.5 mA is signifcant part of the available energy from the Kamstrup meter. The datasheet says RIDD max 80k, but I would try even more and see if the circuit becomes unstable.

 

Yes, i'm running 82k, that change alone saves ~0.6ma.  ;)

 

I've made some small changes that look good today with quick testing.  I think the peak current consumption is down to ~6.5ma now.  If we limit the messages sent in the code I believe it should be no problem to go lower too.  I need to verify some of this over the weekend and hopefully get a setup to measure currents with a scope put together...then I can answer some of your more detailed questions.  

 

Regardless, after this weekend I want to test on a kamstrup.  

  • Like 1
Lenke til kommentar
Del på andre sider

  • 2 uker senere...
1 hour ago, nicbra said:

Is there a place we can follow your progress, like github? Or do you wait to publish your work when the project is finished?

Although it was me who started this thread, @spenceme has now taken the lead and made very good progress. He has the latest wiring diagrams etc.

 

I am in the process of assembling a board (PCB kindly provided by  @spenceme ) to test the design on a Kamstrup unit - which seems to be the most demanding one due to its low current output. Current status: Waiting for delivery of Buck converter IC (TLC3642), due to arrive next week (free sample from Analog Devices).

 

The design files are currently held by @spenceme, I expect he'll respond regarding github etc.

Lenke til kommentar
Del på andre sider

5 hours ago, nicbra said:

Is there a place we can follow your progress, like github? Or do you wait to publish your work when the project is finished?

 

(see below for the reply to this)

 

On another note, does anyone with a Kafia meter want to test?  I have a board ready to send out for testing.  The best would be if you have an oscilloscope for debugging if needed.  

Endret av spenceme
Too fast of fingers
  • Like 1
Lenke til kommentar
Del på andre sider

4 hours ago, nicbra said:

Is there a place we can follow your progress, like github? Or do you wait to publish your work when the project is finished?

 

I don't have a github for this.  Perhaps I might here in the coming couple days.  Basically @ArnieO mentioned the current status.  There is not really something secretive...its basically the schematic I've posted up the other week.  My thoughts were to test with @ArnieO and work out some bugs before putting up the design files, maybe it's time to put them up.  

 

@nicbra I know you want one, so just give us a little more time.  :)  I'll build you one here before too long.

  • Like 2
Lenke til kommentar
Del på andre sider

I've forked the gskjold repository and updated the best I could tonight with the latest design and some of my thoughts.  @nicbra, this would be the best place to follow for the latest.  Although all the design details are there, I suggest to wait a little before building much to give us a chance to debug on other meters.  

 

https://github.com/dakarym/AmsToMqttBridge

 

@ArnieO, I updated the sketch on my repository with the sketch I am running today for the changes needed.  I'm not sure if the gskjold fork runs the other Kamstrup and Kafia meters 100%, but it runs the Aidon I have perfectly.  Hopefully it is okay.

 

  • Like 1
Lenke til kommentar
Del på andre sider

  • 5 uker senere...

Status

On 28/11/2019 at 17:49, tronde said:

Har dere sett denne om Kamstrup og strømforsyning?

Jeg så den nettopp, og responderte i tråden. Interessant - men jeg vil gjerne ha mer informasjon før jeg hiver meg på den.

Lenke til kommentar
Del på andre sider

Statusoppdatering

Kortet fungerer som sådan.

 

Firmware er mer krevende, ser ut for å kreve utstrakt bruk av ESPens sleep modes. Det mest aktuelle ser ut for å være "Light sleep", hvor prosessoren stanser - men kan vekkes igjen via en GPIO. Noen melder også at det kan gjøres med timer - men det ser ikke ut for å gjelde alle ESP versjoner, og/eller kanskje versjon av bibliotek for ESPen. "Litt alkymi".

 

Utfordringen: Kortet bruker ca 70 mA mens det er aktivt med WiFi operativ, gjennomsnittlig forbruk må ned på ca 30 mA.

Det springende punktet er rask reconnection til WiFi og MQTT etter en Light sleep (hvor forbruket faller til ca 1 mA).

 

Dersom noen i forumet sitter med god hands-on kompetanse på ESPens sleep modes så skrik ut!

 

(Fremdriften går ellers i rykk og napp basert på tilgjengelig tid.)

Lenke til kommentar
Del på andre sider

Not sure to write in english or norwegian. I've done this already with Kamstrup and the general han standard. Its just alot simpler with the Kamstrup meter because they have direct access to serial data.

 

There is no way of turning on wifi on any esp-device without any form of energy storage. The wifi-check takes just to much power and the meter will drop the voltage when you try to pull more energy than allowed. Kamstrup answered me in an email that they dont recommend pulling over 40ma from the VCC pin.

 

There is already a module you can buy on the market if you have the Kamstrup-meter. But its pretty expensive. https://web.smart-me.com/en/project/kamstrup-module/

 

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.

Lenke til kommentar
Del på andre sider

7 minutter siden, ArnieO skrev:

Statusoppdatering

Kortet fungerer som sådan.

 

Firmware er mer krevende, ser ut for å kreve utstrakt bruk av ESPens sleep modes. Det mest aktuelle ser ut for å være "Light sleep", hvor prosessoren stanser - men kan vekkes igjen via en GPIO. Noen melder også at det kan gjøres med timer - men det ser ikke ut for å gjelde alle ESP versjoner, og/eller kanskje versjon av bibliotek for ESPen. "Litt alkymi".

 

Utfordringen: Kortet bruker ca 70 mA mens det er aktivt med WiFi operativ, gjennomsnittlig forbruk må ned på ca 30 mA.

Det springende punktet er rask reconnection til WiFi og MQTT etter en Light sleep (hvor forbruket faller til ca 1 mA).

 

Dersom noen i forumet sitter med god hands-on kompetanse på ESPens sleep modes så skrik ut!

 

(Fremdriften går ellers i rykk og napp basert på tilgjengelig tid.)

 

Hvis du bruker ESP8266 må du koble sammen GPIO16 og reset. På ESP32 har de allerede gjort det.  Du kan få ESP til å bruke veldig mye mindre strøm ved å klokke ned prosessoren. Men den bruker uansett for mye når man skrur på Wifi.

Lenke til kommentar
Del på andre sider

2 minutes ago, Marius-H said:

 

Hvis du bruker ESP8266 må du koble sammen GPIO16 og reset. På ESP32 har de allerede gjort det.  Du kan få ESP til å bruke veldig mye mindre strøm ved å klokke ned prosessoren. Men den bruker uansett for mye når man skrur på Wifi.

 

Det der er for Deep sleep.

ESPen har tre sleep modes:

  1. Modem sleep, ca 15 mA
  2. Light sleep, ca 1 mA
  3. Deep sleep, µA området - men firmware restarter fra toppen (som full RESET)

 

Det er Light sleep som er mest aktuell å utnytte, sketchen fortsetter da der den sovnet.

Endret av ArnieO
Lenke til kommentar
Del på andre sider

5 minutter siden, ArnieO skrev:

 

Det der er for Deep sleep.

ESPen har tre sleep modes:

  1. Modem sleep, ca 15 mA
  2. Light sleep, ca 1 mA
  3. Deep sleep, µA området - men firmware restarter fra toppen (som full RESET)

 

Det er Light sleep som er mest aktuell å utnytte, sketchen fortsetter da der den sovnet.

Jeg har forøvrig programmert alt i micropython.

Lenke til kommentar
Del på andre sider

Bli med i samtalen

Du kan publisere innhold nå og registrere deg senere. Hvis du har en konto, logg inn nå for å poste med kontoen din.

Gjest
Skriv svar til emnet...

×   Du har limt inn tekst med formatering.   Lim inn uten formatering i stedet

  Du kan kun bruke opp til 75 smilefjes.

×   Lenken din har blitt bygget inn på siden automatisk.   Vis som en ordinær lenke i stedet

×   Tidligere tekst har blitt gjenopprettet.   Tøm tekstverktøy

×   Du kan ikke lime inn bilder direkte. Last opp eller legg inn bilder fra URL.

×
×
  • Opprett ny...

Viktig informasjon

Vi har plassert informasjonskapsler/cookies på din enhet for å gjøre denne siden bedre. Du kan justere dine innstillinger for informasjonskapsler, ellers vil vi anta at dette er ok for deg.