Doel:€250.00
Donaties:€65.00

Per saldo:€-185.00

Steun ons nu!

Laatst bijgewerkt
op 17-02-2020
Algemeen

De stichting

Recente berichten

Concept en vragen voor eenvoudig bloksysteem met transistors door Joost O
Vandaag om 01:30:25
Wat is er momenteel te zien op de Betuweroute? door laurent
Vandaag om 01:28:57
Het oude station Wageningen (versie 3) door Martin Hornis
Vandaag om 01:16:38
Toon hier je nieuwe (model-) spooraanwinst(en)... door Bram S
Vandaag om 00:58:34
Zonder fouten een Arduino programmeren door Martin Hornis
Vandaag om 00:58:27
Onlangs gespot - gefotografeerd, de foto's door dennie
Vandaag om 00:42:43
SBB Vectron met Nederlandse bestickering: wie brengt hem uit? door Rondje_HO
Vandaag om 00:37:52
NS C-4704 coupérijtuig in messing. Spoor-0 door FritsT
Vandaag om 00:15:44
Gemeentetram Eemstede door Willem1951
28 februari 2020, 23:55:46
Atlas NS1602, statisch model, kap over te zetten op bestaand onderstel? door Duikeend
28 februari 2020, 23:40:09
Coöperatie de Eendracht door Edsko Hekman
28 februari 2020, 23:26:51
Projekt 083-338 door DE-II
28 februari 2020, 23:24:28
Waterstoftrein als alternatief voor diesel door AK952
28 februari 2020, 23:22:37
Kuehn WD10 programmeren, hoe schakeltijd instellen? door jerrytrein
28 februari 2020, 23:05:25
Raadplaatje door Twinkie
28 februari 2020, 23:03:19
Falcons Baan-Zonder-Naam door Remco_Nzo
28 februari 2020, 22:58:33
Rheinburgh, TP V/VI door martijn v m
28 februari 2020, 22:46:21
"Litter Bin" voor Brits spoor en Britse modelspoorprojecten door St00mboy
28 februari 2020, 22:46:15
"Union Pacific's Power Shop", een nieuwe baan in H0 door Ronald Halma
28 februari 2020, 22:39:09
Mijn eerste H0-modeltreinbaan in aanbouw door Wim Vink
28 februari 2020, 22:34:29
Nederlandse Modelspoordagen in Rijswijk, jullie komen toch ook? door MOVisser
28 februari 2020, 21:52:31
RAIL 2020 21, 22 en 23 februari, Houten. door iarnrod
28 februari 2020, 21:48:12
Schwarzburg-Neuffen-Bahn door Overet
28 februari 2020, 21:40:41
Helix teken in AnyRail door Frank 123
28 februari 2020, 21:34:38
Uhlenbrock 76320 decoder, kortsluiting? door heuvelbaan
28 februari 2020, 21:22:16
Schaduwstation Zevenheuvelenbaan door Wim Hesselink
28 februari 2020, 20:59:39
DR4018 eerste 4 outs zijn niet te gebruiken ondanks reset CV8=8 door Bert_Apd
28 februari 2020, 20:54:35
Mardec, optocouplers raken defect. Suggesties? door NL-modelspoor
28 februari 2020, 20:18:50
Ombouw/Pimpen Bolle neuzen door bollen neus
28 februari 2020, 20:12:01
BMB 00-modulebaan, Algemeen. door St00mboy
28 februari 2020, 19:46:35
  

Auteur Topic: De CanBus komt naar Kranenberg, Arduino's en de CanBus  (gelezen 11062 keer)

bask185

  • Offline Offline
  • Berichten: 353
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #90 Gepost op: 07 januari 2020, 07:41:23 »
Had ik ook ooit bedacht om geluid te maken onder de baan ipv in de locs. Ik was toen 14 ofzo en ging niet echter verder dan een idee. Het heeft zeker wel toegevoegde waarde om dit uit te ontwikkelen.

Als ik dat nu zou doen, zou ik elke speaker exact hetzelfde geluid laten afspelen waarbij je alleen de versterkers regelt afhankelijk van de positie van de locs. Daarbij moet eigenlijk elke route zn eigen speakers hebben. Zodat elke trein een volg geluid kan krijgen.
Wat voor versterkers heb je gekocht?

