digitale data meesturen over 5V / 12V voedingslijnen ?

Wij doen dat zelfs met audio... Digitaal gaat het eenvoudigst door aan de 'zend' kant een stabilisator als bijv. een 7812 te gebruiken, met 2 diodes in serie met de Gnd aansluiting. Hierover zet je een mosfet.
Mosfet gesloten: output is 12v
Mosfet open: output is 13.3v
Dit werkt prima en is aan de andere zijde met een picje met comparator prima te detecteren.
(Voor audio gebruikten we een 47 Ohm weerstand en een LM386 i.p.v. 2 diodes en een fet)

Wat jij wil wordt bij modelspoortreinen al gedaan.
Alleen worden nullen en enen daar anders gevormd. De voedingsspanning wordt volledig omgepoold, en het is niet de spanning, maar de tijdsduur tussen twee ompolingen die bepaalt of iets een nul of een één is.

Voor een overzicht van de diverse protocollen die daarbij worden toegepast kun je eens hier kijken:
http://people.zeelandnet.nl/zondervan/digispan.html

Je kan het zo doen:

Naast RS232 kan je uiteraard ook een zelfverzonnen protocol gebruiken.

De schakeling van pros werkt wel alleen maar met klokkende signalen, manchester e.d. Je signaal mag namelijk geen last hebben van het feit dat je geen DC meer op je signaal hebt (dankzij de C-tjes).

Wat je ook kan doen is gewoon serieel gebruiken als voeding, als je dan met relatief lage data dichtheid (niet baudrate) signalen verstuurd, dan zie je daar in de praktijk heel weinig van, omdat de "idle" van je serieele lijn hoog is (en dus voeding). Het enige waar je dan rekening mee moet houden is dat je LEDs vermogen uit je seriele bus trekken, je zult dus een flinke transistor aan je TX moeten hangen, zodat deze het gewenste vermogen kan leven (bijv, 3 spotjes van 3x1W RGB = 9W, is een kleine 2A op 5V).
Je zult je microcontrollers aan de ontvangstzijde dan van een condensator moeten voorzien om ze geen spanningsdip te laten krijgen, maar die C's mogen niet aan je voedingslijn, omdat je dan je seriele signaal dempt, maar dit is eenvoudig met een diode op te lossen.

Op 12 mei 2011 16:29:11 schreef pros:
Je kan het zo doen:

[afbeelding]

Naast RS232 kan je uiteraard ook een zelfverzonnen protocol gebruiken.

Prachtig, ik wilde net hier gaan zoeken voor iets gelijkwaardig, toen ik dit topic zag.

Is het mogelijk
A. Uit te leggen hoe we C en de spoel moeten berekenen? moet ik denken aan 1mh en 100nf?

B. Zonder dit topic te kapen, is het mogelijk om
Device 1 te voeden via device 2,
Device 1 data te laten ontvangen van device 2
Device1 een terugkoppel signaal terug te laten sturen naar device2 om een 5v relais te schakelen.

Dacht aan een combinatie van ideeen van pros en arco.
B.v voeding 13,3 van device2 naar device1
Data van 5v van device2 naar device1 bovenop de voeding,
en het terugkoppel signaal de voeding laten instorten naar 12v als terugkoppel signaal ( al gelijk of niet tussen het verzenden van de data )?

Zoiets haalbaar?

Waarom zou je de data in beide richtingen op verschillende manier willen moduleren?

De voedingsspanning moduleren lijkt me de simpelste oplossing, met als nadeel dat de data alleen van de voeding naar andere devices kan. Je zou in het andere device een belasting over de lijn kunnen zetten die je moduleert, om op die manier data terug te sturen, maar dat lijkt me niet heel erg handig, vooral niet als je meerdere devices hebt die toch al aan het schakelen zijn in normaal bedrijf (LEDs, motortjes, dat soort dingen). Je kunt dat wat onderdrukken door de PWM frequenties veel hoger te kiezen dan de bitrate, en LC filters op te nemen zoals Pros voorstelt.

Ik heb ook wel eens wat experimenten gedaan met zulke dingen, maar het lastige is dat je toch al wat rommel op de voeding krijgt als je veel verschillende devices wilt kunnen gebruiken, en in elk device een forse driver nodig hebt om voldoende ruismarge over te houden.

Met het concept van Pros zou je de tijd tussen de flanken direct kunnen gebruiken om bitjes te versturen, met wat trucjes voor clock recovery. Waarschijnlijk moet je de decodering nog helemaal in software doen, wat nog een flinke uitdaging is, en behoorlijk wat rekentijd gaat kosten, denk ik.

