Forums Forums Traffic Signals Intergreens

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #3216
    Anonymous
    Inactive

    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.

    #3215
    robertma
    Participant

    Hi Jo
    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 M

    #3213
    Anonymous
    Inactive

    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.

    #3212
    Anonymous
    Inactive

    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.

    #3211
    robertma
    Participant

    Hi Jo

    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.

    #3210
    Anonymous
    Inactive

    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.

    #3209
    David Hughes
    Participant

    Have you had any feedback on this Jo?

    #1030
    Anonymous
    Inactive

    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!

Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.