PC oscilloskop

Det er fint hvis man ikke har et storage scope i forvejen og fylder ikke så meget - men så skal computeren også være der altid.

Der er efterhånden en del udbydere af denne slags instrumenter til en overkommelig pris.

Strømforsyninger, skillevariotransformer, frekvenstæller, målesender, HF wattmeter, , multimeter og hvad man ellers har på sin arbejdsplads, skal stadig være der.....

Billederne af tonegenerator og voltmeter give visse mindelser fra tidligere.

Gert

Da' Gert.

Det har du naturligvis ret i: Men på den anden side skrev jeg jo netop, at jeg leger med Arduino - og det er svært uden en computer, man kan bruge til at programmere den, så computeren står naturligvis på bordet i forvejen.

Hej Lars,

Jeg har også været på den galej for en del år siden.

Men så kommer der en ny Windows eller man skifter til 64bit eller sågar til Linux - og så er der ingen drivere, og hvis man har haft skopet i et par år, kan man godt glemme alt om, at der kommer nye. Køb et nyt skop, er beskeden!

Det gør jeg kun en gang - så nu har jeg købt et rigtigt skop på Ebay.

/henrik

Da' Henrik.

Det problem kender jeg desværre også godt. Det gælder dog ikke kun hardware - jeg bruger enorme mængder tid på at hjælpe min søn med at få gamle spil, som han jo altså også har købt og betalt for, til at køre på nye Windows-versioner - det kan så sandeligt også være en stor udfordring. For ikke at tale om den dag, han kom og forlangte et IPX netværk, så han kunne spille et gammelt spil sammen med sine venner. Godt, man har været med så længe, at jeg rent faktisk kunne klare udfordringen!

Det er dog ikke så svært, som det har været: Med virtuelle maskiner er vi i dag rigtig godt hjulpet i mange af disse situationer - jeg har således investeret i en VMware Workstation licens til min Linux desktop, så med en virtuel Windows XP og en anden virtuel Windows 7 er der ikke mange ting, jeg ikke kan klare på min "Linux" maskine.

Endeligt taler vi om en "dims" til 1.200 kr.: Der er mange af den slags, man må udskifte hen ad vejen, selvom de ikke er teknologiske udtjente - sådan fungerer vores samfund jo altså i dag, selvom jeg heller ikke bryder mig om udviklingen.

Hvem vil f.eks. købe et brugt fladskærms TV, der ikke er Full HD, i dag? Eller endnu værre: Et TV, der kun har MPEG2 dekoder? Eller hvad med det top-kvalitets 26" Loewe 16:9 billedrørs-TV, jeg ikke engang kan forære væk?

Nu har jeg jo altså allerede et rigtigt skop: Det står bare langt væk i en kælder, for det fylder alt for meget herhjemme i stuen. Velleman boksen har givet mig nogle nye muligheder, jeg ikke synes, jeg havde før - men det behøver naturligvis ikke at tælle for dit vedkommende.

Er der det nødvendige software med til de € 159,- ?

Er fuldstændig uvidende på opråde, så prisen passe vist meget fint til sådan en som mig, hvis der er det relevante SW med.

Nu du leger med Arduino, og digitale signaler, så vil jeg anbefale en anden gadget. En logic analyzer fra Saleae, som er sådan cirka i samme størrelse:

http://www.saleae.com/

Gerne 16 kanals versionen, hvis man har råd (og behovet).

Sjældent har jeg brugt et måleværktøj så meget som denne her. Den er nærmest uundværlig når man leger med microcontrollere. Softwaren har indbygget dekodere til en del forskellige protokoller, bl.a. seriel, I2C og SPI. Og hvis man kan skrive software, så kan man selv lave sin egen dekoder. Således har jeg "lært" den at dekode DCC kommunikation (som vel ikke er helt uinteressant for vores slags).

Der er også et lidt dyre alternativ hvis man i forvejen har noget Apple grej.

