Відео

Hi - afraid JMRI requires all detected blocks to be 'contiguous' - ie connected to each other with no gaps! Regards, Chris

Ha - it's a good recommendation but I'm not sure they do those in Code 100 either! Regards, Chris

Thank you - but yes, in JMRI all blocks need to be contiguous so it all has to be connected up. It was a pain when I was having to solder them all together, but from a logical running point of view, you have extra data -like when block B goes active, it also means that the loco has just started to exit block A - something that's incredibly useful to me at the moment and that I will try to explain in the next video! Regards, Chris

That's an interesting concept - I'll look it up! Thanks! Chris

@WirenwoodModelRailway thinking about it was a DMU or EMU that was the problem with the lighting, they modified the lighting some how and the creeping and stopping inconsistently stopped straight away.

Thank you - yeah, I think that keep-alives might be perfect for this problem - I just don't like the idea of them running around the layout and, if there's an issue somewhere, them not stopping when I need them to! Regards, Chris

Excellent, if you have any tips or instructions I'd gladly accept them! Regards, Chris

Ha, thank you, I think the more important lesson is to learn what trains I'm actually using on my layout! I do have a Hornby class 101 3-car which works really well. Regards, Chris

I've gone back to buying Lima 37s and 47s and DMUs, I'm not paying the vast price for the so called premium models now. And Hornby have made a good job of their Lima models in their R/R plus range.

Thank you! No, no issues at all with wifi reliability - I have an old wifi router from an expired internet contract sat up there in the loft and it's dedicated to the ESPs. The Arduinos and Galileos are wired. Sounds like you're making excellent planning progress! Regards, Chris

Hey Jeffroid! Yeah - I think in this particular case, they would! Might have a look into it. Regards, Chris

That's promising - I've reduced the number of coaches in my APT now as once it starts getting long, it's a bit of a liability! Regards, Chris

Thank you, that's very kind! Apologies - I missed this comment as I haven't really looked at UA-cam for a month or two. Regards, Chris

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

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

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

Thank you - yeah it is quite fun! Thanks, Chris

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.

Ha, thanks very much, Jade! Regards, Chris

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

"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

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

@@WirenwoodModelRailway I agree. I’m hoping that it will interface well with my loconet devices.

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!).

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

Ha, thanks, I've always had a toe in the dark side's pool, you know it!

Thank you for letting me know - I can assure you that, if it is the case, it is entirely by pure luck! Regards, Chris

Hey Tony - my stuff is here -ua-cam.com/video/WULCDdYoGKw/v-deo.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

@@WirenwoodModelRailway thats great - thanks

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

Thank you!

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 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

Thanks Tony! Interesting thought - do you mean that A or B would be something that exists in that block, rather than the block itself? Regards, Chris

@@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

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

@@WirenwoodModelRailway well i'm sure you have enough modelling skill to use it as a base to make it more realistic....haha

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

@@WirenwoodModelRailway Cheers thanks for that Chris

Ha, thank you, that,s very kind! Regards, Chris

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 think DCC sound is a very clever technology but - sadly, not something I've found myself particularly interested in.... yet!

I think some of the most creative layouts stem from finding clever ways to maximise available space! Regards, Chris

I did not! Thanks for the tip!

Thank you!! Regards, Chris

Hi - thank you - it's DCC!

If nothing else, just for an excuse to say 'knob' a lot !!

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

Good to hear. Sounds like you have more stable lighting conditions than I have.