Je hebt voor je seinen ook andere oplossingen dan een arduino mega in in te prakken voor slechts 9 pwm pinnen. Als je op een uno een timer ISR elke 10us ofzo laat draaien kan je een software PWM realiseren. Je kan ook de ingebouwde micros() functie gebruiken van Arduino. Je kan misschien wel of niet flikkeringen waarnemen als je andere interrupts hebt draaien die te veel tijd in beslag nemen.

Je kan ook PCA9685 boards kopen. Dat zijn I2C PWM drivers. Kan je gebruiken voor leds en voor servo's, ze kosten geen drol en ze zijn makkelijk in het gebruik. klik mij

meino

  • Offline Offline
  • Berichten: 627
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #91 Gepost op: 07 januari 2020, 11:04:54 »
Over dat uitbreidings kaartje voor PWM pinnen, ik zal eerlijk zeggen dat ik lang niet alles weet wat er te krijgen is voor een Arduino. Maar ik had destijds een aantal Mega's gekocht voor 5,50 euro per stuk, een UNO deed toen 3,50 euro. Als je dat kaartje zou gaan gebruiken (dat is ook nog 3,20Euro per stuk) en een NANO (1,50-2 euro) dan is de besparing toch niet zo heel groot. En voorwat de ruimte betreft, dat is geen probleem onder de baan. Maar het is wel goed om te weten dat dat soort zaken ook beschikbaar zijn.

Over het geluid onder de baan. Ik heb een vaag idee hoe ik dat ga doen. Ieder blok in de hoofdrijbaan, een (of twee) speakertjes en een eigen NANO die het geluid voor dit blok controlleert. Dan Koploper een accesssory bericht laten genereren als een lok een blok binnen gaat. Op basis van dit bericht en de snelheid van de lok laat ik de blok NANO het geluid maken. Dat op basis van een roseruis (pink noise) generator. Snelheid en omtrek van de drijfwielen geeft je het tempo van de pufjes. Verder als de lok aan het optrekken is, dan is het geluid ook anders. Ook bij het verminderen van de snelheid (dichte regulator) is het een ander geluid. Kortom het is best wel complex, maar ook een uitdaging en daar houd ik wel van.
Om het een en ander te gaan proberen heb ik 2 NANO's en 2 PAM8403 (a 1euro per stuk) besteld. Ik heb net even een pdf over de PAM8403 gelezen en zie dat ik niet het volume kan regelen, dus misschien moet dat toch nog iets anders worden. Ik ga eerst maar eens proberen of ik uberhaupt het puffend geluid van een stoomlok kan maken met dit spul. Als dat lukt dan is de rest vrij simpel.

Groet Meino
A clean desk is a sign of an empty mind

Kranenberg

bask185

  • Offline Offline
  • Berichten: 353
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #92 Gepost op: 07 januari 2020, 13:16:34 »
Je kan wel 16 servo/leds op het boardje aansluiten + het consumeert geen performance van de arduino  :police:.

Ik heb ooit .WAV bestanden gespeeld van een SD kaart met een uno. Ik gebruikte slechts 1 transistor als versterker. Het geluid werd ook met pwm gedaan. Het volume kon best goed vanuit software geregeld worden.

Later had ik een wekker gemaakt die ook geluid kon afspelen. Deze had ik een digitale potmeter gegeven om volume mee te regelen.

Kan je koploper echt een accessory decoder laten voorzien van informatie van meer dan 1 byte ???. Je kan de nano natuurlijk wel zowel loc commando's als accessory laten uitlezen. Dan weet de nano hoe hard het ding rijd, zoals je al zei. En adhv het adres weet hij ook nog welke loc er rijdt. Moet je dan ook elke nano een eigen adres geven als accesory decoder? Je bent dan ook nog eens afhankelijk van de lengte van de baanvlakken in kwestie en ook de wiel groottes ed. Elke nano moet dan ook nog eens weten hoe lang zijn baanvlak is.

Misschien dat I2C eeproms hier voor handig zijn. Dan kan je 1 malig 10 of 100 EEPROMS branden voor alle nano's die je vervolgens dan op de printjes kan prikken.

Wat ook nog een issue wordt, is dat niet elke trein even hard rijdt op dezelfde stand. Ook dit is iets om over na te denken. Je kan wel alle decoders misschien instellen om even hard te rijden. Anders moet elke arduino weten hoe hard elke trein rijdt op elke stand. Optie 1 lijkt me hiervoor makkelijker.

