Hur vad det nu sodjan? ....... just det.... DATABLADET!
Allt beror ju på strömekonomin men välj kanske en nW PIC med dubbla oscillatorer och möjlighet att köra med en 32KHz sub-klocka.
Så kolla alltså databladet eller rättare: börja med att välja rätt PIC till att börja med, sedan kommer resten att lösa sig.
Jag tror att det kan bli svårt att få en extern skaplig exakt timerkrets som tar mindre ström än en nW PIC på 32KHz i 3V, de kan fungera ner till 2V så jag hade tagit 2 celler och byggt till en liiiiten SMPS med LDO-regulator till radiodelen, då kan strömförbruket hållas nere och färre celler kan användas vilket kanske medger större celler.
Ska jag hjälpa längre behövs det en hel del upplysningar:
* Antal nodes max.
* Minimal levtid/batteribyte.
* Uppdateringsintervall.
* Ekonomiska krav.
Protokoll för LPRS Easy-Radio ER400TRS
Jag vet inte vilken PIC du kommer att använda, men t.ex för 16F628A så gäller :
"14.8 Power-Down Mode (Sleep)" och speciellt "14.8.1 WAKE-UP FROM SLEEP".
Där står t.ex :
"14.8 Power-Down Mode (Sleep)" och speciellt "14.8.1 WAKE-UP FROM SLEEP".
Där står t.ex :
Ett par sidor tidigare (i rutan med Figure 14-14) står det :The device can wake-up from Sleep through one of the following events:
1. External Reset input on MCLR pin
2. Watchdog Timer wake-up (if WDT was enabled)
3. Interrupt from RB0/INT pin, RB port change, or any peripheral interrupt, which is active in Sleep.
Note 1: Some peripherals depend upon the system clock for operation. Since the system clock is
suspended during Sleep, only those peripherals which do not depend upon the system
clock will wake the part from Sleep. See Section 14.8.1 Wake-up from Sleep.
Ja, jag har kollat databladet men det är inte alltid så lätt att förstå sig på det. Jag har läst igenom delen om sleep-mode och förstår att jag kan få den att vakna med RB-change eller INT0 tex men det jag funderade på var just att time att den ska sova till en viss tidpunkt.
PICen jag tänkte köra är en PIC16F88. En pic som jag jobbat med tidigare och trivs bra med.
Hur fungerar det med dubbla klockor? Kan den gå ner i sleepmode samtidigt som en 32khz ligger och tickar och så vaknar den när den har kommit till tex 60 sekunder?
Angående krav på uppsättningen så är det mindre än 100 noder. Antagligen blir det upp till 25 noder. Varje nod kommer ha en 1-wire sensor på sig. DS2438 / DS18B20 eller DS2760.
Tänkte använda serienummret som identifiering av nodern.
Mätning ska göras minst 1ggr/min från varje nod och ju längre batteritid desto bättre.
PICen jag tänkte köra är en PIC16F88. En pic som jag jobbat med tidigare och trivs bra med.
Hur fungerar det med dubbla klockor? Kan den gå ner i sleepmode samtidigt som en 32khz ligger och tickar och så vaknar den när den har kommit till tex 60 sekunder?
Angående krav på uppsättningen så är det mindre än 100 noder. Antagligen blir det upp till 25 noder. Varje nod kommer ha en 1-wire sensor på sig. DS2438 / DS18B20 eller DS2760.
Tänkte använda serienummret som identifiering av nodern.
Mätning ska göras minst 1ggr/min från varje nod och ju längre batteritid desto bättre.
> det jag funderade på var just att time att den ska sova till en viss tidpunkt.
En extern kristall på timer1-osc. "Viss tidpunkt" är lite svårare.
Om den sover för kort tid, så får du ha en räknare och t.ex göra det
du ska efter att visst antal wakeup's. Att bara räkna upp (eller ner) en
räknare och direkt gå tillbaka till sleep tar inte många cykler.
> Kan den gå ner i sleepmode samtidigt som en 32khz ligger och tickar...
Ja, om du menar timer1-osc.
> och så vaknar den när den har kommit till tex 60 sekunder?
Läs på om timer1 så får du se hur man kan konfigurera den.
> Antagligen blir det upp till 25 noder.
Jag vet inte, men personligen tycker jag att det låter som ganska många
noder. Bilden som man har fått tidigare i tråden tycker jag har pekat mot
"ett par" till "några". Spelar kanske inte så stor roll, men avvägningen
mellan tid/kostnad blir ju lite annan om man ska bygga 25 st enheter
eller 5 st...
> ju längre batteritid desto bättre.
Jo det är möjligt. Men det är inget bra designkrav!
Sätt istället en önskad batteritid. 1 vecka. 1 månad, 1 år eller vad
som helst som är rimligt.
Att designa mot ett rörligt mål är aldrig bra ! Det går ju alltid att göra
"lite till", och det blir ett litet helvete att välja teknik och komponenter...
En extern kristall på timer1-osc. "Viss tidpunkt" är lite svårare.
Om den sover för kort tid, så får du ha en räknare och t.ex göra det
du ska efter att visst antal wakeup's. Att bara räkna upp (eller ner) en
räknare och direkt gå tillbaka till sleep tar inte många cykler.
> Kan den gå ner i sleepmode samtidigt som en 32khz ligger och tickar...
Ja, om du menar timer1-osc.
> och så vaknar den när den har kommit till tex 60 sekunder?
Läs på om timer1 så får du se hur man kan konfigurera den.
> Antagligen blir det upp till 25 noder.
Jag vet inte, men personligen tycker jag att det låter som ganska många
noder. Bilden som man har fått tidigare i tråden tycker jag har pekat mot
"ett par" till "några". Spelar kanske inte så stor roll, men avvägningen
mellan tid/kostnad blir ju lite annan om man ska bygga 25 st enheter
eller 5 st...
> ju längre batteritid desto bättre.
Jo det är möjligt. Men det är inget bra designkrav!
Sätt istället en önskad batteritid. 1 vecka. 1 månad, 1 år eller vad
som helst som är rimligt.
Att designa mot ett rörligt mål är aldrig bra ! Det går ju alltid att göra
"lite till", och det blir ett litet helvete att välja teknik och komponenter...
Tycker inte det stog så bra i databladet men jag hittade en app note för Timer1 http://ww1.microchip.com/downloads/en/A ... 00580c.pdf som jag kan rekommendera för andra som undrar.
Vad jag förstog så är det bara att koppla en 32khz kristall till PICens OSC-ingångar och ställa in att den ser till att Timer1 snurrar.
Timer1 måst vara i asynkron-mode. Vid 32khz och högsta prescale så blir det avbrott var 16:e sekund.
Eftersom det blir olika långa intervall beroende på hur lång tid den behöver vara vaken så kommer jag antagligen behöva köra lägre prescale och sedan räkna ut när den ska vakna nästa gång, något som mastern skulle kunna hålla reda på och berätta för noden.
Okey det kanske är lite diffust att säga att man ska behöva byta batterier så sällan som möjligt men det var för att jag inte visste hur länge den skulle kunna leva på en uppsättning batterier.
Men efter lite räknande borde väll 1 år kunna vara rimligt tycker jag.
Fick förresten RF-modulerna och Picarna idag. Sitter bara och väntar på exprimentkorten som kommer vara av denna modell: http://www.mikroe.com/en/tools/easypic4
Måste ändå planera hur protokollet ska lira innan jag sätter igång så det är nog bäst att jag inte har fått exprimentkortet ännu kanske trots allt.
Vad jag förstog så är det bara att koppla en 32khz kristall till PICens OSC-ingångar och ställa in att den ser till att Timer1 snurrar.
Timer1 måst vara i asynkron-mode. Vid 32khz och högsta prescale så blir det avbrott var 16:e sekund.
Eftersom det blir olika långa intervall beroende på hur lång tid den behöver vara vaken så kommer jag antagligen behöva köra lägre prescale och sedan räkna ut när den ska vakna nästa gång, något som mastern skulle kunna hålla reda på och berätta för noden.
Okey det kanske är lite diffust att säga att man ska behöva byta batterier så sällan som möjligt men det var för att jag inte visste hur länge den skulle kunna leva på en uppsättning batterier.
Men efter lite räknande borde väll 1 år kunna vara rimligt tycker jag.
Fick förresten RF-modulerna och Picarna idag. Sitter bara och väntar på exprimentkorten som kommer vara av denna modell: http://www.mikroe.com/en/tools/easypic4
Måste ändå planera hur protokollet ska lira innan jag sätter igång så det är nog bäst att jag inte har fått exprimentkortet ännu kanske trots allt.
Funderar på det här med tidsluckorna. Ska man försöka ha någon fast uppsättning av tidsluckor så noderna vet när de ska sända nästa gång trots att den inte har fått synk?
Tänkte på ifall mastern är utom räckhåll någon minut så noden inte får någon kontakt när den sänder sitt ID och data.
Kör man med dynamisk tilldelning av tidsluckor så ska ju helst inte noden sända förän den har blivit synkad igen.
Om man ska sända 1ggr/min och det är mindre än 100 noder. Vi kan säga max 60 noder för att förenkla. Ska man ta en nod per sekund och sedan köra på det och att synkning sker vid kommunikation ifall Timer1 på nod och master inte strämmer överrens.
Och vid 10 misslyckade sändningar gå till START-läget där den väntar på att SYNC-knappen trycks.
Tänkte köra med att master och node har SYNC-knapp för att de inte bara ska koppla ihop sig hur som helst. I det läget sänder mastern ut en förfrågan under en av tidsluckorna och noden lyssnar under 1 min för att svara på förfrågan.
Tänkte på ifall mastern är utom räckhåll någon minut så noden inte får någon kontakt när den sänder sitt ID och data.
Kör man med dynamisk tilldelning av tidsluckor så ska ju helst inte noden sända förän den har blivit synkad igen.
Om man ska sända 1ggr/min och det är mindre än 100 noder. Vi kan säga max 60 noder för att förenkla. Ska man ta en nod per sekund och sedan köra på det och att synkning sker vid kommunikation ifall Timer1 på nod och master inte strämmer överrens.
Och vid 10 misslyckade sändningar gå till START-läget där den väntar på att SYNC-knappen trycks.
Tänkte köra med att master och node har SYNC-knapp för att de inte bara ska koppla ihop sig hur som helst. I det läget sänder mastern ut en förfrågan under en av tidsluckorna och noden lyssnar under 1 min för att svara på förfrågan.
Här kommer lite tillståndsdiagram som jag gärna vill ha lite tycke om. Något jag inte har tänkt på eller vad skulle man kunna förbättra?
Master: http://pici.se/pictures/Ahm5Lz.gif
Node: http://pici.se/pictures/mZBP8P.gif
Jag är tacksam för all hjälp jag får här nu när jag gör mitt Exjobb. Tack ni alla som står ut med mina ibland rätt korkade frågor.
Master: http://pici.se/pictures/Ahm5Lz.gif
Node: http://pici.se/pictures/mZBP8P.gif
Jag är tacksam för all hjälp jag får här nu när jag gör mitt Exjobb. Tack ni alla som står ut med mina ibland rätt korkade frågor.
Jag förstår inte varför du vill ha en "Learn"-knapp. Varje slav kommer att ha sin egen adress, ska du ha fler system kan du köra dom på olika frekvenser så alla enheter på en frekvens ska ju koppla ihop. Om detta sker automatisk blir det inget strul med att byta batteri och omstarta osv. allt kör automatisk.
Jag vill föreslå att mastern alltid skickar en förfrågan om data från en adress, detta ger förvisso lite mer strömförbruk på slaverna men det säkrar mot att de pratar i munnen på varandra.
Alltså:
Slav sover fram till tidsluckan börjar
Master: "Hallå slav x, skicka data"
Slav: Synkroniserar sov-timern och skickar "Här kommer data".
Mastern kollar om data-CRC är OK och svara "OK"/"Omsändning" men bara 1 försök.
Slaven sover.
Jag vill föreslå att mastern alltid skickar en förfrågan om data från en adress, detta ger förvisso lite mer strömförbruk på slaverna men det säkrar mot att de pratar i munnen på varandra.
Alltså:
Slav sover fram till tidsluckan börjar
Master: "Hallå slav x, skicka data"
Slav: Synkroniserar sov-timern och skickar "Här kommer data".
Mastern kollar om data-CRC är OK och svara "OK"/"Omsändning" men bara 1 försök.
Slaven sover.
Om de ska kunna koppla upp sig automatiskt så måste man tänka på vilken kanal man har satt på innan man startar upp en modul. Annars är ju risken att en master snappar upp noden.
Tror att det är bättre att man aktiverar en tidslucka för att lägga till nya om man trycker på en knapp på mastern och sedan har en tidslucka som mastern frågar efter moduler den inte fick svar från när deras tidslucka var.
Att låta mastern fråga efter data kanske är bättre. Då är det inte hela världen om en nod tappar bort sig eftersom den aldrig sänder något. Bara lyssnar i 1 minut i sträck om den missade senaste förfrågan för att få en ny synkning och ny tidslucka.
Sedan var det tänkt att mastern ska sitta på en 1-wire bus som slave och svara på förfrågen efter data från de olika noderna. Den ska alltså emulera de olika komponentern.
Tror ni det blir för mycket jobb för en PIC16F88 att både leka master för det trådlösa och sedan svara som slave på 1-wiren?
Kommer behöva mellanlagra all data från noderna i något minne och skulle då kunne köra på ett minne som kan läsas med en PIC samtidigt som en annan PIC skriver till det.
Tror att det är bättre att man aktiverar en tidslucka för att lägga till nya om man trycker på en knapp på mastern och sedan har en tidslucka som mastern frågar efter moduler den inte fick svar från när deras tidslucka var.
Att låta mastern fråga efter data kanske är bättre. Då är det inte hela världen om en nod tappar bort sig eftersom den aldrig sänder något. Bara lyssnar i 1 minut i sträck om den missade senaste förfrågan för att få en ny synkning och ny tidslucka.
Sedan var det tänkt att mastern ska sitta på en 1-wire bus som slave och svara på förfrågen efter data från de olika noderna. Den ska alltså emulera de olika komponentern.
Tror ni det blir för mycket jobb för en PIC16F88 att både leka master för det trådlösa och sedan svara som slave på 1-wiren?
Kommer behöva mellanlagra all data från noderna i något minne och skulle då kunne köra på ett minne som kan läsas med en PIC samtidigt som en annan PIC skriver till det.
"...skulle då kunne köra på ett minne som kan läsas med en PIC samtidigt som en annan PIC skriver till det" Varför då?
Vad du ska kolla lite på är vilken datamängd som ska sparas. Ska du spara de unika serienummer? Eller bara temperaturdata?
Sedan väljer man PIC efter det. Jag tror att du redan nu ska kolla på PIC18F-serien.....
Om PIC'en hinner med att vara båda master och sköta kommunikationen? Det beror ju på din programmeringsskicklighet och klockhastighet, inget annat.
Kör du t.ex. en MATCH-ROM-ID med 60 nodes blir det en del att sampla för varje bit men detta kan göras allt eftersom så att datan är förberedda, då använder man "dödtiden" istället för att köra på för fullt.
Vad du ska kolla lite på är vilken datamängd som ska sparas. Ska du spara de unika serienummer? Eller bara temperaturdata?
Sedan väljer man PIC efter det. Jag tror att du redan nu ska kolla på PIC18F-serien.....
Om PIC'en hinner med att vara båda master och sköta kommunikationen? Det beror ju på din programmeringsskicklighet och klockhastighet, inget annat.
Kör du t.ex. en MATCH-ROM-ID med 60 nodes blir det en del att sampla för varje bit men detta kan göras allt eftersom så att datan är förberedda, då använder man "dödtiden" istället för att köra på för fullt.
Eftersom det är flera olika kretsar som tex DS2438 som har en hel del minne i sig men olika egenskaper så krävs det en del minne. Det var därför jag kollade på externt minne. Klockan på en PIC16F88 tycker jag borde räcka annars men jag vet inte om jag skulle lyckas med att låta den både prata med noderna och svara som slave på 1-wire.
Har inte jobbat med 1-wire tidigare men jag vet att den är väldigt tidskritisk så det är möjligt att jag måst hoppa upp till någon häftigare krets för mastern. Har inte jobbat med PIC18-serien tidigare men det kanske inte är så mycket som skiljer. Det underlättar dock om den passar exprimentkortet som är beställt som stödjer alla 8, 14, 18, 20, 28 and 40 pin PIC microcontrollers.
Kompilatorn klarar både 16F och 18F som tur e (MikroC).
Har inte jobbat med 1-wire tidigare men jag vet att den är väldigt tidskritisk så det är möjligt att jag måst hoppa upp till någon häftigare krets för mastern. Har inte jobbat med PIC18-serien tidigare men det kanske inte är så mycket som skiljer. Det underlättar dock om den passar exprimentkortet som är beställt som stödjer alla 8, 14, 18, 20, 28 and 40 pin PIC microcontrollers.
Kompilatorn klarar både 16F och 18F som tur e (MikroC).
Vad skilje PIC16 och PIC18 familjerna? En del kretsar verkar rätt lika.
Borde räcka med att kolla edfter en PIC med mycket RAM antar jag. För det är väll där variabler lagras, eller? EEPROM minnet e nog förlångsamt i alla fall och mastern kommer ändå inte gå på batteri så den ska inte få några avbrott.
Borde räcka med att kolla edfter en PIC med mycket RAM antar jag. För det är väll där variabler lagras, eller? EEPROM minnet e nog förlångsamt i alla fall och mastern kommer ändå inte gå på batteri så den ska inte få några avbrott.
