| Author |
 Topic  |
|
silvervarg
Member
652 Posts |
 Posted - 2005/02/08 : 13:43:16
|
quote:
För oss som tänkte bygga mutlikanal, om det nu blir kretskort för 2 kanaler, hur mycket skulle ett sådant kosta? Det kan ju dra iväg en hel del i pris om man behöver 3-4st sådana kort. Hur mycket mer skulle det kosta att göra ett kort för tex 4 kanaler istället för 2 kanaler?
Jag tror att det är för tidigt att säga något om detta. Troligen så blir ingångarna ganska annorlunda för ett multikanal, t.ex. om du kör 5.1 kanal så har du kanske 2*6 ingångar istället för stereo på tex 6*2 ingångar. Beroende på hur ingångskortet designas så kanske man måste ha ett annat ingångskort för multikanal. Det viktigaste här är om ingångskortet är ihopbyggt med huvud-analogkortet eller inte.
Huvudanalogkortet/korten behövs förståss flera, och kostnaden för dessa är starkt beroende av vilken lösning som väljs för volymkontroll och om tonkontroller skall finnas med eller inte.
Digitaldel, LCD, knappar, strömdel etc blir nog helt identisk, och där ligger den största kostnaden.
Kanske Ludo vågar sig på en pris-gissning mellan tummen och pekfingret?
|
Edited by - silvervarg on 2005/02/08 13:44:08 |
 |