Hoeveel speakers wil je ongeveer gaan plaatsen? Dit is ook belangrijk voor het maken van een goede keuze.

Bas
« Laatst bewerkt op: 07 januari 2020, 13:20:01 door bask185 »

meino

  • Offline Offline
  • Berichten: 627
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #93 Gepost op: 07 januari 2020, 16:15:25 »
Nee een accessory decoder bericht bevat slechts de waarde 0 of 1. Maar dat is geen probleem, waar ik geluid wil hebben zijn 10 blokken. En ik kan in totaal 2040 accessory decoder adressen gebruiken. Zeg dat ik 500 daarvan reserveer voor seinen en wissels, dan kan ik nog ruim 1500 gebruiken voor andere zaken. In de locomotief configuratie van Koploper kun je iedere loc voor ieder blok apart een accessory decoder laten activeren. Bij voorbeeld, BR01 gebruikt adressen 1500-1510, BR23 gebruikt 1511-1520 etc. Op het moment dat een lok een blok inrijdt laat ik Koploper een rechtdoor stand genereren en als de lok het blok weer uitrijdt de afbuigende stand. De NANO's hebben geen eigen adres, dat is niet nodig omdat ze via de CanBus alle berichten zien. Het enige dat ik moet doen, is deze NANO's configureren met de blok layout zoals wissels en mogelijke routes, verder bloklengtes en daar de gebruikte accessory adressen aan te koppelen in combinatie met de loc. Voor een deel heb ik dat al gedaan in de SeinController. Mijn locs rijden allemaal met geijkte snelheden, dus de koppeling tussen rijstap en snelheid is ook bekend.
Het is wel een berg aan extra configuratie, maar daar zit ik niet zo mee, tenslotte ben ik niet van plan om constant mijn baanplan te veranderen.

Maar eerst maar eens kijken, dat zal op zijn vroegst de zomer worden, of ik die NANO's het geluid van een stoomlok kan laten produceren.

Groet Meino
A clean desk is a sign of an empty mind

Kranenberg

Timo

  • Team encyclopedie
  • Offline Offline
  • Berichten: 4592
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #94 Gepost op: 28 januari 2020, 16:10:53 »
Wow, dat is al weer even geleden! De beste wensen nog ;D Ik was met onderstaand antwoord al in december begonnen. Ik dacht deze ook al afgemaakt te hebben ::) Maar schijnbaar heeft deze gewoon al die tijd open gestaan :angel: Maar goed om te zien dat jij niet stil gezeten hebt! (y)

Eén interessante vraag heb je onbeandword gelaten:
Pointers kunnen als parameters aan methods door gegeven worden, de physieke objecten niet.
Hoezo niet?  ???
Nogmaals, niet dat je het anders zou moeten doen hoor ;D

Ik dacht al, geen commentaar van Timo  ;)
Joop niet dat je het vervelend vind ::)

Dit begrijp ik niet helemaal ???, of bedoel je het gebruik van volatile? Dat is bij mij standaard voor data die in ISR (Interupt Service Routine) gebruikt worden.
[/quote]
Nee, niet, volatile. Dat is goed voor een ISR. Let wel op dat je niets aan atomic doet maar dat het alleen goed gaat doordat je alleen atomic operaties doet.

Nee, het feit dat je nu een array van 6 x 16 = 96 bytes ofwel 768 bits aan maakt. Terwijl je maar 96 bits = 12 bytes nodig hebt.

Zie de code. De S88 gebruikt 3 signalen, CLOCK, PS en RESET. Ik heb een ISR op de CLOCK en de PS signalen. RESET wordt niet gebruikt.
Ah, ja. Een ISR voor Clock en een voor PS/latch :)

Weet jij wat het verschil tussen C en C++ is? Het niet initialiseren van variabelen in C is een van de grootse valkuilen. Ik kom uit de C wereld, daar leer je op de harde manier dat je variabelen moet initialiseren voor je ze kunt gebruiken. Maar dat zit er bij mij zo ingesleten dat ik dat ook in C++ doe.
Dat je variabelen moet initialiseren klopt natuurlijk, maar globals (en volgens mij alle statische variabelen) worden altijd al geïnitialiseerd naar 0 :) Maar ook
byte eenArray[100] = {0};Zal alle waardes 0 initialiseren. (Niet expliciet genoemde elementen worden 0, de 0 in de initialisatie lijst slaat alleen op element 0.)

