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

[tronde]

Aidon says "If the current is above the 30-mA limit for ~50 µs, the HAN interface is shut down. "

 

https://www.nek.no/info-ams-han-utviklere/

[DeVille]

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.

 

[ArnieO]

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.

[tronde]

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

[ArnieO]

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. 

[tronde]

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 18. oktober 2019 av tronde
Innholdet er feil, og gir ingen nytte.

[spenceme]

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.

[tronde]

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.

[nicbra]

14 timer siden, ArnieO skrev:

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

Værsågod:

 

https://drive.google.com/file/d/10_0Aciq4mqrvXClLzhA6IP_-INAlRbC4/view?usp=sharing

[spenceme]

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.

 

[tronde]

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?

[tronde]

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.

[spenceme]

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.  

[nicbra]

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

[ArnieO]

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.

[spenceme]

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 28. oktober 2019 av spenceme
Too fast of fingers

[spenceme]

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.

[spenceme]

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.

 

[tronde]

Har dere sett denne om Kamstrup og strømforsyning?

 

[ArnieO]

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.

[ArnieO]

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.)

[Marius-H]

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.

[Marius-H]

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.

[ArnieO]

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 2. desember 2019 av ArnieO

[Marius-H]

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.