Multifunctioneel alarm en brandmeldingssysteem

[Redwood]

(ik zal zo duidelijk mogelijk proberen te zijn)

Voor een horecabedrijf van 3 verdiepingen, heeft de gemeente sinds kort nieuwe eisen.
Ik zal eerst de inrichting verduidelijken!

Dit horeca bedrijf (disco) heeft dus 3 verdiepingen,
In de kelder 1 bar
op de begane grond 3 bars
en op de 1e verdieping 1 bar
een garderobe op de 1e verdieping
uiteraard een dansvloer met dj booth
een balie met de kassa's
en een in- en uitgang.

Wat is de bedoeling?

Dit is dus dat bij elke bar, de garderobe, de dj-booth en de balie, een knop komt, om in geval van onrust, de security te alarmeren, (deze staan bij de ingang), dit moet door middel van audio (zoemer) en visueel, (lampje cq. ledje met text erachter bij welke locatie dit is)
Bij voorkeur komen er bij elke bar, de garderobe, de kassa, de dj-booth, een 2 tal knoppen, 1 knop voor code groen (de security moet komen, maar het is niet dringend) en knop 2 voor code rood (security SPOED!)

Ook is een eis van de brandweer, dat er bij dezelfde lokaties een brandmeldknop komt.
Hier is de bedoeling van dat, als er bijv. brand uitbreekt in de garderobe, de medewerkers hier op drukken, er bij de security EN bij de dj booth tegelijkertijd een waarschuwingslamp en een zoemer(ander type als bij roep voor security) afgaat.

In een notendop: bij elk van de 5 bars, de garderobe de dj booth en de kassa, een 3 tal knoppen.

knop 1. code groen (groen lampje van desbetreffende lokatie, en zoemer gaan af bij security)
knop 2. code rood (rood lampje van desbetreffende lokatie, en zoemer gaan af bij security)
knop 3. brandalarm (ander lampje, en andere zoemer voor desbetreffende lokatie gaan af bij security, EN bij dj-booth)


Op zch zou dit voor mij geen enkel probleem zijn, een hoop signaal kabel, een hoop relais, een mooi kastje, lampies erin, en een prima functionerend systeem.

Helaas....... dit zit er niet in, het probleem is namelijk, dat door de bouw van de zaak het niet meer mogelijk is alle kabels te leggen, het zou dan gaan om 8 verschillende lokaties die allen naar de security moeten. 1 of 2 lukken nog, maar de rest...... nada!


Wat blijft er dan over...... draadloos!!

Maar hoe dit te realiseren?
Ik zat zelf te denken aan, 8 -3 kanaals ontvangers in een kastje te bouwen, elk met zijn eigen freqs, en een standaard 3 voudige controller (sleutelhangermoder) om te bouwen naar een mooi kastje, met grote knoppen erop!

Maar het is nogal omslachtig, aangezien er voor het brandalarm natuurlijk 8 lampjes op een meldkast moeten komen, om te laten zien waar brand is, en ook nog eens lampjes bij de dj-booth moet laten afgaan, hier is 1 voldoende.

Hier krijg ik geen oplossing voor, ook leek het mij makkelijk, om bij de waarschuwingsknoppen een lampje in te bouwen, zodat ze kunnen zien dat ze daarwerkelijk een signaal gegeven hebben.
Dit is te realiseren d.m.v. relais en een extra knop om de lampjes daarna weer uit te zetten.


Wat is nu mij vraag??

Is dit echt de beste manier, en zo ja, wat zouden de beste zender ontvanger combo's zijn?
De 433/434 MHz van conrad? X10? of toch iets anders?
Deze ontvangers gaan problemen geven met het feit dat elk brandalarm 1 lampje bij de dj's moet laten oplichten, het moeten beter en vrijer te programmeren ontvangers zijn.

Plus dan komt het volgende punt, hoe betrouwbaar is draadloos?
Ik heb thuis een x10 setje voor mijn verlichting, en heb hier eigenlijk nooit problemen mee, maar in zo'n grote zaak.
het langste wat te overbruggen is, is een meter of 35, zal het signaal storingen ondervinden van bijv. stroboscopen?

Ook is het belangrijk dat er bij de locaties een goeie schakelkast komt, een sleutelhanger ab van conrad is binnen de kortste keren weg!


Zijn er evt. oplossingen voor dit probleem bedacht (ik kan niets nuttigs vinden op internet)


Als er echt geen mogelijkheid is, dit draadloos te realiseren, word er toch overgegaan op een bedraad systeem, alleen de kosten die daar mee gemoeid zijn, worden erg hoog, je kan in een chique nette disco niet een kabeltje over de muur of het plafond laten lopen.
Er zal gebroken, gezaagd en gesloopt moeten worden.

Maar goed... vandaar... iemand tips?

thnx

[ Voor 3% gewijzigd door Redwood op 01-11-2005 00:10 ]

[Sine]

De vraag is of je dit zelf MAG klussen ..

zeker bij het brandmeld gedeelte vraag ik me dat af, normaal wordt dat bijvoorbeeld zelfs met brandvertragende bekabeling uitgevoerd.

En of dat draadloos mag is nog zo'n vraag, lijkt me onwaarschijnlijk bij een brandmeld installatie.

[ Voor 23% gewijzigd door Sine op 01-11-2005 00:39 ]

[j-a-s-p-e-r]

