tronde Skrevet 16. oktober 2019 Skrevet 16. oktober 2019 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/ Siter
DeVille Skrevet 16. oktober 2019 Skrevet 16. oktober 2019 spenceme skrev (På 16.10.2019 den 18.56): 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? Ekspander 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. Siter
ArnieO Skrevet 17. oktober 2019 Forfatter Skrevet 17. oktober 2019 tronde skrev (På 16.10.2019 den 15.14): Yes, but not caused by lack of constant current draw as specified in the standard for a "normal" slave. Ekspander 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. Siter
tronde Skrevet 17. oktober 2019 Skrevet 17. oktober 2019 ArnieO skrev (På 17.10.2019 den 6.51): 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. Ekspander 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 Siter
ArnieO Skrevet 17. oktober 2019 Forfatter Skrevet 17. oktober 2019 tronde skrev (På 17.10.2019 den 15.24): 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 Ekspander 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. Siter
tronde Skrevet 17. oktober 2019 Skrevet 17. oktober 2019 (endret) 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. Siter
spenceme Skrevet 17. oktober 2019 Skrevet 17. oktober 2019 tronde skrev (På 17.10.2019 den 20.36): 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. Ekspander 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. Siter
tronde Skrevet 17. oktober 2019 Skrevet 17. oktober 2019 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. Siter
nicbra Skrevet 17. oktober 2019 Skrevet 17. oktober 2019 ArnieO skrev (På 17.10.2019 den 6.51): Do you (or someone else here) have access to EN 13757-2? Ekspander Værsågod: https://drive.google.com/file/d/10_0Aciq4mqrvXClLzhA6IP_-INAlRbC4/view?usp=sharing 1 1 Siter
spenceme Skrevet 17. oktober 2019 Skrevet 17. oktober 2019 tronde skrev (På 17.10.2019 den 21.40): 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. Ekspander Ignoring the initial charge current of the input caps, I see a peak current of ~14ma when the dc-dc is switching at 12v. Siter
tronde Skrevet 17. oktober 2019 Skrevet 17. oktober 2019 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? Siter
tronde Skrevet 18. oktober 2019 Skrevet 18. oktober 2019 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. Siter
spenceme Skrevet 18. oktober 2019 Skrevet 18. oktober 2019 tronde skrev (På 18.10.2019 den 16.06): 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. Ekspander 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. 1 Siter
nicbra Skrevet 28. oktober 2019 Skrevet 28. oktober 2019 Is there a place we can follow your progress, like github? Or do you wait to publish your work when the project is finished? Siter
ArnieO Skrevet 28. oktober 2019 Forfatter Skrevet 28. oktober 2019 nicbra skrev (På 28.10.2019 den 10.13): Is there a place we can follow your progress, like github? Or do you wait to publish your work when the project is finished? Ekspander 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. Siter
spenceme Skrevet 28. oktober 2019 Skrevet 28. oktober 2019 (endret) nicbra skrev (På 28.10.2019 den 10.13): Is there a place we can follow your progress, like github? Or do you wait to publish your work when the project is finished? Ekspander (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 1 Siter
spenceme Skrevet 28. oktober 2019 Skrevet 28. oktober 2019 nicbra skrev (På 28.10.2019 den 10.13): Is there a place we can follow your progress, like github? Or do you wait to publish your work when the project is finished? Ekspander 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. 2 Siter
spenceme Skrevet 28. oktober 2019 Skrevet 28. oktober 2019 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. 1 Siter
tronde Skrevet 28. november 2019 Skrevet 28. november 2019 Har dere sett denne om Kamstrup og strømforsyning? 1 Siter
ArnieO Skrevet 2. desember 2019 Forfatter Skrevet 2. desember 2019 Status tronde skrev (På 28.11.2019 den 16.49): Har dere sett denne om Kamstrup og strømforsyning? Ekspander Jeg så den nettopp, og responderte i tråden. Interessant - men jeg vil gjerne ha mer informasjon før jeg hiver meg på den. Siter
ArnieO Skrevet 2. desember 2019 Forfatter Skrevet 2. desember 2019 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.) Siter
Marius-H Skrevet 2. desember 2019 Skrevet 2. desember 2019 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. Siter
Marius-H Skrevet 2. desember 2019 Skrevet 2. desember 2019 ArnieO skrev (På 2.12.2019 den 8.10): 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.) Ekspander 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. Siter
ArnieO Skrevet 2. desember 2019 Forfatter Skrevet 2. desember 2019 (endret) Marius-H skrev (På 2.12.2019 den 8.20): 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. Ekspander Det der er for Deep sleep. ESPen har tre sleep modes: Modem sleep, ca 15 mA Light sleep, ca 1 mA 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 Siter
Marius-H Skrevet 2. desember 2019 Skrevet 2. desember 2019 ArnieO skrev (På 2.12.2019 den 8.22): Det der er for Deep sleep. ESPen har tre sleep modes: Modem sleep, ca 15 mA Light sleep, ca 1 mA 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. Ekspander Jeg har forøvrig programmert alt i micropython. Siter
Anbefalte innlegg
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.