Det finns en jättenackdel med dagens dekoderteknik - körström och data är blandat. Eller, man kan uttrycka det så här, dataströmmen ÄR körströmmen.
Det får flera effekter. Dekodrar i lok kan inte själva generera information och skicka ut den på spåren, eftersom det måste vara rejäla spänningar och strömmar, det ska räcka åt motorerna i andra lok, solenoider till växlar och så vidare.
Det bästa hade varit att ha en SEPARAT buss för datat, och ha körströmmen på rälsen som vanligt. I princip skulle man då kunna ha konstant 16 V DC över rälsen (eller 16V AC på en Märklinisk anläggning) och sedan styra en effektreglering av motorn via en annan buss.
Bara ett litet problem, järnvägar har två räler (vissa har visst punktkontakter också, sägs det, men där är relärna förbundna med varandra).
Det finns inte så många andra sätt att få in styrdata. Eller är det där egentligen sant? Man borde kunna använda radio, t.ex. 866 MHz-bandet.
En radio kan nämligen fungera som en "trådlös buss" där man skickar digitala paket med information. Många sändare och mottagare kan alltså dela på samma frekvens - precis som alla enheter på en elektrisk buss egentligen "hör" allt, men struntar i information som inte är adresserad till den.
En av de mer kända tillämpningarna av digital radiotrafik är elmätare, som använder ett protokoll som kallas M-bus. Elmätare ska kunna läsas av via radio (EU-direktiv) eftersom debitering ska ske efter faktisk förbrukning. Ett annat sånt här protokoll är Zigbee. På mitt jobb pratas det mycket om IPv6 som protokoll, eftersom antalet adresser (2 upphöjt i 64) medger enorma mängder enheter i sådana nät.
De här protokollen är DUBBELRIKTADE, vilket innebär att en kontrollstation kan få tillbaka information från växlar, lok m.m. Det ger helt andra möjligheter än DCC, MFX och Motorola... Eftersom dekodrar inte behöver generera körström så kan de "prata".
Är det någon som vet om NMRA håller på att titta på standarder för radiokontrollerade dekodrar?
Radiotransceivrar (kombinerade mottagare/sändare) kostar 2-3 Euro och är i DIL-kapselstorlek. En dekoder på 3-4 cm2 är fullt rimlig.
Transceiver, en processor, matning till processorn och nån form av transistorsteg till motorn är vad som behövs på kortet. En DC-motor reglerar man genom en PWM på processorn, och en transistor som man kör spänningen från rälsen igenom.
Toppbilden, visa:
Radio-dekodrar?
-
Svante Andersson
- Inlägg: 1179
- Blev medlem: 01 jan 2012, 23:05
Re: Radio-dekodrar?
Magnus... tanken är riktig.
Men... dekodrar större än idag är bara att glömma. De flesta vill idag ha ljud i de fordon där en högtalare får plats. Någon måste utveckla det hela.
Dessutom är pulståget på 19V toppvärde bättre för strömupptagning än ren DC... fast man kan ju ha en kantspänning istf DC även i din version.
Jag körde själv redan radiostyrt i slutet av 80-talet, då med batterier i fordonet. Min tanke då som aldrig blev genomförd var att "stjäla" ström från den bara jag körde på för laddning av batterier vilket skulle ge ett mindre krav på batteristorlek. Ett sådant sätt att köra skulle eliminera alla problem med vändslingor och spårtrianglar, bara att ha en isolerad sektion för att undvika kortisar.
SA
Men... dekodrar större än idag är bara att glömma. De flesta vill idag ha ljud i de fordon där en högtalare får plats. Någon måste utveckla det hela.
Dessutom är pulståget på 19V toppvärde bättre för strömupptagning än ren DC... fast man kan ju ha en kantspänning istf DC även i din version.
Jag körde själv redan radiostyrt i slutet av 80-talet, då med batterier i fordonet. Min tanke då som aldrig blev genomförd var att "stjäla" ström från den bara jag körde på för laddning av batterier vilket skulle ge ett mindre krav på batteristorlek. Ett sådant sätt att köra skulle eliminera alla problem med vändslingor och spårtrianglar, bara att ha en isolerad sektion för att undvika kortisar.
SA
Vila i tid... så blir risken att du behöver "VILA I FRID" betydligt mindre!
Re: Radio-dekodrar?
Troligtvis för att någon har räknat på hur mycket enheter som pratar på en begränsad yta. Är ju inga problem i en lägenhet,magnus63 skrev:Det finns inte så många andra sätt att få in styrdata. Eller är det där egentligen sant? Man borde kunna använda radio, t.ex. 866 MHz-bandet.
En radio kan nämligen fungera som en "trådlös buss" där man skickar digitala paket med information. Många sändare och mottagare kan alltså dela på samma frekvens - precis som alla enheter på en elektrisk buss egentligen "hör" allt, men struntar i information som inte är adresserad till den.
En av de mer kända tillämpningarna av digital radiotrafik är elmätare, som använder ett protokoll som kallas M-bus. Elmätare ska kunna läsas av via radio (EU-direktiv) eftersom debitering ska ske efter faktisk förbrukning. Ett annat sånt här protokoll är Zigbee. På mitt jobb pratas det mycket om IPv6 som protokoll, eftersom antalet adresser (2 upphöjt i 64) medger enorma mängder enheter i sådana nät.
De här protokollen är DUBBELRIKTADE, vilket innebär att en kontrollstation kan få tillbaka information från växlar, lok m.m. Det ger helt andra möjligheter än DCC, MFX och Motorola... Eftersom dekodrar inte behöver generera körström så kan de "prata".
men i en stor FREMO träff med hundratals moduler och tusentals med prylar som skall sända kan det definitivt bli ett problem.
Skall bli intressant och se när de försöker använda Z21 i en stor träff...........
Men exempelvis i mitt bostadshus, där vi använder WiFi har alla begränsad bandbredd tack för många som försöker använda det samtidigt.
Samma sak när vi har träffar i Stockholms Skalabåt klubb och någon drar på en kanal för att skicka video så får man störningar direkt i videolänkan
tack vare alla båtradio kanalerna.
Fundera på hur många sändare och mottagare samt typ och vilken bandbredd som dessa behöver. Vid RC skickar man samma kommando hela tiden,
för att vara säker på att den kommer fram trots störningar. Räkna med att ju närmare maximum du hamnar
får antagligen samma problem som med en Ethernet buss med återsändningar och standoff tider.
Misstänker att i framtiden kommer frekvenserna att krypa uppåt med mera prylar som vill kommunicera.........
MvH Roberth
Re: Radio-dekodrar?
Man kan va precis vad som helst på spåret, det påverkar egentligen inte dekodern. Inte direkt i alla fall, möjligen den delen av dekodern som försörjer övriga delar med ström. Likriktarbrygga och glättningskondingar kanske påverkas så att man får en någorlunda snygg 5V (eller 3.3V) DC till resten av komponenterna i dekodern.Svante Andersson skrev:Magnus... tanken är riktig.
Men... dekodrar större än idag är bara att glömma. De flesta vill idag ha ljud i de fordon där en högtalare får plats. Någon måste utveckla det hela.
Dessutom är pulståget på 19V toppvärde bättre för strömupptagning än ren DC... fast man kan ju ha en kantspänning istf DC även i din version.
Tar man drivspänningen från spåret kvarstår de klassiska problemen med vändslingor etc. I alla fall om man har 2-räls.Svante Andersson skrev: Jag körde själv redan radiostyrt i slutet av 80-talet, då med batterier i fordonet. Min tanke då som aldrig blev genomförd var att "stjäla" ström från den bara jag körde på för laddning av batterier vilket skulle ge ett mindre krav på batteristorlek. Ett sådant sätt att köra skulle eliminera alla problem med vändslingor och spårtrianglar, bara att ha en isolerad sektion för att undvika kortisar.
SA
Jag är inte säker på att en dekoder med radiotransciever blir större än en vanlig DCC-dekoder. Man slipper nämligen ingångssteget (optobryggan) eftersom man inte behöver bygga en galvanisk isolering från nån svinstark kontrollsignal. Strömförjningsdelen (som tar ner 19V fyrkantsvåg AC till 5V DC) finns där redan idag på dekodern, "snor" man DC från rälsen behöver man inte likrikta heller, det räcker med ett litet DC-DC chip. Dessutom finns det en helvågslikriktarbrygga som tar 19V fyrkant till 16V DC till motorn, den slipper man.
Ska man ha dekodern liten gäller dock ytmonterade komponenter och det är inget man kan göra hemma!
Re: Radio-dekodrar?
Ja och nej. Det beror på flera saker, och det finns flera aspekter på det problemet.robbox skrev: Troligtvis för att någon har räknat på hur mycket enheter som pratar på en begränsad yta. Är ju inga problem i en lägenhet,
men i en stor FREMO träff med hundratals moduler och tusentals med prylar som skall sända kan det definitivt bli ett problem.
Skall bli intressant och se när de försöker använda Z21 i en stor träff...........
1) Arbitration (vet inte vad det heter på svenska). Alltså, vem får snacka, när och varför. Det finns en massa olika tekniker för det här.
Ethernet har egentligen ingen arbitration, utan varje nod får snacka precis när den vill men BARA om det är tyst på nätet (CSMA). Så innan en nod
börjar babbla SKA det vara en ren bärvåg som inte modulerar ettor eller nollor.
ProfiBUS (en ganska vanlig industribuss som använder RS485 som medium), där får ingen nod förutom master-noden snacka. Däremot får noder svara på tilltal, de SKA svara på tilltal från master-noden. Det ger en bättre determinism än Ethernet.
2) Bitrate. Ju kortare tid det tar att skicka ett meddelande, desto mindre tid ockuperar man en kabel eller en radiogrid. Ethernet ligger uppåt 100 Mbit/s och upp till 1 Gbit/s. En RS485-lina har lite olika bitrate beroende på längd, men upp emot 12 Mbit/s förekommer. Så snabb är INTE en radiolänk.
3) En DCC-buss ligger på 6700 bit/sekund (i snitt. Bitarna behöver 120 resp 200 usec på sig). De minsta meddelandena har 3 byte information (24 bitar) men innehåller 3 "mellanbitar", 1 stoppbit och 14 preamblebitar så det är rätt mycket overhead. 18 bitars overhead, 45% av meddelandet i sig...
De radiochip jag jobbat med (SiLAB 4360) brukar man köra på 19600 bit/sekund.
Man kan inte skicka kommandon hela tiden. DCC funkar så, men det har mindre med dålig mottagning att göra, och mer med att DCC-signalen ÄR strömförsörjning till lokens motorer. De flesta meddelanden som skickas är kommandot IDLE som broadcastas, så för det mesta säger kontrollstationen "Lyssna allihop! Gör ingenting!"-robbox skrev: Men exempelvis i mitt bostadshus, där vi använder WiFi har alla begränsad bandbredd tack för många som försöker använda det samtidigt.
Samma sak när vi har träffar i Stockholms Skalabåt klubb och någon drar på en kanal för att skicka video så får man störningar direkt i videolänkan
tack vare alla båtradio kanalerna.
Fundera på hur många sändare och mottagare samt typ och vilken bandbredd som dessa behöver. Vid RC skickar man samma kommando hela tiden,
för att vara säker på att den kommer fram trots störningar. Räkna med att ju närmare maximum du hamnar
får antagligen samma problem som med en Ethernet buss med återsändningar och standoff tider.
Misstänker att i framtiden kommer frekvenserna att krypa uppåt med mera prylar som vill kommunicera.........
MvH Roberth
Våra meshnet för elmätare har 4094 noder (av den anledningen att det är 10-bitarsadressering, två adresser används för broadcast) och de har inga problem med krockar MEN de snackar inte speciellt mycket. WiFi snackar ju hela tiden, samma sak med videolänkar.
Tål att funderas på i alla fall.
Re: Radio-dekodrar?
Om de publicerar sitt radioprotokoll skulle det kunna vara något. Innan de gör det så tror jag mer på att ett antal kloka människor slår sina huvuden ihop och gör något inom NMRAs/NEMs hank och stör. DCC är ju bra med de begränsade förutsättningar som en "data-överlagrat-på-körströmmen" ger. Öppet, stödjer programmering av EEPROM ("CV") både på programmeringsspår och på själva anläggningen (det funkar men loket måste ha en adress först, annars går det INTE).
Hemsnickrade låsta odokumenterade protokoll tror jag inte ett dugg på. Det hack jag gjorde åt Hemi vad gällde Motorola-Märklin byggde på att folk hade skvallrat på nätet hur protokollet fungerade, läs hackat det, men informationen var knapphändig och därmed blev MM-versionen av dekodern väldigt korkad.
(CV-programmering funkade inte därför att jag inte VET om MM stödjer sådana finesser. Jag vet fortfarande inte om protokollet stödjer det...)
Så - GLÖM odokumenterade speciallösningar.
Hemsnickrade låsta odokumenterade protokoll tror jag inte ett dugg på. Det hack jag gjorde åt Hemi vad gällde Motorola-Märklin byggde på att folk hade skvallrat på nätet hur protokollet fungerade, läs hackat det, men informationen var knapphändig och därmed blev MM-versionen av dekodern väldigt korkad.
(CV-programmering funkade inte därför att jag inte VET om MM stödjer sådana finesser. Jag vet fortfarande inte om protokollet stödjer det...)
Så - GLÖM odokumenterade speciallösningar.
Re: Radio-dekodrar?
Jag tycker fortfarande man kan använda WiFi (IPv4 och/eller IPv6), dekodrar bör kunna ersättas av en liten Linux-kärra på ett eller två små chip.
Och så ren strömmatning från räls/kontaktledning till fordonen.
Utmaningen är väl "bara" att få plats i fordonen men kollar man vad som finns i t ex en Webbkamera (typ Axis) så...
Och så ren strömmatning från räls/kontaktledning till fordonen.
Utmaningen är väl "bara" att få plats i fordonen men kollar man vad som finns i t ex en Webbkamera (typ Axis) så...
Med bästa hälsningar
/CGN (Om inga bilder visas så är min server nere - det händer, men inte ofta)
/CGN (Om inga bilder visas så är min server nere - det händer, men inte ofta)
Re: Radio-dekodrar?
IPv6 kommer mer och mer, jag märker det på jobbet.
Man ska komma ihåg en sak om IP - det är ett protokoll avsett för att skicka information mellan OLIKA typer av nätverk. Man kan jämföra det med en ISO-container. Containrar passar på lastbilar, tåg, båtar, flygplan och andra fordon, just för att man enkelt ska kunna flytta gods mellan OLIKA fordonssystem.
För att kommunicera mellan två noder på ett Ethernet är IP egentligen bara en onödig barlast. IP-paketet läggs inuti Ethernet-paketet. Ska man kommunicera mellan en maskin på ett Ethernet och ett TokenRing så är IP nödvändigt, då man kan "lyfta ur" IP-paketet ur ett Ethernet-paket och "lyfta in det" i ett TokenRing-paket, eller vise versa. IP betyder just "INTER network Protocol".
Ovanpå IP (eller snarare inuti IP-paketen) använder man framför allt protokollen TCP och UDP, det förstnämnda funkar som en oändlig ström av tecken (en "ström") medan det andra är paket.
Inuti UDP eller TCP kan man hitta på sitt eget protokoll, genom att skriva via programmeringsinterfacet "sockets". Det är ett ganska enkelt och begripligt programmeringsinterface.
En 32-bitars ARM-kärna (ST Cortex M3 eller nåt) kanske skulle kunna klara en liten RT-Linux eller nåt. Processorn ligger runt 20:-, drar knappt nån ström och är riktigt fläskig. Sitter i en del smarta telefoner. ARM-konsortiet verkar ha gett sig tusan på att förstöra marknaden för 8-bitarsprocessorer genom att erbjuda otroligt avancerade processorer för löjligt låga priser.
TCP/IP är egentligen lite för klumpigt för MJ, men samtidigt skulle man ju kunna styra modelljärnvägen från i princip vad som helst.
Egentligen skulle man kunna använda DCC genom UDP. Eftersom man slipper adresseringen och checkumman räcker det med en enda byte för att styra ett lok, tre byte för att programmera det. Och detta på EN enda UDP-port. Andra portar kan användas för att skicka tillbaka information.
Kan kolla lite på jobbet imorgon hurpass mycket data man kan skicka över en UDP/IPv6-lina. Vi använder det för att koppla upp kossor (!!) på nätet, för brunstperiod, foderstatus, ev. sjukdomar, m.m.
Man ska komma ihåg en sak om IP - det är ett protokoll avsett för att skicka information mellan OLIKA typer av nätverk. Man kan jämföra det med en ISO-container. Containrar passar på lastbilar, tåg, båtar, flygplan och andra fordon, just för att man enkelt ska kunna flytta gods mellan OLIKA fordonssystem.
För att kommunicera mellan två noder på ett Ethernet är IP egentligen bara en onödig barlast. IP-paketet läggs inuti Ethernet-paketet. Ska man kommunicera mellan en maskin på ett Ethernet och ett TokenRing så är IP nödvändigt, då man kan "lyfta ur" IP-paketet ur ett Ethernet-paket och "lyfta in det" i ett TokenRing-paket, eller vise versa. IP betyder just "INTER network Protocol".
Ovanpå IP (eller snarare inuti IP-paketen) använder man framför allt protokollen TCP och UDP, det förstnämnda funkar som en oändlig ström av tecken (en "ström") medan det andra är paket.
Inuti UDP eller TCP kan man hitta på sitt eget protokoll, genom att skriva via programmeringsinterfacet "sockets". Det är ett ganska enkelt och begripligt programmeringsinterface.
En 32-bitars ARM-kärna (ST Cortex M3 eller nåt) kanske skulle kunna klara en liten RT-Linux eller nåt. Processorn ligger runt 20:-, drar knappt nån ström och är riktigt fläskig. Sitter i en del smarta telefoner. ARM-konsortiet verkar ha gett sig tusan på att förstöra marknaden för 8-bitarsprocessorer genom att erbjuda otroligt avancerade processorer för löjligt låga priser.
TCP/IP är egentligen lite för klumpigt för MJ, men samtidigt skulle man ju kunna styra modelljärnvägen från i princip vad som helst.
Egentligen skulle man kunna använda DCC genom UDP. Eftersom man slipper adresseringen och checkumman räcker det med en enda byte för att styra ett lok, tre byte för att programmera det. Och detta på EN enda UDP-port. Andra portar kan användas för att skicka tillbaka information.
Kan kolla lite på jobbet imorgon hurpass mycket data man kan skicka över en UDP/IPv6-lina. Vi använder det för att koppla upp kossor (!!) på nätet, för brunstperiod, foderstatus, ev. sjukdomar, m.m.
Re: Radio-dekodrar?
Hej, kul diskussion.
Som Magnus är inne på så finns det protokoll i flera olika nivåer. Som ryska dockor ungefär. En av de stora skillnaderna mellan TCP och UDP är att TCP innehåller felkontroll och omsändning. Använder man TCP så vet man att informationen kommer fram. Det kan låta bra men är ofta onödigt om det finns ett under- eller överliggande protokoll som redan hanterar detta. Datafolk brukar gilla TCP, inom telekom finns större förståelse för UDP.
IPv4 eller IPv6 spelar nog ingen större roll. Med IPv4 måste man administrera adresser på ett sätt man slipper med IPv6 men eftersom snart varendaste liten pryl stödjer IPv6 så spelar det inte så stor roll.
Jag gissar att det som kräver mest bandbredd är ljudet. Om loket genererar ljudet så vill man skicka basen till en subwoofer under anläggningen. Har man centralt genererat ljud vill man skicka det till loket och få tillbaka information om koppelstångens position.
Enklast vore om man hittade en färdig krets med Wi-Fi, kraftelektronik och en liten webserver. Den skulle man kunna styra via HTTP från snart sagt vad som helst.
Som sagt, några lösa tankar på söndagskvällen
/Olof
Som Magnus är inne på så finns det protokoll i flera olika nivåer. Som ryska dockor ungefär. En av de stora skillnaderna mellan TCP och UDP är att TCP innehåller felkontroll och omsändning. Använder man TCP så vet man att informationen kommer fram. Det kan låta bra men är ofta onödigt om det finns ett under- eller överliggande protokoll som redan hanterar detta. Datafolk brukar gilla TCP, inom telekom finns större förståelse för UDP.
IPv4 eller IPv6 spelar nog ingen större roll. Med IPv4 måste man administrera adresser på ett sätt man slipper med IPv6 men eftersom snart varendaste liten pryl stödjer IPv6 så spelar det inte så stor roll.
Jag gissar att det som kräver mest bandbredd är ljudet. Om loket genererar ljudet så vill man skicka basen till en subwoofer under anläggningen. Har man centralt genererat ljud vill man skicka det till loket och få tillbaka information om koppelstångens position.
Enklast vore om man hittade en färdig krets med Wi-Fi, kraftelektronik och en liten webserver. Den skulle man kunna styra via HTTP från snart sagt vad som helst.
Som sagt, några lösa tankar på söndagskvällen
/Olof
Re: Radio-dekodrar?
http är inkapslat i tcp som är inkapslat i ip som är inkapslat i WiFi.... Förstår inte poängen OM bandbredd och baudrate är ett problem. Vilket det kanske inte är..?
Jag hade samma problem i helikopter 14 när jag byggde en hel tcp/ip-stack som gick på ett LAN inuti helikopter. Jag frågade varför man inte skickade datat direkt i Ethernet, allting satt ju på samma Ethernet i alla fall. Svaret var att "men då kan vi inte köra wireshark". GAAaaahhh!!!! Snacka om att missförstå varför IP och ovanliggande skikt existerar.
(Japp jag skrev själva STACKEN -IP, ARP, RARP, ICMP, UDP och TCP - och socket API, det enda som ens liknande ett operativ var en liten RTOS, tror det var Eneas OSE om jag minns rätt)
Jag hade samma problem i helikopter 14 när jag byggde en hel tcp/ip-stack som gick på ett LAN inuti helikopter. Jag frågade varför man inte skickade datat direkt i Ethernet, allting satt ju på samma Ethernet i alla fall. Svaret var att "men då kan vi inte köra wireshark". GAAaaahhh!!!! Snacka om att missförstå varför IP och ovanliggande skikt existerar.
(Japp jag skrev själva STACKEN -IP, ARP, RARP, ICMP, UDP och TCP - och socket API, det enda som ens liknande ett operativ var en liten RTOS, tror det var Eneas OSE om jag minns rätt)
Re: Radio-dekodrar?
Brian Barnt på NMRA håller tydligen i trådarna vad gäller radiostyrning. Ska kolla lite imorgon.
Re: Radio-dekodrar?
Jag tror inte bandbredd och baudrate är något problem så länge vi inte behöver köra alltför många 4K-videokanaler mellan lok och förare. Våra krav på ping-tid ligger också långt under vad som krävs i First Person Shooter spel. Tåg skall vara lite tröga att styra.magnus63 skrev:http är inkapslat i tcp som är inkapslat i ip som är inkapslat i WiFi.... Förstår inte poängen OM bandbredd och baudrate är ett problem. Vilket det kanske inte är..?
Storlek och pris är inte heller något problem. Det enda problem jag ser är hur man kommer upp i så stora volymer att man kan använda samma teknik (grad av integration) som i mobiltelefoner. MJ-marknaden räcker inte utan jag tror det måste vara en standardlösning från ett annat område.
/Olof
Re: Radio-dekodrar?
Vi är rätt stora på IPv6-meshnet, mest elmätare, så vi kanske har nåt.