​ ​ ​ ​ TLV493D-A1B6 3D Magnetic Sensor - Page 2
Page 2 of 6 FirstFirst 1 2 3 4 ... LastLast
Results 11 to 20 of 58

Thread: TLV493D-A1B6 3D Magnetic Sensor

  1. #11
    Senior Member
    Join Date
    Apr 2012
    Location
    Cēsis, Latvia
    Posts
    852

    Default

    Ok, I'm now looking into this again. One interesting thing I can find is the parity bit that Alan has mentioned earlier. How do I "calculate" if the sum of "all 32 bits of write registers is odd"? And do I understand correctly, this bit is used to force it odd? I.e. it would have to be set for even sum of all the other bits or clear for odd?


    Thank you for your time,

    Edmunds

  2. #12
    Senior Member
    Join Date
    Feb 2012
    Location
    London
    Posts
    2,869

    Default

    Hi,

    Yes, the parity bit simply determines whether the total number of bits set is Even or Odd. Odd parity has the advantage that it will catch "hardware-type" errors such as all zeros or all ones (255). But then it only gives a 50% chance of catching more complex (multi-bit) errors; a parity byte or CRC would be much better,

    There might be faster X2 commands, but calculation is not difficult anyway, because much can be done in parallel. First combine the 4 bytes (or two words first, but it's hardly worth the added complication) and then combine the nibbles, pairs of bits and finally single bits. Not fully tested:

    Code:
    b1 = b1 xor b2 xor b3 xor b4
    b1 = b1 * 16 xor b1     ; Or could /16 (or >> 4 with X2) but * faster
    b1 = b1 * 4 xor b1
    b1 = b1 + b1 xor b1
    oddparity = not bit15      ; If parity bit originally was 0
    Cheers, Alan.

  3. #13
    Senior Member
    Join Date
    Apr 2012
    Location
    Cēsis, Latvia
    Posts
    852

    Default

    Are there any known I2C bit-banging examples I could borrow? I searched the forum for a couple of phrases and read through a lot of interesting posts, but none to provide exactly that.


    Thank you for your time,

    Edmunds

  4. #14
    Senior Member
    Join Date
    Feb 2012
    Location
    London
    Posts
    2,869

    Default

    Hi,

    I2C bit-banging code was suggested by Technical in post #2 of this thread but I didn't investigate it in detail because the HI2C method is about 300 times faster.

    Cheers, Alan.

  5. #15
    Technical Support
    Join Date
    Jan 1970
    Location
    UK
    Posts
    24,335

    Default

    You don't need any code to determine the parity bit. When configuring the MOD1 and MOD2 registers you will know exactly which bits you want to set and clear and can determine the parity bit simply by counting how many bits are set. Or simply try it with 0 or 1 and see which works.

  6. #16
    Senior Member
    Join Date
    Apr 2012
    Location
    Cēsis, Latvia
    Posts
    852

    Default

    Quote Originally Posted by hippy View Post
    You don't need any code to determine the parity bit. When configuring the MOD1 and MOD2 registers you will know exactly which bits you want to set and clear and can determine the parity bit simply by counting how many bits are set. Or simply try it with 0 or 1 and see which works.
    Thanks, hippy. I agree I don't 'need' to do it, just trying to plug all the holes. As far as I understand, parity bit is not my problem, as long as I'm getting 255's from the sensor. Pretty much out of options by now, will take the last look with the logic analyser. If that does not show anything unexpected, "someday maybe drawer" it is.


    Edmunds

  7. #17
    Senior Member
    Join Date
    Feb 2012
    Location
    London
    Posts
    2,869

    Default

    Hi,

    Yes I agree that you can't do much if the I2C only ever returns 255s; but are you sure you've tried every possible slave address? Also, the User Manual does contain quite a lot of "small print" and in particular are you sure that you've complied with this requirement from page 12 of the Data Sheet ? :

    "...the chip does not use a classic (and current consuming) reset concept. The implemented reset focus is on ensuring a proper supply for the ADC operation only (so it inhibits the ADC reliably until the sensor supply is high enough). Thus, the sensor rely on a proper supply ramp incl. 3.7mA current consumption during power-on to ensure it is initialized correctly, typically a monotonic rise of Vdd from zero to 3.3V within less than 10μs and without over/undershoots larger than 300mV. If such a supply can not be provided, the I2C reset feature of the sensor shall be used by the μC after power-up."

    Cheers, Alan.

  8. #18
    Senior Member
    Join Date
    Apr 2012
    Location
    Cēsis, Latvia
    Posts
    852

    Default

    Dear Alan,

    What you are referring to, could be one small spark of hope.

    I checked the rise time for high B.0, which is how I have been powering the sensor and it is about 30us. Clearly, nowhere near 10us required as spotted by you. Now I tried to use the suggested workaround of calling I2C address 0x00 without checking all the relevant data sheets I should have checked first . This did not help at all and somehow seem to have 'hanged' picaxe process on the chip as I do not even get to the 'debug' part of the code. The execution seems to just halt after hi2cmaster, 0x00, i2cslow, i2cbyte.

    Now, either this has to be issued manually i.e. bit-banged or I have to find a way to get the rise time of sub-10us. Probably possible both electronically and software-wise, but I will leave people in other time zones at that for a while, as it is too late for this kind of thing here now .

    Thank you for your input, I at least feel a have some thread to dig now.

    I'm still not entirely sure about the address either, because the only thing logic analyser seems to show ack for is %1010000[0] and not 0x5E. I don't get at this with brainpower to actually collect the proper pictures for now, but the inadequate power supply is the first thing to sort anyway.

    /Edmunds
    Last edited by edmunds; 16-01-2018 at 06:43.

  9. #19
    Technical Support
    Join Date
    Jan 1970
    Location
    UK
    Posts
    24,335

    Default

    As the device is at least acknowledging the initial part of the I2C communications it would seem that it is working, even if not delivering the desired results.

    I think using a $00 device address, bus slew rates, suspecting some sort of inadequate power supply are red herrings and blind alleyways.

    Rather than digging ever deeper into the hole it would be worth posting how your code is now that some of the device's peculiarities have been determined.

  10. #20
    Senior Member
    Join Date
    Apr 2012
    Location
    Cēsis, Latvia
    Posts
    852

    Default

    Quote Originally Posted by hippy View Post
    As the device is at least acknowledging the initial part of the I2C communications it would seem that it is working, even if not delivering the desired results.

    I think using a $00 device address, bus slew rates, suspecting some sort of inadequate power supply are red herrings and blind alleyways.

    Rather than digging ever deeper into the hole it would be worth posting how your code is now that some of the device's peculiarities have been determined.
    Hippy, I don't want any red herrings!
    So, lets try the sensible approach once again and see if something obvious was missed.

    Below is the code I'm using as I2C scanner:

    Code:
    #picaxe 40x2
    
    #no_data
    #no_table
    
    symbol sspbuf = $C9
    
      high B.0 'for magnetic sensor
      high C.4 'for magnetic sensor
      
      pause 5000
      sertxd (cr,lf,"START PROGRAM")
      hi2csetup i2cmaster,2,i2cslow,i2cbyte
      for b2 = %00000010 to %11111110 step 2
        hi2cout [b2],(0)
        peeksfr sspbuf,b0
        if b0 = 0 then
          b0 = b2 / 2
          sertxd (cr,lf,"** i2c response @ [",#bit7,#bit6,#bit5,#bit4,#bit3,#bit2,#bit1,#bit0,"] 0x")
          
          b1 = b0 / 16 + "0"
          if b1 > "9" then
            b1 = b1 + 7
          endif
          sertxd(b1)
          
          b1 = b0 & %00001111 + "0"
          if b1 > "9" then
            b1 = b1 + 7
          endif
          sertxd(b1)
        else
          if b0 <> b2 then
            sertxd (cr,lf,"Something strange happened!")
          endif
        endif
      next
      sertxd (cr,lf,"END PROGRAM")
      end
    This returns:

    I2CTesterPrtSc.JPG

    So far so good.

    /Edmunds

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •