Slumpmässig strömbrytare 12v med tidsfördröjning?

[Yamabushi]

Hej! Undrar om det någon här som vet vart man kan köpa/bygga eller någon som kan bygga ett kretskort eller liknande till en strömbrytare som slumpmässigt slår på/av upp till 8 stycken 12V uttag med slupmässig tidsfördröjning på 3-11 sekunders intervaller?


Mvh Per.W

[Icecap]

Att bygga en sådan grej är inget speciellt svårt, en mikroprocessor klarar enkelt detta. Dock är det ett problem, en µC kan inte slumpa på riktigt! Men med den rätta algoritm och ett par primtal kan man komma mycket långt. Det blir dock en sekvens som spelas upp men man kan börja olika ställen i den sekvens och göra en ganska lång sekvens av det hela.

Så exakt hur "slumpmässigt" ska det vara?

Och att styra 8 utgångar på det vis är knappast ett problem heller, det kan t.ex. räcka ett använda samma algoritm men seeda med olika värden.

[Yamabushi]

Hej!


Slumpmässigt och slumpmässigt. Den skall kopplas till 8 stycken ”bollkastare” (som jag skrev i en annan tråd) och användas som träningsredskap. Så eleverna som använder träningsredskapet måste uppleva det som slumpmässigt så att dom ej lär sig sekvensen även om dom står tränar flera timmar om dagen. Så den måste nog vara ganska lång sekvens så att dom ej uppfattar mönstret.


Mvh Per.W

[ristomemo]

Till denna applikation behövs det nog inte, men om man vill förbättra slumpmässigheten så brukar man ju "salta" ett tal som sedan slumpfunktionen använder sig av. Saltet kan ex vis komma från brus och a/d omvandling. Eller om det är knapptryckning inblandat så kan man använda sig av hur länge knappen hålls ner.

[jesse]

Eller om man använder någon analog ingång och stoppar in brus där, så kanske du kan få ut ganska slumpartade tal... Bruset borde man väl kunna åstadkomma på olika sätt???

[Icecap]

Det är enkelt att med primtal skapa en sekvens med t.ex. 32k olika värden, det är gjort på en kick. Och det sekund de lär sig den sekvens är det dags att gå vidare till en annan sport...

Om tiden mellan 3 och 11 (8 sekunder) sekunder delas upp i 32k delar är upplösningen ~244µs och jag är ganska säker på att mekaniken knappast har den upplösning! Alltså är det viktiga en fråga om vilken upplösning som behövs, detta ger sedan antal steg som kan behövas men jag skulle tro att en sekvens på 32 olika tider skulle räcka ganska långt!

[Glattnos]

Lånar tråden lite då jag också skulle göra en "slumpgenerator". Jag trodde att jag var smart när jag kom på iden men den verkar inte fungera. Gör detta i mjukvara på AVR uC.

Jag har två timers som rullar:
En 8-bitars timer som som rullar fort prescale 64
En 16-bitar timer som rullar långsamt prescale 1024
När 16-bitarstimern "slår runt" så sker ett avbrott. I avbrottet sparas det aktuella värdet från 8-bitarstimern.
Värdet skriver jag ut på en LCD för att se vad det blir, värdet uppdateras varje gång 16-bitarstimern når TOP.

Jag kan faktiskt köpa att detta inte fungerar något vidare bra som "slump" men det som jag inte kan förstå är att värdet blir 245 eller 246, det pendlar lite mellan de två. Jag kan gå med på att värdet inte varierar mer än så men varför det ALLTID blir 245 eller 246 förstår jag inte riktigt. Det blir nämligen ingen skillnad när jag ändrar startläge för 16-bitarstimern(dvs laddar räknar-registret med ett start-tal i avbrottet). Jag har testat alla möjliga tal, ojämna som jämna. Har även testat andra prescaler-tal. Jag har även koll på att räknarna rullar och att start-talet fungerar och allt verkar stämma och rulla som det ska men den prickar lik förbaskat 245 eller 246 varenda gång.

Är det möjligt att det är så himla magiskt att det är ett axiom som bara blir så? Eller MÅSTE det vara något annat fel i programmet?

Och ett tips på hur jag kan göra en enkel slumpgenerator med primtal skulle vara välkommet. Jag behöver ingen stor slumpmässighet.

[Icecap]

Din "slump"-generator fungerar inte för att båda timers kör på samma klocka.


Kanske primitiv men följande rutin ger 32k variationer som duger alldeles utmärkt till t.ex. en bollkastare:

Kod: Markera allt

#define PRIME_1 13
#define PRIME_2 73

void Randomize(unsigned int* Data)
  {
  *Data *= PRIME_1;
  *Data += PRIME_2;
  }

Man kan ändra de två primtal men inte alla ger så himla många variationer. Jag har hittat en lista med massor av primtal på nätet, för att testa variationer har jag gjort en snabb rutin i Excel som börjar med att seeda värdet till noll, sedan räknar den igenom hur många iterationer den kan köra innan det åter blir noll. Antalet iterationer - 1 = antal kombinationer.

Väljer man fel värden blir det aldrig en stopp på det hela då det bara blir ett antal fasta värden som aldrig kommer till startvärdet så en max.-räknare kan vara bra att ha...

