|
Hi,? for various reasons I opted to use IR sensors for detecting where my loco(s) is on the track and for block occupancy,? not realising (because i'm new to this) that JMRI seems to only be able to detect when a loco enters a block and there isn't a mechanism to know if it's part way through a block or even exited a block until the sensor at the start of the next block is triggered.? Unlike current sensing methods with isolated track blocks etc where you know the loco and carriages are on the block somewhere and hence it is still occupied. ? So I was wondering if it was possible to use a second IR sensor at the end of the block section which unless it is triggered after the first sensor for the block is activated would indicate a loco is still in the block and thus it is still occupied? ?
Could JMRI with a block exit sensor connected in someway and possibly some scripting make this work? OR? alternative as I am using an Arduino for my IR sensor decoder could an Arduino sketch code be used to also monitor the block exit sensor for each block and unless it is activated following the block entrance sensor being activated would keep the block entry sensor still activated so? jmri? knows the block is occupied , ? if that makes senses. ?? Just looking at ideas to explore, before I scrap IR sensors for block occupancy.
Thanks Steve
|
Using point sensors, like IR sensors, can get complicated. You have to consider things like intermittent activation (if the sensor goes ON/OFF/ON as the train goes by), how to handle it if a train reverses out of a block, etc. It¡¯s easier with more information. Some people have put two IR sensors togehter to get an idea of which way the train is going. Some use delays to avoid intermittent firing. You can use JMRI scripts or Logix to take the inputs and figure it out. Somebody who¡¯s done it will probably comment on that. But if you want to use timing to e.g. check two nearby sensors to see which way it¡¯s going, an Arduino might be a better tool. Bob On May 29, 2019, at 6:18 AM, SteveM <steve@...> wrote:
Hi, for various reasons I opted to use IR sensors for detecting where my loco(s) is on the track and for block occupancy, not realising (because i'm new to this) that JMRI seems to only be able to detect when a loco enters a block and there isn't a mechanism to know if it's part way through a block or even exited a block until the sensor at the start of the next block is triggered. Unlike current sensing methods with isolated track blocks etc where you know the loco and carriages are on the block somewhere and hence it is still occupied. So I was wondering if it was possible to use a second IR sensor at the end of the block section which unless it is triggered after the first sensor for the block is activated would indicate a loco is still in the block and thus it is still occupied?
Could JMRI with a block exit sensor connected in someway and possibly some scripting make this work OR alternative as I am using an Arduino for my IR sensor decoder could an Arduino sketch code be used to also monitor the block exit sensor for each block and unless it is activated following the block entrance sensor being activated would keep the block entry sensor still activated so jmri knows the block is occupied , if that makes senses. Just looking at ideas to explore, before I scrap IR sensors for block occupancy.
Thanks Steve
-- Bob Jacobsen rgj1927@...
|
Steve - Bob is right - ?it can get tricky! ?But I am doing exactly what you are looking at: IR sensors at block entry and exit, ?monitored by an Arduino acting as a C/MRI node, talking with JMRI. In fact, I am in the middle of writing this all up to share somewhere. ?It¡¯s particularly interesting because I can set up monitoring of three blocks on a single Arduino nano for under $10 in components. ?I would be ?happy to share my Arduino code and write-up to get your comments as long as you recognize this is still a ¡°work in progress.¡±
?
Jerry?
___________________________________
jerryg2003@...
|
I'd be interested in the code too as I am doing this exact same thing
On May 29, 2019 2:15 PM, "JerryG via Groups.Io" <jerryg2003@...> wrote: Steve -
Bob is right - ?it can get tricky! ?But I am doing exactly what you are looking at: IR sensors at block entry and exit, ?monitored by an Arduino acting as a C/MRI node, talking with JMRI. In fact, I am in the middle of writing this all up to share somewhere. ?It¡¯s particularly interesting because I can set up monitoring of three blocks on a single Arduino nano for under $10 in components. ?I would be ?happy to share my Arduino code and write-up to get your comments as long as you recognize this is still a ¡°work in progress.¡±
?
Jerry?
___________________________________
jerryg2003@...
|
Hi Jerry and everyone else, thank you for the feedback so far, ? currently I'm using Jeff Bunza's code scan_sensors.py script to connect the IR / Arduino to JMRI which seems to work without any problems, but i'm interested to explore other methods to achieve better occupancy detection. My setup is very basic at the moment as I get to grips with DCC but i'm willing to test out any code and try to provide feedback. ? I will try to workout some logic with entrance and exit sensors possibly pseudo sensors controlled by scripts,? but I better write some stuff down and do some testing before I waffle on about something that has a strong chance of not working :)
|
I think scan sensors py works best with track switch feedback relays, back to sensor table to flip lights in a table to drive lights on a panel.? Perhaps a sensor state change to an Arduino listener object. Ir sensors work well for gate crossing or calculating scale speed.
Bob
|
Steve,
What you want to do is very possible and easy. First the exit detection can be the entrance detection for the next block so you don't actually need to add any extra detectors but you can have as many as you want. Just OR gate the outputs together (diodes on each output, most detector outputs go low for on so anodes joined together and connected to the Arduino input or cathodes joined and to the Arduino if they go high for on.) then if any of the detectors are set the block will show as occupied. If you are using one detector for exit/entry then have two diodes on that one and connect the second one to the next block input along with any detectors in that block, and follow this through all blocks. No changes to code needed
You will then get the sequence of
block A occupied / blocks A + B occupied / block B occupied / blocks B + C occupied?/ block? C occupied as the train passes along the track. the only thing with this approach is that detectors need to be placed so that at least one is detecting the train at any time or you will get a line clear on your panel. This can also be fixed by adding current detectors to each block.
To help eliminate the possibility of flicker set the detectors across the track at an angle
Tony
https//ozfreemo.com
|
Tony -
good suggestions, but I think the placement of sensors is more of a issue than you let on. ?I run everything from 1 car to 8 car trains. ?I¡¯d have to put a lot of sensors to make sure I¡¯m always detecting the 1 car trains. ?However, ?some electronic or computer logic would allow you to determine if a block is occupied even if the sensors are spaced farther apart than a train length. ?I use Arduinos to capture sensor status and then process that info before passing results (which blocks are occupied or not) onto the panel (in my case, a JMRI panel on my computer, but could also be a physical panel).
Jerry
___________________________________
jerryg2003@...
|
You could possibly use both a current sensor and then IR sensors at both ends of the block.
toggle quoted message
Show quoted text
On May 30, 2019, at 9:23 AM, JerryG via Groups.Io < jerryg2003@...> wrote: Tony - good suggestions, but I think the placement of sensors is more of a issue than you let on. ?I run everything from 1 car to 8 car trains. ?I¡¯d have to put a lot of sensors to make sure I¡¯m always detecting the 1 car trains. ?However, ?some electronic or computer logic would allow you to determine if a block is occupied even if the sensors are spaced farther apart than a train length. ?I use Arduinos to capture sensor status and then process that info before passing results (which blocks are occupied or not) onto the panel (in my case, a JMRI panel on my computer, but could also be a physical panel). Jerry ___________________________________ jerryg2003@...
|
Jerry,
One of the main reasons that most use current detection is then anything, even a single wagon with resistor wheels, in the block will show up and that is what I would use but I was just trying to work with what Steve has on the layout now in the most economical way.
Tony
https://ozfreemo.com
|
Thankyou for the feed back and I may well switch to track current sensing for block occupancy as the IR sensors haven't cost a great deal and can be used for other applications on the setup.? However before I do that? I was wondering if there is any merit in my current thoughts and how easy could it be scaled up?
Two sensors are at the start of Block A,? ?pseudo sensor PS1? and IR sensor S1, ?the Block occupancy is set by PS1. The loco passes S1 which via scripting sets PS1 ACTIVE and thus Block A occupied and even though S1 goes INACTIVE as the loco passes it, ?PS1 is still Active because of the script until the loco passes the exit sensor S2 at the end of Block A at which point the script is triggered making PS1 INACTIVE and thus Block A unoccupied, this way the block a stays occupied until the exit sensor is triggered,? it could even be possible to cater for the fact as the loco passes S2 it will go from INACTIVE to ACTIVE back to INACTIVE but it only sets PS1 to INACTIVE when S2 finally goes INACTIVE.
I'm not sure how this could be applied to several blocks and how complcated the script gets, i've been looking through the samples scripts at CombineSensors.py and similar to get some feel for how it could done, but if there's a flaw in what i am thinking then no point,. Also figuring out what happens in reverse direction etc may need to be worked on at some point.
Thanks Steve
|
Steve,
One problem I see with holding the block as occupied via scripts is that if the train parked in a siding or reverses out of the block then the system will still report the block as occupied. If current detectors are used then whatever method the train leaves the block (even via the 0-5-0 hand from the sky) it will clear the occupancy. The case of "leaving" via a siding happens when the point is switched back to the mainline and therefore the detection not passed to the block via a switch under the point.
Tony
https://ozfreemo.com
|
I think the occupancy and direction problem will get more and more difficult the more you analyze it.
Latching block A occupied with PS1 fixes the problem of S1 being momentary, not staying occupied as the loco or train clears.
One immediate issue is that when the loco reaches S2, the rest of the train still is in Block A. That's not when you want the block status to change to clear.
Also, you are mentally using the fact you know which way the train will be moving. When a train reaches S2, you'd set PS2 and clear PS1. But, in the real world one sensor becoming active only means the loco is there, not which way it's going. For trains going the other direction, the opposite is true. So, if you know where the train began, and which way it's going, the logic works. But, if the train reverses direction you probably couldn't be certain until it passes two sensors going the opposite direction.
I spent a lot of time long ago trying to solve the apparently simple problem of making certain of which direction a train was moving by when it tripped photodetectors. It's hard to make that completely reliable, let alone build occupancy and signalling systems that work properly relying on those signals.
Say we start up with no train information, and S2 becomes active. Is that a train in Block A moving into Block B, or one in B moving into A? No way to tell, so set both blocks' status as occupied. When S1 at the far end of Block A, or S3 at the far end of Block B senses that train, then we can tell its direction, but only if our train was sensed, not another.
Even with one train, if using a closed loop of track, there must be more than two blocks and sensors for direction to be determined. Otherwise, S1 and S2 sensing the loco (or train) will be the same pattern for the train in either direction.
It also seems to me that two IR detectors are needed between trains to be able to keep track of them separately. If there is only one, then if either train reaches it, there is no way to tell them apart from a single long train, or which train moved, and in which direction.
Implementing the logic is easier now, as it's practical to use software now, not hardware. But, the basic challenges posed by using
momentary indications of position to derive direction, occupancy, and
signal aspect remain.
Don Weigt
|
I used the track sensor (magnetic sensors in the track) idea because I wanted to start simple and not need to cut the track to create sections. I use the sensor at the start of each section to trigger the section occupied and then the sensor at the end of the section to trigger it unoccupied. Of course the length of the train is still in the section so I compensate by adding a delay to releasing the section as unoccupied. This is another compromise since it has to allow for the longest slowest train and I think I went for 20 or 30 seconds. The positive side was that the sensors were cheap and a single 16 way sensor input board from NCE senses all of the sensors and passes them back to JMRI. The sensors operate 4 aspect led signals and the final sensor as the train leaves the layout triggers a series of timers for 'virtual sections' that allow the signals on the layout to step back to green.
|
Dave,
I can see how that would work, if you know train direction. Do trains run only one direction on this track? Or, are their directions found some other way, for example by monitoring polarity if using DC track power, not DCC.
Don Weigt
|
Maybe borrowing from the prototype might help. As I understand it, some
country's prototype railroads use optic sensors. Here a sensor spot is
really two sensors very close together. The result is that it knows which
direction (and speed) the train is passing. It then is doing an axle
counting to tell if a train has finished passing or not. So if 50 axles
passed into a block, it doesn't consider the block empty until 50 have left.
These might not be just optic sensors but what I read said it was a place on
the track to determine when the block was clear or not by doing the axle
counting.
The worst case to figure out is when a train stops over the sensor spot,
then the train goes into reverse. Give it some thought and you would see
getting it right every time is not simple.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
|
Hi There,
What I am about to suggest to probably far too software intensive.
Let us assume that there can be no train or at most one train in any block.
Is it possible to determine the speed and direction of train?.
If "yes" would the following work?
Let us assume that we know that there is a train in block B that is called TrainID.
We can easily determine that if TrainID is moving forward, it will enter Block A.
We can easily determine that if TrainID is moving backward , it will enter Block C.
If we monitor the speed and direction of TrainID and see that it is going forward, we can determine that when TrainID is no longer detected in Block B, it must be in Block A, as verified by the Block Occupancy detectors for Block A and Block B.
If we know the speed of TrainID and the length of Block A and the time it entered Block A, it can be determined when TrainID will leave Block A and enter Block Z.
Is this too software intensive?
Stephen.
toggle quoted message
Show quoted text
-----Original Message----- From: Ken Cameron Sent: Tuesday, June 4, 2019 8:58 PM To: [email protected]Subject: Re: [jmriusers] IR Block Occupancy Sensors - Entrance and Exit Maybe borrowing from the prototype might help. As I understand it, some country's prototype railroads use optic sensors. Here a sensor spot is really two sensors very close together. The result is that it knows which direction (and speed) the train is passing. It then is doing an axle counting to tell if a train has finished passing or not. So if 50 axles passed into a block, it doesn't consider the block empty until 50 have left. These might not be just optic sensors but what I read said it was a place on the track to determine when the block was clear or not by doing the axle counting. The worst case to figure out is when a train stops over the sensor spot, then the train goes into reverse. Give it some thought and you would see getting it right every time is not simple. -Ken Cameron, Member JMRI Dev Team www.jmri.org www.fingerlakeslivesteamers.org www.cnymod.com www.syracusemodelrr.org
|
Hi Stephen,
This is not a million miles away from what I am planning to do. So I hope it's not going to be software-intensive, and I think it won't be. Determining speed and direction are both not going to be trivial. For the former, there will need to be calibration (I plan to make an automatic calibration process that will measure speed through a block at every speed step and in both directions, kept in a configuration table, or a number of configuration tables) and for the latter at some point someone will have to tell the software which side of the engine is facing forward - ther's no getting around that unless the software is going to be allowed to tentatively move an engine until it hits the next block - which I am not willing to do.
Plenty of issues to resolve after that: coping with momentum settings, with changes over time (short term: engine warming up, long term: engine becoming older) and probably loads more that I'm not yet aware of, but I'm hoping it'll work within certain tolerances.
I will get the speed and direction information from sniffing the DCC track signal, so non-DCC throttles will not pose a problem.
Wouter
Hi There,
What I am about to suggest to probably far too software intensive.
Let us assume that there can be no train or at most one train in any block.
Is it possible to determine the speed and direction of train?.
If "yes" would the following work?
Let us assume that we know that there is a? train in block B that is called
TrainID.
We can easily determine that if TrainID is moving forward, it will enter
Block A.
We can easily determine that if TrainID is moving backward , it will enter
Block C.
If we monitor the speed and direction of TrainID and see that it is going
forward, we can determine that when TrainID is no longer detected in Block
B, it must be in Block A, as verified by the Block Occupancy detectors for
Block A and Block B.
If we know the speed of TrainID and the length of Block A and the time it
entered Block A, it can be determined when TrainID will leave Block A and
enter Block Z.
Is this too software intensive?
Stephen.
-----Original Message-----
From: Ken Cameron
Sent: Tuesday, June 4, 2019 8:58 PM
To: [email protected]
Subject: Re: [jmriusers] IR Block Occupancy Sensors - Entrance and Exit
Maybe borrowing from the prototype might help. As I understand it, some
country's prototype railroads use optic sensors. Here a sensor spot is
really two sensors very close together. The result is that it knows which
direction (and speed) the train is passing. It then is doing an axle
counting to tell if a train has finished passing or not. So if 50 axles
passed into a block, it doesn't consider the block empty until 50 have left.
These might not be just optic sensors but what I read said it was a place on
the track to determine when the block was clear or not by doing the axle
counting.
The worst case to figure out is when a train stops over the sensor spot,
then the train goes into reverse. Give it some thought and you would see
getting it right every time is not simple.
-Ken Cameron, Member JMRI Dev Team
|
That¡¯s not hard. It¡¯s already in the JMRI block tracking. It follows a single mainline train well. But it¡¯s not always sufficient for more complicated things without lots of detected blocks. For example, if a train enters block A or C from some _other_ block, you¡¯ll incorrectly move TrainID. You have to have at least _two_ blocks between trains. You also need to have all spurs detected (or a train will disappear and it¡¯s tracking lost), have to have blocks shorter than whatever following length your trains have (and some trains really do tuck right up behind others), etc Mostly, it¡¯s a matter of thinking through how complicated you want the automated tracking to be. Bob On Jun 5, 2019, at 12:03 AM, Stephen Grant Brown <steve.brown_nbn@...> wrote:
Hi There,
What I am about to suggest to probably far too software intensive.
Let us assume that there can be no train or at most one train in any block.
Is it possible to determine the speed and direction of train?.
If "yes" would the following work?
Let us assume that we know that there is a train in block B that is called TrainID.
We can easily determine that if TrainID is moving forward, it will enter Block A.
We can easily determine that if TrainID is moving backward , it will enter Block C.
If we monitor the speed and direction of TrainID and see that it is going forward, we can determine that when TrainID is no longer detected in Block B, it must be in Block A, as verified by the Block Occupancy detectors for Block A and Block B.
If we know the speed of TrainID and the length of Block A and the time it entered Block A, it can be determined when TrainID will leave Block A and enter Block Z.
Is this too software intensive?
Stephen.
-----Original Message----- From: Ken Cameron
Sent: Tuesday, June 4, 2019 8:58 PM
To: [email protected]
Subject: Re: [jmriusers] IR Block Occupancy Sensors - Entrance and Exit
Maybe borrowing from the prototype might help. As I understand it, some
country's prototype railroads use optic sensors. Here a sensor spot is
really two sensors very close together. The result is that it knows which
direction (and speed) the train is passing. It then is doing an axle
counting to tell if a train has finished passing or not. So if 50 axles
passed into a block, it doesn't consider the block empty until 50 have left.
These might not be just optic sensors but what I read said it was a place on
the track to determine when the block was clear or not by doing the axle
counting.
The worst case to figure out is when a train stops over the sensor spot,
then the train goes into reverse. Give it some thought and you would see
getting it right every time is not simple.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
-- Bob Jacobsen rgj1927@...
|
Hi Don,
You are quite right that I do not know train direction. There are two main lines with loops and the signalling is predominantly single direction. There are some areas like station approaches where I have crossovers where the sensors lock out large non-directional blocks to prevent collisions but once the train is into a platform and has cleared the block the expectation is that it then sets off down the line in the usual direction!
Dave
|
Bob Jacobsen
Ken Cameron