BeneluxSpoor.net forum
Vraag en antwoord => Digitaal => Topic gestart door: bask185 op 24 maart 2019, 16:32:32
-
Beste modelspoor fanaten,
Ik ben afgelopen week druk bezig geweest met het uitpluizen van DCC pakketjes voor een zelf gemaakte arduino centrale.
Vandaag wilde ik testen en helaas de trein wilt niet rijden :(
De hardware bestaat uit; een 15V DC voeding die ik nog had rondslingeren, een arduino nano, een 2.5A H-brug en een schakelende voeding van 15V naar 5V voor de arduino. Er zit ook nog een printje voor de Rs485 bus maar deze is nog niet gebruik. Ik heb het met 2 treinen geprobeerd en het spoor is schoon.
(https://images.beneluxspoor.net/bnls/WhatsApp-Image-2019-03-24-at-14.20.08_1.jpeg)
Het grootste probleem is dat ik nog werk met een iet wat antieke oscilloscoop en niet makkelijk het hele signaal kan aanschouwen.
(https://images.beneluxspoor.net/bnls/WhatsApp-Image-2019-03-24-at-14.20.08-1.jpeg)
Wel heb ik dmv data te dumpen op het scherm bevestigd dat de geassembleerde bit reeks klopt, althans dat hij is wat ik denk dat het moet zijn.
//11111111111111 0 00001001 0 01110101 0 10011001 0 10110000 0 10111001 1 0000
//14 bit preable address 9 speed 9 ^ ^ F5-F8 checksum 4 trailing 0's
// | |
// headlight
// |
// F1-F4
Ik klok alles uit van links naar rechts.
Ik heb dit adhv de nmra website samengesteld:
Speed and Direction Packet For Locomotive Decoders
111111111111 0 0AAAAAAA 0 01DCSSSS 0 EEEEEEEE 1
Preamble Byte One Byte Two Byte Three (Error Detection Data Byte)
Dus mijn eerste vraag: stel ik de data pakketten goed samen?
Tweede vraag: de checksum byte. De nmra website is niet bijzonder duidelijk. Het komt er op neer dat je alle data adress bytes met de data bytes moet XOR'en. Maar nu heb ik 1 adres byte en 3 data bytes. Moet ik nu voor de checksum 1 byte sturen of 3 bytes? En als het 3 bytes zijn, moet er dan ook nog een '0' bit hier tussen? (Ik dacht dat er tussen bytes altijd en immer een 0 bit moet zitten ???)
De software heb ik zo simpel als mogelijk gehouden. Via de seriele bus stuur ik van de computer een pakketje van 5 bytes. Een * om door te geven dat ik een instructie stuur. Een adres byte, een snelheid byte, een byte voor de koplampen en nog een byte voor F1 t/m F8. Ik heb er bewust voor gekozen om te beperken tot slechts 8 functies.
Ik stuur continu pakketten voor adres 1 t/m 80.
Als een pakket verstuurd is, incrementeer ik het adres, prepareer een nieuw pakket en begin opnieuw.
In deze functie worden de pakketten samengesteld. Ik heb een struct array 'train' gemaakt. Elke 'train' bestaat uit 3 bytes voor de snelheid en functies.
void assemblePackets() {
byte speed_tmp; // make local variable for speed to calculate with
/****** ADDRES *******/
packetAddres = addres;
/****** SPEED *******/
speed_tmp = train[addres].speed; // store speed in 'speed_tmp' to calculate with
packetSpeed = 0; // clear byte for re-usage
if(speed_tmp < 0) {
packetSpeed |= REVERSE; // set flag for reverse speed direction
speed_tmp ^= 0xff; // invert the byte if is negative to positive using XOR
speed_tmp++; }
else {
packetSpeed |= FORWARD; } // set flag for forward speed direction
packetSpeed |= (speedTable[speed_tmp + 4] & 0b11111l);
// first 4 speed steps are (E)stop commands, the last 5 bytes contain the speed information
/****** FUNCTIONS F1 - F4 *******/
packetFunctions1 = 0; // clear byte for re-usage
packetFunctions1 |= FUNCTIONS1; // mark this as instructions byte
if(train[addres].headLight) packetFunctions1 |= (1<<4); // turns on headlight
packetFunctions1 |= (train[addres].functions & 0x0F); // F1 - F4
/****** FUNCTIONS F5 - F8 *******/
packetFunctions2 = 0; // clear byte for re-usage
packetFunctions2 |= FUNCTIONS2; // mark this as instructions byte
packetFunctions1 |= ((train[addres].functions & 0xF0) >> 4); // F5 - F8
/***** CHECKSUM *******/
packetChecksum = packetAddres ^ packetFunctions2;
//packetAddres ^ packetSpeed also tried.. must I send 3 checksum bytes?
/***** SHIFT PACKETS FOR TRACK SIGNAL *******/
bitArray[0] = 0xFF;
bitArray[1] = 0xFC; // pre-amble + 2 0 bits
bitArray[2] = packetAddres << 1;
bitArray[3] = packetSpeed;
bitArray[4] = packetFunctions1 >> 1;
bitArray[5] = packetFunctions1 << 7 | packetFunctions2 >> 2;
bitArray[6] = packetFunctions2 << 6 | packetChecksum >> 3;
bitArray[7] = packetChecksum << 5 | 1<<4;
}
De kern van de code ziet er als volgt uit:
ISR(TIMER1_COMPB_vect)
{
if(ISR_state == 0){ // pick a bit and set duration time accordingly
ISR_state = 1;
Bit = (*ptr & (0x80 >> bitCounter)) >> (7-bitCounter); // select the next bit out of bitArray
if(Bit == 1) OCR1A=DCC_ONE_BIT; // '1' 58us
else OCR1A=DCC_ZERO_BIT; // '0' 116us
// Serial.print(Bit);
// enabling this, showed me that the the variable 'Bit' is always what it should be
bitCounter++;
if(bitCounter==8) {
bitCounter = 0;
ptr++; // select the next byte from bitArray
if(ptr == (&bitArray[7] + 1)) { // if last byte is done
ptr = &bitArray[0];
OCR1A = 0xFFFF;
// temporarily susppend ISR by setting compare register at 0xfff untill the main routine has assembled a new package
packetSent = 1;} } }
else {
ISR_state = 0;
PORTB ^= 0X3; } // toggle pin 8 and 9 for direction
}
Dit is het ISR. Het is de bedoeling dat 'Bit' of een 0 of een 1 is en adhv dit, wordt de ISR tijd op 58 of 116us gezet. De 2e keer dat het ISR wordt doorlopen, worden de 2 richtings I/O (voor de H-brug) getoggled. Als ik de Serial.print instructie uit commentaar haal (wat eigenlijk niet gewenst is in een ISR), zie ik dus wel alle bits in de (hopelijk) juiste volgorde op het scherm worden geprint.
Ik heb met mijn primitieve scope wel kunnen bevestigen dat de ISR tijden (compare match register) kloppen. Nadat ik ze had berekend, zag ik dezelfde waardes in een ander stukje arduino code van iemand anders.
void nextPacket()
{
packetSent = 0;
ptr = &bitArray[0]; // set the pointer back to the first bit
bitCounter = 0;
addres++; // if it is sent, increment addres
if(addres > 10) addres = 1; // address range is 1-80
assemblePackets(); // assemble a new package
Serial.println();
Serial.println(addres);
OCR1A=927;
}
void loop()
{
readSerialBus();
shortCircuit();
EstopPressed();
if(packetSent) nextPacket();
}
Dit is de rest van het programma. Ik gebruik een pointer ptr, die wijst naar 1 van de bytes uit bitArray. De bitCounter wordt gebruikt om de indivuele bits te benaderen.
Kan iemand mij vertellen wat het precies is dat ik verkeerd doe? ::)
Met voorbaat dank,
Bas.
-
Je kunt ook een andere manier gebruiken om te checken.
Pak een tweede arduino, laad daar de standaard DCC-monitor-sketch op zet en sluit hem aan op de rails (via de opto zoals bij de documentatie is uitgelegd. Is hetzelfde schematje als Mardec gebruikt)
Dan zie je of standaard NMRA software jouw berichtenstroom kan decoderen.
Is geen 100% garantie voor alle consumers - maar zegt in iedergeval iets.
Remco.
-
Hoi Bas,
Leuk bezig! (y) Maar nog een bijzondere reden dat je niet een van de standaard libraries wilt gebruiken?
Dus mijn eerste vraag: stel ik de data pakketten goed samen?
Dat is ff puzzelen. Je quote de layout van een baseline pakket maar je wilt zo te zien een extended pakket sturen.
Dus nee, volgens mij is dat niet juist. Volgens mij moet je snelheid en functie als twee losse pakketjes sturen
Snelheid
{preamble} 0 AAAAAAAA 0 CCCDDDDD 0 EEEEEEEE 1
11111111111111 0 00001001 0 01110101 0 01111100 1
Preamble | | | | | |
start | | | |
addres 9 | | | |
011 = Speed and Direction Instruction for forward operation
Speed 8 | |
Error = XOR
StopFuncties
{preamble} 0 AAAAAAAA 0 CCCDDDDD 0 EEEEEEEE 1
11111111111111 0 00001001 0 10011001 0 10010000 1
Preamble | | | || | |
start | || | |
addres 9 | || | |
Function Group One Instruction
F0 = on | |
F4 = on, F3 = off, F2 = off, F1 = on
Error = XOR
Stop
Moet ik nu voor de checksum 1 byte sturen of 3 bytes?
Altijd 1 byte met de XOR van alle voorgaande bytes.
Niet heel hard naar de code gekeken maar toch paar vragen:
Voor de ISR, ik zie dat je een aantal variabelen gebruikt. Zijn deze als volatile gedeclareerd? En benader je ze ook nog extern? Volgens mij zijn ze allen alleen in de ISR nodig dus zou het handiger / veiliger zijn ze als local static te definiëren.
Bit: Waarom niet bit?
ISR_state: Probeer zelf altijd één stijl aan te houden, dus waarom niet IsrState?
DCC_ONE_BIT / DCC_ZERO_BIT: ziet er uit als een macro, weet dat C++ ook const kent ;)
(&bitArray[7] + 1)) mag ook zijn &bitArray[8] maar zou het denk ik zelf als constante buiten de IRS om definiëren om flexibel te blijven.
ptr: gebruik je deze ook nog buiten de ISR? Zo ja, dan moet je de ISR uitschakelen tijdens het lezen. Als anders de ISR vuurt als je aan het lezen bent ben je namelijk in de aap gelogeerd daar een pointer niet atomic is ;)
En ow
packetSent = 1;} } }Het maakt niet uit welke stijl van C je schrijft, dat is een doodzonde ;D :police: Sluithaken altijd op een nieuwe regel in lijn met het begin van de regel waar de openingshaak staat. Maakt het ook zooooo veel leesbaarder ;)
Timo
-
Ow, en gooi deze (https://www.aliexpress.com/item/USB-Logic-Analyzer-24M-8CH-Microcontroller-ARM-FPGA-Debug-Tool-24MHz-16MHz-12MHz-8MHz-4MHz-2MHz/32981849062.html) maar in je winkelwagen ;) Mooie aanvulling op je scope voor dit werk. Let wel, 5V max maar dat is zo opgelost met een opto (y)
Timo
-
Bit: Waarom niet bit?
Naja, da's een makkelijke. Ik maak dit in de arduino ide en dat komt zo heel af en toe met een haak en een oog. 'bit' wordt namelijk gehighlight in de ide. 'speed' die ik ook gebruik, wordt ook gehighlight alleen die kan je wel gebruiken. Arduino's ide kennende, zal bit wel bedoeld zijn om een soort bit variabele te maken of weet ik veel waar het 'bit' keyword voor gebruikt wordt
ISR_state: Probeer zelf altijd één stijl aan te houden, dus waarom niet IsrState?
Je hebt gelijk meestal begin ik met een kleine letter en elk nieuw woord met een hoofdletter, ik weet eigenlijk niet waarom ik hier een uitzondering gemaakt heb. Woorden als ISR tik ik wel altijd in hoofdletters, kwenie waarom ik dat doe. Ik denk dat ik dat voor afkortingen doe. Dus hiervan maak ik dan ISRstate van. Ik gebruik _ meestal voor _bool en _prev.
DCC_ONE_BIT / DCC_ZERO_BIT: ziet er uit als een macro, weet dat C++ ook const kent ;)
(&bitArray[7] + 1)) mag ook zijn &bitArray[8] maar zou het denk ik zelf als constante buiten de IRS om definiëren om flexibel te blijven.
Ja ik dacht er aan dat het hier wel kon, maar ik ben schurftig om buiten de vastgelegde array grenzen te treden ;D. Die dingen op mijn werk crashen altijd als ik dat probeer. Net als dat ik nooit bit en boolean variabele gebruik. Mijn 8051 core kan ook met bits werken (hij gebruikt dan ook echt 1 bit in het geheugen ). Maar ik deed er ooit iets mee wat niet kon en niet werkte icm een if statement. Dat was de laatste keer dat ik een bit gebruikte. Ik werk alleen met hele bytes
ptr: gebruik je deze ook nog buiten de ISR? Zo ja, dan moet je de ISR uitschakelen tijdens het lezen. Als anders de ISR vuurt als je aan het lezen bent ben je namelijk in de aap gelogeerd daar een pointer niet atomic is ;)
Ja, maar voordat ik dat doe set ik de compare match register op 0xFFFF ik weet niet hoe lang dat precies is. Ik meen iets rond de 65535 /16000000 = 4ms. Dan stel ik een nieuwe pakket samen en zet ik het ISR weer op 58us. Ik weet niet 100% hoe deze timers werken, maar als die 58us al voorbij zijn, zal die wss wel meteen het ISR uitvoeren, maar dit is gis werk. Maar ik denk wel dat ik dat ombouw naar echt de ISR uitzetten, dat is zeker veel beter en veiliger.
En ow
packetSent = 1;} } }Het maakt niet uit welke stijl van C je schrijft, dat is een doodzonde ;D :police: Sluithaken altijd op een nieuwe regel in lijn met het begin van de regel waar de openingshaak staat. Maakt het ook zooooo veel leesbaarder ;)
Dit is echt mijn beste uitvinding ooit. Ik had ooit ff in Python gespeeld en daar waren geen accolades. Die bestonden net zo min als end of line markers ;
Zodoende heb ik mijn eigen accolade gebruik ontworpen. Want ja we hebben tabs en we hebben wit regels, waarom zou je per sluitings accolade een aparte regel nemen als je aan de tabs ook al kan zien wat waar bij hoort. Als ik 3 accolades heb staan, dan weet ik precies dat de volgende regel 3 tabs naar voren begint. Ik heb daar geen 3 aparte wit regels voor nodig.
Weet dat, omdat je het nog nooit gezien heb of dat omdat het door de grote menigte niet is aangenomen of omdat het je raar lijkt, het niet noodzakelijk iets slechts is. Ik ben er al een lange tijd achter dat de beslissingen die de grote groepen nemen of beslissingen die lange tijden zijn genomen niet ook meteen de beste of goede beslissingen waren.
Als je deze stijl eenmaal gewend ben, wil je nooit meer anders :P.
iig erg bedankt voor je antwoord. Ik dacht dat ik zoveel instructie bytes kon sturen als ik wilde. Dat leek me ook logisch omdat de decoder kan synchorniseren na elke byte en je niet telkens de pre-amble hoeft te versturen.
Ik zal mijn code aanpassen. En misschien dat ik de andere kant van de H-brug ga gebruiken omdat deze kant misschien niet helemaal meer werkt ::)
-
also
Ik heb in de libraries gekeken, maar er staat erg erg erg veel in en het is niet allemaal even duidelijk wat alles doet. Ik wil graag weten wat ik precies aan het doen ben. En dan maak ik liever de keuze om zelf dingen uit te puzzelen en code te schrijven.
Ik kan wss wat ik wil met 1/20 van de code van die libraries
-
iig erg bedankt voor je antwoord. Ik dacht dat ik zoveel instructie bytes kon sturen als ik wilde. Dat leek me ook logisch omdat de decoder kan synchorniseren na elke byte en je niet telkens de pre-amble hoeft te versturen.
Nee, volgens mij dus niet. Versterkt door:
a packet using the extended packet format definition may have a length of between 3 and 6 data bytes each separated by a "0" bit.
Bekeken vanuit een decoder is dat ook wel logisch.
- Preamble => alle decoders gaan weer opletten
- Adres => decoder met dat adres blijft opletten, rest haakt af
- CCC => Okay, prima, dat gaan we doen dus ik verwacht x bytes of dat commando ken (/ondersteun) ik niet, ik haak af
- DDDDD => weten gelijk waar dat moet
En daarnaast kan een pakket dus max 6 bytes zijn, je weet dus altijd hoeveel ruimte je moet hebben voor voor het ontvangen (maar ook voor het verzenden) van een pakket. En dat is ook handig voor de XOR.
Tuurlijk, er zijn wel omwegen maar die houdt het lekker makkelijk. Vooral als decoders bepaalde CCC's niet ondersteunen, dan zouden ze opvolgende data (met wel ondersteunde CCC) niet meer zien.
Eerste over libraries, zelf uitpuzzelen heeft zeker ook voordelen, dat ben ik met je eens. (y) Maar je zou ook die verder kunnen uitpluizen. Toegegeven, zelf iets maken is leuker werk ;D
Maar dat er veel code in staat die je niet wilt gebruiken is niet zo erg. Als jij vervolgens die code ook niet aanroept zal die ook niet in de uC terecht komen ;)
Wat betreft namen, iedereen heeft zijn eigen voorkeuren en dat is prima. Denk alleen dat het belangrijkste is dat je consistent bent anders kan je echt niet onthouden hoe je ook al weer iets genoemd had. Ik ga daarmee door op hoe Arduino dat doet: camelCaseVoorVariabelen UpperCamelCaseVoorConstants (en classes), ALL_CAP_UNDERSCORE voor macro's (die ik zo veel mogelijk niet gebruik maar C++ alternatieven). Dingen met afkortingen zoals ISR zijn dan wel een twijfelgeval inderdaad. Maar ik ga dan voor IRSStatus (elke hoofdletter een los deel aan in uitspraak Ie eR eS Status). Maar nogmaals, consistent zijn is belangrijker!
Naja, da's een makkelijke. Ik maak dit in de arduino ide en dat komt zo heel af en toe met een haak en een oog. 'bit' wordt namelijk gehighlight in de ide. 'speed' die ik ook gebruik, wordt ook gehighlight alleen die kan je wel gebruiken. Arduino's ide kennende, zal bit wel bedoeld zijn om een soort bit variabele te maken of weet ik veel waar het 'bit' keyword voor gebruikt wordt
Mja, de highlight functie uit de IDE is %^$&^*$%^$%^&*$$%^. Er wordt niet gekeken naar welke libraries je gebruikt maar alle keyword.txt's worden op één hoop gegooid. De reden dat FadeLed dus geen keywords.txt heeft.
Maar goed, bit is misschien gebruikt ja. Maar zeer lokaal is een korte naam ook niet zo erg
const bool b= (*ptr & (0x80 >> bitCounter)); // select the next bit out of bitArray
//laatste shift is niet nodigof je doet het gewoon in de if(). Toegegeven, voor debug kan het even handig zijn hem wel te hebben (maar een serial print is niet zo slim daar het een grote kans is dat die faalt).
Of een methode met minder schuiven:
ISR(TIMER1_COMPB_vect){
static byte bitMask = 0x80;
if(ISR_state == 0){ // pick a bit and set duration time accordingly
ISR_state = 1;
if(*ptr & bitMask){
OCR1A = DCC_ONE_BIT; // '1' 58us
}
else{
OCR1A = DCC_ZERO_BIT; // '0' 116us
}
// Serial.print(Bit); // enabling this, showed me that the the variable 'Bit' is always what it should be
//BUT a serial print from a ISR is a bad idea and fails A LOT
bitMask >>= 1;
if(!bitMask) {
bitMask = 0x80;;
Ja ik dacht er aan dat het hier wel kon, [...]
Nouwja, ging meer om de onflexibele definitie van het einde van je array. Ik zou gewoon een eind pointer definiëren.
En daarnaast is de baan bitArray best wel verwarrend daar het een array van bytes is ;D En dat daar bitjes in zitten is nogal wiedes 8) Zou dus ook eerder spreken van packetArray ofzo.
byte packetArray[7];
byte * const PacketEndPtr = &packetArray[sizeof(packetArray)];
//of waarom eigenlijk nog losse pointers aanmaken, een array is al een pointer constructie
const byte PacketArraySize = 7;
byte packetArray[PacketArraySize];
//en gewoon een iterator in de ISR
[...]Maar ik denk wel dat ik dat ombouw naar echt de ISR uitzetten, dat is zeker veel beter en veiliger.
Dit is echt mijn beste uitvinding ooit. Ik had ooit ff in Python gespeeld en daar waren geen accolades. Die bestonden net zo min als end of line markers ;
Haha, ja. Bugs door non-atonic operaties op ISR variabelen is meestal een nachtmerrie om te debuggen.
Zodoende heb ik mijn eigen accolade gebruik ontworpen. Want ja we hebben tabs en we hebben wit regels, waarom zou je per sluitings accolade een aparte regel nemen als je aan de tabs ook al kan zien wat waar bij hoort. Als ik 3 accolades heb staan, dan weet ik precies dat de volgende regel 3 tabs naar voren begint. Ik heb daar geen 3 aparte wit regels voor nodig.
Weet dat, omdat je het nog nooit gezien heb of dat omdat het door de grote menigte niet is aangenomen of omdat het je raar lijkt, het niet noodzakelijk iets slechts is. Ik ben er al een lange tijd achter dat de beslissingen die de grote groepen nemen of beslissingen die lange tijden zijn genomen niet ook meteen de beste of goede beslissingen waren.
Haha, klopt. Maar als voorbeeld daarvan zie ik nu juist het niet gebruiken van haken in Python ;D :angel: Toegegeven, het forceren van indentatie helpt wel voor de leesbaarheid. En inderdaad, voor de compiler maken nieuwe regels überhaupt geen fluit uit, ook al zet je alles op één regel. Maar weet dat je, ondanks de grote hoeveelheid strijd binnen C++ omtrent stijl, zeeeeeeee weinig bijval krijgt ;D Zeker omdat je er met de definitie van functies zelf opeens weer van af wijkt ;)
Ik zal mijn code aanpassen. En misschien dat ik de andere kant van de H-brug ga gebruiken omdat deze kant misschien niet helemaal meer werkt ::)
Busje magic smoke (https://upload.wikimedia.org/wikipedia/commons/thumb/e/e4/Magic_smoke_refill_%285990429717%29_%282%29.jpg/640px-Magic_smoke_refill_%285990429717%29_%282%29.jpg) nodig? ;D
Timo
-
Ik ga gebruik maken van je bit mask idee, minder rekenwerk & minder lijntjes code -> meer performance & leesbaarheid
Mijn eerste 2 treintjes die rijden!! (y)
Het minder goede nieuws is dat de snelheden niet zijn wat ik verwachtte. Ik vermoed dat dit ligt in het 5e snelheids bitje maar daar ben ik nog niet uit. Er klopt iig helemaal niks aan de snelheden.
Morgen maar weer verder spelen. Ben iig blij dat de basis werkt
-
Top!
Dat snelheid blobje is inderdaad een chaos :-\
Maar iets als
byte speedBlob = speedStep + 3;
speedblob = (speedBlob >> 1) | ((speedBlob & 0x01) << 4);
Timo
-
Half-moderator-opmerkinkje: ik heb in de eerste post wat commentaar (in de code) op een nieuwe regel gezet in de hoop de breedte binnen de perken te houden omdat het op m'n scherm over ging lopen. Nog niet helemaal gelukt.
a) Volgens mij heb ik het C-technisch goed gedaan en geen syntax errors veroorzaakt :)
b) Ik weet niet wat voor breedbekkikker je als monitor hebt, maar kijk voor het posten van code hier op het forum even naar de lijnlengte. Met m'n pythonachtergrond krijg ik toch al de vlekkenkoorts van alles wat over de 80 karakters heen gaat, maar goed :D
Reinout-beetje-als-moderator
-
Top!
Dat snelheid blobje is inderdaad een chaos :-\
Maar iets als
byte speedBlob = speedStep + 3;
speedblob = (speedBlob >> 1) | ((speedBlob & 0x01) << 4);
Timo
Ik had een lookup table gemaakt adhv nmra website
byte speedTable[] = {
0b00000/*Stop */ ,0b00100/* 5 */ ,0b01000/* 13 */ ,0b01100/* 21 */
,0b10000/*Stop1*/ ,0b10100/* 6 */ ,0b11000/* 14 */ ,0b11100/* 22 */
,0b00001/*Estop*/ ,0b00101/* 7 */ ,0b01001/* 15 */ ,0b01101/* 23 */
,0b10001/*Estop*/ ,0b10101/* 8 */ ,0b11001/* 16 */ ,0b11101/* 24 */
,0b00010/* 1 */ ,0b00110/* 9 */ ,0b01010/* 17 */ ,0b01110/* 25 */
,0b10010/* 2 */ ,0b10110/* 10 */ ,0b11010/* 18 */ ,0b11110/* 26 */
,0b00011/* 3 */ ,0b00111/* 11 */ ,0b01011/* 19 */ ,0b01111/* 27 */
,0b10011/* 4 */ ,0b10111/* 12 */ ,0b11011/* 20 */ ,0b11111/* 28 */};
Als index gebruikte ik de snelheid die ik decimaal heb opgeslagen als een signed char van -28 t/m +28.
#define FORWARD 0b01100000
#define REVERSE 0b01000000
speed_tmp = train[addres].speed; // store speed in 'speed_tmp' to calculate with
packetSpeed = 0; // clear byte for re-usage
if(speed_tmp < 0) {
packetSpeed |= REVERSE; // set flag for reverse speed direction
speed_tmp ^= 0xff; // invert the byte if is negative to positive using XOR
speed_tmp++; }
else {
packetSpeed |= FORWARD; } // set flag for forward speed direction
packetSpeed |= (speedTable[speed_tmp + 3]);
Ik kijk eerst of de trein achteruit of vooruit moet. Dan OR ik betreffende instructies FORWARD of REVERSE aan packetSpeed. Als de snelheid negatief is dan xor ik hem met 0xff en tel ik er 1 bij op. Dit resulteert dat een negatieve snelheid positief wordt. En dan haal ik ahdv van de ingestelde snelheid een waarde op uit de tabel.
Maar ik ga het eerst met 14 snelheidsstapjes proberen
-
@Reinout-beetje-als-moderator, misschien kan het verzoek gedaan worden de CSS van de website daarvoor correct te maken (https://forum.beneluxspoor.net/index.php?topic=74858.msg3221761273)? Tijdens het schrijven van code zullen de meeste gewoon word-wrap aan hebben staan namelijk.
@bask185, lookup kan ook maar de logica is dus niet zo heel lastig. Dus een lookup (zeker in een non-const tabel) lijkt me wat overkill. Paar punten over de huidige implementatie:
- Klopt niet voor speedStep 0 (okay, die van mij ook niet ;D)
- Ipv zelf 2-complement om te zetten zou je ook gewoon abs() kunnen gebruiken
- Of het opslaan als 1-complement
- Ipv eerst 'packetSpeed' te clearen en dan te OR'en met FORWARD of REVERSE zou je ook gewoon een asign daarvan kunnen maken. Twee vliegen in één klap.
- En ik gebruik liever C++ functionaliteit dan macro's :angel:
Ow, LOLLL ;D Toen wilde ik send drukken maar zie ik je fout ;D ;D ;D Je hebt de speed tabel letterlijk overgenomen uit het DCC document. Maar C/C++ leest natuurlijk niet boven naar beneden, links naar rechts 8) Die leest van links naar rechts, van boven naar beneden ;D Dus als je speedstep 10 hebt kom je uit bij '0b10101/* 8 */' Geen wonder dat je loc bokkensprongen staat te maken!
Timo
-
Ow, LOLLL ;D Toen wilde ik send drukken maar zie ik je fout ;D ;D ;D Je hebt de speed tabel letterlijk overgenomen uit het DCC document. Maar C/C++ leest natuurlijk niet boven naar beneden, links naar rechts 8) Die leest van links naar rechts, van boven naar beneden ;D Dus als je speedstep 10 hebt kom je uit bij '0b10101/* 8 */' Geen wonder dat je loc bokkensprongen staat te maken!
omg ik ben zooooo'n noob ;D ;D ;D
-
Haha, gebeurt de beste ;D ;D
Timo
-
Ik weet niet of het is wat jullie met "de standaard libraries" bedoelen, maar waarom gebruik je niet DCC++ https://dccwiki.com/DCC_Plus_Plus (https://dccwiki.com/DCC_Plus_Plus)?
Dat blaas je zo op een Arduino met Motor Shield (overigens wilde het bij mij een enkele decoder niet helemaal lezen/schrijven, waar het de Digikeijs DR5000 wel lukte).
-
Ja, dat is dus een "standaard" (lees: bestaande) library ;D
Weet jij overigens of er ook een schema van de DCC++ opstelling beschikbaar is ivm dat verschrikkelijke schild gedoe?
Timo
-
@Illya Omdat mijn hele treinbaan besturing (wissels en terugmelders) op basis van Arduino's is ontworpen te samen met mijn eigen computer programma en mijn eigen protocol heb ik helemaal geen behoefte DCC++ te gebruiken wat ik vervolgens nog zou moeten aanpassen om met mijn netwerk te communiceren.
Ik heb geen niet-trein dcc decoders. Ik heb geen s88 of digikeys DR5000 of weet ik veel wat voor overpriced dingen mensen tegenwoordig kopen. Dus geen loconet of xpressnet of.... nodig.
Mijn gedachtegang was: Als je toch al op verscheidene plekken elektronica heb hangen met een communicatiebus voor de terugmelding dan waarom in godsnaam zou je nog vrijwillig aparte wisseldecoders gebruiken voor wissels?
Mijn dcc centrale hoeft alleen maar dcc signalen te genereren voor treinen. Het ding luistert verder naar instructies om een nieuwe snelheid/functie op te halen.
@Timo ik heb de snelheidsstappen aangepast en werkt nu wel logisch ;D. Ik heb ff een processing sketch opgezet zodat ik ook negatieve snelheden kan sturen dmv pijltjes toetsen. Alleen hadden m'n treinen nog geen zin om achteruit te rijden ??? Dus daar hebben ze nog wat liefde voor nodig.
-
Ja, dat is dus een "standaard" (lees: bestaande) library ;D
Weet jij overigens of er ook een schema van de DCC++ opstelling beschikbaar is ivm dat verschrikkelijke schild gedoe?
Timo
Op deze (http://trainelectronics.com/DCC_Arduino/DCC++/) pagina van Dave Bodnar staat een schema van het motorshield. Daar kun je evt. zelf een arduino chip bijtekenen.
-
Kwam nog een leuk "bugje" tegen.
Ik ben nu met twee treinen aan het testen een 2200 (2225) en een 2400 (2426). De merken? dat weet ik niet meer.
Nu doet de 2225 met zijn lampen knipperen elke keer dat ik de snelheidstapjes ophoog en hij reageert niet op de helft van de snelheidsstapjes.
Maar 2426 heeft dat dus net niet. Deze reageert wel op alle 28 snelheidsstapjes en knippert niet met zijn lampje.
Toen ging bij mij dus ook het lampje branden :angel: Ik had ergens gelezen in de baseline dcc packets dat het 5e bitje niet voor snelheid maar voor de koplamp kan worden gebruikt. Ik pakte simpelweg 28 snelheidsstapjes omdat dat dat kon.... dat kon dus niet.
Toen ging er nog een lampje bij me branden :angel:. Ik kon me herinneren dat ik bij de CS2 een keuze optie had voor "snelheidsstapjes". Dus ik pakte m'n gestoffeerde CS2 die nog ergens rondzwierf en ging op zoek. Het eerste treintje was een MM2 trein van M* uit te database en deze had die optie dus niet. Toen moest ik ff achter mijn oren krabben en nadenken welke van mijn treinen een DCC'er was. Dus die trein geselecteerd en opties geopend en potverdriedubbeltjes 'k kon kiezen tussen 14, 28 en 126 stapjes.
Maar goed het is duidelijk "it isn't a bug, it's a feature". Ik kan kiezen tussen 14 stapjes of ik moet via een de handregelaar of computer tegen de arduino vertellen wat voor soort decoder de trein heeft en dat opslaan in EEPROM. Vanwege mijn prestatie druk en afwezigheid van voldoende voortgang naar mijn mening, kies ik voor de 14 snelheidsstapjes. Dat doet mijn MS1 ook (hoewel MS1 met MM2 werkt) en ik ben er opzich content mee.
Ik heb dit punt wel alle bugs omtrent de bewegingen opgelost. Ik kan nu beide treinen voorruit en achteruit sturen. Ik kan ze laten stoppen en noodstoppen.
Er is echter 1 ding die ik nog niet begrijp en wat voor mij een probleem wordt:
Als ik met de koplamp knop op de MS1 het 5e "snelheidsbitje" verander tbv de koplamp, hoe komt het dan dat loc 2426 niet anders gaat rijden? want deze heeft wel 28 stapjes en luistert naar dit bitje.
Ik vermoed, maar verbeter me, dat dit een MM2 protocol eigenschap is waardoor het goed gaat. De MS1 kan namelijk helemaal niet weten hoeveel snelheidsstapjes een loc heeft en maakt de aanname van 14.
Bij mij gaat dit dus het probleem opleveren dat de snelheid van 2426 wordt veranderd wanneer ik zijn lamp probeer aan te zetten. Moet ik achteraf toch nog invoeren en opslaan wat voor decoder er in zit.... ??? :-\ :'(
Ik moet de koplamp van 2426 echter nog steeds kunnen aanzetten (en de andere functies bedienen). De koplamp gaat echter nog niet aan en ik weet nog niet waarom. Ik dacht namelijk wel het goede pakketje te versturen.
Function Group One Instruction (100)4
The format of this instruction is 100DDDDD
Up to 5 auxiliary functions (functions FL and F1-F4) can be controlled by the Function Group One instruction. Bits
0-3 shall define the value of functions F1-F4 with function F1 being controlled by bit 0 and function F4 being
controlled by bit 3. A value of "1" shall indicate that the function is "on" while a value of "0" shall indicate that the
function is "off". If Bit 1 of CV#29 has a value of one (1), then bit 4 controls function FL, otherwise bit 4 has no
meaning.
programma:
#define FUNCTIONS1 0B10000000
/****** FUNCTIONS F1 - F4 *******/
packetFunctions1 = FUNCTIONS1; // mark this as instructions byte
packetFunctions1 |= (train[addres].functions & 0x0F); // F1 - F4
...
...
if(train[addres].headLight) {
packetSpeed |= (1<<4); // turns on headlight for 2200
packetFunctions1 |= (1<<4); } // should turn on headlight for 2400
switch(packet){ // send 1 of 3 types of packets
case speedPacket: bitArray[3] = packetSpeed; break;
case functionPacket1: bitArray[3] = packetFunctions1; break;
case functionPacket2: bitArray[3] = packetFunctions2; break; }
Ik stuur per adres 3 pakketten; snelheid, functies F1-F4 en functies F5-F8.
Waarom gaan de lichten van de 2400 niet aan?
-
Ja, dat is dus een "standaard" (lees: bestaande) library ;D
Weet jij overigens of er ook een schema van de DCC++ opstelling beschikbaar is ivm dat verschrikkelijke schild gedoe?
Bedoel je zoiets (PDF)?
https://github.com/DccPlusPlus/Documentation/blob/master/Motor%20Shield%20Pin%20Mappings.pdf (https://github.com/DccPlusPlus/Documentation/blob/master/Motor%20Shield%20Pin%20Mappings.pdf)
Alle documentatie die ik ken, vind je onder https://github.com/DccPlusPlus/BaseStation/wiki (https://github.com/DccPlusPlus/BaseStation/wiki) (de link onderaan de eerder genoemde URL).
-
@Haas67 en @Illya Vaes
Hartelijk dank! Jammer dat er niet een echt schema is maar goed, met de genoemde links moet ik denk ik wel aardig eind komen..
@bask185
Oef, 14 stappen, dat is wel weinig. Zit daar echt zo'n oude decoder in? >12 jaar geleden was 28 en 128* al normaal... 8) En moet zeggen, 28 rijdt prima maar 14 is wel erg beperkt. Dus ik zou toch even kijken of je de decoder niet gewoon 28 stappen kan (CV29 bit 1 = 1);
En ja, daar hebben ze toen bitje 4 voor misbruikt. ;D Vandaar dat de adressering dus zo raar is. Eigenlijk is LSB gewoon naar de plek van MSB geschoven. (Maar de E-stop gooit wat meer toet in het eten.)
Termen 128 en 126 stappen wordt vaak door elkaar gebruikt. Dit omdat de aanduiding toch al raar is. Bij "28 stappen" heb je er namelijk eigenlijk ook al 30 als je stop en e-stop mee telt.
Als je de 2426 met 14 stappen DCC aan stuurt, weet je dan zeker dat hij niet sneller gaat? Het verschil is maar 1 stap (1/2 14-stap) dus makkelijk te missen. Helemaal als de decoders nog het volgende doen:
[quote S-9.2.1 DCC Extended Packet Formats]
If a decoder receives a new speed step that is within one step of current speed step, the Digital Decoder may select a 250 step half way between these two speed steps. This provides the potential to control 56 speed steps should the command station alternate speed packets.
[/quote]
En als je hem met MM2 aan stuurt dan geldt alles rond DCC natuurlijk simpelweg niet ;)
Eerste wat me zo opvalt is dat je met die if()'s en die case eigenlijk dubbel werk aan het doen bent. Eerst alle mogelijke 3e byte's ;D bepalen en er dan maar één gebruiken. Beetje zonde rekenwerk. Maar goed, kan ook aan de snippet liggen dat het zo lijkt.
Naar het probleem, hoe wat waar is FUNCTIONS1 gedefinieerd? Die zou 0x80 moeten zijn.
En als laatste, waarom is dit de vierde byte in de array? (bitArray[3]) Zou zeggen 0: AAAAAAAA, 1: CCCDDDDD, 2: EEEEEEEE.
Timo
-
Ik zou het wel mooi vinden om een DCC++ Centrale te maken met 1 pcb waar dan een arduino, een motorshield en een withrottle op zit.
En dan in een zelfde kastje als de nieuwe DccNext van Nico Teering (y)
Tot nu toe heb ik zelf wel een DCC++ met een shield aan de praat, maar nog geen Withrottle.
-
Ik zou het wel mooi vinden om een DCC++ Centrale te maken met 1 pcb waar dan een arduino, een motorshield en een withrottle op zit.
En dan in een zelfde kastje als de nieuwe DccNext van Nico Teering (y)
Tot nu toe heb ik zelf wel een DCC++ met een shield aan de praat, maar nog geen Withrottle.
De Arduino zoals ik hem opzet, kan je zien als een simpel doorgeefluik. Serieel stuur ik een instructie voor een trein, en de arduino converteert het naar dcc pakketjes en laat de trein rijden. Hoe ik het de arduino precies vertel is afhankelijk van hoe ik het programmeer. Dat programma JMRI heeft ook een eigen manier hoe JMRI aan de base station vertelt welke trein hoe hard moet gaan rijden. Als ik er voor kies dat protocol over te nemen, dan zou mijn arduino programma met je WiThrottle kunnen werken. Voor het mooie kan je ook andere protocollen gaan implementeren zodat Itrain en koploper en .... er ook mee kunnen werken. Maar dit hebben mensen ook al uitgevogeld. Ik weet niet meer welk draadje het was maar iemand heeft een bijna hele complete arduino base station gemaakt die met loconet en xpressnet kan werken en S88 dacht ik zelfs ook nog.
Het is gewoon een gevalletje van protocolletjes uitpluizen. Ik ga mijn arduino tijdelijk van bluetooth voorzien zodat ik mijn treinen tijdelijk met mijn smartphone kan aansturen met een hele basic bluetooth serial app totdat ik mijn handregelaar gemaakt heb.
Voor je print kan je dit (https://hackerstore.nl/Artikel/195) kopen en een gaatjes print er bij. Dan kan je zelf een 'arduino' naar believen in elkaar solderen. Dan neem je een H-brug (https://hackerstore.nl/Artikel/188) en een USB-TTL converter (https://hackerstore.nl/Artikel/258) er bij en je kan spelen.
Oef, 14 stappen, dat is wel weinig.
Nou ik zat er over na te denken en kwam tot de conclusie dat het toch wel meer dan genoeg is. Ik merk bij m'n 2426 wel wat het uitmaakt, maar met je rem/optrek vertraging ben ik content. Ik had het nog met 6 stapjes afgekund ::) Niemand zal ooit alle 126 stapjes gebruiken, het zit er alleen per toeval in. Niemand zal ooit bewust 102 kiezen en een minuut later 104. Let maar eens op met hoeveel verschillende snelheid je daadwerkelijk rijdt.
Ik ga wel even kijken of ik 2225 op 28 kan zetten, maar mijn backup plan is dat de handregelaar dit gaat onthouden en meestuurt met de instructies. In de headLight byte heb ik nog 7 bits over...
Als je de 2426 met 14 stappen DCC aan stuurt, weet je dan zeker dat hij niet sneller gaat? Het verschil is maar 1 stap (1/2 14-stap) dus makkelijk te missen.
Ja hij gaat sneller, wanneer ik de koplampen aanzet. Hij blijft gevoelig voor 28 stappen. Dus de arduino moet perse weten op hoeveel stapjes de decoder is ingesteld,
En als je hem met MM2 aan stuurt dan geldt alles rond DCC natuurlijk simpelweg niet ;)
verrekte M* af en toe. Baal nog steeds dat die 36xxx decoder niet ook meteen werkt. De koplampen gingen alleen aan of uit als ik met een snelheid van +- 4 zat te spelen... Volgens mij spreekt deze helemaal geen DCC? Ik heb nog 2 >10j oude Mfx treinen van M*.... ga ik niet eens aan beginnen :'( dat werkt toch niet.
Eerste wat me zo opvalt is dat je met die if()'s en die case eigenlijk dubbel werk aan het doen bent. Eerst alle mogelijke 3e byte's ;D bepalen en er dan maar één gebruiken. Beetje zonde rekenwerk. Maar goed, kan ook aan de snippet liggen dat het zo lijkt.
Nee je hebt helemaal gelijk. Dit is legacy in een week oude software (y) (y) (y) In mijn eerste opzet zou ik eerst alle snelheid en instructie pakketten samenstellen en achter elkaar op de baan gooien. Later kwam ik er pas achter dat dat niet ging. En ook bij het samenstellen van de dcc signalen voor de baan vulde ik dat hele array in 1 keer in. Ik had er ook nog niet eens aan gedacht dat dat ik nutteloze berekeningen zat te maken ::)
Naar het probleem, hoe wat waar is FUNCTIONS1 gedefinieerd? Die zou 0x80 moeten zijn.
Stond in de snippet, het is 0b10000000 aka 0x80 of 128 0f 0200 :laugh: Dus de byte samenstelling klopt wel. Ik moet even nagaan of de timing klopt. Ik had aanvankelijk wat issues dat wanneer ik het adres veranderde, het wel eens mis kon gaan met de pakketten die nog verzonden moesten worden
#define FUNCTIONS1 0B10000000
En als laatste, waarom is dit de vierde byte in de array? (bitArray[3]) Zou zeggen 0: AAAAAAAA, 1: CCCDDDDD, 2: EEEEEEEE.
Simpel ik moet ook nog die preamble sturen en 0'en tussen de bytes in en de '1' op het einde. Voor de drie bytes zou ik zowieso een constructie nodig hebben om ze bit voor bit uit te klokken. En deze constructie is ook prima in staat om alles buiten die 3 bytes ook meteen mee te pakken. Als ik de preamble en de '0' 'anders' zou aanpakken ik geheid meer code zou krijgen.
Ik ben wel voor een naam wijziging van bitArray naar iets als 'transmittBuffer' oid.
Ik wil ook de nodeloze berekeningen aanpakken en er 100% zeker van zijn, dat het verwerken van een seriele instructie de dcc packetten niet verstoort. De variabele 'addres' kan volgens mij nu nog tot problemen leiden.
-
...
Ik weet niet meer welk draadje het was maar iemand heeft een bijna hele complete arduino base station gemaakt die met loconet en xpressnet kan werken en S88 dacht ik zelfs ook nog.
...
Bedoel je dit (https://forum.beneluxspoor.net/index.php?topic=84035.0) draadje?, of nog een andere...
-
@haas67 nee het was een andere maar ik weet niet eens meer of dat op dit forum was.
Ik heb helaas de andere kant der H-brug ook voorzien van magic smoke. Ik heb nieuwe besteld en tevens heb ik ook een printje besteld om stroom te meten. Deze geeft een analoog signaal af en ik lees hem elke programmacyclus in.
Ik heb ook een oplossing gevonden voor de verschillende decoder types. Ik kwam er achter dat niet elke M* decoder van de 36xxx reeks ook DCC spreekt (of ik moet een instelling wijzigen). Ik zat in de knoop omdat zowel rijregelaar als computer beiden moesten weten met welke decoder we bezig waren. Om dat op te lossen, heb ik bedacht dat deze informatie in centrale moet liggen. Zowel handregelaar als computer kan dan een wijziging sturen voor de decoder type.
Ik heb aan de 'trains' struct een extra byte toegevoegd genaamd 'decoderType' die aangeeft of het een DCC14, DCC28, MM2 of er geen decoder is. Deze 80 decoderType's heb ik opgeslagen in het EEPROM geheugen van de arduino en ik lees ze in bij het opstarten.
Ik maak ook nog op een andere manier gebruik van de decoderType. Als hij op EMPTY_SLOT (kon ff niks anders verzinnen) staat dan sla ik het desbetreffende adres over. Zo worden de DCC pakketten voor treinen die er niet zijn, overgeslagen en worden de pakketten voor de treinen die er wel zijn, veel vaker herhaald. Ik zal wss toch niet meer dan ~15 treinen op de baan hebben staan.
Als ik mijn nieuwe elektronica heb, kan ik weer verder met het uitvogelen van de instructie bytes, dat gaat nog steeds niet helemaal goed. Ik zette laatst een LoPi V3 met sound op de baan en de toeter ging continu af.
Ik kom er net achter dat de checksum byte nog niet goed is voor de instructies. Het adres werd nog steeds geXOR'ed met de snelheidsbyte ipv de instructie byte.
Ik hoop dat ik de nieuwe checksum vanavond kan testen.
Ik heb het seriële protocol uitgebreid om met de Bluetooth app te communiceren.
(https://i.imgur.com/AEYxoCR.png)
(overigens een oude screenshot, ik heb de namen en instructies van de knoppen veranderd zodat hij meer op de keypad lijkt.)
De app kan niets onthouden qua snelheid dat doet de centrale. De handregelaar die ik maak die krijgt een 4x4 keypad met 0-9, A-B, * en #.
Met A-D wil ik alle 8 functies aansturen, met # kan ik dan toggelen tussen F1-F4 en F5-F8.
(https://hackerstore.nl/Afbeeldingen/1225klein.jpg)
En er komt een potmeter op met een grote knop en een LCD scherm. De centrale stuurt over bluetooth stukken text op die ik op mijn telefoon en handregelaar kan zien voor feedback. Ik kan dus handmatig een adres invullen en met de <, <<, > en >> de snelheid instellen. Die verhogen en verlagen de snelheid.
Ik denk dat ik het * wil gebruiken voor de koplamp functie.
Kan niet wachten om dit allemaal onder mijn treinbaan te fietsen (y) :angel:
-
Als je niet van rook houdt en dus een kortsluitbeveiliging handig vindt, is dit misschien wat voor je:
https://forum.beneluxspoor.net/index.php?topic=58491.msg3221455095#msg3221455095
De (bouw)handleiding: https://hansqprs.home.xs4all.nl/Handleiding-1.1.09.pdf
-
@HansQ dat circuit van die booster van jou, die heeft niet eens kortsluitbeveiliging. Die chip die je gebruikt, de L6203, die is intern tegen kortsluiting beveiligd. Het enige wat je circuit doet is een led rood laten branden aan de hand van die sense pin.
Mijn L298 heeft die beveiliging niet ingebouwd en ik heb geen ingebouwde sense pin. Daarom heb ik een apart printje gekocht die de stroom kan meten van de voeding. Als dat niet werkt, ga ik kijken na een andere H-brug. Volgens iemand op het arduino forum is de L298 "ancient" en ben ik beter af met een andere driver...
-
Als er kortsluiting wordt geconstateerd wordt de L6203 uitgeschakeld, kijk maar es naar het schema... misschien als inspiratie?
-
De L298 is een "dubbele" L6203. Je kunt via de pen 1 (sense A) en pen 15 (sense B) de stroom door iedere brug meten . Een simpele weerstand met een transistor is als melder voldoende om aan te geven dat er teveel stroom door de brughelft loopt. Misschien dat een L298 al langer bestaat dan een L6203, maar ouderwets is de L298 op dit moment zeker niet. Als stappenmotor aandrijving is hij samen met het aanstuur IC goed te gebruiken (Er zijn veel betere oplossingen).
Verder is het feit dat er twee H bruggen in zitten in ons geval een nadeel, daar we er niet vaak twee tegelijk in een schakeling nodig hebben.
Groet,
Gerard van der Sel.
-
@HansQ Ja schat, ik weet dat die chip zich zelf uitzet, maar we hadden het over het circuit om de chip heen ;). Jij gaf mij links om me te helpen met het kortsluiting probleem en daarmee vond ik uiteindelijk een getekend circuit die zelf geen kortsluiting circuit had maar die een chip had die dat heeft. De links die je gaf, en met name de "bouwhandleiding", bevatte geenzins relevante informatie. Echter een link in de eerste link (https://forum.beneluxspoor.net/index.php?topic=54663) leidde me naar dit schema:
(https://images.beneluxspoor.net/bnls/BoosterSchema01.jpg) En in dit schema is duidelijk te zien dat de sense pin alleen maar wordt gebruikt voor een ledje en dat er verder geen externe beveiliging aanwezig is.
Maar nu zijn we achter elkaar rondjes om een boom aan het rennen.
@gvandersel
De L298 is een "dubbele" L6203.
Nee. De L298 is misschien een dubbele H-brug en de L6203 een enkele H-brug, maar ze zijn alles behalve hetzelfde. Ze doen alleen hetzelfde. Die L298 gaat gewoon hartstikke kapot als je de outputs kortsluit daar de L6203 intern beveiligd is.
Ik zie wel dat de 298 wel degelijk sense pinnen had, ik denk dat ik destijds in de datasheet van de 293 heb gekeken die dat niet heeft. En de current sense pinnen hangen aan het ground vlak, daarom waren ze me niet eerder opgevallen. Wel jammer, want als ik beter mijn huiswerk beter gedaan had, had ik mezelf veel geld kunnen besparen :-[
Ik heb trouwens een breakoutboardje met een L6201 gekocht voor onder de 5€ in het verre oousten. De betere motor drivers zijn best prijzig nog en deze vond ik wel betaalbaar. Misschien dat ik ook een setje in elkaar flans voor op de modelspoor club. Collega daar heeft een fancy kraan gemaakt die met DCC werkt. En ik kan hem voor ~10€ laten werken aansturen (y)
Als je trouwens met stappenmotors ga spelen dan moet je zo'n polulu driver kopen voor ~€3,-. Kleiner, goedkoper, beter
-
Ik ben je schatje niet. Als je het juiste schema leest zie je een kortsluit schakeling op basis van een thyristor die de H-brug afschakelt.
Het schema wat je dupliceert is oud, zie de handleiding. Als je geen goedbedoelde hulp wilt stel ik voor dat je geen gebruik maakt van een forum.
-
HansQ het spijt me verschrikkelijk ik had geenszins de intentie je te beledigen. De Toon in geschreven woorden komt niet altijd over zoals men die bedoelt. En ik ben je wel degelijk dankbaar voor je hulp. Ik heb nu ook het andere schema heleeeeemaal onderin je bouwhandleiding gevonden en ook de thyristor. Om, hier zo een thyristor toe te passen, zou ik niet zelf bedacht hebben.
Ik snap dat die sense pin in serie staat tussen de load en de ground en dat ze willen dat je daar een shunt weerstand zet. Had liever gehad dat ze dit al op het board hadden gezet met een versterker en potmeter er bij :laugh: Zat er aan te denken om daar iets van 0.25Ohm te zetten en de spanning over die weerstand eindeloos te versterken als hij boven een vast ingestelde referentie spanning komt.
Vind het wel een gedoe omdat ik nu 4 weestanden van 1 Ohm of een dedicated shunt weerstand, die ik allemaal niet in huis heb, moet solderen aan de topside van m'n driver board. En vervolgens ook nog moet versterken ::) Opamps heb ik ook niet in huis liggen. Ik denk dat ik deze week maar ff in de club ga solderen die hebben deze dingetjes wel in huis liggen (y)
Ik heb nu ook eindelijk controle over de koplampen van de treinen. Ik kon van mijn De2 ook functie 1 en functie 2 aansturen (dat zijn bij deze de koplampen, de vorige gebruiker reed AC analoog en ik heb nog niet onder de hood gekeken).
Ik kan alleen van mijn Vt11.5 die verrekte toeter en het primaire rijgeluid niet uitzetten ::). Het rare is, dat deze al gaat toeteren nog voordat ik zijn adres had gebruikt. Ik dacht eerst dat hij nog steeds adres 3 had. Maar ik had even in mijn CS2 gekeken en zag dat deze decoder op 128 stapjes stond. Die heb ik nu op 28 stapjes gezet en ik heb het adres gevonden. Ik kan hem wel laten rijden en zijn koplampen aansturen, maarja die functies.... willen gewoon niet werken bij deze.
Ik ben nu ook op zoek gegaan naar het MM2 protocol maar m'n initiële zoekacties hebben nog niets opgeleverd. Ik had wel ooit een site gevonden die dat protocol uitlegde, ik moet hem alleen nog vinden.
-
Ik kan alleen van mijn Vt11.5 die verrekte toeter en het primaire rijgeluid niet uitzetten ::). Het rare is, dat deze al gaat toeteren nog voordat ik zijn adres had gebruikt.
Vaak onthouden decoders de laatste staat. Sommige maar even en andere meer permanent. Dus als hij als laatste aan stond en je stuurt nu niet specifiek een (geldig) uit commando dan blijft hij gaan. Stuur je nu alle functies aan in staat 'uit'? Eventueel op een DCC centrale eens controleren en/of daar alle functies (ook de hogere) eens aan en weer uit zetten.
Ik ben nu ook op zoek gegaan naar het MM2 protocol maar m'n initiële zoekacties hebben nog niets opgeleverd.
Volgens mij moet je dat gewoon niet willen :angel: Dat asymmetrische gedoe ;D
Timo
-
Ik ben nu ook op zoek gegaan naar het MM2 protocol maar m'n initiële zoekacties hebben nog niets opgeleverd. Ik had wel ooit een site gevonden die dat protocol uitlegde, ik moet hem alleen nog vinden.
Als je met MM2 “Motorola New 28 stappen“ bedoeld dan kan ik je hier wel een beschrijving van geven.
Ondanks dat het Motorola protocol maar 14 stappen kent is er een truc om toch (bijna) 28 stappen te krijgen. Ik moet het nog even nakijken maar ik denk dat het er maar 27 zijn.
Als je de beschrijving wilt dan hoor ik het wel.
Gr. Marco
-
Vaak onthouden decoders de laatste staat. Sommige maar even en andere meer permanent. Dus als hij als laatste aan stond en je stuurt nu niet specifiek een (geldig) uit commando dan blijft hij gaan. Stuur je nu alle functies aan in staat 'uit'? Eventueel op een DCC centrale eens controleren en/of daar alle functies (ook de hogere) eens aan en weer uit zetten.
Ik kan wel de trein laten rijden en ik kan had ook succesvol zijn licht en binnenverlichting kunnen bedienen maar die toeter uit zetten, is me nog niet gelukt.
Volgens mij moet je dat gewoon niet willen :angel: Dat asymmetrische gedoe ;D
Nou rijdt driekwart van mijn treinen niet. Zelfs mijn Fleischman plan V werkt niet op DCC. Van mijn M* mFX'jes wist ik dat ze niet zouden rijden, maar die fleischman kwam wel als een verrassing. Het verbaasde me ook dat mijn M* 36xxx treinen geen zin in DCC hebben. Ik weet niet wanneer M* decoders ging maken die ook DCC spraken? Ik heb volgens mij geen originele M* loco in bezit die met DCC kan rijden.
Ik heb ook nog een drietal delta loco's die.. naja dit kan je wel raden.... it doesn't bloody work ;D
Trouwens als ik terug kijk naar de resultaten, kom ik tot de conclusie dat MM2 beter werkt dan DCC. Om te beginnen het werkt. Op mijn mobile station 1 rijdt namelijk alles. En ik hoef ook niet in te voeren of het een 14 staps of 28-staps of xx staps decoder is. De lichten gaan niet knipperen zoals dat bij DCC gebeurt met een verkeerde instelling. De boel rijdt gewoon.
Aangezien driekwart simpelweg niet rijdt, lijkt het me vruchtbaar om toch MM2 uit te pluizen en te implementeren.
Ik heb overigens ook een werkende kortsluitbeveiliging ingebouwd. Ik had op m'n L298 board de ground baan tussen sense pin en GND doorgesneden en een 0.33Ohm 4~5Watt shunt weerstand die ik op werk per toeval vond, gesoldeerd tussen de 2 sense pinnen. De andere kant hangt namelijk nog wel aan ground en dit wat makkelijk solderen. Ik heb ook in software ingebouwd dat de kortsluiting minimaal 50ms moet duren voordat de juice er af wordt gezet. Ik testte net mijn piko NMBS 2813 uit en kortsluiting werd gedetecteerd bij het optrekken van deze trein terwijl de detectie pas op 2.5A triggert.
Ik was wel een beetje schurftig om het op de "spannende" manier te testen door echt kortsluiting te maken, maar ehh.. works like a charm.
Voor nu. Op naar MM2! (y)
-
Ik kan wel de trein laten rijden en ik kan had ook succesvol zijn licht en binnenverlichting kunnen bedienen maar die toeter uit zetten, is me nog niet gelukt.
Heb je hem dus ook al eens op een andere DCC centrale gehad?
En/of geprobeerd ook de hogere Fx's als UIT te versturen?
Nou rijdt driekwart van mijn treinen niet. Zelfs mijn Fleischman plan V werkt niet op DCC. Van mijn M* mFX'jes wist ik dat ze niet zouden rijden, maar die fleischman kwam wel als een verrassing. Het verbaasde me ook dat mijn M* 36xxx treinen geen zin in DCC hebben. Ik weet niet wanneer M* decoders ging maken die ook DCC spraken? Ik heb volgens mij geen originele M* loco in bezit die met DCC kan rijden.
Oef, wist niet dat je zo veel M* hebt. :-X Nu ben ik wat dat betreft afgehaakt net na MM2 dus M* decoders met MFX en laat staan DCC weet ik 0 van af. :angel:
Maar wat voor decoder zit er in die Fleischmann dan?
Ik heb ook nog een drietal delta loco's die.. naja dit kan je wel raden.... it doesn't bloody work ;D
Hehe, mja, dat is weer een uitgeklede variant van MM (of al wel MM2?) Had je niet beter een (puur) MM2 centrale kunnen maken? ;D
Trouwens als ik terug kijk naar de resultaten, kom ik tot de conclusie dat MM2 beter werkt dan DCC. Om te beginnen het werkt. Op mijn mobile station 1 rijdt namelijk alles. En ik hoef ook niet in te voeren of het een 14 staps of 28-staps of xx staps decoder is. De lichten gaan niet knipperen zoals dat bij DCC gebeurt met een verkeerde instelling. De boel rijdt gewoon.
Dat vind ik niet helemaal een eerlijke vergelijking. ;) Binnen DCC wordt 14 stappen echt al 20+ jaar niet meer gebruikt. Steekt alleen af en toe de kop nog op als iemand de verkeerde instelling in CV29 propt op op zijn centrale selecteert omdat het er voor backward compatibility eigenlijk altijd nog op zit. Maar standaard is het nergens. En ook MM kent 14 en 27 stappen met MM en MM2. Dat je toevallig geen oer Motorola hebt is je geluk ;) Toegegeven, dat ze dat met het bitje zijn gaan doen voor de verlichting is misschien niet geheel handig. Anderzijds, zo merk je het wel in tegenstelling tot bij Motorola die het volgens mij stilletjes negeert ;D
Timo
-
Heb je hem dus ook al eens op een andere DCC centrale gehad?
En/of geprobeerd ook de hogere Fx's als UIT te versturen?
Oef, wist niet dat je zo veel M* hebt. :-X Nu ben ik wat dat betreft afgehaakt net na MM2 dus M* decoders met MFX en laat staan DCC weet ik 0 van af. :angel:
Ja ben en blijf 3-rail rijder he. Ik koop echter geen Marklin treinen meer. Veels te duur voor wat het is. Ik heb M* nog steeds niet vergeven dat ze die lelijke gele leds (wat M* "warmwit" noemde) in alle goedkopere treinen gingen stoppen. Ik kocht wel eens een traxx van ze voor 105€, maar opeens waren die 130€, hadden nog steeds de gele leds en ze hadden geen sluitverlichting. Toen kocht ik een Piko expert Traxx.... superieur in elke opzicht. Mooie front en sluit verlichting, fluister stil en perfect rijgedrag. Die van M* schokken een beetje op lage snelheid en piko is ook nog... goedkoper.
Heb ook helse verhalen gelezen over mFx'jes die zich niet meer aanmelden omdat het geen feilloos systeem is. Dus geen M* OEM treinen meer voor mij. (y)
Maar wat voor decoder zit er in die Fleischmann dan?
Ik zou het niet weten, heb hem nog niet open gemaakt.
Hehe, mja, dat is weer een uitgeklede variant van MM (of al wel MM2?)
Ze rijden goed (wat je goed kan noemen :D) op de MS1 dus ik vermoed dat ze MM2 wel begrijpen.
Had je niet beter een (puur) MM2 centrale kunnen maken? ;D
Ja.
Zit in een docu (http://spazioinwind.libero.it/scorzoni/motorola.htm) te lezen over MM2 maar kanonnen wat een erg protcol. Het is zo langzaam en alles moet 2x verzonden worden ipv een cheksum te sturen.
A complete information for one loco lasts:
(28.1 * 8) ms = 224.8 ms (long pauses, DIP #3 OFF)
(20.1 * 8) ms = 160.8 ms (short pauses, DIP #3 ON)
Hier is DCC wel een stukje sneller. met ~2.5ms. Ik snap ook niet waarom ze nu weer perse met "trits" moeten werken. Er wordt geenzins gebruik gemaakt van een tri-state systeem het zijn gewoon bit paren. Ze hadden dan net zo goed een 4-tallig systeem kunnen invoeren. Hoe dan ook je bereikt er helemaal geen drol mee tov een normaal en simpel binair systeem.
-
Had je niet beter een (puur) MM2 centrale kunnen maken?
Een zelfbouw centrale kan best zowel DCC als MM ondersteunen, dat is geen enkel probleem.
Als je MM-oud (tbv de delta decoders) en MM-New tbv 14 stappen kan aansturen is de stap naar MM2 tbv 27 stappen een “fluitje van een cent”. Het zijn gewoon MM-New commando’s.
MFX decoders worden op zelfgebouwde centrales (uitsluitend) aangestuurd met MM-New commando’s. Bij MFX met meer dan 4 functies wordt het wel wat ingewikkelder, maar zeker niet onmogelijk.
Dat het MM protocol twee keer verstuurd wordt heeft nog te maken met de oude Motorola MC27*** chips specs die dat vereiste. De MM commando’s zijn in vergelijking met DCC veel korter (minder bits) dus qua timing kan de keuze voor (ook) MM nooit een probleem. Je moet er altijd wel voor zorgen dat als er iets tbv een decoder veranderd dit loc-commando wel als eerste op de baan wordt gezet. Verder de loc- commando’s cyclies op de baan zetten.
Met vriendelijke groet,
Marco
-
Zit in een docu (http://spazioinwind.libero.it/scorzoni/motorola.htm) te lezen over MM2 maar kanonnen wat een erg protcol.
Welcome to that rabbit hole ;D
@MRdirect, doelde ook niet op de onmogelijkheid maar op het feit dat bask185 nu veel moeite in DCC gestoken heeft en daarmee maar een kwart van zijn treinen kan aansturen waar dat bij MM misschien 90% (100%?) was geweest.
Timo
-
Doe maar 100 procent. Märklin plaatst pas een jaar of twee decoders die ook DCC verstaan in modellen en stopt iets langer DCC in centrales. Het is ook niet zo vreemd dat die Fleischmann plan V alleen Motorla verstaat. Het is al even geleden dat Fleischmann nog een drierail plan V leverde. Je mag al blij zijn dat er geen omschakelrelais in zit of zo’n decoder met een programmeerknopje erop. ;D
-
Welcome to that rabbit hole ;D
Het Motorola protocol is oorspronkelijk niet voor modeltreinbesturing ontwikkeld.
Marklin heeft het geadopteerd tbv het digitaliseren van hun modeltreinen. Jammer genoeg heeft Marklin daar veel te lang aan vast gehouden en dan ook nog zo eigenwijs om MFX te gaan doen. Eigenwijs of een zekere arrogantie terwijl DCC ook in Europa al door bijna alle andere fabrikanten was geïntroduceerd.
@MRdirect, doelde ook niet op de onmogelijkheid maar op het feit dat bask185 nu veel moeite in DCC gestoken heeft en daarmee maar een kwart van zijn treinen kan aansturen waar dat bij MM misschien 90% (100%?) was geweest.
Uit ervaring met MRdirect weet ik dat de meeste tijd gaat zitten ineen goede algemene opzet en niet zozeer in het op de baan zetten van het juiste signaal. Als dat voor voor DCC goed werkt dan is dat voor MM meer van hetzelfde. De conversie van loc-adres naar bits zal het lastigste zijn. En niet te vergeten als er vier functies worden ondersteund dan het (dubbele) commando 5 keer op de baan zetten voor respectievelijk F0+richting+snelheid, F1, F2, F3 en F4. Het lijkt en is wellicht wat omslachtig, dat komt ervan als je (Marklin) aan een protocol vasthoud wat niet voor jouw toepassing is ontwikkeld.
M.vr.gr.
Marco
-
Ik vind het DCC protocol ook niet erg praktisch. Het werkt wel, maar had IMO beter/praktischer gekund.
Je hebt natuurlijk dat grapje met dat snelheids/licht bitje. Maar hoe ze de instructies hebben ingericht. Met de eerste 3 bits zeg je welke instructie je doet, en met de laatste 5 bits geef je dan de details voor de instructie, F1-F8, snelheid, etc.
Ik zelf zou zeggen om gewoon 1 of 2 byte(s) voor een adres te gebruiken, 1 byte voor een instructie keuze, en 1 byte met de details voor de instructie. Nu zijn er ~8 verschillende instructies mogelijk en heb je maar 5 bits voor echte informatie te gebruiken. Door een bytje toe te voegen zou je 256 verschillende instructies met 256 verschillende data mogelijkheden.
Tevens was het ook goed mogelijk geweest om meer dan 1 instructie in een datapakket te verwerken. Tussen 2 bytes zit altijd een 0 bit en na de laatste byte komt een 1. Dan kan je met minder bits (je hoeft niet telkens en pre-amble te sturen) meer vertellen.
Heren, ik heb overigens nog een ander vraagje. Hoewel ik het actuele adres zet naar het geselecteerde adres voor een snelle responsie, is de responsie tijd niet altijd onmiddellijk. Ik stuur in sequentie een instructie voor de snelheid en twee instructies voor alle functies. Zo stuur ik altijd 3 dcc pakketten achter elkaar. Om een snellere responsietijd te krijgen, sla ik adressen over waar bij ik nog geen decoderwaarde (0-2) heb toegewezen. Hoe meer treinen er bij komen hoe langzamer pakketten herhaald worden.
Ik had nog getracht om het op een andere boeg te gooien door een nieuwe instructie 20x te herhalen en verder idle pakketten te sturen. Dat deed ik om eigenlijk altijd een snelle responsie tijd te krijgen. Ik las ook op nmra.org (http://nmra.org) dat een decoder geen nieuwe pakket mag ontvangen gedurende 5ms na zijn laatste pakket. Dus tussen het sturen van pakketten liet ik een tijd van 5ms tussen. Dit heeft nooit gewerkt en ik snapte niet waarom. Op het moment negeer ik die 5ms gewoon keihard zonder problemen (denk ik ???).
De vragen:
Als een treintje (en ik bedoel elke willekeurige decoder) zonder spanning komt te zitten, weet hij daarna nog steeds wat hij aan het doen is of heeft hij dan een instructie nodig?
Kan je 5ms lang geen nieuwe instructie of idle pakket op de baan zetten zonder problemen?
Voor het versturen van DCC pakketten, wat is beste manier?
Zoals ik het nu doe, continu pakketten de centrale uit trappen,
of eerste alle snelheids instructies en dan alle functie instructies te sturen om een tussen pauze van minimaal 5ms te realiseren?
Of om 20x een wijziging op de baan te zetten, gevuld met 5ms aan idle instructies er tussen?
-
<niet serieus>
Verstuur een SX1 frame, dat duurt 5msec en je hebt toch een signaal op de rails
</niet serieus>
Maakt je centrale in ieder geval nog universeler.
Groet,
Gerard van der Sel.
-
In de huidige wereld zou dat zeker makkelijker zijn. Maar bedenk wel, 20 tot 30 jaar geleden wat een byte nog een heeeeeel stuk kostbaarder.
Nu was dat richting bitje niet helemaal de handigste maar de andere extended pakketjes zijn best slim bedacht. Nu is het mogelijk meer data te versturen dan vroeger maar mooi backwards compatible. Met uitzondering van dat richting bitje ::)
Nadeel van langere instructies is de hoeveelheid decoders je kunt aanspreken/verversen in de tijd, het feit dat decoders vaker een snelheid willen zien dan of F20 aan moet staan. Naast dat je op deze manier de decoder wat tijd gunt. Toegegeven, met moderne uC's niet meer zo'n issue maar was het wel. Vandaar ook de 5ms. Dit dringt redelijk makkelijk een bepaalde manier van verversen af.
Dus tuurlijk zou het mogelijk zijn maar onderliggend is het huidige protocol eigenlijk KISS. (y)
Wat betreft spanningsloos, volgens mij als de decoder dusdanig lang spanningsloos geweest is dat ook de buffer van de uC leeg is heeft hij weer een instructie nodig wat betreft snelheid. Functies kan hij wel onthouden maar is volgens mij voor de lage functies niet verplicht en voor de hoge wel.
Maar om de boel wat te versnellen, waarom stop je niet gewoon alleen de snelheid in de ververs cyclus en de functies alleen bij aanroepen (en misschien nog eens per 5 seconden ofzo).
En om aan die 5ms te voldoen, je hoeft niet 5ms niets te doen. Je mag alleen niet direct dezelfde decoder aanspreken. Maar je mag prima door naar een ander adres :)
Timo
-
“De boel wat versnellen.”
MRdirect doet het (globaal) al > 20 jaar op de volgende manier en ik heb nog nooit klachten gehad dat commando’s te traag worden uitgevoerd.
Plaats de loc-adressen van alle actieve locs in een ringbuffer.
Maak per actieve loc een buffer waarin je het laatst gegenereerde baansignaal opslaat.
Doorloop het ringbuffer en zet dan het bijbehorende baansignaal op de uitgang cq. Ingang van de booster.
Zo worden alle actieve loc-decoders regelmatig “ge-update”. Het baansignaal wordt dus niet iedere cyclus opnieuw gegenereerd.
Komt er een verandering in de decoder pas dan het baansignaal in het buffer aan.
Spring in het ringbuffer vervolgens naar het betreffende loc-adres en het veranderde baansignaal wordt als eerste op de baan gezet.
Vervolgens kan je er voor kiezen in het ringbuffer terug te gaan naar het oorspronkelijke loc-adres of gewoon naar het volgende in het ringbuffer. Mijn ervaring is dat het niet uitmaakt welke methode je kiest.
Met alleen snelheidsopdrachten op hoge prioriteit en de functie informatie “zo nu en dan” maak je het onnodig ingewikkeld en is beslist niet nodig.
Bovenstaande procedure werkte zelfs goed op een 286 PC dus de modernere microprocessors moeten dat ook zonder problemen kunnen doen.
Succes,
Marco
-
Het grappige is dat mijn programma eigenlijk zo oningewikkeld als mogelijk op gezet. Ik bedoel dit is mijn loop()
void loop() {
readSerialBus();
shortCircuit();
if(packetSent) { // signal from ISR that last bit is transmitted on tracks
if(nextPacket()) { // nextPacket returns true when the first following packet is a speed packet
nextAddres(); } // select next 'active' addres
assemblePackets(); // assemble a new packet
sendPacket(); } } // sets required variables and enables ISR
Nogmaals in sequentie stuur ik: speed, function1, function2 -> volgende adres
Ik kijk dus of een pakket verzonden is, dan selecteer ik de volgende pakket. Dat is een speed, function1 of function2 (F1-F4 / F5-F8) en als het een snelheids pakket betreft, dan schuif ik ook het volgende adres. Dit was naar mijn mening de makkelijkste en kortste (514 regels code inclusief wit regels en compacte{} schrijfwijze) manier om alle pakketten de deur uit te trappen. Ik denk niet dat ik het korter en makkelijker had kunnen maken.
volgens mij doet een gemiddeld pakket er ca ~3ms (14 preabmle bits, 3 bytes en 4 extra bits met 50:50 '0' : '1' bits = ~75us/bit) over om verzonden te worden.
Ik doe in grote maten al hetzelfde als MRdirect muv het feit dat ik 3 pakketten per lok de deur uit stuur.
Het ringbuffer idee heb ik al anders opgelost door inactieve decoders over te slaan. Wat ik wel interessant vind, is om alleen de laatst gewijzigde functies uit te voeren, maar dit geeft we wel weer het probleem dat ik decoders, die stroomloos geweest zijn, ook nog een herhalingspakketjes moet versturen voor alles.
Wat voor mij de volgende logische stap zou zijn, is om eerst alle snelheidspakketten te sturen, dan de function1 pakketten en als laatste de function2 pakketten. Zo stuur ik nog steeds alles naar alle actieve decoders en elke decoder krijgt niet binnen 5ms een nieuwe pakket binnen.
-
Ook ik heb veel plezier beleefd aan het zelf bouwen van een command station.
Initiëel enkel DCC, later uitgebreid met MOTI en MOTII (new) (multi protocol centrale). Was inderdaad een hele kluif.
Initiële versie is ook gepubliceerd als een bouwproject in elektor ( https://www.elektormagazine.com/magazine/elektor-200809/18906 (https://www.elektormagazine.com/magazine/elektor-200809/18906))
Ik heb toen gekozen voor een ringbuffer die cyclisch alle pakketten ververst voor locs die recentelijk nog een opdracht ontvangen hebben, zij van het de MM of van een PC. Daarnaast maak ik gebruik van "urgent frames" die de cyclische afhandeling tijdelijk onderbreken. Elk pakket dat ontvangen wordt via PC (IB P50x) en/of MM wordt eerst verstuurd als urgent frame. Opdrachten die de snelheid van de loc verlagen worden daar bovenop nog met extra voorrang behandeld.
Loconet heeft nog lang op het lijstje gestaan maar nooit aan begonnen omdat ik voor mijn baan als S88 terugmelders had en de nodige accessory decoders.
Al bij al een leuk project.
mvg, Patrick
@ Marco, jouw aanpak is goed gevonden. Ik ben gestart met gelinkt lijsten van buffers voor diverse soorten pakketten en jouw oplossing is zelfs niet bij mij opgekomen.
-
@ Marco, jouw aanpak is goed gevonden. Ik ben gestart met gelinkt lijsten van buffers voor diverse soorten pakketten en jouw oplossing is zelfs niet bij mij opgekomen.
Leuk te horen. Er zit natuurlijk wel meer dan 15 jaar denkwerk in en optimalisatie (pogingen) aan ten grondslag. En ik ben er voor mezelf nog steeds mee bezig, oa LocoNet implementatie. Die wekt maar bij MRdirect is het P50 protocol toch stabieler. Door het XEvent mechanisme weet je continue of de verbinding cq communicatie nog goed functioneert.
M.vr.gr. Marco
-
Was vandaag nog even aan het puzzelen geweest met de code. Ik ben nu ook druk bezig met de arduino code om de wissels, bezetmelders en andere rand apparatuur aan te sturen en zodoende heb ik nog niks met MM2 gedaan. Te veel te doen in te weinig tijd...
Omdat ik met werk nogal veel bezig ben met state machines bedacht ik me dat het voor een DCC centrale ook handig kan zijn. Dus ik ging puzzelen en maakte:
(https://i.imgur.com/mvKqqRx.png)
De werking is als volgt:
Onder normale omstandigheden worden eerst snelheidsinstructies gestuurd naar de actieve locs, dan doe ik alle instructiebytes voor F1-F4 en als laatste komen functies F5-F8 aan bod.
Nadat een packet het spoor is opgegaan, check ik of er een nieuwe instructie is ontvangen. Indien zo, stuur ik deze nieuwe instructie 20x met 2 IDLE pakketten tussen de herhalingen.
De state machine in Code ziet er zo uit:
/***** MAIN LOOP *****/
void loop() {
readSerialBus();
shortCircuit();
#define State(x) break; case x: if(x ## F())
switch(state){
default:
State(assemblePacket){ state = awaitPacketSent; }
State(awaitPacketSent){
if(newInstructionFlag) state = newPacketSent;
else state = nextAddres; }
State(nextAddres){
if(lastAddresFlag) state = nextPacketType;
else state = assemblePacket; }
State(newPacketSent){
if(newPacketSentFlag) state = assemblePacket;
else state = nextPacketType; }
State(nextPacketType){ state = assemblePacket; }
break; }
#undef state
}
Ik ben niet zo'n fan van die function pointer arrays en prefereer deze methode. Ik maak gebruik van een slim truukje met een macro om een overzichtelijke structuur op te bouwen
Deze regel:
define State(x) break; case x: if(x ## F())
vervangt bijvoorbeeld
State(assemblePacket) {
door
break; case assemblePacket: if(assemblePacketF()) {
assemblePacketF()) is een van de functies die worden gecalled vanuit de switch-case. Alle functies dienen een 0 of een 1 te returnen. Pas wanneer een functie een 1 return't dan is de desbetreffende state klaar en wordt de volgende state geselecteerd.
Logisch benoemde flags reguleren de flow naar de volgende states.
Ik hoop dat ik dit weekend kan testen of dit niks stuk maakt een iets snellere responsie geeft (en wie weet wel het toeter probleem van m'n tee oplost ::))