Jag har ett projekt där jag behöver variera hastighet och tid på varje hastighet, då låter jag hastigheten köra igenom denna "slump"-rutin en gång per ändring och hastighetens värde kör igenom en gång per varv i main-loop. Då följs de inte åt helt enkelt fastän det är samma primtal som ligger i grunden. Till det projekt använder jag 32 olika nivåer, det räcker alldeles utmärkt då det hela är lite primitivt.

[Nerre]

Om tiden mellan 3 och 11 (8 sekunder) sekunder delas upp i 32k delar är upplösningen ~244µs och jag är ganska säker på att mekaniken knappast har den upplösning! Alltså är det viktiga en fråga om vilken upplösning som behövs, detta ger sedan antal steg som kan behövas men jag skulle tro att en sekvens på 32 olika tider skulle räcka ganska långt!

Men det är ju inte bara tiden som skall slumpas, det är ju tid OCH utgång som skall slumpas. Bollen skall komma från olika kastare och med oförutsägbar fördröjning.

[Icecap]

Vad skulle vara problemet i det? Som jag skrev: jag använder exakt denna rutin till att "slumpa" två samverkande värden.

Vilken boll slumpas en gång per boll!
Tiden mellan varje boll slumpas en gång per varv i main-loop eller mha. en timer.

Då har du 32k värden för tiden * 32k värden för kastaren och de är inte låsta till varandra på ett sätt som juniorerna klarar att klura ut.

OK, du har inte 32k bollkastare men då är det bara att ta restsumman efter en division med antalet bollkastare. I detta fall blir det 8 st, man kan då likaväl göra en AND med 7 då.

Tiden mellan varje kast är 3 sek + ((11 - 3)/32k)*slumpvärdet, det ger steg om 244,15µs och det borde väl räcka... Är det för många steg för att det är enkelt att lösa gäller det samma som vid antal bollkastare: räkna på kanske 32 värden, alltså en upplösning på 250ms (ett kvart sekund).

Den totala kombinationsantal blir på det vis 32 * 8 = 256 olika. Sedan är det bara att välja rätt värde för upplösningen i tid för att öka detta.
Väljer man t.ex. 1/100-del sekund som tidupplösning blir antalet kombinationer 6400 och om en spelare fattar mönstret där är det en helt annan karriär som h*n ska förfölja!

[Nerre]

Det jag menade är att du behöver inte ha 32k tider och 32k värden för kastare.

Det var ju 8 kastare, använd de tre lägsta bitarna att välja kastare och resterande 12 bitar till en slumpmässig fördröjning.

[Icecap]

"Inte behöver" är inte det samma som "vill inte ha"!

Men javisst jag fattar precis vad du menar. Sedan är tiden ju knappast okänd heller, den är ju definierat att vara mellan 3 och 11 sekunder som yttergränser.

En delning av ett "slump"-värde på det vis du anger ska nog fungerar helt fint till detta projekt, det kommer att bli rikligt för att ingen ska räkna ut/lära sig sekvensen. Det går ju utmärkt att lägga in formeln i t.ex. Excel eller OpenOffice Calc och se resultaten och hur en delning av värdet ville fungera för de enstaka delar.

Så det är ingen raketteknologi, det är bara kreativ användning och att ställa rätt krav som gäller.

[Nerre]

Med en psudoslumpalgoritm som sparas mellan avstängningarna (man kan tänka sig att den slumpar fram ett nytt seed vid boot som senn används nästa boot) så tror jag inte man kommer att kunna lära sig nåt. En bra slumptalsalgoritm på 8 bitar ger ju inte en sekvens som upprepas efter 256 gånger.

[Glattnos]

Icecap: Jag använder assembler och är inte så bra på C. Vad är det som händer i koden du skrev?
Är det typ att variabeln "data" multipliceras med PRIME_1 och adderas med PRIME_2, sedan läggs den lägsta byten av resultatet i "data" igen. Så snurrar det på hela tiden så att det är "data" man ska plocka när man vill ha ett "slump-tal"?
Förmodligen har jag fel

Kan man inte ta värdet från en ADC som inte är kopplad någonstans? Dom brukar ju fladdra ganska mycket. Om man tar en 10-bitars ADC och låter den "fladdra" i tomma luften. Så plockar man de lägsta bitarna och gör något med. Tex plockar de lägsta 4 bitarna fyra gånger med kanske 200 ms i mellan så lägger man dom efter varandra så man får ett 16-bitars-tal som borde kunna vara allt mellan 0 och 65535. Eller är det "förbjudet" att lämna en pinne "öppen" på det viset? Kan man sätta dit något enkelt som "fladdrar"?

[Nerre]

ADC-ingången kan du väl använda som seed, men den är troligen för lätt att påverka för att den skall vara vettig som rent slumptal.

På ABC80-tiden så minns jag att nån tidning hade en artikel om "är dina slumptal fyrkantiga?", den handlade alltså om att perfekta slumptal skall ju ha en rektangulär fördelning. Jag tror inte att de värden du får från ADC har en rektangulär fördelning.

Slumtalsalgoritmer finns det många, det handlar alltså om att räkna fram ett slumptal från föregående slumptal genom en "oförutsägbar" beräkning. Googla på "pseudo random generator".


Här står det en del om hur man kan testa sina slumptal
http://en.wikipedia.org/wiki/Diehard_tests

Fast så avancerat behöver du nog inte ha, det går nog att göra enklare.