De EL-kroeg - Deel 3

[mace]

http://www.products4engin...gasklep-atex-200mbar.html ??

[the_stickie]

@mace de afsluiters voor aardags zijn niet geschikt (200mbar versus 5 tot 8 bar)
@base_ thx voor de link, ik contacteer hen
@mux gebruikte je dan persluchtcomponenten? Als dat kan met een klein verlies, lijkt me dat meer dan prima: uiteindelijk komt er wel een degelijke kraan en een reduceerventiel tussen, dus heb ik alleen verlies als het geheel in gebruik is Uiteindelijk zal het gebruik van persluchtcomponenten vooral een stuk goedkoper zijn!

ik ben er overigens ondertussen uit hoe het heet: gewoon een shut-off valve. Voor snelle helium afsluiters worden "solenoid valves" gebruikt. dat die dingen moeilijk te vinden zijn, ligt meer aan het feit dat "normale" mensen het niet zoeken denk ik
Allen bedankt voor het meedenken; zodra ik resultaat (of nieuwe vragen) heb, laat ik iets weten

[mux]

Oh, als je het buiten gebruik goed hebt afgesloten is er helemaal geen probleem. Daar kun je inderdaad persluchtcomponenten voor gebruiken (let wel: zelf heb ik er nooit iets mee gemaakt, ik heb slechts toegekeken hoe teamgenoten er van alles mee bouwden).

[mace]

mux schreef op zaterdag 04 december 2010 @ 14:54:
Zo, mace, nu hoor je het ook eens van een ander!

Wait, what?

Hmja onze aller Lullo kan niks beters bedenken om mij te jennen dan dat ik in Twente woon.

Boudewijn, LUL, verzin eens wat nieuws.

[ThinkPad]

Ik ben een Dell 2005FPW TFT scherm aan het repareren, want hij doet nu niks als je er 230V op aansluit. Typenummer van voedingsprintplaat: YUYANG TELECOM YP20106D REV 1.1

Ik heb hem open getrokken en dacht eerst aan kapotte elco's, maar die zien er nog allemaal goed uit.

Wel is er een onderdeeltje genaamd "ZD103" geëxplodeerd zie ik.

In de buurt van dat onderdeeltje zitten nog een paar, en die zijn nog wel heel. Daar staat de code "Z6" op.

Nu blijkt dat dat een BZX84C7V5-V zenerdiode is. Ik heb hem bij Farnell al gevonden: http://nl.farnell.com/fai...mw-7-5v-sot-23/dp/1828302

Maar zou ik niet gewoon zo'n normale zenerdiode kunnen gebruiken? Die kan ik namelijk zo bij m'n elektroboer halen. Kan ik dan gewoon een 7V5 zenerdiode halen of moet het echt specifiek zo'n SOT-23 dinkie zijn ?

Edit:
Oh kak, er is nog meer kapot, ik zie nu dat een soort transistor (TO-220 behuzing) met 6 poten ook geëxplodeerd is Hij zit op een redelijk groot koelblok, en heet op de printplaat "U101". Het enige wat ik nog van de behuizing kan lezen is "3230" op de onderste regel. Iemand een idee wat dat voor ding is?

[ Voor 19% gewijzigd door ThinkPad op 08-12-2010 16:43 . Reden: Andere onderdeel wat ook kapot is ]

[mux]

De hele spanningsregeling is geexplodeerd, waarschijnlijk omdat de optocoupler (veelvoorkomende oorzaak als de zener ook explodeert) of primaire regelaar (die TO-220 met teveel poten) het begeven heeft. Je zult heel systematisch de kapotte componenten moeten vervangen en testen om dit aan het werk te krijgen, anders explodeert de helft weer bij elke test.

Dat de zener kapot is gegaan betekent dat hij waarschijnlijk een paar seconden een te hoge spanning heeft geproduceerd. Er is dus ook een goede kans dat je CCFL-inverter naar z'n moer is, of in het slechtste geval ook de rest van de elektronica. Dat zou ik eerst even uitproberen (aan een labvoeding hangen), en daarna pas proberen de voedingsprint te repareren. Je kunt wat foto's (scherp, juiste componenten in focus, goede overzichtsfoto erbij) posten als je specifiekere hulp wilt.

[ThinkPad]

Ik zal even wat foto's maken. Ik kan zo verder geen defecte componenten zien met het blote oog.

Ik had ook al gekeken naar een nieuw powerboard omdat ik geen zin heb om onderdelen te kopen die dan weer uitelkaar klappen , maar die powerboards zijn moeilijk te vinden op internet.

[mux]

http://www.lcdrepair.us/2005fpw-power.html

[ThinkPad]

mux schreef op woensdag 08 december 2010 @ 16:58:
http://www.lcdrepair.us/2005fpw-power.html

Daar moet je hem opsturen om te laten repareren Dan probeer ik het liever zelf


Foto's:
1. Overzichtsfoto onderkant power board


2. De geklapte ZD103 met links ernaast de U101 die ook kaduukie is


3. Overzichtsfoto bovenkant powerboard


4. De geëxplodeerde ..... 3230


5. Typenummer


Als je nog meer foto's of info nodig bent, of als ik wat moet omcirkelen ofzo dan moet je het maar even zeggen

[ Voor 5% gewijzigd door ThinkPad op 08-12-2010 17:21 ]

[Boudewijn]

Zijn er tegenwoordig nog dingen behalve : typenrs en ESD waar je op moet letten als je een hdd printplaat transplanteert? Vroeger kon het vrij makkelijk, maar dit specifieke probleem betreft klandata.

[Sprite_tm]

Blergh, ik heb nu al 4 LTC485s stukgemaakt. Situatie: een FT232 met een LTC485 eraan aan de ene kant, een ATMega88 met een LTC485 eraan aan de andere kant. Op dit moment hangt er een stukkie UTP van nog geen halve meter tussen. Er worden eens in de 0.3 seconden een stel bytes overgestuurd vanuit de FT232 waar de ATMega dan weer met een enkele byte op reageert.

De LTC485 bij de FT232 doet het nog prima, maar ik lijk continue de LTC485 bij de ATMega in de buurt stuk te maken, en allemaal op dezelfde manier: receiven gaat nog gewoon 100% netjes, maar het ding reageert niet meer op het signaal wat z'n transmitter aan moet zetten: er verschijnt gewoon niets op de lijn terwijl dat wel zou moeten. Als ik er een nieuwe LTC485 inzet doet deze het een tijdje, varierend van uren tot seconden, en dan gaat 'ie ook op dezelfde manier stuk.

Iemand enig idee? Ik begin door mijn LTC485s heen te raken

[mux]