http://www.let-elektronik.dk/logic-analyzer-for-ios.html

Det er ikke noget jeg har prøvet - har heller ikke noget med butikken at gøre, fandt det i forbindelse med noget andet jeg søgte.

Da' Bent.

Ja - og den ligger frit tilgængeligt på hjemmesiden, så man må formode, at eventuelle updates også vil være frit tilgængelige. Du kan downloade softwaren, før du køber, og se den køre i demo mode.

Til gengæld er der ikke prober med, så dem skal du købe ved siden af. ELV har nogle udmærkede nogen til € 20 (ca. 150,- kr.), som jeg købte et par stykker af - så slap jeg for at skulle rode min kælder igennem for at finde de gamle, der også var godt slidte.

Da' Mikael.

Den ser godt nok spændende ud - den er skrevet højt på ønskesedlen!

Det lyder som et spændende projekt, jeg også godt kunne deltage i; og så skal den naturligvis også lære NMRAnet/OpenLCB...

Jeg har fundet den her som alternativ til Velleman enheden, hvis man vil have noget der virker med andet end Windows. Både software og driver er open source. Det er ca. det samme prisleje.

http://www.syscompdesign.com/CGR101.html

Jeg er blevet "beriget" med en ny laptop - med Windows 8: I må godt have ondt af mig, det er dog noget af det værste, jeg længe har været udsat for...

Men Velleman har skam rigtige Windows 8 drivere til skopet - og der er også dukket et API op, så man kan skrive sine egne programmer, der udnytter skopet. Det sidste har jeg ikke fået set nærmere på, men det ser godt nok spændende ud.

Jeg kan anbefale at hente og installere Classic Shell - det gør livet med Windows 8 noget mere udholdeligt

mvh
Henrik

Da' Mikael.

Jeg kunne jo ikke dy mig, så nu har jeg også sådan et dyr: En dejlig lille boks, som jeg utvivlsomt vil få megen glæde af.

Bestemt: Min første opgave hedder netop DCC på Arduino. Hello World kører - jeg kan tænde og slukke den berømte LED på ben 13 via DCC som var det et sporskifte, men der er naturligvis lang vej endnu til en for alvor fungerende løsning.

Da jeg har en vis modvilje mod at genopfinde hjulet, vil jeg gerne høre, om du kunne tænke dig at dele din DCC dekoder? Jeg kunne muligvis bidrage til projektet, og vil helt sikkert også lave en OpenLCB dekoder senere hen.

Tillykke med den. Den bliver du med garanti glad for. Købte du den store eller den lille?

Selvfølgelig vil jeg det. Jeg har allerede gjort det på Saleaes brugerforum, men det kræver vist at man registrerer sig der først. Du kan bare hente den her i stedet:

http://www.ejberg.dk/external/sporskiftet/DCCAnalyzer.zip

Bare pak zip filen ud, tag dll filen og kopier ned i Analyzers mappen hvor du installerede Saleae softwaren.

Resten i zip filen er sourcekoden, hvis du vil pille. Men der skal du givetvis registrere dig hos Saleae og så hente deres Analyzer sdk og brugsforvirring, før du forstår noget videre af det

http://community.saleae.com/

Da' Mikael.

Jeg købte den store - prisforskellen var ikke så stor, når man tager i betragtning hvad mere man får.

Det var noget af det første, jeg gjorde; jeg har også hentet SDKen, og er i gang med at grave mig gennem den. Desværre kan man vist ikke længere få fat i VS 2008 Express, men indtil videre har jeg bygget diverse eksempler med VS 2010 Express, og det har virket, som det skulle.

Skal lige have puttet sønnike - så må jeg vist i gang med at lege!

Da' Mikael.

Jeg har nu leget med det et par dage - men jeg kan desværre ikke rigtigt få den til at virke: Den dekoder præambelen korrekt, men herefter viser den blot en stribe 0er og 1er - hvis der er 1er nok på stribe, blive de dekodet som en fejlbehæftet præambel:

