Announcement

Collapse
No announcement yet.

Sparkfun Z-X Sensor and reading I2C with non sequential register addresses

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    It feels as though what you describe might the case.

    However, the kids felt that checking that tmpByte.length was non-zero would have the same effect as checking DAV. Because, we reasoned, the getReadBuffer or something else hidden from us was handling polling and whatnot.

    Run time for the state machine is pretty wildly variable; it's spending various time in states waiting for a non-zero-lengthed byte. Thus suggesting, at least, that values are only returned when there is something new to return. ???

    More problematic was the sensor itself though. Really does not seem like it's tuned to work with the kinds of materials we'd expect to see in a challenge. Seems very optimized as what it is branded as: a gesture sensor you move a hand over.

    It really would be nice if some future SDK had a way to pass a matrix of register addresses to read to some tidy method the kids could utilize. I'm not sure how much more time they'll spend messing with the ZX sensor, but I suspect there are other sensors that have various non-sequential registers they may like to try.

    - Z

    Comment


    • #32
      One more question: how are you guys posting those nice organized code snippets that appear inside a scrollable window? My simple cut and paste produced that un-tabbed mess above...

      Comment


      • #33
        Originally posted by zain View Post
        It feels as though what you describe might the case.

        However, the kids felt that checking that tmpByte.length was non-zero would have the same effect as checking DAV. Because, we reasoned, the getReadBuffer or something else hidden from us was handling polling and whatnot.

        Run time for the state machine is pretty wildly variable; it's spending various time in states waiting for a non-zero-lengthed byte. Thus suggesting, at least, that values are only returned when there is something new to return. ???

        More problematic was the sensor itself though. Really does not seem like it's tuned to work with the kinds of materials we'd expect to see in a challenge. Seems very optimized as what it is branded as: a gesture sensor you move a hand over.

        It really would be nice if some future SDK had a way to pass a matrix of register addresses to read to some tidy method the kids could utilize. I'm not sure how much more time they'll spend messing with the ZX sensor, but I suspect there are other sensors that have various non-sequential registers they may like to try.

        - Z
        In theory, I shouldn't need to check zero length. I am expecting if I got a buffer back from getReadBuffer, it should contain valid data. But reality shows it's not true. That's why I check for zero length. I think it is either a problem in the Qualcomm I2c support code or the device itself. I am leaning more towards a bug in the Qualcomm code. Regardless, I think you still need to check the DAV bit because that's in the device spec. If the DAV bit is not set, you may still read a value but who know what it is. It could be garbage or the last reading. In my opinion, the device needs time to acquire the data and recognize gestures. So once it finished that process, it will put the data into the registers and set the DAV bit. Chances are if the DAV bit is not set, you get the data from the previous data point.
        Regarding the reliability of the X and Z data, we gave up on that sensor too because like I said in my previous posts, the data seems a little random. We wrote that code mainly for fun and to test our library's I2C support infrastructure. I am not seeing ourselves using that sensor in competition.
        Regardless posting code in a nice format, you need to surround your code with the code tag (i.e. prefix the code with open square bracket then the word code then close square bracket and then suffix the code with open square bracket, slash code, close square bracket).
        Alternatively, an easier way is to click the "Go Advance" button on the reply and it will show you more buttons, one of which is the "#" button that will insert the code tags for you.

        Comment


        • #34
          Originally posted by zain View Post
          It really would be nice if some future SDK had a way to pass a matrix of register addresses to read to some tidy method the kids could utilize.
          Qualcomm classes/APIs provide a lot of basic functionality but generally is not very friendly in my opinion. Fortunately, Java's OOP architecture allows you to extend/modify their functionality to be a lot more friendly. That's one of the reasons behind our library. Another reason is to provide an abstraction layer so that FTC and FRC code looks very similar.

          Comment

          Working...
          X