Ze moeten gevoed worden vanuit het DCC signaal. Dat beide rails onderbroken moeten worden volgt uit de beschrijving en dat wordt ook bevestigd door mijn ervaring met deze detector.
Doelde er meer op dat het niet de standaard is bij stroomdetectie. Misschien bedoelde je het niet zo maar je beschrijving lijkt te zeggen dat stroomdetectie altijd twee onderbroken spoorstaven nodig heeft. Kan zijn dat de PMP7 wel moet (kan de documentatie niet vinden) maar bij de meeste volstaat één staaf.

Dat doe ik om te voorkomen dat deze routines direct aangeroepen worden. Ik dwing nu dat afgeleide klassen een attach() en heartBeat() method implementeren.
(y) Maar is het dan echt nodig dat iedere child een redefined versie daarvan heeft?

Hangt ervan af wat je flink noemt. 1,25 tot 1,50 maal trager uitlezen van de bus maar wel foutloos. Geen gedoe met 2 x uitlezen, tragere clock of andere pleisters. Geen slecht compromis, althans zo denk ik erover.
Nouwja, als je gewoon alleen de geldigheid van de data checkt weet je wel dat je alleen goede data gebruikt maar niet of je data mist. Vandaar het "niet robuust". Maar zeker eens, liever wat trager en betrouwbaar dan snel en rommel.

[...] Daarom gebruik ik de Canbus voor de echte communicatie en blijft de kabel voor de S88 communicatie zo kort mogelijk en gebruik ik een cat5 kabel (S88-n).
Wat ik een hele slimme en gebruiksvriendelijke manier vind om het op te lossen (y), gewoon transporteren op een andere manier en weer terug bouwen.

Per wissel heb ik een relaispaar nodig.
Waarom heb je geen wisselspanning gepakt? Of loopt hij daar niet zo mooi op? Ook aan een H-brug gedacht? L293D of Mini-L298/MX1508 ofzo.

Dit schrijven gebeurd cyclisch, zodat ik iedere keer een nieuwe locatie gebruik.
Hoe hoe je bij waar in geheugen de laatste geldige stand staat? En neem aan dat je EEPROM.update() gebruikt?

Heb je specifieke Nano's met sd-kaart/geluid/wav optie? Of gewoon standaard ATmega328p Nano's?


Timo
Verzonden vanaf mijn desktop met Firefox

Patrick Smout

  • Offline Offline
  • Berichten: 311
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #95 Gepost op: 28 januari 2020, 19:24:33 »

Nouwja, als je gewoon alleen de geldigheid van de data checkt weet je wel dat je alleen goede data gebruikt maar niet of je data mist. Vandaar het "niet robuust". Maar zeker eens, liever wat trager en betrouwbaar dan snel en rommel.


In deze toepassing niet echt een probleem dunkt me. Dezelfde info wordt keer op keer om de x ms verzonden. Je moet maar pech hebben om net een puls te missen van enkele ms. Robuust " genoeg" maar onder techneuten is er altijd ruimte voor verbetering  ;) . Overigens kan je dan ook het dcc protocol en bij uitbreiding nog wat andere op de schop gooien. Net hetzelfde "probleem". Belangrijkste is hier dat de dataintegriteit gecontroleerd kan worden. Enkele tellen later komt de volgende boodschap. Een ander protocol dat kan aangeven om de boodschap te herhalen brengt geen soelaas hier als er op de physical layer gestaag iets fout loopt. Het meest zwakke punt nog zijn de controle signalen reset/load/clock. Als die grondig verstoort worden helpt een crc ook niet.

Mvg,  Patrick

Timo

  • Team encyclopedie
  • Offline Offline
  • Berichten: 4592
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #96 Gepost op: 29 januari 2020, 10:54:51 »
Helemaal met je eens! Fysieke laag blijft hier ook extreem zwak. En denk dat het pas een beetje robuust is als er error correctie in zit. Maar eens dat de kans dat het fout gaat als je in ieder geval een checksum hebt (verkeerde data weg gooit en moet "wachten" op juiste data) met deze snelheden op een baan niet zo groot is.

En de grap is eigenlijk dat je zou kunnen stellen dat DCC een per bit "checksum" heeft doordat elk bitje twee keer in een pakket zit. Helaas doet dat niets tegen het dan niet ontvangen van data dus robuust is dat ook niet ;D