Så vidt jeg kan se, er der er en korrekt DCC pakke, der indeholder fire bytes med værdierne 00000011 00111111 10000000 10111100. Hvis jeg har ret, betyder pakken, at et lokomotiv med adressen 3 skal sætte hastigheden efter 128 trins standarden - lokomotivet skal køre forlæns med hastigheden 0 - dvs. holde stille. Det er DecoderPro i kombination med en SPROG, der udsender disse - jeg ved ikke hvorfor. Der er ikke noget lokomotiv på.

Der er til gengæld en Arduino på, der fungerer som tilbehørsdekoder - og den fungerer fint: Jeg kan styre den fra DecoderPro og tænde og slukke dioden på Arduinoens port 13. Arduinoen reagerer korrekt i forhold til adresser og alle øvrige ting, jeg har kunnet finde på at teste. Men mit trace fra DCC analyzeren ser konstant ud som ovenstående.

Er det noget, du har lyst til at vi arbejder videre med? Skal vi lave en tråd her på Sporskiftet til formålet - eller foretrækker du at arbejde på en anden måde? Jeg er i gang med at installere en Subversion server her på Sporskiftet - den virker sådan set nu, men jeg skal have opfundet en måde at lave adgangskontrol i kombination med Drupal, før jeg for alvor sætter den i fri drift.

Ja, det ser godt nok lidt mærkeligt ud. Så vidt jeg husker, så markerer de røde krydser en timingfejl, hvor der er for stor forskel på den høje og den lave halvperiode. Hvad er tiderne, der hvor fejlen er? Du kan evt. prøve at øge samplehastigheden.

Jeg går ikke ud fra at du måler direkte på skinnerne. Det ville nok være for hård kost for logic analyzeren i det lange løb. Du har sikkert en form for transistorkobling, eller måske ligefrem en optokobler, der bringer signalet ned på logikniveau. Muligvis er dine stige- og faldetider her ikke tilstrækkeligt symmetriske. Kører du 3.3 eller 5V? Og har du sat analyzeren til det rigtige niveau hertil?

Og lad os bare lave en passende tråd herinde til den fortsatte snak.

Da' Mikael.

Jeg har prøvet den samme øvelse på 10 MHz, men det gør ingen forskel - der kommer blot flere timingfejl.

Jeg har skam sat en optokobler på - med følgende kredsløb:

Det er nok også her, problemet ligger: Det lader til, at 4N35 ganske enkelt ikke er hurtig nok, hvilket er lidt ærgerligt, da jeg netop har købt 100 af dem... Med ovenstående setup får jeg et input på Arduinoens D2, der ser således ud:

DCC biblioteket, som jeg bruger på Arduinoen, er mægtig glad for dette - men det er analyzeren ikke; og med god ret, må man desværre nok sige. Bemærk iøvrigt, hvordan jeg her har benyttet det oscilloskop, som tråden egentligt handler om: Målinger som dette kan man ikke lave med Saleae analyzeren - der er altså ikke tale om enten/eller, men derimod om både/og.

Den kritiske komponent har vist sig at være R2 på diagrammet ovenfor: Ved at gøre den mindre, har jeg kunnet gøre kurven bedre og bedre. Jeg nåede helt ned på 100Ω, men så blev den laveste spænding pludseligt omkring 2V, og det var ikke så brugbart; en værdi på 180Ω viste sig imidlertid at give brugbare resultater:

Her kan man så nøjes med at undre sig over, at pakke nummer to er dekodet som "?"?

Desværre kunne Arduinoen ikke lide disse små modstande: Jeg opdagede, at processoren blev temmeligt varm, og den er vist desværre stået af - jeg kan ihvertfald ikke få den til at virke mere. Heldigvis er det ikke så dyrt at reparere - man køber blot en ny processor og skifter den ud, den sidder i en sokkel på Arduinoen. Jeg forstår ikke helt, hvad der er gået galt - den store strøm bliver trukket fra Arduinoens strømforsyning, ikke fra processoren, og strømforsyningen har det godt nok.

