Q-SEE NVR QC804

[Machineman 0]

If you happen to figure out how to lift the 4 camera limit, definitely update. It's possible the only hardware change is the POE switch (I assume the QC808 have 8 POE ports and so fourth).

 

The 4, 8, and 16 Station QC NVRs all have the same 4 POE ports. I have the QC808. A seperate POE switch is needed for more than 4 cams on the 8 and 16 channel stations.

[AaronHolio 0]

Kyle: Perhaps I was remembering the screen that allows you to turn off DHCP for the WAN network. My mistake. So yeah, no option to bridge the NVR's LAN into your LAN other than putting the camera on your local network behind a PoE switch. Although to give them credit, at least it can see cameras over its WAN port.

The 4, 8, and 16 Station QC NVRs all have the same 4 POE ports. I have the QC808. A seperate POE switch is needed for more than 4 cams on the 8 and 16 channel stations.

Yup. And for the price, they could at least let the user still show up to 16 cameras on the QC804 even if the frame rate is slow. Q-See told me there was a different chipset to handle the extra streams on the higher models. In this case it would possibly be the Broadcom h.264 decoder chip I was told they use. Which likely has a cost difference of $10-$15 to them but they want $200-$400 more for the more advanced models. Kind of disappointing.

 

By the way - something I forgot to note before. If you put your cameras on your local 192.168.x.x LAN, either log in to them and give them a manual hard set IP address, or go into your router and set them to have a reserved DHCP preset IP. Otherwise your NVR will lose them every time they reboot because when you configure them under the "Remote Devices" menu of the NVR, it attaches to the IP address at the time and won't find them again by itself. Since my router didn't seem to like to reserve an IP for them reliably, I just set each one with a permanent IP address outside the IP pool range of my router. Now it is totally fixed and reliable.

 

you wrote: "I'm still surprised there isn't even a forwarded port for each camera's interface (ie: port 192.168.0.3:8502 goes to camera 10.1.1.20:85, 192.168.0.3:8503 goes to camera 10.1.1.30:85, etc)." Excellent idea -- Well, maybe someday Q-See (or their OEM Dahua) will read these forums and adopt our ideas and feature requests. I'm pretty sure Q-See can do very little to improve their products without paying for it with Dahua. That extra layer of middle man just means we get fixes and feature improvements far less than needed.

 

Wow, look at this bad boy! http://www.dahuasecurity.com/products/nvr60006000d6000dr-3.html

Input 128ch@D1/64ch@720P/32ch@1080P

Transmission 128ch@D1/64ch@720P/32ch@1080P

Recording 128ch@D1/64ch@720P/32ch@1080P

 

If you happen to figure out how to lift the 4 camera limit, definitely update. It's possible the only hardware change is the POE switch (I assume the QC808 have 8 POE ports and so fourth).

If bricking the unit wasn't a concern, I'd attempt to run the firmware update for the QC8016. But Q-See wrote me back that I can't have the firmware images, because they don't have any new ones to release. Edited March 2, 2013 by Guest

[KyleK29 0]

...

 

Since POE switches cost about $59+, I ended up putting an old switch I had on one of the NVR POE ports (plugged one of the cameras in to the wall). Whenever I need to change a setting, I just plug my laptop into that switch and set it to 10.1.1.* (the NVR doesn't do DHCP, it sets the IP#'s via ARP/Ping .. from what I can tell). That allowed me the backdoor I needed. 802.3af standards are supposed to force the power off if a POE device is not detected - I haven't had any issues with blowing a port.

 

If you want full-time access and can sacrifice one port (plug a camera in locally), you can put an old router on there and portforward to the cameras individually. That'll get the permanent bridge between home and nvr networks.

 

The NVR will respond to a shell prompt on 10.1.1.1 - but none of my passwords worked. I tried the default admin/admin and had no luck.

 

I'm sure there's a way to enable more cameras via software, it's just finding someone who knows how to do it

 

The 4, 8, and 16 Station QC NVRs all have the same 4 POE ports. I have the QC808. A seperate POE switch is needed for more than 4 cams on the 8 and 16 channel stations.

 

With that in mind, I wouldn't doubt if it isn't just a software lock.

 

When Costco was first selling the QC804, some people got upgraded to the QC808 for free. The only practical reason for Q-See to do that is if their cost was insignificant.

[AaronHolio 0]

With that in mind, I wouldn't doubt if it isn't just a software lock. When Costco was first selling the QC804, some people got upgraded to the QC808 for free. The only practical reason for Q-See to do that is if their cost was insignificant.

