De EL-kroeg - Deel 3 - Modding, mechanica en elektronica

maandag 9 september 2013 10:26

craio schreef op zaterdag 07 september 2013 @ 14:35:
Als een RTCC module (van een PIC) die z'n frequentie krijgt van een extern kristal veel te snel loop( (ongeveer x4) en een probe van een oscilloscoop ertegen houden zorgt dat het wel aan de juiste snelheid werkt.
Betekent dit dan dat de condensatoren erbij te laag zijn? Indien ja, en de condensatoren zijn al wat max aangeraden wordt bij dat kristal, wat moet je dan doen?

Je probe beinvloed je crystal op twee manieren:
-Een impedantie van + naar - aansluitingen van je probe. Staat op je scope/probe hoeveel, meestal 1MOhm oid.
-Capaciteit tussen de twee aansluitingen, staat ook op je probe/scope en is meestal iets van 10-20pF.

Wat je kunt doen is een trimming condensator (0-50pF ongeveer) parallel plaatsen en die gebruiken om heb precies goed te krijgen.

Ctrl+k

Acties:

maandag 9 september 2013 13:00

Sibylle schreef op zondag 08 september 2013 @ 23:27:
[...]

Je probe beinvloed je crystal op twee manieren:
-Een impedantie van + naar - aansluitingen van je probe. Staat op je scope/probe hoeveel, meestal 1MOhm oid.
-Capaciteit tussen de twee aansluitingen, staat ook op je probe/scope en is meestal iets van 10-20pF.

Wat je kunt doen is een trimming condensator (0-50pF ongeveer) parallel plaatsen en die gebruiken om heb precies goed te krijgen.

De oorzaak van mn probleem was dat ik 'load capacitance' van de datasheet zag als welke condensators je moet gebruiken en niet de totale capaciteit die over het xtal moet staan... Maw het moest 12pF zijn in totaal en niet 2 keer 12pF. Ik heb dan die 12pF vervangen door 22pF (heb geen 25pF) en nu klopt het al een stuk beter.
Toch bedankt voor de uitleg!

Acties:

Flake

Kijk, dat verklaart ook een hoop.

Ondertussen, mag ik even slowchat gal spuwen op Lattice? Probeer die Diamond suite binnen te trekken en die site ligt al rustig de hele dag plat met ASP errors.... Vorige week ook al beste tijd onbereikbaar, dat kun je toch niet laten gebeuren als halfgeleiderfabrikant? Sjongejonge

maandag 9 september 2013 18:38

Acties:

Verwijderd

ik heb een ontvangertje met een koptelefoon uitgang.. dat signaal wil ik aan een ADC (mbed) aanbieden.
nu dacht ik erover om een AVC automatische volume control er tussen te zetten, daar de ontvangststerkte maar ook het audiosignaal schommelt wanneer ik mobiel ben.
de meeste schakelingetjes die ik tegenkom werken met een opamp.. en mijn ontvangertje werkt op een 9 v batterijtje.. hoe maak ik -15 +15 van 9 V ? of ken je een AVC schakelingetje dat op een enkele voedingspanning werkt ?

maandag 9 september 2013 20:53

Acties:

maandag 9 september 2013 22:02

Er zijn veel opamps die werken op een single supply, en 9V zal geen probleem zijn.
Wat je zoekt is een 'single supply' of 'single rail' opamp (en daaromheen een AVC).

Je kunt ook zelf eentje maken met een opamp als je graag soldeert.

Ben bestaande single supply (voor)versterker met AVC is bijvoorbeeld:
http://www.spezial.com/co...raege/max9756-max9758.pdf

Ctrl+k

Acties:

Verwijderd

ik zie nu idd een NE5532 .. http://coolarduino.files..../2012/06/audio_input.jpeg

moet eerst nog is eea gaan lezen vrees ik .. ik wil de output van dit ontvangertje aan een mbed 1768 ADC ingang knopen om realtime ontvangen audio te verwerken.

Afbeeldingslocatie: http://i.imgur.com/X7RPQb4.jpg

Afbeeldingslocatie: http://i.imgur.com/X7RPQb4.jpg

2 chinese ontvangertjes en een mexicaans biertje

[ Voor 12% gewijzigd door Verwijderd op 09-09-2013 22:03 ]

dinsdag 10 september 2013 00:23

Acties:

donderdag 12 september 2013 11:57

Aah, lekker knutselen met bier en schetspapier

Loving it

Zelf in elkaar zetten van een schakeling rondom een versterker zoals de MAX9757 (of *56 of *58) is niet zo lastig als je de datasheet hebt: http://datasheets.maximin...en/ds/MAX9756-MAX9758.pdf
Als je niet veel ervaring hebt dan is de kans wel aanzienlijk dat je eindigt met een hoop werk en een groot circuit op een print of breadboard. Als je gewoon wilt dat het werkt en niet per se alles zelf hoeft te solderen dan zou ik zoeken naar een kant en klaar printje.

Je kunt het beste googlen naar iets van: "single supply ALC amplifier board" of "single supply AVC amplifier shield" of iets in die richting. AutomaticLevelControl wellicht voluit schrijven.

[ Voor 5% gewijzigd door Sibylle op 10-09-2013 00:24 ]

Ctrl+k

Acties:

donderdag 12 september 2013 12:23

ik ben inmiddels mijn LED-strip-modules zo ver werkend dat ik met de PC meerdere strips kan aansturen via RS485 en een eigen protocol.

Gisteren heb ik voor het eerst meerdere modules aangesloten, maar liep toen tegen een probleem aan. De eerste module werkte perfect. Nadat ik de tweede had aangesloten vroeg deze netjes om een nieuw ID (doet ie alleen als ID = 0) en werkte daarna prima. De eerste gaf daarna echter geen kik meer.

Nu had ik gemerkt dat ik bij het aansluiten van de tweede module, wel de eerste wat 'over de zeik' heb gebracht doordat ik aan de onderkant van de print wat dingen heb aangeraakt. De LED-strip begon flink te knipperen en had blijkbaar ook een nieuwe kleur in de EEPROM opgeslagen.
Na enige tijd werkte de module ineens wel weer en kwam ik er achter dat deze op de een of andere manier een ander ID had gekregen (ook opgeslagen in de EEPROM). Nadat ik dat gecorrigeerd had, werkte beide modules naar behoren.

Nu vroeg ik me af of het mogelijk is dat door mijn aanrakingen/kortsluitingen de chip andere waarden in het geheugen heeft gekregen en of ik daar in code rekening mee moet houden. Het is uiteraard niet de bedoeling om aan die modules te gaan zitten, maar mogelijk dat andere zaken de modules ook kunnen verstoren. Ik wil het geheel wel robuust hebben.

Mijn protocol bestaat uit:
startbyte | module-type | groep-id | module-id | lengte | commando | <extra parameters>
Het lijkt me dus erg onwaarschijnlijk dat er een packet met exact de juiste waardes is ontstaan door mijn aanrakingen.

Acties:

donderdag 12 september 2013 13:14

Aah, een beetje statische dingetjes of simpelweg een waarde tussen de logic 0 en 1 (1,1 - 2,5 V?) op wat pinnetjes en je kunt rare dingen krijgen. Wellicht is er in het geheugen wat geschoven met bits en krijg je raar gedrag. Dit soort processen kun je beter niet gaan troubleshooten als het niet echt moet en al helemaal niet als je geen goede logic analyser hebt.

Mijn advies is: Controleer even snel alle pull-up/down resistors, zorg dat er geen pinnetjes kunnen 'zweven' tussen de communicatie door. Maak het geheel verder werkend, als je het geheugen niet vertrouwt programmeer het dan allemaal opnieuw en zorg dat je ze niet aanraakt zoals je eerst per ongeluk deed.
Als alles werkt dan de printjes simpelweg beschermen met tape of haarlak (als je niet meer hoeft te solderen) oid. Dan heb je een werkend en robuust systeem

Ctrl+k

Acties:

JER00N

Je protocol maakt ook geen gebruik van een checksum. Wellicht een idee om dat ook nog toe te voegen.

donderdag 12 september 2013 14:06

Acties:

donderdag 12 september 2013 17:25

maikel schreef op donderdag 12 september 2013 @ 11:57:
Nu had ik gemerkt dat ik bij het aansluiten van de tweede module, wel de eerste wat 'over de zeik' heb gebracht doordat ik aan de onderkant van de print wat dingen heb aangeraakt. De LED-strip begon flink te knipperen en had blijkbaar ook een nieuwe kleur in de EEPROM opgeslagen.

Zou niet mogen gebeuren. Misschien te hoge impedantie in een pull-up resistor of een open ingang ergens?

Mijn protocol bestaat uit:
startbyte | module-type | groep-id | module-id | lengte | commando | <extra parameters>
Het lijkt me dus erg onwaarschijnlijk dat er een packet met exact de juiste waardes is ontstaan door mijn aanrakingen.

Dus als een een bitje omvalt in |lengte| dan kun je een buffer overflow krijgen? Dat kan hele vreemde effecten geven. Je kan beter alles in ASCII hoofdletters doen en een start en stopbyte gebruiken.
Mijn protocol is heel simpel:
startbyte (@) | ID (byte 00-FF) | commando(1 letter A-Z) | data | checksum (byte 00-FF) | stopbyte (carriage return)

Dit maakt de interpretatie heel simpel, dat kun je af met een PIC16 microcontroller.
- Bij een startbyte begin je met karakters bufferen
- als geen geldig karakter [0-9,A-Z,@,CR], buffer overflow of uart error, begin dan opnieuw met wachten op startbyte
- als stopbyte ontvangen na een startbyte, dan controleer lengte, ID en checksum en voer commando uit als ok, begin opnieuw

Door het inbouwen van voldoende checks kun je random foute commando's bijna uitsluiten. Dit maakt het ook mogelijk om apparaten met een heel ander protocol of zelfs een andere baudrate op dezelfde bus aan te sluiten.

[ Voor 6% gewijzigd door Ploink op 12-09-2013 14:08 ]

Acties:

donderdag 12 september 2013 17:47

De buffer heeft sowieso een maximum lengte van 40 bytes. Hij zal daar dus niet overheen gaan. Die lengte is er voor om niet onnodig lang te wachten op data. Aangezien ik de waarde voor de LED-strip ook als byte doorstuur, kan die elke waarde van 0 - 255 bevatten. De microcontroller kan dan dus niet zien of het data dan wel de stopbyte is.

Een checksum wil ik inderdaad nog wel toevoegen, maar ben er nog niet helemaal uit hoe ik die het makkelijkst kan berekenen.

Acties:

donderdag 12 september 2013 22:42

Voor zo'n klein projectje heb je dat toch niet nodig...Als het nu gaat over een protocol dat je ontwikkelt voor een bedrijf of voor een product waar honderden van gemaakt worden.

Het is goed om te hebben, en leerzaam, maar het hoeft niet per se. Maak het werkende en dan ben je klaar...

Ctrl+k

Acties:

donderdag 12 september 2013 22:45