Skulle Arduinoens indgang ikke "måle" på kredsløbet med en relativt høj impedans?

Under alle omstændigheder vil jeg stoppe med flere eksperimenter, indtil jeg har fået reservedelene hjem - og nogle andre optokoblere, konklusionen må vel være, at 4N35 ikke er hurtig nok til opgaven. Øv.

Jeg laver en ny tråd, når jeg er oppe at køre igen.

Da' Skott.

Jep - det kan jeg godt se, selvom under ½ pris nok er lidt af en tilsnigelse: Jeg har givet 44,- kr. i enkeltstyk incl. moms, mens den pris på lige over 20,- kr., du linker til, er ved fem styk og excl. moms. Men billigere er det bestemt: Let Elektronik var faktisk den dyreste forhandler på min liste - til gengæld den eneste, der havde den på lager med bootloader til en Duemilanove, så jeg besluttede mig for den hurtigste og nemmeste løsning.

Faktisk var jeg rigtigt doven og bestilte dette shield også: Så kan jeg lave dem på samlebånd i fremtiden - og Cypax kan meget nemt ende med at blive leverandøren. Selvom jeg naturligvis ikke håber på at brænde alt for mange af...

Tjah. Softwaren i Arduinoen er nok lavet til bare at skelne mellem 0 og 1, og med masser af ekstra luft omkring fejltimings.

Jeg skrev analyzeren med bagtanke i at kunne bruge den til at analysere bit-timingen op imod DCC standarden. Så hvis man nu skulle bygge sin egen command station, så kunne man verificere den. Jeg har allerede lagt noget tolerance ind i analyzeren, men det kunne man sagtens gøre større.

Nej, her har du sikkert ramt grænsen for optokoblerens CTR. Det kunne nok rettes ved at øge strømmen gennem dioden på indgangen. Men det er ikke den rigtige måde at gøre det på. Sæt i stedet R2 tilbage til den oprindelige værdi. Eksperimentér herefter med også at sætte en modstand fra basen (pin 6) til stel. Jeg vil gætte på nogle få kohm vil være passende.

Dit problem er at fototransistoren ikke slukker for sin CE strækning lige så hurtigt som den kan tænde for den. Ved at sænke R2 øger du strømmen gennem CE, og mindsker dermed tiden som transistoren forbliver i sit mætningsområde. Mit forslag vil i stedet hjælpe basen med at aflade når lyset forsvinder. Værdien af modstanden skal nok findes ved lidt eksperimenteren. For stor modstand, og den hjælper ikke nok. For lille modstand vil aflade basen, også med lys på, og så får du slet ikke noget signal igennem. Men med en passende værdi kan du højst tænkeligt balancere forsinkelserne ved både tænd og sluk, så de bliver tæt på symmetriske. Jeg har selv brugt samme trick på en 6N138 optokobler.

Ja, det er mystisk. Hvis du zoomer tilpas langt ind, skifter det spørgsmålstegn så til "Analyzer error"? Hvis det gør, så har du fundet en fejl i min analyzer kode (der bliver opdaget i DCCAnalyzerResults.cpp linje 69). Jeg kan ikke lige gennemskue hvordan det overhovedet kan lade sig gøre.

Jo, jeg kan ikke se hvordan det skulle kunne være sket. Med mindre der er noget kode, der kortvarigt sætter den pin som en udgang på et tidspunkt.

Hej Lars

OK - Det er så rigtigt, men med tanke på de projekter, du har snakket op er undervejs - med mange Arduinoer rundt om på banen, så ville en stang ATmegaer måske ligge på hylden en dag

Super - Det er da lettere - Enig. Håber, du får god fornøjelse af indkøbet

Da' Mikael.

Helt sikkert. :)

Jeg er ikke færdig med at studere APIen - men måske man kunne lave en option, så man kunne vælge "Strict timing" eller "Relaxed timing"? Det første ville være fint ved udvikling af f.eks. en command station, som du selv er inde på - det andet, hvis man vil måle på mindre optimale real-world scenarier. Det virker lidt absurd, at man har et kredsløb, der virker, og hvor man tydeligt kan aflæse værdierne "med håndkraft" - men analyzeren nægter at være med, fordi timingen er nogle få nS gal (og det er det, der er tale om); den burde nærmere vise en advarsel, men dekode løs i sådanne tilfælde, hvis du spørger mig.

Så lærte jeg noget nyt igen i dag - fedt! Jeg har nu googlet en del på emnet og lært, hvad man bruger basis til på en sådan optokobler. Jeg må i gang med at lege videre.

Right you are: Jeg har her, som så ofte før, hugget noget kode på nettet og tilpasset det mine formål. Koden her er oprindeligt skrevet til at styre servoer, men jeg har lavet den om til en Hello world med LEDen på D13:

//DCC Decoder
//By Adam Hellier <adam@adamhellier.co.uk>
//Free for personal use, may not be reproduced comercially without consent
 
#include <NmraDcc.h>
 
//Begin Dcc Code
 
NmraDcc  Dcc ;
DCC_MSG  Packet ;
 
struct CVPair
{
  uint16_t  CV;
  uint8_t   Value;
};
 
CVPair FactoryDefaultCVs [] =
{
  {
    CV_ACCESSORY_DECODER_ADDRESS_LSB, 1            }
  ,
  {
    CV_ACCESSORY_DECODER_ADDRESS_MSB, 0            }
  ,
};
 
uint8_t FactoryDefaultCVIndex = 0;
 
void notifyCVResetFactoryDefault()
{
  // Make FactoryDefaultCVIndex non-zero and equal to num CV's to be reset 
  // to flag to the loop() function that a reset to Factory Defaults needs to be done
  FactoryDefaultCVIndex = sizeof(FactoryDefaultCVs)/sizeof(CVPair);
};
 
const int DccAckPin = 2 ;
 
// This function is called by the NmraDcc library when a DCC ACK needs to be sent
// Calling this function should cause an increased 60ma current drain on the power supply for 6ms to ACK a CV Read 
void notifyCVAck(void)
{
  digitalWrite( DccAckPin, HIGH );
  delay( 6 );  
  digitalWrite( DccAckPin, LOW );
}
 
 
 
//Begin the void Setup
void setup()
{
  {
    // Configure the DCC CV Programing ACK pin for an output
    pinMode( DccAckPin, OUTPUT );
 
    // Setup which External Interrupt, the Pin it's associated with that we're using and enable the Pull-Up 
    Dcc.pin(0, 2, 1);
 
    // Call the main DCC Init function to enable the DCC Receiver
    Dcc.init( MAN_ID_DIY, 10, FLAGS_OUTPUT_ADDRESS_MODE | FLAGS_DCC_ACCESSORY_DECODER, 0 );
  }
 
  pinMode(13, OUTPUT);
}
 
 
 
// This function is called whenever a normal DCC Turnout Packet is received
void notifyDccAccState( uint16_t Addr, uint16_t BoardAddr, uint8_t OutputAddr, uint8_t State)
{
  if (Addr <= 13 && Addr >= 1) { //checks to see if the Adress CV belongs to this decoder
    if ((OutputAddr % 2) == 0) { //checks to see if we have anything left when output addresss is divided by 2
      digitalWrite(13, HIGH);
    } else {
      digitalWrite(13, LOW);
    }
  }
}
 
 
 