Ik betwijfel of je er inderdaad zelf mee bezig mag, en of je het uberhaupt WILT. Stel dat er nu brand uitbreekt, en er blijkt een melder niet te werken? Wat dan? Denk eens in hoe je je dan voelt.
En trouwens, brandmelders zijn vaak automatisch, dus zonder knopje, maar gewoon optisch of mechanisch. Lijkt me ook wel een stukje veiliger dan nog een factor mens erbij betrekken.

Anyway, draadloze toepassing wordt wel gebruikt om optische brandmelders aan elkaar te koppelen voor een algemeen alarm. Dat is bijvoorbeeld in studentenhuizen, enz vaak het geval (ook verplicht) maar dat is absoluut geen zelfbouw.

Ik bedoel dit trouwens absoluut niet bemoederend ofzo, maar komop, het gaat zelfs om een bedrijf. Die gaat echt niet failliet van het aanschaffen van een degelijk brandmeldingssysteem. Gewoon kopen dus volgens mij.

[Brede P]

Denk niet dat de overheidsinstanties het erg op prijs zullen stellen als je hier zelf mee gaat lopen knutselen. Stap over je tweaker-eer heen, en haal er een installatiebureau bij.
Over het kabeltrek gebeuren, je kan altijd nog een nette leiding leggen, of er desnoods eentje de wand in laten frezen ofzo.

[JvW]

Er zijn zeer strikte regels voor dergelijke installaties. Ze mogen alleen aangelegd worden door daarvoor erkende bedrijven welke gecertificeerde installaties afleveren. En daarbovenop zal de brandweer e.e.a. al dan niet regelmatig inspecteren.

Draadloos lijkt me geen optie wegens groter risico van technisch falen.

Als je dit uitbesteedt hoef je je ook geen zorgen te maken over de problemen bij inbouw wat betreft kabels etc.

[D-Three]

Is een bussysteem geen optie? Ik heb jaren geleden eens meegewerkt aan iets gelijkaardigs in mijn vroegere school. Een kabel die door het volledige gebouw liep en daarop waren alarmknoppen, LCD-display, verwarming, schoolbel, sirene, enz.. aangesloten. Het systeem zelf vond ik niet zo goed aangezien het moest bestuurd worden via een PC-kaart en een zelfgeschreven programma. Stel dat de elektriciteit uitvalt, dan kan de PC nog weinig doen. Het bussysteem zelf, werkte op batterijen die automatisch werden opgeladen. Als ik het mij goed herinner tenminste want het is al enkele jaren geleden

edit:
Nu herinner ik mij wel dat er ook nog een controle-unit was die ook op batterijen werkte en dus ook bij uitval van elektriciteit nog een alarm kon registreren en sirenes kon inschakelen.
Voor zover ik weet was installatie van een bevoegde instantie niet nodig aangezien het alarmsysteem niet automatisch de politie of de brandweer belde. Ik denk wel dat er een controle is geweest van de brandweer.

[ Voor 71% gewijzigd door D-Three op 01-11-2005 01:40 ]

[Verwijderd]

MediJack schreef op dinsdag 01 november 2005 @ 01:25:
Er zijn zeer strikte regels voor dergelijke installaties. Ze mogen alleen aangelegd worden door daarvoor erkende bedrijven welke gecertificeerde installaties afleveren. En daarbovenop zal de brandweer e.e.a. al dan niet regelmatig inspecteren.

Draadloos lijkt me geen optie wegens groter risico van technisch falen.

Als je dit uitbesteedt hoef je je ook geen zorgen te maken over de problemen bij inbouw wat betreft kabels etc.

[Jfwiet]

Op het punt, brandveiligheid zal je denk ik niet kunnen besparen, het interne systeem voor de beveiliging daar kan je dan je geld uitsparen. En aangezien er toch een installatiebureau zal komen voor de brandveiligheid kan je waarschijnlijk wel een paar extra draden mee laten lopen.

Ik weet natuurlijk niet wat voor cafe/discotheek het is, maar een alarmknop bij de bar is meestal iets wat wel eens ingedrukt word, ff snel de cola bijvullen en je gooit zo een krat tegen een knop. En dan krijg je al heel snel dat verhaal van de schaapsherder en de wolf. Als er gewerkt word met barmanagers dan misschien die persoon de alarmknop meegeven (jouw draadloze idee)?

[Redwood]

even een aantal zaken ophelderen!

het systeem zelf klussen???
ja dit mag ik doen.
Ik ben de electroman bij een gecertificeerd bedrijf, ik maak voor de lokale brandweer regelmatig meld systemen.

Draadloos mag dit?
Ja, de brandweer vind dit geen enkel probleem, sterker nog, die houden niet van bekabeling, er bestaat trouwens geen brandvrije bekabeling, alleen brandvertraagde, over het algemeen 30 a 60 minuten, maar dit is onder bepaalde omstandigheden, en bij een bepaalde brand, voor hetzelfde geld is het 3 seconden voordat de bekabeling doorfikt!


brandmelders??
Nee, een brandmeldings/alarmerings installatie werkt op basis van manuele controle,dat is de bedoeling hiervan, puur omdat brandmelders het in horecagelegenheden NIET goed werken.

De desbetreffende zaak voldoet op dit moment ver BOVEN de huidige eisen, 2 maal de verplichte noodverlichting, extra nooduitgangen, voor veel situaties een rampenplan, zelfs zonder dit systeem is de brandvergunning geen probleem, maar de gemeente heeft het als eis, dus vandaar!

