KaKu protocol nieuw

Hoi,

Ik ben bezig om een dimmer te bouwen die ik wil kunnen schakelen met mijn ICS-1000 van KaKu.
echter als ik met een arduino en de code van Simons (https://bitbucket.org/fuzzillogic/433mhzforarduino/wiki/Home)
Het signaal afluister, krijg ik wel de aan-uit signalen binnen van zowel een APA3-1500R AB als van de ICS-1000.
Echter het Dim-signaal wordt niet weergegeven, nu heb ik het vermoeden dat het weer gaat om een nieuwere versie van het protocol, voorheen had je 16 dimniveau's en van de ICS-1000 zeggen ze dat je procentueel kan dimmen.

Nu heb ik met Audacity het signaal opgenomen van de APA3-1500R AB, maar ik kom er niet uit om die te vertalen naar wat de ShowReceiverCode (NewReomteSwitch) mij geeft.

ShowReceivedCode geeft mij:

code:


Addr 4890942 unit 0 on, period: 252us.
Addr 4890942 unit 0 off, period: 252us.

Het bijbehoordende signaal in Audacity (reeds geinveteerd):
http://dark-tower.nl/CircuitsOnline/APA3-1500R-thumb.jpg

In de info die ik hier vond; http://www.circuitsonline.net/forum/view/message/1181410#1181410 staat :

code:


         _   _
'0':	| |_| |____	(T,T,T,3T)
  	 _      _
'1':	| |____| |_	(T,3T,T,T)
  	 _   _
dim:	| |_| |_	(T,T,T,T) 

T = korte periode = 275 µs (of 375, werkt ook)
lange periode = 3 of 4*T (werkt ook allebei)

Het frame bestaat normaal uit 32 bits:
startpuls (T hoog, 9*laag)
26	adres
1	groep-bit
1	on/off/[dim]
4	unit (indien meerdere kanalen op één zender)
[4]	[dimniveau]
stoppuls (T hoog, 40*laag)

Echter ik zie 3 verschillende lengtes:
De T en de 3T van hierboven, maar tussen 2 T's zit een hele korte puls, moet ik die ook meetellen, of moet ik die overslaan?
Maar ik krijg het niet voor elkaar om het adres bit er uit te halen, zoals hierboven vermeld is.

de start en stoppuls kan ik er wel uithalen, echter zijn de lengtes van de lange puls wel anders (lees korter) dan hierboven vermeld.

Zou iemand mij verder op weg kunnen helpen hoe ik deze code moet "lezen" en moet decoderen?

PS. het plaatje is express zo groot, dan kun je goed de signalen zien.

Problems don't exist, only challanges

Sorry, het zou volgens diverse websites op X10 moeten lijken, maar ik kom er (nog) niet uit, ik zit met het probleem, hoe ik mijn signaal moet decoderen, dat staat ook niet in die Wiki.

Ik heb al diverse dingen geprobeerd:

Kort laag =1
Kort hoog = 1 (deze zijn altijd heel kort)
Lang hoog = 0

of de hele korte weglaten:

Kort laag =1
Lang hoog = 0

maar ook dan kan ik het niet vertalen naar de ontvangen code zoals ik in mijn star-post vermeld.

Dus ik zoek even wat hulp met hoe ik de code moet lezen en/of vertalen.

Problems don't exist, only challanges
Arco

Special Member

Heb je hier wat aan? Staat e.e.a. over het Nexa (kaku) protocol...
http://dephiox.blogspot.nl/2013/01/decoding-new-nexa-protocol.html
http://tech.jolowe.se/home-automation-rf-protocols/ (zie ' Nexa I ' protocol)
De boel wordt gemaakt door Arc Technology: http://www.arctech.com.tw/html/product.htm

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Hensz

Golden Member

Op 10 september 2013 11:31:35 schreef Raymond_S:
Sorry, het zou volgens diverse websites op X10 moeten lijken

Ik heb geen enkele ervaring met X10, maar dit lijkt er niet op.

Op 10 september 2013 11:31:35 schreef Raymond_S:hoe ik mijn signaal moet decoderen, dat staat ook niet in die Wiki.

Er staat hoe er gecodeerd wordt, dat moet voldoende zijn om te bepalen hoe het gedecodeerd moet worden:

"a bit value of one is represented by a 1 millisecond burst of 120 kHz at the zero crossing point (nominally 0°, but within 200 microseconds of the zero crossing point), immediately followed by the absence of a pulse. A zero value is represented by the absence of 120 kHz at the zero crossing point (pulse), immediately followed by the presence of a pulse."
Het gaat er dus om of er wel of niet een puls is tijdens/direct na de nuldoorgang.

Don't Panic!

Oeps, iets ging er mis, per ongeluk openingspost gequote, direct maar verwijderd, sorry

[Bericht gewijzigd door Raymond_S op dinsdag 10 september 2013 21:01:52 (97%)

Problems don't exist, only challanges
Arco

Special Member

Links heb ik boven al gegeven.
Je beschrijving klopt trouwens niet, die is van het oude protocol, en het signaal is het nieuwe protocol.

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Op 10 september 2013 21:01:39 schreef Arco:
Links heb ik boven al gegeven.
Je beschrijving klopt trouwens niet, die is van het oude protocol, en het signaal is het nieuwe protocol.

Ik had het gezien en probeer die sites nu uit te pluizen om mijn signaal te decoderen . . .
De beschrijving komt trouwens uit de Arduino-code NewRemoteReceiver die te vinden is op de link in mijn start-post.
Ik had vagelijk al zo een vermoeden trouwens, maar hoeveel code-versies bestaan er dan van KaKu?
1e met codeschijfjes
2e inleren (32 bits?)
3e inleren (66 bits?)

Problems don't exist, only challanges

Op de timing van de tussenliggende pulsjes na, komt het signaal uit je plaatje volledig overeen met de protocolbeschrijving uit de quote eronder (adres 4890942 dec = 00010010101010000100111110 bin).

De korte duur van de tussenliggende pulsjes kan verschillende oorzaken hebben, zoals bv een trage of overstuurde ontvanger. Heb je dit signaal aan de zender of aan de ontvanger gemeten?

Wieltje Hoe tel jij de pulsen dan ? Want ik tel nergens 5 1-en achter elkaar, zou je het misschien kunnen toelichten in mijn plaatje met wat aantekeningen of omschrijving?

Ik heb trouwens gemeten met een ontvanger, weinig zin om mijn AB open te schroeven, ik heb ondertussen 2 ontvangers (van Velleman) extra, dus zal de meting morgen nog eens overdoen en kijken wat daar uit komt.

Ik heb ook nog een andere ontvanger die ik morgen ook eens zal testen en misschien dat ik zelfs ook nog de AB toch open zal schroeven.

Problems don't exist, only challanges

Ok, ondertussen ben ik erachter dat ik inderdaad niet kan tellen, heb ondertussen het adres eruit weten te halen.

Ik hou daarna nog 6 bits over (010000) en dat is dus:
0 = Groepbit
1 = On (off/dim)
0000 = Unitnr

dank u Wieltje ik ben eruit, ik ga morgen kijken of de code van de ICS-1000 ook klopt en dan kijken of en hoe ik de dimsignalen kan achterhalen :D

Problems don't exist, only challanges

Ondertussen ook met de andere ontvangers getest, maar ook die geven een korte lage puls. Trouwens ik denk nu dat het niet aan de ontvangers ligt, want de lange lage puls is wel netjes 3x de hoge puls, als het aan de ontvanger ligt zou die ook een stuk korter moeten zijn. En ook op internet, bv de links die door Arco genoemd worden, tonen ook dit beeld.

Ik ga nu in ieder geval kijken of ik het Dim signaal kan achterhalen.

Problems don't exist, only challanges

Het korte pulsje zou ook wel bij het protocol kunnen horen; zoals ik in het door jou gelinkte topic al zei heb ik zelf nooit aan de nieuwe afstandsbedieningen gemeten maar had ik het samengesteld uit meerdere bronnen. Het maakt ook niet zoveel uit aangezien de zelflerende ontvangers niet zo kritisch zijn m.b.t. timing.

Ik ben ook wel benieuwd naar de 100% dimfunctie van de ICS-1000. Het zou zomaar kunnen dat de 0-100% gewoon omgezet wordt in 16 stappen. Mocht het anders zijn dan zie ik graag een plaatje van de nieuwe dim-commando's.

Btw, je zei dat je plaatje uit audacity kwam. Gebruik je hiervoor gewoon de audio-ingang van je PC i.c.m. een spanningsdelertje ofzo?

Ja het plaatje kwam inderdaad uit Audacity, ik vond ergens op het wereld weide web het volgende plaatje.

http://dark-tower.nl/CircuitsOnline/rf2line-in.gif
(gevonden op: http://davehouston.net/rf2line-in.gif gevonden op http://rayshobby.net/?p=3381 die hierheen linkt http://forum.arduino.cc/index.php/topic,22105.0.html)
(Tot zover mijn bronvermelding ;))

Bij mij werkte hij echter niet op de Line-in en heb ik heb dus alsnog aan de Mic-ingang gehangen en dat werkt (bij mij wel), zou uit veiligheid eerst de Line-in proberen en werkt het niet, kan je (op eigen verantwoordelijkheid) de Mic-ingang proberen.

Maar ik houd jullie op de hoogte van mijn vorderingen om het signaal te begrijpen (of het onbegrip ervan)

Problems don't exist, only challanges

Hoi,

Leuk te lezen dat er overal mensen met dezelfde problemen zitten: Hoe krijg je die dimmer optimaal aan de praat. Ik heb zelf een ICS-1000 en hiervan ook de communicatie specs van gekregen (om via UDP commando's naar de ICS te kunnen sturen). Dat protocol specificeert 32 niveaus voor dimmen.

Maar eerlijk gezegd ben ik er van overtuigd dat het gewoon de 16 niveaus zijn (4 bits) en dat de software in de ICS-1000 de waarde door 2 deelt en die naar de naar de zender stuurt.

Overigens heb ik de transmitter kant voor de dimmer eenvoudig toe kunnen voegen aan de code voor een switch. Als je bit nr 28 met korte pulsen doet (1 periode hoog, 1 laag, 1 hoog, 1 laag) dan kun je 4 extra (!) bits toevoegen voor de dimvalue (wordt dus 36 bits lang).
- 26 adres bits
- 1 group bit
- 1 bit dim, speciale codering van de puls
- 4 bits unit code
- 4 bits dimmer waarde

Maarten

Ps. Je kunt die ICS-1000 bijv. op poort 9760 via UDP het commando !R1D1FdP16\n sturen. Room 1, Device 1, Function dim, P geeft level aan met een getal van 1 tm 32.

Ik heb vandaag per toeval de oplossing voor het niet dimmen gevonden, er staat een fout in de code van Fuzzilogic, op de Bitbucket site heeft iemand de bug geplaatst met de oplossing, ik heb deze overgenomen en deze werkt (bij mij met de ICS-1000).

Hier staat de bug en de oplossing genoemd:
https://bitbucket.org/fuzzillogic/433mhzforarduino/issue/20/bug-in-rem…

Nu maar hopen dat Fuzzilogic de code overneemt voor een volgende release, ik ga in ieder geval nu verder met het maken van mijn dimmermodule.

BTW, inderdaad stuurt de ICS-1000 maar 16 dimwaarden, dat kan je nu goed zien. (al heeft de huidige app het zelfs over procentueel dimmen, misschien dat er nog eens een update komt voor de ICS-1000 die wel echte procentueel dimmen ondersteunt.

Problems don't exist, only challanges