Timo
Verzonden vanaf mijn desktop met Firefox

meino

  • Offline Offline
  • Berichten: 627
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #97 Gepost op: 29 januari 2020, 17:12:05 »
Helemaal met je eens! Fysieke laag blijft hier ook extreem zwak. En denk dat het pas een beetje robuust is als er error correctie in zit. Maar eens dat de kans dat het fout gaat als je in ieder geval een checksum hebt (verkeerde data weg gooit en moet "wachten" op juiste data) met deze snelheden op een baan niet zo groot is.

En de grap is eigenlijk dat je zou kunnen stellen dat DCC een per bit "checksum" heeft doordat elk bitje twee keer in een pakket zit. Helaas doet dat niets tegen het dan niet ontvangen van data dus robuust is dat ook niet ;D


Timo

Eigenlijk vindt ik dit erg grappig. De hele wereld communiceert tegenwoordig met IP (Internet protocol), Maar dat heeft op de fysieke laag ook geen enkele error protectie, of hoogstens iets heel rudimentair. Pas op de (software) IP laag zit wat error checking, geen recovery, een packet dat niet door de checksum komt wordt gewoon weggegooid. Pas op de TCP (een transport laag) zit een primitieve vorm van recovery. Overigens als een router onderweg problemen heeft, mag hij ook zonder meer packetjes op de grond laten vallen, Het is de verantwoordelijkheid van de twee eindpunten om op TCP nivo maar te proberen de handel te repareren. Toen ik in begin 80er jaren met Ethernet en IP begon te werken, was de mening van de communicatie guru's, dat IP een prut protocol was dat absoluut ongeschikt was voor een bedrijfs zeker netwerk, nee daar had je iso/osi, sna, decnet etc voor nodig. Dat waren tenslotte protocollen met een fatsoenlijke error checking en recovery op alle lagen (fysieke, session en transport laag en eventueel op de applicatie laag). Dat dit voor geen meter presteerde ten opzichte van IP was niet belangrijk.

Groet Meino, die vanuit Tierra del Fuego, keurig met TCP/IP, dit draadje kan volgen.
« Laatst bewerkt op: 29 januari 2020, 18:17:45 door meino »
A clean desk is a sign of an empty mind

Kranenberg

meino

  • Offline Offline
  • Berichten: 627
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #98 Gepost op: 29 januari 2020, 18:11:13 »
Doelde er meer op dat het niet de standaard is bij stroomdetectie. Misschien bedoelde je het niet zo maar je beschrijving lijkt te zeggen dat stroomdetectie altijd twee onderbroken spoorstaven nodig heeft. Kan zijn dat de PMP7 wel moet (kan de documentatie niet vinden) maar bij de meeste volstaat één staaf.
Wat ik weet, is dat deze detector een stroomdetector is, maar hij onttrekt ook zijn voeding van het DCC signaal en moet dus verbonden worden met beide railstaven. Het DCC signaal wordt op de detector aangeslote en gaat vanaf de detector naar beide railstaven. Ik heb geen elektronica kennis, maar als je slechts een staaf onderbreekt, dan werkt het niet goed.

(y) Maar is het dan echt nodig dat iedere child een redefined versie daarvan heeft?
Gewoonte, daarmee dwing je iemand die een afgeleide klas maakt, om bewust met deze methods om te gaan.

Waarom heb je geen wisselspanning gepakt? Of loopt hij daar niet zo mooi op? Ook aan een H-brug gedacht? L293D of Mini-L298/MX1508 ofzo.
Wederom, ik bezit geen electronica kennis. De wissels worden aangedreven door verbouwde 9g servos. De electronica is kortgesloten en de voeding is direct op het motortje aangesloten. Ik gebruik een voedingspanning van 3V, dan draaien ze niet te snel. De richting wordt bepaald door de polariteit van de voeding, 2 microswitches met diodes begrenzen de uitslag, en een aparte microswitch voor de puntstuk polarisatie. Het omschakelen doe ik met een dubbelpolige schakelaar. Helaas toen ik een aantal wissels via Koploper en Arduino's wilde aansturen was dat wat lastig, Het makkelijkste was om daar een relais paar voor te gebruiken.