Begrijp mij goed, draadloos is niet om kosten te besparen, maar gewoon omdat het echt onmogelijk is, om door de hele zaak te gaan bekabelen, dit is echt goed overwogen!


Zijn weinig installatiebedrijven die het net zo goed als mij aan kunnen leggen, ik doe het ook niet low budget, het gaat er gewoon om of een draadloos systeem mogelijk is?

Er zijn weinig bedrijven hierin gespecialiseerd, en al zeker niet in draadloos, vandaar dak als tweakert toch ff ga kijken naar de mogelijkheden, ik vertel de dixo liever niet dat het toch kabeltjes trekken word!

,

[Redwood]

Jfwiet schreef op dinsdag 01 november 2005 @ 09:03:
Op het punt, brandveiligheid zal je denk ik niet kunnen besparen, het interne systeem voor de beveiliging daar kan je dan je geld uitsparen. En aangezien er toch een installatiebureau zal komen voor de brandveiligheid kan je waarschijnlijk wel een paar extra draden mee laten lopen.

Ik weet natuurlijk niet wat voor cafe/discotheek het is, maar een alarmknop bij de bar is meestal iets wat wel eens ingedrukt word, ff snel de cola bijvullen en je gooit zo een krat tegen een knop. En dan krijg je al heel snel dat verhaal van de schaapsherder en de wolf. Als er gewerkt word met barmanagers dan misschien die persoon de alarmknop meegeven (jouw draadloze idee)?

Nee, daarom worden het knoppen die je echt in moet drukken, ronde signaal knoppen, al ga je daar tegenaan staan, er gebeurt niks, ze moeten echt ingedrukt worden, ook komen ze niet op posities waar je snel tegenaan loopt, hierin zie ik totaal geen problemen!

Met draadloze kleine afstandbedieningen, is het probleem oa. vocht, barkeepers willen nog wel eens nat worden bij het glazenspoelen, en zo'n klein dingetje verlies je natuurlijk!
Het moeten (ook van de brandweer) vaste knoppen bij een lokatie zijn!
(maar toch goed dat je meedenkt, )

[naftebakje]

Voor mij is het (als graduaat en bijna ingenieur electronica) redelijk duidelijk: ofwel koop je ergens een draadloos systeem aan met garanties (dat bijvoorbeeld niet op de 2.4GHz band zit waar de magnetron en wlan en dergelijke volop storen), wat een redelijke som zal kosten, en misschien worden er dan ook door dat bedrijf erg strenge eisen gesteld;
Ofwel maak je gebruik van draden, eventueel redundant opgelost, en ik zou er een RS-845 bus (of iets vergelijkbaars) voor gebruiken. Dan kan je elke µP die een UART heeft gebruiken, elke locatie heeft een eigen µP die knopjes/lampjes regelt, en bij de security zelf zet je de master, die constant de knoppen/lampjes afloopt via de bus. Wanneer een locatie niet meer reageert, door draadbreuk of dergerlijke, kan je dat ook op een extra manier aanduiden, waardoor je steeds zekerheid hebt of alles werkt. Zo heb je maar 2 draadjes +massa nodig om een erg robuust systeem te maken.

