@Flosol The EC-RED certification for the Omega2S & Omega2S+ has been updated with the latest versions of the standards.
Find the updated certificate here: https://github.com/OnionIoT/Omega2/blob/master/Documents/Certification/Omega2S/Omega2S EC-RED Certificate.pdf
And the corresponding test reports here:
https://github.com/OnionIoT/Omega2/tree/master/Documents/Certification/Omega2S/Test Reports
Certification updates for the Omega2 & Omega2+ are in progress.
@JackHulspas Two suggestions from the team:
data_depth member that should be more useful for what you're looking to do. It's a one dimensional array of float32 that holds the raw distance data. It's one dimensional but holds the entire 160*60 frame sequentially, so you may have to do a little transforming.Let us know how it goes!
@Nagarjuna-Reddy Does the Omega2 LTE work as expected when only powered by the battery? Ie the USB cable is unplugged and then the Omega2 LTE is turned on
@Missa Happy you resolved the issue!
We've updated the Troubleshooting Guide to cover this scenario as well!
Let us know what you end up doing with your Tau Camera!
Np!
@tony-ter-neuzen said in FAQ: Is it possible to "clone" the firmware running on an Omega2 device and copy it to other Omega2 units?:
I guess this is just cloning and injecting the overlay into a "fresh" omega right?
The target device can be not "fresh" since this will overwrite the overlay partition (on /dev/mtd3). But just to be safe try to make sure the target device is fresh.
For more info on openwrt flash layout, see this OpenWRT Docs article
@tony-ter-neuzen said in FAQ: Is it possible to "clone" the firmware running on an Omega2 device and copy it to other Omega2 units?:
Are there any concerns about using the same firmware version on both source and target?
You raise a good point! I would recommend making sure you're using the same firmware version on both source and target. I've edited the procedure above to mention this.
This process will only clone the overlay partition, that is, changes you've made to the device. This could potentially cause issues if the packages in the firmware of the target are a different version than on the source.
@Cooper-Chan The memory scenario suggested by @luz is definitely worth investigating.
On the hardware side, I would suggest looking for any stray sources of electromagnetic interference.
There was a post earlier this year about a situation similar to yours - deployed Omega2 units would stop booting after some time because of what looked like corrupted firmware. It turned out a cable connected to the cellular modem in the device was emitting electromagnetic interference that would corrupt the filesystem.
See the original post for more details:
https://community.onion.io/topic/4448/onion-omega-2-jffs2-newly-erased-block-contained-word-0x0-at-offset-0x01180000-warning/
Let us know if that helps!
Yes! The firmware, installed packages, and configuration of a device can be "cloned" and written to other devices.
This method is useful for quickly deploying a fleet of devices for the same application. Ie you have a single device setup and working for the application, and want to quickly get dozens or hundreds more devices up and running doing the same thing. This is an alternative to building your own firmware.
This cloning process serves as a quicker alternative to creating your own firmware from scratch using the build system (https://github.com/OnionIoT/source), which is more work intensive
If a factory restore is triggered on a cloned device, it will revert to the original firmware. Meaning it will look and behave like an Omega device coming from the factory.
cd /mnt/sda1dd if=/dev/mtd3 of=<IMAGE-NAME>.binWe recommend using a version number or a date to easily differentiate the clone images, for example:
dd if=/dev/mtd3 of=/mnt/sda1/firmware-20200308.bin
mtd -r write <IMAGE-NAME>.bin firmwareupdateHostname -fRepeat Step 2 for all devices that you want to clone with the same setup as the original.
@Nagarjuna-Reddy
Please refrain from creating duplicate threads back to back. If you forgot to mention something in your post, feel free to edit it. But please do not make another thread about the same thing.
It's possible that, when you unplug USB power, the instantaneous current demand on the battery power circuit is too high, resulting in the Omega2 LTE restarting.
If you just have a battery connected (no USB power) and use the switch to turn on the Omega2 LTE, does it work normally?
@Rastus Awesome, happy to hear you resolved your issue! I'll add your Jetson setup steps to the FAQ.
I don't foresee any issue with using the Jetson to analyze the data - should be a fun project. Do you have any specific libraries in mind?
Make sure to keep us in the loop as your project progresses, we love robots - especially those that use the Tau Camera 
@Rastus Looks like there's some issue with the websocket that sends the frames from the camera to the browser. Can you post the full program log?
And in the meantime, can you try running the example Python programs? If they run properly, we can rule out any issues with the Tau Camera hardware.
Follow Step 2 in the Getting Started Guide to run the example programs.
The distance.py example is a good place to start.
@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
oniondirectory
We don't recommend using this image for any production environment, just for testing for now.
kmod-fs-* packageskmod-i2c-mt7628 packageIf 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!
@Zakrze Hmm that's pretty odd! One more check before we declare the hardware faulty.
Can you try running the checkCamera.py example program in Mode 2 where you specify the serial port:
python checkCamera.py --port <SERIAL PORT>
More info here: https://github.com/OnionIoT/tau-lidar-camera/tree/master/examples#mode-2---specifying-a-port
@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:
bad frame ignored error - https://github.com/OnionIoT/tau-lidar-camera/issues/14A 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.
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.
@kevin-lefrank My first guess wouldn't be the graphics card since the recordFrames.py program doesn't use OpenCV. Since your older PC works just fine, I think think points to some speed or other issue with the serial port on your main PC.
I responded on GitHub as well, there should be a fix you can test out soon. Will let you know when it's ready!