New VIVE user, issue. Need help.
Hi i finally had chance to buy VIVE and so far everything is amazing.
I have problem with DoomVFR.
My PC:
[email protected],5Ghz||
[email protected]||8GBDDR3ram
When i start game everything is butter smooth 90hz then after a while like minute or two suddenly it get VERY choppy and image instantly blurs and looks like 320x240 resolution. At first i thought it was due to performance issues but then i tested it more and it happens regardless of what is happening on screen !
What is even weirder i found "solution", when this happens i press home button then go to "desktop" when i see screen from my TV and then everything goes back to normal home button again and game play butter smooth again... for minute or two and goes back to this ultra choppy 15fps like framerate. Both headset and controllers at the time are very choppy as well.
I also noticed similar thing happens to Fallout 4 VR though it doesn't change resolution.
On other hand Elite:Dangerous doesn't have such problems !
Anyone had such a problem ? Any ideas what is going on ?
_
_
_
_
EDIT: FIGURED IT OUT ! It is some malware crypto miner. IT turns on after about 2-3 minutes and switches off itself when you move mouse or keyboard. Naturally it doesn't know what are vive controllers so it doesn't switch off by moving them. Only when i go to home menu then desktop my controls emulate mouse and then it switches off giving butter smooth performance !
Thanks for help people. Now i will need to reinstall system, as think mint.exe apperently is very tricky to remove.
submitted by
perkel666 to
Vive
[Project] Nuclear Reactor Monitoring System
For my capstone project I built a Farnsworth Fusor. It basically takes 30KV + 2H and outputs 3He + n + energy. As the energy output is in the form of xray and neutron radiation, even with a bit of shielding it can be dangerous. For the computer engineering portion of the project, I built a camera system for watching the window remotely.
This was the 'turn in' portion of my capstone project.
- RPi to powered USB hub
- Powered USB Hub to HDD
- Powered USB Hub to USB camera
- Powered USB Hub to keyboard/mouse (optional)
- RPi to ethernet
- Ethernet to Wireless Router (DD-WRT)
- Router to external monitor and control Computer
- Router bridged to anther network providing Internet access
- RPi to monitor (optional)
- GPIO to vacuum gauge controller (todo)
- GPIO to reference on power supply (todo)
Camera using a freecycle'd Logitech Quickcam Chat, HDD is a cheap Toshiba 500G, a keyboard with built-in trackpad, the router a Linksys that works 100% with DD-WRT.
RPi running the bastard child of LinuxFromScratch and Arch. Entire OS built from source; glibc, binutils, etc built to Arch specs for compatibility. Pacman/Yaourt installed for access to PKGBUILDs. Kernel running a modified 3.9, modifications from patches submitted to the linux-rpi-kernel mailing list.
Once the base system was cross compiled under a patched GCC (for floating point), I setup arch's package handler for access to PKGBUILDs to easily add or remove additional packages. I built ffmpeg, xfce4, and a some other stuff out of the arch source, but the core was built by me.
When plugged in, kernel is loaded off of the SD card, which then passes to the HDD, where root is kept. We really need to come up with a way to forgo the SD requirement, imho.
The HDD will boot up to a prompt, with everything 'up'.
You can either attach IO to the RPi, or you can SSH in from another computer. For my turn in, I did both. Once logged in, I setup a script entitled 'ff' which launched ffserver and ffmpeg, and streamed to cam.mjpeg at [email protected] with pretty good quality considering.
The router was easily setup as a Wireless Bridge, connecting it to the school's wireless system, providing my network internet capabilities. I'd done this at home as well to get package sources. By using DD-WRT, I was able to take a lot of strain off the RPi regarding networking.. I'd discovered that when using wpa_supplicant wireless, it actually used a bit more cpu when streaming, and I wasn't able to reliably stream 320x240. When I streamed and hit max cpu, I was crashing the camera kernel modules.
So, to reliably stream 320x240, I had to be at command line, on ethernet, with minimal daemons running. If I dropped down to [email protected] or [email protected], then I could run xfce, wireless, and so on.
I'll share configurations, scripts, and so on later today; as the overall project as-is can be used for more than just my use, and is easily duplicated using a stock Arch system.
TLDR: Description, topology, and required settings of a camera system on RPi for capstone project, shared for posterity.
submitted by
BloodyKitten to
raspberry_pi