Thinkpad: de regulator (TO-220F-6L) is opgeblazen en heeft waarschijnlijk in zijn neergang de gehele feedback-lijn meegenomen. Die ZD103 is enkel een bescherming (voor wanneer de optocoupler een te hoge spanning produceert), niet kritiek voor de werking, net als het componentje dat ernaast zit en ongetwijfeld ook kapoets is. R114 zorgt samen met C103 een RC-filtertje dat waarschijnlijk wel redelijk belangrijk is voor de stabiliteit van het circuit, beiden zullen stuk zijn. Je optocoupler is ook ongetwijfeld stuk. D102 en C107 vormen een filter voor een aftakking van de trafo, C107 is waarschijnlijk stuk maar D102 kan nog best eens heel zijn als het een hoge spanningsrating heeft (1N4006/7/8/9, laatste getal staat voor spanningsrating in honderden volts). Wanneer D102 ook kapot lijkt te zijn heb je een fundamentele kans dat je trafo ook opgeblazen is en het bord onreparabel is (je komt er nooit achter wat voor magnetica er is gebruikt).

Maar... wanneer de trafo en diode goed lijken te zijn heb je geluk, en is enkel de feedback-lijn stuk. Condensatortjes en weerstandjes vervangen, en dat IC, en je bent er.

De controller-IC (dat TO-220F-6L-ding) ziet eruit als een Fairchild Power Switch-device. 323x lijkt echter niet een bestaand model te zijn, en je foto is niet scherp genoeg om te zien of een 3 niet eigenlijk een 8 was oid. Er zijn andere merken die ook dit soort IC's maken maar Dell kennende hebben ze niet echt bespaard op het ontwerp en een brand-name controller gebruikt (Fairchild, National, ST/SGS-thompson, etc.) met een leuke topologie erachter. Een halfuurtje ronddwalen op de parametric search van fairchild en anderen die dit soort ICs maken en je vindt hem waarschijnlijk wel. Je zult de datasheets moeten openen en letten op de volgorde van de pinnen, deze is: 1 Drain - 2 Feedback - 3 Source - 4 Vcc en 5 een of andere valley detection/QR ingang en 6 onbekend.

Ik ben overigens lichtelijk geshockeerd door de relatief slechte kwaliteit van dit bord! Dell staat bij mij bekend als een bedrijf dat zeker op de betere monitoren gewoon Delta-bordjes te gebruiken en garant te staan voor goede kwaliteit. Dit bordje ziet eruit als... een el cheapo single-sided bordje met slechte ingangsfilters, zo goed als geen input protection, al helemaal geen PFC, veel heatsinking en dus waarschijnlijk een ouderwetse forward-converter (ipv een modernere resonante converter). Dit wordt gevolgd door een hokkietokkie niet-vindbare flyback controller (wederom, de betere monitoren gebruiken resonante flybacks) voor de CCFLs...

Dell, I am disappoint.

[nick_haak]

Sprite_tm schreef op woensdag 08 december 2010 @ 23:43:
Blergh, ik heb nu al 4 LTC485s stukgemaakt. Situatie: een FT232 met een LTC485 eraan aan de ene kant, een ATMega88 met een LTC485 eraan aan de andere kant. Op dit moment hangt er een stukkie UTP van nog geen halve meter tussen. Er worden eens in de 0.3 seconden een stel bytes overgestuurd vanuit de FT232 waar de ATMega dan weer met een enkele byte op reageert.

De LTC485 bij de FT232 doet het nog prima, maar ik lijk continue de LTC485 bij de ATMega in de buurt stuk te maken, en allemaal op dezelfde manier: receiven gaat nog gewoon 100% netjes, maar het ding reageert niet meer op het signaal wat z'n transmitter aan moet zetten: er verschijnt gewoon niets op de lijn terwijl dat wel zou moeten. Als ik er een nieuwe LTC485 inzet doet deze het een tijdje, varierend van uren tot seconden, en dan gaat 'ie ook op dezelfde manier stuk.

Iemand enig idee? Ik begin door mijn LTC485s heen te raken

lijkt me een open deur... maar ik trap em toch in:P
zit er genoeg ontkoppeling omheen?

[Verwijderd]

ik zoek wat software om wat elektronische componenten uit te tekennen, suggesties?
voor de nieuwschierigen, ik heb een bordje nodig waarmee ik dmv een avr bordje wat sensoren, knoppen, en op 24v werkende motortjes kan aansturen (dmv een relais), niet zo ingewikkeld dus, maar je moet ergens beginnen

en meteen een vraag, als ik een schakelaar hebt waarvan ik de positie wil uitlezen (aan/uit), kan ik deze dan direct op mn bordje aansluiten? (tussen een willekeurige I/O pin en +5v) of moeten daar nog wat componenten tussen?

[mux]

TinyCAD+FreePCB.

Alternatief: EAGLE (gratis versie). gEDA. KiCAD.

[ThinkPad]

mux schreef op donderdag 09 december 2010 @ 10:14:
Thinkpad:

[.....]

Dell, I am disappoint.

Bedankt voor de uitgebreide reactie! Zal er binnenkort eens mee aan de slag gaan

[Verwijderd]

mux schreef op zaterdag 11 december 2010 @ 00:38:
TinyCAD+FreePCB.

Alternatief: EAGLE (gratis versie). gEDA. KiCAD.

ik zat al met pen en papier te klooien tinnyCAD werkt toch duidelijk beter

[Stekeltje]

-

[ Voor 99% gewijzigd door Stekeltje op 11-12-2010 15:47 ]

[wesleytjuh]

:W
Kan iemand hier mij opweg helpen met het volgende?

Ik ben van plan om een herlaadbare lader te maken voor mijn telefoon met een dc/dc converter. Ik heb al een paar kant en klare DC/DC converters van bijvoorbeeld samenkopen.net getest maar deze voldeden niet helemaal aan mijn eisen. Vandaar dat ik besloten heb om zelf een print te ontwerpen die wel aan mijn eisen voldoet.
Als stroomvoorziening ben ik eerst op zoek gegaan naar protected 18650 cellen, maar vaak zijn deze van slechtere kwaliteit dan unprotected cellen. Er zijn er wel wat die wel van goede kwaliteit zijn maar hier betaal je dan ook flink voor(14.75 dollar voor 2600mAh bijvoorbeeld).

In mijn zoektocht kreeg ik de tip van iemand om gewoon unprotected cellen te gebruiken in combinatie met een DC/DC converter met undervoltage lockout. Ik heb al aantal converters gevonden met deze functie, maar vaak was deze threshold dan te laag.
Bijvoorbeeld:
LT1935
http://cds.linear.com/docs/Datasheet/1935f.pdf
Undervoltage Lockout Threshold 2.1 2.3 V
Ik geloof dat het aangeraden is om een li-ion batterij niet verder dan 2.75v te ontladen, dus dit valt dan ook af.

Wel zie ik het volgende staan:
SHDN Input High Voltage 1.8 V
SHDN Input Low Voltage 0.5 V
Als ik het goed begrijp is het dan mogelijk om met een spanningsdeler te zorgen dat wanneer de accuspanning onder de 2.75v zakt, er minder dan 0.5v op deze pin staat waardoor het ic uitschakelt? Zodra de lader wordt aangesloten stijgt de spanning weer naar 4.2v, en op de SHDN pin dus meer dan 1.8v, en zal het ic weer aangaan?

