Speed kills

Or does it?

Let look at the official statistics:
http://www.nzta.govt.nz/resources/road-deaths/toll.html

Road Toll in NZ is just a bit under 300 (remember that figure). Overall there are about 30,000 deaths in NZ every year (natural or otherwise).
The road toll represents 1%.

I am fed up with NZ Police blatant propaganda against speeding, in particularly that they are trying to spin on the speeding aspect on almost every accident (incident?) on the NZ roads.

Yes speeds is a factor. No, it is not a factor because of some arbitrary limit being exceeded. It is a factor because to get somewhere you have to move and that involves speed (be that 1kph or 100kph). It is like saying that for every fall gravity is a factor. Hell, lets start campaign against gravity!

Alcohol Kills (even more)!
According to this: https://www.drugfoundation.org.nz/alcohol/drug-trends alcohol causes more than 1000 deaths per year. In my opinion it is far more avoidable than road toll (at 300). There are over 3 times more deaths from alcohol than from road toll, and unlike road toll the alcohol deaths are 100% preventable. Alcohol deaths represent >3% of all deaths. Pretty pathetic.

Smoking Kills (even more than alcohol)!
According to this: http://smokefree.org.nz/sites/default/files/Fact_5000_NZers-fnl-081003_0_0.pdf Smoking kills 5000 of New Zealanders, and it is far more preventable than Alcohol deaths, and even further more preventable than road toll. For every person that died on the road 16 people died from smoking. Smoking deaths represent almost 17% of all deaths. Very sad.

What really got to me is that during 2014 Christmas break the NZ Police silently introduced (possibly illegally) no tolerance towards speeding: drivers could be stopped by police if they were caught just 1kph over the speed limit.

Here http://www.nzherald.co.nz/nz/news/article.cfm?c_id=1&objectid=11365666 NZ Police comissioner quoted to state the following:

He advised drivers to set their cruise control to the limit, or just below, as any speed above the posted limit would warrant an infringement.

It is a very silly thing to say, for starters the cruise control is very unsafe for NZ with so many twisted roads. Secondly the cruise control is a very rare option in New Zealand. Most importantly the cruise control should not be recommended as safe option as it allows the driver to remove feet from the pedals and not being concentrated while driving.

The no tolerance presents multiple problems:

1) The most obvious is accuracy of police measuring equipment (from my research it is not accurate enough, and prone to user error)

2) The inaccuracy of the speedometers

3) The disparity of the readings of speedometers between different vehicles

4) The unfairness between sampling rate of the speedometer by the driver and the enforcing officer.

5) The drivers will tend to focus on speedometer than on the road.

6) Effective speed limit becomes 10-20kph less than posted due to speed-cautious drivers (they say speed limit is not a target, but if it is not, what is the point?).

7) Even more difficult passing lane manoeuvre, due to less head room and the annoying effect of speeding up on the passing lanes being amplified.

8) Due to stupidity of the no tolerance, the NZ Police endanger people by doing dangerous manoeuvres, and speeding themselves (far more than 1kph) to catch the “speeders” that went over 1kph over limit.

9) Most importantly the delusion (or a blatant lie?) of the success of the “Speed Kills” campaign.

#1. Accuracy of the police equipment.

At this stage I have no answer, as I am still waiting for NZ Police to provide me with their equipment specs.

From my research the New Zealand Police uses stalker gear, Specifically:

Stalker LIDAR LR (EU)
Stalker Dual

Now for Stalker LIDAR the manufacturer claims +/- 2kph. The LIDAR is more accurate than RADAR.

The LIDAR is susceptible to sweeping error. Here is a good demonstration of the sweeping error:

The below is a bit of speculation (until I get facts from NZ Police).

I have made inquires and apparently the NZ Police uses their own software (firmware?) and are “immune” to sweeping errors.
From my programming experience it is not possible to completely make things immune from user abuse, the device is simply unaware of the intention of the user. All they can do is prevent jitter errors (hand shaking), but if the motion is smooth device will unable to differentiate the motion of the vehicle with added motion of the LIDAR tracking+sweeping the vehicle (unless they make it so it only reads out if the device is completely immobile, which makes it impractical).
I have been also told that due to their own software and stringent “ISO17025” calibration they are much more accurate than the manufacturer states. I take it with a grain of salt, as these devices are not calibrated very frequently (apparently once a year), and they do not run atomic clocks in them (or use GPS for time signal). Combined with temperature instability of quartz clock crystal, it is highly unlikely they can be more accurate than what manufacturer states.
I don’t see how it is possible, just by software, to make the temperature dependant device to be by order of magnitude more accurate than those +/-2kph stated by the manufacturer.

