Sensor states and synchronous design confusion RRS feed

  • Question

  • Hi there. As mentioned in another thread, I'm working with Long on the Geosense software-only sensor (geolocation). (We've been trying to connect with the Sensor team, but had to fallback to using the forums.)

    So, we can't seem to agree on the usage of SENSOR_STATE_INITIALIZING.

    In one proposed (re)design, we simply don't use the INITIALIZING state. This makes boot up easy -- we simply return NOT_AVAILABLE until we get data into our internal cache, then change state to READY. Subsequent calls to GetData would result in whatever is in cache (and signal the worker thread to update whenever possible).

    In another, we use the state but block until something is available.

    What is Microsoft proposed use of the INITIALIZING state? MSDN states we should use INITIALIZING to indicate we're trying to get a fix, or in our case looking for radios/wifi. But INITIALIZING comes with the requirement that we have a valid data report on hand, which isn't the case at boot (meaning we'd have to not use this state at boot).

    What does the Location/Sensor platform do when it receives a request and the sensor is in an INITIALIZING state? Would it behave any differently (and if so, how) if our sensor simply omitted this state altogether. If preferred we use, how do we use this state in the synchronous request scenario?

    A Sensor state flowchart/diagram would be perfect for the aforelinked MSDN page.
    Friday, March 12, 2010 1:01 PM


All replies