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

Thanks for sharing how you like to operate your layout! Regards, Chris

Thank you Rudolf! Regards, Chris

Get a life

Thank you! And thanks for taking the time to leave a message. Regards, Chris

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

Thanks Justin, I appreciate you taking the time! Regards, Chris

Thanks I've just Googled them as I'd never heard of them - they look interesting! I'mnot sure what extra they'd bring though?! Thanks! Chris

Ah thank you that solved a mystery! I guess that would work - I hope there are extension cables available though or all your readers are going to be very close together! Regards, Chris

Thank you - it's a good shout, I'll have a look into it! Regards, Chris

Thanks Tony! Well, funny you should mention that! I've since done a video on RFID which enables JMRI, and therefore the cab signals app I wrote, to know what train is in a block when it goes to caution or danger. So what I'm currently working on is building a new 'knob box' controller which has LEDs integrated, showing signals for each train throttle. It would be perfectly feasible to build multiple boxes for multiple operators, as many as I had the time for really! I don't know if that would fully replace actual layout signals though, I like them just for some scenery! Regards, Chris

Hmm, yeah, good luck with that! I hope you find something, it must be out there! Regards, Chris

I know nothing about trains, but wonder whether an injectable 125kHz animal tag would work (low cost in quantity from various Chinese suppliers), sizes down to 8 mm x 1.4mm. If the mounting point is metal then space the tag away using VHB tape or similar.

Thanks Jim, that really does sound clever. An unexpected bonus of publishing this video has definitely been that I got to hear about other solutions - especially Train Controller and iTrain - it sounds like they are really accessible in terms of automation and do a lot to help us! Thanks for the comment! Chris.

@@WirenwoodModelRailway No worries,. I also have i-train which has its own unique way of working but much prefer Train Controller, (very expensive software to buy now but in my experience its the best and easiest to get going. Take care..

One question, have you tried those tags on stock with a metal chassis? I know there are specific tags for fixing on metal surfaces but just wondered if you’ve had any issues with it, or issues with there being live rails between the reader and tag?

Hi Martyn - thank you! And good question - I immediately scuttled up there to do a bit of a test and confirm that metal can interfere with the reading. My initial, very scientific test was to slap a tag on the back of one of those wallpaper scraper type tools and stick a few strong magnets to it for good measure - and no response. I then too the motor car from the class 43 and it looks like I'm getting nothing from a tag stuck to the bottom of that - even though the Class 40, Class 158 and Class 370s all had metal chassis too. This isn't a major issue for me as I can just stick a tag to the first coach, which is almost entirely plastic. But it may affect others who intend to use RFID in a different way. And yes, good idea to get the readers down before too much track / track detail goes on. I would have done that on mine but thought I'd never get RFID working so never got around to it! Then I got it working and wished I'd put the sensors down earlier. Regards, Chris

@@WirenwoodModelRailway thanks for doing some testing, very useful to know. After watching the video I did some rummaging as in the past we’ve built lots of RFID learning puzzles. In the stores I found some NTAG203s that are designed for metal and we’ve used successfully (massive overkill for this application). But these are 13.56MHz tags rather than 125Khz. Did you do much research on which frequency is best for this use case, I’m guessing low frequency is probably better? I’m just wondering if I can re-use existing kit or should just go down the route you took.

Hi Martyn - caveat here is I haven't tried any of this - but it looks like those 13.56MHz devices use SPI for communication which complicates things a little for me as, on the Arduinos, I've got ethernet devices plugged into the SPI ports. It did look possible to have multiple SPI devices connected at once but it looks like a bit of a cabling and code faff so I thought I'd go for the simple life (especially as it took me ages to get that working anyway!) and use the relatively simpler serial 125khz devices. So my advice would be make sure you're comfortable with the whole process, from reading, to processing, to sending to JMRI or whatever, before you invest. Think about how many readers you might need, where they'll be placed and what the conduit will be (Arduino over ethernet, ESP32 over wifi etc) to get those tags to their ultimate destination - I think I saw you using JMRI in a recent video so I'll assume that's what you're using. Hope that helps - get in touch if you want to chat some more about it. Regards, Chris

@@WirenwoodModelRailway that’s really good advice, thanks. I think I’ll take a step back and do a little testing with the kit that’s sat on the shelf. I have some code that allows me to talk to the high frequency readers using python, so I can use that for testing. That might allow all comms over USB, with the data then being dumped into MQTT if the hardware works reliably. But as you suggest I won’t make any choices till I’ve got stuck in and understand things a bit better. Thanks!

Good morning - and thank you! I'm afraid not - in the sense of controlling trains, DCC is very much a one-way protocol. The Command Station generates the digital instructions that are sent out to the decoders but nothing is sent the other way. I think maybe RailCom does something in terms of feedback but I've never used it. Regards, Chris

Absolutely - having signal status sent to the box and being displayed for the trains that each throttle is driving is definitely interesting me! The challenge to get around to start with is there are absolutely no spare pins on the ESP driving it! Regards, Chris

Thank you and yeah, I love pleasant surprises like that !Already got my head down working what I can do with it! Regards, Chris

Hey Jeff! And yeah, sniggering here too. I realised when I was doing this actually that different people will want different things from RFID, which is interesting in itself! Chris

Ha, it really is! Thank you! Chris

I'm afraid it's not that easy at the moment, Henry, they seem in short supply! I'm trying out a new supplier, if they send what I've ordered I'll come back with a link. But you want to be searching for 125khz EM4100. Regards, Chris

Sorry this took so long but it's taken a while to establish a reliable supplier, which I now have! Please note - I made a mistake in the video and referred to 10mm tags - the smallest ones are not 10mm, they're 20mm, which I think is why I struggled to find any! I recommend PAC Supplies on eBay (no affiliation) - they've been really helpful with me. These are the smallest ones that you see in the video - they're 20mm rather than 10mm. www.ebay.co.uk/itm/202972535921

@@WirenwoodModelRailway Thanks. I was curious about the "10mm" ones!!! I'd never heard of them (obviously, as they don't exist). How close are the tags to the readers? I could never get mine to read farther than 10 - 15mm away. Also, the metal weights in wagons interfere with the reader/tag contact, if I want to tag them.

@@henrybest4057 There's quite a distance with the Seeed ones as they're under 12mm baseboard, so probably 20mm I guess. Most of the tags work in when stuck in any recess I can find under the train. And yes, I'm getting issues with metal too - some of the locos - Hornby class 43 and another loco that slips my mind right now - the tags wouldn't work underneath them, so I just stuck them under the first coach in the rake instead. Regards, Chris

Thanks Lee!

Hi! That sounds interesting but I think the issue I'd have is that the ethernet connectors I have use the SPI interface so the devices wouldn't have a way of communicating the tags received back to JMRI / MQTT. You do have me thinking about what I'd program the tags with though! Regards, Chris

@@WirenwoodModelRailway gone with an over-engineered solution here for the RFID, one reader - one ESP8266 controller.. keeps the SPI wires short and talks directly over MQTT. also means they are portable for testing and connect to the layout with just a power and ground wire. See! part of a layout can be "just two wires"...

@@aleopardstail I like it, good idea! Just two wires, wow. I think these days it's only the wires propping the baseboards up on this layout. If I took them out the whole thing would collapse into a dusty heap on the floor! Regards, Chris

Hi - thank you! The code is shared in the description - I've shared a repo that contains the code for all of my layout nodes - specifically, the ones containing RFID code are github.com/Vintage80sModelRailway/Nodes-for-JMRI/tree/main/MQTT_Client_PS_Node_2 - this is the one I use in the video, and two others github.com/Vintage80sModelRailway/Nodes-for-JMRI/tree/main/MQTT_Client_PS_C1_minimised github.com/Vintage80sModelRailway/Nodes-for-JMRI/tree/main/MQTT_Client_PS_Node_3_minimised Get going and good luck! Regards, Chris

@@WirenwoodModelRailway Thanks Chris sorry I did not spot the links in the description. Love what you have been doing. Regards John

@@modelrailwaytheeasyway9743 Thanks John, that's very kind, and no need to apologise, it was a bit of a breadcrumb trail to the code! Regards, Chris

Thank you for the kind words and, funnily enough, I am very much digging my way down the next rabbit hole this weekend! Regards, Chris

Hi Chris - good to hear from you. I'd never considered automating trains outside of Dispatcher, that might just solve the problem for my shuttle, if I can get it to respect the manually reserved blocks that my little app is putting in to protect the 2 blocks ahead of my manual trains. And ha, yeah, that sounds very similar to my first automation project, getting JMRI to assume control of a train as it went over an IR sensor at the front of the yard, then taking it in and parking it for me. I had to set the points though. I'm playing with RFID now and one plan I have is to use tag IDs from RFID to make that process much more dynamic. Regards, Chris

Thanks Luke that does sound like the best of both worlds, it must be a lot of fun. I'm starting to understand how Train Controller must be doing that - to an extent it has to guess, I think. But it must be doing stuff I can't fathom yet! Regards, Chris

Thanks TB! I'll look into that - and also the MERG Automation SIG, I don't think I knew they had one somehow, so I should join that too. Strangely this 'I'm not sure I enjoy automation any more' video, and mainly the responses to it like yours, have really got me back into automation again and planning to do stuff with the station! Regards, Chris

Now that's caught my attention - thank you for messaging! I'm off to Google conductive plastics - if you have any links to further information on the wheelsets you're talking about please post them! Thanks, Chris

Hi Mary - it would but sometimes short blocks are a necessity rather than a choice - sometimes there can be more than one entry / exit into a block and trains 'short cut' through along the shortest route - this is similar to a double slip I think. The issue with the double slips is they effectively offer two routes and if I was to extend their length along adjoining track, then presence on that track would prevent the double slip's alternate route being used. All about compromise! Regards, Chris

Hi Justin and, well thank you so much, they're very kind and encouraging words! And I think you're absolutely right, the point is to enjoy it and learn from it. I totally agree - those automated trains do look good when they're running, especially acceleration and deceleration. Your kind words, and many from others too have got me back on the 'I'm going to make it work somehow' path - I think my mission now is to get automated and manual trains running on the same layout! Regards, Chris

Thanks - I am intrigued on how that works - just being able to have blocks exactly where you want them, it's definitely something I need to look into. Regards, Chris

Thank you - and yeah, an automated train is just as likely to stall as a manually run one - more so, maybe, when you take those slow starts and slow downs into account. But - it doesn't break anything - JMRI knows the train went into the block and it's waiting for it to enter the next one - it allows for the fact that the train might stop. So it just sits and waits, and once the 'hand of God' has done its thing, you're off like there was no hold up. Grumpy imaginary passengers aside. Yeah, my cabling is terrible and it does cost me time, trying to follow the right ones. Or accidentally knocking a few out and having no idea where they came from! One day I'll sort it all out. Probably! Regards, Chris

Thank you - and yes that sounds very similar. I was a real Electronics beginner to start with - and I still struggle to get my head around it. I love those ideas! Especially optical recognition, although I struggle to tell a Class 40, 55 and 37 apart when they're all in the same livery so I hope the AI would fare better. Really interested to hear how you get on with all of that! Regards, Chris

They have some excellent libraries that do the heavy lifting of the image processing nowadays

@@WirenwoodModelRailway Thanks Chris, I have a really hard time just getting started - at all !! 😂 Yes, the imaging needs to be able to read the numbering at speed. Regards the Procrastinator

@@maryginger4877 OK, wasn't aware of that. You will need more processing power than a micro computer, but one central PC should be able to process and control everything I should think. Will look into that, thanks!

@@downunderDSB Ha, procrasticator, great word and definitely one that I can relate to!

Thanks Howard - no but it could do, I'll take a look into it - it's definitely an option! Good to hear from you! Regards, Chris

Well maybe you could have your yard outside of the automated routes - somewhere that automated trains never go, then you can trust that you're in charge of the points and they won't get changed at short notice. Then when your train is built up, drive it to a point on the layout that the software is aware of, and trigger something - maybe an RFID sensor would work well - that says to the software - 'OK you take it from here'. I think I'm going to do something similar with my yard, and RFID is the next thing to implement I think! Regards, Chris

Thanks George! And yes, you're right - a completely separate branch line would work, but I didn't build one in and it feels a bit late now! The frustrating thing is it almost works - if I'm driving manual trains and can see signals, then I can, like you say, give way to the auto trains and avoid collisions. It's just those split second moments - the software allocating 2 blocks ahead and switching points in those blocks with no notice when it allocates them - giving me no time to react if I have a train hurtling towards said points! I'll work it out! Regards, Chris

Thank you! The monitor is just attached to my PC, the one running JMRI. It's a good point actually, something I forgot about - it's another requirement of automation, that that panel is built, as it's what JMRI uses to work out how all of the blocks are connected. It's a bit of a pain to build, that part of the software is not the easiest to use. I think I've mentioned it over time, as I've been building it up, but never done an actual video on it - you can see in this video, from about 1 minute, the PC starting up and the panel appearing, but that's as close as I get! kzfaq.info/get/bejne/pbtkdLpyx8iWj40.htmlsi=pXYIdKa0niJ5nvG2&t=69. Maybe I'll do a video soon on how it was built - it's a good idea! Regards, Chris

Thank you! Yeah, I think the end wasn't right, it was supposed to be a bit tongue-in-cheek but that didn't come across. I think the bottom line is, like you say, if you're in a place where you can enjoy the process, enjoy the journey that gets you there, then, of course, throw yourself into it. Next - well, after two years of head scratching, and after mentioning it in another comment today, I went back to RFID, which I just haven't been able to get working at all. And I got a bit of luck, and worked out what was going wrong, so am now planning that out - and, somewhat hypocritically will probably embark on that next. Hypocritical because it would be fairly useless to me, but I think I'll enjoy getting it working! Regards, Chris

Thanks Antony! I've never used iTrain so am very interested to hear about how it works, and what the differences are. Thanks for taking the time to comment. Regards, Chris

@@WirenwoodModelRailway It's pretty neat software...while not free like JMRI, it has pretty good functionality without breaking the bank. I have the standard edition and it has everything I need. It does error now and again but I think that it is mainly because I went the super cheap way with detection - I use S88 on a Dr5000 with arduinos and they are connected to reed switches. Obviously with current detection, you reduce a lot or ghosting risks (which I do get now and again) - fortunately iTrain does pick this up and usually stops the trains when they appear where it doesn't expect them...might be worth looking at the documentation and some of the tutorial videos (Bob Fuller) to see if it might fulfill your needs...They have a 2 month free trial as well. I am sure it would save a lot of time and frustration over manual coding and you sound as if the fun is going out of it...not where any of us wants to be....Good luck! (I am not in any way affiliated with them and normally try to escape with the cheapest options)

I use iTrain as well, far better at operating than I am!

@@Rule1ModelRailways Thanks for the vote! I'm now at the stage of actually Googling iTrain to see what it's all about! Regards, Chris

Thanks Calvin, and yeah that sounds like a plan. I enjoyed the video, those auto trains are looking smooth! Regards, Chris

Thanks Mike, I'm sure your wife is very grateful to iTrain 🤣. Just out of interest, does it support the driving of manual trains at the same time, and does it provide the operator with tools to prevent collisions, derailments and short circuits? Thanks! Chris

@WirenwoodModelRailway My Wife enjoys playing with me. 😉🤣 Yes, iTrain supports manually controlled trains. It doesn't let you run lights or enter blocks already occupied.

Ah yes, sorry - to clarify - all of the track that is intended to be used for automation should be part of a block - so sure you could leave your yard track not assigned to blocks with no occupancy detection - but you wouldn't be able to configure JMRI to use those areas of track for automated trains. Regards, Chris

@@WirenwoodModelRailway That makes sense. I wonder if there's a way to include turnouts and crossovers in "the right block" to have them work safely in the way you want. I am thinking a turnout should be part of the block they are switched to, and that they cannot be switched when occupied. Basically, so the trailing arms of the switch would connect from the trailing block they are switched to. Crossovers should probably be a large (enough) block including the tracks leading up to them to give safe stopping distance. NM: Just read up about sections, which are designed to encompass multiple blocks, so turnouts and crossings can be logically protected. This is definitely food for thought as I have similar ambitions to your regarding automation.

Thank you for the comment and yes - I totally agree, but I do think that, for something as complex and time consuming as automation, electronics and, to an extent, the use of complex software, have to be 'your thing'. It's not necessarily someone who is not interested in, or struggles with, that side of things could easily pick up and expect to have instant success with. Regards, Chris

Thanks, Lee!

Hi - and thank you! Good question - I had to turn it off once I added the upper deck track as due to the extra lines, there can be more trains out of the yard, and therefore more empty spaces, including entirely empty lines, which there weren't before and it was getting a bit mixed up. Something else that's on the 'must get around to rewriting' list! Thanks, Chris

@@WirenwoodModelRailway Makes sense - I'd be very interested if you do go back to it. One day I'll have a bigger layout and I'd really like to implement something like that for the fiddle yard and station. The other thing I'm curious about using automation for is sound effects - getting sound-enabled locos to whistle in particular places, etc. but also for ambient scenic sounds like slamming doors and guard's whistles when trains are departing from stations. Personally I'm more interested in automation for that sort of 'making the layout respond to what I'm doing' effect than having it drive trains for me.

@@JanjyGiggins Ah I think that's pretty easy in JMRI, there are events you can trigger in sections - when a train enters a block, leaves a block, triggers a sensor in a block etc - and you can then choose decoder functions to execute - from memory anyway! I'm not really into sound so I've never played with it. And yeah I will update the yard stuff - the issue I was having was it was harder to track if a train was in the yard or not as more could be out, so the logic was taking control of a loco to move it forward, and actually that loco was out on the track somewhere and would suddenly slow down to a crawl, yard speed! The trick will be to better track when trains are in the yard - RFID would be ideal but I've never managed to get that working, even in test. Regards, Chris

Speaking of RFID, McKinley Railroad on KZfaq built a system using RFID, have a look. He’s big on electronics. And also wants to have some trains running automatically in the background for more realism while operators can run their trains manually and include overhead screens to view the traffic.

@@ClinchfieldModelRailroad Yeah, I'm a big fan of Mckinley and do often wonder how they make it work - automated trains running at the same time as manual - especially with no apparent visible signalling system - I suspect that they're actually fully automated, and that operators are actually driving semi-automated trains, to a script ans part of the timetable. As for RFID - my failures are much more basic than that, I've never actually got a reader to read a tag! I suspect I've bought dodgy tags. Regards, Chris

Thanks Jeffroid! Totally agree and the first point you made sounds like fun. The problem (in JMRI at least) is with the second point. You're right, in that JMRI will stop a train it's driving if there's danger ahead. And that if you're driving manual trains while JMRI is thundering auto trains around, you need to be able to see signals for your manual trains at all times (or have some kind of notification of caution / danger). However, it's about allocation. JMRI will not warn you that it's going to allocate a block / section to its train. And it allocates them ahead of the train (that's a user setting, I have it at 2 blocks ahead). I kind of went through it at about 18:25 in the video - as soon as it allocates a block to its train, any turnouts in that block are set in its trains favour. Regardless of where any of your trains are - OK, your trains won't be on the turnout because it won't allocate itself an occupied block - but your train could be 3cm from entering the block that JMRI just allocated itself and set the points for - which means you have about 1 second to realise and stop your train, otherwise it's a short circuit or derailment (depending on if you use electrofrog or not) for your train. And that's what's currently stopping me. The trick for me would be to 'pre-allocate' blocks - have software that's read the config and knows the path the auto train is going to take, and allocates blocks 2 blocks ahead of the ones JMRI is allocating. Then those blocks are reserved for the auto train, for a short space of time, without the points being set - which prompts an alert for my trains that they're heading towards an occupied block, and either gives me chance to stop them, or met them run through the contested block and occupy it before JMRI allocates it. Complicated stuff! Regards, Chris

@@WirenwoodModelRailway Oh, I get you; JMRI doesn't know where you are driving to but does know where you are. So what you need is for JMRI to set a route for the train but allow you to drive it manually. Yes, complicated.

Great video and good timing. I’m trying to decide whether to order software and hardware for my (first) layout, at huge expense and it’s so hard to justify the cost involved. Also the learning curve to set it up. I want to play with trains, not programming software. I still can’t decide 🤷‍♂️. Help 🙏

@@alanwhite4003 Hi Alan, i think that's the exact dilemma isn't it? The more you're prepared to dive in to the nitty gritty, complex software config, electronics, programming, the less expensive the whole thing is, but the more high maintenance it is. I think I've just about gone down the least expensive route but it's been hugely time consuming and still really quite expensive! Hopefully you're watching lots of videos on train controller and iTrain too, to get a balanced view before deciding! Regards, Chris

Hi, and thank you! Yeah it really is a rabbit hole. I think something I maybe forgot to emphasise in the video is, just like Lego, if you're into that kind of thing, the process of building it can be very enjoyable - it was for me, I just have, again, that Lego-like feeling if 'oh wow, now it's done I can .... just sit and look at it?!'. Be careful with those short blocks and a good question to ask yourself when building / planning is 'how will the layout know when....?' - with the diamonds, how will the layout know when the whole train has entered the next block, as opposed to just the front of it? Regards, Chris

@@WirenwoodModelRailway thinking automation here won't be via JMRI, likely a Raspberry Pi playing with the MQTT interface. as for the diamond, well its basically part of a larger "block" its just one track circuit, it gets allocated by the "signal box", the system will see it occupied as the loco enters, the sensor will say "I'm free" in *that* voice when the loco leaves but the micro controller watching it will only report it as clear when one of the two possible routes reports the train has reached a given block further along the line. likely having quite a few shorter track circuits that get combined in the logic when it comes to being reserved. I gather JMRI can do with with "sections" that get allocated in one go but I also need to keep them allocated after a train passes through until it reaches the next "signal post" location. pure hobby in itself really, and yes I fully get the "ok that works, so now what? just watch it?" stuff. find its good to have something else to break into, be that painting part of the layout or even something totally unconnected - the moment it starts to get tiresome walk away for a bit for blocks though I tend to see a "block" as the space between signals, which has one or more track circuits attached, and when you have diamonds you get one track circuit that can be part of multiple blocks in the logic. have gone from a 4'x2'6" loop that was four "blocks" and about ten track circuits to a 12'x7' loop thats still only four blocks, and with logic that only permits a train to stop in two of them (the other two being too short to hold a train), actually less operable but with parallel loops. will get a video up on it all eventually - something else you are far better at, the motivation to actually film it all

Hi - thanks for the suggestion and absolutely yes. Incredibly, those class 370 coaches have capacitors - which are very visible through the windows of the coaches - but they don't hold charge for any length of time so don't prevent flickering. This was corrected on the second release of the train but there's no offer from Hornby to fix the first batch. Regards, Chris

Thanks - yeah just need those steps sticking down and a bit of filler, then a big re-paint and it might be looking completed! Regards, Chris

Thank you, there are no silly questions! You mean the IR sensors? I have shift in registers and 5v power supply pins close to them, then the shift in registers run to the Arduino. To fix them in, I chop a square off, say a 4cmx4cm batten, then put a screw that's, say 5cm long, through the middle of the block but only half in. Then screw the sensor to it so that the bulbs stick up above the block. Then line it up to the hole, bulbs through the hole towards the track, main screw head facing down, and when it's all lined up, screw the screw into the baseboard to hold it in place. Not sure I described that all that well, I'll do a bit on it in the next video! Regards, Chris

Thank you, I am getting a lot of help but it's making a huge difference. Regards, Chris