Направих преустройство на сушилнята с новия цифров датчик SMTHS08I и съм супер впечатлен от стабилността на работата му. Използвах готов код от I2C сензора HYT271, тъй като специално за изчисленията имах затруднения. Прочитам го на всяка половин секунда. В последствие го преработих като за моя датчик. В кода се използва отчитане до първия знак след запетаята. Имам, обаче два проблема:
1. Температурата в началото тръгва от 11 градуса /сушилнята е на терасата, където е около 7 градуса/ , качва се плавно и вместо да се поддържа на 80 градуса /по програма/ се поддържа на 50 градуса по дисплей. На пипане също е около 50-те. Днес ще измеря с цифров уред за по-сигурно...
2. Влажността в началото се измерва на около 75%. Слагам дрехи сушащи се на простора в темперирана сушилня, влажността се застопорява след около 20 секунди и се отчита на около 35%, което ми се вижда доста странно...
Усеща се, че нито температурата е каквато трябва, нито влажността, макар че и двете са супер стабилни като показание на дисплея.
Очаквам съвети, предположения и предложения!

Интересува ме освен това необходимо ли е в края на по-долния почернен ред /част от програмния ми код/ да фигурира оператор за NoAck и евентуално за STOP за да спре I2C датчика да бълва данни или това става хардуерно в зависимост от оператора /в случая I2CIN/
I2CIn SDA, SCL, Chipread, [Hbyte1, Lbyte1, Hbyte2, Lbyte2]:BusNack:BStop
Ще е проблем ли датчика да продължи да работи и да зарежда регистрите си, които няма да бъдат прочетени?

50(hex)=80(dec)
Някъде да липсва преобразуване от hex na dec или обратно??

Въобще не е ясно дали четеш сензора за влажност.
Тези почернени оператори говорят нещо на много малко хора, ако имаш някакъв листинг - намери съответната част и я покажи тука.
Това "Chipread" как му е указано от кой чип да чете и от кой адрес да почне?

В Manual-а е записано:
.
.

Резултатът как да се интерпретира - като HEX или DEC? Аз го ползвам като DEC....

Няма съмнения, че чипа се чете! Показанията се променят общо взето в тон със ситуацията /според мен и опита ми от предишните датчици/.
http://www.smartec-sensors.com/assets/files/pdf/manuals/SMTH08INv2.2.pdf

Относно "почернения" ред - комуникацията я има и смятам, че няма проблем в нея. Очаквам Cekins да се намеси..по въпроса за NoAck специално за PROTON IDE

Двата реда формули за изчисляване са от някакъв мануал. Ако си преписал така формулата
директно в кода си - много як компилатор имаш. Предполагам ,че си редуцирал формулата
до нещо по-просто, което не ползва плаваща запетая.

За температурата - ако на ръка я мериш около 50 градуса и на дисплея е 50 - би трябвало
регулаторът на температура да получава задание 0х50 , но да го интерпретира като десетично 50 - виж си процедурите, които управляват нагревателите.

Това ми е процедурата за мерене на PROTON. Не ми стана ясно в мануала крайните резултати в HEX ли са или в DEC, а това с пипането с ръка е малко неясна работа и затова ще меря довечера с уред.

Ако има грешка в преобразуването тогава началната температура мисля, че няма да се извежда като 11 градуса, вместо реални 7градуса наоколо, а като 4 или 5..

Ако Temperatura ти е 16 битово без знак.. всичко заминава в кофата.
Ако използваш само старпия байт:
Temperatura = ( Hbyte2*165)/256 -40.

За влажността са подобни нещата сигурно.
Трябва да съобразиш реда на деление и умножение до какво води.

Ако разгледаш мануала, там си пише, че имаме 14-битово число за температурата и за влажността. От двата първи байта, които са за влажността, се премахват най-старшите два статус битове. При температурата - от двата байта се премахват двата най-младши байта по подобни причини. Сметките са обработка и освобождаване от излишните битове и след това - според мануала. Предполагам, че са ми правилни.

