The Omega2 doesn't have bluetooth support built in. If you'd like to talk CANbus you could add a USB to CAN dongle. If you'd like to talk bluetooth do you know of those dongles do bluetooth or ble?

There are some ble dongles but ble5 is hard to come by. The nrf52840 is a great chip for ble5 and can do so at a lower cost than a usb dongle.

Concept would be a board with:

• Omega2s+
• nrf52840
• battery charging support (like the onion lte board)
• omega headers (same as lte board)

Thoughts, interest? If there is interest I’d look at a crowdsupply project.

Regards,
Chris

Hi @Gerhard-Bertelsmann.

Does the PIC approach support regular Canbus or does it also support CANFD?

I'm looking to see what the best non-usb approach might be for adding can bus support to an Omega2 system. It looks like SPI is out due to the full duplex issue, serial via slcan looks like an option as does the PIC approach as well? For CANFD I was wondering if using a SAM21 micro as the controller could work but I'm not sure if slcan supports canfd (or if it has to).

Or is the usb approach really the only way to go with canfd on the Omega2?

Regards,
Chris

I'd like to generate a feed for some custom packages I'm using on the omega2+, like Onion has done for http://repo.onioniot.com/omega2/packages/onion.

How is this custom feed generated?

The usb option could work but I'm interested in pcb integrated options for mechanical and cost savings. Something that could live on other busses like SPI, I2C etc but that would have integrated support in the kernel through bluez.

Any recommendations?

Onion publishes https://hub.docker.com/r/onion/omega2-source but this container hasn't been updated for several months, it looks like prior to the upgrade to LEDE 18.

Any plans to publish a newer container? I'd rebuild the container here but I can't find the originating Dockerfile so maybe it was built manually??

Hello.

Is there a way or a recommended way to interact with ubus from outside of the omega? I'd like to make some calls to ubus and report results from a web call. Is there a way in place right now to do that? If not, recommendations on how to do that?

@zedf yep, building on windows works but it sounds like Linux and macOS it doesn’t. I thought docker was supposed to be the same across all OSes? There must be some differences. Would be great if it worked on mac and Linux.

I was able to build the image, I think with the docker container on OS X after disabling mosquitto or something like that. At least I’m almost certain I could build a full image...

Hi @György-Farkas.

Same SD card works fine on another Omega2+ so I'm less likely to think its the card. Supply voltage looks good as well, 3.45v (need to adjust regulator resistors to bring that down to 3.3v) That's a good path to check and more data sheet driven then my approach of swapping the cards and performing a functional check.

I saw that diagram with those pinouts as well but isn't EPHY_APGIO_AIO_EN set in software and not affected by the boot pins?

After a few hours of experimenting here the issue turned out to be a relatively strong pulldown on GPIO45. This was affecting a boot pin. Looking at http://plan44.ch/downloads/Onion-Omega2-Pinout-annotated.png and the MT7688 data sheet though it isn't clear exactly what the issue is. Measuring the module itself there is a 4.7k pullup to 3.3V on that pin, so no need for external strapping. Pulling that pin down would appear to be enabling JTAG mode, page 33 of the MT7688 data sheet fyi.

JTAG pins look entirely separate from SD interface pins though so maybe I'm close on the bootstrap pin issue but off on the effect? I still can't figure out why everything would boot fine if that GPIO45 was strapped low (overriding the 4.7k pullup) but just the SD card wouldn't be working......

HI @György-Farkas.

Looking at the Omega2S-reference schematic it looks like the SD card pins are entirely separate pins but its tough to know for certain without the Omega2 module schematic I think.

I'm using a lot of header pins (not the SPI ones related to the internal memory) but if none are related to the microSD then I'm left with an issue with this particular Omega2+ module, a firmware difference (both are upgraded to latest, I upgraded the working module once it worked thinking maybe it would break after the upgrade), or some pin configuration that isn't documented that I'm missing.... any ideas?

The symptom I'm seeing is the kernel driver is reporting that there is no support for the card's volts. This same card works fine in my other Omega2 (not mounted on my custom PCB).

4.901374] MTK MSDC device init.
[    4.944622] mtk-sd: MediaTek MT6575 MSDC Driver
[    4.954890] sdhci: Secure Digital Host Controller Interface driver
[    4.961182] sdhci: Copyright(c) Pierre Ossman
[    4.966206] mtk-sd 10130000.sdhci: no support for card's volts
[    4.972137] mmc0: error -22 whilst initialising SDIO card
[    4.978735] sdhci-pltfm: SDHCI platform and OF driver helper
[    4.989205] usbcore: registered new interface driver usb-storage
[    4.998530] mtk-sd 10130000.sdhci: no support for card's volts
[    5.004520] mmc0: error -22 whilst initialising MMC card
[    5.010722] kmodloader: done loading kernel modules from /etc/modules-boot.d/*
[    5.020594] init: - preinit -
[    5.254946] mtk-sd 10130000.sdhci: no support for card's volts
[    5.260882] mmc0: error -22 whilst initialising SDIO card
[    5.356121] mtk-sd 10130000.sdhci: no support for card's volts
[    5.362058] mmc0: error -22 whilst initialising MMC card
[    5.600540] mtk-sd 10130000.sdhci: no support for card's volts
[    5.606528] mmc0: error -22 whilst initialising SDIO card
[    5.626395] mtk-sd 10130000.sdhci: no support for card's volts
[    5.632331] mmc0: error -22 whilst initialising MMC card