cpu22

Aidon format Jeg har sjekket Aidon formatet litt, og funnet ut følgende: Meldingene er 100 byte lang Meldingene kommer med 60 sekunders mellomrom Hos meg kommer det en byte ekstra hver gang verdien 0xdb forekommer i meldingen. Når dette skjer, fjerner jeg byten etter 0xdb. CRC16 koden stemmer på alle meldingene når jeg regner over de 97 første bytene, og fjerner evt. ekstra byte etter 0xdb. Alle måleverdier sendes med minst signifikante byte først. Byte 0-15 er målernummer, stemmer med det som står trykt på måleren Byte 16-19 er akkumulert forbruk, samme som måleren viser. Forskjellen er at byte 16-19 viser Wh, altså 1000 ganger høyere oppløsning enn det som kan avleses visuelt. Byte 48-51 ser ut til å være øyeblikksbelastning, oppgitt i Watt. Byte 64-65 ser ut til å være strøm på fase 1 oppgitt i mA, men det er en offset som gjør at måleverdien blir alt for stor. Byte 70-71 ser ut til å være strøm på fase 2 oppgitt i mA. Byte 78-79 ser ut til å være strøm på fase 3 oppgitt i mA. Byte 82-83 er spenning på fase 1 (oppløsning på 100mV, så den må deles på 10). Byte 84-85 er spenning på fase 2 (oppløsning på 100mV, så den må deles på 10). Byte 86-87 er spenning på fase 3 (oppløsning på 100mV, så den må deles på 10). Byte 94-95 er frekvens (oppløsning på 0.01Hz, så den må deles på 100) Byte 96 er alltid 0x03 Byte 97-98 er CRC16 checksum Byte 99 er alltid 0xc0 Det er i tillegg 7 andre data-felter som jeg ikke har funnet ut av. Noen av måleverdiene er litt basert på synsing og gjetninger. Andre er greie å verifisere. Vellkommen til å komme med tilføyninger og korrigeringer.