Verder heb ik nog gekeken naar een LT1308, weer net wat krachtiger.
http://cds.linear.com/docs/Datasheet/1308abfa.pdf
Deze beschikt ook over een low battery in en output. Maar zover ik kan zien geeft een spanning onder de threshold alleen een signaal af bij de low battery output pin, en schakelt dit niet automatisch het ic uit. Ik neem aan dat dit dan niet geschikt is voor mijn doelstelling?
Danku .

[DaWaN]

mux schreef op zaterdag 11 december 2010 @ 00:38:
TinyCAD+FreePCB.

Alternatief: EAGLE (gratis versie). gEDA. KiCAD.

Je hebt tegenwoordig ook nog DesignSpark van RS components, dat is eigenlijk gewoon EAGLE met een nieuwe GUI en gratis

[Sprite_tm]

nick_haak schreef op vrijdag 10 december 2010 @ 22:17:
[...]


lijkt me een open deur... maar ik trap em toch in:P
zit er genoeg ontkoppeling omheen?

Yep. Uiteindelijk bleek het probleem te zijn dat ik het ding perongeluk op de 3.3V-voedingslijn gezet had ipv de 5V-voedingslijn. Als 'ie te weinig spanning krijgt wil 'ie blijkbaar niet meer zenden ofzo Nja, uiteindelijk omgekat naar 5V en het beestje doet het nu prima.

[lemming_nl]

Ik ben bezig een magnetische roerder/verwarmer (IKA RCT basic) te repareren zodat ik, ook na het even laten staan, goed verwarmde en geroerde koffie heb.

Het roergedeelte werkt prima. Het verwarmingsgedeelte echter niet. Het lampje dat hij op temperatuur is brand gelijk. Openmaken gaf aan dat er enkele onderdelen in contact geweest zijn met vocht of zuur. Na de oxidatie verwijderd te hebben en de verbindingen gecontroleerd ben ik tot de conclusie gekomen dat hij het gewoon zou moeten doen. In de handleiding vond ik het volgende:

In the event of a disturbance in the control circuit, the heating
plate is permanently cut off by the safety circuit.

Mijn idee is dat hij door het vocht een fout gaf, er een beveiliging in werking is getreden en dat hij het daarom niet meer doet. De printplaat bevat qua grotere chips enkel opamps, wat nand pporten, een pwm regelaar (voor de roerder). Deze lijken mij niet in staat om dingen permanent te onthouden. Het meeste kleinere grut zijn transistoren. Een zwart, ongemarkeerd, smd onderdeel (maatje 1206) verdacht ik ervan een zekering te zijn. Het overbruggen van dit component levert niets op.

Een verdere zoektocht gaf mij een smd onderdeel met 4 pinnen waarvan 3 aangesloten met de code JE42. Deze heb ik niet kunnen achterhalen. Om een lang verhaal kort te maken: iemand een idee wat het zou kunnen zijn?

[Sprite_tm]

Heb je pics of een schema ofzo? En omgwtf, een magnetische roerder repareren met het doel je koffie warm te houden, ik geloof dat er ergens een grens in awesomeness is die je gepasseerd hebt

[ThinkPad]

Mag je wel oppassen dat je niet stikt in die roervlo

[Boudewijn]

Sprite_tm schreef op woensdag 15 december 2010 @ 00:33:
Heb je pics of een schema ofzo? En omgwtf, een magnetische roerder repareren met het doel je koffie warm te houden, ik geloof dat er ergens een grens in awesomeness is die je gepaseerd hebt

Ik verwacht jou in januari met een dergelijke gadget in a'dam te zien hoor .


@vraagsteller: nice.

[sebastius]

Een simpel vraagje, maar analoge elektronica kan ik echt niet

Ik wil een schietspel maken. Laserpointer als pistool en dan een sensor die aan een toets op het toetsenbord zit verbonden. Dus dat als het oogje een laserstraal merkt, moet ie een contactje kortsluiten.

Na even graven bedacht ik me dat er twee mogelijkheden waren. Een LDR en een Fototransistor (Fotodiode). De LDR lijkt me te traag. De fotodiode ken ik niet goed, maar volgens mij is het toch gewoon een kwestie van de fotodiode over het contact heen zetten en beschijnen met de laser?

Van solderen ben ik niet vies en uitvinden is m'n hobby, maar ik moet echt weer es m'n analoge kennis ophalen...

[lemming_nl]

Sprite_tm schreef op woensdag 15 december 2010 @ 00:33:
Heb je pics of een schema ofzo?
[...]

Schema heb ik helaas niet. Het schema natekenen is verrekte lastig. De printplaat is dubbelzijdig en daar hebben ze gebruik van gemaakt. Echt overal via's. Dit is ook voor een groot deel te wijten aan dat ze maar een kant bestukt hebben met smd componenten. Dus als er ergens een componentje tussen twee traces op de onderkant moet gaan de traces eerst met via's omhoog en daarna weer omlaag.

Foto's heb ik nog niet. Mijn mobiel levert geen bruikbare foto's op waar je ook nog iets van componenten kan zien. Ik ga op zoek naar een kwalitatief betere camera.

Vandaag heb ik een tweede exemplaar (van een iets oudere revisie) kunnen bemachtigen. Deze vertoont hetzelfde gedrag maar ik heb in ieder geval wat reserve onderdelen. Hier zit ook dat JE onderdeel op maar dan de JE41 ipv JE42

[Sprite_tm]