(ben je trouwens in staat om µP te programmeren? Want als je alles met relais wil oplossen heb je idd enorm veel onnodige kabel nodig, terwijl je met µP een mooier systeem kan maken.

[ Voor 15% gewijzigd door naftebakje op 01-11-2005 10:06 ]

[Verwijderd]

Goed, opzich is draadloos natuurlijk een hele goede optie, maar er zullen aardig wat storingsfactoren zijn... (licht, mobiele telefoons, wlan's in de buurt, etc.)
je zult goed moeten zoeken welke frequenties die dingen allemaal hebben, en als je daar een aardig einde uit de buurt zit is het wel mogelijk.

toevallig maak ik nu met mijn studie een soortgelijk alarm systeem, een stuk kleiner alleen, maar dezelfde basis.
je zult eerst goed moeten uitzoeken of draadloos wel een optie is, en op welke frequenties er al protecollen overgestuurd worden.hierna kun je je eigen frequentie wel maken en daar ook wel een eigen protecol voor bedenken.
een zender en een ontvangertje in elkaar zetten / programmeren moet dan ook geen probleem meer zijn...
het grootste punt is dus die juiste frequentie en ruis en verlies van het signaal van de 1ste naar de kelder.

[Sprite_tm]

En als je het systeem nou eens via bestaande bekabeling laat lopen? Zit er toevallig andere bekabeling in de buurt van alle punten? Stopcontacten, Ethernet, telefoonaansluitingen, ...?

[Jgsvuden]

Sprite_tm schreef op dinsdag 01 november 2005 @ 10:59:
En als je het systeem nou eens via bestaande bekabeling laat lopen? Zit er toevallig andere bekabeling in de buurt van alle punten? Stopcontacten, Ethernet, telefoonaansluitingen, ...?

ja zat ik ook net aan te denken, wij hebben hier namelijk op de TU een ogo project om gegevens via het lichtnet door te geven...

[Redwood]

telefoonlijnen niet, utp geld hetzelfde.

Via het lichtnet, tja... wat ik mij kan herrinneren van dat soort systemen van een paar jaar geleden, is dat het dan op de zelfde groep moest zitten, dit is denk ik nog net zo?
Dan werkt het alweer niet, elke bar heeft sowieso meerdere eigen groepen.
Of maak ik nu een denkfout?

Wat betreft µP en UART, ik weet wat het is, maar heb er weinig kaas van gegeten.
Gewoon simpelweg geen ervaring mee.

Tja helaas.... ik denk toch dat ik moet melden om met bekabeling te gaan werken.
Ik ga mij dan wel eerst verdiepen in µP en UART, dit is toch wel erg functioneel!!

[joca]

Verwijderd schreef op dinsdag 01 november 2005 @ 10:25:
Goed, opzich is draadloos natuurlijk een hele goede optie, maar er zullen aardig wat storingsfactoren zijn... (licht, mobiele telefoons, wlan's in de buurt, etc.)
je zult goed moeten zoeken welke frequenties die dingen allemaal hebben, en als je daar een aardig einde uit de buurt zit is het wel mogelijk.

toevallig maak ik nu met mijn studie een soortgelijk alarm systeem, een stuk kleiner alleen, maar dezelfde basis.
je zult eerst goed moeten uitzoeken of draadloos wel een optie is, en op welke frequenties er al protecollen overgestuurd worden.hierna kun je je eigen frequentie wel maken en daar ook wel een eigen protecol voor bedenken.
een zender en een ontvangertje in elkaar zetten / programmeren moet dan ook geen probleem meer zijn...
het grootste punt is dus die juiste frequentie en ruis en verlies van het signaal van de 1ste naar de kelder.

Je eigen frequenties? Je zit gewoon vast aan een aantal banden hoor, tenminste als je het legaal wilt houden..
Het lijkt me zowiezo handig om kant en klare modules te kopen, dan hoef je je namelijk niet te wagen aan een antenne design oid.


Communicatie over het lichtnet is wel het betrouywbaarst als je onderdelen op 1 groep zitten. Maar je zou idd wat met dat X10 kunnen proberen.

Welke optie je ook kiest, ik zou iig het geheel uittesten voordat je het implementeerd in de discotheek op een drukke avond. Dan zijn namelijk alle storingsbronnen aanwezig.

[naftebakje]

redwood schreef op dinsdag 01 november 2005 @ 11:39:
...
Wat betreft µP en UART, ik weet wat het is, maar heb er weinig kaas van gegeten.
Gewoon simpelweg geen ervaring mee.

Tja helaas.... ik denk toch dat ik moet melden om met bekabeling te gaan werken.
Ik ga mij dan wel eerst verdiepen in µP en UART, dit is toch wel erg functioneel!!

Je kan eens de PIC tutorial lezen op http://www.circuitsonline.net/artikelen/view.php?id=8, samen met de datasheet van een PIC heb ik zo mezelf PICs leren programmeren, en zo mijn eindwerk gemaakt (volledig computergestuurd meettoestel, 16 keer geschakelde voeding + instelbare belasting + specifiek communicatieprotocol waarmee in 10 minuten gemeten wordt waar manueel weer dan een uur werk aan is), jou project zal heel wat eenvoudiger zijn om te programmeren, dus dat jezelf aanleren moet zeker lukken.
Voorts lijkt het me dat je niet echt zonder µP kan, om je datastroom in goeie banen te leiden.

[Sine]

redwood schreef op dinsdag 01 november 2005 @ 09:50:
er bestaat trouwens geen brandvrije bekabeling, alleen brandvertraagde,

Sine schreef op dinsdag 01 november 2005 @ 00:38:
De vraag is of je dit zelf MAG klussen ..

zeker bij het brandmeld gedeelte vraag ik me dat af, normaal wordt dat bijvoorbeeld zelfs met brandvertragende bekabeling uitgevoerd.

[naftebakje]

Op de site van Microchip zelf (de producent van PIC's) vind je heel wat development kits, ik heb oorspronkelijk zelf een testprintje gemaakt en met de MPLAB ICD 2 MODULE de PIC steeds geprogrammeerd (kan ook in het circuit zelf programmeren), die voldoet zeker voor je toepassing, maar om de geschakelde voeding te maken heb ik een wat krachtiger tool gebruikt, een emulator van 2.500€ (héél handig en krachtig, ws iets te duur voor je, mijn eindwerk koppelde toestellen van 62.500€ dus die prijs hadden ze er zo uit). Ik heb ook de PICkit 1 (die net onder de ICD 2 staat op de 1e link) gekregen, daar kunnen alleen wat kleinere PIC's in, maar die kunnen ws wel voldoen voor je toepassing, die is ook wat goedkoper dan de ICD 2 (en kan toch via USB programmeren en gevoed worden).

Ook velleman heeft development boards: http://www.voti.nl/winkel/catalog.html?K-K8048 (je hebt wel een seriele poort nodig), en als je wat zoekt vind je nog heel wat leveranciers die bordjes hebben.

Ten derde kan je ook de schema's gebruiken die op internet ronddwalen, bijvoorbeeld op circuitsonline. Deze schema's zijn echter allemaal met de seriele poort, en kunnen (bijvoorbeeld met laptops) niet goed werken.

Ik persoonlijk zou zelf een printplaatje maken, eerst op zo'n gaatjesprint om te testen, en dan met de ICD 2 programmeren (met een gewone RJ45 connector op je printje kan je de bijgeleverde kabel gebruiken), als dat niet te duur is (133€). Anders kan je eens kijken naar de PICkit 2 Microcontroller Programmer, die kost maar 30€, op internet zal je wel voldoende ervaringen vinden om te weten of die voldoet.

Overigens bestaan er nog andere µP families dan PIC's, bijvoorbeeld AVR's, maar daar ken ik niet genoeg van om mij erover uit te spreken.

Over UART's: in bijna elke µP zit een UART ingebouwd, omdat deze communicatie zo eenvoudig maakt. Dit is eigenlijk een basic seriele poort, 1 pin voor data uit, en 1 voor data in. Deze kan je rechtstreeks doorverbinden naar de seriele poort van je pc, en zo communiceren met je µP. In je programma van de PIC maak je je instellingen, en dan kan je om iets te verzenden de data gewoon verplaatsen, en de UART handelt alles af (parallel naar serieel, BAUD rate,...).
In jou toepassing zou ik de PIC die het meldpaneel aanstuurd (deze PIC moet krachtiger zijn dan deze bij de knoppen) master laten zijn, en dus constant de ene na de andere "kleine" PIC vragen naar zijn status, waarna hij dan de status ontvangt. Elektrisch kan je best een RS-845485 bus gebruiken, deze is gemaakt om op lange afstanden storingsvrij te werken, maar heeft wel 2 draadparen nodig, die gewoon doorgelust mogen worden van de ene naar de andere PIC. Er bestaan specifieke IC's om deze omzetting te maken, als je het kan gebruiken post ik wel een schema. In mijn eindwerk hebben we dit gebruikt, om max 15 (adres was 4 bits, dus 2^4, adres nul als broadcast) PIC's aan elkaar door te koppelen, dit was ook nog eens aan een PC gekoppeld, en werkte perfect.

[ Voor 37% gewijzigd door naftebakje op 01-11-2005 21:24 ]

[Paul]

naftebakje schreef op dinsdag 01 november 2005 @ 20:24:
In jou toepassing zou ik de PIC die het meldpaneel aanstuurd (deze PIC moet krachtiger zijn dan deze bij de knoppen) master laten zijn, en dus constant de ene na de andere "kleine" PIC vragen naar zijn status, waarna hij dan de status ontvangt. Elektrisch kan je best een RS-845 bus gebruiken, deze is gemaakt om op lange afstanden storingsvrij te werken, maar heeft wel 2 draadparen nodig, die gewoon doorgelust mogen worden van de ene naar de andere PIC. Er bestaan specifieke IC's om deze omzetting te maken, als je het kan gebruiken post ik wel een schema.

Mits je rs485 bedoelt (op rs845 vind ik vrijwel niets electronica-gerelateerd ): Ook als Redwood er niets mee kan ben ik best geinteresseerd in het opzetten van een RS485-bus. Ik kan namelijk wel een hoop pagina's vinden die vertellen _dat_ je een RS485-bus kunt gebruiken, maar nergens _hoe_ Ja, wat weerstandsjes aan 1 kant en zo (termineren/dat hij niet gaat floaten), maar uit een uC komt echt geen -7 en +12, dus gewoon die lijntjes aan je pic knopen is geen strak plan

[naftebakje]

Paul Nieuwkamp schreef op dinsdag 01 november 2005 @ 21:18:
[...]

Mits je rs485 bedoelt (op rs845 vind ik vrijwel niets electronica-gerelateerd ): Ook als Redwood er niets mee kan ben ik best geinteresseerd in het opzetten van een RS485-bus. Ik kan namelijk wel een hoop pagina's vinden die vertellen _dat_ je een RS485-bus kunt gebruiken, maar nergens _hoe_ Ja, wat weerstandsjes aan 1 kant en zo (termineren/dat hij niet gaat floaten), maar uit een uC komt echt geen -7 en +12, dus gewoon die lijntjes aan je pic knopen is geen strak plan

Idd RS485, typo. Je hebt een convertorchip nodig, ik heb de MAX489 gebruikt, deze bevat een zender ne een ontvanger en kan met TTL signalen aangestuurd worden. Ik weet niet waar jij je -7 en +12V vandaan haalt, maar er wordt gebruikt gemaakt van 2 differentiele paren, een voor zenden (Y en Z) en een voor ontvangen (A en B ), en vanaf 200mV verschil tussen de 2 draden van een paar wordt een '1' of '0' gedetecteerd, 5V en 0V voldoen dus.
Dit is het schema wat ik gebruikt heb, de verticale lijnen met blokje boven en onder (die 2 RJ45 connectoren voorstellen) zijn de bus zelf, rechts ervan de omzetting naar een seriele poort (connectie naar PC, kan evt weggelaten worden als je alleen tussen PIC's "praat") en links de connectie naar de µP, VCC is 5V, TX enable mag altijd aanliggen dacht ik.
Door het linkse stuk van de schakeling bij elke µP te zetten, en gewoon door te lussen (ik gebruikte netwerkkabels omdat die standaard zijn) heb je je bussysteem, er zijn 2 connectors voorzien om dit doorlussen te vergemakkelijken, je kan natuurlijk alles wat je wil hiervoor gebruiken, zolang het maar 2 getwiste paren zijn, voor TS kan het mss gemakkelijk zijn om via netwerkkabel meteen de kastjes met knoppen te voeden, bijvoorbeeld met 10V en elke knoppenkast een 7805 geven.

Collisions moet je in je software oplossen, in mijn geval is de PC master, en zijn de PIC's slaves, elke PIC kreeg met DIPswitches een 4-bits adres. De slaves zenden maar iets wanneer ze op hun adres aangesproken zijn, daardoor kan je geen collisions hebben.

[ Voor 28% gewijzigd door naftebakje op 01-11-2005 22:03 ]

[Paul]

naftebakje schreef op dinsdag 01 november 2005 @ 21:47:
Ik weet niet waar jij je -7 en +12V vandaan haalt

Dat staat op bijna iedere pagina die over RS485 gaat, dat het tussen -7 en +12 werkt

(die 2 RJ45 connectoren voorstellen)

Wat doe jij met de niet gebruikte aders? Gebruik je die voor je common ground?
Ik was zelf van plan ze als voeding te gaan gebruiken (inderdaad ergens tussen 9 en 12v (9v trafo heb ik toevallig zat liggen, maar na gelijkrichten en een km kabel houd je dan misschien wat weinig over voor een 7805 ), de helft van een getwist aderpaar als + en de andere helft als GND.

Collisions moet je in je software oplossen, in mijn geval is de PC master, en zijn de PIC's slaves, elke PIC kreeg met DIPswitches een 4-bits adres. De slaves zenden maar iets wanneer ze op hun adres aangesproken zijn, daardoor kan je geen collisions hebben.

Die 15 adressen en een broadcast, dat is iets in software toch? RS-485 defineerd 32 load units en er zijn 1/8 drivers, dus binnen de standaard kun je al tot 256 transceivers.

"Termineer" jij je bus bij iedere node (wat dus bij 15 nodes tot een terminatie van 1K leidt, verspreid over de bus)?
Over de softwarekant: met dat schema kun je in de PIC exact hetzelfde doen als wat je bij een RS-232-verbinding zou doen (In assembler poortjes gaan bit-bangen of in een hogere taal e.o.a. SendByte aanroepen)?

Iig al voor het schema

[Nox]

redwood schreef op dinsdag 01 november 2005 @ 11:39:
telefoonlijnen niet, utp geld hetzelfde.

Via het lichtnet, tja... wat ik mij kan herrinneren van dat soort systemen van een paar jaar geleden, is dat het dan op de zelfde groep moest zitten, dit is denk ik nog net zo?
Dan werkt het alweer niet, elke bar heeft sowieso meerdere eigen groepen.
Of maak ik nu een denkfout?

Wat betreft µP en UART, ik weet wat het is, maar heb er weinig kaas van gegeten.
Gewoon simpelweg geen ervaring mee.

Tja helaas.... ik denk toch dat ik moet melden om met bekabeling te gaan werken.
Ik ga mij dan wel eerst verdiepen in µP en UART, dit is toch wel erg functioneel!!

niet via het lichtnet gaan !! als er sluiting is heb je een probleem denk ik, t zou iig niet egt goed kunnen zijn.

[naftebakje]

Paul Nieuwkamp schreef op dinsdag 01 november 2005 @ 22:32:
[...]
Dat staat op bijna iedere pagina die over RS485 gaat, dat het tussen -7 en +12 werkt

[...]
Wat doe jij met de niet gebruikte aders? Gebruik je die voor je common ground?
Ik was zelf van plan ze als voeding te gaan gebruiken (inderdaad ergens tussen 9 en 12v (9v trafo heb ik toevallig zat liggen, maar na gelijkrichten en een km kabel houd je dan misschien wat weinig over voor een 7805 ), de helft van een getwist aderpaar als + en de andere helft als GND.

[...]
Die 15 adressen en een broadcast, dat is iets in software toch? RS-485 defineerd 32 load units en er zijn 1/8 drivers, dus binnen de standaard kun je al tot 256 transceivers.

"Termineer" jij je bus bij iedere node (wat dus bij 15 nodes tot een terminatie van 1K leidt, verspreid over de bus)?
Over de softwarekant: met dat schema kun je in de PIC exact hetzelfde doen als wat je bij een RS-232-verbinding zou doen (In assembler poortjes gaan bit-bangen of in een hogere taal e.o.a. SendByte aanroepen)?

Iig al voor het schema

1) Common ground is niet nodig bij RS845, en kan storing veroorzaken (steekt rommel in de voeding van je PIC). Ik laat de niet gebruikte aders floaten om geen problemen te krijgen.
2) uit 9V AC haal je 12.7V DC, dat moet genoeg zijn. Om storingen tegen te houden (als je lange draden/storende omgevingen hebt) goed ontkoppelen, ook je massa. Waar je aders toekomen, een grote (10µF ofzo) en een kleine (100nF, tantalium, vraag je electroboer een ontstoorC) condensator tussen VCC en GND, en dan een weerstandje van 100 ohm in serie voor zowel je VCC als je GND. Dan je 7805 met zijn eigen Ctjes zoals normaal plaatsen. Zo zal er quasi geen storing doorkunnen, zolang je natuurlijk niet teveel stroom trekt.
3) Idd, dat is pure software. Je kan idd tot 255 eenheden plaatsen volgens de standaard, maar niets zegt dat het wel/niet werkt voor jou specifieke toepassing. Een broadcast (bijvoorbeeld adres 0) kan erg handig zijn, om een algemene reset te doen bijvoorbeeld. Ik verzend eerst een L (ASCII code voor letter L, gemakkelijk af te luisteren met hyperterminal), dan een byte die het totaal aantal bytes voorsteld (omdat de lengte variabel is in mijn toepassing), dan een A (adres), dan een byte voor het adres, en dan de daadwerkelijke data (vooral instructies, dus ook steeds met een lettertje).
Daardoor zal ook storing nooit tot fouten leiden, aangezien alle data die niet L is verworpen wordt.
4) Weerstand op de bus. Dit is nattevingerwerk, gecombineerd met ervaring van mijn eindwerkbedrijf. Zij hebben het schema hierboven gegeven, en werkt zeker perfect in elke toepassing die ze al gebruikt hebben. Ze gebruiken geen afsluitweerstanden (mss kan dit enkel bij het gebruik van de MAX 489 converterchip), en een weerstand van 15K naar +5V en 10K naar de GND in elke node. Ik heb niet getest welke invloed dat heeft bij 15 gekoppelde toestellen, ik heb er alle vertrouwen in dat het perfect zal werken. Als je liever conform de standaard werkt (begin en einde met 120 ohm afsluiten, 1* 470 ohm op A naar +5V, 1* 470 ohm op B naar GND), doe dit dan gerust, maar je bus is dan moeilijker aan te passen (neem de module met een afsluitweerstand weg, en je kan problemen hebben).
5) De softwarekant: op de bus doe je wat je wil. Er is geen protocol gespecificeerd, je mag kiezen. Logisch is natuurlijk de RS232 standaard volgen, dus gewoon via de UART zoals je zegt zal perfect werken en wordt ook bijna altijd gedaan. Als je liever per 27 bits je data verzend, ga gerust je gang, maar dan moet je het zelf maar weten als je er niet uit geraakt

[ Voor 8% gewijzigd door naftebakje op 01-11-2005 23:23 ]

[Paul]

naftebakje schreef op dinsdag 01 november 2005 @ 23:14:
1) Common ground is niet nodig bij RS845, en kan storing veroorzaken (steekt rommel in de voeding van je PIC).

http://www.circuitcellar....ure/perrin0799/c79bp4.htm

Ik laat de niet gebruikte aders floaten om geen problemen te krijgen.

Zelfde site:

The last subject related to termination is what to do with unused conductors in a data cable. Unused conductors will self-resonate and couple noise into the data wires. If the unused cables are left open, they will resonate at all sorts of strange frequencies. If they are grounded at one end, they will resonate at L/2. If they are grounded at both ends, they resonate at L/4.

The best method for minimizing energy on an unused conductor is to dissipate the energy as heat. In short, terminate both ends of the unused conductor to ground with resistors (a bidirectional termination). The resistors should be equal to the characteristic impedance of the line.

Ze gebruiken geen afsluitweerstanden

Dat schijnt de max-kabellengte fors te benadelen?

1* 470 ohm op A naar +5V, 1* 470 ohm op B naar GND)

