- This topic has 7 replies, 4 voices, and was last updated 6 years ago by Anonymous.
3rd July 2015 at 7:30 am #3216AnonymousInactive
Ah ha! I thought the hurry call might have something to do with it, but I never thought about the ped crossing.
Thank you very much for taking the time to look through the spec and come back to me and pointing me in the right direction.
Sounds like the best way forward is a new prom and and update the database accordingly.2nd July 2015 at 9:20 pm #3215robertmaParticipant
Thanks for uploading the config. I’ve spotted a couple things which may give you problems.
1. Stages 5 and 6 don’t have any G bits defined, these seem to be related to the firestation hurry call. If the controller goes to these satges, there won’t be any G bits being replied, giving long intergreen errors. Would recommend defining F and G bits for these stages, even though you might not want to force them from UTC, but they will then reply correctly when called.
2. The offset ped is of the puffin type with variable following intergreen. Becuase it is defined as part of a single stream with the main junction, the junction can change stage, run a traffic minimum whilst the puffin clearance is still timing off and the junction is interstage. Thus the UTC server misses the G bit reply for the following stage giving a long intergreen error. I would recommend moving the ped crossing to a separate stream, put a “hold” into sepcial conditioning to make sure it only comes up during stage 2 at the main junction as it does at the moment. For Scoot / UTC you only need to control the main junction and the ped crossing will follow correctly using the hold link.
Hope this helps.
Robert M29th June 2015 at 1:43 pm #3213AnonymousInactive
Hi Robert, one config. I’ve been on holiday the last couple of weeks, but one of my colleagues said the junction was showing similar dodgy timings.5th June 2015 at 2:22 pm #3212AnonymousInactive
How do you know the intergreens have gone up? Is this happening on site or just being reported by SCOOT? if it’s just a SCOOT report then it’s something to do with your G bit generation. I would suspect another stage is running in the “intergreen” I suspect what you are seeing is, termination of one stage- IG-stage with dodgy G bit – intergreen – next stage.3rd June 2015 at 10:06 pm #3211robertmaParticipant
Sounds like there are a few different problems here. For the Scoot stage drifting up, you need to fix a length for the stage without a Scoot loop. I would set the stage min and max to the fixed value you want. Also on the network data, there is an option to mark a stage as fixed length, this should be selected for the stage in question. Finally check none of the links have ticked the fixed length stage as being associated with the link, note the fixed length stage doesn’t require a link to be defined (we run an Imtech server but I assume options would be similar for both types).
As to the unpredictable intergreens, sounds like there is something funny in the controller config. We had a couple of sites that gave similar errors, one reverted to all-red but there was no all-red stage G-bit, so this gave long intergreeen errors, or no road green confirm errors. You mentioned demand dependent stages, but are all your phases type 0’s? Sometimes setting demand dependent phase types can give issues if all phases need to be at ROW before the G-bit replies. If you can post the controller config, I could have a look and advise further.3rd June 2015 at 8:33 am #3210AnonymousInactive
Hi David. Nothing as yet. I passed it on to our utc/scoot provider yesterday as the junction has gone a bit daft again this week, so just waiting for some feedback.3rd June 2015 at 8:25 am #3209David HughesParticipant
Have you had any feedback on this Jo?25th May 2015 at 12:25 pm #1030AnonymousInactive
I seem to be getting some very long intergreens at one of our sites here. This normally happens when the junction drops off scoot control after the peaks and reverts to VA. The intergreens can end up in the 20s, 30s and sometimes 40s, then everything settles down apart from the odd blip.
There are two demand dependant stages at this junction, one of which does not have a scoot loop attached to it, only a stop line presence loop. Normally, it only runs its minimum stage length when under scoot control. This morning, however, it’s decided it wants to run whatever it wants – 40 odd seconds at one point! It’s a site exit so there are about seven or eight vehicles in the queue at most. The min and max times in the controller for this stage are 7 seconds and 12 seconds. The minimum and maximum in the scoot database are 15 seconds and 120 seconds. I’ve always thought that because there is no scoot loop on this link, it wouldn’t “see” the traffic on it and therefore only run its minimum, as it has been.
Don’t know what has upset it over the weekend, but advice as to where I could start looking would be appreciated!
- You must be logged in to reply to this topic.