sebastius: Pak een fototor of een LDR. LDRs lijken binnen 15ms te reageren, wat me snel genoeg lijkt. Fototorren zijn ook bruikbaar, die reageren nog sneller. Fotodiodes zijn niet handig; die genereren namelijk maar een minimalistisch stroompje of spanninkje (afhankelijk van hoe je 'm schakelt) en dat gaat een keyboard niet meteen snappen. Je kan een fototor gtewoon zien als een random BC550 of andere kleinsignaaltor, met dat verschil dat de hoeveelheid licht de geleiding bepaalt en niet de basisstroom.

[sebastius]

Ik had altijd gedacht dat een foto-transistor en een foto-diode hetzelfde waren. Dus ik moet of een LDR of een foto-transistor pakken? Is het gewoon alleen die tor/ldr er in prikken of heb ik nog creaties nodig om het werkend te krijgen?

[ Voor 27% gewijzigd door sebastius op 15-12-2010 14:51 ]

[Sprite_tm]

Je kunt het iig proberen en hopen dat de gevoeligheid OK is; zoniet valt er altijd nog een schema'tje met een (normale) tor en wat weerstanden te verzinnen. Let bij de fototor wel even op de polariteit.

[sebastius]

Met een schemaatje bedoel je waarschijnlijk dat je de fototor met een weerstand aansluit tussen 5v en gnd, en dan tussen die twee in aftakt naar de basis van een transistortje? (het komt weer een beetje terug )

[Sprite_tm]

Zoiets inderdaad

[lemming_nl]

Whoei! De magneetroerder werkt weer. De magneetroerder had twee relais die allebij ingeschakeld moesten zijn om hem te laten verwarmen. De ene hangt aan het temperatuurregelcircuit, de ander aan een setje NAND poorten. Deze poorten zijn volgens mij onderdeel van het fout-detectie circuit. Nalopen leverde op alles weer goed werkte. Maaarrrr.... aan de achterkant van de magneetroerder zit een connector. Hier kan je externe thermometers aan hangen. Wat ik niet wist (ik werk eigenlijk nooit met magneetroerders) is dat wanneer je er geen externe thermometer aan hebt hangen, er een plug in hoort welke twee pinnen kort sluit. Deze pinnen zijn natuurlijk verbonden met die NAND poort waardoor hij niet in wilde schakelen. Het kortsluiten van de twee pinnen bleek te werken en ik heb nu een werkende magneetroerder. Ik moet hem nog even echt goed schoonmaken, wat nieuwe knoppen enzo, maar eerst een bakje koffie.



Voor de geintereseeerde, de binnenkant:



Het plaatje is niet zo groot maar groter heeft geen zin, je ziet nauwelijk meer

[maikel]

Kunnen MOSFETs kortsluiting veroorzaken via de achterkant? Ik heb er nu drie naast elkaar op een print staan voor mijn LED-strip, maar als ik een beetje tegen de MOSFETs duw, zie ik ineens de drie kleuren LED's tegelijk aan gaan. Het lijkt er dus op dat er ergens dan kortsluiting ontstaat.
Als het niet via de achterkant is, moet ik de print toch eens nalopen op teveel tin.

En nog een ander probleempje: ik heb m'n printje nu aan m'n labvoeding hangen, maar de 433MHz-ontvanger lijkt niet heel betrouwbaar. Als ik de voeding aan zet, lijkt geen enkel commando door te komen. Als ik dan de voeding aan laat, de print even loskoppel en weer aan sluit, werkt het wel. Waar kan dit aan liggen en, belangrijker, hoe kan ik dit oplossen?
Mijn idee was dat het wellicht iets met het inschakelen van de voeding te maken heeft en het mogelijk met een condensator is op te lossen. Maar wat voor eentje dan?

[edit]
Na wat meer testen lijkt het alsof de ontvanger na een tijdje sowieso niets meer ontvangt. Maar dat kan natuurlijk ook aan het programma liggen.
Feit blijft in ieder geval wel dat het geheel beter lijkt te werken als ik eerst de voeding aan zet en dan pas aansluit.

[ Voor 54% gewijzigd door maikel op 16-12-2010 00:28 ]

[Gwannoes]

maikel schreef op woensdag 15 december 2010 @ 23:24:
Kunnen MOSFETs kortsluiting veroorzaken via de achterkant? Ik heb er nu drie naast elkaar op een print staan voor mijn LED-strip, maar als ik een beetje tegen de MOSFETs duw, zie ik ineens de drie kleuren LED's tegelijk aan gaan. Het lijkt er dus op dat er ergens dan kortsluiting ontstaat.
Als het niet via de achterkant is, moet ik de print toch eens nalopen op teveel tin.

Zitten die FETs tegen een koelblok? Ja, dan kunnen ze via het koelblok natuurlijk kortsluiting maken als je ze niet geisoleerd hebt aangebracht. Even de datasheets langslopen...

[maikel]

Dat niet, maar ze zitten wel zo dicht naast elkaar dat ze elkaar kunnen raken. Nooit bij stil gestaan dat die achterkant ook verbonden is met het circuit.

[DaWaN]

maikel schreef op donderdag 16 december 2010 @ 09:51:
Dat niet, maar ze zitten wel zo dicht naast elkaar dat ze elkaar kunnen raken. Nooit bij stil gestaan dat die achterkant ook verbonden is met het circuit.

Die tab is eigenlijk altijd verbonden met de drain in het geval van een N-FET.
Een D2-PAK MOSFET behuizing heeft bvb ook maar 2 pinnen en nee die heeft geen Wireless gate

[tokko1]

Heeft iemand tips voor online electro componenten shop(goedkoop inc verzendkosten)?
Gewoon wat kleine dingentjes ook kleine partijen bestellen...

Ik wil namelijk een een transistor die "NPN-transistors that could switch 200mA at 12V" bestellen, maar weet eigenlijk ook niet precies welk model dit is.. kan het ook niet zo makkelijk vinden op google. Voor jullie vast een makkelijke vraag maar ik zit er al even mee te puzzelen

[LED-Maniak]

dickbest, farnell. Bijna elk generiek type transistor kan jou specs halen

[tokko1]

LED-Maniak schreef op maandag 20 december 2010 @ 18:19:
dickbest, farnell. Bijna elk generiek type transistor kan jou specs halen

Okee bedankt voor de info
Maar transistor: http://www.dickbest.nl/we...t=viewProd&productId=2165 kan dus ook?

[base_]

tokko1 schreef op maandag 20 december 2010 @ 18:21:
[...]
Maar transistor: http://www.dickbest.nl/we...t=viewProd&productId=2165 kan dus ook?

BC547 is de standaard NPN tot 100mA, BC337 de NPN tot 800mA,

http://www.dickbest.nl/we...ct=viewProd&productId=683

(de -16 / -25 / -40 slaat op de versterking, als je niet zeker weet de -40 pakken)

[mace]

Of 2N2222 of 2N3904 o.i.d... Ik heb ooit een zak torren gekocht en het hangt vaak maar net af van wat ik omhoog grabbel.

[dalus]

sneak peak van een projectje:

[mux]

Het is bij jou ook nooit echt moeilijk om te raden wat je aan het uitvoeren bent hè

[mace]

dalus schreef op woensdag 22 december 2010 @ 09:57:
sneak peak van een projectje:

[afbeelding]

Die Picasa....

GAST!

[dalus]

@mux
Blijft toch wel leuk. In een zo'n coil gaat toch heel wat tijd en geld zitten. Blijft een beetje een never ending story. Kan altijd groter en beter.

@mace
Thanks. Meer details en een write up komen er ergens komend jaar aan. Die moet ik jullie helaas schuldig blijven.

[epic_gram]

Ik zit weer te knutselen, maar heb een probleem.

Mijn soldeerpunt is namelijk veel te dik om te solderen, weet iemand hier een oplossing of trucje voor?

Foto:

klikbaar
Het is al een vrij oud apparaat, maar hij is vrij sterk en doet het nog goed. Er zitten schroefjes op, ik kan de punt dus los draaien. Kan ik hier zomaar een dunnere in schroeven of is dat niet verstandig?

Alvast bedankt

[mux]

Is het nu al april?

[epic_gram]

mux schreef op donderdag 23 december 2010 @ 19:15:
Is het nu al april?

, nee ik meen het.

Kijk ik begrijp wel dat ik er een nieuwe op moet draaien, maar ik vroeg me af of ik nog ergens op moest letten voordat ik dat zou doen. Het is namelijk niet mijn soldeerapparaat dus ik doe graag voorzichtig.

Kan ik er dus zomaar een dunnere erin draaien?

[Rmg]

epic_gram schreef op donderdag 23 december 2010 @ 19:36:
[...]

, nee ik meen het.

Kijk ik begrijp wel dat ik er een nieuwe op moet draaien, maar ik vroeg me af of ik nog ergens op moest letten voordat ik dat zou doen. Het is namelijk niet mijn soldeerapparaat dus ik doe graag voorzichtig.

Kan ik er dus zomaar een dunnere erin draaien?

Euuhh dat is een soldeerpistool voor dikke kabels, glas in lood, plaatwerken en zut, niet voor (fijn)electronica man

Daar jaag je iig alle elektrostatisch gevoelige ic's de dood mee in

ohja die punt is gewoon een stuk koperdraad in dat ding zit een trafo en je jast gewoon een hele hoop stroom door die punt waardoor die warm wordt je zou er dunner koperdraad in kunnen draaien maar dat wordt sneller warm daar moet je wel opletten

[ Voor 25% gewijzigd door Rmg op 23-12-2010 19:47 ]

[epic_gram]

Rmg schreef op donderdag 23 december 2010 @ 19:41:
[...]


Euuhh dat is een soldeerpistool voor dikke kabels, glas in lood, plaatwerken en zut, niet voor (fijn)electronica man

Daar jaag je iig alle elektrostatisch gevoelige ic's de dood mee in

ohja die punt is gewoon een stuk koperdraad in dat ding zit een trafo en je jast gewoon een hele hoop stroom door die punt waardoor die warm wordt je zou er dunner koperdraad in kunnen draaien maar dat wordt sneller warm daar moet je wel opletten

hmm, dat is jammer.

Misschien moet ik mijn nick maar weer in epic_fail laten veranderen, net als vroeger.

Maareh, bedankt voor jullie reacties

[burne]

epic_gram schreef op donderdag 23 december 2010 @ 19:51:
hmm, dat is jammer.

http://www2.conrad.nl/goto.php?artikel=588332 ?

[epic_gram]

burne schreef op donderdag 23 december 2010 @ 20:08:
[...]

http://www2.conrad.nl/goto.php?artikel=588332 ?

Super, dat word hem denk ik. Voor dat geld kan ik wel een gokje wagen.

Dankjewel

[sebastius]

Ik heb even wat hints nodig...

Ik heb een fototransistortje. En ik heb een oud USB toetsenbord. Ik wil de fototransistor keyboard contact laten schakelen zodra er een laserpointer op schijnt. Dit werkt, maar het is niet gevoelig genoeg.

Dus denk ik, ik pak gewoon een BC547c transistortje en knoop een en ander in een darlington opstelling. Het probleem is dat dit té goed werkt. Continu contact (zelfs in het donker...)

Help me alsjeblieft, ik heb gewoon geen idee hoe ik de boel 'iets' sterker kan maken, maar dus ook weer niet te sterk.

[mux]

Comparator? MOSFET met goed gedefinieerde, lage Vgs(th)?

[ Voor 67% gewijzigd door mux op 23-12-2010 21:06 ]

[sebastius]

Oh damn, moet dat echt? Ik wil het echt supersimpel houden (heb het namelijk 20x nodig)

[mux]

Op die manier orthogonaliseer je je probleem. Dat wil je.

[Boudewijn]

Wat is een probleem orthogonaliseren?

[mux]

Een probleem op zodanige manier formuleren (of oplossen) dat je alle variabelen onafhankelijk kunt beïnvloeden, en niet dat het een van het ander afhangt als je iets verandert.

[sebastius]

Ja maar het is zegmaar een spelletje voor 1 avondje met 40 kinderen dat ze effe kunnen schieten op ruimteschepen Ik wil het niet te moeilijk (en duur) maken.

[ Voor 16% gewijzigd door sebastius op 23-12-2010 22:11 ]

[mux]

Kijk naar mijn blog. Kijk nu terug naar dit topic. Kijk nog eens rond in mn blogs. Kijk nu weer in dit topic.

Ik doe dingen niet echt simpel...

Je kunt allicht proberen wat meer basisweerstand in je darlingtonconfiguratie te stoppen, of een weerstand tussen de basis en emitter van de output-tor van je darlingtonconfiguratie zetten zodat een deel van de fototransistorstroom wordt afgetapt naar de emitter ipv dat alles versterkt wordt.

Maar dat is wel flink wat frummelwerk voordat je de juiste waarde hebt gevonden. Heb je 10k potmeters om dit mee te doen?

[Sprite_tm]

How about this: fototor vanuit de plus naar de basis van de normale tor, basis via een potmeter naar de min. Daarna spelen met de potmeter tot het schakelingetje doet wat je wilt (zet er wel even een weerstandje van 470 ohm mee in serie, anders sloop je je fototor namelijk als je 'm compleet opendraait.) Daarna weerstand potmeter (plus serieweerstand) meten en het geheel opbouiwen met vaste weerstanden van die waarde.

[mux]

Exact wat ik zei dus

[Sprite_tm]

Misschien, ik heb mijn koffie nog niet op en had wat moeite met lezen wat je precies bedoelde. Nja, staat het er 2 keer, kan vast geen kwaad. *lurkt aan z'n koffie*

[sebastius]

Tof, bedankt! Vanavond weer lekker knutselen dus

[ThinkPad]

He verdorie, wou ik een i2c adapter maken om een EEPROM in een laptop battery pack uit te lezen, kom ik erachter dat ik geen male DB25 (LPT) connectoren meer heb liggen.

Maandag maar even langs de kringloopwinkel paar van die oude printerkabels halen dan

[DJSmiley]

ThinkPadd schreef op vrijdag 24 december 2010 @ 22:36:
He verdorie, wou ik een i2c adapter maken om een EEPROM in een laptop battery pack uit te lezen, kom ik erachter dat ik geen male DB25 (LPT) connectoren meer heb liggen.

Maandag maar even langs de kringloopwinkel paar van die oude printerkabels halen dan

ook geen sloopmateriaal? db25 seriele poort, seriele verlengkabel, antieke inbelmodem met db25 oid?

[ThinkPad]

Nope, die heb ik allemaal al eerder misbruikt voor dit soort doeleienden

Had er toch nog eentje liggen Het is me zelfs gelukt om het werkend te krijgen met m'n smerige soldeerskills: ThinkPadd in "Laptop accu refurbishen"

[ Voor 55% gewijzigd door ThinkPad op 25-12-2010 01:16 ]

[Sprite_tm]

Hmm, ik zie net dat de garantie op mijn Rigol DS1042, 1 van de 2 apparaten waarvan ik de garantie nog wel respecteer, verlopen is. Ik denk dat ik maar eens voorzichtig ga proberen 'm open te maken en te kijken of ik eventueel een botched firmwarehack weer ongedaan kan maken.

[dalus]

Zow volgend jaar wordt het testen Fingers crossed dat alles het doet.

[Coenen]

Wat is het? Het ziet er bijna eng uit. Dike elco's, grote spoel.

[dalus]

Het is een nogal grote H-brug om solid state een teslacoil aan te kunnen sturen.

[peeter123]

dalus schreef op zaterdag 25 december 2010 @ 14:15:
Zow volgend jaar wordt het testen Fingers crossed dat alles het doet.

[afbeelding]

Ach en als die het niet doet heb je in ieder geval nog mooi vuurwerk!

[Mr_gadget]

Welke onderdelen kunnen eventueel gaan piepen en is dit schadelijk? Heb namelijk een laptopdock waar af en toe een hele hoge pieptoon uit komt, niet heel hard. Vooral als de accu van de laptop geladen moeten worden, piep hij een beetje, is dit een spoel die aan zijn maximum zit ofzo?

BTW: in januari weer een Sparkfun freeday

[ Voor 6% gewijzigd door Mr_gadget op 27-12-2010 12:56 ]

[mux]

Meestal is dat een spoel die inderdaad vrij veel ripple moet verwerken. Soms ook condensatoren.

[burne]

Mr_gadget schreef op maandag 27 december 2010 @ 12:11:
Welke onderdelen kunnen eventueel gaan piepen en is dit schadelijk?

Bijna alles. Zelfs transistoren kunnen piepen. Maar in de praktijk zijn het niet-ingegoten of slecht ingegoten spoelen. Onder invloed van het wisselend magnetisch veld gaan delen van de spoel meetrillen met de wisselstroom die er doorheen loopt. Het is nagenoeg nooit een probleem, alleen een hinderlijke eigenschap van een component.

[ThinkPad]

Grrrrr had ik m'n labvoeding even aan accu van onze scooter hangen omdat ie leeg was.

Heb ik nog zo tegen m'n pa gezegd dat hij hem niet moest starten als de voeding eraan hing (ik wil niet dat m'n voeding naar de klote gaat).

Hoor ik hem zonet de scooter proberen te starten

Ik hoop maar dat m'n voeding nog heel is, morgen maar even kijken.

[Boudewijn]

Je kunt je pa toch gewoon aansprakelijk stellen voor eventuele schade?

[sebastius]

Boudewijn schreef op maandag 27 december 2010 @ 20:57:
Je kunt je pa toch gewoon aansprakelijk stellen voor eventuele schade?

Potje breken is potje betalen Maar ja, dan zit je toch weer een tijd te wachten, en de discussies die je er bij krijgt...

[Boudewijn]

Mwa je hebt hem vantevoren gewaarschuwd en je kunt daarna hem gewoon een onrechtmatige daad aanwrijven?

Even serieus; als ik vrinden waarschuw "doe x niet met y" en ze zijn handelingsbekwaam en doen het vervolgens alsnog en y is stuk, dan ga ik wel vragen stellen ja.

[virus.elektro]

ThinkPadd schreef op maandag 27 december 2010 @ 20:51:
Grrrrr had ik m'n labvoeding even aan accu van onze scooter hangen omdat ie leeg was.

Heb ik nog zo tegen m'n pa gezegd dat hij hem niet moest starten als de voeding eraan hing (ik wil niet dat m'n voeding naar de klote gaat).