Het idee is wel om het op meerdere plaatsen in huis te gaan gebruiken en later op basis hiervan ook een draadloze versie (op 433MHz) te maken. Zeker in dat laatste geval lijkt me een checksum geen overbodige luxe.

Acties:

donderdag 12 september 2013 22:54

Aah, dan sluit ik me aan bij het advies om je protocol wat robuuster te maken ja

Ctrl+k

Acties:

AMD Athlon II M320

Die enkele for loop om XOR checksum te genereren zal toch ook niet het probleem zijn om dat toe te voegen. Ik zou het eerder dom vinden om geen checksum in te bouwen als je iets over de lucht communiceert, kan klok op gelijk zetten dat je data zo nu en dan corrupt zal zijn. 433Mhz is van zich zelf al gammel, dus alle beetje helpen.

Ik zou eigenlijk aanraden om naar 2.4Ghz Nrf2401 over te stappen als dat kan, heb je tenminste frequentie hopping om verstoring tegen te gaan. 433Mhz kan je te gemakkelijk verstoren, als je buurman op zijn kaku drukt zal jij niks meer kunnen verzenden, ligt hele 433Mhz netwerk plat, en buurman kan zijn lamp niet aandoen als jij zend.

vrijdag 13 september 2013 09:43

Acties:

vrijdag 13 september 2013 11:20

Een enkele for-loop voor een XOR checksum? Gewoon een kwestie van elke byte XOR'en dan? Als ik ga zoeken op checksums kom ik al gauw uit bij CRC, maar dat is allemaal wat ingewikkelder als ik het zo lees.

Acties:

AMD Athlon II M320

Zoek dan op XOR checksum.

XOR is hele gebruikelijke(simpelste) manier om iets te versleutelen of checksum te maken, ik wil wel even voorbeeld posten die ik gebruik, zal even twee voorbeelden uit mijn code's vissen, ze geven beide dezelfde uitkomst, gebruikte deze voor internetverbinding tussen arduino en C programma op de pc.

Arduino:

C:

 
int getCheckSum(char *string) {
  int i;
  int XOR;
  int c;
    // Calculate checksum ignoring any $'s in the string
    for (XOR = 0, i = 0; i < strlen(string); i++) {
      c = (unsigned char)string[i];
      if (c == '*') break;
      if (c != '$') XOR ^= c;
    }
  return XOR;
}

C(vb)

C:

 
     public string GetXORChecksum(string sentence) {
            
            int XOR = 0;
            int c;
               // Calculate checksum ignoring any $'s in the string
              foreach (char Character in sentence)
                {
                c = Character;
                if (c == '*') break;
                if (c != '$') XOR ^= c;
                }

            return XOR.ToString();
        }
       
    }

Je gooit je code door de fucntie heen, daaruit komt een getal, die zend je mee naar de andere kant, waar je de data die je ontvangen hebt ook door dezelfde type XOR gooit en dan vergelijk je het getal met het getal dat je mee hebt verzonden van de andere XOR loop, zijn die beide uitkomsten hetzelfde dan is je data valid.

Kind kan de was doen.

vrijdag 13 september 2013 11:52

Acties:

Infant

It's a floating Dino!

In theorie is CRC wat ingewikkelder, maar de implementatie kan heel eenvoudig zijn:

C:

uint16_t crc16_CCIT(uint8_t *data, uint8_t len, uint16_t crc)
{   
    while(len--){
        crc = ((uint8_t)(crc >> 8)) | (crc << 8);
        crc ^= *(data++);
        crc ^= ((uint8_t)crc) >> 4;
        crc ^= crc << 12;
        crc ^= (crc & 0xFF) << 5;
    }
    return crc;
}

Een kortere en snellere versie (zonder lookup) ben ik nog niet tegen gekomen.

Werkt zo:

C:

uint8_t bericht[] = "banaan";

//0x1D0F is de seed, meerdere zijn mogelijk, deze is standaard.
uint16_t check = crc16_CCIT(bericht,6,0x1D0F);

//De uitkomst kan weer als seed gebruikt worden, waardoor je dit kan doen. De uitkomst is hetzelfde als hierboven:
check = crc16_CCIT(bericht,3,0x1D0F); //Len = 3;
check = crc16_CCIT(&bericht[3],3,check ); //Vanaf positie 3 tm het eind.

vrijdag 13 september 2013 12:09

Acties:

AMD Athlon II M320

Ja inderdaad, crc is ook niks meer dan paar regels code, theorie is in begin misschien wat overweldigend maar praktijk is niks meer dan paar regels code met wat shifts en masks.

Ik vind dat als je iets verzend en zeker over de lucht dat je checksum moet inbouwen, en al helemaal als je weet dat je data verstoord kan raken.

Edit/
In de nrf24l01 transceiver zit een hardwarematig crc16 check ingebouwd, hoef je dus niet in de code uit te voeren, niet dat die paar regels code minder zoveel zode aan de dijk zet maar alle beetjes helpen.

[ Voor 25% gewijzigd door mad_max234 op 13-09-2013 12:26 ]

vrijdag 13 september 2013 13:51

Acties:

Cassettebandje

SA-C90 TDK

Let op dat je ondanks dat je CRC klopt nog steeds een fout in je data kunt hebben. Als je data zo fout is dat er hetzelfde CRC uitkomt of als er zowel in je data als in je CRC iets misgaat kun je zomaar een kloppende boodschap hebben die toch niet klopt.
Natuurlijk is de kans klein (bij een 16-bits CRC 1/65535 volgens mijn niet wiskundig onderbouwde inschatting) maar niet volledig afwezig.

vrijdag 13 september 2013 15:45

Acties:

AMD Athlon II M320

Uiteraard, maar is iets complexer dan jij schrijft, want dan zou je 1 op 65k zending dus foute valid geven, maar dat is het dus niet, getal is veel groter, immers zal niet altijd data corrupt zijn, kans dat data corrupt raakt en dan ook nog eens dezelfde uitkomst goede is echt 1 op miljoenen.

vrijdag 13 september 2013 16:03

Acties:

eL_Jay

Ik weet niet of hier de juiste plek is, maar ik vond deze het meest geschikt zonder zelf een topic aan te maken.

Ik heb een 2*molex naar 6 pins pci kabeltje
Afbeeldingslocatie: http://www.power4pc.be/images/jzzn98.jpg

Afbeeldingslocatie: http://www.power4pc.be/images/jzzn98.jpg

Uit elke molex komen drie draadjes (geel,zwart,bruin)

De 2 gele en 2 zwarte gaan mooi naar de 4 hoek pci-pinnetjes, de 2 bruine komen echter samen op 1 van de 2 middelste pinnetjes. Het andere middelste pci-pinnetje is helemaal leeg (ook geen contactje).
Is dit kabeltje defect/fabricagefout of werkt dit gewoon en heb ik maar 5 van de 6 pci-pins nodig om een videokaart van prik te voorzien?

Alvast bedankt voor een reactie

[ Voor 3% gewijzigd door eL_Jay op 13-09-2013 16:11 ]

vrijdag 13 september 2013 16:18

Acties:

Infant

It's a floating Dino!

Cassettebandje schreef op vrijdag 13 september 2013 @ 13:51:
Let op dat je ondanks dat je CRC klopt nog steeds een fout in je data kunt hebben. Als je data zo fout is dat er hetzelfde CRC uitkomt of als er zowel in je data als in je CRC iets misgaat kun je zomaar een kloppende boodschap hebben die toch niet klopt.
Natuurlijk is de kans klein (bij een 16-bits CRC 1/65535 volgens mijn niet wiskundig onderbouwde inschatting) maar niet volledig afwezig.

Dat is dus waar het ingewikkeld word:

Je kiest een type crc aan de hand van de fout die je verwacht: bijv:
Op Flash-kaarten verwacht ik dat er een heel gebied kapot is, dus kies ik een CRC die een reeks fouten kan herkennen.
In de lucht verwacht ik dat er bitjes omkeren, maar niet zozeer heel veel achter elkaar, dus kies ik een crc die goed is in enkele bitfouten herkennen.

CRC-CCIT is oorspronkelijk bedoeld voor modem transmissies, en wordt in bijv.WLAN toegepast, dus zonder verder enige kennis lijkt me dat een aardige keuze voor jouw toepassing.

vrijdag 13 september 2013 17:03

Acties:

vrijdag 13 september 2013 17:31

mad_max234 schreef op vrijdag 13 september 2013 @ 11:20:
Zoek dan op XOR checksum.

XOR is hele gebruikelijke(simpelste) manier om iets te versleutelen of checksum te maken, ik wil wel even voorbeeld posten die ik gebruik, zal even twee voorbeelden uit mijn code's vissen, ze geven beide dezelfde uitkomst, gebruikte deze voor internetverbinding tussen arduino en C programma op de pc.

Arduino:
C:
1
2
3
4
5
6
7
8
9
10
11
12
13
 
int getCheckSum(char *string) {
  int i;
  int XOR;
  int c;
    // Calculate checksum ignoring any $'s in the string
    for (XOR = 0, i = 0; i < strlen(string); i++) {
      c = (unsigned char)string[i];
      if (c == '*') break;
      if (c != '$') XOR ^= c;
    }
  return XOR;
}
C(vb)
C:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
     public string GetXORChecksum(string sentence) {
            
            int XOR = 0;
            int c;
               // Calculate checksum ignoring any $'s in the string
              foreach (char Character in sentence)
                {
                c = Character;
                if (c == '*') break;
                if (c != '$') XOR ^= c;
                }

            return XOR.ToString();
        }
       
    }
Je gooit je code door de fucntie heen, daaruit komt een getal, die zend je mee naar de andere kant, waar je de data die je ontvangen hebt ook door dezelfde type XOR gooit en dan vergelijk je het getal met het getal dat je mee hebt verzonden van de andere XOR loop, zijn die beide uitkomsten hetzelfde dan is je data valid.

Kind kan de was doen.

Ja, dat was dus precies zoals ik het ook had bedacht dan.

Maar wellicht dat ik toch eens naar die CRC ga kijken, aangezien die nog wat robuuster is.

Acties:

vrijdag 13 september 2013 18:43

eL_Jay schreef op vrijdag 13 september 2013 @ 16:03:
Ik weet niet of hier de juiste plek is, maar ik vond deze het meest geschikt zonder zelf een topic aan te maken.

Ik heb een 2*molex naar 6 pins pci kabeltje
[afbeelding]
Uit elke molex komen drie draadjes (geel,zwart,bruin)

De 2 gele en 2 zwarte gaan mooi naar de 4 hoek pci-pinnetjes, de 2 bruine komen echter samen op 1 van de 2 middelste pinnetjes. Het andere middelste pci-pinnetje is helemaal leeg (ook geen contactje).
Is dit kabeltje defect/fabricagefout of werkt dit gewoon en heb ik maar 5 van de 6 pci-pins nodig om een videokaart van prik te voorzien?

Alvast bedankt voor een reactie