|
|
ludo
Member
1196 Posts |
Posted - 2005/02/08 : 13:54:02
|
Nu har vi sonderat lite (inte heltäckande men tillräckligt tycker jag) vad vi har för önskemål på förförstärkaren/projektet. Allmänna känslan är att många drar åt samma håll / kan tänka sig kompromissa för att genomföra projektet (rätta mej om jag har fel).
Antag att några av oss vill gå vidare med projeket (hypotetisk fråga än så länge).
Då måste vi börja ställa oss följande frågor:
1) Har vi tillräcklig KOMPETENS inom följande områden så vi kan GENOMFÖRA projektet:
A) projektledn
B) hårdvarudesign ana/digi (inkl schemaritn, layout, komponentkännedom)
C) hårdvarunära mjukvarudesign (inkl protokoll för fjärr)
D) mekanik (cad)
E) ekonomi, inköp
F) test, verifering
G) "manualskrivning"
Vi behöver inte visa några CV'n för varandra -det är inte det det handlar om- anonymiteten får gärna fortsätta. Det räcker med om vi kan få svar på ifall vi TROR oss ro det här projektet i hamn.
2) Vem kan i så fall tänka sig ta ansvar för vilken del i projektet?
3) Och ifall vi INTE har kompetens nog -vad gör vi åt det?
4) Om vi har har den kompetensen som krävs - är vi UTHÅLLIGA nog att genomföra projektet?
Vad jag menar är att projektet kommer att få en viss utstäckning i tiden. För att vara lite realistisk så måste vi räkna med att det kommer ta minst ett halvår innan vi får fram resultat.
Hur ställer vi oss till allt det? |
|
|
|
silvervarg
Member
652 Posts |
Posted - 2005/02/08 : 13:55:47
|
Såg just denna förförstärkare på säljes:
http://www.hififorum.nu/forum/topic.asp?TOPIC_ID=36859
Rotal RC-995 med fjärr etc.
Den har separat listen och rec selector, balans, hörlursutgång, 1 blanaserad och 2 SE utgångar.
Den saknar: tonkontroller, LCD.
Utsatt för 3500:-
Jag tog bara upp denna för att vi skall tänka till vad vi måste vara bättre på.
Om vi inte är bättre på några viktiga punkter så är det ju inte lönt att bygga själv.
Prismässigt kommer vi troligen hamna ungefär lika.
Är det funktionalitet/utbyggnadsmöjlighet/storlek/ljudkvalitet/utseende/... som vi siktar på att vara mycket bättre på?
|
|
|
|
Joav
Member
233 Posts |
Posted - 2005/02/08 : 20:34:48
|
Jag kom på en idé idag, har ingen aning om den är bra eller inte men här kommer den  :
Det sägs att trafo-volym ska var bland det bästa man kan ha...
Om man använder relän för att välja volym och har ett kontroll kort till det så har man både volym och balans...
(relän används för att styra volymen i "PHATOS LOGOS")
mer info om volym-trafo finns här
http://www.stevens-billington.co.uk/page102.htm
http://www.sowter.co.uk/attens.htm
|
Jag lär mig av att ställa dumma frågor
Gör din Streo glad spela "Riltons vänner" www.riltonsvanner.com |
|
|
|
luften
Member
723 Posts |
Posted - 2005/02/08 : 20:55:44
|
Joav: Mja, problemet med trafo-volym är väl att det är dyrt?! Annars är det säkert bra.
Eventuellt kunde man ju använda sej av en spänningsdelare med ett mostånd i serie med signalen, och en "digital potentiometer" ner till jord. Dessa finns t.ex. av Dallas Semiconductors tillverkning som är menade för audiobruk. Kvaliten vet jag inget om, men det vore en "enkel" lösning, även för flerkanalsbruk. Dom enklaste modellerna av potarna kan styras med 2 tryckknapper, dvs, upp och ner. Sedan finns det mera avancerade modeller som kan styras via mikroprocessor.
Priserna på deras hemsida är mycket låga, men det innefattar ju att man köper 1k av en modell. Iallfall, bara en möjlighet.
http://para.maxim-ic.com/compare.asp?Fam=Dig_Pot&Tree=DigiPots&HP=DigitalPotentiometers.cfm&ln=&SORD=742+739&FT_739=7774&FT_742=7786&ITEMLIST=146806,146808,146809,146813,146819,146840,146841,146861,146862,146863,146864
|
//air |
|
|
|
silvervarg
Member
652 Posts |
Posted - 2005/02/09 : 14:10:31
|
Om det skall vara trafo volym med bra kvalitet så pratar vi över 10.000kr.
Dessutom tar trafo-volym stor plats, och på papperet så har de faktiskt inte så bra värden.
Jag har inte lyssnat på någon eller sätt några riktiga jämförelser med annat.
Bara prislappen går nog att det är helt uteslutet att köra trafo-volym.
Tillbaks till huvudämnet:
1. Målen med preampen.
2. Vad har vi för möjligheter att kunna genomföra ett projekt.
3. Tekniker för lösning av specifika problem.
Jag tror att vi behöver jobba mest med 1 & 2 nu. Utan dem så är 3:an inte värd något.
Vi har kommit en bit på målsättningen, men fortfarande inga svar på min post om vad vi vill göra som är bättre än att tex köpa en begagnad preamp.
Eftersom jag ställde frågan om målsättning så svara jag istället lite på Ludos frågan om möjligheter att genomföra projektet.
Hittills så saknar vi nog det mesta, men om vi kommer fram till målet så kanske fler är beredda att ställa upp.
Någon måste dock vara beredd att axla projektledningsbiten för att hålla ihop det, och där ser det svårast ut.
Om det ser ut att ta fart så kan jag hjälpa till med delar av hårdvarudesign och delar av mjukvarudesign och en del av testning och verifiering. De delar som jag designar kan jag förståss dokumentera också.
|
|
|
|
ludo
Member
1196 Posts |
Posted - 2005/02/09 : 20:39:11
|
silvervarg: det verkar som om det bara är vi två som vill ta ansvar för genomförandet av det här projektet.
Fördelen är självklart att ju färre kockar desto godare soppa...
När den första yran av entusiasm (över att bygga nåt nytt) lagt sig och "tillnycktringsfasen" satt in så måste jag erkänna att för min egen del börjar jag dessutom tvivla på huvudmålet, dvs den om (behov av/) att bygga en flerkanalsförstärkare.
1) Det blir kostsamt.
2) Prestandamässigt/ljudmässigt (per kanal) blir det alltid sämre än endast stereo.
(Har aldrig hittills lyssnat till nåt mulikanalsysten -mycket dyra system inkluderat- som lät bättre än *bra* stereo).
3) Utrymmeskrävande. Mycket kringkomponenter. Placeringsvårighet (högtalare, eff.stärkare, sladdar).
4) Noll utbud av musikmjukvara.
5) Och sist men inte minst (projektmässigt) mycket tidskrävande, särskilt om bara två pers deltar aktivt i genomförandet.
Upplys mej: varför satsa på ett flerkanalssystem!??? (Ledsen för min kovändning men jag har nog svårt att bygga nåt jag inte tror på...ideelt vill tillägga). |
|
|
|
silvervarg
Member
652 Posts |
Posted - 2005/02/09 : 23:03:36
|
Ludo: Vi får väl se om fler nappar, men på bara två personer så är det ett ganska rejält projekt.
Tror du inte att det finns möjlighet att kunna köra flera analogkort bredvid varandra även om ett kort bara är designat för 2 kanaler?
Det beror nog lite på vad vi väljer för volymlösning, men många har stöd för kaskadkoppling. Ingångssteget kanske blir lite annorlunda vid flerkanal också och så blir programmvaran kanske mycket mer avancerad. Hm, det kanske blir en hel del skillnad trots allt...
Hur ställer du dig till:
Balancerat/SE på ingångar respektive utgångar?
Typ av volymkontroll?
Och framförallt på vilket sätt ett projektbygge slår en färdig produkt.
Dvs om vi inte går långt under i pris.
|
|
|
|
ludo
Member
1196 Posts |
Posted - 2005/02/10 : 20:05:41
|
quote:
Vi får väl se om fler nappar, men på bara två personer så är det ett ganska rejält projekt.
Ja.
Lite nedslående bara att när man börjar prata ansvar så dör tråden nästan...i o för sig så ska det väl mestadels diskuteras på diskussionsforum men ändå.
quote:
Tror du inte att det finns möjlighet att kunna köra flera analogkort bredvid varandra även om ett kort bara är designat för 2 kanaler?
Min erfarenhet är att det redan kan vara svårt att få plats med två kanaler inkl VÄLdesignad strömförsöjning i en någorlunda smidig låda.
quote:
...Det beror nog lite på vad vi väljer för volymlösning...
Definitivt är det så. Ju fler kanaler desto färre frihetsgrader. Dels beror det på begränsning i komponenterna dels storleken.
quote:
Balancerat/SE på ingångar respektive utgångar?
Både och är inget problem att designa in. Ökar kretskortytan natuligtvis men enl min mening är det en bra "investering". Sen om man väljer intern balanserad topologi och konverterar SE->BAL på ingången eller tvärtom har ingen större betydelse. Jag skulle i o för sig föredra intern balanserad topologi i och med att det minimerar inverkan av jordstörningar men å andra sidan ökar antal komponenter (men inte så mycket kretskortyta som man skulle tro).
quote:
Typ av volymkontroll?
Shunt av något slag...hade jag tänkt mej. (Ökar inte bruset vid lägre volym )
quote:
Och framförallt på vilket sätt ett projektbygge slår en färdig produkt.
Det kan man först få reda på efteråt...men att göra något som är ett strå vassare än den rotel du länkat till borde inte vara nåt större problem...det är det minsta problemet skulle jag vilja påstå .
Att hitta tid för genoförande av projektet är däremot alltid det största.
Vad skulle vi kunna använda för uC-familj? |
|
|
|
Joav
Member
233 Posts |
Posted - 2005/02/10 : 23:31:25
|
Jag skulle gärna vara med och ta ansvar men min tekniska kompetens räcker inte längre än att komma på konstiga idéer
Är det något mindre tekniskt som ska göras så ställer jag upp! |
Jag lär mig av att ställa dumma frågor
Gör din Streo glad spela "Riltons vänner" www.riltonsvanner.com |
|
|
|
silvervarg
Member
652 Posts |
Posted - 2005/02/11 : 10:18:06
|
quote:
Silvervarg: Och framförallt på vilket sätt ett projektbygge slår en färdig produkt.
quote:
Ludo: Det kan man först få reda på efteråt...men att göra något som är ett strå vassare än den rotel du länkat till borde inte vara nåt större problem...det är det minsta problemet skulle jag vilja påstå.
Vi bör väl ha några målsättningar om vad vi skall vara bättre på tycker jag.
Jag gissar att du syftar på ljudkvalitet, och där kan vi tex ha målsättning att vara bättre än XXX.
Vissa andra mål är betydligt lättare att se om vi kan klara innan vi bygger, t.ex.
Storlek på lådan, pris, finesser etc.
Är det full rackbredd som är intressantast eller vill vi ha något betydligt mindre?
Detta hänger i viss mån ihop med frågan balancerat/SE eftersom största vinsten med balancerat är att man får mindre störningar, och det är främst ett problem vid långa avstånd mellan burkarna.
Jag har aldrig granskat något som haft balancerad teknologi internt, men det kanske är en spännande teknologi.
Om man vill köra balanserat in och balancerat ut så bör det vara bäst att ha balancerat hela vägen så att man slipper konverteringarna. En fråga som dyker upp är då vad de flesta kommer att köra med huvuddelen av användningen? Alltså blanacerat/SE på ingång respektive balancerat/SE på utgång.
Vad får det för övriga konsekvenser?
Jag antar att 2 kanal balancerat blir liknande komplexitet som 4 kanaler SE. Stämmer det?
Blir komponentmatchning mycket viktigare?
Självklart kan vi stödja både balancerat och SE, men valet av intern teknologi betyder nog ganska mycket.
|
|
|
|
ludo
Member
1196 Posts |
Posted - 2005/02/11 : 11:56:52
|
Målsättning att vara "bättre än/sämre än ett vist märke" är lite orealistisk. Det har att göra med allas olika "smak"/preferenser. Tar vi exempelvis fram kretskort så kan alla bestycka det med den hårdvara (opampar/kondingar/whatever) de mest tror på / har erfarenhet av sen tidigare. Så varje bygge kan komma att låta litet olika.
Det vi definitivt måste satsa på att är att få så bra ljud/prestanda under förutsättning att vi håller oss till de ramar vi själva begränsar oss till (pris/komponentval/topologi/storlek/osv).
På frågan varför ett projekt som drivs att en grupp audioentusiaster har en chans att bli bättre än ett kommersiellt finns många svar.
1) Vi är inte bundna till att välja komonenter som redan finns på lager (miljontals med halvtaskiga data kanske som man är tvungen att göra sig av med)
2) Vi är inte bundna till nåt fabrikat (elektroniktillverkaren kanske har skrivit på kontrakt som begränsar denne till endast att handla in exvis opampar fr endast ett fabrikat)
3) Vi kan vara mer "fanatiska" dvs definera våra behov lite smalare och därmed få ut bättre prestanda.
4) Vi behöver inte bekymra oss om anpasning till produktion eller snarare ekonomisk storskalig produktion...det ger många fördelar
5)-1000)osv osv
Vi har nu berört lite analogdelen och lite annat smått å gott.
Vi har inte berört digitaldelen än vilket vi måste ta itu med - mest:
1)plattform dvs processorval (för "tyst" uC-system enl mina krav tidigare). 8bitars? Processorfamilj? Utv.miljö? mm mm
2)Någon som skulle vara villig av att programera? (Går säkert att programera i C eller annat högnivåspråk...där tycker jag användarvänlighet går före optimering av snabbhet/antal klockcykler osv. Programmet behöver inte vara så stort.)
3)Funktionalitet?
4)Fjärrstyrning?
5)Val av display?
... |
|
|
|
ludo
Member
1196 Posts |
Posted - 2005/02/11 : 12:06:19
|
Joav: att komma på konstiga ideer är inte alls så dumt.
Kul att du vill delta i projektet! |
|
|
|
silvervarg
Member
652 Posts |
Posted - 2005/02/11 : 14:20:20
|
Okej, då diskuterar vi digitaldel lite:
Som uC så är PICmicro eller Amtels de som är mest populära att köra för hobbybruk. De är enkla att komma igång med och priset är lågt. Dessutom finns det gott om hobbyfolk på nätet att få hjälp av om man kör fast på någon punkt.
Lågnivåprogrammering är viktigt får två saker. Det ena är för att skriva ett mycket mindre program så att man kan köra på en mindre och därmed billigare variant av uC. Eftersom vi troligen pratar om ganska få exemplar och kostnaden för uC ändå kommer att vara en liten del så är detta inte så viktigt.
Den andra anledningen är att vi vill ha 100% koll på klockclykler för att kunna hantera saker som händer snabbt. I vårt fall är det signalerna från fjärrkontrollen som är det enda som måste hanteras snabbt och i rätt timing. Om vi skippar fjärrkontrollen så försvinner även detta problemet.
Det går förståss att hålla koll på detta även vid högnivåprogrammering, men då behöver man ha koll på vilken kod som högnivån genererar och då är det egentligen mer jobb än om man skriver allt i lågnivå direkt.
Ytterligare ett alternativ är att strunta i timings och hoppas att det funkar i alla fall. Har vi tur fungerar det ändå. Har vi otur så slutar det fungera eller fungerar sämre när vi stoppar in mer funktionalitet för att vi tappar tidssynken i huvudloopen för mycket då. Har vi mer otur så funkar inte fjärren alls eller fungerar bara med vissa fjärrkontrollers. Då blir det till att spendera mycket tid i debugger, och det kanske måste göras av den som har en viss fjärrkontroll som krånglar.
Tyst uC: En del av de enklare PICmicro chippen i PIC16Fxxx serien har inbyggd klocka med sleep-funktioner etc som är lätta att använda. Det är nog den lösning som hårdvarumässigt blir enklast och billigast. Om man kör chippen med inbyggd klocka så går de typiskt i 1MIPS, vilket jag anser vara fullt tillräckligt för våra behov.
Funktionalitet: Hittills har vi nog inte specat något som ställer speciella krav på uC:et förutom möjligen på antal input/output pinnar, sleepmode och uppväckning med interupt.
Fjärrstyrning: Jag har inte trixat med detta ordentligt ännu utan bara läst en hel del om det. Vi borde kunna få till fjärrstyrningen. Det stora problemet är att stödja många fjärrkontrollsstandarder. Hårdvarumässigt så behöver vi nog välja vilken bärvågsfrekvens som vi stödjer och mjukvarumässigt vilket protokoll som vi stödjer. Stöd av flera samtidigt är knepigt och löses oftast genom mycket mer avancerad mjukvara och körning i hög hastighet. En ganska vanlig lösning verkar vara att bara köra RC5 protokollet som används av en hel del vanliga fjärrkontroller i europa. Här behövs ett rejält projekt för att undersöka vad vi skall stödja och vilka fjärrkontroller som kommer att fungera i praktiken med de val vi gör.
Tyvärr så finns det alldeles för många olika standarder på detta område.
Kanske något för Joav att börja söka och sammanställa information om?
Display: Någon form av standard teckenbaserad display med vanliga parallellgränssnittet anser jag att vi skall köra med. De är lätta att få tag på, lätta att styra och bland de billigaste displayer man kan köpa. Vanligast är 2*16 tecken om man vill ha en hyfsat liten och det borde räcka gott åt oss.
Sedan finns valet att köra med/utan backlight och vilken displaysort man vill använda vilket påverkar färg, kontrasten, betraktningsvinkel etc). Exakta valet är nog inte så viktigt nu, det kan tom lämnas till var och en beroende på vilken display som är snyggast eller som man kan få tag på billigt.
Ludo: Har du funderat något på mina frågeställningar om balancerat/SE i mitt förra inlägg?
|
|
|
|
Michael
Member
110 Posts |
Posted - 2005/02/11 : 14:35:51
|
Hej
Har uppfattat en liten oro för högnivå programmering och fjärrkontroll avkodning. Kan upplysa om följande:
Avkoda RC5 i en AVR med ett C program kompilerat med WinAVR (GNU GCC) är inga problem. Har gjort detta med en egen skriven interrupt rutin. Har ännu bara implemeterat RC5. Kanske kan uppstå problem om något protokoll med högre bithastighet skall avkodas.
//Michael |
|
|
|
silvervarg
Member
652 Posts |
Posted - 2005/02/11 : 16:51:45
|
Hejsan Michael, och välkommen in i diskussionen.
Är du möjligen intresserad av att hjälpa till och sköta utvecklingen av mjukvaran?
Gör du något annat än avkodning av RC5 samtidigt eller håller du dig till bara en sak i taget?
Vilka fjärrkontroller fungerar i din lösning hittills?
Är koden du använder fri eller är det något du håller på själv?
Hur mycket minne tar koden?
Vilken bärvågsfrekvens stödjer du och vilken hårdvara kör du på?
Tar du ner uC i sleepmode? I så fall kan den ta emot RC5 från detta läge? (Alltså om den hinner vakna ur sleep mode tillräckligt fort för att inte missa någon info).
Vad gör företaget "Sound Light Electronics"? Verkar inte ha någon websida ännu i alla fall... |
|
|
|
luften
Member
723 Posts |
Posted - 2005/02/11 : 17:58:23
|
Hej. Det låter ju riktigt bra dethär.
Jag skulle gärna vara en del av detta projekt, men jag vet inte i vilken del jag skulle passa in. Projektledare eller dylikt är nog inte passande uppgifter åt mej, och jag har inte heller erfarenhet av mikroprocessorkodning. Den analoga designen intresserar mej mest, men jag vet att det finns personer i detta gäng som har mycket mera erfarenhet av detta. Dock kanske man kan bistå med nån "konstig ide".
|
//air |
|
|
|
Michael
Member
110 Posts |
Posted - 2005/02/11 : 18:11:50
|
Hej hopp, va många frågor... här kommer lite svar:
Nej, jag kan inte hjälpa till och sköta mjukvaru utvecklingen. Men lite tips, ideer och hjälp vid problem kan jag nog bistå med.
Ja, det är tänkt att göra andra saker samtidigt som RC5 avkodningen. Därav att avkodningen ligger i en interrupt rutin. Det används även en timer interruptrutin, för tids tick.
Kör med en one for all (URC-6510) inställd för gammal Philips TV. Som sagt bara RC5. Alla andra fjärrar jag har kör något annat protokoll.
Koden kommer att sitta i en kommersiell produkt (förhoppningsvis) och är inte fri.
Koden är på ca 135+30 rader C-kod. Snabbt ihop skriven för ca ett halv år sedan, bara för att se om det funkar. Skall fintjusteras.
Använder en IRM-8601S (Elfa) och ATmega88 (för tillfället).
Använder inte någon form av sleep mode. Har inte provat detta.
Mitt företaget är ett litet 'fritids intresse', har annat jobb. Har hänt väldigt lite i företaget under många år. Är dock på G med något HiFi relaterat, lite senare i år så kanske kanske...
//Michael |
|
|
|
ludo
Member
1196 Posts |
Posted - 2005/02/11 : 19:10:59
|
Hur många fysiska uppvakningspinnar har dessa processorer ni pratar om? Jag menar finns det exvis bara 8-9st KBI-pinnar (eller vad de kan tänkas heta) så kan det resultera i att de som vill köra med knappar för ingångsval blir begränsade till ett visst (kanske för litet) antal. Eller så kan man kanske komma runt problemet på nåt smidigt sätt?
uC i en analog förstärkare är nödvändigt ont, den underlättar bara i handhavandet, samtidigt som den bara i bästa fall inte påverkar ljudet och då endast när alla klockor/generatorer är avstängda. (Kunde inte hålla mej...)
Ville komma fram till att val av uC bör styras av det ovan skrivna.
Sen skulle det vara hur smidigt som helst (och billigare) att slippa kristallen (med kringkomponenterna). |
|
|
|
Jesper_Nilsson
Member
494 Posts |
Posted - 2005/02/11 : 19:29:54
|
Hej,
Håller med Michael här, programmeringen är inget jätteproblem. ATmega48/88 kostar bara runt 30:- på elfa och på http://hubbard.engr.scu.edu/embedded/avr/avrlib/index.html finns open-source kod (i C) för LCD och SPI/I2C eller vad gränssnitt vi vill ha. På Atmels hemsida finns appnote för RC5 och på AVRfreaks finns säkert massor mer... allt som behövs för detta projekt.
Att dela på analoga och digitala delar är i grunden sunt med det innebär inte för den skull att man blir av med störningsproblematiken, det kan även bli värre. Strålningen direkt från ett kort/processorn/LCD'n eller vad det nu är är ganska begränsad och koncentrerat till mycket höga frekvenser. Det är i första hand kablaget som strålar. Extra skräpigt blir det om man skapar stora strömloopar vilket man lätt gör genom att dra långa kommunickationskablar utan att ha 100% koll på var strömmen letar sig tillbaka. En högfrekvent störning kan oxå utan större svårighet leta sig ut på ledningar som man tror är lungna, som ex matning till reläer etc för att sedan stråla villt.
Lösningen är (åtminstonde delvis):
1. Skapa en filterbarriär runt de digitala delarna. Filtrera ALLA kablar.
2. Använd optokopplare placerade på digitalkortet för att eliminera risken till stora loopar.
3. Alternativt, (om man inte vill ha optokopplare) försök att ha en egen jordretur för varje signalledning och tvinna samman dessa.
4. Fundera på vad som är jordreferens för störkällan, filtrerar man mot en annan jord riskerar man att få liten effekt. I värsta fall kan man koppla två jordar på ett sätt så man får resonans vid vissa frekvenser och där jodplanen själva fungerar som antenn.
Med tungan rätt i mun går det att få att få till det, men för att verkligen veta vad som händer och för att få en åtminstonde suboptimal lösning behöver man kunna mäta i ett EMC labb.
Därmed inte sagt att en halvskäpig lösning behöver låter illa. De flesta audioprylar är inte vidare bra immunitmässigt, men låter bra ändå.
/Jesper
|
|
|
|
Michael
Member
110 Posts |
Posted - 2005/02/11 : 22:04:15
|
quote:
Hur många fysiska uppvakningspinnar har dessa processorer ni pratar om?
Beror naturligtvis på valet av chip. På lite nyare AVRer så har dom något som kallas "Pin Change Interrupt", där grupper om upp till 8 i/o pinnar har ett gemensamt irq. Vad gäller Atmega88 så kan man få irq från alla i/o pinnar (23st). Varav 2st kan ge eget 'riktigt' irq (rekommenderas till IR mottagaren). Val av chip måste naturligtvis tas utifrån krav på antal i/o pinnar och önskad funktionalitet. Går också att t.ex. använda ett extra I2C chip med 8 ingångar som kan ge ett irq om någon pinne ändrar sig.
Vad gäller mjukvaran så behöver man ju inte ta en massa bitar som hittas på internet, som kan vara svåra att få att fungera ihop (kan även innehålla buggar, även om det kommer från Atmel). Vi pratar ju om DIY, det är ju roligt att skriva själv också :-) Jag tror inte att det kommer att vara någon jätte avancerad och komplex mjukvara ni vill skriva. Ta t.ex. styrning av en volym krets som nämts tidigare i tråden. En snabb titt i databladet och några minuter senare är koden skriven som styr den (bittbangning).
//Michael |
|
|
|
silvervarg
Member
652 Posts |
Posted - 2005/02/12 : 21:38:22
|
quote:
Håller med Michael här, programmeringen är inget jätteproblem.
Jag tror inte att någon av delarna som skall göras är något jätteproblem.
Det stora problemet är mångden arbete och att så få är intresserade av att hjälpa till.
Programmeringen är en stor del av arbetet, speciellt som uC:et kommer att ha kontakt med ganska många av resterade kretsar. Det gör att den som programmerar troligen måste bygga och testa mot alla desa delar. Det betyder att det blir en stor del av arbetet.
Om att programmering skulle vara felfri så kan någon annan förståss testa det, men jag räknar inte med buggfri kod i första försöket utan riktig testning.
Så att säga att programmeringen inte är något problem när hittills inge varit beredd att ta denna uppgift tycker jag tyder på att det är ett stort problem.
Om vi kör med reläer som ingångsväljare och ett chip för volymkontroll och standardlösningar för spänningsreglering så finns det i stort sett inga svårigheter där. Ända stora tekniska svårigheten förutom programmeringen är då kretskortslayouten, och den delen verkar Ludo vara bra på.
Icke-tekniska problem som kvarstår är:
projektledning, avstånd mellan utvecklarna, kostnader för utvecklarna, tiden som projektet kommer att behöva hålla på samt om alla inblandade enas om de kompromisser som görs?
Jag har säkert glömt några icke-tekniska problem.
Personligen så tycker jag att det är synd om man inte utnyttjar möjligheterna som finns i uC för att stoppa in mycket fler finesser. Vissa finesser är dock svåra att kombinera med sleep-mode.
|
|
|
|
Jesper_Nilsson
Member
494 Posts |
Posted - 2005/02/13 : 10:54:40
|
Silvervarg:
Du har ju mer eller mindre varit projektledare hittils, varför inte fortsätta?
Vilka fler uC finnesser hade du tänkt?
/Jesper |
|
|
|
silvervarg
Member
652 Posts |
Posted - 2005/02/13 : 14:57:47
|
quote:
Du har ju mer eller mindre varit projektledare hittils, varför inte fortsätta?
Jag anser mig inte ha den tid som krävs framöver, så därför tror jag inte att jag skulle göra ett bra jobb. Istället gör jag nog mer nytta om jag löser vissa delar som är mer isolerade. Om jag då inte hinner så är det lättare att flytta över det jag inte hunnit med till andra.
quote:
Vilka fler uC finnesser hade du tänkt?
Oj, det finns ju massor med kul saker.
Styrning av av/påslag av slutsteg och hörlursförstärkare.
Vad sägs om klocka, påslag/avslag vid inställbar tid (dvs som en klockradio).
Insomningsläge (spelar en viss tid och tystnar sedan).
Start och stop med upp/nedtoning av volymen.
Minne för volym och toninställningar per ingång.
Om man lägger till avkänning av musik volym så kan man införa automatisk volymjustering dels för att få alla plattor att låta lika högt och dels för att begränsa utnivån så att klippning i slutstegen inte uppstår.
Sen kan man införa mer avancerade menysystem, möjlighet till scrollande text, grafisk equaliser etc.
Fade-in/ut av lysdiod för störm samt backlight på LCD.
De flesta är inte helt nödvändiga finesser, men som de ser så är det mesta till 99% mjukvara, så det går att lägga till i efterhand med ganska liten insats.
Avkänning av musikvolym är lite kontroversiell eftersom man då skapar en koppling mellan analogdel och digitaldel där störningar möjligen kan uppkomma.
Just när det gäller tänkbara störningar mellan digitaldel och analogdel så tror jag på idéen att bygga och se om det är ett problem i praktiken. Om det är ett problem så ser man om man kan lösa det på ett enkelt och billigt sätt. Det finns en hel del klassiska sätt för att minska störningar, och de flesta kommerciella apparater klarar detta utan problem.
|
|
|
|
ludo
Member
1196 Posts |
Posted - 2005/02/13 : 22:03:41
|
silvervarg:
quote:
...klockradio...Insomningsläge...toninställningar...automatisk volymjustering...avancerade menysystem...scrollande text...grafisk equaliser...Fade-in/ut av lysdiod för störm samt backlight på LCD...
De önskemålen ligger precis i motfas med mina. Det ser ut som om vi (tyvärr!) har helt olika syn på VARFÖR man bygger en AUDIOkomponent.
Därför drar jag mej ur projektet.
Startar med all sannolikhet egen förförstärkartråd så smånningom.
EDIT: Det var ingen kritik utan bara en insikt om att vi inte skulle dra jämnt i ett gemensamt projekt vilket skulle slöa ner arbetet. |
Edited by - ludo on 2005/02/13 22:30:02 |
|
|
|
Topic |
|
All Forums
Teknik och DIY
New Topic
Topic Locked
Printer Friendly