Hoor ik hem zonet de scooter proberen te starten

Ik hoop maar dat m'n voeding nog heel is, morgen maar even kijken.

volgende keer gewoon de accu uit de scooter halen. Kan die niet starten en je voeding gaat niet stuk. Oftewel gewoon zorgen dat het niet zomaar gebruikt kan worden

[ThinkPad]

Lijkt mee te vallen, de voeding doet het nog

---

Iemand toevallig een idee wanneer Dick Best weer back in business is? Zal wel in het nieuwe jaar zijn denk ik?

[ Voor 55% gewijzigd door ThinkPad op 28-12-2010 23:00 ]

[maikel]

Ik begin gek te worden volgens mij.

Voor de aansturing van mijn LED-strips heb ik de volgende code:

C:

int main()
{
    int r = 0;
    int g = 0;
    int b = 0;
    while (true)
    {
        int maxR = packet.Red();
        int maxG = packet.Green();
        int maxB = packet.Blue();
        SetR( maxR );
        SetG( maxG );
        SetB( maxB );
    }
}

Hierbij zijn de Set-functies niets meer dan een functie die de waarde in het juiste register zet voor het PWM-signaal. De variabele 'packet' is een object waar ik een buffer in gooi en die netjes alle waarden uit de buffer vist en in de juiste variabelen zet.
Dit werkt perfect via een draadloze verbinding. Ik kan netjes vanaf mijn PC elke kleur instellen die ik wil.