Here is a document on clock drift: http://electronicdesign.com/analog/minimize-frequency-drift-crystals

The RADAR units are even more inaccurate (up to +/- 3kph).

#2. Accuracy of the speedometers.

Let me address the white elephant in the room. NZ public has no means of assuring their speedometers are accurate within 1kph.
According to this article: http://www.stuff.co.nz/motoring/63849814/GPS-speed-readings-not-accepted ,NZ Police states that GPS units are not admissible in court as accurate speed measuring devices, so the motorists have no means defending themselves from abuse of the NZ Police (be that sweeping of the LIDAR, or keeping old reading from other speeding motorists).

According to VIRM (the WoF manual) section 7-12 states:

The speedometer must be in good working order and operate while the vehicle is moving forward.

There is nothing about accuracy in VIRM manual!!! It could read mph as kph for all they care!

Additionally most of modern cars will not have 5kph marks, as well as they will have 240kph speedometers which makes the needle about 3-4kph wide.

Here is the pic of my speedometer:

sti_speedo

Notice how thick is the speedo needle, the lack of numbers on 10ths (odd are missing) and the complete lack of 5ths. The needle in this example is about 3-4kph wide!

Most of the cars (but NOT all) will over read by about 10% from factory. This can change if different tyre and/or wheel size is used.

My speedometer was about 12% over-reading. This was combination of the factory inaccuracy (~10% over) with actual tyre size difference (even though the tyres were of correct size 245/40R18 the particular tyre, Dunlop LM702, was slightly smaller than average 245/40/R18).

I have compensated the inaccuracy by using different brand of tyres as well as slightly higher side wall (Bridgestone RE002 245/45/R18), now my speedometer over-reads by about 3%.

Just by having new tyre vs old tyre can make about 2% difference:
eg: nominal diameter for 245/40/R18 is 653mm, normally the car tyres have about 8mm worth of thread, providing minimal legal thread is 1.5mm we have 6.5mm variance on each side (so about 13mm total), that is about 2% variance. At 100kph it is 2kph difference already.
Then comes in the inflation (which can add a percent or two)…

#3 Disparity of the readings:

Smart drivers learn to compensate, while oblivious drivers (worst kind) will treat speedometer as 100% accurate and hold up every one at 85-90kph. Due to oblivious drivers considering themselves “safe” and driving at the “speed limit” they will not pull over and let others pass. This creates frustration and provokes the unsafe overtaking. Occasionally the “safe” drivers will also attempt to overtake, but because they stick to the speed limit 100%. they will linger for very long time in oncoming lane as they are afraid to break the speed limit.
Overtaking as fast as possible is the safest option when overtaking (if Police says otherwise they are delusional and/or lying).

#4 Unfairness of speed enforcement.

Police Officers will always have upper hand, for simple fact of they have ability to spend 100% of their concentration on the motorist speed (in case of LIDAR operation) for extended amount of time, or simple speed locking function of the RADAR systems (with audible Doppler feedback). On other hand motorists have to spend 99% of their concentration on the road, and only glance occasionally the speedometer to maintain the speed. It is very difficult to perceive 10% change in speed in a modern vehicle, hence the speed can easily drift up or down.

#5 Glued to the speedometer.

What “no tolerance” creates is already inattentive drivers spending all their effort in maintaining the speed, and paying even less attention to the road. The whole “Speed Kills” propaganda creates false illusion of being safe driver by driving slowly. In addition to that it encourages the “safe” drivers to clog up the roads and not allow for safe passing, as these self-righteous assholes will go out of their way to net let you pass them (ie not pulling into slow vehicle bay). Once you do pass them, they will gesture, honk and flash their lights in anger, even though you haven’t cut them off, or broke the law in anyway (just safely passed them).

#6 If it is not a target, what is it then?