Jeg har nå hentet ut data fra Aidon-måleren, og formatet er ganske forskjellig fra Kamstrup-måleren som jeg også har lest data fra. Er det noen her som kjenner Aidon-formatet? Det er ingen 0x7e start-byte eller stopp-byte. Og heller ingen OBIS-koder. De første 16 byte stemmer med målernummeret. Jeg leser 101 bytes med en baud rate på 9600, og en frekvens på en melding i minuttet. Her er noen samples: 101 bytes read 0: 0x37 0x33 0x35 0x39 0x39 0x39 0x32 0x38 0x39 0x32 0x30 0x37 0x37 0x34 0x37 0x30 16: 0x8f 0x1a 0x43 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 32: 0x19 0xbe 0x03 0x00 0x00 0x00 0x00 0x00 0x5a 0xdb 0xdc 0x02 0x00 0x00 0x00 0x00 48: 0x00 0xe5 0x07 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x42 0x00 0x00 64: 0x00 0x24 0x81 0x00 0x00 0xa8 0x12 0x5a 0x05 0x00 0x00 0x00 0x00 0x00 0x00 0x8b 80: 0x02 0x00 0x00 0xf2 0x08 0xf2 0x08 0x27 0x09 0x45 0x00 0x00 0x00 0x29 0x00 0x84 96: 0x13 0x03 0x75 0xe3 0xc0 101 bytes read 0: 0x37 0x33 0x35 0x39 0x39 0x39 0x32 0x38 0x39 0x32 0x30 0x37 0x37 0x34 0x37 0x30 16: 0xb1 0x1a 0x43 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 32: 0x19 0xbe 0x03 0x00 0x00 0x00 0x00 0x00 0x5b 0xdb 0xdc 0x02 0x00 0x00 0x00 0x00 48: 0x00 0xdf 0x07 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x41 0x00 0x00 64: 0x00 0x34 0x81 0x00 0x00 0xb7 0x12 0x52 0x05 0x00 0x00 0x00 0x00 0x00 0x00 0x8d 80: 0x02 0x00 0x00 0xfa 0x08 0xfb 0x08 0x2a 0x09 0x44 0x00 0x00 0x00 0x29 0x00 0x84 96: 0x13 0x03 0x02 0x61 0xc0 101 bytes read 0: 0x37 0x33 0x35 0x39 0x39 0x39 0x32 0x38 0x39 0x32 0x30 0x37 0x37 0x34 0x37 0x30 16: 0xd2 0x1a 0x43 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 32: 0x19 0xbe 0x03 0x00 0x00 0x00 0x00 0x00 0x5c 0xdb 0xdc 0x02 0x00 0x00 0x00 0x00 48: 0x00 0xe4 0x07 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x43 0x00 0x00 64: 0x00 0x2c 0x81 0x00 0x00 0x97 0x12 0x59 0x05 0x00 0x00 0x00 0x00 0x00 0x00 0x8b 80: 0x02 0x00 0x00 0xf0 0x08 0xf7 0x08 0x29 0x09 0x45 0x00 0x00 0x00 0x29 0x00 0x87 96: 0x13 0x03 0xeb 0xb7 0xc0 101 bytes read 0: 0x37 0x33 0x35 0x39 0x39 0x39 0x32 0x38 0x39 0x32 0x30 0x37 0x37 0x34 0x37 0x30 16: 0xf4 0x1a 0x43 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 32: 0x19 0xbe 0x03 0x00 0x00 0x00 0x00 0x00 0x5e 0xdb 0xdc 0x02 0x00 0x00 0x00 0x00 48: 0x00 0xec 0x07 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x41 0x00 0x00 64: 0x00 0x48 0x81 0x00 0x00 0xb3 0x12 0x55 0x05 0x00 0x00 0x00 0x00 0x00 0x00 0x8d 80: 0x02 0x00 0x00 0xf8 0x08 0xfd 0x08 0x28 0x09 0x45 0x00 0x00 0x00 0x29 0x00 0x87 96: 0x13 0x03 0x40 0xb7 0xc0 101 bytes read 0: 0x37 0x33 0x35 0x39 0x39 0x39 0x32 0x38 0x39 0x32 0x30 0x37 0x37 0x34 0x37 0x30 16: 0x16 0x1b 0x43 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 32: 0x19 0xbe 0x03 0x00 0x00 0x00 0x00 0x00 0x5f 0xdb 0xdc 0x02 0x00 0x00 0x00 0x00 48: 0x00 0xeb 0x07 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x45 0x00 0x00 64: 0x00 0x1d 0x81 0x00 0x00 0xa7 0x12 0x5d 0x05 0x00 0x00 0x00 0x00 0x00 0x00 0x8d 80: 0x02 0x00 0x00 0xf5 0x08 0xf8 0x08 0x29 0x09 0x45 0x00 0x00 0x00 0x29 0x00 0x88 96: 0x13 0x03 0x54 0x4f 0xc0 Edit: Jeg ser nå at andre her har dekodet deler av meldingen. Jeg skal sjekke om det stemmer med mine meldinger.

Jøss, kjører du hele dekodingen i ESP8266? Selv tenkte jeg å sende de mottatte dataene (alle 228 bytene inkludert 0x7e i begge ender) rått på MQTT, og la abonnenten gjøre jobben med dekodingen. Abonnenten blir etter hvert openHAB, men jeg har ikke kommet til det ennå. Jeg tenkte at det da blir lettere å endre koden senere dersom det blir endringer i protokollen, og også lettere å debugge når det meste av koden ikke kjører på ESP8266. Men siden du kjørerer alt dette i ESP8266, har du sjekket at det er nok plass til både program, stack og heap. Kanskje du er på grensen, og derfor får problemer. En "long shot", kanskje.

Det kan være flere gunner til at watchdog timeren (WDT) trigger, men den aller vanligste er at programmet kræsjer av en eller annen grunn slik at ting stopper opp. "Long loops" kan selvfølgelig være en årsak. Det kan være verdt å sjekke om det brukes noen blokkerende kall for å vente på f.eks. serie-linjen eller annen input. Det er ikke like sannsynlig at du har for lite power supply, spesielt hvis ting har virket fint lenge. 12V 2A høres allerede nok ut, men uansett om du bruker 2A eller 3A, er det regulatoren til 3.3V som evt. begrenser strømmen til ESP8266. Men som sagt, sjekk SW feil først. Adressering utenfor gyldig område, null-pekere, overskrivninger og slikt.