Dat doe je in dat schema dus met 10k en 15k ipv een halve?

doe dit dan gerust, maar je bus is dan moeilijker aan te passen (neem de module met een afsluitweerstand weg, en je kan problemen hebben).

Bus lastig aanpassen? RJ45-Plugje met afsluitweerstanden dmv koppelblokje op de inbound utp steken, of bij uitbreiding verplaatsen naar wat dan het einde van de rij is

[icegodd]

is niet new. horecabedrijf waar ik nu werk heeft het al. is al 3 keer toegepast bij andere partyhome

tis wel lullig als je per ongeluk op rood drukt. dan komt 3 security naar je toe rennen. en hun loopt iedereen omver

[Redwood]

wel nieuw dat het verplicht is ;-)

Maar goed, ben nu in ieder geval aan het kijken naar microp. oplossingen!
Ik hou jullie hier op de hoogte.

[teun-v]

Mischien ook intresant om eens te kijken naar een LON (Local Operating Network) te kijken. Hier mee kun je een embedded bus oplosing maken dat over verschillende mediums wil werken. Dit wordt veel gebruikt in gebouw beheer. Ik zeg er wel bij dat het vrij prijzigis maar biedt wel mogelijkheden bij een brand of iets anders waardoor het systeem uit zou kunnen vallen toch een alarm te geven op diverse punten waar dit nodig is. Kijk voor meer info bij Echelon en Google