Because of no tolerance, with combined speedometer over-reading and drivers being overcautious about the speed, the actual speed limit becomes 10 to 20kph less than posted, even though it is safe to drive at the speed limit. One of the parts of the “Speed Kills” campaign is “Speed Limit is not a Target” campaign.
In reality it is a target and always will be. The speed limit posted, is just an arbitrary limit anyway, without much of scientific backing on what actual limit can be.
For example the stretch between Warkworth and Welsford (SH1) has 80kph limit, what I fund extremely funny (if not sad) is that the gravel roads that connect to that stretch of highway have 100kph limit on them. This is insane!.
For example:

View Larger Map
or this:

View Larger Map
There plenty more like that.

The fact that extremely dangerous gravel road has 100kph while very safe paved highway has 80kph removes all the confidence of the posted limits.

#7 Passing lane [lack of] culture

NZ motorists have a really bad habit on passing lanes: accelerate by 20kph even if you have no intention going that fast once the passing lane is over. This is a mentality issue. It is a very common sight where a motorist previously holding up another 5-10 vehicles behind it, driving along a highway at 80kph, accelerates to 105kph when passing lane comes, making it impossible to pass them legally. Then at the end of passing lane they drop their speed back to 80kph. If that does not happen, some muppet in their 4×4 pulls out to pass only to struggle going uphill and ending up blocking the passing lane. The only way to deal with this is to pass them outside of passing lanes and ignore passing lanes entirely as there are cops at the end of them anyway waiting for you to go over 1kph over speed limit.

#8 Unsafe enforcement of no tolerance

The no-tolerance allows police officers to stop infringing motorists for going over 1kph. Guess how police officer enforces such “law”? By doing dangerous U-turn across passing lanes, speeding up to well over the speed limit (how else they will catch them?), cross over the double yellow line multiple times, force whole bunch of motorists into shoulder and then pulling over the “offender” in an unsafe spot. And it is ll for what? Maybe 5kph over the limit? I have witnessed way too many events like that.
I drive a fast car, and some cops get out of the way to stalking me, waiting for me to make a mistake. Such a waste of Police resources. Good luck getting such treatment when you are burglarised.

#9 Insane delusion of the success of “Speed Kills” campaign.

Speed Kills campaign is a complete utter failure.
Here is the proof:
http://www.nzta.govt.nz/resources/road-deaths/toll.html

 

Local Government Region 2010 2011 2012 2013 2014
Northland
22
7
17
20
14
Auckland
52
50
41
48
37
Waikato
66
64
64
31
46
Bay of Plenty
37
17
23
18
29
Gisborne & Hawkes Bay
23
17
30
10
19
Taranaki
11
8
17
7
11
Manawatu / Wanganui
40
27
27
13
34
Wellington
10
11
11
17
12
Nelson / Marlborough
24
8
9
9
7
West Coast
7
7
7
9
7
Canterbury
48
32
32
49
35
Otago
17
14
16
14
19
Southland
12
7
6
1
11
Total
369 
269 
300 
246 
281  

If campaign would work we should see at least 50% reduction of the road toll.
Apart from weather related variation, there is no change.
There should be change regardless of the campaign due to cars getting safer and safer by the year.
The biggest increase should have followed the restriction of the imports due to emissions (forces importers to import newer cars).
In fact that this season’s road toll is approaching 300, suggest that the campaign failed.
Probably global climate change had better effect than anything else.

As far as I am concerned the “Speed Kills” campaign is a tool for blatant political career advance for people in charge of it. There absolutely no evidence of it working at all.

Another article that makes my blood boil is this:
http://www.stuff.co.nz/national/64512444/speed-kills-warn-police-as-road-toll-mounts

The NZ Police attributes all of the incidents in article to speed, in reality it could not be far from truth:

A man was killed in the Eastern Bay of Plenty when the car he was travelling in collided with a milk tanker at the intersection of SH2 and Wilson Rd near Paengaroa.

If you collide with the tanker which travels at 90kph no matter what you speed travel at you are dead. You could as well be stationary.
Other two incidents in the article are also head-on colissions. Nothing to do with the speed.

