• Using MLX90614 temperature sensor

    Moved i2c temperature pin
    20
    1
    0 Votes
    20 Posts
    6k Views
    S
    I have been working on the mlx90614 for the last day and can communicate successfully with 6 on an I2C bus, but am am receiving an overwhelming number of errors. Right now it hovers around 25% of attempts to read the sensor. I believe it could be related to a timing issue of the I2C communication in micropython. Some errors are the result of a bad read of the I2C data, which can be verified if you read the PEC byte after the data. The third byte should come back with a crc-8 value, but sometimes it comes back as 0xFF, as if the mlx90614 is one byte ahead of the lopy. The other error is related to readfrom_mem function in i2c. This error produces an OSError exception about every one in four attempts. In other mlx90614 libraries the flow for reading bytes is slightly more complicated, for example // send the slave address then the command and set any // error status bits returned by the write Wire.beginTransmission(_addr); Wire.write(cmd); _rwError |= (1 << Wire.endTransmission(false)) >> 1; // experimentally determined delay to prevent read errors // (manufacturer's data sheet has left something out) delayMicroseconds(30); // resend slave address then get the 3 returned bytes Wire.requestFrom(_addr, (uint8_t)3); // data is returned as 2 bytes little endian val = Wire.read(); val |= Wire.read() << 8; // read the PEC (CRC-8 of all bytes) _pec = Wire.read(); return val; Is there anyway to imitate this flow control? Using the above style code on an Arduino I receive no errors and do not have to do coding gymnastics to control errors.
  • Freeze trying to open file on SD

    micropython thread threading lopy sdcard
    6
    0 Votes
    6 Posts
    2k Views
    A
    UP Anybody got a clue?
  • 0 Votes
    1 Posts
    874 Views
    No one has replied
  • Random number generator

    Moved random lopy
    4
    0 Votes
    4 Posts
    2k Views
    T
    @livius Thanks I tried it and it works. I had another question if you could give some suggestion. I have been trying to take the last four bytes of the mac address as source and destination address to send data from one Lopy to a second LoPy. I created a package header as the following: _LORA_PKG_FORMAT = "LL%ds" _LORA_ACK_FORMAT = "LLB" SRC_MAC_ADDR = ubinascii.hexlify(lora.mac().strip()[-4:]) Destination address DEST_MAC_ADDR = b'9cc15603' ** pkg = struct.pack(_LORA_PKG_FORMAT, DEST_MAC_ADDR, SRC_MAC_ADDR, msg) But when I try running it complains saying ValueError: unsupported format for the line with **. what do you think I am doing wrong?
  • Basic Package header

    Moved lora bytes lopys
    1
    0 Votes
    1 Posts
    754 Views
    No one has replied
  • 0 Votes
    3 Posts
    1k Views
    L
    @RobTuDelft Thanks you for confirmation and the link
  • Mac address format to hexadecimal

    Moved mac address lopy lora mode lora bytes
    4
    1
    0 Votes
    4 Posts
    2k Views
    robert-hhR
    @timeb The data returned by lora.mac() is a 8 byte binary quantity in a bytes object. These bytes may not be printable chars. And it is also not an integer, and can therefore not be printed with the %x specifier. If you want to print it in a ASCII-Hex representation, you have to convert that with ubinascii.hexlify, like you did, and print it with the %s specifier. The results is a string. How you further proceed with the data, is up to you. You could use the binary object or the string.
  • How to read firmware version

    Moved fw version firmware
    3
    0 Votes
    3 Posts
    2k Views
    R
    os.uname()
  • Bookmarks on this forum

    Moved forum
    3
    0 Votes
    3 Posts
    1k Views
    L
    @mmarkvoort Thanks a lot!
  • News about PyByte ?

    Moved pybyte
    1
    1 Votes
    1 Posts
    732 Views
    No one has replied
  • WiPy / SiPy deep sleep interrupt wake

    interrupt deepsleep
    2
    0 Votes
    2 Posts
    1k Views
    L
    @helloerror It is still not supported and also read here about power consumption in old modules new one are not affected https://forum.pycom.io/topic/1022/root-causes-of-high-deep-sleep-current/19
  • BLE multi-connection

    Moved ble multiconnectio wipy
    1
    2 Votes
    1 Posts
    864 Views
    No one has replied
  • Release notes for 1.6.10/1.6.11

    Moved release notes
    3
    1 Votes
    3 Posts
    1k Views
    D
    Please see the latest release notes here: https://forum.pycom.io/topic/1024/new-firmware-release-1-6-12-b1
  • WiPy LoPy I2C with ATMEGA

    Moved wipy 2.0 lopy i2c
    5
    0 Votes
    5 Posts
    2k Views
    C
    @jmarcelino Cables are really very short. Can't be shorter... Baud rate is 100000. I tried different baud rates but this value seems to be the correct. I will try the pullup resistors today
  • Advertising data from 1 lopy, trying to read from another one

    Moved bluetooth
    4
    0 Votes
    4 Posts
    1k Views
    M
    High, Can I have some news about my issue? I don't know how to solve it !
  • Micropython Probe Requests

    micropython probe request
    1
    0 Votes
    1 Posts
    795 Views
    No one has replied
  • Too many [Errno 113] EHOSTUNREACH

    Moved wipy 2.0 lopy socket
    1
    1 Votes
    1 Posts
    1k Views
    No one has replied
  • External SD Card with WiPy - LoPy etc

    Moved wipy2.0 lopy sdcard expansionboard
    2
    0 Votes
    2 Posts
    1k Views
    J
    @constantinos The pins are on the Expansion Board data sheet: https://docs.pycom.io/pycom_esp32/_downloads/exp_v03_pinout_v13.pdf SD_CMD, SD_DATA, SD_CLK
  • Wired Py?

    Moved hardware
    3
    0 Votes
    3 Posts
    2k Views
    J
    The ESP32 chip supports native Ethernet through an external RMII chip (for example the popular LAN8720, breakouts can be bought for $3) I tested this on another ESP32 about a week ago! Works really well. https://twitter.com/jmarcelino/status/843256681807171585 It is still only on the C-interface side (ESP-IDF) but no doubt it will be ported to MicroPython. There is an issue with pin assignments on the LoPy and SiPy, one of the necessary (non-changeable) pins conflicts with the communications chip in those. But should work on the WiPy. (I don't have one to test...) That said if you have PoE it generally means you have ample power available so the board would be competing with the $10 Pis / OpenWRT etc of this world which offer full-fat Python at very high speeds and ample interfacing options. Other than being smaller I don't see how a major market could come from competing with those.
  • This topic is deleted!

    Moved
    1
    0 Votes
    1 Posts
    6 Views
    No one has replied

Pycom on Twitter