void loop()
{
  // You MUST call the NmraDcc.process() method frequently from the Arduino loop() function for correct library operation
  Dcc.process();
 
  if (FactoryDefaultCVIndex && Dcc.isSetCVReady()) {
    FactoryDefaultCVIndex--; // Decrement first as initially it is the size of the array 
    Dcc.setCV( FactoryDefaultCVs[FactoryDefaultCVIndex].CV, FactoryDefaultCVs[FactoryDefaultCVIndex].Value);
  }
}

Den laver åbenbart D2 om til output ind imellem for at sende ACK: Jeg havde naturligvis lagt mærke til det, men havde besluttet, at jeg ville vente til senere med at dechifrere den del. Jeg har ikke umiddelbart kunne finde denne del i NMRA standarderne, men må lede noget mere.

Da' Skott.

Skott skrev:

OK - Det er så rigtigt, men med tanke på de projekter, du har snakket op er undervejs - med mange Arduinoer rundt om på banen, så ville en stang ATmegaer måske ligge på hylden en dag

Ja, det ender det jo nok med.

Men lige netop med Arduino til modeltog håber jeg dog, situationen vil blive en lidt anden: Jeg er ved at se på, hvordan man kan få produceret en større mængde Arduino Micro, hvor der er tilføjet de få ekstra komponenter, der skal til for at kunne dekode en protokol som DCC - mere præcist, optokobleren med omliggende passive komponenter som vist ovenfor. Den skal også have en ensretter, så den kan strømforsynes fra sporet, men må ellers gerne være identisk med Micro, hvis du spørger mig.

Med lidt held kunne man skabe et community omkring denne løsning, så mange ville være interesserede, købe - og dermed få prisen ned?

Enig - Det lyder rigtig spændende. Hvis du vil forsyne Arduinoen fra sporet, bør du som minimum også tilføje en kondensator efter dioden (måske 10 - 100uF - evt. med en 100nF kondensator parallel over - af udglatning og støjhensyn) 

Sjovt, at de anvender en ATmega32 i stedet for 328'eren på micronen -> Flere I/O på mindre plads - Det er da Win/Win

Da' Skott.

Kondensatoren er der allerede, ligesom en spændingsregulator - de skal blot fødes med en DC, og det er nu engang AC, der kommer fra sporet. Derfor ensretteren - resten burde allerede være en del af designet.

Citat:

Sjovt, at de anvender en ATmega32 i stedet for 328'eren på micronen -> Flere I/O på mindre plads - Det er da Win/Win

Nemlig: Det er også derfor, jeg har kastet min kærlighed på den frem for Pro Mini, som jeg ellers har købt nogle stykker af. Der er også mange flere PWM udgange, der kan bruges til blinkende dioder, hvis man ikke vil bruge det TLC kredsløb, jeg har kastet min kærlighed på.

Hej Lars

Kiggede lige på diagrammet på micoeen og kan se, der allerede sidder 22uF samt 100nF, så det er jo fint - Men der sidder en Mosfet på Vin af spændingsregulatoren, som jeg ikke lige kan se, hvad har af funktionme.

Jeg vil dog foreslå dig, at du anvender en diodebro i stedet for en enkelt diode - For det første taber du 1.4V over denne i stedet for 0.7-1V, som du kun vil ved en alm. diode. Det er alligevel et pænt spændingsfald, der kommer til at ligge over regulatoren, der jo skal generere 5V til uC'eren. Jeg tror også, det er derfor, der kun anbefales 7-12V som indgangsspænding af producenten. Men vigtigst: så sikrer du, boardet virker rigtigt uanset, hvordan du vender forsyningsledningerne!

Det er faktisk præcis sådan jeg allerede har lavet analyzeren. Jeg opererer med 3 sæt timingkrav. Det første er "strict", som går benhårdt lige til grænserne i DCC standarden. Fejl herfra bliver kun markeret hvis det er enablet i analyzerens konfiguration.
Andet sæt timings er "relaxed", og tillader 3 µs fejl ud over standarden. Fejl herudover bliver markeret, men stadig dekodet rigtigt.
Det tredje sæt hedder "out-of-spec", og definerer hvornår analyzeren skal give op.De kan alle ses i DCCAnalyzer.cpp:

filter_strict

Jeg vil tro at det er filter_outofspec.bit1diffmax på 10 µs driller i dit tilfælde. Men det ser man bedst ved at tage dit signal med fejl i, og så aflæse præcis hvordan timingen er for begge halv-bits.

Ok, der gik et eller andet helt vildt galt med copy/paste og Sporskiftets editor. Jeg håber det er forståeligt alligevel.

Da' Skott.

FETen sidder på alle nyere Arduinoer: Den bruges til at skifte strømforsyning. Man kan strømforsyne Arduinoen fra en ekstern kilde, men forbinder man den med USB til en computer, vil strømforsyningen skifte til USB, selvom der også er en ekstern strømforsyning på.

Det er bestemt også min hensigt: Jeg skrev vist "ensretter" - det betyder i min sprogbrug en diodebro, men det er naturligvis ikke indlysende. Så - for nu at skære det helt ud: Jeg vil have en ensretterbro til strømforsyningen ud over de nuværende komponenter, og så vil jeg have det viste kredsløb med optokobleren ved siden af. Jeg kan jo ikke så godt måle spændingen på indersiden af ensretterbroen, hvor kondensatoren vil ødelægge DCC signalet.

Men med de få ekstra komponenter burde Arduinoen til gengæld også være klar til såvel at køre på forsyningsspændingen som dekode et digitalsignal på samme. Eller kun dekode, og så blive forsynet fra en anden kilde.

Da' Mikael.

Jeg har pillet lidt i din kode, så den dumper en del debuginformation til en fil - og du har ret, den dør i "out-of-spec".

Leger videre, når jeg har fået min pakke med reservedele i morgen.

Da' Mikael.

Du havde ret - næsten: Det hjalp gevaldigt med den ekstra modstand, men den skulle være en del større:

Normalstørrelsen mindre - dvs. 18 K - giver problemer, da logisk 0 stiger til omkring 2 V. En værdi på f.eks. 10 K reducerer amplituden til omkring 10 mV. Værdier større end 22 K reducerer blot den positive effekt: Værdien er altså overraskende følsom, så man må håbe, den ikke varierer for meget med produktionstolerancer i optokobleren - det har jeg ikke testet endnu.

Til gengæld er både Arduinoen og analyzeren glade nu: Jeg kan styre min Arduino via min SPROG og DecoderPro, og jeg kan samtidigt måle på den:

Men som du kan se, er der stadig et problem med manglende dekodning af den første datapakke: Jeg skal nok prøve at debugge på det.

Samtidigt har jeg testet lidt: Det er SPROG II, der udsender pakkerne ovenfor, så længe den er indstillet til "tændt" - selv når DecoderPro er lukket helt ned. Det er lidt problematisk, da det har vist sig at være overordentligt vanskeligt at finde nålen i høstakken: Der skal godt nok scrolles meget og længe for at finde de få regulære DCC pakker, jeg sender afsted, når SPROG kontinuerligt sender idle pakker som ovenstående.

Det vil derfor nok være praktisk med et filter, der kan fjerne idle pakker, så man lettere kan finde nyttepakkerne; men det vil jeg komme nærmere ind på i en anden tråd - nu har jeg en løsning, hvor kurveformerne er i orden, og det er jo den del, der relaterer til oscilloskopet, som denne tråd handler om. Jeg laver en ny tråd, når jeg har fået set nærmere på din kode.

Ja, jeg kan godt frygte at tolerancer kan drille. Jeg har ikke haft problemer med denne metode, men jeg benyttede også en anden optokobler: 6N138. Den er vist beregnet til højhastigheds kommunikation, men koster også noget mere.