Then they go off the tangent of some muppet doing 240kph on Waikato expressway.
While driving at that speed on public road is a very stupid thing to do, they give impressions that it will take 450m for some one to stop.
The rule of thumb every doubling of speed quadruples the stopping distance (simple physics really).
The modern car will stop from 100kph in less than 40m (my car can do that just a tad over 30m).
Lets take safe 50m stopping distance and for 200kph it makes 200m. So from 240kph it should be around 220m, not 450m.
The whole 240kph suggests that the car is not a simple 20yo Camry, as it requires over 300HP to get there.

Here comes figures pulled out of their asses:

Fatal crashes decreased by 22 per cent over the summer campaign. Serious injury crashes decreased by 8 per cent

How about attributing this to safe cars (even though the figures do not match what is on nzta website)?

This all nice until we get to this gem:

Grace said generally speed was a factor in all crashes and when most think about speed, they think about being in excess of the limits but often that is not the case.

“Often we are just driving at a speed that is not suited to our driving ability or the car we are in or the conditions [of the road],” she said.

“The speed limit is the speed limit but sometimes we have to look at the road.”

So the speeding campaign has nothing to do with speeding?
How stupid she thinks people are?
Speed is a factor in all crashes, because …. something has to be moving to crash!
Then in moment of clarity she hit nail on the head: “Often we are just driving at a speed that is not suited to our driving ability or the car we are in or the conditions” , well no shit Sherlock, guess why is that? Instead of focusing on one aspect, the NZ Police and NZTA should have been focusing on driver training!
Then moment of clarity disappeared in thick fog of delusion: “The speed limit is the speed limit but sometimes we have to look at the road.”, well yes, this is true (but not in the context) and this is why we should not have no-tolerance, as we actually have to look at the road (and not speedometer!).

The whole stopping distance brings into the light of the speeding kills idiocy as well, for example driving @ 120kph in my car is far safer than driving @ 90kph in a 20yo Holden Commodore.

1) 20yo Holden will have under-performing brakes. I can stop in less than 35m, while the Holden will stop in double of that.
2) 20yo Holden will have none of the safety options (stability control, abs, air bags).
3) 20yo Holden will be a death trap if it crashed against my car (5 star rated cars tend to obliterate older cars in head-on collisions: volvo 940 vs renault modus).
4) Tyres will probably be substandard on an older car, as no way the owners will spend $2500 on new good performing tyres.

Here is my opinion on how to address road toll

1) Compulsory minimum time spent with qualified instructor before getting restricted licence.
I have seen way too many people picking up bad habits from their parents when they teach them how to drive.
I bet almost none of the parents teach their kids how to handle the car in emergency (out of control scenarios), as they themselves do not know how. The compulsory driver training will allow instructor to correct bad habits, before they become a problem. This is not too expensive (10 hours, of training is about $400-$600).

2) Compulsory handling training (on the wet car park/track, and on open road).
Most of city dwellers never learn how to handle the car until too late (ie they go on Holiday and crash). The New Zealand terrain posses a difficulty of a driver that only dealt with Auckland streets and motorways. They never learned how to approach a corner, braking points, and how to handle when they hit a slippery spot. The time on track or even wet carpark is not too expensive, eg: trackdays cost about $100 per evening, so it is in realms of reach for most of people. If government organises such training then it should be even cheaper.

3) Re-licence road test every 10 or 20 years.
This will filter out drivers that fell through the seams of the old system, forcing them to resit the test to make sure they are capable of driving.

4) Open road handling test as part of full licence test.
Ability to drive on twisty open roads must a part of licence test, people should not be driving in New Zealand if they cannot handle New Zealand roads.

5) Focusing on other traffic offences (beyond speeding).
There is too much focus on the speeding, while tailgaters, corner cutters, slow drivers and red-light runners are running wild.
The whole Auckland traffic problem is because of people not leaving enough distance between cars!

6) Enforcement of keep left rule.
Change the road code so the drivers lingering in right lanes can be fined.

The whole driving culture in NZ is in shambles, because of lack of public transport people who are lethargic about driving are driving, and making fatal mistakes. It is way too easy to get a driver licence in NZ as well.

P.S. for the slow people saying “why don’t you just drive slower?”, why don’t you just take a bus and stay off the road?

Dahua IPC-HFW4300S

Dahua IPC-HFW4300S

IPC-HFW4300S