[naftebakje]

@ Paul Nieuwkamp: Zoals al gezegd, het is een aanpassing, dus niet conform de RS845 standaard. Jij doet wat je wil. Met de 15K en 10K (idd in plaats van een halve) heb ik tussen 2 modules met 5 meter UTP kabel niets van rommel gezien op de bus, ik heb het nagemeten met een goeie netjes gecalibreerde scoop, en de blokgolf was perfect (voor zover meetbaar). Dat zegt uiteraard niets over jou toepassing, maar even 2 weerstandjes vervangen lijkt me niet zo'n werk (indien je problemen zou krijgen).

Over grounding kan ik kort zijn: in mijn toepassing was de massa = de aarding, en zou een verbinding via de UTPkabel een aardlus genereren, wat zeker voor problemen kan zorgen. Overigens zullen mijn toestellen altijd binnen 1 gebouw gebruikt worden, dus zal het potentiaal van de aarding altijd gelijk zijn. Voor de werking van de RS485 connectie is er geen massaverbinding nodig, ff quoten uit mijn documentatie: "De RS-485 specificatie raad een 100 ohm weestand (0.5 W) aan in serie met de massa bij iedere knoop in het netwerk. Indien de spanning van de massa op twee knopen verschilt dan zullen de weerstanden de stroom beperken." Niet verplicht dus, maar als je dat doet moet je echt wel die weerstand van 100 ohm zetten, dat zal je veel problemen besparen.