Ja, det er meget mystisk. Jeg vil prøve at lave en simulation af den pakke, præcis som du har den der. Har du prøvet at zoome ind på spørgsmålstegnet, og skifter den så til "Analyzer error" i stedet?

Da' Mikael.

Det kan godt være, det bliver vejen frem - selvom det undrer mig en del, hvis DCC skal karakteriseres som "højhastighed". Da jeg spekulerer i masseproduktion, prøver jeg blot at holde prisen så langt nede som muligt.

Ja, jeg har prøvet at zoome voldsomt ind - og nej, det gør ingen forskel.

Det er klart. Men det er jo også kun påkrævet for at kunne debugge på signalet med min analyzer. Hvis man skriver sin software så den kan klare skævhedden i timingen, ja så ser jeg ingen problemer i at holde sig til den billige optokobler. Men hvis Arduinoen også skal forsynes af skinnerne, ja så kunne man overveje helt at droppe optokobleren og derved spare lidt mere.

Ahaaaa. Så er det ikke min software, der har opdaget et problem.

Prøv at gå op i Options og så "Display in Ascii". Skift til Hexadecimal, eller bare Decimal. Hjælper det? Den byte har nok en værdi, der ikke findes et ascii tegn for.

Da' Skott.

Jeg kan ikke helt gennemskue, om der er en uenighed her?

Arduinoen har en stribe forskellige måder at blive forsynet på - tre, for at være helt præcis:

• Den kan forsynes fra en ekstern ren 5 V DC forsyning.
• Den kan forsynes fra en ekstern DC forsyning af en eller anden art med en spænding over 7 V.
• Den kan forsynes fra en host computer via en USB forbindelse.

Du har ret i, at diagrammet kan være noget forvirrende.

Det er der flere grunde til: For at kunne køre på en billig, tilfældig DC strømforsyning kræves en DC regulator. Sådan en har Arduinoen, og den har også udtag, som man kan tappe en 5 V DC fra til sine perifere kredse. Men den kan også vendes om: Onboard regulatoren kan kun levere en begrænset strøm, så har man brug for meget strøm til sine perifere kredsløb - f.eks. en masse LEDer - bør man i stedet slutte en ekstern 5 V DC til. Det gør man ved at vende kredsløbet, så det tap, man før havde på regulatoren, bruges som input fra den eksterne strømforsyning.

Arduinoen kan også drives fra den 5 V forsyning, der findes i enhver USB forbindelse; men den har igen problemer med at levere strøm nok, hvis man sætter en hård belastning på. Derfor er reglen, at hvis man sætter et USB kabel til, vil selve Arduinoen blive forsynet fra USB, mens eventuelle eksterne kredsløb stadig vil få strøm fra den eksterne forsyning - hvis der er en sådan. Det regnes som væsentligt, at Arduinoen får strøm fra USB forbindelsen, hvis den også bliver programmeret herfra - det synes jeg lyder fornuftigt.

Det er muligt, jeg har misforstået dele af det - og jeg tror også nok, der er små forskelle mellem modellerne - men i det store hele er det vist princippet. Det betyder også, at man kan sætte en Arduino på sin bane, forsyne den fra sporet eller en anden boostet DCC kilde - men alligevel proppe et USB kabel på og omprogrammere den uden at skulle afbryde forbindelserne til den eksisterende forsyning. Idiotsikret for dem, der ikke ved, at der kan være et problem - og dejligt nemt for vi andre. Det er denne lille juleleg, FETen skal bruges til. FETen blev indført med Duemilanove - indtil da havde man brugt en jumper.

Så er der selvfølgeligt også en anden "detalje": Nyere Arduoer har også fået en 3,3 V regulator - den trækker vist nok strøm fra selve Arduinoens 5 V (hvordan den så er blevet valgt jvf. ovenstående), så der også vil være strøm til eventuelle 3,3 V perifere enheder, man måtte have på sit kredsløb. Det er derfor blevet lidt af en udfordring at følge strømforsyningen rundt på diagrammet.