High-tech fietsverlichting

[mux]

Inleiding

Ik ben de afgelopen tijd ontzettend aan het knoeien geweest met fietsverlichting. Klassieke verlichting voldeed niet, dus toen ik verlichting moest toevoegen aan mijn twee ligfietsen begon ik al met LEDs (met voorschakelweerstand), die aan een 7805 hingen, welke op zich weer aan een grote accu hing. Je raadt het al, dit was heftig inefficient en ik kreeg ook te weinig batterijtijd uit mijn licht. De eerste extra feature die er dus op werd gebouwd was een dimlicht (grotere voorschakelweerstand).

Toen besloot ik dat ik meer licht nodig had. Ik werkte tot dan toe met 30lm 1W LEDs, en die geven op zich genoeg licht om gezien te wórden, maar niet om zelf te zien. Ik maakte de upgrade naar een 4W voorlicht maar dat ging never nooit niet met voorschakelweerstand werken. Met een Attiny13V microcontroller en wat knutselwerk heb ik toen een buck-converter in elkaar gezet die dat licht voedt.

Dit is echter niet genoeg. Ik kan met mijn huidige systeem mijn licht maar op twee standen zetten: superhoog en superlaag. Bovendien moet ik het zelf aan- en uitzetten, en heb ik geen indicatie van de batterijtijd. Er loopt verder een grote kabelbende over mijn fietsen, ook erg onwenselijk. Als laatste is 4W (~200lm) nog steeds niet genoeg licht, ik wil MEER!!!

Verder heb ik al meermalen ge-experimenteerd met een zelfbouw-fietscomputer. Touchscreens, hardwired stroommeters, thermometers, accelerometers en natuurlijk standaard fietscomputerfuncties zijn allemaal de revue gepasseerd. Echter, het bleef altijd een beetje bij simpele experimenten want zodra ik de functies wilde integreren op mijn fiets moest ik weer een dikke kabel leggen en rekening houden met alle verschillende spanningen die nodig waren op verschillende plekken. Het werd een zootje.

De Eisen

Het is duidelijk dat ik meerdere verschillende soorten apparaten op mijn fiets wil zetten. De eerste, belangrijkste en bovendien wettelijk verplichte functie die dat moet gaan verrichten is verlichting. Vandaar de naam van dit topic. Echter, later wordt dit met allerlei andere apparaten uitgebreid.

Verschillende apparaten op de fiets moeten onafhankelijke modules zijn, elk met hun eigen batterij en welke communicatie er ook moet gebeuren: deze moet draadloos. Dat geeft ons een mooi beginpunt om tot een ontwerp te komen.

Gezien batterijen gebruikt worden willen we hier maximale batterijtijd uit halen. Voor de verlichting betekent dit een buck/boost/buckboost-converter om stroom te leveren aan de LED-lampen. Draadloze communicatie is ook een beruchte energieslurper, dus dat moet ook zo zuinig mogelijk. Het geheel moet op één 18650-formaat Li-ion accu kunnen lopen (of evt. meerdere in parallel, niet serie ivm balancing-problemen). De zwaarste lamp die ik erop wil kunnen zetten is een 10W LED.

Gezien de complexiteit van elke node moet er een microcontroller op (die dan gelijk als PWM controller en communicatiehub kan dienen). Hier zijn de eisen ook redelijk restrictief: enkel platforms waar ik ervaring mee heb, en dan een zo goedkoop mogelijke versie. Ik heb ervaring met Atmel AVRs, NXP LPC-serie MCUs (ARM7/9 en Cortex), TI TMS320 en uiteraard 8051.

Samengevat:
- Draadloos netwerk
- Op zichzelf staande apparaten die aan een netwerk kunnen worden toegevoegd
- Eerste prioriteit: licht
- schakelende voeding, 10W
- low-power draadloos protocol
- AVR, LPC, TMS320 of 8051 microcontroller

Het Plan

In dit hoofdstukje komen concrete ideeën te staan voor de opbouw van een node in het bike area network. Ik zit te denken aan:

- Draadloze communicatie: ANT, dmv een Nordic Semiconductor nRF24AP1
- Buck-boostconverter:
Vi 3.3-4.25V
Vo 3-12V
Po: 10W bij elke situatie
- microcontroller: NXP LPC1311
- kleine 3.3V LDO voor de micro en wireless
- Temperatuursensor op de LEDs en elektronica (ntc/ptc)
- Stroommeting (mogelijk met INA213 versterker)
- true off-schakelaar (iets dat het stroomverbruik helemaal tot 0 laat gaan zodra de accu helemaal leeg is)

Bicycle Area Network

Eén licht maakt deel uit van een lokaal netwerk waarop zich op zijn minst één licht en een controller bevindt. Die controller kan zoiets simpels als een knop zijn (met microcontroller+wireless+batterij om de rest te instrueren aan te gaan) of zelfs helemaal passief - een lichtsensor en bewegingssensor. Maar elk mogelijk apparaat kan natuurlijk deel uitmaken van een BAN, denk bijvoorbeeld ook aan programmeerbare LED-strips in de wielen of een PDA/telefoonadapter.