Vreemd dat ze afwijkende kleuren hebben toegepast, dat maakt het er niet duidelijker op nee.
Een Molex-aansluiting bestaat uit: +5V, GND, GND, +12V. Een PCI-e power cable gebruikt enkel de +12V en Ground (GND). Rood is normaal gesproken +5V, maar wordt in dit geval niet gebruikt. Dat er een pin mist aan de 12V kant (onderkant van de plug, GND zit aan de bovenkant) kan kloppen, want daar is ook geen noodzaak voor. Twee keer molex maakt twee keer 12V, dus een derde draad maakt geen drol uit. Het is ook bijzonder dat ze wél de GND driemaal doorverbinden (blijkbaar zeer kritiek). Hoe dan ook, dit gaat gewoon prima werken. Je moet de twee molexen wel op verschillende rails aansluiten om er voordeel van te hebben (en niet op dezelfde afgaande kabel van de PSU).

Voor meer info: http://www.playtool.com/p...onnectors.html#pciexpress

My favorite programming language is solder.

Acties:

eL_Jay

Dank, heb het doorgelezen.
Vraag me alleen af hoe ik dit moet interpreteren

If you use an adapter then be sure to plug the 4 pin peripheral connectors into separate cables coming from the power supply. If you plug them both into the same power supply cable then you are drawing all the power of the PCI Express connector through a single 18 gauge wire. You can usually get away with that but there's no reason to do it.

De seasonic g-360 die ik wil gaan halen heeft maar 1 +12v rail met 1 kabel waaraan 3 peripheral female zitten. Daar staat dan weer tegenover dat de +12V (geel) in 16 AWG zijn uitgevoerd ipv 18
http://www.hardwaresecret...ower-Supply-Review/1634/1

Geen idee wat dit allemaal betekend, maar voor mij als leek lijkt me dan dat ik er dan mee weg kom

zaterdag 14 september 2013 00:34

Acties:

zaterdag 14 september 2013 00:39

Waarschijnlijk kom je er mee weg ja, MAAR ik maak hier uit op dat je twee 6-pin PCI connectoren nodig hebt want op die voeding zit er 1. Heb je soms twee videokaarten of een hele zware kaart met twee 6-pin connectoren?

De reden dat er maar een op de voeding zit is uit voorzorg dat je de voeding niet te zwaar gaat belasten. Nu ga jij vals spelen door er nog zo'n connector op te fabrieken!

Ik weet niet hoeveel jouw systeem maximaal belast gaat verbruiken als je alles bij elkaar optelt, maar zou het niet beter zijn om je voeding een maatje zwaarder te kiezen?
Op de 450W versie zitten er twee en dan hoef je niet vals te spelen

Sowieso is het goed om een voeding iets zwaarder te kiezen dan strikt noodzakelijk. Een voeding die langdurig 100% belast is zal minder lang meegaan, zelfs een Seasonic.

[ Voor 4% gewijzigd door Ploink op 14-09-2013 00:38 ]

Acties:

zaterdag 14 september 2013 11:41

eL_Jay schreef op vrijdag 13 september 2013 @ 18:43:
Dank, heb het doorgelezen.
Vraag me alleen af hoe ik dit moet interpreteren

[...]

De seasonic g-360 die ik wil gaan halen heeft maar 1 +12v rail met 1 kabel waaraan 3 peripheral female zitten. Daar staat dan weer tegenover dat de +12V (geel) in 16 AWG zijn uitgevoerd ipv 18
http://www.hardwaresecret...ower-Supply-Review/1634/1

Geen idee wat dit allemaal betekend, maar voor mij als leek lijkt me dan dat ik er dan mee weg kom

Dat is dus wat ik bedoeld met mijn laatste zin:

Je moet de twee molexen wel op verschillende rails aansluiten om er voordeel van te hebben (en niet op dezelfde afgaande kabel van de PSU).

Maar aangezien jouw PSU één enkele 12V rail heeft kan dat dus niet (Er had dus net zo goed één molex kunnen zijn). Het verschil tussen AWG16 en 18 is ongeveer 4A (14A vs 18A). Het mobo kan 75W leveren via het PCI-e 16x slot. Met de 2x3 pin komt hier nog eens 75W bij voor een totaal van 150W. Technisch gezien zou de molex stekker 11A kunnen leveren.

Gebruikte bronnen:
http://www.tomshardware.c...tx-reference,3061-12.html
Wikipedia: PCI Express

edit:
Spuit 11: Ik ben weer eens te langzaam

, ik sluit me verder aan bij Ploink.

[ Voor 3% gewijzigd door Puch-Maxi op 14-09-2013 00:41 ]

My favorite programming language is solder.

Acties:

eL_Jay

Puch-Maxi schreef op zaterdag 14 september 2013 @ 00:39:
[...]

Dat is dus wat ik bedoeld met mijn laatste zin:

[...]

Maar aangezien jouw PSU één enkele 12V rail heeft kan dat dus niet (Er had dus net zo goed één molex kunnen zijn). Het verschil tussen AWG16 en 18 is ongeveer 4A (14A vs 18A). Het mobo kan 75W leveren via het PCI-e 16x slot. Met de 2x3 pin komt hier nog eens 75W bij voor een totaal van 150W. Technisch gezien zou de molex stekker 11A kunnen leveren.

Gebruikte bronnen:
http://www.tomshardware.c...tx-reference,3061-12.html
Wikipedia: PCI Express

edit:
Spuit 11: Ik ben weer eens te langzaam , ik sluit me verder aan bij Ploink.

Ploink schreef op zaterdag 14 september 2013 @ 00:34:
Waarschijnlijk kom je er mee weg ja, MAAR ik maak hier uit op dat je twee 6-pin PCI connectoren nodig hebt want op die voeding zit er 1. Heb je soms twee videokaarten of een hele zware kaart met twee 6-pin connectoren?

De reden dat er maar een op de voeding zit is uit voorzorg dat je de voeding niet te zwaar gaat belasten. Nu ga jij vals spelen door er nog zo'n connector op te fabrieken!

Ik weet niet hoeveel jouw systeem maximaal belast gaat verbruiken als je alles bij elkaar optelt, maar zou het niet beter zijn om je voeding een maatje zwaarder te kiezen?
Op de 450W versie zitten er twee en dan hoef je niet vals te spelen

Sowieso is het goed om een voeding iets zwaarder te kiezen dan strikt noodzakelijk. Een voeding die langdurig 100% belast is zal minder lang meegaan, zelfs een Seasonic.

Dank voor de reacties.
De 450 watt-er is helaas modulair en past niet in de case (itx Node 304). Ik verwacht er een 9870 in te gaan leggen ter vervanging van de 6850 ( vanuit gaande dat die net als de 7870 op de sweetspot van performance per watt ligt, en meer dan 250 euro ga ik nooit voor een videokaart betalen dus de echt dikke videokaarten komen er niet in).
Een 7870 heeft 2 pci 6 pins nodig maar trekt geen 200 watt. De i5 4670 die ik erbij leg + hdd/ssd, 8 gb ram en een itx mobo gaat voor de rest never nooit meer dan 150 watt trekken. Hiermee blijf ik dus zelfs in synthetische run als burntest/furmark combo net binnen de specificatie van de voeding wat betreft wattage . (die volgens verschillende reviews kan pieken op ruim 400, ik verwacht een typische gameload van nog geen 300 watt, spot on op de ideale 80% load voor een voeding)
Aangezien ik nogal geobsedeerd ben door performance per watt wil ik graag een voeding die net voldoende capaciteit heeft, gold certified is en niet modulair is, dan kun je eigelijk niet om deze voeding heen. Alternatief is een 520 watts voeding, maar dan ga ik gewoon zoveel watt extra verstoken

(daarom net mijn seasonic s12ll 520 watt en 2500k de deur uitgedaan)
Tot slot heeft de voeding 5 jaar garantie en heel veel langer was ik hem toch niet van plan te gebruiken.

Long story short, jullie raden me molex naar pci-6-pin af omdat de molex-en op 1 rail/kabel zitten?
(begrijp het technische Ampere verhaal helaas niet, 11 A door de molex klinkt mij namelijk als ruim genoeg om er een kleine 75 watt uit te kunnen persen)

