Okey då var några ER400TRS beställda.
Nu är det protokollet jag måste börja kolla på.
Kommer ha en master som ska samla in data trådlöst från några olika 1-wire temperatursensorer.
De trådlösa enheterna kommer sitta på batteri och kommer sova större delen av tiden för att spara så mycket kräm som möjligt.
1 mätning/min skulle räcka.
Vad skulle man kunna använda för något enkelt protokoll för att få en säker överföring av datat. Någon med bra länk till något projekt där Easy-Radio moduler används i liknande situation?
Protokoll för LPRS Easy-Radio ER400TRS
Den här appnoten hade jag mycket nytta av då jag skrev uC-kod för radioöverföring via 433Mhz ASK (visserligen bara envägskommunikation, men det är alltid en början!)
http://www.radiotronix.com/support/clic ... /an401.pdf
http://www.radiotronix.com/support/clic ... /an401.pdf
I detta fall ärdet tvåvägs kommunikation och modulen som används är en Easy-radio modul så någon pre-amble eller liknande behövs inte.
Är ute efter nästa nivå på protokoll som gör så att krockar hanteras med adressering osv.
Dock har jag visserligen en ARF05 som är en enkel RF-modul men den hade jag inte tänk använda pga komplexiteten att få en tillförlitlig dataöverföring. Det som talade för var att strömåtgången var väldigt låg dock.
Är ute efter nästa nivå på protokoll som gör så att krockar hanteras med adressering osv.
Dock har jag visserligen en ARF05 som är en enkel RF-modul men den hade jag inte tänk använda pga komplexiteten att få en tillförlitlig dataöverföring. Det som talade för var att strömåtgången var väldigt låg dock.
Har aldrig provat det själv men det verkar vara relativt enkelt att använda. Om inte annat så kan du kanske få några ideer..........
http://www.hth.com/snap/
http://www.hth.com/snap/
SNAP är bara ett överföringsprotokoll och omhandlar inte omsändning, kollision och annat viktigt. Det som är viktigt är att data överförs på ett säkert sätt, alltså att ett paket är "helt" och inte delvis förstörd.
Vad jag vet har LPRS en hel del sånt i deras ER400TRS-2 modul, det kan vara värd att kolla datablad ordentligt och kanske fråga dom om ytterligare information.
Vad jag vet har LPRS en hel del sånt i deras ER400TRS-2 modul, det kan vara värd att kolla datablad ordentligt och kanske fråga dom om ytterligare information.
Jo som du säger Icecap så har de en hel del inbyggt. CRC, manchesterkodning mm har jag för mig. Det jag syftade på var ett protokoll för att få dem att inte prata i mun på varandra och utan att de behöver vara vakna mer än nödvändigt för att sända ut en viss mängd information.
Det som är trevligt med ER400TRS-2 är att den har 10 kanaler också. Jag tänkte använda dem i första hand till att kunna köra flera "nätverk" i närheten av varandra utan att störa men om det skulle förbättra trafiken mycket så är det klart att man skulle kunna använda 2 kanaler tex för varje plats.
1 kanal där klienterna säger att de vill sända info där mastern sedan svarar vem som får sända och då sänder den sin trafik på en annan kanal.
Var kan jag hitta protokoll i denna nivå? Modbus är väll typ ett sådan protokoll fast för trådfast koppling med flera noder.
Det som är trevligt med ER400TRS-2 är att den har 10 kanaler också. Jag tänkte använda dem i första hand till att kunna köra flera "nätverk" i närheten av varandra utan att störa men om det skulle förbättra trafiken mycket så är det klart att man skulle kunna använda 2 kanaler tex för varje plats.
1 kanal där klienterna säger att de vill sända info där mastern sedan svarar vem som får sända och då sänder den sin trafik på en annan kanal.
Var kan jag hitta protokoll i denna nivå? Modbus är väll typ ett sådan protokoll fast för trådfast koppling med flera noder.
Microchip har ett ZigBee-liknande protokoll som man kan använda gratis om man använder deras kretsar enbart: MiWi
Men annars är det hela en fråga om att tänka en hel del och kan man vore det bra om man använder processorn till att ta hand om timingen i slaverna.
Detta medför att man kan göra en "synk" i tid av slaverna, så att om man har 10 slaver som ska rapportera var 60 sek kan de få var deras tidslucka och då "vakna" när det är deras minut. En grej kan vara att använda en extra tidslucka till att fråga om det finns nya enheter, slår man då på 1 åt gången har man ett självexpanderande nätverk eller alternativt ger alla slaver egna adresser. I den extra tidslucka stegas det då genom de "tomma" adressor och trimmas i tabellen sedan.
Allt detta går att göra när man vet maximalt antal slavenheter, uppdateringstid, maximalt strömförbruk och dylikt.
Det säkraste sätt att säkra att enheterna inte "pratar i munnen på varandra" är ju att använda tiden som en kanaldelare om det finns rikligt.... så gör man ju i GSM.
Vad man egentligen behöver då är att man i varje slav har en skaplig korrekt timer som kan tima 60 sek och sedan är resten mjukvara. Ett viktigt led i detta är att kunna ge en kommando som betyder "om-synkronisera!" och som medger att man kan ge alla slaver besked om att synkronisera ytterligare an gång, då kan man addera alla de slaver man vill och allt trimmas in automatisk.
Blir lite programmerande men sedan kör det som på räls.
Men annars är det hela en fråga om att tänka en hel del och kan man vore det bra om man använder processorn till att ta hand om timingen i slaverna.
Detta medför att man kan göra en "synk" i tid av slaverna, så att om man har 10 slaver som ska rapportera var 60 sek kan de få var deras tidslucka och då "vakna" när det är deras minut. En grej kan vara att använda en extra tidslucka till att fråga om det finns nya enheter, slår man då på 1 åt gången har man ett självexpanderande nätverk eller alternativt ger alla slaver egna adresser. I den extra tidslucka stegas det då genom de "tomma" adressor och trimmas i tabellen sedan.
Allt detta går att göra när man vet maximalt antal slavenheter, uppdateringstid, maximalt strömförbruk och dylikt.
Det säkraste sätt att säkra att enheterna inte "pratar i munnen på varandra" är ju att använda tiden som en kanaldelare om det finns rikligt.... så gör man ju i GSM.
Vad man egentligen behöver då är att man i varje slav har en skaplig korrekt timer som kan tima 60 sek och sedan är resten mjukvara. Ett viktigt led i detta är att kunna ge en kommando som betyder "om-synkronisera!" och som medger att man kan ge alla slaver besked om att synkronisera ytterligare an gång, då kan man addera alla de slaver man vill och allt trimmas in automatisk.
Blir lite programmerande men sedan kör det som på räls.
Hur mycket diffar microchips klockor? eller ska man kanske använda en extern realtidsklocka som skickar en inpuls med ett programmerat intervall för att väcka PICen.
Har inte jobbat med sleepmode på PICar men det verkar inte särskillt svårt. Det stog något om att man kunde ha timer1 som interupt för att väcka PICen om man kör den asynkront, men vad betyder det? Oscillatorn stoppas ju när picen sover.
Eller ska jag kanske bara tagga ner frekvensen till 32 khz någonting i stället? Picen drar visserligen något mer, typ 75uA i stället för 0,1uA som sleepmode gör.
Har inte jobbat med sleepmode på PICar men det verkar inte särskillt svårt. Det stog något om att man kunde ha timer1 som interupt för att väcka PICen om man kör den asynkront, men vad betyder det? Oscillatorn stoppas ju när picen sover.
Eller ska jag kanske bara tagga ner frekvensen till 32 khz någonting i stället? Picen drar visserligen något mer, typ 75uA i stället för 0,1uA som sleepmode gör.
> Hur mycket diffar microchips klockor?
Tro det eller ej, men det finns faktiskt specat i databladen !
Om jag inte tar fel kan timer1 "väcka" PICen ur sleep om den klockas med
en egen kristall. Huvudoscillatorn stoppas.
> Eller ska jag kanske bara tagga ner frekvensen till 32 khz någonting i stället?
Tja, svårt att svara på, det är din strömförbrukning.
För övrigt verkar F88 vara populär just när man vill kunna snabbt växla
ner hastigheten för low-power applikationer. Även 16F688 (som kom lite
senare) borde fungera bra. Eller 12F683 om man klarar sig med en
DIP-8 kapsel. De har samma intowc med programvarustyrd "växellåda...
Tro det eller ej, men det finns faktiskt specat i databladen !
Om jag inte tar fel kan timer1 "väcka" PICen ur sleep om den klockas med
en egen kristall. Huvudoscillatorn stoppas.
> Eller ska jag kanske bara tagga ner frekvensen till 32 khz någonting i stället?
Tja, svårt att svara på, det är din strömförbrukning.
För övrigt verkar F88 vara populär just när man vill kunna snabbt växla
ner hastigheten för low-power applikationer. Även 16F688 (som kom lite
senare) borde fungera bra. Eller 12F683 om man klarar sig med en
DIP-8 kapsel. De har samma intowc med programvarustyrd "växellåda...
Men i sleep-mode måste jag väll ha någon extern krets som väcker PICen antar jag eller kan man säga till picen att sova en viss tid för att sedan vakna?
Det där med Timer1, är det bara att använda en vanlig klockkristall med 32,7680 kHz ? Om picen sover, hur vet den att den ska vakna efter en viss tid då?
Eller ska man använda någon strömsnål timer annars?
Det där med Timer1, är det bara att använda en vanlig klockkristall med 32,7680 kHz ? Om picen sover, hur vet den att den ska vakna efter en viss tid då?
Eller ska man använda någon strömsnål timer annars?