Bought from amazon for $110USD (via Youshop).
I have decided to go with Dahua as replacement of my recently purchased Hikvision DS-2CD2032-I, due to severe stream errors (shitty firmware?) on DS-2CD2032-I.
UPDATE: firmware update fixed the errors with DS-2CD2032-I.
UPDATE: the stream errors are due to nature of these cameras and UDP. The TCP stream is perfect.

Youshop managed to “lose” it, I had to “recover” it from unclaimed pile.

The camera described here was sourced from Amazon.
It came in a retail box, but with Chinese labels. The instructions where also Chinese.

The camera came with preconfigured IP address of 192.168.1.108.

The default username is admin, password is also admin.

WebUI

The web interface is somewhat OK, no video stream visible in any browser on Linux (requires ActiveX?). Typical shitty Chinese webUI.
The video settings do work.
The config Export does not work.

“Live” tab (or anything having video output) is completely useless without even bothering to tell me that “plugin” is missing.
When these idiots will learn that not everyone uses IE6?

The camera has exactly same issues with RTSP and UDP, when used with ffmpeg as . When used with -rtsp_transport tcp flag the stream is stable.
The image quality is good (very close if not better than Hikvision DS-2CD2032-I).

Streams

Picture sample (day):
Dahua-IPC-HFW4300S-day

Picture sample (night):
Dahua-IPC-HFW4300S-night

The camera has 3 streams (configured via webUI, 3rd stream disabled).

The trick was to find out the stream URL that works without authentication.
Main stream: rtsp://{CAMERA_IP}:554/cam/realmonitor?channel=1&subtype=0&proto=Onvif
Sub stream: rtsp://{CAMERA_IP}:554/cam/realmonitor?channel=1&subtype=1&proto=Onvif
Sub stream (disabled by default): rtsp://{CAMERA_IP}:554/cam/realmonitor?channel=1&subtype=2&proto=Onvif

Note: proto=Onvif is the key to bypass authentication.

The snapshot URL is: http://{CAMERA_IP}:9989/ EDIT: the 9989 port access is unreliable, the reliable snapshot URL is: http://{CAMERA_IP}/cgi-bin/snapshot.cgi

Interesting that switch to/from IR is gradual.

Another very good thing about this camera is that it runs High profile on their h264 streams:

  Metadata:
    title           : RTSP Session/2.0
  Duration: N/A, start: 0.009967, bitrate: N/A
    Stream #0.0: Video: h264 (High), yuvj420p, 1920x1080 [PAR 1:1 DAR 16:9], 25.33 fps, 100 tbr, 90k tbn, 49.95 tbc

/proc/cpuinfo:

Processor       : ARMv6-compatible processor rev 5 (v6l)
BogoMIPS        : 526.25
Features        : swp half fastmult edsp java 
CPU implementer : 0x41
CPU architecture: 6TEJ
CPU variant     : 0x1
CPU part        : 0xb36
CPU revision    : 5

Hardware        : Coconut
Revision        : 13ec300a
Serial          : 0000000000000000

kernel:

Linux version 2.6.38.8 (jenkins@localhost.localdomain) (gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-70) ) #1 PREEMPT Tue Sep 30 18:53:02 CST 2014

free -m:


             total         used         free       shared      buffers
Mem:           131           83           47            0            0
-/+ buffers:                 83           47
Swap:            0            0            0

df -h:


Filesystem                Size      Used Available Use% Mounted on
ubi0:romfs                4.9M      4.9M      4.0K 100% /
devtmpfs                 65.6M         0     65.6M   0% /dev
tmpfs                    65.7M    576.0K     65.2M   1% /var
ubi1_0                   21.1M     14.3M      6.8M  68% /usr
ubi2_0                  708.0K     60.0K    648.0K   8% /mnt/custom
ubi3_0                  708.0K     72.0K    636.0K  10% /mnt/pd
ubi4_0                    4.9M      3.3M      1.5M  68% /mnt/web
ubi5_0                  708.0K     84.0K    552.0K  13% /mnt/syslog
ubi6_0                  708.0K    232.0K    404.0K  36% /mnt/mtd
ubi7_0                  708.0K     44.0K    592.0K   7% /mnt/backup

Similar to Hikvision DS-2CD2032-I this camera runs very "hot" CPU wise: sitting around loadavg 10.

