Svenska ElektronikForumet

Snygga grafer!

Jag tycker att jag varit så noggrann när jag mätt totala pulslängden. Lite senare ikväll så ska jag mäta på min PIC och se om det är lika fel på min. Jag återkommer

Lägger till en bild då på en Esic termometer
Är ganska lik Esic Clone v1

Rub-it-in bara

Jag har tittat på timingen på version 0.4, och den är mycket riktigt fel. Väldigt fel. Jag tror att jag mätte 64ms i stället för 72ms.
Version 0.4 är nu borttagen och ersatt med 0.4.1 som ska ha rätt timing.

Tack för att du tog dig tid och kollade. Jag trodde att jag lämnat den delen av koden för gott

Hittade du förresten vilken parameter jag menade för att ändra antalet omsändningar av ett datapaket?

Jag måste ändra till _FOSC_INTRCIO för att få koden att snurra, varför vet jag inte.
Om det beror på MPLAB vs MPLABX eller nått.
Jag kör iaf. MPLABX på Linux och programmerar med Pic Kit 3.

Include filen måste även ändras till P12F675.INC (versaler) under Linux pga.
skiftlägeskänsligt filsystem.

Annars verkar det fungera bra

Jag har bara byggt med MPlabX på OS X och Windows 7.
Fast det viktiga är nog vilken kompilator du använder. Jag har kört med mpasm på båda os:en.

Hur som helst. Kul att du har fått det att fungera!
Glöm inte att öka på parametern SAMPLE_DELAY till något lämpligt, så att du inte skickar så ofta.

Har också mpasm. Ver 5.48 för att vara exakt.
Vad configbiten för intern osc heter spelar visserligen ingen större roll,
men det är ändå väldigt märkligt att den heter olika saker.

Men tack för att du delade med dig av projektet och koden!
Riktigt kul att läsa koden då den är bra dokumenterad och det var ett
tag sen som jag hade med Assembler att göra.

mpasm fungerar för mig, inga ändringar behövs.

Väljer man "fel" compilator i MPLABX måste man göra en massa ändringar för att få det att fungera.

Ja, jag hittade parametern för omsändningarna, men en sändning är för lite och osäkert.
Ofta kommer den inte fram och ändrade inte på mitt problem.

Så måste nu komma på hur jag lägger batteristatus till ett fast värde och kolla vidare vad kan orsaka problemet.

Och nu dyker det upp nåt nytt i Telldus Live
Och fann en bug där också, har pin 7 kopplad och skickar batteristatus 68%.
För att få temperaturen rätt kopplar jag bort pin 7 så den i Duon visar 0% men Live håller fortfarande senaste värde för humanitet dvs 68%
Detta är alltså en Live bug...

Fick också mina nya sändare idag och i paketet var också med en DHT22
DX sändaren fick jag inte att fungera via transistorn men misstänker stort min koppling.
Konstant kopplad fungerar den fint.

Om du vill, kan jag skicka kod för att testa dht22:an.

Datapinnen ska i så fall kopplas till pinne 4 på pic:en. Sen kommer luftfuktigheten att skickas i Humidity-fältet.

Tyvärr så har jag ingen dht22 själv än, så du får i så fall helt otestad kod.

Nu har jag fått detta att fungera
Men jag tror det finns en bugg.
Över 30 grader varmt blir det lite konstiga värden!

Se nedan.

Vilken räckvidd
Härligt att du delade med dig detta!!

Edit: kör med TS Duo samt version 0.4.1 på koden.

FredrikTillman skrev:I v4 var det två DS18B20 som krockade men i v3 en DS18B20 och en DS1822.

Jag fattade inte om det var 1W-sensorerna eller dina moduler som "krockade". 1W kan inte krocka då de har unika adresser. Det finns 2^64 1W-adresser, inte 64, och alla ska vara unika. Om du får krockar på dina 1W-sensorer så är det något annat som är fel.

Testar gärna support för DHT22

Har samma problem med att temperaturer skickas som över 150C men det har i mitt fall nåt att göra med humidity datan.
Är den 70% är allting ok, 69% och värdet är fel.
Har lämnat pin 7 okopplad så fungerar det fint när humidity skickas som 0%.
Nånting du kan pröva på ifall du "batterimätaren" kopplad.

Har också kommit fram till att sändaren från DX har en otrolig räckvidd.
Byggde in en sensor i skalet från en Clas Ohlsson 36-4744.
Denna sensor stöds inte av Telldus och verkar ha ett krångligt protokoll så skippade den
Har en distans på 150 meter nu och fungerar fortfarande fint.
Det jag är orolig över är att skalet bara har plats för två batterier så tror det kan bli problem rätt fort.
Glömde också byta intervallet från 15 sekunder innan jag monterade den så får göra det i samband med första batteribytet