Ja, det ser ut som mange ting falt på plass nå. Fjerningen av 0x09 foran tidskoden og endringen av stringene fra 0xd til 0xa gjorde at boken (Kamstrup HAN-NVE interface description rev 3.0) stemmer bedre. De dubliserte 0xff ene ble borte og det er slutt på at det manglet en byte innimellom. Og når CRC-koden stemmer, er det mulig å verifisere at jeg får feilfrie data. Det er jo lettvint å skylde på firmware-oppgradering (spesielt siden jeg ikke har endret noe i mellomtiden), men jeg skal ikke utelukke at det kan ha vært noe feil her. Nå er det faktisk CRC-feil innimellom, og det er egenlig litt rart med 2400 baud, og 3-4 meter kabel. Ofte i to påfølgende sendinger. Jeg er fristet til å skylde på Kamstrup igjen.

228 bytes read, 0 skipped 0: 0x7e 0xa0 0xe2 0x2b 0x21 0x13 0x23 0x9a 0xe6 0xe7 0x00 0x0f 0x00 0x00 0x00 0x00 16: 0x0c 0x07 0xe2 0x03 0x05 0x01 0x12 0x06 0x14 0xff 0x80 0x00 0x00 0x02 0x19 0x0a 32: 0x0e 0x4b 0x61 0x6d 0x73 0x74 0x72 0x75 0x70 0x5f 0x56 0x30 0x30 0x30 0x31 0x09 48: 0x06 0x01 0x01 0x00 0x00 0x05 0xff 0x0a 0x10 0x35 0x37 0x30 0x36 0x35 0x36 0x37 64: 0x32 0x37 0x30 0x30 0x38 0x33 0x35 0x35 0x30 0x09 0x06 0x01 0x01 0x60 0x01 0x01 80: 0xff 0x0a 0x12 0x36 0x38 0x34 0x31 0x31 0x32 0x31 0x42 0x4e 0x32 0x34 0x33 0x31 96: 0x30 0x31 0x30 0x34 0x30 0x09 0x06 0x01 0x01 0x01 0x07 0x00 0xff 0x06 0x00 0x00 112: 0x18 0x4a 0x09 0x06 0x01 0x01 0x02 0x07 0x00 0xff 0x06 0x00 0x00 0x00 0x00 0x09 128: 0x06 0x01 0x01 0x03 0x07 0x00 0xff 0x06 0x00 0x00 0x00 0x00 0x09 0x06 0x01 0x01 144: 0x04 0x07 0x00 0xff 0x06 0x00 0x00 0x00 0xdb 0x09 0x06 0x01 0x01 0x1f 0x07 0x00 160: 0xff 0x06 0x00 0x00 0x05 0xea 0x09 0x06 0x01 0x01 0x33 0x07 0x00 0xff 0x06 0x00 176: 0x00 0x06 0x76 0x09 0x06 0x01 0x01 0x47 0x07 0x00 0xff 0x06 0x00 0x00 0x05 0xb4 192: 0x09 0x06 0x01 0x01 0x20 0x07 0x00 0xff 0x12 0x00 0xe9 0x09 0x06 0x01 0x01 0x34 208: 0x07 0x00 0xff 0x12 0x00 0xe9 0x09 0x06 0x01 0x01 0x48 0x07 0x00 0xff 0x12 0x00 224: 0xe9 0x71 0xb8 0x7e Ja, det er første etter 0x02 0x19. Se listen over. Men alle text strengene har nå kode 0xa i stedet for 0xd som før oppdateringen. Jeg hadde tenkt å spørre hvordan dere fikk crc-koden til å stemme, men nå trenger jeg ikke det lenger.

Det ser ut til å være flere endringer enn headeren til tidskoden. Headeren til teksten "Kamstrup ..." osv. er endret fra 0x0a 0x0e til 0x0d 0x0e, det 0x0e er lengden i begge tilfellene. To positive ting er: 1) CRC koden stemmer nå, så den kan brukes til feilsjekk. 2) De dupliserte 0xff'ene som jeg trodde var "min skyld" er borte. Jeg har ikke gått gjennom hele meldingen ennå, så det kan være flere endringer.