In all aspects IPC-HFW4300S is very similar to DS-2CD2032-I hardware wise. Same CPU, same clock frequency, similar amount of RAM (128MB for Dahua and 96MB for Hikvision).
Linux wise they run same kernel version (2.6.38.8). Although Dahua runs older busybox version (v1.18.4 vs Hikvision v1.19.3).

Both of these manufacturers violate GPL badly..

It looks like the developers at Dahua use Jenkins, specifically this error message gives it away:

00:00:08|[prc] ERROR  (/home/jenkins/jk_slave_centos6/workspace/IPC_DH3.S0507_IPCAmbarella2.420/tmp_build_dir/PRC_A5S/build/platbuild/../../src/module/submod/i2c/prc_i2c.c|I2C_isr|454): I2C0 dev0x68 wait ack timeout

Even though Dahua are very protective with the firmware, I found newer firmware here (will install once I get shell on the camera):
http://wrightwoodsurveillance.com/forum/thread-89.html

I have upgraded firmware from:

Software Version
2.210.0000.11.R, build : 2014-01-15

WEB Version
3.2.1.164499

to:

Software Version 
2.420.0003.0.R, build : 2014-09-30

WEB Version 
3.2.1.223527

without any issues...

The rest

Now for the shitty part of the camera:

The camera is configured with telnet.
There is no SSH service. It does not look like telnet can be disabled from WebUI (or SSH enabled).

Trying to login to telnet with default admin password fails.

I have managed to extract root hash from firmware file (see here):
$1$jSqQv.uP$jgz4lwEx2pnDh4QwXkh06/
Googling it reveals nothing.
After running JtR for a few hours on GPU, I got the password as 'vizxv' (without the quotes).
The password did not work for any of user combinations...
Still trying to access the telnet...
UPDATE: as per these findings telnet username is admin and password is 7ujMko0{webui_admin_password}, so if webUI admin password is admin then the telnet password is 7ujMko0admin .

Pros:
Good picture quality.
Solid metal construction.
High profile is available for h264 streams.

Cons:
Really shitty support.
No official firmware available.
Windows-centric Web UI.
Telnet is always ON.
Telnet is set up with a different, hard coded root password (Dahua back door).
RTSP urls are a bit long.

UPDATE: after upgrading the firmware the "Live" tab now has controls, as well as option to download plugin. Well almost, the download link http://{camera_ip}/webplugin.tar.bz2 gives you nice 404. Fucking idiots.

The config import/export still does not work.

NOTE: if camera is used with OpenCV make sure to add ?tcp at the end of the url!!! This camera is even more buggy than Hikvision DS-2CD2032-I and it drops UDP packets on even small sub streams. Here is example of the url needed for OpenCV to work reliably:

rtsp://{camera_ip}:554/cam/realmonitor?channel=1&subtype=0&proto=Onvif?tcp

Ubiquiti AIRCAM HD

Ubiquiti AIRCAM HD
aircam1

Bought it in July 2012, from gowifi.co.nz, for ~$200NZD.
At the time it was good value for money.
It is 720p PoE IP camera.

Image (day):
AirCam-HD-day

Image (night, with artificial light):
AirCam-HD-low-light

Streams:

There are four rtsp streams:
Main stream: rtsp://{CAMERA_IP}/live/ch00_0 (1280×720)
Sub stream 1: rtsp://{CAMERA_IP}/live/ch01_0 (640×368)
Sub stream 2: rtsp://{CAMERA_IP}/live/ch02_0 (320×176)
Sub stream 3: rtsp://{CAMERA_IP}/live/ch03_0 (160×96)

There are four snapshot urls:

Main stream: http://{CAMERA_IP}/snapshot.cgi?chan=0 (1280×720)
Sub stream 1: http://{CAMERA_IP}/snapshot.cgi?chan=1 (640×368)
Sub stream 2: http://{CAMERA_IP}/snapshot.cgi?chan=2 (320×176)
Sub stream 3: http://{CAMERA_IP}/snapshot.cgi?chan=3 (160×96)

Technical info:

Linux AirCam 2.6.28 #1 PREEMPT Sun Jun 9 01:03:42 EEST 2013 armv5tel GNU/Linux