Echter, omdat het natuurlijk een stuk mooier is als de kleur netjes naar de nieuwe kleur fade in plaats van verspringt, heb ik de code aangepast.

C:

int main()
{
    int r = 0;
    int g = 0;
    int b = 0;
    while (true)
    {
        int steps = 100;
        int minR = r;
        int minG = g;
        int minB = b;
        int maxR = packet.Red();
        int maxG = packet.Green();
        int maxB = packet.Blue();
        double stepR = (maxR - minR) / (double)steps;
        double stepG = (maxG - minG) / (double)steps;
        double stepB = (maxB - minB) / (double)steps;
        for (int c=1; c <= steps; c++)
        {
            SetR(minR + (int)round(stepR * c) );
            SetG(minG + (int)round(stepG * c) );
            SetB(minB + (int)round(stepB * c) );
            _delay_ms(5);
        }
        r = maxR;
        g = maxG;
        b = maxB;
    }
}

En dit werkt dus niet meer. De code compileert prima, maar de LED-strip blijft gewoon uit.
Het vreemde is ook, dat het daarstraks, na veel pielen, even perfect gewerkt heeft! Daarna heb ik wat overbodige code weggehaald, de microcontroller opnieuw geprogrammeerd en toen werkte het niet meer. Ook na een aantal keer 'undo' heb ik de code niet meer aan de praat kunnen krijgen.

Iemand enig idee wat er met deze code mis is?

[edit]
Overigens werkt het zo wel weer prima:

C:

int main()
{
    int r = 0;
    int g = 0;
    int b = 0;
    while (true)
    {
        int steps = 100;
        int minR = r;
        int minG = g;
        int minB = b;
        int maxR = 255;//packet.Red();
        int maxG = 255;//packet.Green();
        int maxB = 255;//packet.Blue();
        double stepR = (maxR - minR) / (double)steps;
        double stepG = (maxG - minG) / (double)steps;
        double stepB = (maxB - minB) / (double)steps;
        for (int c=1; c <= steps; c++)
        {
            SetR(minR + (int)round(stepR * c) );
            SetG(minG + (int)round(stepG * c) );
            SetB(minB + (int)round(stepB * c) );
            _delay_ms(5);
        }
        r = maxR;
        g = maxG;
        b = maxB;
    }
}

Het lijkt dus iets met de toekenning van die waarden uit de packet te maken te hebben, maar zonder de 'fade-code' werkt dat perfect.

[ Voor 27% gewijzigd door maikel op 29-12-2010 01:16 ]

[Stoney3K]

Draait dit op een AVR?

Gebruik voor de grap eens float in plaats van double. AVR's zijn maar 8-bit processoren en je kan dus wel eens een mooie stack of register overflow krijgen.

En vergeet niet je float te schalen van 0 naar 255 en terug naar int te casten voor je hem in het register stopt.