Bottlenecks in het ontwerp

Dit gaat niet zomaar goed. Er zijn drie punten die dit een heel moeilijk project maken:

- Schakelende voedinkjes dichtbij een wireless interface, dit gaat hoopjes noise opleveren. Ik heb inmiddels wel wat ervaring met EMI-shielding en knap converterontwerp maar het blijft een heikel punt.
- Het risico dat de batterij leeg loopt doordat de elektronica nodeloos aanstaat
- Succesvolle, voldoende veilige implementatie van het BAN.

Wat het eerste punt betreft: dit is gewoon een situatie van de high-powerdelen zo goed mogelijk isoleren en ontkoppelen van het microcontroller- en RF-gedeelte. Dit zorgt er waarschijnlijk voor dat aan de voorkant van het licht alle power elektronica komt te zitten, en erachter, met een ground plane ertussen, alle microelektronica. Of zoiets.

Power savings zijn op zich niet zo moeilijk te implementeren, het moet alleen gedaan worden. Het licht staat bijvoorbeeld standaard op 1W aan (vrij fel). Wanneer een flinke beam nodig is druk je een knop in die ervoor zorgt dat de lamp op 10W wordt geregeld, maar dit valt automatisch (na 10s ofzo) weer terug naar 1W. Wanneer de batterij op 20% staat - ik noem maar wat - wordt de lamp steeds meer teruggeregeld tot hij op 50mW zit en de batterij definitief leeg is. Ondertussen stuurt hij eens in de zoveel tijd eens een pakketje richting de controller met 'hoi, ik ben bijna leeg, help mij!'. Zodra de batterij echt definitief leeg is schakelt hij zichzelf onherroepelijk uit.

Ondertussen moet de controller er ook voor zorgen dat het licht uit wordt gezet wanneer het niet nodig is. Een LDR en bewegingssensor bekijken continu of er licht moet worden gemaakt. Zolang dat niet nodig is gaan zowel controller als alle lichten in sleep-modus, waarbij ze elke seconde (bijvoorbeeld) wakker worden om te kijken of iemand wat zegt, na een tijdje elke vijf seconde en uiteindelijk elke 30 seconden. Uiteraard komt hier ook een hardware interrupt op waardoor je met een knop de hardware aan kunt forceren. Met Zigbee of Bluetooth kan op die manier een licht maandenlang meegaan op de batterij.

Als laatste het bike area network... Dat is wat lastiger. Nordic semiconductor heeft veruit het grootste deel van dit spul voor zijn rekening genomen door de ANT stack in een chip in te bouwen. Je hoeft dan alleen nog een paar kleine configuraties uit te voeren en je kunt redelijk snel aan de slag. Hetzelfde geldt voor veel bluetooth-adapters maar... bluetooth is een stuk minder zuinig en kan bovendien enkel point-to-point communiceren, niet in een netwerk. ZigBee is hier ook een mogelijkheid, maar die heeft volgens mij meer software nodig. Dat kan problemen veroorzaken met het beperkte RAM in goedkope microcontrollers.

Ohja, en dan nog veiligheid. Atmel Zigbee-modules hebben ingebouwde encryptie en negotiation wat het heel aardig maakt. Toch zal hier nog wat verder over moeten worden nagedacht.

Maar nu...

Dit is allemaal slechts een concept. In mijn eentje is dit ook niet haalbaar, dus roep ik graag de hulp van anderen in. Wie vindt dit een leuk idee, wil meedenken en mee-ontwikkelen? Ik werk het liefst met de gratis en open-source programma's TinyCAD en FreePCB, en simuleer doorgaans in Matlab (simulink).

[ Voor 30% gewijzigd door mux op 23-04-2010 23:06 . Reden: TS wat uitgebreid ]

[Rmg]

Dit is al een goeie link voor je uC en netwerk stack

http://news.jeelabs.org/projects/

Open source en goedkope arduino based nodes met een RF12B based mesh network.

Dan heb je iig al een platform om je licht en sensoren aan te sturen

[mux]

Jeelink is alleen wel ontzettend onveilig en nonstandaard. Vergeet niet dat Zigbee en Bluetooth modules vaak niet alleen de hardware layer, maar ook de hele security, non-collision en negotiation rommel ingebouwd hebben zitten.

[Rmg]

Mja toen ik de el kroeg je linkje naar de zigbee transreceivers doorlas bedacht ik me het ook idd, zeker met de prijs van die dingen hmmz

[naftebakje]

Als je het met me eens bent dat 0.01µA niets is, kan je deze solid-state powerswitch gebruiken, hiermee kan je vanuit je software het geheel volledig uitschakelen.
Lijkt me interessant als ontlaadbeveiliging voor je batterijen, als je wil inschakelen controleert je µC eerst of de batterij niet te leeg is, en schakelt zichzelf in dat geval uit.

