Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Motioneye on Zero W very unreliable #1908

Open
Clubeddie opened this issue May 4, 2019 · 25 comments
Open

Motioneye on Zero W very unreliable #1908

Clubeddie opened this issue May 4, 2019 · 25 comments

Comments

@Clubeddie
Copy link

Preliminary Docs

I confirm that I have read the CONTRIBUTING guide before opening this issue.

I confirm that I have read the FAQ before opening this issue.

motionEyeOS Version

I am running motionEyeOS version:

motionEye Version | 0.40rc5
Motion Version | 4.2.2
OS Version | motionEyeOS 20190413

Board Model

I am using the following board/model: Raspberry Pi Zero W

Camera

I am using the following type of camera: (choose from V4L2, MMAL, Network Camera, Fast Network Camera and Simple MJPEG Camera).

My camera model is: Raspberry PI Cam NoIr (v2)

Network Connection

My motionEyeOS unit is connected to the network via:
WiFi

Peripherals

I am using the following peripherals that I consider relevant to this issue:

Connected to SMB share synology
Configured Surveillance station to

Log Files

I consider the following log files relevant to this issue:

boot (1).log
dmesg (1).log
motioneye (2).log
messages (3).log
motion (2).log

I noticed that my installation is very unreliable. The connection is dropped every few minutes, reconnected itself after a couple of minutes. The web interface is sometimes not responding anymore (the software is running as i can see on my surveillance station the stream is active also i can ping the raspberry). After a couple of minutes i can connect.

The preview suddenly stops and after a while it shows the preview again.

I disconnected the SMB because i thought this could be the issue, but no results so far. Maybe someone can find something in the log files what is the issue?

I also tried several SD cards and tried several installations. Stil same issue.
use an original raspberry pi power supply, output 2,5A.

Hope someone can figured it out, because i love the software and possibilities!

@duckietm
Copy link

duckietm commented May 4, 2019

Hello Clubeddie,

Can you test this using the 20190119 build and see if it then works fine ?

@Clubeddie
Copy link
Author

Tried your suggestion, Installled version 20190119 on a new SD card, minimal configuration. No extra's configured like SMB, motion, or whatsoever. No i don't have short interuptions, it looks like crashes. After failing connection no more reconnection.

Log files from this session attached
dmesg (2).log
dmesg (1).log
boot (1).log
messages (1).log
motioneye (1).log
motion (1).log

@duckietm
Copy link

duckietm commented May 4, 2019

have a look at this post : raspberrypi/linux#1754

as i see the following error in the dmesg : bcm2835-v4l2: timed out waiting for frame completion

@Clubeddie
Copy link
Author

Checked the post, was already starting with configure a rPI-3 to test if camera was defect. Not yet ready with configuration.

I read about
sudo chmod 777 /var/lib/motion/

Only, there is no /var/lib/motion folder available on my setup, so i cannot chmod this and this out.

@ccrisan
Copy link
Collaborator

ccrisan commented May 4, 2019

@Clubeddie relevant error in your case is contained by dmesg.log:

[  160.845099] Unable to handle kernel paging request at virtual address ffffff68
[  160.845119] pgd = d5750000
[  160.845125] [ffffff68] *pgd=17ffa861, *pte=00000000, *ppte=00000000
[  160.845146] Internal error: Oops: 837 [#1] ARM
[  160.846679] Modules linked in: arc4 ecb md4 md5 hmac nls_utf8 cifs ipv6 spidev brcmfmac brcmutil snd_soc_bcm2835_i2s regmap_mmio cfg80211 snd_soc_core rfkill snd_compress snd_bcm2835(C) snd_pcm_dmaengine snd_pcm snd_timer i2c_bcm2835 snd spi_bcm2835 uio_pdrv_genirq uio fixed i2c_dev i2c_bcm2708 bcm2835_v4l2(C) v4l2_common videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev media
[  160.854903] CPU: 0 PID: 1223 Comm: st0 Tainted: G         C      4.14.98 #1
[  160.856762] Hardware name: BCM2835
[  160.858618] task: d5c36120 task.stack: d57ac000
[  160.860550] PC is at ret_fast_syscall+0x14/0x28
[  160.862678] LR is at 0x0
[  160.864729] pc : [<c000fd94>]    lr : [<00000000>]    psr: 60000013
[  160.866770] sp : d57adfa8  ip : d57adbfc  fp : 00000000
[  160.868815] r10: 00000000  r9 : d57ac000  r8 : c000ff24
[  160.870981] r7 : 000000a8  r6 : 002e3d88  r5 : aff4fd24  r4 : 00000000
[  160.873665] r3 : 00000000  r2 : 00000001  r1 : aff4fca7  r0 : 00000001
[  160.875736] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[  160.877882] Control: 00c5387d  Table: 15750008  DAC: 00000055
[  160.880009] Process st0 (pid: 1223, stack limit = 0xd57ac188)
[  160.882572] Stack: (0xd57adfa8 to 0xd57ae000)
[  160.885459] dfa0:                   00000000 aff4fd24 aff4fca0 00000001 ffffffff 00000006
[  160.889742] dfc0: 00000000 aff4fd24 002e3d88 000000a8 002bfd58 00000000 ffffffff aff4fca0
[  160.893873] dfe0: 00000000 aff4fc70 aff4fc4c b5772f44 80000010 aff4fca0 00000000 00000000
[  160.897954] Code: f10c0080 e5992008 e35204bf 1b000de1 (e5991000) 
[  160.900220] ---[ end trace 06ca00233bdb6c30 ]---

If the problem is still there with previous versions, it may be a hardware fault.

@Clubeddie
Copy link
Author

Clubeddie commented May 4, 2019

Tested it on rpi3 for several hours, no issue at all. So camera and sd card and power supply and software are not the issues i guess. Probaly hardware as you mentioned. Any idea how to test/check this?

Will testsome more with rpi3 and also zero again.

Edit: founded this thread on another forum, sounds exactly zs my issue. Check hardware tomorrow and test the boot config adjustment if fhis works?
https://github.com/raspberrypi/linux/issues/2555

@ccrisan
Copy link
Collaborator

ccrisan commented May 4, 2019

@Clubeddie interesting. If you find a boot option that improves stability on the Zero W, I'd be happy to test it myself as well and add it to the next build.

@Clubeddie
Copy link
Author

Clubeddie commented May 5, 2019

Because of child project (butterfly's at home) i may not use the camera on the moment of my kids :-) :-) :-) [:-)()...] http://vlinders.huizeveen.nl:8080 i now have plugged the Zero W in, without the camera module, and the connection is still stable. I will test the zero W today without camera module if the connection is stable without streaming. Then later on i will change the boot option with camera module. Hopefully this is be the issue. I will let you now asap.

@Clubeddie
Copy link
Author

Do a little test, installed a Zero W with Raspbian Stretch Lite, attached a raspberry pi camera v1, and stream with raspivid to youtube. On basic setup the stream crashed every several minutes and must be manual restarted.

Then i added the next two lines to to config.txt
over_voltage=4
force_turbo=1

No with exactly the same setup i stream several hours to youtube with raspivid without any issues.

As soon i can check the setup with motioneyeos and noir camera i will make the same adjustments. But for now the adjustment on config.txt has a succesfull result sofar.

@jasaw
Copy link
Collaborator

jasaw commented May 6, 2019

If a stock standard pi zero W requires overvoltage and force turbo, that suggests your pi is broken.

@user9023523
Copy link

user9023523 commented May 6, 2019

@jasaw I think he's using overclocking presets. Remember, the overclocking presets will actually underclock/undervolt a Zero W. If you don't have a golden board going from over_voltage 6 to 4 will probably cause CPU failures at 1000 MHz. If he's using them it's highly likely that his preset is just unstable at the given voltage. #1194

See the table above the force_turbo header. The default settings are 1000 MHz @ OV6. https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.md

The high preset in MotionEye is 950 MHz @ OV0, a difference of 0.15v. Undervolting the board that much won't kill it but obviously nothing's going to work.

In my experience anyways most W's go to 1.1 GHz @ OV8 but this voids the warranty. OV simultaneously drives CPU/GPU voltage so the 8 setting creates huge overclocking headroom but boards tend to have high GPU clock variability. With OV8 GPU_freq (all GPU related clocks) can usually be set somewhere between 450-500 MHz and this also improves CPU performance.

core_freq: Frequency of the GPU processor core in MHz. It has an impact on CPU performance because it drives the L2 cache and memory bus. Note that the L2 cache benefits only the Pi Zero/Pi Zero W and Pi 1, but there is a small benefit for SDRAM on the Pi 2/Pi 3.

I've found an appreciable FPS benefit on all the boards I've overclocked but Zero W boards benefit the most since they never thermal throttle and I'm not exaggerating.

How does warranty work for a board so cheap anyways?

@Clubeddie
Copy link
Author

With the adjustment
over_voltage=4
force_turbo=1

I stream over 48 hours constantly without crashes. Temperature on the board is continue around the 50 degrees celcius.

Is there a way to check the voltage of the board through the command line? To check if the board is broken as @jasaw is suggesting.

I cannot test this settings with motioneye as early as this weekend.

@QSKONE
Copy link

QSKONE commented May 14, 2019

What is a solution to a problem? I run for testing Motioneyeos lite with new power supply and new sd card. Only stream 800x600 is ON. Motion , emails , movies , samba is OFF. System just crashed few times per day.
dmesg.log
boot.log
messages.log
motioneye.log
motion.log

Raspberry PI Zero W
motionEye Version | 0.40
Motion Version | 4.2.2
OS Version | motionEyeOS 20190427

@jasaw
Copy link
Collaborator

jasaw commented May 15, 2019

@Clubeddie
Setting over_voltage=4 actually under-volts the board as pointed out by @user9023523. The default is over_voltage=6 for Pi Zero according to documentation.
If your Pi Zero is running stable with under-volt, that might point to a heat related problem? Maybe your Pi Zero W was getting too hot, which causes it to crash. I noticed all my Pi Zero W boards run pretty hot at stock configuration.
You could also try disabling HDMI (if you don't need it) to reduce temperature. Add tvservice -o to /data/etc/userinit.sh.
You shouldn't need force_turbo.

@jasaw
Copy link
Collaborator

jasaw commented May 15, 2019

@QSKONE From your logs, I see a lot of this:

May 14 11:51:17 meye-c7eeaa54 user.notice motioneye: not responding for 120 seconds, rebooting

Your motioneye process was not responding. I don't know why.

@jasaw
Copy link
Collaborator

jasaw commented Jun 12, 2019

This issue is probably the same as #1945

@ccrisan
Copy link
Collaborator

ccrisan commented Jul 15, 2019

Could you please try the latest nightly dev build and see if the WiFi problem persists?

@FloRup
Copy link

FloRup commented Aug 8, 2019

Could you please try the latest nightly dev build and see if the WiFi problem persists?

Am I blind or is there no image for the raspberry pi zero?

Edit: Ok I think the image for the raspberry 1 is also for the zero

@ccrisan
Copy link
Collaborator

ccrisan commented Aug 11, 2019

@FloRup as indicated in Supported Devices, models Zero and Zero W work with the image for the Raspberry Pi 1 models. There has never been a Zero-specific OS image.

@avanc
Copy link

avanc commented Sep 30, 2019

I had also problems with my Raspberry Pi Zero W. I could solve it with arm_freq=950.

Interestingly, I have also the revision with H* as mentioned in raspberrypi/linux#2555 (comment)

@avanc
Copy link

avanc commented Sep 30, 2019

@jasaw

You could also try disabling HDMI (if you don't need it) to reduce temperature. Add tvservice -o to /data/etc/userinit.sh.

The file /data/etc/userinit.sh does not exist. Can I just create it and make it executable?

@jasaw
Copy link
Collaborator

jasaw commented Oct 1, 2019

@avanc Yes, just create that file and put the tvservice -o line in there.

@ccrisan You previously added some service that supposedly works around this bad RPi Zero hardware issue (similar to how Raspbian does it), but seems like it's still happening? Is it worth just setting the core frequency to 950MHz by default?

@avanc
Copy link

avanc commented Oct 1, 2019

I was to early: I get the same freezes also with 950MHz, although the Raspi runs for several hours.

I'll try 600MHz...

@jasaw
Copy link
Collaborator

jasaw commented Oct 4, 2019

@avanc Even if it runs at 600MHz, it's still not working as advertised, i.e. broken product. I would return it to the seller.

@avanc
Copy link

avanc commented Nov 3, 2019

And it does not work reliable at 600MHz :-(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

8 participants