That is our current conspiracy theory. But you know we conspiracy theory people, we sometimes wish for the conspiracy to be true. Maybe some brave soul will get an 804, obtain the 8016 firmware, and try to flash it. That person won't be me. I can't afford to buy a new unit.

[dexterash 0]

Firmware is the same for a whole category of products (let's say, the 4-8-16 NVRS).

But the drivers, softwares and others work based on the hardware they currently run.

 

Ok, you got a good point, that hardware is cheap. But you usually pay for hardware or software? If you only pay for hardware, phones and others should be damn cheap

[AaronHolio 0]

Ok, you got a good point, that hardware is cheap. But you usually pay for hardware or software? If you only pay for hardware, phones and others should be damn cheap

- I understand the business model. Entice with standard hardware that is limited by software. Microsoft taught us that a long long time ago. But as for smart phones, Google pretty much gives away Android compared to Microsoft and Apple (which doesn't put it on anything other than their own hardware) - companies like Q-See and Dahua are just plane lucky that Google didn't spend 0.000001% of its resources writing an Android/Chrome chunk of code that enabled any basic hardware to operate as a NVR.. Or we'd have $300 i5 or ARM based laptops able to handle 20 1080P cameras without breaking a sweat. And there would be an army of Google Play developers writing awesome software for it.

 

My Galaxy Note 2 has a quad core ARM chip, 2GB ram, 96GB flash memory, records 1080p video with ease, and cost me about $325 total. I'm willing to bet it has more processing power than the QC804. Of course, that was the cost with a 2 year data plan subscription. So I'm paying for the hardware in installments if you want to look at it that way. I'm ok with Q-See releasing what is likely the same hardware and enabling features via software. I'm not ok with the price difference being so extreme. And I guess why I'm the most bitter person on this forum about it is, it was one of their sales people who told me that if I got the 804 all I had to do was "buy a PoE switch" to add more cameras. So I planned my purchase based on that. And now I've got $300 worth of cameras sitting around that my NVR cannot see while I wait for the price on the QC8016 to come down in price so I can actually expand things.

[MaxIcon 0]

As for setting the camera to NEVER turn on the LED lights. As far as I've discovered, not possible. You can set the camera into black and white or color mode, as well as set times for it to change into each mode (or auto which is default), but no matter what, the LED lights turn on when they want to turn on. I actually took an odd route with 2 of my cameras, I used a dry erase black marker and blacked out all the glass (except the camera lens center of course) - and that caused the LED lights to always be on and be barely visible. Since I run all my cameras now in color mode 24/7 the IR light doesn't really matter. For the one part of my back yard that isn't bright enough, I have a motion sensing light so anytime something (including squirrels) is back there, it lights right up and the motion record feature turns on and it is all good.

 

Thanks - that was a really useful post!

 

For turning off the IR, you should be able to unplug the IR board with no issues. I tried this with my HFW3300C, and it worked as normal, since it doesn't use the IR board sensor for anything except turning the IR on and off. If you power up the camera and cover/uncover the sensor, the LEDs switch on and off immediately, so the software apparently has nothing to do with switching (in this version, at least).

 

Other cams, like the Vivotek IP8332, use the IR board sensor to switch between day and night mode as well (which is why it's much faster than the Dahua), but the Dahuas use the video signal to decide when to switch modes.

[AaronHolio 0]

Thanks - that was a really useful post!

For turning off the IR, you should be able to unplug the IR board with no issues. I tried this with my HFW3300C, and it worked as normal, since it doesn't use the IR board sensor for anything except turning the IR on and off. If you power up the camera and cover/uncover the sensor, the LEDs switch on and off immediately, so the software apparently has nothing to do with switching (in this version, at least).

 

Other cams, like the Vivotek IP8332, use the IR board sensor to switch between day and night mode as well (which is why it's much faster than the Dahua), but the Dahuas use the video signal to decide when to switch modes.

You are welcome. I took the time to post what I knew because when I first got the system I was very confused on many features. As for disconnecting the IR board, I tried this when I took apart the unit (shown here viewtopic.php?f=19&t=33075 ). If I remember right, when I disconnected it the entire camera didn't function at all. It seems that it has a trigger tied into the 4 pin connector that disables the whole thing. No biggie. As I said before, putting a piece of black tape, or using a dry erase black marker to cover the sensor will just turn the LEDs on all the time.

 

Edit update: I think I remember better now. When I unplugged the IR board, the camera did work, but got stuck in black and white mode. Which at that time of experimenting, I hadn't yet logged directly into the camera where you can force it to stay in color mode all the time. So, yes - there is a chance that you could unplug the IR board and still have functionality. But, my cameras are all mounted now, so I'm not going to take one down to experiment. I'm willing to bet it would work now that I've thought about it.

Edited March 2, 2013 by Guest

[tomcctv 187]

Yup. And for the price, they could at least let the user still show up to 16 cameras on the QC804 even if the frame rate is slow. Q-See told me there was a different chipset to handle the extra streams on the higher models

 

 

Q-See could have very easily (software wise), simply turned the on board PoE ports into a network bridge switch

 

 

It is a shame that Q-See's NVR has such promise, yet such annoying shortfalls that it turns off a huge amount of customers

 

 

Q-SEE only sell they dont make anything they just re-badge

 

 

If you happen to figure out how to lift the 4 camera limit, definitely update. It's possible the only hardware change is the POE switch

 

 

Hi. the only way to exspand from 4 to 8 is a new NVR and the other problem thats about to happen dahua now have 3 and 5mp cameras and guess what they will not work on ........ well they do but take the 4 way nvr to run one 3mp you would have to remove the other 3

[AaronHolio 0]

Q-SEE only sell they dont make anything they just re-badge

Hi. the only way to exspand from 4 to 8 is a new NVR and the other problem thats about to happen dahua now have 3 and 5mp cameras and guess what they will not work on ........ well they do but take the 4 way nvr to run one 3mp you would have to remove the other 3

Yes, I understand. I've stated it before that it is rebranded stuff. But when I refer to the unit it wouldn't make much sense to always state Q-See (rebranded Dahua) every time.

 

Interesting info on the 3mp and 5mp cameras. Thanks for sharing. It's a good thing that ARM processors are so cheap and increasing in performance so rapidly (4 core chips now, with plenty of 8 core chips on the way). Those billions of people buying cell phones help lower for the price for dedicated devices like NVR's. I'd sure love to have a 16 5mp camera setup with 30fps on each channel someday and likely in 2016-2018 time frame we'll start to see both camera and NVR starting to use the HEVC H.265 standard. 30%-45% the data size as H.264 and capability to handle resolutions up to 8,192×4,320 (35.3mp).

[galentx 0]

...

The NVR will respond to a shell prompt on 10.1.1.1 - but none of my passwords worked. I tried the default admin/admin and had no luck.

...

You might try user root, psw vizxv at the shell prompt. That got me into the WAN port on my QC804. It is probably the same going in through the LAN ports. I nosed around inside soon after I got it last fall. Found that most of the NVR behaviors are inside a single executable, making it hard to do any reverse engineering there. But the linux environment is there and might let you query the hardware configuration, especially identifying the processor, memory size, etc.

[AaronHolio 0]

You might try user root, psw vizxv at the shell prompt. That got me into the WAN port on my QC804. It is probably the same going in through the LAN ports. I nosed around inside soon after I got it last fall. Found that most of the NVR behaviors are inside a single executable, making it hard to do any reverse engineering there. But the linux environment is there and might let you query the hardware configuration, especially identifying the processor, memory size, etc.

I'll PayPal anyone $20 bucks who can either absolutely report the exact model and speed of the ARM main processor, as well as the Broadcom h.264 decoder chip AND if it has any differences between the 804 808 and 8016. A bonus $20 if you prove to me that you can hack the 804 up to 8016 firmware and have it actually work. I'd love to put our conspiracy theory to an end, whether right or wrong.

 

Note, no fudging/hacking the results to make $20.

[tony3263 0]

I am not an IT guy and I am having difficulty understanding some of the terms used on this post but it seems to list many of the issues I am having with my system. First QC tech support is very limited. I used a tip in this post and blacked out the IR LEDs so my camera wouldn't reflect light onto the glass in front of the camera. It worked great until the morning. Sometime during the evening the camera switched to Black & White and stayed in this mode. The only way to change it to color was to reset the power. Any advise on how to keep the camera in color mode?

[MaxIcon 0]

The Dahua version of the camera has a setting for color, bw, or auto mode; presumable the QC cameras do as well. This only affects the IR filter and video mode, and doesn't affect whether the IR LEDs turn on or not - they'll always be on below a certain light level, but the camera won't see much IR if the IR filter is in.

 

You can also unplug the IR LED board if you don't want them on at all. This doesn't affect anything else.

[silencery 0]

You might try user root, psw vizxv at the shell prompt. That got me into the WAN port on my QC804. It is probably the same going in through the LAN ports. I nosed around inside soon after I got it last fall. Found that most of the NVR behaviors are inside a single executable, making it hard to do any reverse engineering there. But the linux environment is there and might let you query the hardware configuration, especially identifying the processor, memory size, etc.

I'll PayPal anyone $20 bucks who can either absolutely report the exact model and speed of the ARM main processor, as well as the Broadcom h.264 decoder chip AND if it has any differences between the 804 808 and 8016. A bonus $20 if you prove to me that you can hack the 804 up to 8016 firmware and have it actually work. I'd love to put our conspiracy theory to an end, whether right or wrong.

 

Note, no fudging/hacking the results to make $20.

 

No bounty required. We can check directly. On my QC808, you can telnet in with the login posted below:

 

root/vizxv (thanks for this! where did you find it?)

 

After dropping into the console, run cat /proc/cpuinfo and the chip info will come up. I'll post my results tonight after getting home.

 

I think the password for the latest QC804 should be the same?

[silencery 0]

Here's the output of /proc/cpuinfo from a QC808:

 

~ # cat /proc/cpuinfo

machine : hdk7108

processor : 0

cpu family : sh4

cpu type : STx7108

cut : 2.x

cpu flags : fpu icbi synco fpchg

cache type : split (harvard)

icache size : 32KiB (2-way)

dcache size : 32KiB (2-way)

address sizes : 32 bits physical

bogomips : 495.61

 

I suspect CPU will be the same for all 4/8/16ch models.

[galentx 0]

And here it is for a QC804:

 

~ # cat /proc/cpuinfo

machine : hdk7108

processor : 0

cpu family : sh4

cpu type : STx7108

cut : 2.x

cpu flags : fpu icbi synco fpchg

cache type : split (harvard)

icache size : 32KiB (2-way)

dcache size : 32KiB (2-way)

address sizes : 32 bits physical

bogomips : 493.56

 

Pretty much the same. Does this tell us everything we might need to know about the hardware's channel capacity? Is there some video processing not identified by cpuinfo?

[groundfaults 0]

I bought a qc804 nvr package from costco. I got the camera setup and I'm able to remote view with the iphone client. However I am unable to do playback with the iphone client. Does anyone know how to configure that ??

[lowpro 0]

I bought a qc804 nvr package from costco. I got the camera setup and I'm able to remote view with the iphone client. However I am unable to do playback with the iphone client. Does anyone know how to configure that ??

 

Double check that the user account that you are using, has permissions to playback.

[groundfaults 0]

I am using the admin account to remote view live on a iphone client, however it says connection failed when I try playback. Any ideas? is there a different port being utilized for playback?

[lowpro 0]

Also double check that you are actually recording the sub-stream. What you are playing back on your phone is actually the sub-stream and not the main stream. Make sure that both of those streams are being recorded.

[silencery 0]

And here it is for a QC804:

 

~ # cat /proc/cpuinfo

machine : hdk7108

processor : 0

cpu family : sh4

cpu type : STx7108

cut : 2.x

cpu flags : fpu icbi synco fpchg

cache type : split (harvard)

icache size : 32KiB (2-way)

dcache size : 32KiB (2-way)

address sizes : 32 bits physical

bogomips : 493.56

 

Pretty much the same. Does this tell us everything we might need to know about the hardware's channel capacity? Is there some video processing not identified by cpuinfo?

 

Thx for the input. From a CPU perspective, it seems the specs are the same. There is a high probability they are also using a hardware decoder card for displaying video, but i haven't had a chance to check yet.

[AaronHolio 0]

Thx for the input. From a CPU perspective, it seems the specs are the same. There is a high probability they are also using a hardware decoder card for displaying video, but i haven't had a chance to check yet.

I think someone mentioned it was a broadcom h.264 decoder chip. The debate may be if it is any different in the 804 808 or 8016. Since Q-See states the same total unit frame rate for all models, it is pretty likely the same chip.

 

On another note, I see Costco is out of stock on the 804.. So perhaps we'll see the 8016 in time. Even tho Q-See said it would be at Costco first of the year.

[groundfaults 0]

how do i verify the alternate stream is being recorded? I have all cameras connected thru the dvrs poe ports.

[Sifter 0]

Here is the cpuinfo from the Q-SEE QCN7001B cam.

 

# cat /proc/cpuinfo

Processor : ARM926EJ-S rev 5 (v5l)

BogoMIPS : 134.75

Features : swp half thumb fastmult edsp java

CPU implementer : 0x41

CPU architecture: 5TEJ

CPU variant : 0x0

CPU part : 0x926

CPU revision : 5

Cache type : write-back

Cache clean : cp15 c7 ops

Cache lockdown : format C

Cache format : Harvard

I size : 16384

I assoc : 4

I line length : 32

I sets : 128

D size : 8192

D assoc : 4

D line length : 32

D sets : 64

 

Hardware : DaVinci DM365 EVM

Revision : 3650000

Serial : 0000000000000000