Al mijn goede ideeën...

[Hans van de Burgt]

@Age,

Ik begrijp dat er wat weerstand is tegen digitale blokbescherming. Maar rijden op zicht is bij druk bezoek op beurzen niet altijd mogelijk. Het blijft dan gokken. En nogmaals wanneer we echt wagentjes van rangeerterrein naar rangeerterrein willen rijden zal er extra beveiliging nodig zijn.
Detectie kan ook resulteren in een groene pijl (doorrijden mogelijk) resp. rode pijl (doorrijden niet mogelijk)op kleine displays aan de bovenkant links en rechts van de fries.



Het lijkt mij dat Bas goed in staat is om zoiets uit te dokteren.

Gr, Hans

[Age van Dijk]

Ha Hans,

Daar heb ik alle vertrouwen in!
We zijn het er over eens dat er wat moet gebeuren om ongelukken te voorkomen, zonder anderen te verplichten ook iets te doen.

Dus benieuwd hoe dit praktisch kan en visueel goed zichtbaar (ook leuk voor publiek)

Groet,
Age

[bask185]

Ik zou dan in de bovenvrees iets van 2 pijlen maken van 3mm rood-blauwe duoleds. Sommigen zien het verschil tussen rood en groen niet.

Die displays hebben vaak maar 1 kleur pixels. Sommigen hebben wel RGB achtergrond verlichting.

Mvg,

Bas

[Klaas Zondervan]

Wat bovenfrees? Angst om naar zolder te gaan?😄

[bask185]

fries*

Ik dacht dan aan zoiets. Hij is wel 46mm in hoogte, misschien een beetje te groot

[nederbelg]

Hallo Bas,
Wij hebben nu naast de 36 hoofdseinen een 30 tal dwergseinen bij de AMC. Die moeten natuurlijk ook aangestuurd worden. Ben je al wat verder met dit project(je)

Die goede idee is net wat wij op onze modelbaan kunnen gebruiken. Eenvoudige montage en plaatsing op de baan.
Het VOLK wil verder.
Groet,
Henk

Hier wil ik ook wel wat info over?
Seinen en kabels heb ik al, maar buisje <> stekker is nog zoekende.

Dave

[schipcas]

Hallo Dave,

kijk eens op https://train-science.com/
even zoeken en je vind hier wat je nodig hebt.

Neem anders even contact op met BASK, lid van dit platform

groet,
Henk

[bask185]

Heb nu wel even tijd  . Mijn werk PC is gereset dus ik ben de heledag naar installatie balkjes aan het turen.

Die singles en tevens mijn lok pilot draaien op een attiny1616. Die is voor mij nieuw en die programmeer je anders dan oudere attiny's. Ik moet van mezelf eerste de lok pilot kunnen programmeren. Als dat gelukt en ik kan DCC decoderen met die chip, dan komen deze sein print en een paar van zijn broertjes ook tot leven.

Ik heb echter eerste andere dingen te doen.
Ik heb gisterenavond mijn centrale zijn eerste goede DCC pakketje laten versturen. Daar moet ik nog wat aan de software sleutelen. Deze centrale is voor mij wel belangrijk omdat de helft van mijn ideeen er om heen draaien. En hij is kritisch voor dit schakelpaaneel van Age.

Ik verwacht ook zeer binnenkort nieuwe ABC modules en diodes voor de oude. Die moeten ook ZSM af.

Ik heb dan nog een edits booster te repareren en dan moet ik nog 2 reeds bestaande schakelpanelen operationeel maken. Deze projecten kwamen met een beetje tegenslag.

Ik wil sws mijn lok pilots/functie decoders ook aan de praat hebben. Dus ik probeer ze er tussendoor te fietsen.

Mvg,

Bas

[Joz]

Heb nu wel even tijd  . Mijn werk PC is gereset dus ik ben de heledag naar installatie balkjes aan het turen.

Daar hoeft je PC geen reset voor te krijgen hoor. Dat kun je regelen met https://www.whitescreen.online/fake-windows-11-update-screen/
Handig voor als je weer even tijd nodig hebt 

[AP3737]

Hi Bas

Die singles en tevens mijn lok pilot draaien op een attiny1616. Die is voor mij nieuw en die programmeer je anders dan oudere attiny's. Ik moet van mezelf eerste de lok pilot kunnen programmeren. Als dat gelukt en ik kan DCC decoderen met die chip,

Ik neem aan dat je https://github.com/SpenceKonde/megaTinyCore kent? De meeste dingen die ik bouw, doe ik op DXCore, van dezelfde persoon. Hij heeft ook uitstekende info over UPDI programmeren; ik vind dat prettiger dan de oude ISP programmering.