Аз мануала го разгледах , преди да пиша за сметките.
Опитвам се да ти насоча вниманието към математиката- ако я правиш на ръка или с калкулатор, делението ще ти даде резултат с дробна част. После умножаваш по 165, закръгляш и вадиш 40.
Твоя код може да работи само ако използва float променливи и математика. Така ли е или не е?
На температурата можеш да ползваш колкото искаш бита - въпросът е да знаеш какво правиш. Ако ползваш 16 бита - ще делиш на 65536, вместо на 16384.
Показах ти как се ползват само старшите 8 бита (със загуба на точност, която за сушилнята не е съществена) - вместо да ги умножавам по 64 и деля на 16384 , само деля на 256 (което е 16384/64).
Като полагам , че Temperatura e цяло число до 16 бита - първо умножавам по 165 и после деля на 256. Въщност деленето на 256 означава да вземеш старпите 8 бита от умножението.
Ако не използваш float - сметките ти не са коректни и ти идват проблемите с температурата. Освен ако компилаторът не е предвидил това ,което ти обяснявам.

В неговият вариант може да има кликсон за прегряване т.е. всичко да е наред а да изключва от защита.

If Temperatura > 90 Then Print Cls:Print At 1,1, 66,165,67,79,75,65,32,84,69,77,168,69,80,65,84,169,80,65:End ;VISOKA TEMPERATURA

Ето това ми е "кликсона", но той действа при стойност 90.
Програмата, която ползвам досега е работила по същия начин, при същите условия като изключим датчика, сметките свързани с него и това, че използвам подпрограма за целта /кода, на която е изложен по-горе/, докато преди използвах текущи измервания в основната програма

което свежда проблемите до:
- комуникация
- математика.
Та какъв е типът на променливата Temperature?

Значи - нямаш нужда от тоя сложен израз. В твоя случай става така :

BusIn DevAdr,{RegAdr},[Word1, Word2]

Така само си изработва всички нужни сигнали, ацк и ноацк и т.н.
Ако си закачен на хардуерните линии се прави с HBusIn.
RegAdr е евентуално адреса на клетката в дивайса (за епроми или за някой настройващи регстри, ако има такива). Ако не се слага - девайса по принцип или продължава от където е спрял (еепромите) или си подава от където трябва - в случая с разни датчици.

Word1 и Word2 си ги дефинираш като Word.

Двата горни статуса се махат така :
word1.byte1 = word1.byte1 & $3F

а за word2 (долните) така :
word2=word2>>2

За температурата - променливата ти temperatura си я дефинираш като SWord и от там на сетне компилатора ще се грижи тя да се разглежда като signed. По принцип протон-а разглежда като променлива със знак само флоат и dword ако не е уточнено друго. Последните версии (тия дето съм ви ги дал) вече работят и с byte и word - съответно SByte и SWord.

Направи първо тези неща и после ще видим нататък какво става.

Знак се почвява чак в последното действие - изважедне на 40(при температурата). Дотогава са се появили ред колизии ,ako SWORD е 16 бита.
Всъщност мотиките трябва да се настъпват.

Кое според теб няма да сметне вярно? То между другото щом тоя код работи значи променливите Humidity и Temperatura са Float. Иначе щеше да сметне дедовия...

Забравих да кажа че за BusIn, адреса на дивайса няма нужда да му е оправен R/W бита - то само си го прави какъвто трябва. Затова за яснота си задаваш адреса какъвто е с 0 за бит 0 и си го оставяш така. Не знам какви са тия сметки там в началото дето си ги писал за тия адреси ама кода ти за това нещо е пет-шест реда :

BusOut ChipAdr,[0]
DelayMS 60
BusIn ChipAdr,[Word1, Word2]
Word1.byte0=Word1.byte0 & $3F
word2=word2>>2
Humidity = word1 / 163.84 'Тука Humidity трябва да е флоат за да стане
Temperatura = word2 / 99.3
Temperatura = Temperatura - 40

и това е... друго няма

Ето ги декларациите:


Ето я и процедурата:


Ами, Cekins, аз това с обработката на байтовете и думите съм го направил и то работи! Идеята за NoAck беше - дали помага или пречи добавката от :BusNack:BStop, трябва ли да я има /в момента я няма/ или не.
А това по-долу, от мануала, мисля, че малко се разминава с твоите сметки, но може и да не съм прав..

Temp[°C] = (Temp_High[7:0]*64 + Temp_Low[7:2]) / 16384 * 165 – 40

RH[%] = (RH_High[5:0]*256+RH_Low[7:0]) / 16384 * 100