@ redwood: veel succes, en welkom in de wondere wereld van de µP. Laat je niet van de wijs brengen van mijn lappen tekst, met wat inzet zal het je wel lukken. Mijn woord is ook zeker niet wet, kijk gerust naar wat anderen zeggen, maar ik denk dat een µP per locatie, en een RS485 netwerk de beste oplossing is.

@ teun-v: TS kan natuurlijk ook op elke locatie een itanium bak zetten, met redundante voeding en UPS en alles erop en eraan, en daarmee een netwerkje aanleggen, maar in mijn ogen is dat een klein beetje overkill Zo'n LON kan meteen ook videobeelden streamen en dergerlijke , dan hou ik het liever behapbaar, aanpasbaar en daardoor waarschijnlijk voor TS' toepassing krachtiger.
LON kan idd als er problemen zijn toch alarm geven, indien je dit insteld.
Eenmaal TS op weg is met zijn code, zal hem snel duidelijk worden dat elke knoppen- (en evt. lampen-) locatie een µP moet hebben, verbonden met de bus, met een eigen uniek adres op de bus. De software mag maar reageren wanneer er een vraag wordt gesteld aan zijn adres, deze kan erg gemakkelijk bijhouden of er al dan niet communicatie passeert. Zo niet kan er direct een ledje ingeschakeld worden (no connect) dat een probleem aanduidt. Het controlepaneel bij de security, dat aanduid op welke locatie er op een knop is gedrukt, zal constant alle locaties aanspreken, om te weten of er op een knop gedrukt is. Voor TS zal het ook erg snel duidelijk zijn dat het antwoord "ja, op knop X gedrukt" of "nee, niet op knoppen gedrukt" moet zijn, aldus weet het controlepaneel dat als er geen antwoord komt, er een probleem is met die module, en dit kan dan ook op de nodige wijze vermeld worden.
De TS kan dan zelf volledig kiezen hoe er op zulke situaties wordt gereageerd (bijvoorbeeld security laten checken of er iets mis is, eventueel persoon plaatsen op locatie waar de knoppen niet meer werken,...), naargelang de eigen wensen (en die van brandweer/gemeentebestuur).