Hoe hoe je bij waar in geheugen de laatste geldige stand staat? En neem aan dat je EEPROM.update() gebruikt?
Ik schrijf per update 3 bytes weg, 2 bytes met de wisselstanden gevolgd door een byte met een uniek bitwaarde die niet kan voorkomen bij de wisselstanden. Er wordt een index bijgehouden, die na iedere update met 2 wordt opgehoogd, voor de volgende update. Als de Arduino start, lees ik de EEPROM op zoek naar die unieke waarde, als die gevonden is, weet ik waar ik gebleven ben en heb ook de laatste 2 bytes met wisselstanden te pakken.

Heb je specifieke Nano's met sd-kaart/geluid/wav optie? Of gewoon standaard ATmega328p Nano's?
Gewoon standaard Nano's. Ik heb het idee om niet met wav files te werken, maar met een pink noise generator. Maar dat is nog allemaal experimenteel. Het kan zijn dat ik het uiteindelijk heel anders ga doen. eerst maar eens wat proberen.

Groet Meino
A clean desk is a sign of an empty mind

Kranenberg

Timo

  • Team encyclopedie
  • Offline Offline
  • Berichten: 4592
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #99 Gepost op: 29 januari 2020, 19:52:41 »
Ligt er maar net aan wat je als fysieke laag gebruikt voor TCP/IP ;D Hebben we het over ethernet over CAT dan zou ik willen zeggen dat het wel een vorm van error protectie (niet error correctie) door het differentiaal paar door de selectiviteit te verhogen en common noise te ondervangen. Ofwel, geen zwakke fysieke laag. Maar het gaat dan natuurlijk om de gehele stack, net als hier. Dus ja, het is pas echt robuust met TCP/IP (of een andere vorm met error correctie of ACK ofzo) ;D

Wat betreft de PMP7 kan ik alleen dit als referentie vinden. Ofwel, ook die heeft maar één onderbreking nodig maar dat moet wel precies in de juiste rail zijn. ;D En net als vele andere is de tweede draad alleen voor de voeding. Kan dus handig zijn te weten omdat het bijvoorbeeld draad kan besparen :)

Ken inderdaad de "servo truc" ook van Klaas. Als je van een mechanische oplossing af wilt (en eventueel ook de snelheid wilt kunnen regelen) zou je dus ook kunnen kijken naar die kleine H-brugjes. Laten zich net zo makkelijk (misschien zelfs makkelijker want geen "spoel storing") aansturen als een relais. Maarja, don't fix it if it ain't broke* ;D

Ik schrijf per update 3 bytes weg, 2 bytes met de wisselstanden gevolgd door een byte met een uniek bitwaarde die niet kan voorkomen bij de wisselstanden.
Maar dan kan je in 2 byte dus maximaal 15 wisselstanden opslaan.

Gewoon standaard Nano's. Ik heb het idee om niet met wav files te werken, maar met een pink noise generator. Maar dat is nog allemaal experimenteel. Het kan zijn dat ik het uiteindelijk heel anders ga doen. eerst maar eens wat proberen.
Ben benieuwd!


Timo

* Vrij vertaald: Ga geen problemen oplossen die er niet zijn
Verzonden vanaf mijn desktop met Firefox

meino

  • Offline Offline
  • Berichten: 627
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #100 Gepost op: 29 januari 2020, 22:30:40 »
Ligt er maar net aan wat je als fysieke laag gebruikt voor TCP/IP ;D Hebben we het over ethernet over CAT dan zou ik willen zeggen dat het wel een vorm van error protectie (niet error correctie) door het differentiaal paar door de selectiviteit te verhogen en common noise te ondervangen. Ofwel, geen zwakke fysieke laag. Maar het gaat dan natuurlijk om de gehele stack, net als hier. Dus ja, het is pas echt robuust met TCP/IP (of een andere vorm met error correctie of ACK ofzo) ;D
Ik weet dat op diverse hardware lagen ook checksums gebruikt worden. Maar voor IP is dat niet echt relevant. IP is zo gemaakt dat het gebruik kan maken van de meest primitieve hardware laag. Sommigen beschouwen de IP laag als een pseudo hardware laag, waar de echte checksum controle plaats vindt.

Maar dan kan je in 2 byte dus maximaal 15 wisselstanden opslaan.
Ik heb nu 12 wissels die via DCC en Koploper worden aangestuurd, met de 2 bytes kan ik maximaal 14 wisselstanden opslaan, 7 bits per byte. Worden dat meer wissels, dan schrijf ik gewoon meer bytes weg, Voor 21 wissels heb ik 3 data bytes nodig, etc.