1-wire addressena är unika och kan inte krocka, men mandolyn protocollet som används här kan inte använda 1-wire ID.
Huskod måste vara mellan 1 och 16 (4-bit), samt kanal måste vara mellan 1 och 4 (2-bit) så protocollet har en begränsning på 64 IDn.
1-wire addressen används för att försöka göra mandolyn ID så unik som möjligt men är svårt med så få addresser som kan användas.

Visst har jag pin 7 inkopplad, den levererar värde 40 just nu.
Ska pröva att ta bort den jag med så får jag se om jag får in rätt temp när det blir mer än 30 grader.

Vilken Dx sändare är det du kör med? jag hade en gammal "vellerman" liggandes så jag byggde med den, är ju inte så billigt om man köper den hemma i Sverige.

sonnyboy skrev:Nu har jag fått detta att fungera
Men jag tror det finns en bugg.
Över 30 grader varmt blir det lite konstiga värden!

Se nedan.

Vilken räckvidd
Härligt att du delade med dig detta!!

Edit: kör med TS Duo samt version 0.4.1 på koden.

Vad kul att du fått igång det! Och med en bra räckvidd också. Det hänger ju på sändaren, och du verkar ju fått tag på ett praktexemplar

Jag ska kolla det där med temperaturen över 30. Det som gör att det fungerar dåligt, är ju att jag anser att telldus-core har implementerat Mandolyn protokollet fel, och jag rätt
Missmatchen gör att det blir konstigt när temperaturen går över 30 grader. Jag ska kolla vad en ESIC visar när man går över 30. Om den visar värdet korrekt, så får jag retirera och implementera enligt telldus-core

Det är kul att dela med sig när det man gjort är uppskattat, så klart. Tack för feedbacken.

FredrikTillman skrev:Testar gärna support för DHT22

Har samma problem med att temperaturer skickas som över 150C men det har i mitt fall nåt att göra med humidity datan.
Är den 70% är allting ok, 69% och värdet är fel.
Har lämnat pin 7 okopplad så fungerar det fint när humidity skickas som 0%.
Nånting du kan pröva på ifall du "batterimätaren" kopplad.

Har också kommit fram till att sändaren från DX har en otrolig räckvidd.
Byggde in en sensor i skalet från en Clas Ohlsson 36-4744.
Denna sensor stöds inte av Telldus och verkar ha ett krångligt protokoll så skippade den
Har en distans på 150 meter nu och fungerar fortfarande fint.
Det jag är orolig över är att skalet bara har plats för två batterier så tror det kan bli problem rätt fort.
Glömde också byta intervallet från 15 sekunder innan jag monterade den så får göra det i samband med första batteribytet

1-wire addressena är unika och kan inte krocka, men mandolyn protocollet som används här kan inte använda 1-wire ID.
Huskod måste vara mellan 1 och 16 (4-bit), samt kanal måste vara mellan 1 och 4 (2-bit) så protocollet har en begränsning på 64 IDn.
1-wire addressen används för att försöka göra mandolyn ID så unik som möjligt men är svårt med så få addresser som kan användas.

Det som händer vid 30C förvånar mig inte. Jag har lite svårt att få koll på vilket protokoll jag ska implementera efter.
Jag har hittat tre olika protokoll, där det protokoll som jag tycker är minst logiskt är det som är implementerat av telldus-core.
Ta till exempel de fyra sista bitarna. De har telldus core implementerat som sista bitarna av humidity samt en bit checksum.
Om man istället som jag, implementerar det som två bitar sekvensnummer, och två bitar checksumma, så stämmer det för bra för att det ska vara fel. Man får alltid sekvensnummer 1, 2 och 3 när ESIC skickar sin paketburst. Jag ändrar alltså i telldus-core-filen ProtocolMandolyn.cpp när jag testar detta.

Angående räckvidden. Helt fantastiskt att du har 150m Jag har bara testat i lägenheten och där räcker den till alla skrymslen. Jag är nöjd

Bra beskrivning av funderingen som ie hade angående adresseringen. Det är precis så det är, och problemet ligger alltså i att Mandolyn-protokollet bara har 4+2 bitar för att adressera termometrarna. Det hade alltså inte gjort någon skillnad om 1-wire hade haft 256 bitar som serienummer.

Jag PM:ar dig angående beta-versionen som stödjer DHT22. Jag har ju som sagt bara torrkört koden i huvudet, så det finns stor risk att den inte fungerar.

Kan man programera sönder 12f675?
Min ena pic levererar värden som den ska, medans den andra levererar korrekt värde 2 ggr sen kommer typ 148 2 ggr sen kommer korrekt igen.
Byter bara Picen på breadborden.
får inga felmedelanden.

Den är programerad med sample delay . om det ska ha något med saken att göra.