Nieuwe BiDiB-componenten deel 1: introductie

Ik ben helemaal fan van BiDiB: het communicatieprotocol bedoeld om in de wereld van de digitale modelbanen te communiceren tussen de centrale en de modelbaan(componenten). Bij BiDiB hoort ook de BiDiBus: een zogenaamde seriële RS485-bus waarmee de BiDiB-berichten van bijvoorbeeld de centrale naar een decoder kunnen worden gestuurd.

BiDiB en BiDiBus zijn, in tegenstelling tot bijvoorbeeld LocoNet en de CAN-bus, een volledig open standaard. Dat betekent dat de specificaties vrij verkrijgbaar zijn en dat iedereen in principe kan aansluiten op het bussysteem. Als de standaard goed geïmplementeerd is, zouden decoders en andere componenten van verschillende fabrikanten met elkaar uitwisselbaar moeten zijn.

Om dit te waarborgen zijn er overigens een paar simpele voorwaarden voor het gebruik van de standaard en meer specifiek van het BiDiB-logo. Zo moet het gedeelte van je code waarin berichten gecodeerd worden vrij beschikbaar gesteld worden.

Technologisch is de BiDiBus superieur aan andere bussystemen. Deze is bijvoorbeeld veel sneller. Ten opzichte van LocoNet is de BiDiBus dertig keer zo snel.

Wat is er (commercieel) verkrijgbaar?

Hoewel de BiDiB- en BiDiBus-standaarden sinds medio 2010 bestaan, hebben helaas maar weinig fabrikanten de BiDiBus omarmd. Van oorsprong waren BiDiB-componenten alleen als zelfbouw realiseerbaar via een aantal ontwerpen die op de OpenDCC website beschikbaar zijn gesteld.

Later is dit door FichtelBahn opgepakt. Zij hebben eerst digitale componenten verkocht op basis van deze ontwerpen, maar maken inmiddels geheel eigen componenten (die in sommige gevallen wel grotendeels gebaseerd zijn op de originele OpenDCC-ontwerpen).

Hiernaast heeft eigenlijk alleen TAMS Elektronik componenten gerealiseerd met BiDiB. Deze zijn commercieel gewoon goed verkrijgbaar. De centrale van TAMS, de mc², is misschien wel de meest complete centrale die verkrijgbaar is en ondersteunt bijna alle bussystemen en protocollen door elkaar heen.

Bezwaren tegen de beschikbare producten

De wens die ik heb voor BiDiB-componenten is een compacte print die liefst in zelfbouw te realiseren valt. Op zich zijn er van OpenDCC componenten verkrijgbaar voor alle noodzakelijke acties:

• Het aansturen van servo’s, motoren, magneetartikelen en leds;
• Het registreren van inputs;
• Het versterken van het DCC-signaal voor de rails (booster);
• Het vertakken van de BiDiBus (hub).

Nadeel is echter dat de modules vrij prijzig zijn. Dat laatste is geen probleem als je een relatief kleine modelbaan bouwt. Als je echter 80 modules nodig hebt en ze gemiddeld zo’n € 70,- kosten wordt het een dure aangelegenheid.

Daarnaast speelt de fysieke vorm mee. De verkrijgbare printplaten zijn grotendeels gemaakt voor montage onder de baan. Ik heb een plan voor iets anders, maar dat vereist wel dat de printplaten compact zijn.

Een derde nadeel is dat de zelfbouw printplaten van OpenDCC gedateerd beginnen te raken. Veel componenten zijn inmiddels obsolete. Dat vertaalt zich in een moeilijkere verkrijgbaarheid, of de prijs is veel hoger dan nodig. De in die printplaten veelgebruikte ATXmega128 series bijvoorbeeld zijn weliswaar nog heel populair, maar eigenlijk allang opgevolgd door veel meerdere en goedkopere microcontrollers.

Tijd voor iets anders!

Omdat ik niet verwacht dat andere fabrikanten BiDiB zullen gaan omarmen (ze houden de modelbouwer liever in hun eigen gesloten systeem) en omdat ik ook geen nieuwere varianten van OpenDCC verwacht (de innovatie zit bij FichtelBahn meer in hun eigen ReadyLine-producten) moet ik maar zelf aan de slag.

Nu begrijp ik elektronica basaal, maar (vooralsnog) onvoldoende om van scratch af aan alles te bedenken. Gelukkig zijn de schema’s van OpenDCC openbaar en kun je daar een hoop informatie en inspiratie uit halen.

Ik ga dus zelf een serie BiDiB-printplaten ontwikkelen. Eerst dacht ik nog aan het binnen de kaders van de bestaande printplaten “updaten” van de OpenDCC-ontwerpen. Om dat te kunnen doen zul je echter wel binnen de ATXmega microcontrollers moeten blijven en gaandeweg heb ik besloten dat dat geen optie is. Ik zal dus ook een hele software-implementatie moeten gaan maken.

In een volgend blogbericht zal ik ingaan op mijn plannen en vertellen wat uiteindelijk de bedoeling is. Dit is geen project van een paar weken, maar ik verwacht dat het me zo’n twee tot drie jaar aan ontwikkeling zal kosten.