Jeg sjekket min nå i ettermiddag. Fortsatt 24V / 18V ut.

Jeg kjøper gjerne ett av deg. Eller to hvis du ikke blir kvitt dem.

Okei, jeg skrev koden selv for å dekode alle bytene fra måleren. Jeg regner med at feilen har å gjøre med enten FTDI eller oppsett av serieporten på PCen. Uansett, så har jeg tenkt å la en ESP8266 gjøre jobben med å lese inn bytene etterhvert, så jeg hadde ikke tenkt å lete etter feilen nå. Det er kanskje litt off-topic, men hvordan får dere data videre fra ESP8266 og til controlleren (f.eks. til openHAB)? Bruker dere vanlig sockets, eller en protokoll oppå TCP/IP? Det er vel begrenset hva ESP8266 støtter av kommunikasjon? Jeg fant forresten ut at det var overraskende mange måter å programmere ESP8266 på: LUA, Arudrino IDE og gnu toolchain. Jeg har såvidt testet disse 3, bare for å se om det virket. Og det gjorde det. Hva er det folket her bruker?

Håper du har rett, med du ser at du har PWR_FLAG to steder? Sjekk side 10 i databladet. Hvis man bruker "eksternt" power, så må pin 9 og 11 splittes, og pin 9 skal evt. koples til power. Pin 11 kommer fra den interne spenningsregulatoren. Håper jeg ikke blir for pirkete, jeg vil jo ikke påvirke designet ditt i feil retning heller.

Oops, nå er pin 11 koplet til PWR_FLAG. Det var sikkert ikke meningen. Jeg foreslår å kople pin 9 til PWR_FLAG (med avkopling), og så kople pin 11 til egen avkopling og load på f.eks. 100k.

Ja dette er en av tingene man kan ta høyde for. På AliExpress-kortet er det lagt inn en jumper mellom pin 9 og 11. Vet ikke det med optokopler. Det "føles" sikrere å skille HAN-modulen fra resten. Jeg tenkte egentlig som beskyttelse av HAN-modulen hvis man blingser på noe under testingen.

Flotte greier. Jeg har noen kommentarer: Det mangler 2x seriemotstander på M-bus, 220R. De er med i databladet, og de designene jeg har sett. Hva med å kople til pin 12 (RX) på TSS721A også? Noen nevnte at de ønsket å sende på M-bus også. Hva med å legge inn to opto-koplere i tillegg? Tar jo litt plass da, men det blir litt sikrere. Det må jo likevel være power til ESP8266. Jeg har ikke brukt FET-transistoren, funker like bra uten. Men databladet anbefaler den. Jeg ser at den ikke er med på AliEkspress-kortet. Komponent-verdiene kan jo bestemmes senere, men jeg har brukt disse verdiene: Jeg har brukt en R1 på 30k (ihht. til databladet). Jeg har brukt en R2 på 330R. Jeg har brukt en C2 på 220nF Jeg har oså brukt en Rload på 100k mellom pin 11 og GND, men jeg ser nå at den er nødvendig bare dersom pin 9 og 11 ikke koples sammen. Det ser ikke ut som verdiene er kritisk. Jeg la ut et bilde av output på TSS721A tidligere i tråden. Har du målt med oscilloscop? Jeg er litt spent på om den transistoren påvirker signalet. Jeg syntes dette var bra jobbet.

Jeg hentet teksten fra NVE sitt skriv, ""ULN1 Phase voltage 4W meter, Line voltage 3W meter". Jeg er nok ikke helt fortrolig med disse begrepene, så jeg blandet litt. Takker for korrigeringen. Da blir det "UL12 Line voltage" (og UL23 og UL13).

Nei, jeg har vanlig 3-fase uten nøytral leder. Høres interessant ut med flere parametre, kanskje jordstrøm og frekvens (50 Hz) kunne være noe. Ellers kommer jeg ikke på noe mer. Jo, temperatur og fuktighet. Så kan man få en "early warning" før det begynner å brenne i sikrings-skapet.

