Recent pages

Edit
page

New
page

Print
page
Page last modified 18:43, 13 Mar 2012 by beth
0
Page Notifications Off
Was this page helpful?
Yes No
radR project > Features and Plugins > Resumption of radR play when a radar re-awakens

Resumption of radR play when a radar re-awakens

From $1

    Table of contents
    No headers

    If a radar stops providing signals to the digitizing card, the data source's driver plugin generates an error and radR processing pauses.  As of radRstablewindows_2011_07_29, radR can resume processing from the paused state if it notices that a live data source once again has data available.  This is controlled by the value of a new configuration variable (found in main/radR.conf.R):

    ## Automatically resume from paused state?
## For live sources, we can choose to resume from a paused state if we notice the
## source is generating data again.  This variable says whether to do so:

resume.from.paused.state = TRUE

    The value of this variable is available at runtime in RSS$resume.from.paused.state.  If radR is paused, if the source is live, and if end.of.data(RSS$source) is TRUE, radR calls functions on the new ONRESUME_PLAY hook, with a single numeric parameter indicating how many seconds have elapsed since the last scan was processed.  Normally,  an ONRESUME_PLAY hook function (if one is defined) should return FALSE.  If an ONRESUME_PLAY hook function returns TRUE, radR will not resume play.  This behaviour can be used to prevent resume from pause under undesirable circumstances; for example if the digitizing card + radar combination produces a noisy "data available signal".

    In order for resume from pause to work, the digitizing card's driver must be able to accurately report whether or not the radar is active.  Support for this feature is summarized in the following table:

     

    Plugin can end.of.data() notice resumption of radar activity? notes
    xir3000 Yes:  end.of.data() returns true only if trigger, bearing pulse/ACP, and heading/ARP are all present, according to XIR3000 firmware.

    Bridgemaster Decca E:  the way we have connected this radar, a trigger and azimuth signal continue to be generated even when the radar is on standy and not rotating.  Therefore, it is loss of the heading signal that first pauses radR when the radar is put on standby.  The xir3000's method of detecting presence of a heading pulse (aka SHM) has some problems:

    • after putting the radar on standby, it might take several sweep intervals before the heading signal is reported to be missing by the xir3000 firmware/software
    • after detecting a loss of SHM, the SHM is occasionally reported to be available again within a short time interval, even though the radar is stopped.  This does not appear to happen more than a few seconds later, and so a user hook function can be used to "debounce" this signal:
    ## cancel resume from pause (by returning TRUE)
## if we have been paused for less than 15 seconds
rss.add.hook("ONRESUME_PLAY", 
    function(elapsed) return (elapsed < 15)
)
    • this line can be put in the file main/startup.windows.R to be executed each time radR starts.
    • a more complicated hook function could ask radR to restart learning of clutter if the radar has been paused long enough:
    rss.add.hook("ONRESUME_PLAY", 
    function(elapsed) {
        ## cancel resume from pause if we have been 
        ## paused for less than 15 seconds
        if (elapsed < 15)
           return (TRUE)
           
        ## ask for a restart of learning if we have
        ## been paused for more than 2 hours
        if (elapsed > 7200)
           RSS$restart.learning <- TRUE
        
        ## return FALSE just to be sure we don't cancel
        ## the resume from pause
        return (FALSE)
     }
 )
    seascan No: not yet available  
    usrp No: not yet available  
    Was this page helpful?
    Yes No
    Tags: (Edit tags)
    • No tags
    Attach file or image
    Files (0)
     
    Comments (0)

     
    Powered by MindTouch Core