[Stoney3K]

dalus schreef op zaterdag 25 december 2010 @ 14:24:
Het is een nogal grote H-brug om solid state een teslacoil aan te kunnen sturen.

Mooi kerstkadootje zo zeg!

Hoeveel stroom kun je met deze kolos nu door je primary heen jagen?

(Overigens +1 voor de watergekoelde heatsink. )

[ Voor 8% gewijzigd door Stoney3K op 29-12-2010 01:21 ]

[maikel]

Stoney3K schreef op woensdag 29 december 2010 @ 01:18:
Draait dit op een AVR?

Gebruik voor de grap eens float in plaats van double. AVR's zijn maar 8-bit processoren en je kan dus wel eens een mooie stack of register overflow krijgen.

En vergeet niet je float te schalen van 0 naar 255 en terug naar int te casten voor je hem in het register stopt.

Het draait inderdaad op een AVR. Helemaal niet aan gedacht dat een double te groot zou zijn.
Ik had ze dus gebruikt omdat de 'round'-functie een double verwacht en teruggeeft. Dan toch eens 'roundf' gaan gebruiken.

Wat bedoel je met het schalen in die laatste zin?

[ Voor 4% gewijzigd door maikel op 29-12-2010 09:43 ]

[Verwijderd]

Ongeacht of je de float of double gebruikt; je trekt de hele math library mee en die kost je een paar k flash. Of dat een probleem is moet je zelf bepalen

Het lijkt ook alsof je ints gebruikt voor een waarde die tussen 0 en 255 moet liggen? In je huidige code kan de waarde die aan de Set functies wordt meegegeven negatief zijn en ik vermoed dat dat een ongeldige waarde is.

[maikel]

De rest van mijn programma is niet zo erg groot, dus die math-library maakt (op dit moment) nog weinig uit. Ik heb nog ruimte genoeg over in het geheugen. En wat is, in het geval het wel een probleem is, een goed alternatief zijn? Zelf een round-functie bouwen?

Die ints moeten inderdaad tussen 0 en 255 liggen. Daar check ik verder nergens op inderdaad, maar ik verstuur gewoon nooit verkeerde waarden, waardoor een negatief getal niet voor zal komen.

Ik blijf het overigens vreemd vinden dat het wel werkt als ik hardcoded '255' in stel, maar via het packet-object niet. Terwijl dat volgens mij exact hetzelfde zou moeten zijn. Toch?

[ Voor 9% gewijzigd door maikel op 29-12-2010 11:13 ]

[DaWaN]

maikel schreef op woensdag 29 december 2010 @ 00:58:
Het lijkt dus iets met de toekenning van die waarden uit de packet te maken te hebben, maar zonder de 'fade-code' werkt dat perfect.

Je code is één grote puinhoop qua datatypes, dat is meestal niet zo slim.

In C is het zo dat de uitkomst van een berekening altijd het type wordt van het kleinste/minst precieze datatype in de berekening. Je kunt dus heel leuk met float's en doubles gaan werken om die vervolgens te vermeningvuldigen met characters, de uitkomst zal dan een character worden.

Ik zal dus als ik jouw was beginnen met alles in de juiste datatypes te gooien, dan na te denken wat de uitkomsten van de berekening moeten worden en dan alle waardes in die berekening te casten naar het datatype van de uitkomst.
Je huidige opzet is in mijn ogen een puinhoop maar GCC is vrij lief qua compileren dus dan werkt het meestal wel, als je dit soort constructies bvb gaat proberen in MCC18 dan wens ik je veel succes....

Ik snap trouwens ook niet helemaal waarom je met floating point getallen aan de slag gaat, de uitkomst (de stappen van het PWM register) zijn toch unsigned chars dus waarom niet gewoon met unsigned chars gaan rekenen ?

Je wordt dus niet gek, je maakt er een puinhoop van en verwacht dat GCC het oplost, meestal doet GCC dat aardig maar zonder je aan de stricte C syntax te houden bevind je je al gauw in een grijs gebied.

[maikel]

Volgens mij valt het met die puinhoop wel mee. Ik gebruik bijna overal int's en een paar doubles (waar ik floats van zal maken). Die gebruik ik overigens omdat de fade-stappen na de deling geen hele getallen zijn. Voordat ik ze mee geef aan de functie om de PWM in te stellen rond ik ze af, cast ik ze naar int en tel de startwaarde er bij op.

Ik ging er overigens wel vanuit dat als een int door een double/float werd gedeeld, de uitkomst ook een double/float zou zijn. Vandaar de cast naar 'double' bij de deling: die stapgrootte wil ik juist niet als geheel getal hebben. Is dat in C niet het geval dan?

Overigens komt het 'rekenen met unsigned chars' op mij juist rommelig over. Rekenen doe ik liever met ints en/of floats ipv chars.

[ Voor 9% gewijzigd door maikel op 29-12-2010 11:44 ]

[gibraltar]

maikel schreef op woensdag 29 december 2010 @ 11:43:
Overigens komt het 'rekenen met unsigned chars' op mij juist rommelig over. Rekenen doe ik liever met ints en/of floats ipv chars.

Het rekenen met floating point values op een AVR is toch behoorlijk langzaam? Dit omdat een AVR core geen floating point arithmetics heeft, en het dus in software doet. En aangezien alle registers toch op zn max 16 bits integers zijn, is het nut toch ook niet zo groot? Kun je beter het probleem schalen naar 16 bits integers.

[ Voor 5% gewijzigd door gibraltar op 29-12-2010 11:56 ]

[DaWaN]

maikel schreef op woensdag 29 december 2010 @ 11:43:
Ik ging er overigens wel vanuit dat als een int door een double/float werd gedeeld, de uitkomst ook een double/float zou zijn. Vandaar de cast naar 'double' bij de deling: die stapgrootte wil ik juist niet als geheel getal hebben. Is dat in C niet het geval dan?

code:

double stepB = (maxB - minB) / (double)steps;

De uitkomst van die berekening is dus een integer, sommige compilers doen er niet moeilijk over maar als je portable C code wilt schrijven moet je er vanuit gaan dat dit een integer oplevert. Wil je een double als uitkomst moet je het volgende doen:

code:

double stepB = (double)(maxB - minB) / (double)steps;

Dit geeft als uitkomst 100% zeker een double. De aftelling (maxB - minB) kan in dit geval prima een integer als geheel blijven, de uitkomst ligt toch in de range van een integer.

gibraltar schreef op woensdag 29 december 2010 @ 11:54:
[...]
Het rekenen met floating point values op een AVR is toch behoorlijk langzaam? Dit omdat een AVR core geen floating point arithmetics heeft, en het dus in software doet. En aangezien alle registers toch op zn max 16 bits integers zijn, is het nut toch ook niet zo groot? Kun je beter het probleem schalen naar 16 bits integers.

