A DCC layout using JMRI, running on a Windows PC. Running MQTT to communicate with several auxiliary devices - Arduinos, ESP32s - for accessories such as servo turnout motors, signals run by JMRI signal mast logic, relays for electrofrog control, block occupancy sensors using Infrared, LDRs and current detection
I have recently bought the APT. Rails of Sheffield have had the whole thing on huge discount, half price, so i thought why not?, as i have always loved the APT. I had the 1980 model years ago. I opted for the 5 car set, looked at the 7 car set but didn't want an unpowered motor car. I then bought a second powered motor car reduced in price, the instrument coach at half price and the 4 coach packs again at half price. Thats the whole formation at about 60% of the origonal price , very happy. On inspecting the model for the first time i was a little underwhelmed. Don't get me wrong, its a lovely thing, but i just felt it had a slight cheap feel to it. The last loco i bought was an Accurascale Class 55, amazing model..do you know where i am coming from. APT interiors are very 'plastic'. Pantograph is well below standard, should have been a nice etched one. The model is probably worth what i payed for it but the RRP for the whole thing would have been well over £1000, i think well overpriced for what it is. I don't have a layout at the minute so can't fully enjoy the model, but when i do, i have a new 16x8 ft planned in the next couple of years i hope i won't regret buying it.
Thanks for the comment! To be brutally honest, the model is best enjoyed as an ornament. I have 3 motor cars, two of the 'old style' one new. They all have running issues which developed over time. I believe there are issues with communication through the board and messages from the decoder are not getting to the motor all of the time. The coaches, old and new, have a horrible squeal from the pickups which, at least for the new version are worth it as the capacitors actually do their job and keep the lights on (the old ones don't). I want to love it, like you I love the actual train and its history, character, likewise Hornby. But I can't love this, it's below par in every sense. Such a shame! Regards, Chris
Thanks for all of your contributions there. I'm in no position to start something like this but I'm hoping to in the near future, and it is really hard to resist just up and getting all the parts and having a little play. We shall see; I do have a make shift workbench I can tide my time over until I can construct a proper layout. Are you still having relative success with MQTT? From your latest video it seems like you are, but always good to check as I don't recall hearing any gripes about it haha.
Thank you! Short answer is yes, definitely! I keep meaning to make a 'two year review' kind of a video (it would be two and a half years now!) and when I was thinking about that, it got me thinking about the best and worst decisions I've made so far, in terms of cost in time, money etc. DEFINITELY the worst decision was to go with RS485, in terms of time. I just couldn't get it running reliably. I had nothing against C/MRI, it was just that RS485 was its natural conduit, I guess. RS485 was constantly failing, the cheap Chinese components incredibly sensitive and destructive - if one went, it seemed it could take out lots of other components on the RS485 bus, the issues spread like a virus. MQTT on the other hand, over ethernet and Wifi, which I'm much more familiar, comfortable and experienced with, has just worked and never caused any issues. The only slight issue is JMRI occasionally having timeout issues (usually at startup) with MQTT but that's very specific to my setup, and something the devs are actively helping me with (there are a few threads on the JMRI user group board if you're interested enough to search them out!) I think a test setup on a workbench is a good idea too, especially as you're starting out. On a smaller, concentrated setup it's easier to weed out any issues you might encounter while you're getting used to it all. Regards, Chris
@@WirenwoodModelRailway that is very good to hear! My first degree course was around IP networking and MQTT had that familiarity about it, especially in terms of MAC address, IP Addressing and the like. I think I will in fact go for it in that case. The Mrs and I are currently in the process of moving you see, well, waiting for the contract process to move along to moving day, so after then I will have space to build my layout but before then yes I'll see if I can get a test rig setup. Thanks a lot - glad to hear it is working out and the only issue you've had is being investigated; I do know from friends the devs for JMRI are helpful like that and it's something to look forward to if I ever get stuck myself. Cheers Chris!
Ah interesting - I had seen that they had some of those. I think maybe the thing that put me off was the requirement for them to be above the baseboard and I wasn't sure I'd be able to hide them! Let me know how you get on with them. Regards, Chris
I know I'm quite late in response, but the APT-P was rarely run as a 14-car double set. Each half is actually counted as one set and they had to run two together. The full 14 car was just done a few times for press and promotional shots etc. Much more common was to have a shorter (2 or 3 passenger car) set and a full 5 or 6 passenger car set. Sometimes with one and sometimes with two NDMs. There is lots of info on formations on the 25kv APT site.
Thanks for taking the time to post - all information that I had no idea about and found really interesting! The 14 car version was never practical and didn't run for very long on my layout, but did leave me with enough components to run two trains. I'll take a look at the website and see if I can get two authentic sets running! Thanks again, Chris
Thanks Martin, I'm working on that right now! It's very satisfying to see those DMUs stop right next to the buffer on that bay platform! Regards, Chris
I'm about 3/4 of the way through and my brain has sufficiently melted. I understand what you've done but I think because your rail lines are quite complex it is a little hard to follow.
Ha, I think you make a valid point! I realised later that there were one or two bits I'd accidentally left out which might have helped! I'll try to include them next time. Regards, Chris
@@WirenwoodModelRailway I made it through, the logic side actually helps to understand because you pointed out what part of the rail yard you were working on. It's a highly impressive set up you have.
Light at the end of the tunnel finally. I did mention before about being stuck in automation mode in your disgruntled video. Nice to see sticking with it you’ve come out the other end (almost, with extra sensors in platforms being the last addition) so you can enjoy running your trains in whichever mode your mood takes you. Well done. Always enjoy watching your journey. So onto scenics finally, then the layout will really come to life.
Thanks Laurence - you did - and I remember typing in quite a long reply as your questions were valid and really made me think. Unfortunately still a few more things to do, including my least favourite job, resistive wheelsets! Even the manual trains need them, if they're running alongside automated ones. Thanks for the kind words, Chris
I know what you're talking about, and it's been a frustrating experience. I love the idea of a 'living layout' where trains automatically visit stations and businesses, but always find each potential system to be really 'automated,' unable to do anything more intelligent than a light switch on a timer. I would play transport tycoon and wish i could just take a waybill and drive, having everything else behave rationally to my presence. it seems that gap between a computer game and any real world layout is still shockingly large, as the closest I've gotten is in trainz, and those trains are much more simple minded than i hoped, requiring a lot of manual input to work without jams, but were kinda able to pull off the feeling if they don't get stuck at a light or pile up a one way track.😅
"Living Layout"! I love it. Where were you when I was trying (and failing!) to come up with a catchy title for the video?! I completely agree with your point, it doesn't become real fun until the train you're controlling needs to react to the changing environment around it. It's an interesting comparison, to a computer game, and a very valid one. But all of those extra variables on a physical layout, there is definitely a long way to go! Regards, Chris
The distance you have raised your automation control of your layout is a joy to see. I immediately view your videos when I get notifications. Keep up the good work. Mike
Thanks Mike - they're very kind and encouraging words! Not quite sure where I go technically after this (other than improving what's already there!) but I'm sure something will come up! Regards, Chris
Thank you! The intention is definitely to share it, i think i can pretty easily make it not dependent on RFID which would help. My main concern is that JMRI is so broad and there will be so many scenarios for config that i don't have that would very likely make it fall over for most people. I think gathering a small group of people together and testing it with them might be the way forward. Regards, Chris
certainly very interested in this, especially getting the information out of JMRI. for me the ideal is really letting JMRI manage the track, stitch it all together, but then have something else drive the trains according to the signals JMRI sets
Yeah, i actually found getting the signal mast that's protecting a block very difficult, to the point where it was easier just to work out what aspect the mast would be and use that instead! But i think that apart, that's pretty much what I'm doing! Regards, Chris
That’s amazing. I’m glad you’ve got it to work like this, which is most logical. And presumably with two stop sensors in the bay, you could stack two short DMUs and have the bay as platforms 1a and 1b on occasion. Then you could drive one in/out of the bay, and have the other automated, or both either way; a bit like the “shuffle down” in your storage yard lines. You’d need to know that the unit would fit in the available space, of course (or you might have a long wait just outside the station!).
Fantastic progress! And vey glad your mojo is intact! Looking forward to some scenery appearing now!! PS I have so many questions about the app you've built, but that can wait. PPS Please get a hatch cover that fits the hole before you fall down it! You're scaring me everytime you move about! That hatch on the floor is surely a trip hazard! Please take care/precuations!!
Thanks John, and thanks for looking out for me, my dad says much the same! The silly thing is, it's probably visible in the videos, i have a hinged flap in there that closes over and fills the gap, i just forget to close it. I'll endeavour to close it every time from now on. And fire away with any questions. Regards, Chris
I think that you have accidentally alighted on the same basic structure as the real railway uses: the interlocking is in a separate system from the route selecting and displaying, and the latter can only make requests of the former
@WirenwoodModelRailway @aleopardstail Hi Guys Which RFID system are you using - manufacturer/seller and model numbers? I'm way behind you guys in my progress but I have been thinking about the requirements for some time. Chris - thanks for demonstrating MQTT - love it. Cheers guys.
Hey Tony - my stuff is here -ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-WULCDdYoGKw.html - I'm using very basic stuff for RFID but it works for me - I let JMRI be the database so to speak, so don't need to program anything into the tags themselves. Chris
Another interesting video and is it me?…../ I don’t recall seeing any ballast laid before?. I did mention last video I’ve watched when will you get on to scenics, and thanks for that reply. So is ballast new?
Ha, thank you! Yeah I'd got that far - and I'd also done some tests on painting the rails (although was yet to find something I was happy with) and I was really getting into it, but then I solved the RFID issue I had, and that suddenly spawned all of this - updating the tracking app, new Knob box, automation etc. My instinct and comfort zone are always the technical stuff so I just got obsessive about all of that. I will get back to the scenics - Simon has given me the rest of the arches for the street and has plans for the background where I painted / ballasted - so I will get on with it soon! Thanks for asking! Chris
Yeah, there's so much to JMRI, the documentation can sometimes be a little scientific and doesn't always actually explain what can be done! Regards, Chris
I have been following your progress and is in part why I jumped from rocrail (plus simular automation problems), your idea of a project sounds very interesting and simular to my requirements... and you now have me thinking :)
have to say I find myself in agreement, what I want is a system thats "helps" run the layout, specifically I want to drive a terminal station, what I want is the automation to drive the rest of the layout. I want it to pick up a train once it leaves the station area, it will then take it, rattle it around before parking it. then periodically take one out of parking and fling it at the station, plus a few scenic ones to run around. but I do want the ability to manually drive one of those trains, in that pattern I suspect this will end up as a custom bit of software, let JMRI handle a display but thats about it (maybe even do that myself since its a single layout) but have something else monitor the blocks, allocated them, control semaphore signals and then drive the trains. its actually essentially what "1:1 scale" traffic management stuff does, except it also drives the trains. means a fair few inputs, and memory of states, RFID based identification, go far enough potentially axle counters to pick up "lost" vehicles etc can certainly say your progress is inspiring as to what sort of things may be possible oh yes, the ballasted bit is looking good
I think these are the real benefits that RFID bring. The layout's ability to 'know' which train is in a block, and therefore its, or our ability, to hand that train between ourselves and the layout. Similarly, say a train is sat in a platform, having finished its pretend journey, have a button that says 'get this train to the yard' and the app do the rest - work out a route, look at the yard lines for availability, shuffle any trains at the back of lines to the front, then pick a line and park the train. Or 'Get the class 43 to platform 2' - work out which block the 43 is in, try to calculate a viable route, and if there is, drive it. Although - I'm actually a couple of weeks ahead with the app than you see it in this video - I've discovered that there are issues with direction. It can now work out a route from block A to block B, but it doesn't know the things I take for granted - 'don't use that loop because it's anticlockwise and this train is facing clockwise'. It doesn't know which direction I want the train to drive in either. So the compromise here is it presents me with all of the routes it found, sorted by least blocks then least blocks occupied, and lets me decide which one to use. Still some human input, but as long as I keep it minimal I'm OK with that! Regards, Chris
@@WirenwoodModelRailway Direction was something that had me wondering, I have experimented but not gotten very far with the idea of sticking _two_ RFID tags on a locomotive - one at each end. I was using the higher frequency programmable tags (have some lower frequency ones to play with) - so I could stick the same ID on both tags but have one with a "rear" bit set. I set the detection code up so it didn't report a tag until it either saw a _different_ tag or a time gap passed. if in that gap it saw a second tag with the same ID it knew direction. just had a lot of issues with reading the programmable tags which I haven't quite resolved. I did however have my 3' test track which used DCC-EX and WiThrottle etc able to have my drive a train over the tag and then have the control system take over that address to drive the train for a few seconds before hitting stop. not much space to play, will hopefully be starting some video stuff soon to record the inevitable catastrophes. I think if you try to take over a train that has been set going you have the direction and in theory you can store "well it came in from that way moving forwards so the front is facing that way". I just think its useful to have the occasional reader dotted about to confirm what the assumed data is. I really want to get the higher frequency RFID stuff working as it makes life a lot easier when you can load the DCC address onto the tag and avoid needing to do a lookup, also can either store the train length or stick tags on the rolling stock. this works well with bogie coaches, twin axle stuff is awkward to get the tag low enough.. other option is short blocks and RailCOM but I have not experimented yet - the key though is totally "what is in this section" and "which way is it pointing", when you have that there is a lot you can do
I really like that tag at the front and end idea, I'm going to experiment with that. I can't see why JMRI would mind, it just puts the 'username' I assign the tag on the panel. So if front and back tag have the same username, and front or rear in the comment, JMRI won't really care but I should be able to apply some logic that determines front or rear. Direction when taking over a train would be fine as WiThrottle will already have told the app what direction the train is set to, but even if it hadn't, it would just be a case of not changing the direction, just the throttle speed steps. I think yeah my simple RFID tags work for me because all I want to do is identify the whole train. I never swap coaches around, so they all have the same formation all the time. I'm not going to get into shunting / moving coaches or wagons around so don't need that level of granularity. Thanks for sharing, it's really helpful and interesting! Regards, Chris
Definitely agree with wanting to run with manual and automated trains - closer to real world. That route setting system is lovely. Do think that running a particular train from A to B rather than block to block is a better way of thinking, then the route setting can determine if that is possible or if an empty stock move is required. Its great what you are doing.
@@WirenwoodModelRailway I'm thinking of "Train 103(TP DMU) from Yard (general location of multiple blocks) to Station (multiple blocks) Platform N (Block YY)", Routeing software identifies train location as Yard, Road 5 (block XX), 2nd train from exit - -- then allows yout to identify an Empty Stock Move. My thinking is that presently you have to physically inspect the yard for a train that can move, why not let the software tell you it is possible ? When train 103 has finished its duty and returns to yard it willl be at rear of a road - I feel that you may need to know what trains to move so that its ready for its next duty.
@@tonyshield5368 Ah, yes I get it - and it's a good idea! 'I want this train in platform 1, go find it, work out a route for it and bring it!' I just noted in another reply actually, there has to be some element of human approval at this point, as (and I've now written the code that does this) the app will decide that taking an anticlockwise train around a clockwise loop is a viable route. So it needs to present me with the routes it found, and suggest the most viable of those, but allow me to approve, and also to set the train direction, otherwise it's liable to make bad decisions! And the yard - I'm thinking have a section with the 3 yard line blocks in order in it. Check the first one - if it's empty, check the second. If the second is occupied and has an RFID ID, get a throttle for that train and move it into block 1. That should keep the yard lines tidy! Regards, Chris
now add a wifi camera to the train cabin, and stream to it to a pc controlled by the ps2 train controller, from "Densha de Go!" and make a new video. .
That's something actually that we've had quite a lot of discussion about already, as it happens! Thanks for mentioning the controller, I wasn't aware of them, but it perhaps looks a bit toy-like! Regards, Chris
Great video, How do you get the trains to slow down & stop at the red signals, I've been trying to work out how to do this in JMRI but not been able to find out how,. It would be great if you could do a video on this. Cheers. ,but not
Hi - thank you - you need to use automation, the trains that stop need to be being controlled by JMRI. Then it's a case of making sure that the trains are speed-profiled and that 'stop by speed profile' is ticked in the dispatch. Quite a lot of work involved in that, I'm afraid! Regards, Chris
I am enjoying seeing this being built up. Did you have a project plan originally or has it just ‘evolved’ as you think of new and possible implementations? Knob box is so intuitive…. ha; ‘knob’.
Interesting question - absolutely no plan at all! It all stemmed from a conversation with a friend, he'd volunteered and done a few days on some of Pete Waterman's layouts. He'd absolutely enjoyed it, but said that all control was done using tablets (maybe Z21 if I remember correctly) and he'd felt disconnected from the trains he was controlling. I'd only ever used tablets for train control up to that point so thought, well maybe I'll look into using something tactile instead. That's what led to that first plank of wood with a couple of knobs on it. I found I very much preferred the tactile control so the rest has been a journey into designing what's right for me, in terms of functionality. Regards, Chris
I’m very interested in trains, and have three working trains that sound like trains rather than running silently. I have both types of trains in my collection.
I live a space poor life, in which my home layout has to be turned into a shelf. It’s two boards long and wide enough to hold a minimal amount of scenery. It consists of a small freight yard and a two car station.
By the way, did you know that you could run both digital AND analog? All you need is the ANEMODEL LD101 controller and you can do it with single controller simplicity!!
Interesting. How reliable do you find the LDRs are? I have been working with adjustments for varying light levels in the room. But I still have problems with light coming in from the side of the coaches and not going active.
Hi Sven - they seem to be 100% reliable now. They're connected to an ESP and I've written code to read their values. It allows for a little fluctuation, so the sensor has to be giving readings below the active threshold for 100ms before the sensor state in JMRI is changed. And they have a 2000ms off debounce too. Regards, Chris
whats the overhead when you start using the logic stuff instead of just the basic hard coded stuff? does this start to hit the responsiveness as these scripts are run? have short blocks here, diamonds, just current sensing - I've sort of committed to resistor wheelsets "eventually", but this sort of thing will be very useful where I have a block split by a board join to combine two physical sensors into a virtual block
Hi again! I think in the grand scheme of things, impact is minimal - it's just a tiny bit of logic compared to most of what JMRI does. This is actually a small part of a much bigger project which I kind of touched on in the video, for which responsiveness and speed are very important. And as I'm very much sensitive to that, well, all I can say is it's simply instant - not just through the JMRI user interface itself, but also in the API, json server etc. - which is just what I need! As a small aside on performance, and this is just my experience - once I started introducing sensors, automation etc., the Raspberry Pi 4 that I originally ran JMRI on quickly put its hand up and asked to be excused from class, let's say. Just my experience - but once you start really asking quite a bit of JMRI, I think that the only really suitable hardware is PC, Mac etc. I think that the scenario you described, where a block continues over a board join, would be ideal for the multiple sensor approach. Regards, Chris
@@WirenwoodModelRailway Oh, you cruel, cruel person. Is there any way to add a timing element to the release block condition? E.g. don't release the block until it has been clear for x seconds.
@@ianjeffery4773 Ha! Yes - but you'd just use the standard debounce functionality for that, rather than add it with logic - so add 2 second debounce to off on either or both of the actual sensors. You could see in the video, actually, that the LDR has a 2 second to off debounce on it, so there was a delay between me clearing the block and the screen reverting it to inactive.
Wow, you’re still trying to eradicate the problems on your layout. I watch from time to time, and getting JMRI sorted to run trains automatically or semi automatically appears to take up all your time. How long have you been building your layout?. I do find it interesting even though I don’t use JMRI. DO YOU EVER FIND IT FRUSTRATING (sorry caps lock was on) that you can’t move on to doing scenic etc. to move your layout forward?. Do you think totally automated programs like yours are really worth it or they are too much trouble to get right. Especially as some of us are not computer programmers, and you do seem to be very into doing this programming and adding the correct sensors and associated electronics to make it all work. I’m not knocking your system, I’m sure itrains and train controller are probably the same levels of difficulty. Keep the videos coming to educate those of us who don’t understand how these systems work. Thanks.
Hi - I think you make some very valid points there! I could probably write an essay on this but I'll try not to! Yes, I get frustrated - not with JMRI as much as the wiring, the components. Much of that is down to my own deficiencies though, bad cabling and dreadful cable 'mismanagement' causing interference etc. Automation is an interesting one - I do think that a fully automated layout, if I ever got there, would bore me. For me I think the process of getting to fully automated is much more interesting than being automated. I made another video at the same time as this one, which I'll publish soon, in which I, to some extent, explain the 'why'. It's about making operating the layout unpredictable. Creating scenarios where the trains I'm manually driving have to take remedial action (slow, stop) due to caution, danger etc. And that caution and danger would be triggered by automated trains operating on the same lines at the same time and everything having to work around each other. Just like the real world. I've been building this layout for just over 2 years. You raise another interesting point though, around moving on to scenic. I have no scenic skills at all and it's something I'm really quite apprehensive about. Much as many who are not programmers would be apprehensive about doing some of the things that come more naturally to me. So I think an element of what I'm doing is actually deliberately delaying the technical completion of the layout, because it will move me way out of my comfort zone! Not sure I succeeded in keeping it brief, but hopefully that explains what's going on inside my head! Regards, Chris
Thanks Mike! And, I guess, exactly what I set out to do. I think it's maybe not widely known that JMRI can do this kind of thing relatively simply. Thanks for taking the time to comment. Regards, Chris
This was one of those conversations I needed to hear. I have been considering block detection and automation for years, but having heard your thoughts on it, its kind of scared me away from needed to do it! I appreciate you taking the time to make this video and explain your thoughts after the fact!
I'm sorry - I definitely didn't mean to scare anybody off! Full disclosure, I'm still working on and adding to my block detection despite everything I said in that video! Just weigh up, I guess the same two factors in any project - benefit vs cost. What would you be able to do if you had block detection fully installed, and would it be worth the cost in time and money it would take to get there? Regards, Chris
@@WirenwoodModelRailway nothing to be sorry about! I really appreciated the honesty and considering I was on the fence on it. It was the push I needed to understand if I wanted it or not. Who knows I keep watching your updates and go "balls, I'm going in to automation" but for now. It was what I needed to hear. Really enjoyed binge watching your stuff this week, so thank you
I know this is an old video but having set up one arduino successfully via USB cable, I've been attempting to set up the RS485 bus and I am now having the same week as you. I have fried at least one TTL converter because it must have got too hot (not really sure how but maybe I powered positive/negative the wrong way round). I either get a timeout or a unrecognised command in JMRI on the CMRI network. Going to look into the light blink circuit that you have mentioned to see if I can get something to work. Although I think the website has gone so not sure if I can get the details for that.
Hi - well, the first thing I have to say is, if you have any option at all (and obviously this is just my opinion and experience) - avoid RS485. I did get it working but it was unreliable and those TTL modules fry for no reason, very regularly. I abandoned CMRI and RS485 in the end and went to MQTT over Ethernet instead. If you have the space and tech to do it, I can't recommend it highly enough! It's a shame that guide went down, but it's basically an approach to cut out as many unknowns as possible. His GitHub repo is still there and this is the sketch - github.com/madleech/ArduinoCMRI/blob/master/examples/hello_world/hello_world.ino There are good instructions in there. Basically just uses the onboard LED on the Arduino to identify whether or not it's receiving data from JMRI. Let me know how you get on! Regards, Chris
What about using a snap relay or similar to provide DCC power to the blocks associated with the turnout in question ? Does jmri dispatcher still allocate a turnout (block ) when occupied by a manual train ? I like the idea of RFId - rfid tags are easier then having to provide resistive wheel sets plus it provides identification similar to transponding
Hi - no, Dispatcher does respect occupation, so if any block is marked as occupied, Dispatcher will wait until it clears to allocate it, and won't let an auto train enter it. I'm not sure that I would go down the route of RFID as occupancy detection as it presents a lot of the same issues as IR would in longer blocks - all of the actual occupation in the blocks is still handled, mostly by the current detectors. Ah I'd heard of transponding - I think that's a Loconet thing is it? Thanks for the comment! Chris