Gebruik je de NMRA DCC lib?

Groet, Aiko

PS: hoe ziet je centrale eruit? Ik ben benieuwd.

[bask185]

Gebruik je de NMRA DCC lib?

Ja voor alle open source projecten. Ik heb zelf wel wat gewijzigd dat ik zowel loc als accessoire instructies kan afhandelen als ik dat nodig heb. Voor de servo decoders was het nodig dat ik ook lok instructies kon ontvangen voor het finetunen.

Ik was al bezig geweest met zijn core. Maar mijn eerste programmer was een arduino board met zo'n upload programma. Die heeft nooit gewerkt dus ik wil het nu met een losse ch340 chip proberen.

PS: hoe ziet je centrale eruit? Ik ben benieuwd.

De centrale is 58mm x 66mm. En heeft niet meer dan Loconet-B, DCC en USB. Er is ook nog een iets smallere zonder USB.


Ik heb nog een beetje software werk. Wissel 123 is nog niet 123 helaas. Bij DCC zijn de adressen een beetje apart opgebouwd voor accessoires. Ik zit hier met rcn213 doc naast me te kijken, wat er nog niet goed gaat.


Uitleg over hoe, wat en waarom komt nog wel een keer.

Mvg,

Bas

[bask185]

Het was even goed zitten en oude code maar vervangen door nieuwe, maar de adressering lijkt goed te werken. Centrale kan nu decoder aansturen.

Wellicht leuk om te weten hoe die adressen werken. Het zijn 11 bits getallen die deze indeling hebben.  En het eerste adres, dus DCC adres 1 heeft eigenlijk waarde 4. Omdat geschiedenis en.. logic... en eigenlijk geen idee tbh 

Code: [Selecteer]

//  Paket:   1 0  A  A -  A  A  A  A |  1    A   A   A - D  A  A R
//  Adresse: 1 0 A7 A6 - A5 A4 A3 A2 |  1 /A10 /A9 /A8 - 0 A1 A0 0
Hierbij is R de richting en D geeft aan of de uitgang aan of uit moet zijn. Ik weet eigenlijk niet of er nog decoders in omloop zijn die dat gebruiken. Je kan er vanuit de centrale de pulslengte mee regelen, maar meeste decoders doen dat zelf. En voor servo dingen is het sws puntloos.

De bits 10, 9 en 8 zijn geinverteerd. Ik weet niet de precieze reden waarom.

Ik had voor de grap nog geprobeerd met chatGpt de software puzzel op te lossen. Dus ik liet hem rcn213 doorlezen, maar hij kwam er niet uit. Ik denk dat ik hem maar bezig laat houden met wat python scripts, daar is die beter in  .

Oplossing van deze adres puzzel is dit lapje code. Je moet uiteindelijk 2 bytes samenstellen en die heb  ik byte1 en byte2 genoemd. byte1 was niet zo super lastig, maar die 2e byte was toch een beetje een hersenkrakertje. Daarom doe ik eerste de 2 afzondelijke nibbles berekenen. Het probleem splitsen in kleinere problemen en dan alles weer optellen.

Code: [Selecteer]

        uint16 address  = accessory[accessoryNow].address + 4 ;
        uint8 state     = accessory[accessoryNow].state ;
        uint8 ext       = accessory[accessoryNow].ext ;

        uint8 byte1         = 0x80 | (address & 0x00FF) >> 2 ;                      // sets a7 <-> A2
        uint8 lowNibble     = ( (address & 0x0003) << 1 | state | 0b1000) & 0x0F ;  // sets A0 and A1 direction and output = on
        uint8 highNibble    = (~((address >> 8) & 0x03)) & 0x0F ;                   // sets and invert A8-A10 and the first bit
        uint8 byte2         =  highNibble << 4 | lowNibble ;
En dan denk je dat je hiermee klaar ben, en dan zie je terug in je log dat de getallen boven 1020 (eigenlijk dus 1024) niet goed overkomen. Maar misschien dat dit aan de nmraDCC library ligt van de logger. Voor nu maakt het iig niet zo veel uit.

Code: [Selecteer]

OutputPower: 1
Addr: 1020
Direction: 1
OutputPower: 1
Addr: 65533
Direction: 1
OutputPower: 1
Addr: 65533
Direction: 1
OutputPower: 1
Addr: 65533
Direction: 1

Mvg,

Bas

[AP3737]

Hi Bas

Ja voor alle open source projecten.

Ik begrijp de keuze voor de NMRA-DCC lib.