Precies en dat is ook mijn punt. Float's gebruiken op een AVR is zoiets als een vrachtwagen huren om een klein pakketje weg te brengen. Je had ook prima een auto kunnen huren; sneller en goedkoper.
Met float's rekenen is totaal niet nuttig als de uitkomst geen float hoeft te zijn, de syntax wordt er ook niet overzichtelijker van (alle casts), om over de code size en snelheid nog maar te zwijgen.

[mux]

Mja, casten middenin een expressie, de hele math package gebruiken voor iets dat je met een beetje slimmer gebruik van variabelen ook had kunnen doen? Doubles, ints en mixed integer/float math..... Dit is rommelig hoor! Nofi, maar dit kan simpeler.

Heb je door dat dit:

code:

double stepR = (maxR - minR) / (double)steps;

een hoeveelheid precedentie veroorzaakt waardoor jij blijkbaar niet meer kunt beredeneren wat hier exact gebeurt? Welke term heeft hier precedentie? Gaat de compiler alsnog (double) steps stilletjes casten naar int om de deling homogeen te krijgen, en dan wederom stilletjes terugcasten naar double om te returnen naar stepR? Je hebt een ambigue situatie gecreëerd!

Je hebt ook een situatie gecreëerd waarin je - zelfs met deze simpele code - niet ondubbelzinnig kunt beredeneren wat de maximale en minimale mogelijke waarde van je variabelen kunnen zijn, en dus of je eventueel ergens wraparound krijgt. Vooral door gebruik te maken van de math package - in dit geval op een redelijk onschuldige manier - introduceer je veel extra (langzame!) code die dingen doet die je op een makkelijkere manier had kunnen doen, namelijk door het slim kiezen van je types en ranges.

edit: spuit 11.

[maikel]

Die doubles/floats gebruik ik omdat de stapgrootte niet altijd een geheel getal is. Als er van bijv. 200 naar 255 moet worden gefade in 100 stappen, zal de stapgrootte 0.55 zijn. Als dat een int zou zijn, werd het 1. Als ik die 1 in de loop 100 keer bij de startwaarde (200) op tel, kom ik op 300 uit. Vandaar dat ik dus een float nodig heb.
Ik zie ook niet echt in hoe ik dat anders zou kunnen doen?

Normaal gesproken ontwikkel ik in C#, waar het volgens mij wel zo is dat de uitkomst bij een deling met een float ook een float oplevert. Vandaar dat ik dat hier in C ook zo gedaan had. Maar ik kan ze dus beter allebei casten, zoals DaWaN ook aangeeft.
En hoe zou ik die floats kunnen voorkomen dan? Volgens mij heb ik ze voor bovenstaande situatie toch echt nodig.

En die eventuele wraparounds komen niet voor, aangezien ik overal in mijn code netjes waarden tussen 0 en 255 gebruik. Alleen als die stapgrootte dus een int zou zijn en naar boven is afgerond kan het voorkomen.

Wat bedoel je met het slim kiezen van de ranges? Ik kan er hooguit een if-statement omheen zetten om de waarden te checken, maar verder kan ik toch niet echt een range kiezen? Of ik moet een ander type kiezen (short int ipv int bijv.).

Nogmaals, ik werk dus normaal in C#, vandaar dat ik gewoon altijd de simpelste manier gebruik. Ik heb ook nog niet echt een idee van alle valkuilen waar ik bij een microcontroller ik kan stappen en hoe deze te ontwijken.

[ Voor 18% gewijzigd door maikel op 29-12-2010 12:48 ]

[Verwijderd]

maikel schreef op woensdag 29 december 2010 @ 12:41:
Die doubles/floats gebruik ik omdat de stapgrootte niet altijd een geheel getal is. Als er van bijv. 200 naar 255 moet worden gefade in 100 stappen, zal de stapgrootte 0.55 zijn. Als dat een int zou zijn, werd het 1. Als ik die 1 in de loop 100 keer bij de startwaarde (200) op tel, kom ik op 300 uit. Vandaar dat ik dus een float nodig heb.

Je kunt ook, als er maar 55 stappen nodig zijn slechts 55 stappen uitvoeren?

[mux]

IMO zou ik gewoon doen:

code:

while(redValue < requestRed) redValue++;

klaar. Geen duizend andere variabelen nodig, geen math nodig, geen casting nodig, lekker simpel. Wat boeit het of het faden af en toe iets langzamer en sneller gaat?

[maikel]

Dat was slechts een voorbeeld natuurlijk. In de uiterste gevallen moet er van 0 naar 255 worden gefade of van bijv. 0 naar 1. Daarbij worden er drie kleuren tegelijk gefade met verschillende waarden, welke wel netjes gelijk moeten lopen.

@mux: Aangezien het voor drie kleuren netjes tegelijk moet gebeuren, kan ik die while-loop niet gebruiken.
Overigens: het faden op zich werkt prima als ik de kleuren hardcoded op geef. Daar gaat dus weinig mis.

[ Voor 30% gewijzigd door maikel op 29-12-2010 12:57 ]

[Verwijderd]

code:

while(true) {
  if (redValue < requestRed) redValue++; 
  if (blueValue < requestBlue) blueValue++; 
  if (greenValue < requestGreen) greenValue++; 
}

Da's toch niet zo moeilijk?

[maikel]

Maar dan is het weer jammer dat als bijv. rood van helemaal uit naar helemaal aan moet gaan en groen van half aan naar helemaal aan, groen veel eerder klaar is.
En zelfs dat stukje zou uitgebreid moeten worden, aangezien het natuurlijk ook voor kan komen dat bijv. rood van helemaal aan, naar helemaal uit moet faden.

Maar nogmaals: het faden zelf is het probleem niet, dat werkt prima als ik de waarden hardcoded in vul. Alleen als ik ze uit mijn packet-object toe ken, doet ie helemaal niets meer. Terwijl dat, tussen al het gekloot door, wel een keertje heeft gewerkt.

[edit]
Het is me gisteren nog gelukt een en ander werkend te krijgen. Het grootste probleem zat 'm eigenlijk helemaal niet in de genoemde code maar meer in het afhandelen van de binnenkomende data en de buffer.
Ik heb overigens wel de code wat verder vereenvoudigd en gebruik nu ook 'unsigned char' ipv 'int', aangezien die precies het juiste bereik heeft: 0...255.

Vanavond nog maar eens wat beter naar die buffer kijken, die kan nog wel wat verbeteringen gebruiken.

[ Voor 44% gewijzigd door maikel op 30-12-2010 12:03 ]

[Ibex]

Bah, twee uur aan het kutten geweest en wat blijkt, ik had een aantal pennetjes van mijn schuifregisters niet goed aangesloten. No shit dat ik rare resultaten kreeg...

Soms werkt het nog steeds het beste om gefrustreerd alle draadjes van het breadboard te rukken en opnieuw te beginnen. En dan kom je aan een bepaalde pin "he, die had ik daarnet anders zitten, even nakijken" (...) *facepalm*

Edit; en zonet ontdekte ik twee LMC7660's in de bus. Met deze lieverd is het toch een pak gemakkelijker om een negatieve spanning te krijgen voor het contrast van mijn lcd .

[ Voor 58% gewijzigd door Ibex op 30-12-2010 21:27 ]