[ Voor 5% gewijzigd door naftebakje op 02-11-2005 17:47 ]

[teun-v]

naftebakje schreef op woensdag 02 november 2005 @ 17:42:
(...)

@ teun-v: TS kan natuurlijk ook op elke locatie een itanium bak zetten, met redundante voeding en UPS en alles erop en eraan, en daarmee een netwerkje aanleggen, maar in mijn ogen is dat een klein beetje overkill

Zou je kunnen doen.

Zo'n LON kan meteen ook videobeelden streamen en dergerlijke , dan hou ik het liever behapbaar, aanpasbaar en daardoor waarschijnlijk voor TS' toepassing krachtiger.
LON kan idd als er problemen zijn toch alarm geven, indien je dit insteld.

De snelhijd van lon zou inderdaat een streem toelaten met 1.25 Mbps op een twisted pair. Maar aangezien CCTV meer als maar 1 stream inhoud en er geen device te vinden is die dit doet lijkt mij het alsnog vrij onmogelijk. Over behapbaar en aanpasbaar, het aanpassen van een lon netwerk door er een device aan toe tevoegen is een questie van het aan maaken van een nieuw device en de juiste lijtjes verbinden in een MS Visio tekening te tekenen. Dit zelve geld ook voor bestaande devices. Om nou gelijk een baterij aan µP opnieuw te flashen om een extra waarde uit te lezen kan een best klusje zijn volgens mij.

Eenmaal TS op weg is met zijn code, zal hem snel duidelijk worden dat elke knoppen- (en evt. lampen-) locatie een µP moet hebben, verbonden met de bus, met een eigen uniek adres op de bus.

De TS heeft aangegeven dat aanlegen van kabel eventueel probleematich is.
hier een lijstje van eventuele mogelijkheden

• Twisted pair
• Power line (powered or unpowered)
• Radio frequency
• Coaxial cabling
• Fiber optics

De software mag maar reageren wanneer er een vraag wordt gesteld aan zijn adres, deze kan erg gemakkelijk bijhouden of er al dan niet communicatie passeert. Zo niet kan er direct een ledje ingeschakeld worden (no connect) dat een probleem aanduidt. Het controlepaneel bij de security, dat aanduid op welke locatie er op een knop is gedrukt, zal constant alle locaties aanspreken, om te weten of er op een knop gedrukt is. Voor TS zal het ook erg snel duidelijk zijn dat het antwoord "ja, op knop X gedrukt" of "nee, niet op knoppen gedrukt" moet zijn, aldus weet het controlepaneel dat als er geen antwoord komt, er een probleem is met die module, en dit kan dan ook op de nodige wijze vermeld worden.

Dit valt uiteraard met ieder te bedenken oplosing zo te maken als je zou willen

(...)

Tot slot heeft de TS ook aangegeven niet goed thuis te zijn in µP. Nu wil ik niet beweren dat hij dat is in lon, Maar wil alleen maar aangeven dat dit eventueel een mogelijk zou kunnen zijn. Zeker als het om veiligheid gaat en dus uitval eigenlijk niet getolereerd zou zijn.