Jeg har koplet den til en PC med FTDI, og lagde et program for å tolke OBIS-kodene. Det ble seende slik ut da: 229 bytes read, 13 skipped 0: 0x7e 0xa0 0xe3 0x2b 0x21 0x13 0x98 0x86 0xe6 0xe7 0x00 0x0f 0x00 0x00 0x00 0x00 16: 0x09 0x0c 0x07 0xe2 0x02 0x19 0x07 0x14 0x36 0x1e 0xff 0x80 0x00 0x00 0x02 0x19 32: 0x0d 0x0e 0x4b 0x61 0x6d 0x73 0x74 0x72 0x75 0x70 0x5f 0x56 0x30 0x30 0x30 0x31 48: 0x09 0x06 0x01 0x01 0x00 0x00 0x05 0xff 0x0d 0x10 0x35 0x37 0x30 0x36 0x35 0x36 64: 0x37 0x32 0x37 0x30 0x30 0x38 0x33 0x35 0x35 0x30 0x09 0x06 0x01 0x01 0x60 0x01 80: 0x01 0xff 0x0d 0x12 0x36 0x38 0x34 0x31 0x31 0x32 0x31 0x42 0x4e 0x32 0x34 0x33 96: 0x31 0x30 0x31 0x30 0x34 0x30 0x09 0x06 0x01 0x01 0x01 0x07 0x00 0xff 0x06 0x00 112: 0x00 0x14 0xee 0x09 0x06 0x01 0x01 0x02 0x07 0x00 0xff 0x06 0x00 0x00 0x00 0x00 128: 0x09 0x06 0x01 0x01 0x03 0x07 0x00 0xff 0x06 0x00 0x00 0x00 0x00 0x09 0x06 0x01 144: 0x01 0x04 0x07 0x00 0xff 0x06 0x00 0x00 0x02 0x02 0x09 0x06 0x01 0x01 0x1f 0x07 160: 0x00 0xff 0x06 0x00 0x00 0x04 0x23 0x09 0x06 0x01 0x01 0x33 0x07 0x00 0xff 0x06 176: 0x00 0x00 0x05 0x39 0x09 0x06 0x01 0x01 0x47 0x07 0x00 0xff 0x06 0x00 0x00 0x07 192: 0x16 0x09 0x06 0x01 0x01 0x20 0x07 0x00 0xff 0x12 0x00 0xea 0x09 0x06 0x01 0x01 208: 0x34 0x07 0x00 0xff 0x12 0x00 0xe8 0x09 0x06 0x01 0x01 0x48 0x07 0x00 0xff 0x12 224: 0x00 0xe8 0xa1 0x14 0x7e 2018-02-25 sun 20:54:30 (255.128.0.0) List number 1 (10 sec) Kamstrup_V0001 Meter ID: 5706567270083550 Meter type: 6841121BN243101040 Active power+: 5358 W Active power-: 0 W Reactive power+: 0 VAr Reactive power-: 514 VAr Current phase L1: 10.59 A Current phase L2: 13.37 A Current phase L3: 18.14 A ULN1 line voltage: 234 V ULN2 line voltage: 232 V ULN3 line voltage: 232 V crc=0xa114 Jeg har et par problemer med kommunikasjonen. 0xff bytene blir konsekvent duplisert, så jeg måtte ta høyde for det i programmet og fjerne dublettene. Dessuten mister jeg en byte i ny og ne, slik at det kommer bare 228 bytes. Det blir bare tull i dekodingen da.

Såvidt jeg har sett, er det 4 ønsker som går igjen her: 1) Lese data fra M-bus (åpenbart) 2) Skrive data til M-bus 3) Galvanisk isolasjon 4) Data til ESP8266 Den mest kompakte løsningen til nå, er kortet som @roarfred har lagd, den tilbyr 1) og 4), og har det som trengs for å lese data fra strømmålerne. Selv syntes jeg det er greit med det kortet fra AliExpress som det er bilde av over her. Det gir 1) og 2) og galvanisk skille (pkt. 3), men har ikke prosessor ombord, så det blir to kort. Jeg vet ikke hvilke andre to potensielle løsninger du nevner. Hvis du skal sende på M-bus også, er jo TSS721A et perfekt valg. Den implementerer M-bus protokollen i en chip, og sparer deg for masse arbeid i forhold til å designe noe selv. Så jeg syntes det optimale må være et kort med TSS721A, optokoplere og ESP8266. Men jeg har ikke sett noe slikt ennå.

