Nice! This can indeed save some dev time!
@Lazar-Demin : I'm for PoE as well. Lot's of my applications need connectivity without having power availability. It's much easier to install a simple RJ45 cable than a new wall socket...
@crispyoz : I have a PoE board (with a bunch of other features you probably do not need: RTCC, Touch screen interface, RFID reader etc...), don't hesitate to get in touch if you're interested. Other features can be stripped away.
Hi Community,
I've been developing a new device embedding an Onion Omega 2S+ with the need of a small (3,5") touch screen. First, I had a look at the Omega Dash (which seems to be the first choice as many functions are already integrated). However, I ran into 2 main issues:
I had a look at several posts from this forum, and noticed many people where looking for touch solutions. However, I didn't find anything regarding capacitive touch....
I therefore went on the hunt of a capacitive touch solution which I could handle with the Omega. Requirements are as follow:
After a lot (I really mean a lot) of research, I finally tested a solution from 4D Systems: https://4dsystems.com.au/products/. This Australian company offers quite a lot of different screens and controllers. I finally chose a 3,5" touch screen which can be driven by their diablo 16 controller: https://www.mouser.fr/ProductDetail/4D-Systems/DIABLO16?qs=0lQeLiL1qybL%2FKx9ffo26w%3D%3D
This solution needs quite a bit of custom PCB design, but as my device anyway needs a custom PCB, it wasn't a real hastle integrating the diablo 16 onto the board. The nice thing here is, all the heavy lifting is done by the controller, which directly interfaces with the Omega with a simple serial connection. So once the hardware is done, just get out the Diablo 16 documentation and start writting serial commands....nice..... 
Here are my conclusions to this project:
Advantages:
Disadvantages:
Not sure this will meet the requirements for other projects, however for my purposes, this was a great solution enabling a really nice looking device, development simplicity at a reasonable cost. I tried to attach a small video of the screen interaction, this however failed in this post...sorry.
My device as such bundles some other features:
I'm a little short on time, but I'll try to post some more infos regarding these other features.
Best,
Hi Community,
Just an update on this. Thanks to @crispyoz , I had A LOT of really interesting documentation to read. So this is how I would summarize my investigations:
Point 1 was that after dumping a 2,967MB file into /root, the du -h command showed a total additional storage usage of 5,8MB (3MB in /root and 2,9MB in /overlay). As I understand, the overlay FS is a union of 2 filesystems. In OpenWRT the two filesystems will be /rom containing the rootfs and /overlay which will be the actual storage space. As in my understanding /root is uncluded in /overlay, this explains why the du command counts the used storage as double.
Point 2 was that the df command however only returns an additional storage usage of 0.8MB after dumping my 2.967MB file. I couldn't find any explanation for this in the OpenWRT specific flash layout. However, some dark memory popped into my mind regarding JFFS2 and compression. Following Stackoverflow post seems to confirm my thoughts:
https://stackoverflow.com/questions/31622039/jffs2-filesystem-storage-usage-inconsistent-with-real-file-size
To conclude:
1 - It seems du and df commands do not calculate storage the same way. du seems to add the individual file sizes, whereas df seems to take into account the "real" used flash storage taking into account JFFS2 compression algorithms.
2- This makes it quite difficult to evaluate remaining storage. For my projects I think I'll go over to practical use cases with max file sizes (+ some safety) in order to make sure my applications do not run out of storage.
Open Points:
1 - Does anybody know where I could find the Omega specific flash layout (just out of curiosity in order to cross check it with the standard OpenWRT flash layout found here: https://openwrt.org/docs/techref/flash.layout#explanations)?
2 - I think the Omega Flash in of NOR type. I however was unable to find any official datasheet confirming this. Does anyone have this kind of ressource?
Hi Community,
I was wondering how to create custom apps for OnionOS. Except for some dead links here (https://onion.io/the-onion-app-sdk-is-here/), I haven't found any kind of documentation. I'd like to create a simple administration app on a browser available GUI. I'd like to use the OnionOS environnement. Else I'd have to build a full server in Django or something (don't know if Django even runs on the Omega).
Thanks,
MK
@Lazar-Demin : Thanks a lot. It took us some time to finalize this dev :-). Correct: The MicroSD only is accessed by the display controller. However, over serial commands from the Omega to the display controller, you can interact with the display itself. I'm pretty fond of this, as just dumping some serial commands really is easy.
I therefore have two MicroSD slots on the board. One is reserved for the display controller and only accessed by it. The second one is connected to the Omega2S+ and serves as memory extension.
If this can be an interesting solution for you, don't hesitate E-mailing me. I'll send you a proto board.
Best,
MK
Nice! This can indeed save some dev time!
@Lazar-Demin : I'm for PoE as well. Lot's of my applications need connectivity without having power availability. It's much easier to install a simple RJ45 cable than a new wall socket...
@crispyoz : I have a PoE board (with a bunch of other features you probably do not need: RTCC, Touch screen interface, RFID reader etc...), don't hesitate to get in touch if you're interested. Other features can be stripped away.
Hi Community,
Has anybody figured out if it is possible to grand the access to the OnionOS to another user (other than root)?
Thanks,
MK
@crispyoz : Sorry for the delay. Haven't been very active on the forum for a few weeks. We did integrate a POE hardware into our device which can be found here: https://community.onion.io/topic/5050/omega-and-capacitive-touch-screen
So, it's not just a POE dock. It's a complete PCB integrating a bunch of other functions. But still....POE works on it.
Moreover, here is an older post:
https://community.onion.io/topic/2968/omega-poe-dock
@Kazooie : Hadn't time top check the datasheet in depth, but you should indeed get values up to 4096 if Vin = Vdd (check p.13 of datasheet).
What is you Vdd and Vin to wich you get 252 (which is a very strange value by the way).
You could connect the analog input to you Vdd. The converter should output 4096.
@Lazar-Demin : Thanks a lot. It took us some time to finalize this dev :-). Correct: The MicroSD only is accessed by the display controller. However, over serial commands from the Omega to the display controller, you can interact with the display itself. I'm pretty fond of this, as just dumping some serial commands really is easy.
I therefore have two MicroSD slots on the board. One is reserved for the display controller and only accessed by it. The second one is connected to the Omega2S+ and serves as memory extension.
If this can be an interesting solution for you, don't hesitate E-mailing me. I'll send you a proto board.
Best,
MK
Hi Community,
I've been developing a new device embedding an Onion Omega 2S+ with the need of a small (3,5") touch screen. First, I had a look at the Omega Dash (which seems to be the first choice as many functions are already integrated). However, I ran into 2 main issues:
I had a look at several posts from this forum, and noticed many people where looking for touch solutions. However, I didn't find anything regarding capacitive touch....
I therefore went on the hunt of a capacitive touch solution which I could handle with the Omega. Requirements are as follow:
After a lot (I really mean a lot) of research, I finally tested a solution from 4D Systems: https://4dsystems.com.au/products/. This Australian company offers quite a lot of different screens and controllers. I finally chose a 3,5" touch screen which can be driven by their diablo 16 controller: https://www.mouser.fr/ProductDetail/4D-Systems/DIABLO16?qs=0lQeLiL1qybL%2FKx9ffo26w%3D%3D
This solution needs quite a bit of custom PCB design, but as my device anyway needs a custom PCB, it wasn't a real hastle integrating the diablo 16 onto the board. The nice thing here is, all the heavy lifting is done by the controller, which directly interfaces with the Omega with a simple serial connection. So once the hardware is done, just get out the Diablo 16 documentation and start writting serial commands....nice.....
Here are my conclusions to this project:
Advantages:
Disadvantages:
Not sure this will meet the requirements for other projects, however for my purposes, this was a great solution enabling a really nice looking device, development simplicity at a reasonable cost. I tried to attach a small video of the screen interaction, this however failed in this post...sorry.
My device as such bundles some other features:
I'm a little short on time, but I'll try to post some more infos regarding these other features.
Best,
Hi Community,
Just an update on this. Thanks to @crispyoz , I had A LOT of really interesting documentation to read. So this is how I would summarize my investigations:
Point 1 was that after dumping a 2,967MB file into /root, the du -h command showed a total additional storage usage of 5,8MB (3MB in /root and 2,9MB in /overlay). As I understand, the overlay FS is a union of 2 filesystems. In OpenWRT the two filesystems will be /rom containing the rootfs and /overlay which will be the actual storage space. As in my understanding /root is uncluded in /overlay, this explains why the du command counts the used storage as double.
Point 2 was that the df command however only returns an additional storage usage of 0.8MB after dumping my 2.967MB file. I couldn't find any explanation for this in the OpenWRT specific flash layout. However, some dark memory popped into my mind regarding JFFS2 and compression. Following Stackoverflow post seems to confirm my thoughts:
https://stackoverflow.com/questions/31622039/jffs2-filesystem-storage-usage-inconsistent-with-real-file-size
To conclude:
1 - It seems du and df commands do not calculate storage the same way. du seems to add the individual file sizes, whereas df seems to take into account the "real" used flash storage taking into account JFFS2 compression algorithms.
2- This makes it quite difficult to evaluate remaining storage. For my projects I think I'll go over to practical use cases with max file sizes (+ some safety) in order to make sure my applications do not run out of storage.
Open Points:
1 - Does anybody know where I could find the Omega specific flash layout (just out of curiosity in order to cross check it with the standard OpenWRT flash layout found here: https://openwrt.org/docs/techref/flash.layout#explanations)?
2 - I think the Omega Flash in of NOR type. I however was unable to find any official datasheet confirming this. Does anyone have this kind of ressource?
@SpiderKenny
Thanks for your reply.
My app will write quite a lot. The device is intended to collect external data (every minute or so) and transfer the data to an MQTT broker. However, the device will always keep an internal Database (sqlite) in order to backup the sent data. Database will be about 2MB at it's maximum size.
Not sure the internal flash really is an issue with frequent writings. I always understood sd cards are more prone to errors over time. My device has a built in sd card slot if needed. If really really necessary I could therefore switch to the sd card. However, if possible, I'd like to avoid this.
@crispyoz
Thanks for the link. This is exactly what I was looking for. I'll dive into this content.