I supply power via the dock's GND and 5V pins. I now tried to power it from USB socket, and the behaviour is the same — device heats up, power LED does not go on.

With or without the Omega2+ plugged in, the voltage across GND and 3.3V pins is lingering around 3.28V.

My project was working just fine, but then my Omega2+ suddenly halted. When I checked the device, it was pretty hot, so I assume the poweoff was some kind of automatic safety measure.

So I switched it off (the expansion dock switch), waited for the device to cool off, switched on again, the amber LED went on, then blinking while booting, then stopped blinking, just like normal boot sequence. But the device nevertheless started to heat up again, and after short time the power LED went off.

So I plugged in my multimeter to measure the current draw, and it shows 0.4A at this emergency-poweroff state, 0A when the expansion dock switch is off, and 1A when I switch it back on. Now the onboard power LED does not go on anymore.

The power source is 5V switched-mode power supply, there's no reason to think that it's not stable.

I my Omega2+ dead? Is there any way to find out for sure? A very disappointing and bitter end to a project that was supposed to go live for Christmas.

Ok, I was avoiding the oupgrade -f because of dire warnings about unstable versions.

@Lazar-Demin said in Omega2+ SPI in Python3:

We haven't done a good job of publicizing that so far. Where can we post about it so that more users are aware of the change?

I think this would be a very appropriate place: https://docs.onion.io/omega2-docs/using-the-omega-updating.html. If I prefer to stick with stable firmware version, perhaps I could just update the repo URL.

I am running 0.2.2

# oupgrade
> Device Firmware Version: 0.2.2 b200
> Checking latest version online...
url: https://api.onioniot.com/firmware/omega2p/stable
> Repo Firmware Version: 0.2.2 b200
> Comparing version numbers
> Device firmware is up to date!

I am not sure how I can upgrade to v0.3.0, if oupgrade does not propose it. The image repo http://repo.onion.io/omega2/images/ also does not contain any v0.3.0 images.

Ok, so I thought it's a good time to move my project to Python3. It's an APA201 RGB LED strip controller, written in Python.

Official doc https://docs.onion.io/omega2-docs/communicating-with-spi-devices.html encourages to use spidev module. The readme of the official github repo of spidev https://github.com/OnionIoT/python-spidev says that I should install python3-spidev package.

However, if I write opkg install python3-spidev in the command line, all I get is this error:

Unknown package 'python3-spidev'.
Collected errors:
 * opkg_install_cmd: Cannot install package python3-spidev.

What am I missing? Can the python3-spidev package be installed in another way?

P.S. Yes, I did the opkg update, of course.

Yeah... you're right:

# nano -V
 GNU nano, version 2.7.5
 (C) 1999..2016 Free Software Foundation, Inc.
 (C) 2014..2017 the contributors to nano
 Email: nano@nano-editor.org	Web: https://nano-editor.org/
 Compiled options: --enable-tiny --disable-nls --disable-utf8

I just installed it from an opkg package. Is the only way to fix this is to build it locally?

I also tried very hard to get I2S sound working on Omega2, but could not. So I gave up and moved my project to Raspberry Pi Zero.

When I log in over ssh (from Ubuntu), I can write unicode symbols like ĀĒŠ just fine. Also, if I cat a utf-8 encoded file that contains such characters, it is outputed correctly.
However, if I open the nano editor and attempt to enter a Unicode character, it is not displayed corretly. In fact, two or even three characters are outputed to the screen, and If I attempt to enter some other characters on the same row beyond the place where I inserted the Unicode char, then the cursor is displayed not exactly where the new characters appear, it's messed up. If I save the file and cat it out in console, the Unicode character is outputed correctly. I assume that those several characters is utf-8-encoded representation of that character, for some reason not processed correctly by nano.
What could be done to fix this?

P.S. I just checked the file opens nicely in the Onion console editor app, all Unicode characters displayed correctly. However, if I use the http Onion console terminal app, the behavior is exactly the same: can write the characters in the shell, can cat a file with those characters, but entering and displaying them in nano does not work.

@luz Thank you, I finally solved this! Ordered bunch of 74HC125D chips, there are four gates per chip. I pass through the gate only the CLK line, assuming that any MOSI traffic will be ignored by the strip when there is no CLK. So far so good, it seems that both flash memory (device 0), and LED strip are working just fine.