Today I caught up with your four videos from the last 3 months. I am impressed by the amount of creative work you are doing to effect the desired automation without requiring the wheelset resistors. Watching the multiple trains running is quite enjoyable; also seeing the screen monitoring the changes in block status certainly adds to the fun. In one of the four videos you said two personality traits of yours are impatience and laziness. Seeing the amount of work you have invested, I find it hard to believe the laziness attribute. Thank you again for letting us look over your shoulder as you pursue this dream.
Thanks Justin! And yes, it's hopefully getting to a point now where I can just sit and enjoy it all working as I'd like it to. And, ha, on the laziness I know plenty of people who would disagree with you! Regards, Chris
Ha, thank you - I've had a good 30 years of practice when it comes to code, this kind of thing is very similar to my day job really. Although arguably that would be a good reason not to do it at all! Thanks, Chris
Ha, that made me smile, and I'd have pretty much guaranteed that I'd have daydreamed my way through that lesson, some of it must have sunk in! Regards, Chris
I have a couple ideas that might work. what if you took and instead of making sure every car is checked what if you made a caboose or car that can be put at the very end acting as the sensor. which cars are going to be at the end and make some special trucks with the end piece that would normally hook up to another car have the end device that would normally be put at the end of an engine. With the light on it. the trucks would be removable containing all the necessary materials to draw enough power
Thanks for the suggestion - I'm not quite sure I understand it, also it may not be right for my layout as my train formations tend to be static and don't change - I don't do shunting etc. Sounds like it might work though! Regards, Chris
This is amazing. I would love to be able to do this. I too dont fancy the resistor wheel sets but i have no idea how to achieve what you have. I can cope with reasonably straightforward Arduino code but i dont understand how the code acesses the individual train's parameters. Would you consider doing a video(or more) to explain the app youve created and its code, sufficient for me and others to be able to do it. I realise thats maybe a lot of work but just thought I'd ask. I love your videos. Its great to be able to follow you through the process. Its very helpful and encouraging. Thanks for sharing your journey.
Thank you, that's very kind! I'm trying to write the apps, as much as i can, to be relevant to other JMRI layouts and, hopefully, not specific to mine. My hope is that, one day, I'll get them robust enough to be able to make them available, the source and the compiled apps, to anyone who wanted to give them a go. They're not stable enough yet, but I'll get there! Regards, Chris
That is some very very clever thinking. I may take this idea and roll it into my automation. I have a similar issue on my tramway. Blocks appear unoccupied when a tram is present. This cause is different. 4 wheel trams often "sit down" on dead spots on track. They stop drawing current and the DTC2 can't detect them. JMRI then drives another tram into the back of them. I've been thinking of a way of rewriting my JMRI scripts. Now you have me thinking about rewriting the Arduino sketches to ensure that the next block is active before the allowing a block to go inactive. Easy when the blocks are on the same Arduino, trickier when the block is on the next node. Thanks for sharing this. Cheers Chris
Thank you Chris - knowing some of the work you've done and seen you present, it means a lot coming from you! Sounds like a plan, a lot of the logic in the monitoring app I wrote is based on sequence, which I think is quite similar - when a new block goes active, attempt to work out what direction the train is travelling in by checking occupancy of surrounding blocks - if the one to the right is occupied and the one to the left isn't, then it's likely that the train is travelling right to left. Regards, Chris
@@WirenwoodModelRailway checking adjacent blocks when they go active is a smart idea. But, I don't think I need to do that. When automated, my tramway is one way so the block sequence is fixed. However, I'll need to think through the consequences of implementing this. If I drive a tram manually and use a turn back siding, that would break the one-way sequence. Hummm, that complicates things. I'd need some kind of reset function for when things inevitably go wrong. You've given me lots to think about. And possible content for a MERG talk.
@@WirenwoodModelRailway I mentioned your time expanded detection system at the Arduino SIG last night. It got a very favourable response. John Fletcher (SIG leader) said "this needs to be written up and submitted to the journal". A couple of other people had already watch your video and been impressed. It's the idea that the "Arduino" keeps the sensor active even though the DTC2 isn't detecting that has impressed me and others. I need to get my head around how I can implement that.
@@chrissharp6845 Wow, thank you - and challenge accepted, I've been threatening to, and backing out of, writing something for the journal for a long time. The Arduino side of things was actually very simple - in the code, sensors are objects (with properties such as last known value, pin, is inverted etc). I just added a new boolean 'Is on hold' property. Then, when the Arduino receives the 'hold' message for a sensor through MQTT, it sets that value to true. Then the 'check sensor' method simply has a line at the top saying 'if on hold = true, return'. Then, when the 'release hold' MQTT message is received, on hold is set to false and the check sensor method starts executing normally again. I do have a timeout on there too, around 30 seconds, in case for whatever reason the 'release' message doesn't arrive. I do try to get onto the SIG calls but life always seems to get in the way! Regards, Chris
Thanks for sharing another video. The logic makes good sense, just complicated to get all the software to talk and share the information but I guess that's what you have sorted with your custom app. I took a more simplistic approach and just hold the blocks for much longer than necessary as I didn't fancy the resistive wheelset option either. I did notice that for JMRI to stop a train for a red signal within one of my safe blocks, it needed to leave the previous block so delaying that block every time was causing an issue but fortunately it's only short trains that use that part of my layout so I just don't hold the previous block for a long train in that case. You shouldn't have that problem if it knows the speed and length of the train.
Thanks for the comment - I'm interested in the leaving the previous block thing - when you set a train off in Dispatcher do you set the train length? And do you have your block length properties set in JMRI? If Dispatcher knows that the length of a train is less than the length of the block, then it will wait until the whole train is in that block to stop it. If it thinks the train is longer than the block, it will stop the train as soon as it first enters that block. That's what I remember anyway - it might be worth tinkering with those length values to see if you can change the behaviour! Regards, Chris
@@WirenwoodModelRailway Thanks Chris. That might be a good call actually. I haven't bothered with the block lengths and train lengths after adding stopping sensors but this might be an issue from a time when I was trying to use those values to control the station stopping distances. I'll have a look later. I suspect the train length is less than the block length in this instance. Also on a related topic, I have been amending CVs 3, 4, 5 and 6 to get my trains to run at similar speeds. This may not be something you want to change if you have a solution but should one train be massively different in terms of speed, it might be something to adjust.
Very true, it would be an issue. But it's an incredibly rare occurrence. I guess if i wanted to mitigate that risk i could just put a resistor on the back axle of the back coach / wagon of each train? Good point! Regards, Chris
@@WirenwoodModelRailway how about toggling blocks? The head of the train toggles block sensor into "Occupied" and the tail toggles it back. If decoupling occures, then block never frees. This method also simlpifies automation in taking away time-length-speed calculations.
@@rcsailboat hmm I think it actually makes life a lot more complicated as sensors don't toggle, they go on when they're activated and off when they're not. So the toggle logic would need to be program the toggling logic. Not something I'd fancy! Regards, Chris
Regarding the comments of parting trains, I'm looking into using a resistor or track powered FRED on the last wagon to protect it. For most of my layout it would stop a rear ender but at junctions/crossovers may need some LogixNG to stop allocation of blocks in between.
Hi - thank you. And yes, I think for absolute full reliability, there needs to be something drawing current on the last coach / wagon of every train. Sounds like a good plan! Regards, Chris
This is how iTrain does it. It knows the length of the trains, the speed of the trains (track speed against speed setting), and the point in time that the train enters or leaves (same thing) a block. It can then calculate the instantaineous position of a train in a block, even when the speed within a block changes.
Thank you - I'm learning a lot about iTrain at the moment from someone who is taking time to really explain its inner workings. It looks like a clever piece of software. Regards, Chris
Seems to me that if you have sensors on the points, you could tie the "timer" for the main blocks to the occupy trigger for the point. Then if the train stops, the point remains active, and the adjacent blocks remain active, even when there's no current sensed(?) I'm figuring a top & tail method of block detection, obviously the locomotive always runs current. I'm planning to modify all of my coaching stock for track powered lighting. Still leaves me with a problem for the wagons, but the guards vans will also be modified for a tail light... and since I'm steam era, the only time there won't be a van on the end of a goods train is when the train breaks, and losing the tail of the train is a whole new problem!!
Thank you - yeah, I think the 'spot' sensors thing is definitely worth looking at, I just didn't like the sheer volume of them that I'd need! Top and tail would work in most scenarios but make sure you take short blocks into consideration - sometimes long blocks can become short blocks if they have a turnout in the middle of them leading into another block. Regards, Chris
Clever, "Lies to Children" (JMRI edition) hopefully I will have enough of a loop to play about with similar soon (ish) what you are getting into is a proper Train Management System, and your set up with pretty much everything going roundy roundy or back and forth works well. no need to overly complicate it this actually sounds like something JMRI should be able to do itself, given you can profile stuff and tell it the length of the blocks I like this, comes down to JMRI doesn't see the sensor directly, it sees what its told the sensor is. with MQTT also quite easy to have a "real sensor" and a "virtual one" - JMRI sees the virtual one, and a logic controller sets that based on considering the real ones etc goes to show just how deep this rabbit hole is very nice
You're absolutely right and, I think, part of my reason for publishing this video is to say 'look, this is possible'. Dispatcher has access to exactly the same config data and live telemetry that the app I wrote has, it would just need an 'agreed' method with JMRI to override sensor reports. I didn't fancy that bit, in JMRI, which is why I opted to go direct to the sensors - that's something that wouldn't be at all straightforward for JMRI. Good to hear plans are progressing! Regards, Chris
Love what you are doing with automation. I totally get the calculations that you are doing. But I'm not sure where you are doing them? Perhaps you could cover the current overall architecture in a future video. Have you also automated the speed profiling? It seems like a necessity if 128 speed step granularity is needed for a new loco both forwards and backwards. No need to reply directly. Make more videos
Thank you - I keep trying to put something on video but it just gets too detailed and too boring too quickly! The basis is that the main part of the apps run on a loop so every 100ms or so it recalculates where it thinks the train is based on the current time. And yes, speed profiling is automated, you just tell it what speed step to start at, which to end at and what step between to do then leave it ti get on with it. Regards, Chris
Have you thought about axle counters instead? Entry and exit counters for each block? This way speed is irrelevant and would also catch decoupling issues. Could use micro IR emitter/receiver pairs to count with nothing more than white paint in the middle of each axle...?
Hi - thanks for the suggestion - it's an interesting point and something that's been discussed from time to time on MERG. It's definitely something I'd like to understand more about and explore. Regards, Chris
@@WirenwoodModelRailway Or could try tiny magnets on each vehicle with Hall sensors at the start and end of each section or block. Either way, it's counting in and out to determine section occupation. I'd suggest treddles, but mechanical options introduce their own set of problems...
BTW with JMRI warrants for auto trains it dynamically calculates train speed over block length to check if the speed to throttle ratio is correct. I'm also not keen on going on the resistive wheelset exercise and looking at how to keep blocks occupied.
That's interesting - I've looked at warrants a couple of times but it seems unavoidable that I'd have to add in all the lblocks etc. which just seemed like too much work! Regards, Chris
@@WirenwoodModelRailway I was starting off when seeing your early struggles made me change from dispatcher to warrants. Hat's off for what you achieved 👍
@@modelrailwaytheeasyway9743 I recognise some of the work you're doing in your videos from MERG - I'm starting to write it all up for the journal but will maybe add some more detail either in the forum or in an online meeting. Feel free to contact me though if you have Regards, Chris
It is a clever idea but it limits what you can do from what you had before. How can it deal with a train stopping at a station decelerating through the block and at a station a parcel van being added to the train. It looks like everything now has to run at constant speed and length for it to work whist before you could do that. I started out using reed switches with a tiny magnet under vehicles which worked OK but as the amount of stock increased it was hard to keep up with the number of magnets needed. Not so much of a problem now with sales on line I can get them cheaper and more powerful so smaller than ones I started out with. No really up your street I guess not being an electronic solution but these days I use treadles that are depressed by the wheel flange of any vehicle so no need to modify anything on my stock before it can run.
Sounds good! No need for constant speed, the app is connected to WiThrottle so gets all throttle changes for the locos it's tracking, which it logs. Even if the train stops between blocks the app knows and adjusts. For my requirements static lengths is fine, i don't have uncouplers and don't switch wagons or coaches between trains. If i did it would be possible to put sensors on the exit of yard, platform that measure the length of the trains as they leave. Regards, Chris
@@WirenwoodModelRailway OK That sounds good then. I don't often re marshal trans on my layout either but some DMU's get doubled up 2 car to 4 car in the station or a parcel van added or taken off so it was that kind of flexibility I was thinking about. The real railways are using axle counters more these days which for someone with a knowledge of detecting and counting a wheel would work well on a layout.
Hi - thank you - I'm not really aware of them but I think the issue I'd still have would be how to get the occupation information back into JMRI. I'll take a look though! Regards, Chris
Re: paint "wearing out" - that's why we solder 805 resistors between wheels and axles. As for the sort of dead reckoning you can do - it doesn't deal with a separated train (slipped coupling), which is also a real world problem. If you're OK with that, then dead reckoning (and putting the consists in a database and computing length, speed etc) would be fine.
Thank you - I didn't mention it in the video but I did explore the soldering avenue but just couldn't find the right resistors - I bought some quite small standard type resistors (I'm no expert here!) but I think the low wattage was an issue as they just burned up when I put them across the rails. Finding the right size, but also able to cope with the power going through it, was an issue for me! Regards, Chris
@@WirenwoodModelRailway there should be no issues, if the detector sensitivity is correct; then you should be able to go up to kilo-ohms with the R value. generally, we go 5 to 20 kOhm with detectors reliably sense a rolling stock drawing at least 1 milliamp. Anything is way far from burning or melting.
How do you manage not to melt the plastic insulation between the wheel disc and the axle? I destroy 1/4 of the wheels, another ~ half is not straight any more, and only about 1/10th is perfect :D .. I switched to the Uhlenbrock conductive paint.
@@czsokola Ah - counter intuitively, I use a very hot iron and I use a good flux, tin the wheel and axles, and then when I place the resistor I barely need to touch the end with the tip and the solder just flows into place and seals the deal.
If you made your blocks a consistent length - say 3m then you could free up the previous block only when the train enters the block one ahead of its current block. This would ensure that exactly one block is occupied for each train, irrespective of how fast the train is travelling.
I like the concept, but sorry to be a party pooper, what if a wagon or coach becomes detached from the rest of the train? If the last wagon or coach had a lamp (as they would in reality), there would be a current draw. Worth considering?
🤣 parties are there to be pooped. Or is that just me?! Anyway yes, totally valid point, although it's very rare. And the prefect solution too! Regards, Chris
With your new software you actually should be able to fake a block between two real blocks. Just the gap belongs to the block "behind" the train in each direction.
Hi. I’m really interested in the layout of your railway - you have some interesting route ideas that I’m keen to explore as part of my next layout design. Do you have an AnyRail layout file that you’d be willing to share?
Hi, thank you! I do have one - in fact there are loads of iterations of it that got saved during the planning stage. They're not exactly neat and perfect, it was more just to see what would fit and what wouldn't, so the curves are a bit inconsistent and it's not a true representation of the yard as I kind of went off-script with that when I started laying it! But will happily share - there's an email address in the 'about' for the channel - if you email me on that I'm sure I'll be able to get them to you. Regards, Chris
Ha, I do keep saying that to myself, at the end of every little project. Then something else gets me and I think 'oh I'll just do that and then it will definitely be finished'. I'm mulling over the idea of updating the monitoring app, as it now has a WiThrottle connection, to auto-stop the trains they're monitoring, but I don't think there's much value in it. I'll probably end up doing it anyway! Regards, Chris
Today I caught up with your four videos from the last 3 months. I am impressed by the amount of creative work you are doing to effect the desired automation without requiring the wheelset resistors. Watching the multiple trains running is quite enjoyable; also seeing the screen monitoring the changes in block status certainly adds to the fun.
In one of the four videos you said two personality traits of yours are impatience and laziness. Seeing the amount of work you have invested, I find it hard to believe the laziness attribute. Thank you again for letting us look over your shoulder as you pursue this dream.
Thanks Justin! And yes, it's hopefully getting to a point now where I can just sit and enjoy it all working as I'd like it to. And, ha, on the laziness I know plenty of people who would disagree with you! Regards, Chris
Although this is totally over my head I do find it interesting as to how you get around your problems.keep up the good work
Ha, thank you - I've had a good 30 years of practice when it comes to code, this kind of thing is very similar to my day job really. Although arguably that would be a good reason not to do it at all! Thanks, Chris
I remember getting the DST triangle lesson in school and thinking.... When am I EVER gonna use that? Hahaha. Boom! Right now. 😀 Well done!!!!
Ha, that made me smile, and I'd have pretty much guaranteed that I'd have daydreamed my way through that lesson, some of it must have sunk in! Regards, Chris
great vlog on channel keep up the great vlogs thanks lee
Thanks Lee!
I have a couple ideas that might work. what if you took and instead of making sure every car is checked what if you made a caboose or car that can be put at the very end acting as the sensor. which cars are going to be at the end and make some special trucks with the end piece that would normally hook up to another car have the end device that would normally be put at the end of an engine. With the light on it. the trucks would be removable containing all the necessary materials to draw enough power
Thanks for the suggestion - I'm not quite sure I understand it, also it may not be right for my layout as my train formations tend to be static and don't change - I don't do shunting etc. Sounds like it might work though! Regards, Chris
This is amazing. I would love to be able to do this. I too dont fancy the resistor wheel sets but i have no idea how to achieve what you have. I can cope with reasonably straightforward Arduino code but i dont understand how the code acesses the individual train's parameters. Would you consider doing a video(or more) to explain the app youve created and its code, sufficient for me and others to be able to do it.
I realise thats maybe a lot of work but just thought I'd ask.
I love your videos. Its great to be able to follow you through the process. Its very helpful and encouraging. Thanks for sharing your journey.
Thank you, that's very kind! I'm trying to write the apps, as much as i can, to be relevant to other JMRI layouts and, hopefully, not specific to mine. My hope is that, one day, I'll get them robust enough to be able to make them available, the source and the compiled apps, to anyone who wanted to give them a go. They're not stable enough yet, but I'll get there! Regards, Chris
That is some very very clever thinking. I may take this idea and roll it into my automation. I have a similar issue on my tramway. Blocks appear unoccupied when a tram is present. This cause is different. 4 wheel trams often "sit down" on dead spots on track. They stop drawing current and the DTC2 can't detect them. JMRI then drives another tram into the back of them. I've been thinking of a way of rewriting my JMRI scripts. Now you have me thinking about rewriting the Arduino sketches to ensure that the next block is active before the allowing a block to go inactive. Easy when the blocks are on the same Arduino, trickier when the block is on the next node.
Thanks for sharing this. Cheers Chris
Thank you Chris - knowing some of the work you've done and seen you present, it means a lot coming from you! Sounds like a plan, a lot of the logic in the monitoring app I wrote is based on sequence, which I think is quite similar - when a new block goes active, attempt to work out what direction the train is travelling in by checking occupancy of surrounding blocks - if the one to the right is occupied and the one to the left isn't, then it's likely that the train is travelling right to left. Regards, Chris
@@WirenwoodModelRailway checking adjacent blocks when they go active is a smart idea. But, I don't think I need to do that. When automated, my tramway is one way so the block sequence is fixed. However, I'll need to think through the consequences of implementing this. If I drive a tram manually and use a turn back siding, that would break the one-way sequence. Hummm, that complicates things. I'd need some kind of reset function for when things inevitably go wrong. You've given me lots to think about. And possible content for a MERG talk.
@@WirenwoodModelRailway I mentioned your time expanded detection system at the Arduino SIG last night. It got a very favourable response. John Fletcher (SIG leader) said "this needs to be written up and submitted to the journal". A couple of other people had already watch your video and been impressed. It's the idea that the "Arduino" keeps the sensor active even though the DTC2 isn't detecting that has impressed me and others. I need to get my head around how I can implement that.
@@chrissharp6845 Wow, thank you - and challenge accepted, I've been threatening to, and backing out of, writing something for the journal for a long time. The Arduino side of things was actually very simple - in the code, sensors are objects (with properties such as last known value, pin, is inverted etc). I just added a new boolean 'Is on hold' property. Then, when the Arduino receives the 'hold' message for a sensor through MQTT, it sets that value to true. Then the 'check sensor' method simply has a line at the top saying 'if on hold = true, return'. Then, when the 'release hold' MQTT message is received, on hold is set to false and the check sensor method starts executing normally again. I do have a timeout on there too, around 30 seconds, in case for whatever reason the 'release' message doesn't arrive.
I do try to get onto the SIG calls but life always seems to get in the way! Regards, Chris
Thanks for sharing another video. The logic makes good sense, just complicated to get all the software to talk and share the information but I guess that's what you have sorted with your custom app. I took a more simplistic approach and just hold the blocks for much longer than necessary as I didn't fancy the resistive wheelset option either. I did notice that for JMRI to stop a train for a red signal within one of my safe blocks, it needed to leave the previous block so delaying that block every time was causing an issue but fortunately it's only short trains that use that part of my layout so I just don't hold the previous block for a long train in that case. You shouldn't have that problem if it knows the speed and length of the train.
Thanks for the comment - I'm interested in the leaving the previous block thing - when you set a train off in Dispatcher do you set the train length? And do you have your block length properties set in JMRI? If Dispatcher knows that the length of a train is less than the length of the block, then it will wait until the whole train is in that block to stop it. If it thinks the train is longer than the block, it will stop the train as soon as it first enters that block. That's what I remember anyway - it might be worth tinkering with those length values to see if you can change the behaviour! Regards, Chris
@@WirenwoodModelRailway Thanks Chris. That might be a good call actually. I haven't bothered with the block lengths and train lengths after adding stopping sensors but this might be an issue from a time when I was trying to use those values to control the station stopping distances. I'll have a look later. I suspect the train length is less than the block length in this instance. Also on a related topic, I have been amending CVs 3, 4, 5 and 6 to get my trains to run at similar speeds. This may not be something you want to change if you have a solution but should one train be massively different in terms of speed, it might be something to adjust.
I still think you will have a problem if you get an accidental uncoupling. How will JRMI know there is an uncoupled wagon/coach on any block?
Very true, it would be an issue. But it's an incredibly rare occurrence. I guess if i wanted to mitigate that risk i could just put a resistor on the back axle of the back coach / wagon of each train? Good point! Regards, Chris
@@WirenwoodModelRailway how about toggling blocks? The head of the train toggles block sensor into "Occupied" and the tail toggles it back. If decoupling occures, then block never frees.
This method also simlpifies automation in taking away time-length-speed calculations.
@@rcsailboat hmm I think it actually makes life a lot more complicated as sensors don't toggle, they go on when they're activated and off when they're not. So the toggle logic would need to be program the toggling logic. Not something I'd fancy! Regards, Chris
Regarding the comments of parting trains, I'm looking into using a resistor or track powered FRED on the last wagon to protect it. For most of my layout it would stop a rear ender but at junctions/crossovers may need some LogixNG to stop allocation of blocks in between.
Hi - thank you. And yes, I think for absolute full reliability, there needs to be something drawing current on the last coach / wagon of every train. Sounds like a good plan! Regards, Chris
This is how iTrain does it. It knows the length of the trains, the speed of the trains (track speed against speed setting), and the point in time that the train enters or leaves (same thing) a block. It can then calculate the instantaineous position of a train in a block, even when the speed within a block changes.
Thank you - I'm learning a lot about iTrain at the moment from someone who is taking time to really explain its inner workings. It looks like a clever piece of software. Regards, Chris
Seems to me that if you have sensors on the points, you could tie the "timer" for the main blocks to the occupy trigger for the point. Then if the train stops, the point remains active, and the adjacent blocks remain active, even when there's no current sensed(?)
I'm figuring a top & tail method of block detection, obviously the locomotive always runs current. I'm planning to modify all of my coaching stock for track powered lighting. Still leaves me with a problem for the wagons, but the guards vans will also be modified for a tail light... and since I'm steam era, the only time there won't be a van on the end of a goods train is when the train breaks, and losing the tail of the train is a whole new problem!!
Thank you - yeah, I think the 'spot' sensors thing is definitely worth looking at, I just didn't like the sheer volume of them that I'd need! Top and tail would work in most scenarios but make sure you take short blocks into consideration - sometimes long blocks can become short blocks if they have a turnout in the middle of them leading into another block. Regards, Chris
Clever, "Lies to Children" (JMRI edition)
hopefully I will have enough of a loop to play about with similar soon (ish)
what you are getting into is a proper Train Management System, and your set up with pretty much everything going roundy roundy or back and forth works well. no need to overly complicate it
this actually sounds like something JMRI should be able to do itself, given you can profile stuff and tell it the length of the blocks
I like this, comes down to JMRI doesn't see the sensor directly, it sees what its told the sensor is. with MQTT also quite easy to have a "real sensor" and a "virtual one" - JMRI sees the virtual one, and a logic controller sets that based on considering the real ones etc
goes to show just how deep this rabbit hole is
very nice
You're absolutely right and, I think, part of my reason for publishing this video is to say 'look, this is possible'. Dispatcher has access to exactly the same config data and live telemetry that the app I wrote has, it would just need an 'agreed' method with JMRI to override sensor reports. I didn't fancy that bit, in JMRI, which is why I opted to go direct to the sensors - that's something that wouldn't be at all straightforward for JMRI. Good to hear plans are progressing! Regards, Chris
Love what you are doing with automation. I totally get the calculations that you are doing. But I'm not sure where you are doing them? Perhaps you could cover the current overall architecture in a future video. Have you also automated the speed profiling? It seems like a necessity if 128 speed step granularity is needed for a new loco both forwards and backwards. No need to reply directly. Make more videos
Thank you - I keep trying to put something on video but it just gets too detailed and too boring too quickly! The basis is that the main part of the apps run on a loop so every 100ms or so it recalculates where it thinks the train is based on the current time. And yes, speed profiling is automated, you just tell it what speed step to start at, which to end at and what step between to do then leave it ti get on with it. Regards, Chris
Have you thought about axle counters instead? Entry and exit counters for each block? This way speed is irrelevant and would also catch decoupling issues. Could use micro IR emitter/receiver pairs to count with nothing more than white paint in the middle of each axle...?
Hi - thanks for the suggestion - it's an interesting point and something that's been discussed from time to time on MERG. It's definitely something I'd like to understand more about and explore. Regards, Chris
@@WirenwoodModelRailway Or could try tiny magnets on each vehicle with Hall sensors at the start and end of each section or block. Either way, it's counting in and out to determine section occupation. I'd suggest treddles, but mechanical options introduce their own set of problems...
BTW with JMRI warrants for auto trains it dynamically calculates train speed over block length to check if the speed to throttle ratio is correct. I'm also not keen on going on the resistive wheelset exercise and looking at how to keep blocks occupied.
That's interesting - I've looked at warrants a couple of times but it seems unavoidable that I'd have to add in all the lblocks etc. which just seemed like too much work! Regards, Chris
@@WirenwoodModelRailway I was starting off when seeing your early struggles made me change from dispatcher to warrants. Hat's off for what you achieved 👍
Great work
Thank you!
@@WirenwoodModelRailway I would really be interested in how you create some of the apps.
@@modelrailwaytheeasyway9743 I recognise some of the work you're doing in your videos from MERG - I'm starting to write it all up for the journal but will maybe add some more detail either in the forum or in an online meeting. Feel free to contact me though if you have Regards, Chris
It is a clever idea but it limits what you can do from what you had before. How can it deal with a train stopping at a station decelerating through the block and at a station a parcel van being added to the train. It looks like everything now has to run at constant speed and length for it to work whist before you could do that. I started out using reed switches with a tiny magnet under vehicles which worked OK but as the amount of stock increased it was hard to keep up with the number of magnets needed. Not so much of a problem now with sales on line I can get them cheaper and more powerful so smaller than ones I started out with. No really up your street I guess not being an electronic solution but these days I use treadles that are depressed by the wheel flange of any vehicle so no need to modify anything on my stock before it can run.
Sounds good! No need for constant speed, the app is connected to WiThrottle so gets all throttle changes for the locos it's tracking, which it logs. Even if the train stops between blocks the app knows and adjusts.
For my requirements static lengths is fine, i don't have uncouplers and don't switch wagons or coaches between trains. If i did it would be possible to put sensors on the exit of yard, platform that measure the length of the trains as they leave. Regards, Chris
@@WirenwoodModelRailway OK That sounds good then. I don't often re marshal trans on my layout either but some DMU's get doubled up 2 car to 4 car in the station or a parcel van added or taken off so it was that kind of flexibility I was thinking about. The real railways are using axle counters more these days which for someone with a knowledge of detecting and counting a wheel would work well on a layout.
I 3D printed some wheelset insulators with conductive plastic. problem is they are now 2k Ohm per wheelset when 20k ohm would be better..
That's very clever - I didn't even know there was such a thing as conductive plastic! Sounds like a really good solution. Regards, Chris
Hey mate, just wondering with your automation at the end of blocks, could you not use red and green dwarf signals? With asp-1 or asp-2 infrared units?
Hi - thank you - I'm not really aware of them but I think the issue I'd still have would be how to get the occupation information back into JMRI. I'll take a look though! Regards, Chris
Would it be possible to use the DCC Concepts DCF-WP12 pcb pickup and bridge the contacts with a resistor??
I'm sure it would - I think DCC Concepts sell resistor wheelsets too which might be an easier option. Regards, Chris
Re: paint "wearing out" - that's why we solder 805 resistors between wheels and axles.
As for the sort of dead reckoning you can do - it doesn't deal with a separated train (slipped coupling), which is also a real world problem. If you're OK with that, then dead reckoning (and putting the consists in a database and computing length, speed etc) would be fine.
Thank you - I didn't mention it in the video but I did explore the soldering avenue but just couldn't find the right resistors - I bought some quite small standard type resistors (I'm no expert here!) but I think the low wattage was an issue as they just burned up when I put them across the rails. Finding the right size, but also able to cope with the power going through it, was an issue for me! Regards, Chris
@@WirenwoodModelRailway there should be no issues, if the detector sensitivity is correct; then you should be able to go up to kilo-ohms with the R value. generally, we go 5 to 20 kOhm with detectors reliably sense a rolling stock drawing at least 1 milliamp. Anything is way far from burning or melting.
How do you manage not to melt the plastic insulation between the wheel disc and the axle? I destroy 1/4 of the wheels, another ~ half is not straight any more, and only about 1/10th is perfect :D .. I switched to the Uhlenbrock conductive paint.
@@czsokola Ah - counter intuitively, I use a very hot iron and I use a good flux, tin the wheel and axles, and then when I place the resistor I barely need to touch the end with the tip and the solder just flows into place and seals the deal.
If you made your blocks a consistent length - say 3m then you could free up the previous block only when the train enters the block one ahead of its current block. This would ensure that exactly one block is occupied for each train, irrespective of how fast the train is travelling.
Would be great if I could but there are lots of reasons why blocks can't be the same length - layout design, turnouts etc. Regards, Chris
I like the concept, but sorry to be a party pooper, what if a wagon or coach becomes detached from the rest of the train? If the last wagon or coach had a lamp (as they would in reality), there would be a current draw. Worth considering?
🤣 parties are there to be pooped. Or is that just me?! Anyway yes, totally valid point, although it's very rare. And the prefect solution too! Regards, Chris
With your new software you actually should be able to fake a block between two real blocks. Just the gap belongs to the block "behind" the train in each direction.
Maybe, it just seems too much to think about right now for my tired head! Thanks for the suggestion though! Regards, Chris
Hi. I’m really interested in the layout of your railway - you have some interesting route ideas that I’m keen to explore as part of my next layout design.
Do you have an AnyRail layout file that you’d be willing to share?
Hi, thank you! I do have one - in fact there are loads of iterations of it that got saved during the planning stage. They're not exactly neat and perfect, it was more just to see what would fit and what wouldn't, so the curves are a bit inconsistent and it's not a true representation of the yard as I kind of went off-script with that when I started laying it! But will happily share - there's an email address in the 'about' for the channel - if you email me on that I'm sure I'll be able to get them to you. Regards, Chris
you certainly think outside the box
Ha, thank you, that made me chuckle. Regards, Chris
I know you said you think you have reached the end of the tech path. I doubt it you love it to much. lol.
Ha, I do keep saying that to myself, at the end of every little project. Then something else gets me and I think 'oh I'll just do that and then it will definitely be finished'. I'm mulling over the idea of updating the monitoring app, as it now has a WiThrottle connection, to auto-stop the trains they're monitoring, but I don't think there's much value in it. I'll probably end up doing it anyway! Regards, Chris