Heb je het volgende al eens bekeken?
https://github.com/aikopras/AP_DCC_library/blob/main/extras/Performance_MegacoreX.md
https://github.com/aikopras/AP_DCC_library/blob/main/extras/History_Differences.md
De andere interrupt structuur bij de "nieuwe" 8-Bit controllers van Microchip zorgt voor een verdubbeling van attachInterrupt (7,4 ipv 4,1 us). Ook de
aanroep van micros verdubbelt: 3,5 (UNO) versus 7,2 us. Je houd dan weinig speelruimte over voor andere kritische dingen, zoals servo's.

Ik heb nog een beetje software werk. Wissel 123 is nog niet 123 helaas. Bij DCC zijn de adressen een beetje apart opgebouwd voor accessoires.

 
Vergeet ook niet dat verschillende command stations ook verschillend nummeren. Het zou handig zijn om dat in je code via een CV instelbaar te maken.

Groet, Aiko

[bask185]

Vergeet ook niet dat verschillende command stations ook verschillend nummeren. Het zou handig zijn om dat in je code via een CV instelbaar te maken

Wat ik tegen kwam was dat alleen adres 0-3 op een aparte plaats konden staan, maar dat het verouderd was

Bij enkele bestaande centrales volgt op adres 255 niet adres 256, maar worden de adressen 0 tot 3 ingevoegd. Daarna gaat het verder bij 260. Dit geldt ook voor adressen vanaf 511, 767, 1023, enzovoort. Dit moet als verouderd worden beschouwd en een lineaire adresvolgorde moet worden nagestreefd, waarbij de eerste adressen 0 tot 3 aan het einde van het adresbereik worden aangesproken.

Ik geef eigenlijk niet zo veel om wat andere command stations anders doen. Zolang die van mij het maar goed doen. Ik plan me gewoon aan de laatste standaard te houden.

Heb je het volgende al eens bekeken?

Nog niet. Ik weet wel dat ik zelf fan van de micros() functie omdat dat tot zover toereikend is, het is hardware abstract en het conflicteert niet met de PWM kanalen. Niet dat ik daar veel gebruik van maak tho. Ik vind dat ze dat slim hebben gedaan bij arduino dat ze timer 0 gelijktijdig kunnen gebruiken voor zowel millis(), micros() en 2 PWM kanalen.

Ik heb zelf voor m'n Weistra library gebruik gemaakt van micros() om de pulslengtes te regelen. En dat werkt misschien niet super efficient, maar het werkt wel en je kan ook probleemloos meer weistra objecten aanmaken enzo.

aanroep van micros verdubbelt: 3,5 (UNO) versus 7,2 us. Je houd dan weinig speelruimte over voor andere kritische dingen, zoals servo's.

Maar. Servo's gebruiken een hardware timer. Dat zou niet uit moeten maken hoe lang een functie call er over doet. Je kan een servo.write() uitvoeren gevolgd door een delay() en dan werkt de servo.

een verdubbeling van attachInterrupt (7,4 ipv 4,1 us)

attachInterrupt is toch iets wat je (meestal) maar 1 malig gebruikt in de setup?

Also

the lack of structure and the long NmraDcc source file gives, in my opinion, "room for improvement"

+1  . Dit viel mij ook op. Er staat een functie in van 400 lijntjes met nested switch-cases.

Mvg,

Bas

[AP3737]

Hi Bas

Ik weet niet goed hoe te reageren. Misschien zijn de termen “schoonheid van een ontwerp” of “liefde voor het vak” het meest treffend.

Met je nieuwe microcontroller heb je een aantal nieuwe mogelijkheden, die ideaal zijn voor het decoderen van het DCC signaal. Je kunt met behulp van het event systeem de DCC input pin rechtstreeks met je Timer B verbinden. Geen ISR meer nodig; geen instructie die de processor nog hoeft uit te voeren. Timer B kent een Frequentie Capture Mode, dus de tijd tussen twee signaal transities wordt in tienden van microseconde nauwkeurig bepaald. Wederom zonder dat de processor iets hoeft te doen, dus onafhankelijk of de processor juist op dat moment in één of andere ISR zat. Als de timer klaar is, dan pas roept hij een ISR aan, en die hoeft dan nog niet eens onmiddellijk afgehandeld te worden.

Met alle respect, maar ik zie echt geen goede redenen meer om bij deze nieuwe processoren voor DCC decodering nog de veel onbetrouwbaardere methode met millis() te gebruiken. De millis() methode zal bij kleine banen het best wel goed doen, maar bij grotere banen en complexere systemen zullen af en toe DCC commando’s verloren gaan. Dat wil je toch niet? Nogmaals, je hebt met deze nieuwe processoren allle tools al in je handen om het echt goed te doen.

Sorry, maar dat is hoe ik het zie

Groet, Aiko