Processor : FA626TE rev 1 (v5l)
BogoMIPS : 532.48
Features : swp half thumb
CPU implementer : 0x66
CPU architecture: 5TE
CPU variant : 0x0
CPU part : 0x626
CPU revision : 1

Hardware : Faraday GM8126
Revision : 0000
Serial : 0000000000000000


total used free shared buffers
Mem: 127712 103684 24028 0 3784
-/+ buffers: 99900 27812
Swap: 0 0 0

Pros:
Very good web UI (Chinese manufacturers should learn from it), everything works on non-Windows OS, even live view.
Stable RTSP stream.
Ran without issues for over 2 years.
Fantastic support from Ubiquiti (firmware availability, forum, and documentation is great).

Cons:
Average image quality.
No IR.
Low sensitivity (performs poorly in low light).
Noise correction is overzealous (the image has oil painting feel).
Flimsy plastic body and mount.
Camera is not 802.3at or 802.3af compliant so does not work with ; it needs it’s own 24V injector.

The Ubiquiti even provides their own version of Zoneminder. Although I used it for short period of time, I found it is too CPU intensive and because it stores the video clips as collection of images, I found it a bit impractical. I settled for my own motion detection (built python OpenCV).

Probably will be retiring it in favour of more modern camera…

TP-LINK TL-SG1008PE 8-Port Gigabit PoE Switch

TP-LINK TL-SG1008PE 8-Port Gigabit PoE Switch

TL-SG1008PE-V1-01

Got it on amazon for ~$120USD. With shipping it costed me $200NZD, while it retails in NZ around $250-300, typical NZ price disparity.

Solid PoE switch (802.3at/af compliant), quiet fan, runs cool, sturdy…
Main use is for PoE cameras, got 16 port since the price difference is not huge (probably not going to have 15 cameras…).

Hikvision DS-2CD2032-I IP camera

Hikvision DS-2CD2032-I
Hikvision DS-2CD2032-I

Very sturdy all metal construction. Quality casting and solid mount.

Bought it on amazon for ~$120 USD.
Seller didn’t ship to NZ so got it sent via Youshop.

It is a PoE camera, so I hooked it up via TP-LINK TL-SG1008PE 8-Port Gigabit PoE Switch

The camera came preconfigured with unusual static ip address of 192.0.0.64. In Windows world it supposed to be configured via some utility, so theoretically it is not a big deal. All I had to do is RTFM and add the 192.0.0.1/24 to the machine I was trying to configure the camera from.

The web interface can be used with OS independent browser for basic configuration (beyond that you are out of luck, unless you use Windows).

It came with firmware Version V5.2.0 build 140721 and encoding Version V5.0 build 140714.

The picture quality is very good (substantially better than Ubiquiti AIRCAM HD)

Day:
DS-2CD2032-I-sample-day

Night:
DS-2CD2032-I-sample-night

Night+Light (low level flood light):
DS-2CD2032-I-sample-night-lights

There are two streams that can be configured independently.
I have configured one for 1080p/15fps (not 25fps due to increased frequency of stream errors, see below in the issues), and another for 320×240/10fps for motion detection. The key issue is to increase I-frame frequency to at least every 10 frames (due to RTSP stream errors).

How to access camera:

Default username/password: admin/12345

Main stream URL: rtsp://{CAMERA_IP}/Streaming/Channels/1 (although rtsp://{CAMERA_IP}/ works too.)
Sub stream URL: rtsp://{CAMERA_IP}/Streaming/Channels/2
Main stream snapshot URL: http://{CAMERA_IP}/Streaming/channels/1/picture
Sub stream snapshot URL: http://{CAMERA_IP}/Streaming/channels/1/picture
EDIT: sub stream snapshot is exactly same as main stream snapshot, in fact using any number above 0 in url /Streaming/channels/{X}/picture leads to same result.

Technical details:

Linux version 2.6.38.8 (root@HIK-RD-CI-Frontend) (gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-70) ).
CPU: ARMv6-compatible processor [4117b365] revision 5 (ARMv6TEJ), cr=00c5387f

# cat /proc/cpuinfo 
Processor       : ARMv6-compatible processor rev 5 (v6l)
BogoMIPS        : 525.92
Features        : swp half fastmult edsp java 
CPU implementer : 0x41
CPU architecture: 6TEJ
CPU variant     : 0x1
CPU part        : 0xb36
CPU revision    : 5

