• omz

    @JonB Thanks for the reminder, should be fixed now.

    posted in General Discussion read more
  • omz

    In your pyui file (example.pyui here), add a custom view, and set its "Custom View Class" field to SceneView. Also set the name to something unique (I've used "sceneview" in the code below), so you can get a reference to the view more easily, after loading the UI. Load the UI, and set the scene attribute of the custom view. That's pretty much it.

    from scene import *
    import ui
    
    class MyScene (Scene):
        def setup(self):
            pass
            # Define your scene like usual...
    
    v = ui.load_view('example.pyui')
    v['sceneview'].scene = MyScene()
    v.present('fullscreen')
    

    posted in Pythonista read more
  • omz

    @ProgrammingGo said:

    Do you mean 0b00000010, bit 8 '0' and bit '9'is 1 would correspond to 8G?

    No, I think it would correspond to 4G. If I'm not mistaken, 8G would be 0b00000001 (I assume the last bit is bit 8, and the second-to-last is bit 9).

    posted in Pythonista read more
  • omz

    The first byte contains bit 0 to bit 7, and the second byte contains bit 8 to bit 15.

    Just 10 of those 16 bits are actually used for the configuration, but you can only send entire bytes.

    When the second byte is 0b00000010, bit 8 would be 0 and bit 9 would be 1, which should correspond to a scale of 4G. If you want 16G, you should set both bits to 1 (11 is 3 in binary notation).

    posted in Pythonista read more
  • omz

    I think the bit order in the config bytes I suggested may be wrong, though I'm not really sure why you don't get any data at all...

    Otherwise, I might have an explanation for the behavior you described in your first post:

    chr(0x011F) evaluates to the unicode string 'ğ'. Encoding this as a byte string with the default utf-8 encoding, this results in b'\xc4\x9f'. The first byte (0xc4) in binary notation would be 0b11000100. If we now assume that Bit 0 in the Wiki refers to the last (least significant) bit, and not the first (as I had assumed), those 8 bits represent the following configuration:

    1 1 0 0 0 1 0 0
      ^ ^ ^ ^ ^ ^ ^
      | | | | | | |
      | | | | | | Gyro Z [❌]
      | | | | | Gyro Y [❌]
      | | | | Gyro X [✅]
      | | | Accel. Z [❌]
      | | Accel. Y [❌]
      | Accel. X [❌]
      Magnetometer (all axes) [✅]
    

    Given this configuration, the output you're getting (-393, 0, 0, 0, 0, 0, 268, -341, 582) seems to make sense, as the non-zero values correspond to the things that are enabled.

    Anyway, could you try using bytes([0b00111111, 0b00000010]) for the configuration?

    Also, perhaps you could implement did_write_value, if you haven't already, to check if there are errors.

    posted in Pythonista read more
  • omz

    @ProgrammingGo I think I wrote the sample code in the cb module docs when Pythonista didn't support Python 3 yet, and for single byte values, it should work fine anyway, but you're dealing with more than one byte for setting the configuration.

    Another question why bytes(0b11111100, 0b01000000) ? Is only 0b11111100 not enough?

    Possibly, but you wanted to set bit 9 to 1 (setting the accelerometer range, I think?), so you'd need the second byte for that. I'm also not sure how the SensorTag behaves when you set the config to only one byte, as the wiki mentions that it's a two byte (16 bit) value.

    Since I used the bytes notation I am not able to get any output of the values. The callback did_update_value is not called since I changed chr() to bytes in configuration characterisitc.

    Maybe you need to either read the characteristic explicitly (via the cb.Peripheral.read_characteristic_value method), or perhaps write 0x0001 for the "Notification" characteristic (UUID 2902), as mentioned in the wiki?

    Did you check in your previous code if the c parameter in did_update_value was actually the characteristic you were expecting?

    posted in Pythonista read more
  • omz

    The value for the configuration characteristic seems wrong to me. chr(0x011F) returns a unicode string, and you really want a byte string there.

    I think (can't try this here without the hardware) bytes([0b11111100, 0b01000000]) should be correct for the bits you want to set (as the individual bits are relevant here, I think it makes sense to use binary notation instead of hex here).

    posted in Pythonista read more
  • omz

    img = ui.Image('test.jpg')

    posted in Pythonista read more
  • omz

    Yes, that's possible, here's an example:

    import ui
    
    img = ui.Image('test:Lenna') # Just load a sample image here...
    
    # Save as PNG:
    with open('test.png', 'wb') as f:
        f.write(img.to_png())
    
    # Save as JPEG:
    with open('test.jpg', 'wb') as f:
        quality = 0.9 # From 0.0 (more compression) to 1.0 (better quality)
        f.write(img.to_jpeg(quality))
    

    posted in Pythonista read more
  • omz

    @ProgrammingGo

    In the if statement there is something which is a bit unclear. Does it mean that if p.name is available and SensorTag is in P.name is clear, but why not self.peripheral?

    The example connects to just one SensorTag, and that SensorTag is stored in the self.peripheral attribute, so the if not self.peripheral condition means "ignore this if we already found it". As you want to connect to multiple SensorTags, you'd have to handle this differently, of course.

    @ccc's code from earlier should be a good starting point. You might just need to use UUIDs instead of names, if all your SensorTags have the same name (not sure if they do generally).

    posted in Pythonista read more

Internal error.

Oops! Looks like something went wrong!