PC-styrning av Bergvärmepump
Jag har läst litet i databladet på PIC18C601:FredRovers skrev:Alla idéer är välkomna.
Jag håller med, det stämmer bara nästan att de två LSB-erna skuller vara avsändare/mottagare.
http://ww1.microchip.com/downloads/en/D ... 39541a.pdf
Kan det vara så att de använder USART:en i 9-bitars-mode? På något annat ställe på nätet har jag läst att det är vanligt att koppla en master med flera slavar i ett rs485-system via ett 9-bitarsprotokoll där den extra biten talar om huruvida byte:en är en adress eller data (har inte läst in mig på detta ännu så ta det med en nypa salt).
Vad var det du sa tidigare, att de två 485-portarna var paralellkopplade? Det skulle stämma med detta.
Om det nu är så skulle man vilja konfigurera den vanliga serieporten på PC:n att klara 9 bitar. Är det någon som vet om UART:en på en PC klara det?
Jag har läst ur pannans program-minnet till PICen i hopp om att kunna hitta några användbara kommandon i klartext, men hittade tyvärr inga sådana.Det enda jag hittade i klartext är texterna som visas i pannans display.
Är det någon här på forumet som kan tolka den urlästa hex-filen och på så sätt få reda på protokollet och kommandona?
I annat fall så blir det att plocka fram oscilloskopet samt sniffa datan mellan styrkortet och displayen medans man knappar runt i menyerna.
I mitt fall är det en NIBE 360-panna som jag skulle vilja kunna styra via nätet.
Är det någon här på forumet som kan tolka den urlästa hex-filen och på så sätt få reda på protokollet och kommandona?
I annat fall så blir det att plocka fram oscilloskopet samt sniffa datan mellan styrkortet och displayen medans man knappar runt i menyerna.
I mitt fall är det en NIBE 360-panna som jag skulle vilja kunna styra via nätet.
Förklaring till invertering och skiftning?
rs485-nätverket använder ett 9-bitars-protokoll där paritetsbiten används för att signalera något, tex huruvida byten är en kontrollsignal eller data. Kommunikationen är halv duplex. Protokollet innehåller mekanismer för att addressera moduler och att vända på kommunikationsriktningen.FredRovers skrev:6E C6 7E 7E 7E 2A 3A 46 3A 3E C9 F3 E7 E7 E7 E7 32
Inverterat och >> 2 ger följande (om man omvandlar till ASCII om data >= 0x20):
'$'x0E' '' '' ''5''1''.''1''0'x0Dx03x06x06x06x06'3'
51.1 är det som hamnar på displayen.
Är det någon som känner till något system som inverterar och skiftar två steg. Kanske är detta helt egetutvecklat av NIBE???
Förslag på vad de två bitarna som man skiftar bort ska användas till?
Förklaringen till inverteringen, de extra bitarna och de oregelbundna sekvenser associerade med tidvisning på displayen som du rapporterat om i ett annat meddelande kan vara en kombination av följande:
1. Baudrate är 19200, men man ska inte använda 8N1 utan 8 bitar med paritet (som man sedan tolkar om eftersom paritetsbiten också är data).
2. Datasignalen är inverterad, dvs den rs232-rs485-adapter du använder bör invertera RXD-signalen mellan 75176 (eller vilken rs485-IC som nu används) och rs232-gränssnittet, jämfört med hur det nu är gjort.
1 + 2 ovan leder till "framingproblem", dvs din UART skär inte ut de 8 databitarna på rätt ställe. Paritetsbiten bidrar ytterligare till detta problem. Jag föreslår att detta är orsaken till skiftningen.
Pinnar
Jag har inte mätt detta, men kan med säkerhet dra slutsatsen att rs485-nätverket drivs av PIC18C601:s USART, dvs 75176 (bussdrivaren) är kopplad till RC6/TX/CK (pin 31) och RC7/RX/DT (pin 32). Dock är jag osäker på om signalen inverteras innan 75176 eller ej.TomasL skrev:Dock måste man veta hur pic'en är kopplad dvs man måste göra ett schema så man vet vad de olika pinnarna är kopplade.
Min VP er (tror jeg) for praktiske formål en nibe 1130, PIC Prom er merket 1.06 så den bør støtte RCU-10.
Det ser ut til at all tekst på displayet sendes som seriedata fra PIC, dette gir mening da nasjonalisering kun påvirker _en_ PROM. Mulig også derfor den trenger extern prom, det blir kanskje for mye text data å lagre. Ellers er det noen ganger enklere i produksjonen å plugge i en ferdiglaget prom i et ellers ukonfigurert kort en å brenne en uC.
Jeg bruker en ren RS232 converter (MAX203) der jeg lar ene 485 signalet drive logisk signal inn, (RS485 trenger GND i tillegg til de to linjene, linjene er inverterte men referert mot GND) lar RS232 siden gå til PC. Dette gir ikke isolasjon så det er ingenting jeg vil bruke over tid, men jeg hadde det liggende så det var enkelt.
Bruker hyperterminal satt til 19200:
Velger parity space får jeg mye lesbare data, typisk display text med tid, og noen binær data.
Turlednings temp.qpÀã7.0)°C÷Sp2.0
13:46 RpTurlednings temp.qÔp¤pÀã7.0)°C÷Sp2.0 13:46 RpTu
rlednings temp.qÔp¤Ôù kpÀã7.0)°C÷Sp2.0 13:47!RpTurlednings
temp.qÔp¤pÀã7.0)°C÷Sp2.0 13:47!RpTurle
(dette er listet ut med http://www.serial-port-monitor)
6C 65 64 6E 69 6E 67 73 20 74 65 6D 70 2E 00 71 lednings temp..q
06 D4 00 70 00 A4 00 70 03 00 00 C0 E3 37 2E 30 .Ô.p.¤.p...Àã7.0
29 B0 43 00 F7 06 53 00 70 15 32 2E 30 20 20 20 )°C.÷.S.p.2.0
20 20 20 20 20 20 20 20 20 31 33 3A 34 34 00 22 13:44."
06 52 00 70 12 54 75 72 6C 65 64 6E 69 6E 67 73 .R.p.Turlednings
20 74 65 6D 70 2E 00 71 06 D4 00 70 00 A4 00 70 temp..q.Ô.p.¤.p
03 00 00 C0 E3 37 2E 30 29 B0 43 00 F7 06 53 00 ...Àã7.0)°C.÷.S.
70 15 32 2E 30 20 20 20 20 20 20 20 20 20 20 20 p.2.0
20 31 33 3A 34 35 00 23 06 52 00 70 12 54 75 72 13:45.#.R.p.Tur
6C 65 64 6E 69 6E 67 73 20 74 65 6D 70 2E 00 71 lednings temp..q
05 06 D4 00 F9 07 07 09 11 13 45 15 02 74 00 70 ..Ô.ù.....E..t.p
03 00 00 C0 E3 06 51 00 70 0E 20 32 38 2E 35 28 ...Àã.Q.p. 28.5(
32 37 2E 30 29 B0 43 00 F7 06 53 00 70 15 32 2E 27.0)°C.÷.S.p.2.
30 20 20 20 20 20 20 20 20 20 20 20 20 31 33 3A 0 13:
34 35 00 23 06 52 00 70 12 54 75 72 6C 65 64 6E 45.#.R.p.Turledn
69 6E 67 73 20 74 65 6D 70 2E 00 71 ings temp..q
kommer som burst som repeteres med noen sekunders mellomrom.
Pakker ser ut til å starte med 06 + feks 51/52/53 + 00 + 70 men andre finnes også. 51 /52/53 kan da tenkes referert til linjenr i displayet. øverst står temp i stor text dette kommer trolig som binær data, så kommer på linjen under "turlednings temp" og på nederste linje "2.0 13:44"
Velger jeg parity mark får jeg noen få bytes per sekund med binær data 03 00 14 00 14 00 14 00 F9 06 03 00 14 00 14 00
På skop ser det ut til at data har:
startbit, 8xdata, parity (nesten alltid 0), og to stoppbit,
neste byte kommer så direkte med startbit.
Velger jeg NONE eller ODD får jeg ca samme som med MARK, med EVEN får jeg ingenting.
Synes dette (hvertfall delvis) bekrefter antagelsen om at pakker adresseres (og implisitt startes) med bytes fulgt av parity = 1, alle andre bytes ser ut til å ha parity satt til 0.
NB Koblet opp dette i går kveld så har ikke målt mye enda.
NB: jeg ser mer data på skop en jeg synes jeg får i hyperterminal...
VP har et meny valg for RCU, har satt den PÅ men har ikke lagt merke til noen endring i datastrømmen enda.
ligner dette på det som dere andre logger?
Det ser ut til at all tekst på displayet sendes som seriedata fra PIC, dette gir mening da nasjonalisering kun påvirker _en_ PROM. Mulig også derfor den trenger extern prom, det blir kanskje for mye text data å lagre. Ellers er det noen ganger enklere i produksjonen å plugge i en ferdiglaget prom i et ellers ukonfigurert kort en å brenne en uC.
Jeg bruker en ren RS232 converter (MAX203) der jeg lar ene 485 signalet drive logisk signal inn, (RS485 trenger GND i tillegg til de to linjene, linjene er inverterte men referert mot GND) lar RS232 siden gå til PC. Dette gir ikke isolasjon så det er ingenting jeg vil bruke over tid, men jeg hadde det liggende så det var enkelt.
Bruker hyperterminal satt til 19200:
Velger parity space får jeg mye lesbare data, typisk display text med tid, og noen binær data.
Turlednings temp.qpÀã7.0)°C÷Sp2.0
13:46 RpTurlednings temp.qÔp¤pÀã7.0)°C÷Sp2.0 13:46 RpTu
rlednings temp.qÔp¤Ôù kpÀã7.0)°C÷Sp2.0 13:47!RpTurlednings
temp.qÔp¤pÀã7.0)°C÷Sp2.0 13:47!RpTurle
(dette er listet ut med http://www.serial-port-monitor)
6C 65 64 6E 69 6E 67 73 20 74 65 6D 70 2E 00 71 lednings temp..q
06 D4 00 70 00 A4 00 70 03 00 00 C0 E3 37 2E 30 .Ô.p.¤.p...Àã7.0
29 B0 43 00 F7 06 53 00 70 15 32 2E 30 20 20 20 )°C.÷.S.p.2.0
20 20 20 20 20 20 20 20 20 31 33 3A 34 34 00 22 13:44."
06 52 00 70 12 54 75 72 6C 65 64 6E 69 6E 67 73 .R.p.Turlednings
20 74 65 6D 70 2E 00 71 06 D4 00 70 00 A4 00 70 temp..q.Ô.p.¤.p
03 00 00 C0 E3 37 2E 30 29 B0 43 00 F7 06 53 00 ...Àã7.0)°C.÷.S.
70 15 32 2E 30 20 20 20 20 20 20 20 20 20 20 20 p.2.0
20 31 33 3A 34 35 00 23 06 52 00 70 12 54 75 72 13:45.#.R.p.Tur
6C 65 64 6E 69 6E 67 73 20 74 65 6D 70 2E 00 71 lednings temp..q
05 06 D4 00 F9 07 07 09 11 13 45 15 02 74 00 70 ..Ô.ù.....E..t.p
03 00 00 C0 E3 06 51 00 70 0E 20 32 38 2E 35 28 ...Àã.Q.p. 28.5(
32 37 2E 30 29 B0 43 00 F7 06 53 00 70 15 32 2E 27.0)°C.÷.S.p.2.
30 20 20 20 20 20 20 20 20 20 20 20 20 31 33 3A 0 13:
34 35 00 23 06 52 00 70 12 54 75 72 6C 65 64 6E 45.#.R.p.Turledn
69 6E 67 73 20 74 65 6D 70 2E 00 71 ings temp..q
kommer som burst som repeteres med noen sekunders mellomrom.
Pakker ser ut til å starte med 06 + feks 51/52/53 + 00 + 70 men andre finnes også. 51 /52/53 kan da tenkes referert til linjenr i displayet. øverst står temp i stor text dette kommer trolig som binær data, så kommer på linjen under "turlednings temp" og på nederste linje "2.0 13:44"
Velger jeg parity mark får jeg noen få bytes per sekund med binær data 03 00 14 00 14 00 14 00 F9 06 03 00 14 00 14 00
På skop ser det ut til at data har:
startbit, 8xdata, parity (nesten alltid 0), og to stoppbit,
neste byte kommer så direkte med startbit.
Velger jeg NONE eller ODD får jeg ca samme som med MARK, med EVEN får jeg ingenting.
Synes dette (hvertfall delvis) bekrefter antagelsen om at pakker adresseres (og implisitt startes) med bytes fulgt av parity = 1, alle andre bytes ser ut til å ha parity satt til 0.
NB Koblet opp dette i går kveld så har ikke målt mye enda.
NB: jeg ser mer data på skop en jeg synes jeg får i hyperterminal...
VP har et meny valg for RCU, har satt den PÅ men har ikke lagt merke til noen endring i datastrømmen enda.
ligner dette på det som dere andre logger?
funnet ut litt mer nå.
Meldingen som utveksles antas å ha samme oppbygning for alle kilder så selv om display meldinger ikke direkte lærer oss hvordan evt logge data skal hentes ut bør det gi gode hint om formatene som brukes.
Om jeg skrur av RCU i menyen slutter VP å sende 00 0x14 med parity = 1
Jeg tolker dette som en request til RCU-10 (formodentlig med ID 0x14) til å svare.
har med digital skop samplet 50k samples over 500ms (10us rate) og dekodet for hånd alt sammen. (noen eksempler tatt med nedenfor)
bruker notasjonen med "p" etter byter med parity = 1
alle bytes er i hex, bruker "." for kort pause.
linjene med tekst som starter med 06 5x 00 70 har alltid rett før start
06 03p eller 00 F9p eller 00 F5p (disse ligger også spred rundt alene uten følgende data)
så følger meldingen, trolig til display, 5x er så langt jeg ser i gruppen 50, 51 ,52 53, eller 55 slik ser det ut samlet:
06 F9p . 06 50 00 70 YY DD DD DD CRC ........ 06 03p
(godt mulig siste 06 03p er urelatert til meldingen)
YY stemmer alltid overens med antall DD, CRC er en byte.
00 70 er muligens indikasjon av komando type, evt adressering.
der 5x er med ser det ut til at
50 er muligens symbolene øverst i display (3 bytes kun 2 bits er på som kan stemme bra i forhold til antall tente symboler)
51 gjelder stor tekst ca midt på displayet
52 er tekst til linjen nest nederst
53 er til nederst linje
55 vet jeg ikke enda.
teksten ser ut til å være terminert med 00 som vanlig for string håndtering.
har sett noen display relaterte meldinger der jeg tolker det som at det ikke alltid sendes strings men isteden binær verdier.
CRC:
Algoritmen for CRC er så langt jeg kan se til nå ikke checksum, selv om følgende eksempel først satte meg på den tanken.
00p F5p 06 55 00 70 02 44 2a 49 (fra F5 ? til 06? 2 byte DD CRC = 49)
så litt senere
00p F5p 06 55 00 70 02 44 2b 48 (samme som over men ene payload er endret fra 2a til 2b)
Da endret CRC seg også _en_ men motsatt vei, det er vanlig at checksums er inverter ved sending så om summen av data i pakken ble en større kunne det forklare at CRC ble en mindre.
meldingene over som starter "00p f5p" ser forøvrig ut til å være repetert, jeg antar det er fordi innholdet er kritisk for oprasjonen og 8 bit CRC (særlig om det er en checksum algoritme) ikke gir mye beskyttelse, full og korrekt repetisjon av hele pakken derimot gir svært mye bedre egenskaper.
det er også tegn som tyder på at når det sendes enkeltstående 06 03p så kommer 06 fra en kilde (tydelig lavere høyt nivå) og at 03p er fra en annen kilde som er sterkere.
Det kan se ut som det er bitfeil eller manglende bytes i loggen jeg postet i forrige mail, kabelen jeg bruker er ganske lang (synd å klippe en provisorisk bunt med kabel) og signal kvaliteten kunne vært bedre...
Meldingen som utveksles antas å ha samme oppbygning for alle kilder så selv om display meldinger ikke direkte lærer oss hvordan evt logge data skal hentes ut bør det gi gode hint om formatene som brukes.
Om jeg skrur av RCU i menyen slutter VP å sende 00 0x14 med parity = 1
Jeg tolker dette som en request til RCU-10 (formodentlig med ID 0x14) til å svare.
har med digital skop samplet 50k samples over 500ms (10us rate) og dekodet for hånd alt sammen. (noen eksempler tatt med nedenfor)
bruker notasjonen med "p" etter byter med parity = 1
alle bytes er i hex, bruker "." for kort pause.
linjene med tekst som starter med 06 5x 00 70 har alltid rett før start
06 03p eller 00 F9p eller 00 F5p (disse ligger også spred rundt alene uten følgende data)
så følger meldingen, trolig til display, 5x er så langt jeg ser i gruppen 50, 51 ,52 53, eller 55 slik ser det ut samlet:
06 F9p . 06 50 00 70 YY DD DD DD CRC ........ 06 03p
(godt mulig siste 06 03p er urelatert til meldingen)
YY stemmer alltid overens med antall DD, CRC er en byte.
00 70 er muligens indikasjon av komando type, evt adressering.
der 5x er med ser det ut til at
50 er muligens symbolene øverst i display (3 bytes kun 2 bits er på som kan stemme bra i forhold til antall tente symboler)
51 gjelder stor tekst ca midt på displayet
52 er tekst til linjen nest nederst
53 er til nederst linje
55 vet jeg ikke enda.
teksten ser ut til å være terminert med 00 som vanlig for string håndtering.
har sett noen display relaterte meldinger der jeg tolker det som at det ikke alltid sendes strings men isteden binær verdier.
CRC:
Algoritmen for CRC er så langt jeg kan se til nå ikke checksum, selv om følgende eksempel først satte meg på den tanken.
00p F5p 06 55 00 70 02 44 2a 49 (fra F5 ? til 06? 2 byte DD CRC = 49)
så litt senere
00p F5p 06 55 00 70 02 44 2b 48 (samme som over men ene payload er endret fra 2a til 2b)
Da endret CRC seg også _en_ men motsatt vei, det er vanlig at checksums er inverter ved sending så om summen av data i pakken ble en større kunne det forklare at CRC ble en mindre.
meldingene over som starter "00p f5p" ser forøvrig ut til å være repetert, jeg antar det er fordi innholdet er kritisk for oprasjonen og 8 bit CRC (særlig om det er en checksum algoritme) ikke gir mye beskyttelse, full og korrekt repetisjon av hele pakken derimot gir svært mye bedre egenskaper.
det er også tegn som tyder på at når det sendes enkeltstående 06 03p så kommer 06 fra en kilde (tydelig lavere høyt nivå) og at 03p er fra en annen kilde som er sterkere.
Det kan se ut som det er bitfeil eller manglende bytes i loggen jeg postet i forrige mail, kabelen jeg bruker er ganske lang (synd å klippe en provisorisk bunt med kabel) og signal kvaliteten kunne vært bedre...
-
FredRovers
- Inlägg: 19
- Blev medlem: 9 januari 2007, 21:24:41
Hög tid att släppa lite information om NIBEs RS485 protokoll Använd 19200, 9bit, N, 1.
All data är angivet i hex. En stjärna (*) före hexdata indikerar att bit 9 är satt.
Det finns fyra noder (adresser) i systemet:
14 RCU
24 Styrkort (Master)
F5 Reläkort
F9 Displaykort
Styrkortet adresserar noderna och det är bara för noderna att svara ACK eller ENQ. ACK om noden inte har något att meddela och ENQ om noden har något att meddela till styrkortet, det kan t.ex. vara en knapptryckning på displaykortet eller liknande. ACK=06 och ENQ=05. Det gäller dock att svara i tid!!!
Det som är av intresse är RCUns kommunikation. För att styrkortet ska adressera RCU (14) krävs att RCU aktiveras i meny i pannan. Om din panna inte har stöd för RCU så finns heller ingen meny för att aktivera RCU.
Styrkortet inleder varje adressering med *00. följt av en adress t.ex. *14 för RCUn.
Exempel av läsning av parametrar. När styrkorted adresserar RCUn enligt:
*00 *14
förväntar sig styrkortet ett svar. Om endast läsning av parametrar ska göras är det bara att svara med 06 d.v.s. ACK.
Styrkortet kommer då att skicka, tex:
C0 00 24 11 00 04 01 25 00 05 01 10 00 06 01 42 00 07 01 66 01 E5
C0 är det som man kan kalla cmd, det är olika för olika enheter men för RCUn är det alltid C0 men för displayen kan det vara tex 51 som betyder att datat är en textsträng som ska presenteras på översta raden, 52 andra raden 53 tredje raden.
00 skickas alltid efter cmd.
24 identifierar vem som skickar datat, dvs styrkortet i detta fallet.
11 är längden av datat som kommer efter ländbyten, 0x11=17. Obs! csum ej inkluderat.
00 första byten före en ny parameter är alltid 00.
04 parameterindex dvs parameter 4.
01 25 = data för parameter 4, 0x0125 (1/10°C)=29.3°C == Frånluftstemperatur för mif som har en 360p.
00 05 = parameterindex 05.
01 10 = 0x0110=27.2°C == Förångningstemp.
00 05 = parameterindex 06
01 42 ...
00 06 ...
01 66 ..
01 = I slutet kommer det ibland skräp. Det gäller att hålla koll på detta. Detta beror på att man kollar datalängden för sent när man skickar ut datat på RS-485. Datamängden är nämligen begränsad.
E5 = csum dvs XOR av allt från cmd till sista byten.
Nu är det inte alla parametrar som består av två bytes. Vissa parametrar består av endast en byte och vissa bytes eller bytepar kan vara bitfält. Jag antar att det ger sig om man börjar undersöka lite närmare för respektive pannmodell.
Efter att RCUn har tagit emot datat och kollat att csum stämmer ska den skicka 06 för att informera styrkortet om att den har tagit emot allt. Styrkortet kommer då att skicka *03 (ETX). Om det skulle visa sig att du får csum-fel skall 15 (NAK) skickas.
På detta sätt kommer styrkortet att gå igenom parameterindexen för att sedan börja om från början när man fått in alla. Däremellan skickars info till display och reläkort också. Det är bara att hålla koll på parameterindex och spara undan värdet på parametern.
Exempel av skrivning av parametrar.När styrkortet adresserar RCUn enligt:
*00 *14 ska RCUn svara 05 (ENQ) isf 06 (ACK). Styrkortet kommer då att svara 06 (ACK). RCUn ska då sända följande:
C0 00 14 (sender address) följt av antal bytes data du vill skicka.
Efter detta ska adress och data skickas, tex:
00 14 01 45.
XOR-summan skickar du efter att du skickat dina data bytes. XOR-summan ska räknas ut med allt som du sänder dvs c0 00 14 04 00 14 01 45.
När styrkortet tagit emot XOR-summan kommer den att skicka 06 (ACK) om XOR-summan var ok. Om styrkortet skickar 15 (NAK) så var det fel XOR-summa.
När RCUn fått in 06 (ACK) från styrkortet ska RCUn skicka *03 (ETX) och så är det färdigt. Observera att bit 9 skall vara satt när du skickar ETX.
Det finns endast parametrar som har en eller två bytes.
För min 360p så har jag lyckats lista ut följande:
Index Bytecount =Parameterdescription
=============================
00 01 =CPUid 0x20=360p, (0x72=1135)
01 02 =Utomhustemperatur
02 02 =Temp. varmvattengivare
03 02 =Avluftstemperatur
04 02 =Frånluftstemperatur
05 02 =Förångartemperatur
06 02 =Framledningstemperatur
07 02 =Returtemperatur
08 02 =Temp. Kompressorgivare
09 02 =Temp. Elpatrongivare
0a 02
0b 01 =Kurvlutning
0c 01 =Förskjutning värmekurva
0d 01
0e 02
0f 02
10 01
11 01
12 01
13 01 =Kompressordrift 0x02=på 0x00=av
14 02 =Fläkthastighet. bl.a. (1)
15 02 =Bl.a. driftläge (2)
16 02
17 02 =Strömförmrukning (maxfas)
18 02
19 02
1a 01
1b 02 =Antal starter kompressor
1c 02 =Drifttid kompressor
1d 02 =Tidfaktor elpatron
1e 01 =Maxtemp. framledning
1f 01 =Mintemp. framledning
20 01 =? ?Bitfält?
21 01 =Driftläge autodrift ?Bitfält?
22 01 =Kompensering yttre
23 01
24 01 =Intervall periodiskt XVV
25 02
26 01 =RCU-förskjutning värmekurva
27 01
28 01 =Larmnivå frånluftstemperatur
29 01 =year
2a 01 =month
2b 01 =day
2c 01 =hour
2d 01 =minute
2e 01 =second
2f 01
Nu lär det väl ta fart därute i stugorna, mycket nöje!
-
hammer1975
- Inlägg: 7
- Blev medlem: 16 september 2007, 10:01:16
- Ort: Nyköping
Hur påverkar egentligen det här med att man kör med nio databitar. Jag har hållit på en del med RS232/485 kommunikation men aldrig stött på att man använt just nio databitar. Jag har provat att koppla in mig på min Nibe 1230 och kör 19200,8,N,1 i Realterm, jag kan då bla se klartext informationen som skickas till displayen t.ex "Varmvattentemperatur" trots att jag kör med 8 databitar. Jag kollat på alla mina datorer och ingen av UARTarna klarar nio databitar.
Är det så att nio databitar endast används vid adressering och åtta när "vanlig" data skickas? Kanske nån skulle vilja förklara lite närmare hur detta funkar.
MVH, Magnus
Är det så att nio databitar endast används vid adressering och åtta när "vanlig" data skickas? Kanske nån skulle vilja förklara lite närmare hur detta funkar.
MVH, Magnus
9 bitar
Jag skulle nog vilja hålla fast vid beskrivningen att kommunikationen använder 9 bitar. Dessa är uppdelade så att bit 0-7 innehåller kommandon, ascii text etc, medan bit 8 (den som i vanliga fall har rollen som paritetsbit) används för att signalera till alla enheter på bussen att bit 0-7 innehåller en enhetsadress.hammer1975 skrev:Hur påverkar egentligen det här med att man kör med nio databitar. Jag har hållit på en del med RS232/485 kommunikation men aldrig stött på att man använt just nio databitar. Jag har provat att koppla in mig på min Nibe 1230 och kör 19200,8,N,1 i Realterm, jag kan då bla se klartext informationen som skickas till displayen t.ex "Varmvattentemperatur" trots att jag kör med 8 databitar. Jag kollat på alla mina datorer och ingen av UARTarna klarar nio databitar.
Är det så att nio databitar endast används vid adressering och åtta när "vanlig" data skickas? Kanske nån skulle vilja förklara lite närmare hur detta funkar.
En standard-UART har ingen ren 9-bitarsmode, men om man ställer in den på, tex, 8-bitar, udda paritet, så kan man lyssna efter 0x00 utan paritetsfel. Om nästföljande byte är 0x14 utan paritetsfel vet man att RCU:n blivit adresserad. Då är det ju, enligt det protokoll som FredRovers publicerat, dags att sända ACK. För sändning brukar det då gå att ställa in en standard-UART så att den håller paritetsbiten (= bit 8) fixerad till 0. På så vis går det alldeles utmärkt att använda en standard-UART för protokollet. Dock skall man alltså inte använda 8N1 eftersom man då riskerar att få framingfel.
-
hammer1975
- Inlägg: 7
- Blev medlem: 16 september 2007, 10:01:16
- Ort: Nyköping
Tack för informationen! Jag har börjat labba lite med ett program för att läsa ut data från Niben. Jag hittar "00 14" i dataströmmen och svarar tillbaka med 06 (19200,8,S,1). Jag får dock inget tillbaka från Niben vilket jag skulle få om jag förstår FredRovers beskrivning rätt. Har ni fått tillbaka nåt om ni skickar ack?
Nu kanske det har med min RS232 till 485 konverter som är av enklaste modell, jag kör med 1st 1kOhm mellan RX och TX på RS232 samt ett 1kOhm mellan Data- och GND på RS485, fanns en beskrivning på den i Allt om elektronik 2005/1.
Jag tänkte försöka bygga en bättre konverter efter denna beskrivning istället. Verkar rätt enkel även för en inte så elektronikinsatt person! http://aquaticus.info/rs485_to_rs232
MVH, Magnus
Nu kanske det har med min RS232 till 485 konverter som är av enklaste modell, jag kör med 1st 1kOhm mellan RX och TX på RS232 samt ett 1kOhm mellan Data- och GND på RS485, fanns en beskrivning på den i Allt om elektronik 2005/1.
Jag tänkte försöka bygga en bättre konverter efter denna beskrivning istället. Verkar rätt enkel även för en inte så elektronikinsatt person! http://aquaticus.info/rs485_to_rs232
MVH, Magnus