Denne var jo veldig kompakt, og har alt som trengs. Hvor fant du den?

Noen andre her foreslo å montere en stikkontakt ved siden av sikringene. Da kan du ta signalet inn på en ESP8266, som sender på WiFi inn i leiligheten. Så plugger du en 220V~ til 3.3V= inn i stikkontakten til å forsyne ESP8266 og optokopleren på TSS721A-kortet med strøm.

WTF, en av optokoplerne er montert feil vei på mitt kort, og det er selvfølgelig TX, som jeg skal bruke. Jeg sjekket databladet, og fant ut at noe ikke stemte. Dessuten er de montert samme vei på bildet hos Aliexpress. På mitt kort er TX snudd 180 grader. Så det stemmer ikke at man slipper å lodde. ?

Jeg kan ha misforstått noe, men poenget med galvanisk skille er at de to sidene hverken har felles jord eller felles strømforsyning. En strømforsyning må man uansett ha, for HAN-porten har ikke strøm nok til å drive prosessoren som skal motta dataene etter hvert. Nei, jeg har ikke byttet ledningene fra måleren, TSS721A har en intern bridge, så den skal virke begge veier. Dessuten så ser det bra ut på inngangen til opto-kopleren. Men jeg må nok prøve litt med og uten jumper og eksternt suply. Synd at de ikke leverer med skjema.

Jeg har ennå ikke koplet signalet til en prosessor, tenkte å bruke ESP8266 etter hvert. Ja, jeg kan godt poste skjema her, det er som i databladet, men jeg måtte finne noen av komponent-verdiene selv. Må bare tegne litt først.

TSS721A (forts) Pakke fra Aliexpress i dag, perfekt timing. Jeg prøvde dette kortet, men desverre virket det ikke helt som forventet. Ingen skjema, ingen bruksanvisning, så det blir litt gjetting. HAN-porten koples til i den ene enden, og det var en kraftig rød LED som lyste opp når den ble koplet til. Siden det er et galvanisk skille med optokopler, så koplet jeg til 5V i den andre enden (mellom GND og VIN). Da lyste en annen kraftig rød LED opp. Men det var intet signal å se på utgangen (TxD). RxD skal ikke brukes, siden HAN-porten ikke skal motta noe signal. Jeg målte på inngangen til optokopleren, og der så det helt fint ut, det "svingte" som bare det. Det tyder på at det er et eller annet med optokopleren som ikke virker, eller som jeg ikke har skjønt. Vanskelig å feilsøke uten skjema, men det lar seg gjøre å tegne et. Det blir litt jobb. Nødløsningen blir å bypasse optokopleren, men da er det ikke lenger noe galvanisk skille. Er det noen andre her som har prøvd dette kortet?

TSS721A Jeg har omsider prøvd å kople til HAN-porten med en Texas TSS721A. Det går helt fint, bare man husker å kople til pin 15 (GND). Det hadde jeg glemt, så jeg startet på nytt noen dager senere og oppdaget det da jeg hadde klippet av de fleste komponentene som lot seg gjenbruke (brukte loddebolt første gang). En annen lærdom var at kraftselskapet ikke nødvendigvis har åpnet HAN-porten selv om de sier det. Dette forsinket prosjektet med nesten 3 måneder. Porten skulle vært åpnet i midten av november, men jeg fikk ikke signal før uti februar. Nå skal det sies at de trodde selv at porten var åpnet, de sendte til og med en ny HAN-modul i tilfelle det var feil med den. Så nå virker det heldigvis. Se vedlagte bilder. HAN-porten er koplet på ledningen nærmest kamera, og oscilloscopet er koplet direkte på pinne 15 (GND) og 8 (TX) på TSS721A. På skopet ser vi tydlig at meldingen begynner med 0x7e: start bit 0, 01111110, stop bit 1, totalt 10 bits mellom markørene. Jeg har også utelatt FET-transistoren som databladet anbefaler. Den står klar oppe til venstre i bildet, ikke tilkoplet. For å slippe "luft-koplinger", har jeg gjort som @petersv og bestilt et ferdig kort fra aliexpress. @roarfred og @Tubez har også vært med og diskutert TSS721A tidligere.