Voor de beeldvorming, zoiets heb ik voor ogen (eventueel haal ik een T of S CPU als jullie denken dat ik daarmee beter 2*6pci-pins van prik kan voorzien:

#	Product	Prijs	Subtotaal
1	Intel Core i5 4670 Boxed	€ 191,73	€ 191,73
1	ASRock H81M-ITX	€ 57,45	€ 57,45
1	Gigabyte GV-R787OC-2GD	€ 196,20	€ 196,20
1	Samsung Spinpoint F1 HD103UJ, 1TB	€ 0,-	€ 0,-
1	Fractal Design Node 304 Zwart	€ 66,50	€ 66,50
1	Corsair Vengeance LP CML8GX3M2A1600C9B Blue	€ 66,99	€ 66,99
1	Seasonic G-Serie 360Watt	€ 58,-	€ 58,-
1	Crucial m4 CT128M4SSD2 128GB	€ 100,10	€ 100,10
Bekijk collectie Importeer producten		Totaal	€ 736,97

[ Voor 34% gewijzigd door eL_Jay op 14-09-2013 11:47 ]

zaterdag 14 september 2013 21:33

Acties:

AMD Athlon II M320

Ben bezig met nieuwe bench power supply, ben dus wat aan testen geweest maar kom er niet helemaal uit, vooral stroommeting gedeelte ben ik nog niet helemaal over uit. Heb vandaag met differential opamp en power weerstand wat lopen spelen, maar is allemaal wat gammel.

Dacht altijd dat als je door 1ohm weerstand 100mA trekt dat voltage drop 100mV zou zijn, circuit in de praktijk(lees samenwerkende met rest van circuits) leert wat anders.

Voltage (V) = Current (I) x Resistance (R)

Maar nu wilt het helemaal niet meer lukken, krijg nu zelfs 5.67v op output en loop al uren te zoeken, alles lijkt(!) goed te zitten, andere opamp geeft zelfde resultaat, tijd om te stoppen en morgen weer verder te kijken, terug naar tekenbord.

Maar had nog wel even vraag voor jullie, willen jullie even meedenken om beter schema te maken. Gebruik nu onderstaand circuit, met lm6062 opamp. Is een single supply opamp, maar zoals de meeste gaan ze niet helemaal rail to rail. Zat dus te denken om de input wat op te tillen zodat die op 2.5v of zo komt te zitten. Filtering, ik heb geen enkele ervaring met differential opstellingen, zie eigenlijk nergens filters, niet nodig bij differential opamp?

Afbeeldingslocatie: http://farm5.static.flickr.com/4089/5087639893_fd04c1ce61.jpg

Afbeeldingslocatie: http://farm5.static.flickr.com/4089/5087639893_fd04c1ce61.jpg

Edit/
Weerstanden zijn 10K, heb ze met de hand gematcht, zitten binnen de 0.1% afwijking, allemaal 9.92K

[ Voor 4% gewijzigd door mad_max234 op 14-09-2013 21:52 ]

zaterdag 14 september 2013 21:52

Acties:

zaterdag 14 september 2013 22:20

99% efficient!

Hah, ziedaar het nut van gespecialiseerde opamps

Je grote probleem is dat dit circuit volledig geswampt wordt door input offset en bias current. Theoretisch zou het moeten werken, maar die 100mV die over je weerstand valt wordt aan alle kanten tegengewerkt: eerst gaat het door niet-perfecte weerstanden heen (die zowel een eigen 'offset' hebben als een temperatuurafhankelijkheid), en vervolgens heeft je opamp geen perfecte 0V output als de input 0V is. Sterker nog, goede kans dat je opamp niet eens lineair genoeg is in het gebied waarin je hem probeert te gebruiken.

Voor elke praktische toepassing (waar je niet vele watts weg kunt gooien in de senseweerstand) kun je beter een current sense amp gebruiken, zoals de INA19x, INA21x of TSC10x

Acties:

AMD Athlon II M320

Was iets te laat met mijn edit, waren tegelijk aan type, was info over de weerstanden vergeten. De weerstanden zullen niet perfect zijn, maar heb ze wel zo goed mogelijk gematcht, maar dat kan dus nog steeds probleem geven?

Wat bedoeld je met swampt?

Ik zorg uiteraard dat ik binnen de specs van de opamp zit met output, LM6062 zou prima moeten werken rond 1v(+-1A heb ik ook getest) met alleen positief rail. LMC6062 kan binnen de 10mv de negatieve rail halen. 100mV zou ook moeten werken. En dat niet 100% lineair ouput heeft met wat offset en error is ook geen probleem in mijn geval, dat valt meer en deel wel op te lossen in de software en hoeft geen 0.5% specs power supply te worden.

Ben de datasheet van de INA19x serie aan lezen, ziet er op eerste gezicht goed uit, alleen de prijs is wat minder.

Edit/
Op eaby kost de ina193 +-3.2 euro, bij mouser 1.91 euro, maar hoef voorlopig niks bij mouser te hebben.

[ Voor 9% gewijzigd door mad_max234 op 14-09-2013 22:26 ]

zaterdag 14 september 2013 22:57

Acties:

Flake

Zou dit theoretisch wel moeten werken? Ervan uitgaande dat R vele male groter is dan Rs (lijkt me logisch) leg je door die deling de + vele malen lager dan de -. Zonder die terugkoppeling zou hij altijd naar negatieve rail klappen en die terugkoppeling verandert daar niet veel aan, beredeneer ik nu ff uit mijn blote hoofd met een biertje op. Sowieso ben ik geen voorstander van schakelingen die compleet uit de maat lopen door toleranties. Wat is er mis met een current sense IC?

zaterdag 14 september 2013 23:16

Acties:

jeronimo

Ik denk dat een AD8210 hier perfect op z'n plaats is.

Dus wat mux ook al aangedragen had. (snel lezen gaat wel, het begrijpen duurt soms wat langer)

[ Voor 26% gewijzigd door jeronimo op 14-09-2013 23:40 ]

zaterdag 14 september 2013 23:48

Acties:

AMD Athlon II M320

@Flake
Ja het zou theoretisch(en ook in de praktijk na wat tweaken) moeten werken volgens mijn. Als je het zo leest word het vrij veel toegepast, heb net nog wat zitten lezen en kijken en heb filmpje van dave jones bekeken en hij doet precies hetzelfde, ga morgen even wat beter bekijken en zijn circuit gewoon nabouwen, waarom wiel opnieuw uitvinden.

Er is niks mis met speciale ic, maar deze onderdelen had ik in huis.

En werkt ook wel maar niet helemaal zoals ik theoretisch had berekend, wellicht is dat te wijten aan mismatch van weerstanden, en niet perfecte eigenschappen van de opamp.

@jeronimo
Bedankt, maar ga denk ik de ani193 eens uitproberen, heb koper gevonden die er 10 stuk voor 8,99 dollar aanbied. Kan de AD8210 helaas ook niet bij dick best of zo krijgen. Zie door opamp bomen het bos niet meer.

Als je toevallig eentje uit je hoofd weet die ze bij dickbest verkopen, moet daar nog wat onderdelen bestellen van de week, maar als ik door lijsten heen blader dan moet ik eigenlijk voor zogoed als elke opamp datasheet erbij pakken, op de bekende na zoal TL, LMC, etc serie.

Edit/
Lol. zie net in filmpje dat dave precies hetzelfde circuit gebruikt als ik, ook 10K en 1ohm.

Dat kan dus niet het probleem zijn lijkt me, zal morgen eens rest van zijn filmpjes bekijken en met frisse blik eens naar mijn eigen circuit.

[ Voor 9% gewijzigd door mad_max234 op 14-09-2013 23:52 ]

zondag 15 september 2013 09:13

Acties:

zondag 15 september 2013 10:09

99% efficient!

Dat Dave Jones het gebruikt wil niet zeggen dat het een goede oplossing is

current sensing met 'normale' opamps werkt alleen als je een hele grote drop over je senseweerstand hebt. Over temperatuur- en spanningsbereik kan je input offset (weerstanden meegerekend) 10-50mV variëren. Wil je zeg 8 bits effectieve ongekalibreerde resolutie, dan moet je dus al gauw 2V full scale over je senseweerstand droppen. Dat is tegenwoordig gewoon niet meer nodig en maakt je circuit alleen maar complex en lomp (met 10W weerstanden en fannetjes enzo).

Met een INAxxx kun je met 10mV full scale nog steeds ~8 bits effectieve resolutie halen, dus kun je 0805 of 1206 senseweerstanden + een sot23 opamp gebruiken. 100% sexy.

Acties:

zondag 15 september 2013 10:37

Om dichterbij de negatieve rail te komen kun je een belasting weestand aan de output hangen.

De opamp heeft een offset spanning van 100uV max, dus dat is op zich probleem niet, Maar de GBW van de CMOS opamp is slechts 100kHz!
Dit betekent dat hoge frequenties voor problemen kunnen zorgen, ik heb dit zelf ondervonden bij een thermokoppel schakeling met een vergelijkbare, misschien wel dezelfde opamp.

Als er hoogfrequente storing op de inputs zit, dan kan de opamp dit signaal niet volgen. De respons als het signaal omhoog gaat is vaak anders dan wanneer het omlaag gaat. Je opamp is dan meer een peak detektor.
Zorg voor voldoende ontkoppeling met condensatoren. Bijvoorbeeld een 100nF over R4 en splits R1 en zet daar ook een 100nF naar ground. Het liefst hou je de impedanties gezien vanaf de inputs gelijk.

Of kijk eens bij Farnell voor een van de 150 Current sense ampilfiers die ze hebben.

Acties:

AMD Athlon II M320

mux schreef op zondag 15 september 2013 @ 09:13:
Dat Dave Jones het gebruikt wil niet zeggen dat het een goede oplossing is current sensing met 'normale' opamps werkt alleen als je een hele grote drop over je senseweerstand hebt. Over temperatuur- en spanningsbereik kan je input offset (weerstanden meegerekend) 10-50mV variëren. Wil je zeg 8 bits effectieve ongekalibreerde resolutie, dan moet je dus al gauw 2V full scale over je senseweerstand droppen. Dat is tegenwoordig gewoon niet meer nodig en maakt je circuit alleen maar complex en lomp (met 10W weerstanden en fannetjes enzo).

Met een INAxxx kun je met 10mV full scale nog steeds ~8 bits effectieve resolutie halen, dus kun je 0805 of 1206 senseweerstanden + een sot23 opamp gebruiken. 100% sexy.

Lees eens goed, dat zeg ik niet, zeg alleen dat het min of meer bewijs is dat het in praktijk zou moeten werken(ik twijfelde beetje al staat internet er vol mee). En daarbij komt nog dat ik allang hebt besloten om current sense opamp's te kopen, zie post terug heb 10 stuk gekocht voor 8.99 dollar.

Maar dat weerhoud me niet om tussentijd voor dat ik de ina193 in huis heb gewoon met opamp verder te gaan experimenteren, waarom, omdat het kan en leuk is.

PS
1ohm is ook best groot, en ik trek al minimale load wat nodig is via circuit, trek al +-20mA via een led in mijn circuit, dus zit altijd al boven de minimale van mijn opamp en daar komt dan nog de gewone load bij die je aan power supply zou willen hangen. Word vervolgd.

En heb meerdere 12bit adc, 10bit pwm(2 bit extension) en 12bit DAC tot mijn beschikking voor dit project. gaan een atxmega32A4U inzetten voor ADC,DAC, PWM doeleinde, atmega is niet geschikt, en heb nog doosje met 25 atxmega32a4u liggen.

Display word een 128x64 gfx lcd, heb die al werkend en voltage word al gemeten, alleen de stroom nog niet.

Edit/
1V is meer dan zat, kan die met 12bit en wat filtering prima op mV uitlezen. Moet wel goede ref hebben uiteraard.

Ploink schreef op zondag 15 september 2013 @ 10:09:
Om dichterbij de negatieve rail te komen kun je een belasting weestand aan de output hangen.

De opamp heeft een offset spanning van 100uV max, dus dat is op zich probleem niet, Maar de GBW van de CMOS opamp is slechts 100kHz!
Dit betekent dat hoge frequenties voor problemen kunnen zorgen, ik heb dit zelf ondervonden bij een thermokoppel schakeling met een vergelijkbare, misschien wel dezelfde opamp.

Als er hoogfrequente storing op de inputs zit, dan kan de opamp dit signaal niet volgen. De respons als het signaal omhoog gaat is vaak anders dan wanneer het omlaag gaat. Je opamp is dan meer een peak detektor.
Zorg voor voldoende ontkoppeling met condensatoren. Bijvoorbeeld een 100nF over R4 en splits R1 en zet daar ook een 100nF naar ground. Het liefst hou je de impedanties gezien vanaf de inputs gelijk.

Of kijk eens bij Farnell voor een van de 150 Current sense ampilfiers die ze hebben.

Die specs was ik beetje vergeten te controleren, zou zomaar kunnen dat ossilator van LM317 via loop bij de opamp komt, is namelijk niet meest nette circuit op experimenteer printje. Zal daar vanmiddag eens mee aan de slag gaan. Had ook wat filtering gevonden in datasheet van ina193, tussen + en - input. Heb wel 0.1uf bij elke ic zitten, maar verder geen filtering op de input.

PS
Farnell heb ik precies hetzelfde probleem als ik bij mouser had, heb niks nodig, heb voorraad al helemaal aangevuld, kom dus nooit aan minimale bedrag. Maar heb via ebay 10 ina193 gekocht, moet nu alleen paar weken wachten.

Edit/
Heb circuit eindelijk werkend.

Heb alle connecties opnieuw laten vloeien en werkt nu wel zoals verwacht, kon geen kortsluiting of lossen connecties meten maar heeft geholpen. Het komt ook redelijk overeen met wat ik zou verwachten, kleine afwijking, maar gebruik ook niet hele nauwkeurige weerstanden. LMC geet ook netjes 19mV uit als verder geen load aan de voeding hangt.

heb dus nu ongeveer
0.002-1A = 0.002-1V

1v / 4096 = 0,0002

Met wat filtering en software trucjes lukt per 1mA uitlezen wel.

Mijn voeding specs moeten worden
12v (10mV stappen)
1A (1mA instelbaar current limiter)

[ Voor 56% gewijzigd door mad_max234 op 15-09-2013 20:20 ]

dinsdag 17 september 2013 17:45

Acties:

dinsdag 17 september 2013 18:42

/me Geeft een rondje.
Door een stomme actie de zekering in mijn Fluke laten klappen

. Duur geintje hoor á €15,- per fuse.
Leuker nieuws: mijn voltage reference is binnen!

Gebaseerd op de Analog Decives AD584LH, goed voor 10.000V, 7.500V, 5.000V en 2.500V. Onze Chinese vrienden hebben er zelfs een meetrapportje bij geleverd

.

edit:
Datasheet: http://www.sal.wisc.edu/P...analogdevices/AD584_b.pdf

[ Voor 12% gewijzigd door Puch-Maxi op 17-09-2013 19:52 . Reden: Datasheet ]

My favorite programming language is solder.

Acties:

dinsdag 17 september 2013 18:45

Puch-Maxi schreef op dinsdag 17 september 2013 @ 17:45:
/me Geeft een rondje.
Door een stomme actie de zekering in mijn Fluke laten klappen . Duur geintje hoor á €15,- per fuse.
Leuker nieuws: mijn voltage reference is binnen!

[afbeelding]

Gebaseerd op de Analog Decives AD584LH, goed voor 10.000V, 7.500V, 5.000V en 2.500V. Onze Chinese vrienden hebben er zelfs een meetrapportje bij geleverd .

Waar heb je een reference 10.000V van 0.15% nauwkeurig voor nodig? Heb je een heel doosje zekeringen gekocht? ;P

Ctrl+k

Acties:

LED-Maniak

Wat dacht je van 10 punt 00000 volt?

Mitsubishi externe temperatuur sensor (Home Assistant compatible): V&A - ClimaControl - Ook voor Panasonic & LG.

dinsdag 17 september 2013 19:19

Acties:

dinsdag 17 september 2013 19:37

LED-Maniak schreef op dinsdag 17 september 2013 @ 18:45:
Wat dacht je van 10 punt 00000 volt?

In ons formaat is dat nog altijd 10,000
KOMMA!

Ctrl+k

Acties:

dinsdag 17 september 2013 19:48

Die mate van nauwkeurigheid heb ik ook zeker niet nodig, ik kan het toch niet meten. In het Chinees staat dat de meting met een HP/Agilent 34401A is uitgevoerd (6½ digit). Nu heb ik een aantal multimeters en ik wilde wel eens weten of ik ze een beetje kon "vertrouwen".

Forum

Vijf decimalen achter de komma idd.

My favorite programming language is solder.

Acties:

Verwijderd

Puch-Maxi schreef op dinsdag 17 september 2013 @ 17:45:
/me Geeft een rondje.
Door een stomme actie de zekering in mijn Fluke laten klappen . Duur geintje hoor á €15,- per fuse.
Leuker nieuws: mijn voltage reference is binnen!

Klinkt bekend... I feel your pain.

[afbeelding]

Gebaseerd op de Analog Decives AD584LH, goed voor 10.000V, 7.500V, 5.000V en 2.500V. Onze Chinese vrienden hebben er zelfs een meetrapportje bij geleverd .

He he he, geweldig!

dinsdag 17 september 2013 20:09

Acties:

ThinkPad

Hé, de UT61E! Die heb ik ook, leuk dingetje

dinsdag 17 september 2013 20:15

Acties:

woensdag 18 september 2013 23:30

Echt een prima dingetje, blijkt nog vrij nauwkeurig ook

. Daarnaast is de resolutie van 22000 counts ook erg welkom.

My favorite programming language is solder.

Acties:

woensdag 18 september 2013 23:52

Aargh! Ik dacht mijn ledstripmodules zo goed als klaar te hebben (inclusief CRC nu

), maar bij het aansluiten van twee modules tegelijk (een gedeelde voeding aanzetten), reageert er steeds maar eentje (de laatste op de bus).

Blijkbaar werkt mijn 'back-off'-code dus niet goed.

C:

    bool freeBus = false;
    while (!freeBus)
    {
        while ( UCSR0A & (1<<RXC0) ); // Wait for empty receive buffer
        delay_us((TYPE * 65025) + (groupId * 255) + moduleId);
        if (!(UCSR0A & (1<<RXC0))) // Wait for empty receive buffer
        {
            freeBus = true;
        }
    }

Mijn idee was dus om:
1. eerst sowieso te wachten tot de receive-buffer leeg was;
2. dan nog iets langer, afhankelijk van zijn eigen ID (bestaande uit module-type, groep-ID en ID). Dit om te voorkomen dat meerdere modules steeds exact even lang wachten
3. en dan nog eens te checken of de receive-buffer leeg is
4. dan pas te gaan zenden

Als ik het zo type, lijkt me dit een prima methode. Toch?

De optie om bij elke binnenkomende bit een timer te starten is niet mogelijk: ik heb alle drie de timers van de Atmega8 al in gebruik om de LED-strip te PWM'en.

[update]

C:

    float bitTimeUs = 1000000/BAUDRATE;
    while ( UCSR0A & (1<<RXC0) ); // Wait for empty receive buffer
    while (!receivingData)
    {
        receivingData = false;
        delay_us(bitTimeUs*8); // wait one byte time
        delay_us((TYPE * 65025) + (groupId * 255) + moduleId); // wait module-specific amount of time
    }

Dit lijkt helaas ook niet te werken:
0. bij elke USART_RX_vect-interrupt wordt 'receivingData' op 'true' gezet
1. wacht tot de receive-buffer leeg is;
2. wacht 8x de bit-tijd;
3. wacht nog wat extra, afhankelijk van het ID;
4. check of 'receivingData' nog steeds 'false' is -> er is dus in de tussentijd geen data binnengekomen

[PS]
Ik zie nu ineens dat ik check op !receivingData...

Dat moet dus precies andersom. Vanavond nog eens testen...

[ Voor 32% gewijzigd door maikel op 19-09-2013 12:01 ]

Acties:

donderdag 19 september 2013 00:09

C:

    bool freeBus = false;
    while (!freeBus)
    {
        delay_us(100);
        if ( !(UCSR0A & (1<<RXC0)) )    freeBus = true;
    }

Werkt dat?

Ctrl+k

Acties:

donderdag 19 september 2013 17:22

Volgens mij krijg ik dan het probleem dat tijdens de verwerking van de binnengekomen byte de receive-buffer leeg is en de bus dus als 'vrij' wordt gezien. Dit terwijl mogelijk de hele packet (variabel aantal bytes) nog niet binnen is.

[ Voor 29% gewijzigd door maikel op 19-09-2013 00:22 ]

Acties:

donderdag 19 september 2013 18:19

Kan iemand mij uitleggen hoe het kan dat ik 8.8V meet op pin 2 van U9? (zie schema)
Op de andere pinnen van U9: pin 3 = 3V3 en pin 1 = 9.1V (van een adapter).
datasheet IC
schema
Ik gebruik een PCB van het schema, dus in principe moeten de verbindingen overeenkomen met het schema.

Acties:

donderdag 19 september 2013 18:45

99% efficient!

Omdat er een charge pump in elke rs-232 transceiver zit?

Acties:

donderdag 19 september 2013 19:04

mux schreef op donderdag 19 september 2013 @ 18:19:
Omdat er een charge pump in elke rs-232 transceiver zit?

Maar als er geen voeding op toekomt (dat is die pin 2) hoe kan dat ding dan die 8V maken?

Acties:

donderdag 19 september 2013 19:11

maikel schreef op woensdag 18 september 2013 @ 23:30:

[update]
C:
1
2
3
4
5
6
7
8
    float bitTimeUs = 1000000/BAUDRATE;
    while ( UCSR0A & (1<<RXC0) ); // Wait for empty receive buffer
    while (!receivingData)
    {
        receivingData = false;
        delay_us(bitTimeUs*8); // wait one byte time
        delay_us((TYPE * 65025) + (groupId * 255) + moduleId); // wait module-specific amount of time
    }
Dit lijkt helaas ook niet te werken:
0. bij elke USART_RX_vect-interrupt wordt 'receivingData' op 'true' gezet
1. wacht tot de receive-buffer leeg is;
2. wacht 8x de bit-tijd;
3. wacht nog wat extra, afhankelijk van het ID;
4. check of 'receivingData' nog steeds 'false' is -> er is dus in de tussentijd geen data binnengekomen

[PS]
Ik zie nu ineens dat ik check op !receivingData... Dat moet dus precies andersom. Vanavond nog eens testen...

Ik heb de code nu iets aangepast:
[update]

C:

    float bitTimeUs = 1000000/BAUDRATE;
    while ( UCSR0A & (1<<RXC0) ); // Wait for empty receive buffer
    while (!receivingData)
    {
        receivingData = false;
        delay_us(bitTimeUs*10); // wait one byte time
        delay_us((TYPE * 65025) + (groupId * 255) + (moduleId*bitTimeUs)); // wait module-specific amount of time
    }

Met de fout eruit lijkt het al iets beter te werken, maar nog steeds niet zoals ik had verwacht. Toen beide modules nog geen ID hadden (en hier elke 5 seconden om gingen vragen), kreeg ik de oproepen netjes na elkaar binnen.
Echter, als ik van allebei tegelijk de status opvraag (dmv een broadcast), krijg ik alleen antwoord van module 1 terug. Wanneer ik de voeding uit en weer aan zet en de modules (exact tegelijk dus) een 'ready' sturen, krijg ik juist eerst de respons van module 2 binnen!

In dit geheel is module 1 trouwens de laatste op de bus.

Heeft iemand enig idee waar dit aan kan liggen? Het is niet erg consequent zo.

Acties:

memphis

48k was toen meer dan genoeg.

craio schreef op donderdag 19 september 2013 @ 17:22:
Kan iemand mij uitleggen hoe het kan dat ik 8.8V meet op pin 2 van U9? (zie schema)
Op de andere pinnen van U9: pin 3 = 3V3 en pin 1 = 9.1V (van een adapter).
datasheet IC
schema
Ik gebruik een PCB van het schema, dus in principe moeten de verbindingen overeenkomen met het schema.

Wat is U9?

Er zijn mensen die mij een GOD vinden

donderdag 19 september 2013 19:14

Acties:

donderdag 19 september 2013 22:27

memphis schreef op donderdag 19 september 2013 @ 19:11:
[...]

Wat is U9?

Gewoon 3 pinnen naast elkaar om voeding te kiezen tussen rechtstreeks (pin 1+2) of via dc-dc converter (pin 2+3) met een jumper.

Acties:

vrijdag 20 september 2013 08:51

craio schreef op donderdag 19 september 2013 @ 17:22:
Kan iemand mij uitleggen hoe het kan dat ik 8.8V meet op pin 2 van U9? (zie schema)
Op de andere pinnen van U9: pin 3 = 3V3 en pin 1 = 9.1V (van een adapter).
datasheet IC
schema
Ik gebruik een PCB van het schema, dus in principe moeten de verbindingen overeenkomen met het schema.

Als ik het goed begrijp voer je dat printje 9V van een adapter, maar de jumper U9 staat op pin 1-2, wat betekent dat de 3.3V spanningsregelaar niet gebruikt wordt en U1 direct 9V krijgt.

Volgens datasheet ST3232: Absolute maximum rating VCC=6V.
Dikke kans dus dat je schakeling nu stuk is.

Acties:

vrijdag 20 september 2013 10:15

Ploink schreef op donderdag 19 september 2013 @ 22:27:
[...]

Als ik het goed begrijp voer je dat printje 9V van een adapter, maar de jumper U9 staat op pin 1-2, wat betekent dat de 3.3V spanningsregelaar niet gebruikt wordt en U1 direct 9V krijgt.

Volgens datasheet ST3232: Absolute maximum rating VCC=6V.
Dikke kans dus dat je schakeling nu stuk is.

Nee, die 8.8V wordt gemeten zonder jumper. Ik heb eerst de pinnen gemeten zonder een jumper om zeker te zijn dat de correcte voltages -wat dus niet het geval is- aanwezig zijn.
Ik heb het PCB 2x bestukt en de tweede toont ook die 8.8V.

Acties:

vrijdag 20 september 2013 10:34

Bij U2 zit een rare knoop. het lijkt alsof Pin11 (T1in) vast zit aan U2 en dus aan de voeding.
Via de interne schottky diode komt dan 9.1-0.3=8.8 V op de 3V3 voeding te staan.

Acties:

vrijdag 20 september 2013 13:48

Ploink schreef op vrijdag 20 september 2013 @ 10:15:
Bij U2 zit een rare knoop. het lijkt alsof Pin11 (T1in) vast zit aan U2 en dus aan de voeding.
Via de interne schottky diode komt dan 9.1-0.3=8.8 V op de 3V3 voeding te staan.

Nee, dat lijkt alleen maar zo. Ik heb het één en ander wat verplaatst.

Acties:

vrijdag 20 september 2013 13:56

Semi-Chinees

Ik heb hier een stel 10W RGB-schijnwerpers liggen die over waren van Ohm2013 en door mij overgekocht zijn. (Thanks, SA007!) Mijn plan is om er een nette RF-bestuurbare driver van te maken. Als ik het goed heb zitten er per kleur drie led-kristallen in serie voor een drempelspanning van plm. 9V; ik ga ervanuit dat ik per kleur iets van 400mA erdoorheen mag knallen. Nou heb ik een aantal opties om 't beest aan te sturen:

• Een 12V voeding gebruiken, voorschakelweerstanden pakken en stomweg gaan PWM'men. Kan... maar ik vind het een beetje jammer dat ik vastzit aan precies 12V ingangsspanning en dat ik 3V 'weggooi'.
• De AVR (die er toch al inmoet) inzetten om een buck-converter te maken. Betekent 3 PWM-uitgangen naar een buck-schakeling die de ingangsspanning omlaaghelpen en een drietal shunts om het geheel door te meten. Ik heb zoiets al wel eens gedaan, maar ben er niet helemaal zeker van dat ik met dat soort general-purpose-onderdelen het beste resultaat krijg.
• Een specifieke chip pakken voor het buck-gedeelte. Maar welke chip is een beetje te krijgen (Farnell/Digikey zijn opties) en goed in te zetten hiervoor?
• Iets compleet anders? Ik sta open voor suggesties

Anyway, hebben jullie hier nog ideeen over?

Relaxen und watchen das blinkenlichten. | Laatste project: Ikea Frekvens oog

Acties:

vrijdag 20 september 2013 14:01

99% efficient!

Er zijn zo ontzettend veel LED-driverchips op digikey en farnell te krijgen... heb je meer specifieke eisen? Wil je persé grote packages of is QFN ook goed, wil je vastzitten aan 12V of liever ook wat hoger kunnen, ga je alleen optisch dimmen of wil je netjes de stroom regelen, wat voor RF-chipset ga je gebruiken?

Acties:

vrijdag 20 september 2013 15:01

Semi-Chinees

Jah, da's 't punt een beetje; ik verdrink in de opties en misschien zijn er wel goede 'go-to' chips bekend.

Even zien... QFN: liever niet: ik wil 't zelf kunnen solderen, maar als 't moet om het goedkoop te doen is qfn prima. Als de chips tot 48V kunnen zou 't leuk zijn: kan ik ze aan PoE hangen

In psiepe is optisch dimmen genoeg; het gaat erom hoe het eruitziet, 't is niets wetenschappelijks ofzo. Mijn plan was om de nRF24L01s te pakken als RF-chips; modules daarvan kosten geen drol en zijn effectief genoeg.

Ah, om het moeilijk te maken: de LEDs zijn common-anode; ik geloof dat ik dus niet zomaar even drie 1-kanaals drivers in kan zetten...

[ Voor 11% gewijzigd door Sprite_tm op 20-09-2013 14:11 ]

Relaxen und watchen das blinkenlichten. | Laatste project: Ikea Frekvens oog

Acties:

memphis

48k was toen meer dan genoeg.

Als je de sturing ook al een PWM signaal mee geeft doe je er verstandig aan om gewoon lineair te werken. Toevallig ben ik nu ook met 9V 500mA LED's bezig die vanaf een 12v LED voeding gevoed gaan worden. Ik gebruik gewoon 6.8 ohm 3watt weerstanden.

Afbeeldingslocatie: http://www.euronet.nl/users/tooms/f1light/printjes.jpg

Afbeeldingslocatie: http://www.euronet.nl/users/tooms/f1light/printjes.jpg

Er zijn mensen die mij een GOD vinden

dinsdag 24 september 2013 08:07

Acties:

dinsdag 24 september 2013 08:40

maikel schreef op donderdag 19 september 2013 @ 19:04:
[...]

Ik heb de code nu iets aangepast:
[update]
C:
1
2
3
4
5
6
7
8
    float bitTimeUs = 1000000/BAUDRATE;
    while ( UCSR0A & (1<<RXC0) ); // Wait for empty receive buffer
    while (!receivingData)
    {
        receivingData = false;
        delay_us(bitTimeUs*10); // wait one byte time
        delay_us((TYPE * 65025) + (groupId * 255) + (moduleId*bitTimeUs)); // wait module-specific amount of time
    }
Met de fout eruit lijkt het al iets beter te werken, maar nog steeds niet zoals ik had verwacht. Toen beide modules nog geen ID hadden (en hier elke 5 seconden om gingen vragen), kreeg ik de oproepen netjes na elkaar binnen.
Echter, als ik van allebei tegelijk de status opvraag (dmv een broadcast), krijg ik alleen antwoord van module 1 terug. Wanneer ik de voeding uit en weer aan zet en de modules (exact tegelijk dus) een 'ready' sturen, krijg ik juist eerst de respons van module 2 binnen!

In dit geheel is module 1 trouwens de laatste op de bus.

Heeft iemand enig idee waar dit aan kan liggen? Het is niet erg consequent zo.

Niemand?

Acties:

dinsdag 24 september 2013 09:54

Het is extreem moeilijk om zo op afstand te troubleshooten

Je broadcast reply lijkt dus niet lekker te werken, ofwel doordat de software het niet goed doet, ofwel doordat er hardwarematig iets botst.
Dus probeer eens te controleren of de broadcast overal goed aankomt, schakel module 1 eens uit en kijk of dat #2 antwoord stuurt (en #3 niet etc.).

Ctrl+k

Acties:

woensdag 25 september 2013 19:50

Semi-Chinees

maikel schreef op dinsdag 24 september 2013 @ 08:07:
[...]

Niemand?

Wat ik sowieso zie is dat je _delay_us een berekening voert. Iig in de oudere versies van avrlibc is dat niet slim; _delay_us is namelijk een soort-van macro die alleen de juiste delay geeft als je er een constante waarde (of iets wat door de compiler tot een constante waarde te reduceren is) eraan geeft. Je kan beter een _delay_us(bittime) in een for-loopje gooien.

Nevertheless, vziw heeft dit alleen tot resultaat dat je delay _langer_ word dan je wil, wat je symptomen nog niet verklaart.

Relaxen und watchen das blinkenlichten. | Laatste project: Ikea Frekvens oog

Acties:

WVL_KsZeN

@sprite : kun je niet een dc-dc convertertje inzetten om je spanning omlaag te brengen naar 9V? (of zeg 9.5V, dan stook je de resterende 0.5V weg in een weerstandje).

Voor mijn eigen projectje (gebaseerd op 5V) wil ik ook een paar DC-DC convertjes inzetten om efficiënt een geschikte spanning voor LED's te maken.

/me heeft eindelijk ook een icoontje.. woef.. boeien..

woensdag 25 september 2013 22:33

Acties:

woensdag 25 september 2013 23:05

Ik heb weer een en ander zitten zoeken en één ding wat sowieso gedoemd is te mislukken, is die hele formule als parameter meegeven aan een functie die een uint16 verwacht.
Met de waarden type=1, groep=1 en module=1, gaat dat nog net: (1 * 65025) + (1 * 255) + (1*(1000000/57600)) = 65297.
Maar bij een module uit groep 2 wordt het al: (1 * 65025) + (2 * 255) + (1*(1000000/57600)) = 65552. Dat gaat natuurlijk niet passen! Het verklaart alleen ook nog niet waarom het nu met twee modules niet goed werkt.

Nu kan ik dit natuurlijk makkelijk in een loopje gooien om van dit probleem af te komen, maar dan nog staat die module uit groep 2 (zelfs al is er geen andere module aan het zenden!) 65552us te wachten. Met een ander type module gaat het natuurlijk helemaal lang duren.

Ik zat dus te denken om die tijd te verkorten, maar kan zo gauw geen formule bedenken die er zeker voor zorgt dat twee of meer module niet exact even lang wachten. In theorie kunnen er 255 types, 255 groepen per type en 255 modules per groep zijn. Dat zijn dus 16581375 mogelijke modules. Volgens mij ontkom ik er dus niet aan om 1 module minimaal 16s te laten wachten. (En dan ga ik nog uit van de bit-tijd en is er dus maar 1 bit de tijd om te checken of een andere module aan het verzenden is.)
Op zich is dat niet erg, als er gedurende die 16s maar wel andere modules 'aan het woord' zijn. Als dit de enige module is, wil ik niet dat ie 16s voor niks staat te wachten.

Of mis ik nog een of andere ingenieuze constructie?

[ Voor 13% gewijzigd door maikel op 25-09-2013 23:02 ]

Acties:

ThinkPad

Toevallig iemand hier met een IKEA Tanda schakelklok? Die dingen kosten bijna niks, en zijn ideaal om stroom te besparen ('s nachts PC hoek van stroom af, tv meubel uitschakelen etc), maar ik vroeg mij af of ze veel lawaai maken. Heb vroeger ook eens een schakelklok gehad (wel echt een heel oud ding) en die tikte best wel hard... Voor in de slaapkamer is dat niet wenselijk

Edit: Denk zelfs dat ik deze haal, nog goedkoper (2,33 per stuk vs 2,495)

[ Voor 17% gewijzigd door ThinkPad op 25-09-2013 23:10 ]

donderdag 26 september 2013 10:31

Acties:

AMD Athlon II M320

Koop digitale bij blokker voor 5 euro, tikt sowieso niet, en je hebt veel meer instelmogelijkheden, mocht je ze voor iets anders willen gebruiken, stel je wilt maandag om 23 uur de pc uit, maar dinsdag ben je hele dag niet thuis, stel je in dat die dinsdag hele dag uit moet zijn, etc. Dat kan met digtale, maar niet met mechanische, mechanische zijn dom en kunnen maar voor 1 dag instellen.

Dat kan met veel digitale schakelklokken, en kosten bij blokker, action en dergelijke winkels, zijn ook maar iets van 5 euro. Zijn dus wel wat duurder dan mechanische, maar dat je krijgt er ook meer voor terug en ze zijn muisstil.

Edit/
@maikel
stap toch over op zenders die daarvoor gemaakt zijn, 433Mhz is niet echt geschikt voor netwerk, is geschikt voor point to point verbinding en niet echt geschikt voor netwerk. Je moet iets hebben met meerdere kanalen, die elkaar dus niet in de weg gaan zitten.

En hoe haal je de data nu binnen, polling of pushing?

[ Voor 30% gewijzigd door mad_max234 op 26-09-2013 10:44 ]

donderdag 26 september 2013 11:36

Acties:

donderdag 26 september 2013 12:23

Semi-Chinees

WVL_KsZeN: Zoiets zou kunnen, maar is lastiger dan je zou denken. Als ik een standaard DC-DC-converter zou gaan gebruiken om de spanning naar een vaste 9.5V toe te brengen en daarna een serieweerstand zou gebruiken om de stroom te beperken, is de stroom door het geheel nogal gevoelig voor de spanning. Stel, door temperatuurverschillen gaat de drempelspanning van de LED 0.25V omlaag, dan gaat er ineens 50% meer stroom lopen. Dat wil je niet

maikel: Kan je je dingetjes niet on the fly een tijdelijk adres geven? Je zou dus in de eerste instantie, bij het 'aanmelden' van een ding, gewoon random backing off kunnen gebruiken om een lekkere communicatie te garanderen. Daarna geef je vanuit je basisstation je node een tijdelijk adres wat gewoon incremental is, en dan kan je daarna gewoon dat * message size afwachten.

mad_max234: Mijn excuses, maar da's bullshit. WiFi is ook (per access point) een enkel kanaal die vaak overboekt is door andere kanalen en magnetrons en dat gaat ook prima. Je maakt het wel moeilijker als je packetization etc in softeware wilt doen, maar da's een designkeuze en geen flaw.

Relaxen und watchen das blinkenlichten. | Laatste project: Ikea Frekvens oog

Acties:

donderdag 26 september 2013 12:41

Semi-Chinees

Ow, ik ben het er absoluut mee eens dat dedicated chipjes beter zijn, don't get me wrong, maar je originele text impliceerde een beetje dat het onbegonnen werk is om met 433MHz meerdere nodes op te zetten. De problemen die je nu aandraagt zijn echter dingen die die 433MHz-modules in z'n algemeenheid missen; als je die op de koop toeneemt is het enige verschil tussen een oplossing daarmee en een nRF24l01 oid het feit dat je zelf moet packetizen ed.

Ben er trouwens achter dat de common-anode-ness van mijn RGB-schijnwerpertjes ongedaan te maken is: de 3 anodes komen in de vorm van een metalen E naar buiten. Als je dat erafknipt houd je netjes drie metalen pinnetjes over waar de individuele anodes op staan. Ik denk dat ik daarom ook gewoon netjes dat ga doen en drie A6211's op mijn driverprint ga gooien: die krengen kosten maar EUR0.75/stuk en hebben meteen een interne mosfet en een lekker hoge pwmfrequentie waardoor mijn spoelen klein kunnen blijven; kans is dus aanwezig dat dat zelfs goedkoper is dan een discrete oplossing.

Relaxen und watchen das blinkenlichten. | Laatste project: Ikea Frekvens oog

Acties:

donderdag 26 september 2013 13:14

mad_max234 schreef op donderdag 26 september 2013 @ 10:31:
...
Edit/
@maikel
stap toch over op zenders die daarvoor gemaakt zijn, 433Mhz is niet echt geschikt voor netwerk, is geschikt voor point to point verbinding en niet echt geschikt voor netwerk. Je moet iets hebben met meerdere kanalen, die elkaar dus niet in de weg gaan zitten.

En hoe haal je de data nu binnen, polling of pushing?

Ik gebruik op dit moment nog helemaal geen zenders. Alle communicatie verloopt via een kabel.
Vanaf de PC verstuur ik een commando om een ledstrip-module een kleur te geven. Daarop krijg ik een 'ACK' terug. Echter, ik wil ook meerdere modules tegelijk aan kunnen sturen door middel van een groep-id. Dan zijn er dus meerdere modules die exact op hetzelfde moment een 'ACK' terugsturen.
Bovendien wil ik alle soorten modules in m'n netwerk (op dit moment alleen nog ledstrip-modules, maar in de toekomst ook bijv. een lichtsensor) tegelijk om hun status gaan vragen om zo te zien wat er is aangesloten/aan staat.

Ook geven de modules nu bij het inschakelen allemaal even een berichtje 'ready'. Als ik dus meerdere modules op 1 voeding heb zitten, worden die berichten ook tegelijk verstuurd.

Vandaar dus dat ik op zoek ben naar een manier om ervoor te zorgen dat ze allemaal checken of de lijn vrij is en, als dat niet het geval is, niet allemaal even lang wachten.

Sprite_tm schreef op donderdag 26 september 2013 @ 11:36:
...
maikel: Kan je je dingetjes niet on the fly een tijdelijk adres geven? Je zou dus in de eerste instantie, bij het 'aanmelden' van een ding, gewoon random backing off kunnen gebruiken om een lekkere communicatie te garanderen. Daarna geef je vanuit je basisstation je node een tijdelijk adres wat gewoon incremental is, en dan kan je daarna gewoon dat * message size afwachten.

...

Dat is in principe wat ik nu doe. Het probleem is alleen dat het 'echte' ID uit drie bytes bestaat: module-type (ledstrip=1), groep-id, module-id. In theorie zijn er dus 255*255*255 mogelijke modules (ik verwacht niet dat ik ooit zoveel in elkaar ga knutselen, maar het zou kunnen

). Om het ID echt uniek te houden, heb ik dus deze formule: (type*255*255) + (groep-id * 255) + module-id
Wat meer aannemelijk is, is dat er nieuwe types bijkomen. Met deze formule loopt de wachttijd dan per nieuw type met stappen van 65025 tegelijk op.

Maar volgens mij ontkom ik daar dus niet aan. Met alle andere manieren om een wachttijd te berekenen, is er een kans op twee exact dezelfde tijden en zouden die twee modules dus alsnog exact tegelijk gaan zenden.

Ik heb nog wel zitten denken om het idee van een echte broadcast te laten varen en alleen aanspreken per groep mogelijk te maken. Dan valt het eerste stukje van de formule weg. Alleen zou dat nog steeds niet werken als ik verschillende modules achter 1 schakelaar heb hangen.

[ Voor 34% gewijzigd door maikel op 26-09-2013 12:49 ]

Acties:

donderdag 26 september 2013 13:14

Semi-Chinees

Mijn punt is dus dat je die grote wachttijd kan voorkomen door tijdelijke IDs uit te geven die bijvoorbeeld maximaal een byte groot zijn en lekker numeriek oplopen (1, 2, 3, ... onafhankelijk van het 'echte' ID van de module). Deze zijn dan niet globaal uniek, maar uniek voor de sessie; zodra een nieuw apparaat zich aanmeld krijgt 'ie tot een powerdown zo'n tijdelijk ID. De communicatie gebeurt daarna met de tijdelijke IDs. Als je adv daarvan de wachttijd berekent, kom je dus uit op een wachttijd van maximaal de hoeveelheid aangesloten apparaten ipv maximaal 256*256*256.

Met dat ID zit je nog wel met het probleem dat je moet broadcasten naar modules die geen tijdelijk ID hebben om te kijken of er nieuwe modules zijn en ze een tijdelijk ID te geven. Dat probleem kan je aanpakken door (veel minder vaak) te scannen op je oude manier, of je kan een meer standaard methode zoals random backing off gebruiken.

Relaxen und watchen das blinkenlichten. | Laatste project: Ikea Frekvens oog

Acties:

donderdag 26 september 2013 15:22

Heb je al eens naar DMX512 gekeken?
Het is bij uitstek bedoeld voor verlichting en er is veel commerciële apparatuur voor beschikbaar zoals LED drivers, lampen en en mengpanelen. Misschien kun je jouw systeem op de een of andere manier compatibel maken.

mad_max234 schreef op donderdag 26 september 2013 @ 10:31:
Vanaf de PC verstuur ik een commando om een ledstrip-module een kleur te geven. Daarop krijg ik een 'ACK' terug. Echter, ik wil ook meerdere modules tegelijk aan kunnen sturen door middel van een groep-id. Dan zijn er dus meerdere modules die exact op hetzelfde moment een 'ACK' terugsturen.

Gewoon geen ACK sturen indien broadcast/multicast, dan ben je van het probleem af. Voor een bedraad systeem is dat betrouwbaar genoeg.

[ Voor 47% gewijzigd door Ploink op 26-09-2013 13:22 ]

Acties:

donderdag 26 september 2013 15:54

Sprite_tm schreef op donderdag 26 september 2013 @ 13:14:
Mijn punt is dus dat je die grote wachttijd kan voorkomen door tijdelijke IDs uit te geven die bijvoorbeeld maximaal een byte groot zijn en lekker numeriek oplopen (1, 2, 3, ... onafhankelijk van het 'echte' ID van de module). Deze zijn dan niet globaal uniek, maar uniek voor de sessie; zodra een nieuw apparaat zich aanmeld krijgt 'ie tot een powerdown zo'n tijdelijk ID. De communicatie gebeurt daarna met de tijdelijke IDs. Als je adv daarvan de wachttijd berekent, kom je dus uit op een wachttijd van maximaal de hoeveelheid aangesloten apparaten ipv maximaal 256*256*256.

Met dat ID zit je nog wel met het probleem dat je moet broadcasten naar modules die geen tijdelijk ID hebben om te kijken of er nieuwe modules zijn en ze een tijdelijk ID te geven. Dat probleem kan je aanpakken door (veel minder vaak) te scannen op je oude manier, of je kan een meer standaard methode zoals random backing off gebruiken.

In principe geef ik alle modules al wel een netjes oplopend id hoor, dus het probleem is ook meer theoretisch. Het zal in de praktijk pas echt een issue worden als ik gigantisch veel modules aan sluit, wat niet zal voorkomen.
Als ik ze een tijdelijk id geef, dat geldig is tot aan de power-down, maakt dat toch geen verschil? Tenzij ik daarbij het module-type en de groep laat varen en ze dus zo nummer:

code:

type  groep  id | nieuw id
--------------------------------------
1      1      1 | 1
1      1      2 | 2
1      2      1 | 3
2      1      1 | 4
2      2      1 | 5

Maar dan weet ik dus op de PC niet meer wat welke module precies is. Daarnaast moet ik er voor zien te zorgen dat alle modules een eigen ID krijgen en kan ik dus maar maximaal 255 modules aansluiten.

DMX ken ik inderdaad, maar kan niet echt vinden hoe daar 'collision avoidance' is geimplementeerd.

Het idee om geen 'ACK' te sturen, heeft niet veel nut. Ik stuur soms ook een broadcast met 'wat is jullie huidige status' of 'wie is er allemaal'. Als ik dan geen antwoord terug krijg, schiet ik daar weinig mee op. Of ik zou dan juist moeten gaan pollen, maar dat is ook zo'n verspilling van bandbreedte/tijd.

Ik zit nu wel te denken of ik niet iets slims kan doen met het feit dat alle modules ook het ID van de verzendende module binnen krijgen. Daaraan kunnen ze dus zien of hun voorganger aan het verzenden is. Als dat niet het geval is, kunnen ze al zonder extra te hoeven wachten. Alleen zal de daaropvolgende module natuurlijk hetzelfde denken en beginnen ze alsnog tegelijk.

[ Voor 9% gewijzigd door maikel op 26-09-2013 15:48 ]

Acties:

Infant

It's a floating Dino!

Misschien kun je een delay ook doen aan de hand van een hash functie:

Stel dat je maximaal 500us wilt wachten, dan hash je een blok data waar je id, type groep en misschien wat ad inputs om het extra willekeurig te maken.

En die hash neem je dan de mod 500 van. Klaar.

C:

#define DELAY_MAX 500
uint8_t dev_id = 0x02;
uint8_t dev_group = 0x01;
uint8_t dev_type = 0x01;
uint8_t data[5];

data[0] = dev_id;
data[1] = dev_group;
data[2] = dev_type;
data[3] = adread(TEMPERATURE); //Als je dat hebt?
data[4] = adread(AD1); //Als je dat hebt?

uint16_t val = crc(data,5,0xFFFF);
val = val % DELAY_MAX ;
while(val--){
    _delay_us(1);
}

donderdag 26 september 2013 16:01

Acties:

donderdag 26 september 2013 16:27

Dat is op zich geen slecht idee, nee. Zelfs zonder die AD-inputs (die ik wel heb overigens) kan het al werken. Het enige puntje is dan dat er nooit een module is die direct reageert (de kans dat er uit die hash precies 0 komt, is erg klein), maar altijd een bepaalde tijd wacht. Wel kan ik die tijd natuurlijk verkorten door de DELAY_MAX te verkleinen. Als ik die dan af en toe door de PC laat aanpassen, afhankelijk van hoeveel modules er zijn, heb ik het vrij optimaal volgens mij.

En ik bedenk me ook net dat ik die delay alleen nodig heb als het om een (groeps-)broadcast gaat. Anders mag er meteen een antwoord komen.

Acties:

Rusky

Ben op zoek naar een tijd relais voor 5volt. Ben op zoek naar een multifunctioneel tijd relais met een schakelmogelijkheid van 230V en 10A. En een afvalvertraagd relais en die mag gewoon 5v schakelen.
Kon zelf niks vinden op ebay of google.

mijn pc

donderdag 26 september 2013 16:30

Acties:

Kaj.

1 LED is niet genoeg

Wat wil je nu schakelen: 5v of 230v? Wat is je voedingsspanning? Hoe wil je hem sturen/activeren?

donderdag 26 september 2013 16:30

Acties:

donderdag 26 september 2013 16:31

99% efficient!

Met afval, zo te lezen...

Acties:

Rusky

Kaj. schreef op donderdag 26 september 2013 @ 16:30:
Wat wil je nu schakelen: 5v of 230v? Wat is je voedingsspanning? Hoe wil je hem sturen/activeren?

sturen met 5 volt en schakelen 230V

mijn pc

donderdag 26 september 2013 17:10

Acties:

memphis

48k was toen meer dan genoeg.

Rusky schreef op donderdag 26 september 2013 @ 16:27:
Ben op zoek naar een tijd relais voor 5volt. Ben op zoek naar een multifunctioneel tijd relais met een schakelmogelijkheid van 230V en 10A. En een afvalvertraagd relais en die mag gewoon 5v schakelen.
Kon zelf niks vinden op ebay of google.

Zat van dat soort kitjes te vinden bij ded Conrad of Velleman.
http://www.conrad.nl/ce/n...category&rt=category&rb=1
http://www.conrad.nl/ce/n...V-Tijdbereiken-05-s-150-s
Gewoon daarachter gewoon 5 of 6v relais of een solid state relais koppelen.

[ Voor 11% gewijzigd door memphis op 26-09-2013 17:12 ]

Er zijn mensen die mij een GOD vinden

donderdag 26 september 2013 21:01

Acties:

donderdag 26 september 2013 21:48

maikel schreef op donderdag 26 september 2013 @ 15:22:
[...]

DMX ken ik inderdaad, maar kan niet echt vinden hoe daar 'collision avoidance' is geimplementeerd.

Niet. Het is allemaal eenrichtingsverkeer, zonder ACK.
Het voordeel is dat je niet alles apart hoeft te adresseren, maar dat je per lamp/LED/dimmer slechts 1 byte hoeft te versturen. Daarmee kun je bijna 50x per seconde 512 lampen updaten, leuk voor als je dynamische LED licht effecten over een hele wolkenkrabber wil maken.

maikel schreef op donderdag 26 september 2013 @ 12:41:
Vandaar dus dat ik op zoek ben naar een manier om ervoor te zorgen dat ze allemaal checken of de lijn vrij is en, als dat niet het geval is, niet allemaal even lang wachten.

Jij zoekt de CAN bus. Dat is zo robuust dat het gebruikt wordt in elke moderne auto met motor management. Zelfs met gelijkwaardige nodes, dus ook zonder expliciete master/slave relatie zijn collisions onmogelijk. Microchip, Atmel en vele anderen maken microcontrollers met ingebouwde CAN interface.

Acties:

AMD Athlon II M320

Sprite_tm schreef op donderdag 26 september 2013 @ 11:36:

mad_max234: Mijn excuses, maar da's bullshit. WiFi is ook (per access point) een enkel kanaal die vaak overboekt is door andere kanalen en magnetrons en dat gaat ook prima. Je maakt het wel moeilijker als je packetization etc in softeware wilt doen, maar da's een designkeuze en geen flaw.

Je hebt geen multikanalen en frequentie hopping bij 433Mhz, wel bij de 2.4Ghz transceiver die ik eerder voorsloeg(wifi overigens ook), die heeft 6 kanalen(van de totaal 126) waarop die kan ontvangen met 6 verschillende id's(transceiver). En word allemaal hardwarematig geregeld door de transceiver, komt er hoop software tijd vrij van je uC. Ook CRC16 kan die hardwarematig doen, ook dat kan uit de code gehaald worden.

En ze kosten bijna niks meer dan 433mhz setje(zender en ontvanger), 2.50 euro voor setje van 2 transceiver. Nog een voordeel is dat data 2 kanten op gaat, in tegenstelling van 433Mhz setje wat maar 1 weg is.

Edit/
http://www.nordicsemi.com...ct_Specification_v2_0.pdf

Ze noemen het: 6 data pipe MultiCeiver.

Simpel gezegd kan met 1 transceiver samen met 6 andere een netwerk maken, en je kan tegelijk data ontvangen(ook zenden) van alle 6 de transceivers. Uiteraard kunnen ze ook allemaal apart aangesproken worden in het netwerkje, en je kan ten alle tijd altijd on the fly switchen naar andere configuratie.

Overigens kan het netwerk veel groter zijn dan 6 apparaten, je kan er heel veel met elkaar in netwerk laten samenwerken.
http://maniacbug.wordpress.com/2012/03/30/rf24network/

@maikel
Ik was laatst toen we het over checksum hadden overtuigd dat je 433Mhz zender ging gebruiken, of vergis ik me nu?

[ Voor 28% gewijzigd door mad_max234 op 27-09-2013 13:10 ]

vrijdag 27 september 2013 01:36

Acties:

wetsteyn

Hoi,

Iemand hier die mij kan helpen? V&A gevraagd: Flashen BFL jalapeno ? let me know thanks!

*neem aan dat dit mag?*

8*250wp Garage 12*290wp Zolder

vrijdag 27 september 2013 09:27

Acties:

vrijdag 27 september 2013 09:56

mad_max234 schreef op donderdag 26 september 2013 @ 21:48:
[...]

...
@maikel
Ik was laatst toen we het over checksum hadden overtuigd dat je 433Mhz zender ging gebruiken, of vergis ik me nu?

Dat is een waarschijnlijke toekomstige uitbreiding.

Er werd toen gezegd dat CRC niet echt nodig is, vandaar dat ik zei dat ik het wellicht in de toekomst draadloos wil maken en CRC dus wel handig is.
Maar eerst via een kabeltje maar eens aan de praat zien te krijgen.

[ Voor 16% gewijzigd door maikel op 27-09-2013 09:28 ]

Acties:

AMD Athlon II M320

My bad, maar dan heb je de info alvast voor de toekomst.

Edit/
Kwam net wat nieuws tegen, FTDI gaat videochip uitbrengen, FT800 EVE. Zit ook DPS in voor audio verwerking. Dat scheelt hoop resource van je uC, zoals atmega, pic, etc simpel uC zonder lcd controller.

including Audio and Touch controller (4-wire)
enables to create an affordable graphic output with minimal requirements for a Host processor
suitable also for slower microcontrollers like AtMega328, PIC, 8051,...
powerful graphic ship „3in1“ with a 6-bit output (RGB-6,6,6)
Anti-Aliasing, Alpha blending and masking algorithms
graphic controller with a clock (timing) generator
frame buffer
memory (registers, ROM, RAM)
graphic processor and co-processor
MCU interface (I2C, SPI) and other blocks.

http://www.soselectronic....Embedded_Video_Engine.pdf
http://www.soselectronic....roduct%20presentation.pdf

prijs zal ergens tussen de 4 en 5 euro liggen, dat is als je ze per stuk koopt.

[ Voor 91% gewijzigd door mad_max234 op 27-09-2013 12:53 ]

vrijdag 27 september 2013 16:20

Acties:

Boudewijn

omdat het kan

ik moet binnenkort mijn espressomachine debuggen: sinds ik hem een keer goed heb schoongemaakt (veel water

) maakt hij sluiting. De aardlek klapt eruit, volgens mij als of de microcontroller die ik erin heb gehangen aanspringt , of de boiler aan gaat.

NU is dat niet zo heel lastig, maar het is rete irritant dat ik telkens de aardlek erop moet zetten. Is hier nog iets omheen te trucen op een veilige manier?

- ongeaarde kabel gebruiken: hmmm het is een metalen behuizing. Mischien niet heel slim...
- nieuwe groep met eigen aardlek trekken: uhhh beetje overkill

.

Iemand een idee?

vrijdag 27 september 2013 16:52

Acties: