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
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
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
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 -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
Looking great, really good to see you did't give up with automation altogether. The custom C# App is brilliant welcome to the dark side :D.
Ha, thanks, I've always had a toe in the dark side's pool, you know it!
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
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.
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
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
great up on channel
Virgil Coves
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
Thank you for letting me know - I can assure you that, if it is the case, it is entirely by pure luck! Regards, Chris
Walker Mark Martinez Anthony Thompson Larry
@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 -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