Wat je ook zou kunnen doen, is een draaggolf op de lijn moduleren voor een 0 en niets moduleren voor een 1, en de voeding moduleren met een clock signaal. Op die manier zou je de I2C periferal van de microcontrollers kunnen gebruiken om te communiceren. Je kunt dan alsnog geen multi-master bus maken, aangezien er maar 1 controller is die de clock kan genereren, en je kunt geen clock stretch gebruiken, maar dat lijken me geen grote problemen. Voor dergelijke toepassing heb je geen multi-master bus nodig, lijkt me, en in plaats van clock stretching kun je ook wait-state data sturen als een controller tijd nodig heeft om iets te verwerken, of gewoon zorgen dat je de data altijd klaar hebt staan.

Dit zou de implementatie van de software een stuk eenvoudiger maken, denk ik, en de hardware hoeft er ook niet echt moeilijk voor te zijn. Een RC low-pass filter om het hoogfrequente signaal te onderdrukken, met een comparator die dat signaal vergelijkt met het signaal uit een trager low-pass filter als referentie geeft het clocksignaal, en het concept van Pros van een smal bandpass filter rond de opamp voor de data. De data vanaf een device op de bus zetten kan zo simpel zijn als een push-pull drivertje van een paar transistors.

Het rendement van het geheel is natuurlijk beroerd; bij het moduleren van de voeding ga je waarschijnlijk al wat verstoken, en de devices hebben waarschijnlijk ook allemaal een regelaar nodig met wat marge, dus ook daar wordt wat verstookt.

Een ander alternatief kan natuurlijk het gebruik van een UART zijn, in plaats van I2C, op die manier heb je de clock helemaal niet nodig. Doordat elk device de verzonden data ook terug krijgt, kun je ook een soort van arbitration implementeren, waardoor het een beetje op een CAN bus gaat lijken.

Opties genoeg...

Kris,

Waarom gebruik je het DCC protocol niet? Je hebt toch zelf een modeltrein liggen.

In een grijs verleden heeft er in Elektuur ook eens een schakeling gestaan om een windrichting en de voeding van de buitenschakeling gelijktijdig over 2 draden te sturen. Was ook niet zo'n ingewikkeld geheel. Ik kan het wel eens voor je opzoeken mocht je het nummer zelf niet hebben.

Theo

edit: staat in het januari nummer van 1984.

Je kan ook naar protocollen als X10 en KNX (signaal op nuldoorgang van AC) of 1-Wire (voeding kortstondig naar GND trekken, waarschijnlijk minder geschikt voor grote stromen).

of Opentherm...

of Opentherm...

Da's een beetje prijzig voor thuisgebruik...
Wat ik me kan herinneren kost een licentie voor gebruik van Opentherm zo'n 2600 euro per jaar...

Als je maar 1-richtings communicatie nodig hebt naar 1 of meerdere "slaves", dan denk ik dat je de schakeling van pros of het voorstel van Arco prima kan gebruiken in combinatie met een infrarood-communicatie-protocol, zoals bvb. het RC5 protocol van Philips (= Manchester codering) of het SIRCS protocol van Sony ( = puls breedte codering):
http://82.197.193.203/Elektuur-Origineel/Elektuur2001/2001/n013074.PDF
Dat kan je verder zo intelligent of dom maken als je wil met error-correctie mechanismen, multiple-byte commando's....

Als je bidirectionele communicatie wil met meerdere "slaves" dan kan dat op dezelfde manier, maar moet je je communicatie protocol slim aanpakken met een soort adressering en met een vraag/antwoord methode zodat je geen conflicten krijgt. Bvb : Commando voor slave1, antwoord van slave1 afwachten, commando voor slave2, antwoord van slave2 afwachten.....

Als echt alles tegelijk moet kunnen in een rotsvast protocol, dan moet je al richting I2C, CAN of RS232 gaan, zoals SparkyGSX aangeeft.

Om er nog maar een methode aan toe te voegen: DiSeqC (1.2) wat de satelliet ontvangers gebruiken om LNB/polar mounts aan te sturen.
12V bus lijn met een 22KHz data protocol van 250mVpp nominaal.

Reference implementaties zijn vrij beschikbaar. En ook IC's waar het eea in zit.

Beknopt:
http://nl.wikipedia.org/wiki/DiSEqC

Volledige spec/app notes:
http://www.eutelsat.com/satellites/4_5_5.html

Je gebruikt het hardware protocol en de data definieer je dan naar eigen wens.

Hou er wel rekening meer dat de data carrier behoorlijk wat power moet kunnen leveren als het halogeen spots zijn.

[Bericht gewijzigd door henri62 op zaterdag 14 mei 2011 00:31:59 (19%)]

Op 13 mei 2011 16:56:46 schreef Arco:
[...]
Da's een beetje prijzig voor thuisgebruik...
Wat ik me kan herinneren kost een licentie voor gebruik van Opentherm zo'n 2600 euro per jaar...

fripster bedoeld waarschijnlijk de hardware interface van OpenTherm.
Die is kinderlijk eenvoudig en kan je 2 richtingen uit op 1 voedingslijn

precies..dat is wat ik bedoelde