[Oyster]

Misschien is het interessant om een bluetooth device met scherm (telefoon bv) als host te gebruiken. Op deze host kan dan niet alleen de status van je lichten weergegeven en veranderd worden, maar kan ook informatie weergeven over trapfrequentie, snelheid, energieverbruik, tijden, etc. 3G abbo erbij en je moeder kan online bekijken of je met licht aan rijdt.

[mux]

Nou, ik heb dus al een systeem dat verliesloos mn rommel allemaal uit kan zetten. Dat is het probleem niet, het moet er gewoon in. That's all.

Ik ben er net op gewezen door DaWaN dat het misschien een vreselijk beperkende zet is om een AVR te gebruiken. Tegenwoordig heeft NXP namelijk de LPCXPRESSO en ontzettend goedkope Cortex-M3-based chips die op 72 MHz lopen, veel snellere ADCs en PWMs hebben en bovendien oneindig veel beter met hun energie om kunnen gaan dan AVRs. Gezien ik hier ook al ervaring mee heb denk ik dat ik voor een ARM-oplossing ga.

@hierboven: laten we er gelijk een twitter-client op maken ;-)

[ Voor 5% gewijzigd door mux op 20-04-2010 20:03 ]

[voodooless]

ssj3gohan schreef op dinsdag 20 april 2010 @ 20:02:
Tegenwoordig heeft NXP namelijk de LPCXPRESSO en ontzettend goedkope Cortex-M3-based chips die op 72 MHz lopen, veel snellere ADCs en PWMs hebben en bovendien oneindig veel beter met hun energie om kunnen gaan dan AVRs.

Was het allemaal maar werkelijk zo mooi.. Per Mhz zijn die dingen inderdaad iets zuiniger dan een Atmel, en je moet natuurlijk niet vergeten dat een M3 per tik meer kan doen, maar op lage kloksnelheden gaat dat voordeel al redelijk snel verloren. In een toepassing als een lampje aansturen heb je die 72 Mhz echt niet nodig. Bovendien zijn het vaak juist de randapparaten die het stroomverbruik omhoog jagen. Wij hebben de NXP CPU ook getest, en daar werden we niet echt heel erg blij van. 't was zeker niet slecht, maar ook niet beter dan een zuinige Atmel. Je zou nog kunnen kijken naar de EFM32 van EnergyMicro. Dat is ook een M3, die het nog wat beter doet dan de NXP, maar ook hier moet je heel veel uit zetten om te sparen.

[mux]

Hm, maar....:

- Ik ga dit soort projecten niet aanpakken met hardware waar ik geen ervaring mee heb (ontwikkelingstijd wordt dan gewoon te lang, dat laat ik me niet weer gebeuren)
- LPCXPRESSO is een heel erg 'dit wil ik hebben'-ding: JTAG debugger, IDE en knappe proc in 1.

Het gaat me verder ook een beetje om price/performance. Als ik de keuze heb tussen een AVR en LPC13x neig ik al snel naar de laatste omdat je voor dezelfde (farnell-)prijs, namelijk ongeveer 4-6 euro, een proc krijgt die veel sneller kan lopen wanneer je dat wilt (denk PWMs en ADCs op 72MHz basisfrequentie, 10 bit precisie, dat maakt goedkope en kleine inductors mogelijk, en betere stroomregeling en compensatie) en gemakkelijk on-the-fly teruggeklokt kan worden.

Daar tegenover staat een AVR die toch een heel stuk minder uitgebreid is, maar voor de toepassing genoeg kan. Beiden zijn voor mij en eigenlijk iedereen die microcontrollers begrijpt gemakkelijk te programmeren. Wat kies je dan...