Groet Meino
A clean desk is a sign of an empty mind

Kranenberg

Klaas Zondervan

  • Offline Offline
  • Berichten: 18297
    • Pagina van klaas
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #101 Gepost op: 29 januari 2020, 22:48:58 »
Ken inderdaad de "servo truc" ook van Klaas.
Ik gebruik inderdaad ook "gecastreerde" servo's. Maar ik bedien ze met halvegolfsturing. Geen gedoe met H-bruggen of PWM, maar gewoon een paar diodes die de stroom het goede pad wijzen. Dat heeft dan weer als bijkomstigheid dat ik over dezelfde draad ook de terugmelding krijg. Staat allemaal uitgelegd in mijn bouwdraadje over Without.

Wat ik weer bijzonder vind in deze discussie dat Meino kennelijk heel diep in de software en de overdrachtsprotocollen zit, maar van redelijk simpele elektronica geen kaas heeft gegeten. Bij mij is dat precies andersom, ik volg dit draadje nog steeds, maar de helft snap ik geen bal van.
Spoorbaan "Uit en Thuis" in aanbouw.

Martin Hornis

  • Offline Offline
  • Berichten: 1034
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #102 Gepost op: 30 januari 2020, 00:45:02 »
Dat soort vreemde zaken kwam ik 45 jaar geleden ook tegen. De elektronica-leraren op een HTS konden mij geen raadgeving geven met betrekking tot een impedantie-'overdracht'. Een energietechniek-leraar zei dat een emittervolger een standaardoplossing voor dat probleem is. Na 45 jaar gebruik ik dat treindetectie-systeem nog steeds op mijn modelbaan.
Märklin K-rails met boogstralen > 500 mm; NS-lichtseinen met cijferbak: 4, 6 en 8 in één bak; iTrain; Intellibox I; OC32; eigen treindetectiesysteem aangesloten op OC32; controleprogramma's voor iTrain en OC32.

meino

  • Offline Offline
  • Berichten: 627
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #103 Gepost op: 30 januari 2020, 02:11:09 »
Wat ik weer bijzonder vind in deze discussie dat Meino kennelijk heel diep in de software en de overdrachtsprotocollen zit, maar van redelijk simpele elektronica geen kaas heeft gegeten. Bij mij is dat precies andersom, ik volg dit draadje nog steeds, maar de helft snap ik geen bal van.
Ik denk dat dat redelijk klopt, mijn electronica kennis is gebaseerd op zaken die ik lang,lang geleden op de HBS heb geleerd, zaken als de wet van Ohm. Daar red ik me aardig mee, maar ik ga niet proberen om zelf iets te bedenken. Simpele zaken als voorloop weerstanden voor leds berekenen dat lukt wel. Verder heb ik in mijn werk best veel met Hardware engineers samengewerkt en dan pik je ook nog wel eens wat op. Maar hoe een zg H brug werkt? geen idee. Maar dat spreekt me ook zo aan de Arduino's aan, want daarmee kun je het meeste in programmatuur oplossen in combinatie met standaard interface kaartjes.
Overigens de truck met halve golf aansturing met diodes begrijp en ken ik ook. Maar ik had in mijn verzameling stekkervoedingen een 3V dc voeding liggen, en in kombinatie met mini schakelaars kon ik dat ook goed werkend krijgen.

Groet Meino
A clean desk is a sign of an empty mind

Kranenberg

Klaas Zondervan

  • Offline Offline
  • Berichten: 18297
    • Pagina van klaas
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #104 Gepost op: 30 januari 2020, 12:59:41 »
Overigens de truck met halve golf aansturing met diodes begrijp en ken ik ook. Maar ik had in mijn verzameling stekkervoedingen een 3V dc voeding liggen, en in kombinatie met mini schakelaars kon ik dat ook goed werkend krijgen.
Het enige nadeel dat ik zie bij halvegolfsturing is dat je daar een gewone trafo voor nodig hebt. Is duurder en zwaarder dan een schakelende voeding. Voordeel voor mij is dan weer dat ik nog een hele bak met trafo's heb liggen en voor die servo's kun je met een vrij kleine trafo volstaan.
Spoorbaan "Uit en Thuis" in aanbouw.