Hardware        : Coconut
Revision        : 13ec300a
Serial          : 0000000000000000

# free -m
             total         used         free       shared      buffers
Mem:         95436        89024         6412            0          528
-/+ buffers:              88496         6940
Swap:            0            0            0

It looks like it is based on ambarella chipset…
The camera runs “hot”, with loadavg hovering around 5 (it sometimes for no apparent reason gets to 10, and causes issues).

The stream can be accessed via avplay/ffplay:
avplay -rtsp_transport tcp -i rtsp://$IP:554 (or VLC). To do so without authentication it must be disabled from web UI.

It would have been an awesome camera if not for the issues…

Web UI (if you can call it “web” with all the windows centric crap)

Login page:
Hikvision-webui-login

Live View:
Hikvision-webui-Live-View
Note: MJPEG selection is also broken. Only way to get Live View working is to install vlc plugin for Firefox.

Image Configuration:
Hikvision-webui-Basic-Configuration-Image
Shit be broken: none of the things in the image settings sub-menus can be changed except the IR schedule.

Maintenance:
Hikvision-webui-Basic-Configuration-Maintenance
More shit be broken: I guess the idiots who built it never actually tested this page, beyond IE. The export config button does nothing. Thank you Hikvision for working reboot button!

The BIG issues…

UPDATE: As per , the firmware update resolved 99% of the stream error issues.

Most show stopping issue is (are) stream errors. Currently the camera is completely unusable with UDP RTSP stream. It is usable to a degree when stream is forced to TCP (-rstp_transport tcp).
The stream errors get worse when load average reaches 10 (it normally does so after 24-48 hours of operation). Once it hits 10 the camera needs to be rebooted to be usable again (otherwise every second or third frame is corrupted).

The Stream errors look like this:
 

...
[h264 @ 0x20fdd20] error while decoding MB 71 13, bytestream -22
[h264 @ 0x20fdd20] concealing 6578 DC, 6578 AC, 6578 MV errors in I frame
....
[h264 @ 0x20fd4a0] Cannot use next picture in error concealment
....
[h264 @ 0x20fdd20] left block unavailable for requested intra4x4 mode -1 at 0 62
...
[h264 @ 0x20fee20] cabac decode of qscale diff failed at 89 48
...

quick google search shows other people reporting same thing for this camera.
I found a random Russian site describing the issue with different camera from Hikvision, specifically stating that the issue started with firmware v5.X (while v4.X was fine). Here: http://anteh.ru/notes/freebsd/notes_ipcamconfig.html

I have contacted Hikvision regarding RTSP erros, they never replied… From google searches it looks like Hikvision provides no support whatsoever.

The “web” interface is a joke. When logging in you are greeting with multiple of “no plug-in found”. Only basic configuration can be changed (thank you for that Hikvision, otherwise I would be returning the camera).
Image setting does not work (the sliders do nothing), out of all settings in Image tab only thing that works is the IR schedule.
The export config does not work, not sure about reset to defaults or update firmware. The layout is broken on that tab as well.
It looks like the “web” interface never been tested on anything other than IE. Making web interface windows-centric is very stupid and short sighted. You can install VLC plugin in firefox for Live-View to work, beyond that you “need” Windows. Good thing is that I will not be using web interface very often.
Someone needs to make openwrt/tomato style project for IP cameras, to liberate the users from stupid web interfaces that these cameras come with. It is ironical that you need Windows OS to manage a Linux device. We can thank piracy for windows “developers” that flooded the market and creating crappy software like the web interface on this camera.

Admitting defeat I have bought Dahua IPC-HFW4300S. Initial reason I settled for Hikvision (and not Dahua) was simply because of the firmware availability. Dahua does not provide firmware updates whatsoever, stating that the only official suppliers are provided with firmware (good luck finding one in NZ).

It seems to me with all these cheap cameras the whole firmware thing is a big GPL violation….

UPDATE: I managed to borrow a windows machine, and web ui still didn’t work until I used IE and installed their activeX plugin.
Why Ubiquiti (who BTW do not specialise in IP cameras) can do a nice web interface that works on all devices while Hikvision cannot?