BeneluxSpoor.net forum
Vraag en antwoord => Elektronica en analoog => Topic gestart door: Ajean op 10 November 2014, 11:55:48
-
Modelbaan uitlichten m.b.v. WS2812 (Neopixel) leds en Arduino.
In dit forum is al vaker geschreven over het uitlichten van je modelbaan d.m.v. led strips, zowel strips met witte leds als strips met RGB leds, al dan niet digitaal aangestuurd.
Het “nadeel” van deze strips is dat alle leds bij aansturing de zelfde kleur weergeven.
Bij nacht simulatie geven bijvoorbeeld alle leds dezelfde kleur blauw weer.
Wil je echter een meer realistische dag/nacht simulatie (bijvoorbeeld links van je baan komt de zon op en is het lichter terwijl het rechts nog nacht en donker is, of je wilt een gedeelte van je baan met een net iets andere kleur belichten) dan zul je een andere manier van uitlichten moeten zoeken.
Een manier is, volgens mij, je modelbaan uitlichten m.b.v. WS2812 (Neopixel) leds die aangestuurd worden door een Arduino micro controller. WS2812 (Neopixel) leds zijn RGB leds met een ingebouwde controller zodat iedere led afzonderlijk kan worden aangestuurd, zowel op kleur als op helderheid. Ook zijn fade in/fade out als ook knipper effecten mogelijk.
Op dit moment ben ik bezig een proefopstelling te maken om met alle mogelijkheden te experimenteren. Uiteindelijk wil ik komen tot een ,DCC aangestuurde, automatische dag/nacht simulatie.
Ik hou jullie op de hoogte van mijn vorderingen.
Adri
Meer informatie: https://learn.adafruit.com/adafruit-neopixel-uberguide/overview (https://learn.adafruit.com/adafruit-neopixel-uberguide/overview)
-
Dit klink interessant.
Blijf dit volgen
-
Zijn inderdaad leuke stripjes en goed aan te sturen door het dozijn aan lib's. Ik vind ze zelf alleen te duur om hiervoor te gebruiken. Denk dat je ook al een heel eind komt door de verlichting boven de baan op te delen in stukken van 1 of 2 meter. Maar elektronica, voor mij altijd een plus ;D
Timo
-
Voor een baan van enkele meters kan het inderdaad prijzig worden.
Voor mijn diorama (lengte 1 meter) was ik echter aan leds en arduino een kleine 50 euro kwijt.
Adri
-
Leuk project. Alleen jammer dat het DCC is. Ik ben SX rijder.
Wordt trouwens nog leuk met interrupts disabled gedurende bepaalde tijden.
Groet,
Gerard van der Sel.
-
Een Arduino kan op verschillende manieren worden getriggerd. DCC is er slechts een van.
Adri
-
Dat weet ik. Ik heb zelf een uitgebreide SX bibliotheek. Echter interrupts disabled gaat het niet worden. Ben ook benieuwd hoe je dat met DCC gaat doen. Ganbare methode is toch op basis van interrupt om het inkomende bits te lezen.
Groet,
Gerard van der Sel.
-
Om de programma sketch simpel te houden wordt de Arduino getriggerd door een OC32/DCC van VPEB
Adri
-
Dat weet ik. Ik heb zelf een uitgebreide SX bibliotheek. Echter interrupts disabled gaat het niet worden. Ben ook benieuwd hoe je dat met DCC gaat doen. Ganbare methode is toch op basis van interrupt om het inkomende bits te lezen.
[nog verder off-topic mode]
Wat is nou je probleem met interrupts en het disablen dan i.c.m. DCC of SX?
Je hoeft veelal niet ALLE interrupts te disablen en je kunt 'taken' goed langs elkaar uit laten voeren door je Arduino. Je moet natuurlijk niet lappen code in 1 interrupt laten uitvoeren als je met timing rekening moet houden, maar met een beetje slim programmeren zijn interrupts juist een genot en zijn het daarom gangbare methoden.
[/nog verder off-topic mode]
Gr. Dave
-
Dave,
Volledig met je eens. Echter ik heb in mijn SX-bibliotheek een belasting van circa 25% door de SX-bus software. Dit moet met bitbanging gebeuren, er is geen hardware beschikbaar. Ik ben aan het experimenteren met de 8 bits schuifregistermodus, om de 96 bits binnen te halen. Hierdoor krijg ik nog maar 1 interrupt op 8 bits.
Maar dit is nog verre van operationeel.
Groet,
Gerard van der Sel.
-
Heren,
Ofschoon ik er niets van begrijp (ben geen techneut) zal jullie interrupts discussie best interessant zijn, maar ik vraag me wel af wat de specifieke meerwaarde ervan is voor dit topic.
Adri
-
Ja mee eens.
De term uitlichten doet me ook jeuken ;D
-
Als je het DCC deel laat doen door de OM32 is het niet zo lastig. Of je nu drukknopjes of een OM32 gebruikt maakt namelijk niet uit. Laat je de Arduino ook het DCC deel doen dan kan het nog wel eens wat lastig worden. De timing om de Neopixels aan te sturen is nogal kritisch. Zitten er interrupts van DCC tussen kan het nogal eens fout gaan. Andersom kan je DCC pakketten missen als er een interrupt is als je de Neo's aan stuurt.
Timo
-
Hallo,
Stand van zaken:
Tot nu toe heb ik het kleurenverloop van de dag/nachtsimulatie en de bijbehorende RGB (kleur) waarden bepaald.
De waarden zijn verwerkt in een Arduino sketch zodat de led strip aangestuurd kan worden.
Het resultaat is, op wat verfijningen na, datgene wat ik voor ogen had.
Echter na veel pogingen is het me nog steeds niet gelukt om per led de overgang van de ene kleur naar een anderen vloeiend te laten verlopen. De abrupte wisseling van kleur is nog steeds duidelijk te zien. Dit zelfde geld voor de wisseling van helderheid.
In de library van zowel Adafruit_NeoPixel als die van FastLed zijn voorbeelden te vinden waarin deze overgang wel vloeiend gebeurt.
In de bijbehorende sketches is me echter niet duidelijk met welke programregel(s) dit aangestuurd wordt.
Wellicht basiskennis maar mijn programmeer ervaring ligt in een ver verleden en was vooral database gericht (Clipper) en is daarom wat roestig.
Suggesties en tips zijn welkom
Groeten,
Adri
-
Als je je huidige code kunt geven dan kan ik er even naar kijken. Plaats ht wel tusse [ code] tags.
Timo
-
@ Timo,
Heb PB gestuurd
-
Okay, ik ben er even naar gekeken. Ik moet wel zeggen, ik heb geen ervaring met de FastLED librarie en ik heb helaas ook geen Neopixels ofzo liggen. Mijn code is puur gemaakt op basis van de documentatie en compilled zonder error. Maarja, er zou nog een foutje in kunnen zitten...
Goed, omdat er misschien meer mensen wat te zeggen hebben over de code en de aanpassingen begin ik met de originele code van Adri.
Orginele code:
#include "FastLED.h"
// How many leds in your strip?
#define NUM_LEDS 8
// For led chips like Neopixels, which have a data line, ground, and power, you just
// need to define DATA_PIN. For led chipsets that are SPI based (four wires - data, clock,
// ground, and power), like the LPD8806 define both DATA_PIN and CLOCK_PIN
#define DATA_PIN 6
#define BRIGHTNESS 30
// Define the array of leds
CRGB leds[NUM_LEDS];
void setup() {
FastLED.addLeds<NEOPIXEL, DATA_PIN, RGB>(leds, NUM_LEDS);
FastLED.setBrightness( BRIGHTNESS );
}
void loop(){
// Turn the LED off, then pause
leds[0].setRGB(0,0,0);
leds[1].setRGB(0,0,0);
leds[2].setRGB(0,0,0);
leds[3].setRGB(0,0,0);
leds[4].setRGB(0,0,0);
leds[5].setRGB(0,0,0);
leds[6].setRGB(0,0,0);
leds[7].setRGB(0,0,0);
FastLED.show();
delay(2000);
// Turn the LED on, then pause
leds[0].setRGB(60,0,20);
leds[1].setRGB(60,0,20);
leds[2].setRGB(60,0,20);
leds[3].setRGB(60,0,20);
leds[4].setRGB(60,0,20);
leds[5].setRGB(60,0,20);
leds[6].setRGB(60,0,20);
leds[7].setRGB(60,0,20);
FastLED.show();
delay(5000);
// Turn the LED on, then pause
leds[0].setRGB(120,0,40);
leds[1].setRGB(120,0,40);
leds[2].setRGB(120,0,40);
leds[3].setRGB(120,0,40);
leds[4].setRGB(120,0,40);
leds[5].setRGB(120,0,40);
leds[6].setRGB(120,0,40);
leds[7].setRGB(120,0,40);
FastLED.show();
delay(5000);
// Turn the LED on, then pause
leds[0].setRGB(180,0,60);
leds[1].setRGB(180,0,60);
leds[2].setRGB(180,0,60);
leds[3].setRGB(180,0,60);
leds[4].setRGB(180,0,60);
leds[5].setRGB(180,0,60);
leds[6].setRGB(180,0,60);
leds[7].setRGB(180,0,60);
FastLED.show();
delay(5000);
// Turn the LED on, then pause
leds[0].setRGB(240,0,80);
leds[1].setRGB(240,0,80);
leds[2].setRGB(240,0,80);
leds[3].setRGB(240,0,80);
leds[4].setRGB(240,0,80);
leds[5].setRGB(240,0,80);
leds[6].setRGB(240,0,80);
leds[7].setRGB(240,0,80);
FastLED.show();
delay(5000);
}
Eerste paar opmerkingen over de code. Probeer altijd de delay() functie te vermijden. Deze legt het hele programma namelijk stil. Zie Blink Without Delay (http://arduino.cc/en/Tutorial/BlinkWithoutDelay). Ook als je heel vaak hetzelfde doet moet je je gaan afvragen of het makkelijker kan. Vandaar dat ik een for loop gebruik om de ledstrip in te stellen.
Ook staat er een foutje in, hij vind RGB in FastLED.addLeds<NEOPIXEL, DATA_PIN, RGB>(leds, NUM_LEDS); niet leuk bij Neopixels ;D
Ik ben in mijn aangepaste code uitgegaan van een vaste volgorde van kleuren met elk een overgangstijd (fadIn time, transition time) en duur welk vast staan bij compillen. Meer kleuren (en tijden) zijn toe te voegen. Ik heb nu even gekozen voor vol aan (alles 255) en de laatste kleur die jij gebruikte (CRGB(240, 0, 80)) waarbij ik niet weet wat dit oplevert.
In mij voorbeeld ga ik uit van de hele strip in dezelfde kleur. Dit maakt een Neopixel natuurlijk nogal nutteloos. Maar ik denk dat de opzet wel te gebruiken is om meer dynamische (links beginnen bijvoorbeeld) overgangen te maken. Ook al denk ik dat Neopixel nog steeds overkill is als je baan lang is.
Mijn code:
#include "FastLED.h"
/********** Color and timing *************/
typedef struct{
unsigned int fadeIn;
unsigned int ontime;
CRGB color;
} preset_map;
//map of {fadeIn time = transition time (in ms), on time (in ms), CRGB color}
//You can add more colors (and times) for more transitions
//transitions happen in chronological order order starting at 0 at boot
const preset_map Presets[] = { {10000, 5000, CRGB(240, 0, 80)},
{10000, 5000, CRGB(255, 255, 255)}};
#define NUM_PRESETS sizeof(Presets)/sizeof(Presets[0])
/********** FastLED definitions **********/
// How many leds in your strip?
#define NUM_LEDS 8
// For led chips like Neopixels, which have a data line, ground, and power, you just
// need to define DATA_PIN. For led chipsets that are SPI based (four wires - data, clock,
// ground, and power), like the LPD8806 define both DATA_PIN and CLOCK_PIN
#define DATA_PIN 6
#define BRIGHTNESS 30
// Define the array of leds
CRGB leds[NUM_LEDS];
void setup() {
FastLED.addLeds<NEOPIXEL, DATA_PIN>(leds, NUM_LEDS);
FastLED.setBrightness( BRIGHTNESS );
}
void loop(){
ledsUpdate();
}
void ledsUpdate(){
static bool inTransition;
static unsigned long millisLast;
static byte presetCounter;
static unsigned int interval;
static byte transitionCounter;
byte r, g, b, lastPreset;
if(millis() - millisLast > interval){
millisLast = millis();
if(inTransition){
//It's a new transition, calculate transition interval
//transition in 256 steps
//Full transition will be 256 * (fadeIn / 256) as int so there can be a significant error
if(transitionCounter == 0){
interval = Presets[presetCounter].fadeIn / 256;
transitionCounter++;
}
//What was the last preset?
lastPreset = (presetCounter == 0 ? NUM_PRESETS - 1 : presetCounter - 1);
//calculate in between color for RGB
r = lerp8by8(Presets[lastPreset].color.r, Presets[presetCounter].color.r, transitionCounter);
g = lerp8by8(Presets[lastPreset].color.g, Presets[presetCounter].color.g, transitionCounter);
b = lerp8by8(Presets[lastPreset].color.b, Presets[presetCounter].color.b, transitionCounter);
//set al the colors
for(byte i = 0; i < NUM_LEDS; i++){
leds[i].setRGB(r, g, b);
}
//if it was the last transition
if(transitionCounter == 255){
inTransition = false;
}
transitionCounter++;
}
//we are at the new preset
else{
//turn all leds to preset color
for(byte i = 0; i < NUM_LEDS; i++){
leds[i] = Presets[presetCounter].color;
}
//start waiting for next transition
interval = Presets[presetCounter].ontime;
presetCounter++;
inTransition = true;
}
FastLED.show();
}
}
/code]
Ik hoop dat je hier iets mee kan.
Timo
-
@ Timo,
Bedankt voor je reactie. ik heb de sketch ingelezen. Er gebeuren echter enkele dingen (o.a. opeens opflitsen van een ander kleur) die ik niet kan thuisbrengen en ook moeilijk te beschrijven zijn.
Met alle plezier stuur ik je een neopixel stripje (8 leds) op zodat je zelf het resultaat van je sketch kunt bekijken. Als je dit wat lijkt stuur me dan via een PB je adres.
Groeten,
Adri
-
Hoi Adri,
Mm, dan zal er ongetwijveld er een, waarschijnlijk klein en lullig, foutje in zitten ja ::) Snap je globaal wel hoe ik het programma bedoelt heb? De overgangen tussen kleuren moet je zelf dus maken in zo klein mogelijke stapjes.
Als je een stukje zou willen opsturen dan test ik het met alle plezier voor je :) Ik zal je een pb sturen!
Timo
-
Misschien dat deze regel veranderen je probleem met kleur verspringen op lost.
Orgineel:
for(byte i = 0; i < NUM_LEDS; i++){
leds[i].setRGB(r, g, b);
}
Nieuw:
for(byte i = 0; i < NUM_LEDS; i++){
leds[i].setRGB(r, g, b);
delay(10);
}
Ik had ook problemen met timing in PWM. Het korte wachten loste bij mij het probleem op.
-
Hoi Neef(?),
Als je code plaatst moet je dan wel even tussen de [code ] tags doen, kijk nu maar eens naar je code ;D
Maar dan terug komen op het onderwerp. Naast dat ik geen fan ben van de delay functie (je laat de uC zijn kostbare tijd uit zijn neus eten..) is 10ms ook erg veel. Zou je er een strook van 100 ledjes aan hangen zit je al op een seconde!
Daarnaast kan dat het probleem ook niet zijn. Alles wat de set functie doet is de waarde in de buffer (geheugen van de Arduino) aanpassen. Pas met FastLED.show() wordt het signaal naar de ledstrip gepompt (in een keer allemaal). En logischerwijs zal een vertraging voor het schrijven van wat Arduino geheugen niets uitmaken.
Mag ik vragen wat jij voor timing problemen had met PWM?
Timo
-
Beste Timo,
Misschien is 10ms ook wel wat veel. Heb alleen de ervaring dat bits nog wel eens door elkaar willen lopen bij een Arduino UNO,
Met het project waar ik zelf mee bezig ben heb ik het zelfde ondervonden en meestal zorgde de vertraging er voor dat dit probleem werd op gelost.
Als alle dat in één keer weg geschreven wordt met de FastLED.show() functie dan kan het hier inderdaad niet aan liggen.
Zou alleen toch een keertje de waarde van de variabele leds.setRGB(r, g, b) uit lezen per led.
Misschien kom je hier ongeregeld heden in die niet zouden moeten.
-
Hoi Milan,
Bitjes door elkaar lopen is per definitie niet mogelijk. Het schrijven van bitjes is iets wat de Arduino doet en pas verder gaat als het gedaan is.
Wel kan het zijn dat externe dingen (Serial, ledstrips, displays enz) wat tijd nodig hebben het te verwerken. Nu kan een hele korte delay wel eens handig zijn maar dan een paar microseconde. Gebruik van delay() is eigenlijk altijd af te raden en kan beter opgelost worden.
Wil ik het probleem eruit halen zou ik er toch even weer langer voor moeten gaan zitten. Al weer even geleden dat ik naar de library gekeken had... ::)
Timo
PS, let met code plaatsen even op. Code met arrays botsen namelijk met de opmaak tags, zeker omdat i vaak als pointer gebruikt wordt maar [i ] italic oplevert.