@optech Just step line by line through the script, it's not that complex, it's just copying files to our packing folder in the structure we need the files placed on the target system. Then running a few command to create the files required for an opkg repository and signing them using usign.
The structure of the directories is the key to the building of the package. The cool parts are in the CONTROL directory where there are 4 files that get executed depending on what opkg is doing, ie before installing your package (CONTROL/preinst), after installing your package (CONTROL/postinst), before removing your package (CONTROL/prerm) and after removing your package (CONTROL/postrm)
The final ipk will be in the "repo" directory
@Zakrze We've released an update to the TauLidarCamera python module with a fix for this issue.
Can you try updating and trying again? Instructions can be found in the updated troubleshooting guide.
Let me know how it goes!
Wanted to weigh in here:
That's right, we did some experimenting with and testing of OpenWRT 21.02 earlier this year. Hence the openwrt-21.02-dev branch on the OnionIoT/source repo.
There's no plans to make an official release in the near term. As @crispyoz pointed out, there's no official release from OpenWRT yet - we'll see how they fare and adjust accordingly.
That being said, there IS an experimental openwrt-21.02 image available for the Omega2+.
The image can be found here: http://repo.onioniot.com/omega2/images/beta/
It was built using the code in the OnionIoT/source repo openwrt-21.02 branch, following the instructions in the README in the onion directory
We don't recommend using this image for any production environment, just for testing for now.
What currently works
Using the open source mt76 image
May need to install appropriate kmod-fs-* packages
Need to install kmod-i2c-mt7628 package
Can be installed from the OpenWRT package repo
What does not work or is not included
All Onion packages
Have not ported any of the Onion OpenWRT packages to 21.02
Not included in the OpenWRT package repos, not yet being built by us
If you end up trying it out, let us know how it goes! We're interested in your feedback and to hear what should be done/added/changed next!
@kevin-lefrank posted on GitHub but posting here for visibility and future reference:
Looks like your issues are caused by a combo of two problems:
A bug causing the bad frame ignored error - https://github.com/OnionIoT/tau-lidar-camera/issues/14
A USB issue with Thinkpad laptops - https://github.com/OnionIoT/tau-lidar-camera/issues/16
A fix for the bad frame ignored error has been fixed and released in TauLidarCamera v0.0.4. You can update by running python -m pip install TauLidarCamera --upgrade. (Just make sure v0.0.4 is installed).
And the USB issue can be resolved by updating your Thinkpad's BIOS.
Please try that out and let us know how it goes.
I've run into issues when using the Tau Camera, where can I get help?
Start by going over our Troubleshooting Guide. It covers common errors and issues.
If you can't find a solution for your problem there, post on the Onion Community Forum and we'll do our best to help out.
I'm not sure if this belongs here, but I don't know where else to ask. (If not, please redirect me to a more relevant subreddit) I needed to make something on a 3D printer that the engineering shop has at my school, so I decided to try my hand at TurboCAD. I found an old v12 Deluxe edition in my house, so I figured that was all I would need to print the part. After a few hours of working on it (it's not terribly complex, but I had to feel my way through as I had never done anything CAD related before), I had a finished product.
@Russell-Pirie "...will they all fit??...." You'd need to be specific as to what they are and how they are configured in order to answer that.
I'm not sure you need to rewrite a bluetooth driver, most users would utilise "Bluez" package for bluetooth, perhaps take a look at that package and see if it meets your requirements, here's a link to the package:
I flash my devices using a bash script (well ash), it just connects to the device(s) using ipv6, uploads the firmware and then ssh's into the device and execute the firmware upgrade. You could tweak my script a bit to make it handle multiple devices at once. I did about 40 of them today using my exiting script, one by one while I was eating lunch and watching the news.
My script is here:
The other option is to boot into u-boot and flash from USB.
I'm a newer user to Arch and Linux in general. I've got a pretty robust installation running on my computer with Fluxbox, PCManFM and SLiM for the graphical side (if these matter). Everything's running pretty well at the moment except I'd like to be able to auto-mount USB storage devices. Without adding the udev rule as mentioned here (because I would like the mounting to persist through a terminal window popping open), what's the best way to have things auto-mount like they do in Ubuntu or Windows? By this I mean I would plug in a USB flash drive and it'd automatically be mounted to somewhere like /media/<device name>/ and any user (or the one running x? or something) would have permissions to view/edit/execute.
@crispyoz I hadn't considered that, but it seems that getting the display connected to the Omega LTE might be the better option, if it's possible: the Omega LTE is infinitely more compact than most LTE options I've seen and having all of the network info available to software is a huge boon. From what I can tell the Omega Dash only differs in that it has the display adapter built-in, so if I can get the display connected to the Omega LTE and use the Dash drivers or OS, the LTE should be able to drive the display.
Although I'm now tempted to grab the Dash and just plug in my display instead of the 3.2" and see if it works.
@Ioannis this thread may be of use to you:
The data sheet doesn't tell us a whole lot, have you contacted their support email address and asked them to provide further details?
Looks like your connection to Community was lost, please wait while we try to reconnect.