Ämne: Styra luftluft med egen processor...någon som gjort eller sett??

[Fredrik72]

Hej !

Som hemmapulare med elektronik/processorer som stort intresse så
funderar man ju på hur det skulle vara att styra LLVP pumpen själv.

Någon här som sett projekt där man styrt utedelen genom att kommunicera via pumpens egna gränssnitt??

Sökt en del via google men faktiskt inte hittat någon som hackat sin pump.

Kunde ju vara en kul grej att göra när pumparna har gjort sitt en vacker dag.

Att börja från 0 och koppla in en protocol analysator eller liknande är idag med alla andra projekt man
har för sig inte aktuellt.

Men om någon sett något liknande ute i världen för ni gärna posta länkar.

/Fredrik

[GDS-Jan]

Att styra pumpen är en baggis.
Men att ge sig på att prata protokoll med en LLVP existerar inte.

Vill du styra pumpen så ta över styr och sensorer själv.

[pi.r]

Va..? Är handsken kastad..?  eller vadå..?

Kanske inte riktigt så allvarligt, men jag kan ju inte förneka att jag länge varit sugen att sniffa lite på "pratet" mellan inne- o ute-delen. Eftersom jag redan har kåpan avtagen på min MHI-pump, för ett annat (mer angeläget) projekt: att ta kontrollen över innefläkten, så kunde jag inte låta bli att haka på oscilloskopet på "prat"-tråden för att se hur det ser ut.

... att ge sig på att prata protokoll med en LLVP existerar inte.

Jag vet inte det...
Det ser ut som helt normal serie-kommunikation.

• 300 baud
• 8 bit
• Jämn paritet (Even)
• 1 stopp-bit.

Det ser ut att skickas data i 2 paket, ett åt vardera hållet, med ca 1 sekunds intervall. Det på ena hållet är 10 byte långt, det andra 8 byte. Inte mycket alls alltså, så det är utan tvekan binär-data. När jag tittade på datat en stund, såg vissa bytes ut att ändras ordentligt, medan andra var stabila. Detta utan att förändra driftförhållandena för pumpen.

En "intressant" twist på designen, är att signalnivån i tråden har en ca 8V negativ offset i "viloläget". Sedan går pulserna positivt för datapaketat i ena riktningen, medan dom går negativt för datapaketet i andra riktningen, 8V upp resp. 8V ner. Totalt sving är alltså 16V. När man tittar på kurvan ser det ut som att man dessutom inverterat signalnivåerna mellan paketen i dom två riktningarna. Dvs. en "1" är sannolikt -8V i båda paketen, medan en "0" är 0V i det ena paketet (första i kurvan) och -16V i det andra paketet.

Det här är datat i kurvan nedan (decimalt):
Tx:  153  166    0   40  192   58   16    0    0  113
Rx:   85    0   40    0    1    8   28  162

Kanske... för jag vet ju inte ordningen på msb/lsb, eller vad som är "1" eller "0" signalmässigt. Det finns 4 möjliga tolkningar här.

Så nu är det bara att räkna ut funktionen i varje byte...   

Förslag på parametrar som man kan förvänta sej skickas fram och tillbaka..?

Ska man komma något längre, måste någon bygga en sniffer som kan logga och spara all data som skickas över längre tid. Så man kan spåra avfrostningar, övergång från värme till kyla, olika effekt-uttag, mm.

(Skalorna för kurvan är i enheterna Volt och sekunder)

[patrikbn]

Här får ni ett kretsschema på en Bosch EHP.
Det avser hur kretsen för kommunikation mellan ute och innderdel ser ut.

[patrikbn]

Funktionen är som följer.
Både innerdelen och utedelen håller optokopplare PC853H låg och båda leder då ström.
Som man kan se så sitter en 24V zenerdiod och en serie motstånd från Fasen mot Nollan, detta ger -24V i helt obelastat läge.

Denna spänningen går genom alla optokopplare och det blir då som pi.r visar med sin mätning ca -8V mot Nollan.
Detta är normalläge/ingen data.
Om utedelen skall sända så sätter utedelen PC853H hög(släpper låg signal) och då kommer kretsen brytas med följden att spänningen sjunker (-16V), spänningen ut från innerdelen finns fortfarande.
Om innerdelen skall sända så sätter innerdleen PC853H hög(släpper låg signal) och då kommer spänning ut från innerdelen brytas med följden att spänningen stiger (0V), spänning ut från innerdelen finns inte längre.

[pi.r]

Så om man då antar att MHI o Bosch har samma design, kan man även anta att det första 10-byte-paketet sänds från inne-delen, och det andra 8-byte-paketet kommer från ute-delen. Precis som jag gissat...

patb..! 
Vad fick dej att gräva ner dej i det här..?
Ren nyfikenhet eller problem?

[patrikbn]

Jag har reparerat en Bosch EHP efter att ägaren kopplat in den mot 400VAC.
Dels så hade lite optokopplare i kommunikationskretsen rykt.

Toshiba har lite annorlunda lösning.
Dom använder 50Hz sinuskurvan, innerdelen lägger på den positiva delen mot nollan och utedelen den negativa delen mot nollan. Då är det helt plötsligt full duplex på 1 tråd..

[pi.r]

Så Toshiban snackar med 50 baud då? Men i och med att dom kör duplex, så får man väl säga att det motsvarar 100 baud.

I dina kurvor ser det ut som att dom verkar ha ett helt annat (eget?) koncept i data-protokollet. Dessutom mera "sporadisk" trafik än i min MHI. Men det kanske bara är en effekt av undersampling och/eller låg skärmupplösning. Om jag fattat rätt borde det vara 10 databitar per ruta (horisontalt). Så går nog inte att se.

Dom verkar ha klart lägre tempo i dataöverföringen, eller så har dom ett extremt kompakt dataformat, eller både och.

Jag skulle nog gissa att Bosch & MHI är lättare att "de-chiffrera" än Toshiba - för den som känner sej manad...

[patrikbn]

Ja det verkar som dom kör något egen. Det jag lyckats tolka än så länge är att i båda riktningarna verkar det komma åtta ettor och sedan följer 8 byte. Det är alltid 1280 ms mellan dom här åtta ettorna, det är 20 ms mellan varje byte.
Så med andra ord verkar enheterna sända 255 och sedan riktig data, det kan vara så att 255 är reserverat för en synkpuls och sedan kör man på med 8 byte utan varken start eller stop bit.
Det jag sett är att den verkar stega första byten efter "synkbyten", så frågan är om den inte sänder olika "block".

När pumpen är avslagen på fjärren så är nivån 0 Volt och när jag slog på den så startade innerdelen först och sedan kom det bara 1:or i ena riktningen tills andra änden svarade och det "normala" dataflödet startade.

Skulle jag gissa så är det synkbyte, blocknr, 6 byte med data och crc.

[pi.r]

Hmm... Jag undrar...

Jag har ju bara dina 2 bilder att gå på, men jag får inte riktigt ihop det som du beskriver det.

Till att börja med ser det ut att vara mer än 1280 ms mellan 2 synk-bytes (om vi utgår från att det är sådana). På andra bildens negativa sida, ser det ut att vara 1400 ms (7 rutor). Samma intervall passar även bra på första bildens positiva sida.

Dessutom skulle jag vilja påstå att det i bägge bildernas båda halvor, finns ett tydligt mönster med pulser varje 200 ms, som borde kunna vara start-biten för varje data-byte. Med 20 ms/bit passar det perfekt med 8 bitar data + 1 start- och 1 stopp-bit (ingen paritet). Det syns kanske tydligast i första bildens positiva sida.

I så fall skulle det bli 1 sync-byte och 6 data-bytes i ett "paket". Om dom sedan har en "paket-räknare" i första byten så blir det bara 5 byte data kvar i varje paket. Då kan man nog gissa att dom inte har en check-summa i sista byten. Det blir liksom inte mycke data kvar då... Kanske kan dom kombinera en check-summa med paket-räknaren i samma byte..? Någon form av integritets-check på datat borde dom ha - kan man tycka...

[patrikbn]

Jag lägger upp en bild med 100ms per ruta.
Jag funderar på om den kanske kör 16 bit med start och stop-bit

[pi.r]

Nä nu vart det ju knepigt...

Det är ju både 10 och 11 pulser i "sync-byten". Det borde vara 9 - alltid..!

Om man har start o stopp-bitar så ska dom vara varandras invers. Dvs om start är "1" ska stopp vara "0". Så sync-byten ska föregås av en nolla (föregående stopp-bit) och vara 9 ettor (inkl. en egen start-bit) och en nolla (egen stopp-bit). Sen ska nästa bytes start-bit komma osv. Men det stämmer ju inte alls här. Det kanske stämmer för data-byten som följer, men för att se det måste man "spela in" en längre sekvens med den högre upplösningen.

Samtidigt kan jag fortfarande se vad som ser ut som "start-bits-pulser" var 200:e ms - utan undantag. Men det måste inte vara rätt för det. Kan vara slump, eller nåt annat.

Det slog mej att dom behöver ju inte köra asynkront (som i RS232). Dom kan köra synkront - med 2 tråd - data och klocka. Dom synkar ju med nät-frekvensen..! (klock-tråden är 230V fas). Start- o stopp-bitar behövs inte, och det öppnar ju för ett helt annat format. Men det måste finnas ett system att säkert synka starten på ett datapaket. Att bara skicka 10 ettor i följd räcker antagligen inte, eftersom man kan skicka 2 byte med FF i rad.

16-bits data tror jag är osannolikt - om dom inte kör med en 16-bitars processor... men kanske inte ens då.

[gech]

Hej!
en gammal (god) tråd; synd bara att GDS-jan inte fortsatt på sin trådning;
lite tips om hur / vad man letar efter på styrkortet för att koppla in sig..... har en panasonic utedel från 96
som jag tror är ok, och skulle vilja labba lite med ....

[Daniel Sjöblom]

Extremt intressant tråd, får man till egen styrning av utedel kan man bygga en egen luft/Vatten för en femma och en fimp i princip. Problemet är oftast styrningen.

[purjo__]

Jag skrev ett eget styr till min Bosch/IVT luft/vatten istället för rego 800. Det är inte så jättesvårt om det går att kommunicera med prylarna på ett enkelt sätt (canbus i mitt fall).