Als je er dan bij bedenkt dat je misschien een security layer of protocol layer wilt implementeren in de microcontroller komt de 8kB SRAM op de lpc (ipv 1kB op de meeste avr's) wel van pas. Nogmaals, 1kB is genoeg voor AES of een zigbee/BT stack, maar je houdt dan bar weinig over voor je programma. En later wil ik ook programmeerbare ledstrips gaan bouwen, daarvoor is meer RAM echt een pré...

Dus. Wat zeg jij hierop? En trouwens... Wanneer en waarvoor heb jij met die progjes gefrutseld? En, wanneer ben jij je rode kleurtje verloren?

[virus.elektro]

ik zou voor de ATTINY85 gaan.
temperatuurmeting zit op de chip, 2 snelle 8bits PWM (64MHz klokbasis), ADC, USI.

Je wil het samen met andere mensen doen, maar je kan niet van iedereen verwachten dat ze zin hebben om een dure JTAG interface te kopen.

[voodooless]

ssj3gohan schreef op woensdag 21 april 2010 @ 08:25:
- Ik ga dit soort projecten niet aanpakken met hardware waar ik geen ervaring mee heb (ontwikkelingstijd wordt dan gewoon te lang, dat laat ik me niet weer gebeuren)

Dat is natuurlijk een uitermate goed argument

Als je er dan bij bedenkt dat je misschien een security layer of protocol layer wilt implementeren in de microcontroller komt de 8kB SRAM op de lpc (ipv 1kB op de meeste avr's) wel van pas. Nogmaals, 1kB is genoeg voor AES of een zigbee/BT stack, maar je houdt dan bar weinig over voor je programma. En later wil ik ook programmeerbare ledstrips gaan bouwen, daarvoor is meer RAM echt een pré...

Natuurlijk, daarnaast zal de M3 van NXP toch ook wel hardware AES kunnen?

Dus. Wat zeg jij hierop? En trouwens... Wanneer en waarvoor heb jij met die progjes gefrutseld? En, wanneer ben jij je rode kleurtje verloren?

De grote vraag is natuurlijk ook: hoe zuinig moet het echt zijn? Wij zoeken naar een redelijk krachtige CPU voor een custom RF module (868Mhz, 0.5 Watt). In rust moet het ding echt bijna niks verbruiken (RF luisteren is al duur zat). Voor ons voldeed de NXP in ieder geval niet. Ik heb er zelf niet mee gespeeld, maar mijn collega's wel. De EFM32 zijn we nu aan het reviewen. Helaas hebben we het voor elkaar gekregen om het dev bord te slopen ... Morgen krijgen we een vervanger.

En missende kleurtjes: dat is toch al weer een hele tijd zo.

[mux]

virus.elektro schreef op woensdag 21 april 2010 @ 09:55:
ik zou voor de ATTINY85 gaan.
temperatuurmeting zit op de chip, 2 snelle 8bits PWM (64MHz klokbasis), ADC, USI.

Je wil het samen met andere mensen doen, maar je kan niet van iedereen verwachten dat ze zin hebben om een dure JTAG interface te kopen.

Dat is dus de pracht van LPCXpresso: die kost 28 euro en dan heb je een devboard+JTAG interface. Als andere mensen willen meehelpen aan dit project verwacht ik wel dat ze al iets van ervaring hebben met ARM danwel AVR en hun eigen programmeerzooi hebben. Anders is deze investering niet echt groot; ik verwacht dat de rest van de hardware ook niet bij 5 euro blijft (30-40 euro voor een setje lichten is denk ik realistisch).

@hierboven: Ik geloof niet dat die M3'tjes hardware AES doen, maar AES is simpel genoeg voor software en heeft als enige resourceprobleem de 512B SRAM die je nodig hebt (give or take).

Hier heb ik op zich niet zo'n mega-energiezuinigheidsprobleem. De RF-module zal wel tussen de 7 en 20 mA zitten, in slaapmodus doet hij maar ~0.5sec per 30 seconde iets. Als de rest 40mA erbij zuipt zit je dan dus op 1mA RMS, dat houdt hij op één 18650 cel (10Wh) redelijk eenvoudig 2000 uur vol, oftewel 2 maanden. Featureset zal zwaarder wegen. Voor jouw toepassing... is een MSP430 oplossing dan geen beter idee?

[ Voor 27% gewijzigd door mux op 21-04-2010 10:23 ]

[virus.elektro]

ssj3gohan schreef op woensdag 21 april 2010 @ 10:18:
[...]


Dat is dus de pracht van LPCXpresso: die kost 28 euro en dan heb je een devboard+JTAG interface. Als andere mensen willen meehelpen aan dit project verwacht ik wel dat ze al iets van ervaring hebben met ARM danwel AVR en hun eigen programmeerzooi hebben. Anders is deze investering niet echt groot; ik verwacht dat de rest van de hardware ook niet bij 5 euro blijft (30-40 euro voor een setje lichten is denk ik realistisch).

@hierboven: Ik geloof niet dat die M3'tjes hardware AES doen, maar AES is simpel genoeg voor software en heeft als enige resourceprobleem de 512B SRAM die je nodig hebt (give or take).

Hier heb ik op zich niet zo'n mega-energiezuinigheidsprobleem. De RF-module zal wel tussen de 7 en 20 mA zitten, in slaapmodus doet hij maar ~0.5sec per 30 seconde iets. Als de rest 40mA erbij zuipt zit je dan dus op 1mA RMS, dat houdt hij op één 18650 cel (10Wh) redelijk eenvoudig 2000 uur vol, oftewel 2 maanden. Featureset zal zwaarder wegen. Voor jouw toepassing... is een MSP430 oplossing dan geen beter idee?

28 euro dat is inderdaad een mooie prijs, ik neem aan dat de ontwikkelomgeving gewoon te downloaden is.
Toen ik met ARM werkte voor een bedrijf vond ik het te duur om mee te hobbyen. 1000 euro voor JTAG en KEIL ofzo. Voor de AVR ontwikkelset heb ik 100 euro uitgegeven (AVRDRAGON, STK500 en wat losse spullen).
En vergeleken bij de leds is 28 euro inderdaad niet zo duur. Indien je nog leds nodig hebt, ik heb nog een paar 4X1W strips over van AVAGO.

[mux]

Inderdaad, gewoonlijk zijn voor studenten/non-commerciele dingen de KeIL devboards + Ulink2 JTAG debugger >400 euro, met commerciele pakketten die minstens 1000 euro (klinkt nog goedkoop eerlijk gezegd) kosten. Maargoed, NXP is er eindelijk achter gekomen dat studenten ook thuis willen knutselen en daar is de xpresso voor. Andere fabrikanten deden dit veel eerder al trouwens... Helaas hadden die meestal redelijk zielige featuresets of 'turbo 8051' cores (=complete crap, nooit gebruiken, AVOID).

Die leds, hoeveel lm/W doen die? Enneh... Ga jij ze goedkoper weg willen doen dan niels1 op samenkopen (want die heeft echt belachelijk goedkope zooi, 210lm 3W LEDs voor 2,25 enzo)?

[voodooless]

ssj3gohan schreef op woensdag 21 april 2010 @ 10:18:
@hierboven: Ik geloof niet dat die M3'tjes hardware AES doen, maar AES is simpel genoeg voor software en heeft als enige resourceprobleem de 512B SRAM die je nodig hebt (give or take).

De EFM32 M3 kan dat dus wel Maar met voldoende RAM en genoeg clock moet dat ook in software kunnen

Hier heb ik op zich niet zo'n mega-energiezuinigheidsprobleem. De RF-module zal wel tussen de 7 en 20 mA zitten, in slaapmodus doet hij maar ~0.5sec per 30 seconde iets. Als de rest 40mA erbij zuipt zit je dan dus op 1mA RMS, dat houdt hij op één 18650 cel (10Wh) redelijk eenvoudig 2000 uur vol, oftewel 2 maanden.

Dat zijn andere behoeften dan wij hebben. Wij hopen toch op heel wat minder uit te komen

Featureset zal zwaarder wegen. Voor jouw toepassing... is een MSP430 oplossing dan geen beter idee?

We moeten AES en Reed Solomon doen, er moet een bootloader in kunnen, het moet weinig pootjes hebben, low power, en het moet vooral heel goedkoop zijn. De RF module (uC, rf chipje, switches, external RF amp en een stuk voeding, en pinnen) mag maximaal 15x35 mm worden (effectief 13x35 mm), en kostprijs moet onder de 10 euro uitkomen.

Maar goed, ik je topic niet kapen Zo'n 10W monsterfietslamp vind ik wel heel erg gaaf trouwens

[virus.elektro]

Ik blijf dit topic nog even volgen, je weet me te vinden als je iets nodig hebt. Enig idee of dit trouwens ook toepasbaar zou zijn in een roeiboot(C2x+)? lengte ongeveer 6m

[mux]

De bedoeling is dat het dan ook nog moet werken ja.

Ondertussen ben ik geattendeerd door een collega bij mijn stagebedrijf op het protocol ANT. Dit is eigenlijk nog geschikter voor het doel omdat het een stuk zuiniger en flexibeler is dan BT en Zigbee, maar vooral ook omdat het al gebruikt wordt in vergelijkbare apparaten (hartslagmeters, fietscomputers, etc.).

Maar terugkomend op de range... Deze protocollen zijn meestal wel gelimiteerd tot iets in de orde van 10 meter. Het zal op het randje zijn. Maar ze kunnen ook meshen - pakketjes kunnen over verschillende nodes heen 'hoppen' tot ze bij het eindpunt zijn. Dat is niet uniek aan ANT, want ZigBee doet dat ook.

[mux]

Ik heb gistermiddag met iemand van mijn stagebedrijf erover gepraat en er zijn nogal wat haken en ogen aan de ingewikkeldere protocollen. Allereerst, ZigBee/Z-Wave en vooral Bluetooth hebben een vrij monsterlijk grote stack nodig: een gereduceerde implementatie van ZigBee (enkel een vast gedefinieerd netwerk, geen meshing) kost je meer dan 32kB (liefst in SRAM), Bluetooth tikt nog een heel stuk harder aan met 160kB. Als ik dus enige hoop wil hebben dat dit op een LPC1311 oid gaat werken (lees: in de orde van 8-16kB SRAM) zit ik dus wel vast aan ANT.

Bijkomend voordeel: ANT is een heeeeeel stuk goedkoper dan ZigBee (componentkosten ~10 euro voor ANT tegen 25+ euro voor ZigBee, waarbij een ZigStick 60+ euro kost incl. wat leuke software).

[Oyster]

Ik heb je topicstart maar eens goed doorgelezen en wat mij betreft gaat er niet direct een lichtje branden. Eigenlijk heb ik geen idee wat het doel van dit project moet zijn. Ben je niet ontzettend bezig met het oplossen van problemen die er eigenlijk (nog) niet zijn? Ik lees dat commercieel verkrijgbare fietsverlichting niet voldoet (waarom niet?) en dat je bent overgestapt op een systeem waarbij je de lichtopbrengst van een led opstelling kunt regelen. Dat is natuurlijk allemaal prima.

Vervolgens zie ik een duidelijke trend in deze tread met betrekking tot een BAN netwerk / anti-collision / scatternet systemen. Waarom wil je dit zo graag en welke problemen moet dit oplossen? Vervolgens zie ik microcontroller specs voorbij vliegen en een drang tot gebruik van een 72MHz Cortex. Ik denk niet dat jezelf vastleggen op een achitecteur een goede keuze is.

Naar mijn mening komt de selectie van een controller pas nadat je hebt bepaald wat de randapparatur moet worden. Als je niet weet wat je aan een controller moet aansluiten en hoe de functionaliteiten op de controller zich moeten gedragen zijn specs als controller vermogensefficiëntie koffiedik kijken. Je hebt immers nog geen idee wat de controller uberhaupt moet doen.

Het is belangrijk dat je eerst een duidelijk beeld hebt van wat er allemaal gedaan moet worden in je systeem. Vervolgens ontwerp je daarbij de randelektronica voor de aansturing / conditionering / voeding-/-management van je sensors/actuators. Deze randelektronica kan je aansluiten op een controller die naar aanleiding van de gewenste functionaliteiten gekozen kan worden. En dat kan vanalles zijn met de duur jouw gespecificeerde weegfactoren.

Ik zou eerst eens duidelijk op papier zetten wat het doel van dit project is en welke problemen het moet oplossen en wat de voordelen voor een gebruiker zijn. Momenteel zie ik echt niet wat het nut is van een BAN. Als ik mijn licht aan wil hebben druk ik een knopje in en als ik het luxe wil hebben dan zit er een bewegingssensor met lichtsensor in. Als dat ding van m'n fiets af wordt gejat koop ik een nieuwe voor 1 knaak 80.

[mux]

Dit is géén praktisch systeem... *insert this-is-spartaaaaa-plaatje* dit is een tweakersysteem.

De reden dat ik me 'vastleg' op lpc/avr is omdat ik hier ervaring mee heb en ze goedkoop zijn (ik heb ook wel ervaring met TMS320/arm9 maar dat is te duur). Er is een microcontroller nodig voor communicatie, en dat moet iets zijn wat ik snel en efficient kan programmeren, dan zijn er maar twee keuzes die binnen budget vallen. Uit ervaring weet ik dat een 64 resp. 72 MHz baseclock voor PWM handig is om enige regelprecisie te houden bij frequenties waarbij je een betaalbare inductor kunt gebruiken, dus dan blijven er al helemaal weinig micro's over.

Toegegeven, er worden een paar denkstappen overgeslagen, maar ik ben niet iemand die vanaf de grond aan moet beginnen met microcontrollers en dit soort systemen ofzo. Ik kan dit bij wijze van spreken al in mijn hoofd uitontwerpen. Het lijkt me leuk om een proof-of-concept privénetwerk te kunnen bouwen dat meer dan enkel esoterisch nut heeft, en mijn toepassingsgebied hiervoor wordt dan één van mijn andere grote hobby's: de fiets.

Bovendien, als het werkt is het van groot nut boven andere systemen: het is draadloos, het is on-the-fly programmeerbaar en het is willekeurig uitbreidbaar. Precies wat ik nodig heb als basisplatform om later in andere toepassingen vergelijkbare oplossingen te maken, en iets dat een hoop andere mensen ook kunnen gebruiken. Privénetwerken zijn 'hot' - zogezegd: iedereen wil er wel een toepassing mee maken, niet iedereen kan het (op zn minst omdat er weinig publiek beschikbare end-to-end ontwerpen zijn).

[deepbass909]

Een eerste ding wat mij te binnen schoot wat betreft stroomverbruik, is een bewegingssensor niet iets om alles automatisch uit te schakelen na x-minuten? Ik bedoel dan een bewegingssensor zoals die nu ook al in automatische achterlichten wordt gebruikt.

Daarnaast ben ik het wel eens Xander2000. Natuurlijk is het l33t-gehalte erg hoog als je kan zeggen dat je een microprocessor gestuurde verlichting op je fiets hebt, maar ik vind het persoonlijk nogal een overkill...

Sowieso zou ik powerleds niet aansturen met een spanningsbron, maar met een stroombron. Daarvoor zijn hele mooie IC's te koop die veel efficiënter werken dan je ooit met een weerstand gaat halen. Of je kan aan de slag met een PWM-aansturing, mits die maar op een hoog genoeg frequentie werkt en eventueel buffert met een elco, om stroboscoop effect te voorkomen.

[Mr_gadget]

ssj3gohan schreef op vrijdag 23 april 2010 @ 13:48:


Bijkomend voordeel: ANT is een heeeeeel stuk goedkoper dan ZigBee (componentkosten ~10 euro voor ANT tegen 25+ euro voor ZigBee, waarbij een ZigStick 60+ euro kost incl. wat leuke software).

Maar je hebt toch ook modules die de stack voor je al implementeren?
Zoiets als dit bijvoorbeeld (geen ervaring mee). 21 dollar en werkt als seriële poort, maar of er meerdere slaves aan kunnen vraag ik me af

Btw: ANT= nordic 2.4 Ghz toch?

[mux]

deepbass909 schreef op vrijdag 23 april 2010 @ 16:13:
Een eerste ding wat mij te binnen schoot wat betreft stroomverbruik, is een bewegingssensor niet iets om alles automatisch uit te schakelen na x-minuten? Ik bedoel dan een bewegingssensor zoals die nu ook al in automatische achterlichten wordt gebruikt.

Daarnaast ben ik het wel eens Xander2000. Natuurlijk is het l33t-gehalte erg hoog als je kan zeggen dat je een microprocessor gestuurde verlichting op je fiets hebt, maar ik vind het persoonlijk nogal een overkill...

Sowieso zou ik powerleds niet aansturen met een spanningsbron, maar met een stroombron. Daarvoor zijn hele mooie IC's te koop die veel efficiënter werken dan je ooit met een weerstand gaat halen. Of je kan aan de slag met een PWM-aansturing, mits die maar op een hoog genoeg frequentie werkt en eventueel buffert met een elco, om stroboscoop effect te voorkomen.

3x raden wat ik doe... Ik maak juist een dc/dc converter om zo verliesloos mogelijk highpower LEDs aan te sturen. Daarvoor heb ik al een PWM controller nodig. Momenteel heb ik dat al werkend in mijn fiets, met een microcontroller, met two-wire communicatie. In zekere zin is dit project dus niets meer dan het draadloos maken van m'n huidige installatie - en gelijk nog meer mooie dingen inbouwen because I can.

Verder, wat betreft het stroomverbruik als alles 'uit' staat - dit is juist het sterke punt van al die draadloze technieken. Ze werken al op het principe dat ze elke zoveel ms heel even opstarten, in burst het een en ander naar elkaar versturen en dan weer gaan slapen. Als je een ANT module continu zou laten verzenden/ontvangen zuipt hij 15 a 20 mA, doe daar een microcontroller en wat andere zut bij en je zit al gauw op een redelijk ondraaglijke 50mA. Echter, als je ze elke seconde een frame laat zenden en ontvangen - dit duurt niet langer dan 100ms inclusief tijdsynchronisatie met de andere nodes - gebruikt het bij elkaar niet meer dan 5mA RMS. Als je dan ook nog het zendvermogen aanpast (bit error rate bekijken, en zodanig tunen dat hij precies alle errors nog kan corrigeren) kun je het gemakkelijk terugkrijgen tot 2-3mA.

Een bewegingssensor en lichtsensor staan in de planning, deze zorgen hier dano ok precies voor: wanneer de fiets stilstaat en/of er toch teveel licht is gaat het licht automatisch uit en gaat het geheel in power saving mode.

Dan nog over de stack size: Een stack stopt niet bij de hardware en protocol layer. Bij een peer-to-peer communicatie kan het wel: dan heb je als enige configuratie het ID waar je naartoe wilt zenden en dat is het. Maar als je een ad-hoc netwerk hebt wordt het meteen een stuk moeilijker: je moet weten hoe je je packets moet routen van node naar node, je moet de situatie opvangen dat een node plots stopt te bestaan in je netwerk, en je moet een beetje slim kunnen schakelen tussen nodes als de bit error rate opeens omhoog vliegt. Bovendien - maar dit gaat erg ver - wil je eigenlijk een soort rotating security key over je netwerk houden zodat een snelle bruteforce-aanval op je WPAN (wireless personal area network) niet mogelijk is. Alles behalve dat laatste moet in SRAM gebeuren, de protocol en hardware layer zitten helemaal geintegreerd in de meeste IFE's (integrated front end).

Ik zal vanavond wel een wat betere TS fabriceren en beter op een rijtje zetten waar alles voor dient. Ook zal ik wat meer motivatie bij mijn keuzes tot nu toe zetten.

Overigens, ik maak voor jullie gevoel nogal grote stappen naar specifieke MCU/protocolkeuzes. Ik houd ervan om dit soort dingen al snel concreet te hebben, zodat ik iets heb om mee te werken en andere opties tegen af te wegen. Bovendien is het mn bedoeling om hier een gezamenlijk project van te maken: mensen die willen instappen hebben op deze manier een idee waar ik heen wil.

_{@mr_gadget: nee, dat is de generieke ISM 2.4GHz chip van nordic. De nRF24AP1 is degene met grootendeels ingebouwde ANT stack}

[Corn]

RFM12B is eventueel wel een leuke optie als het op budget moet. Ze zijn ook in verschillende frequentiebanden te krijgen, kunnen channel hoppen, en hebben redelijk wat zelf ingebouwd. Zijn ook relatief simpel via SPI aan te sturen. Je zult wat meer werk op je mcu moeten verzetten als je een nette security layer er tussen wilt persen, maar ze zijn wel voor euro's per stuk te krijgen.

Nadeel is wel dat ze 12mA doen in receive, dus daar moet je iets handigs op bedenken.

[mux]

Hmmm... Aan de ene kant:
- Het is goedkoper (~6-7 euro voor een volledige transceiver incl. alles) dan ANT (7,50 alleen voor de chip, daar komen nog een paar externe componenten bij, dus reken 10 euro).
- Het is tweakbaarder dan geintegreerde protocollen+hardware layers

Aan de andere kant:
- Er is een hoop meer software voor te schrijven, het verschil in prijs is daar niet echt goed genoeg voor
- Het stroomverbruik zal iets hoger (maar niet dramatisch) uitvallen gezien de datafrequentie lager is (en hij dus langer zenden/ontvangen moet).
- mijn ervaring met 433 MHz en 868 MHz is dat ze nooit geintegreerde CRCs, retransmits of andere error correctie hebben. Het is een gepruts (en ik heb de theoretische kennis gewoon niet) om dit goed te krijgen.

Maar als het erop lijkt: ik ben niet alles aan het afzeiken hoor. Ik probeer gewoon de meest voordelige keuze te maken. Misschien is een vergelijkings-tabel een goed idee, dat zal ik eens in de TS zetten.

[RemcoDelft]

Mooi topic om even te volgen! Mijn 28-LED-voorlamp (op 3 AAA's) is ondertussen kapot, dus aan vervanging toe. Ik rijd graag in het pikdonker met harde wind (mee) door de duinen, dan geldt: hoe meer licht, hoe beter! Het liefst zou ik meerdere koplampen hebben, maar dat is slechts toegestaan als je ook meerdere voorwielen hebt (een bakfiets dus).

[mux]

Daarover gesproken, ik zie tegenwoordig Gazellefietsen verkocht worden met dubbel achterlicht. Volgens mij is dat niet toegestaan, of mag je dat hebben als ze niet meer dan X cm uit elkaar staan ofzo?

Maargoed, waar heb je meerdere koplampen voor nodig? Als je gezien wilt wórden is dat niet nodig, en als je zelf wilt zien heb je gewoon zoveel mogelijk lumens nodig (brommerkoplamp = 500 lm, autolamp = 1500-3000lm). Uit goede (denk Cree K-bin) LEDs komt 70-90 lm/W, dus als je licht vergelijkbaar met een brommer zou willen kun je er twee 3W LEDs op gooien, als je echt helemaal gek wilt doen (zoals ik, ik wil door de Delftse Hout, Balijbos, etc. kunnen fietsen met 40 km/h in he tpikdonker) gooi je er een 10W Cree MC-E op (800lm). En volgens mij heb je dan niet meer lichten nodig, want je wordt én geweldig gezien, en je kunt zelf ook een kilometer vooruit kijken.

3 à 10W is lastig om uit AA's te trekken, dus ik denk dat ook jij aan li-ion zult moeten dan. Alleen lijkt het me dan handig als hij ook automatisch bijlaadt vanaf een dynamo, of heb je een li-ion lader thuis?

[RemcoDelft]

ssj3gohan schreef op zondag 25 april 2010 @ 10:57:
Daarover gesproken, ik zie tegenwoordig Gazellefietsen verkocht worden met dubbel achterlicht. Volgens mij is dat niet toegestaan, of mag je dat hebben als ze niet meer dan X cm uit elkaar staan ofzo?

Toen ik de regels daarover opzocht, werd er heel duidelijk gesproken over "1 licht". Maar ja, zolang ze knipperende kerstbomen nog niet bekeuren, denk ik dat je weinig risico loopt op een boete. Wel jammer, want een knipperend achterlicht is normaal gesproken iemand die achter geparkeerde auto's langsfietst. Het geeft dus verwarring als-ie bijvoorbeeld opeens voor de auto's rijdt.
Om het niet te hebben over de IDIOTEN die een rood lampje voor bevestigen, en blijkbaar geen idee hebben wat er van ze over blijft als iemand "achter" ze langs wil rijden

10W aan fietsverlichting is gewoon VEEL, en lastig te doen met alleen accu's. Tenslotte wil ik ook niet dagelijks moeten opladen.

[mux]

1W is i.h.a. genoeg tijdens het rijden, en 10W heb je maar eventjes nodig om wat te zien. Zo ga ik het althans aanpakken. En dan gooi ik er twee of drie li-ion cellen in per module (20 à 30 Wh). Zelfs in de wintermaanden gaat dat nog een halve maand mee.

Er is natuurlijk prima wat te doen om die dingen herlaadbaar te maken vanaf je naafdynamo, maar ik ken niet veel naven die 10W leveren. Laat staan een ouderwetse banddynamo. Je zult dus hoe dan ook batterijen nodig hebben als buffer.