I’ve been wanting to upgrade the memory in my QNAP NAS for quite some time. They are great machines, but with all the extra features in the Turbo Station UI as well as a bunch of .qpkg add on’s they can sometimes get a bit bogged down.
I had been reluctant to buy new memory as I had trouble finding much helpful info on the QNAP forums as to what to get, or if it was even possible to be done on a 459 Pro+. Eventually I got sick of performance issues and searched again, this time with a bit more luck.
There are plenty of posts around using Kingston memory, and ones that had failed, but thanks to a post on Cyconet blog I decided to go ahead and get a Samsung M471B5773DH0-CH9 module.
The install went fine, swapping out the ADATA module from QNAP as the 459 Pro+ doesn’t have a second memory slot like some of the newer models. Here you can see the memory hiding in there to the right of that big power supply plug.
Powered up and ensure all my normal services were running and I’ve got a decent increase in speed and a lot more free memory now, with usage down from around 70% to around 45%.
This memory module has also been confirmed to work in other models, as suggested by Jamie Austen on his blog, where he was able to upgrade from 1GB to 3GB – also thanks to that Cyconet post.
The problem most small businesses have with their security setups is that they are reactive. They can only look at the video once something has happened, rather than using real time remote monitoring and motion detection alerts. Let’s face it – that’s why most get these cheap eBay systems – the appeal of smartphone apps and all they promise at a fraction of the cost of a full blown ‘professional’ installer. Most of the time the ‘professionals’ are just glorified labourers installing cheap eBay systems that have been rebranded anyway.
Sadly, theres a little bit of networking knowledge needed to get everything set up correctly – which ironically the ‘professionals’ don’t know either (but most teenagers do). Dynamic DNS or static IPs, UPnP, static DHCP, port forwarding – it’s all such a headache. And often end users have not tested their motion detection settings are working properly, so may not get the crucial video they need.
So here’s the breakdown to get things working:
The router and external network traffic
This is one of the most tricky parts and what the ‘pros’ don’t know. Getting traffic from the internet into the premises and back again. So lets start with that first. Without that working, all else is in vain.
Note: Is say router, but I mean any combination of modem/router onsite that is between the DVR and with wider web.
Get access to the router. Make note of the admin username and password – will need them later.
Make a note of local IP range, gateway etc.
Turn on remote administration. Make note of the remote admin IP address and port. Make note of the admin username and password if different to the previous one.
Check if they have a static IP – probably not, so look for the DDNS section and what service providers can be used.
Check if UPnP is supported and on. Some people think UPnP is a security threat, but not really for most small businesses – who’s going to hack them and what for? Too much effort really.
See if you can identify the IP address of the DVR and note that down. If there isn’t one, or you can’t tell what’s what – it may not even be connected to the network yet – deal with that later.
If required, sign up for a DynDNS or No-IP domain. Make note of the full domain, username and password. Go back and enter these into the DDNS section in the router.
Test dynamic DNS is working by setting port forwarding to a device with a know working web server. Open a browser – success! (or troubleshoot dynamic DNS or web server until there is success).
The DVR DHCP and remote access
These DVR’s are actually quite snazzy, for simple bits of hardware and their embeded software is really quite good for what it can do. Just sometimes gets a little lost in translation. Have a poke around both the hardware and GUI. Get familiar – look for the ‘Network’ section in the GUI, which is where we will get this thing connected to the outside world.
Keep an eye out for UPnP (turn it on if you find it) as well as remote admin user/pass and access ports (TCP) for admin and video. Make a note of these – you will need them later.
OK, let’s get cracking:
Check all cables are connected firmly and the network cable is attached, with lights flashing on the network port to confirm connection. If there are no lights check the cable is connected to the router.
Log in the the admin GUI and find the ‘UPnP’ and ‘Network’ sections. If there is a ‘UPnP’ section, start there.
Enable UPnP if it isn’t already, and if you have confirmed the modem supports UPnP. Reboot the device – UPnP magic should take care of the rest. Proceed to test setup some apps, but using the local IP of the DVR first then the dynamic DNS address.
If UPnP fails or is unreliable, use a static IP for the DVR and set up port forwarding in the router. Go to the ‘Network’ section in the DVR GUI and disable dynamic DHCP, then fill in the details for the router (that you noted down earlier…). Reboot the device.
Log in to the router and check you can see the device and it has the IP address you just set via the GUI.
Set port forwarding to the DVR remote access ports (that you noted earlier).
Download and test apps/troubleshoot using the local IP of the DVR first then the dynamic DNS address.
Document everything. Most important.
That’s really all there is too it – in writing. In practice there’s all sorts of quirks to deal with – different modem configs, different DVR configs, no manuals etc. Just make clear notes of everything as you go, or better yet, document as you go.
1. Go to andhttp://www.google.com/fonts/ pick the fonts you want.
2. Go down to Step 3 and on the Standard tab copy the href ie ‘http://fonts.googleapis.com/css?family=Open+Sans’ and paste in a new browser tab.
3. Copy the text shown on screen
4. Go to Dreamweaver and create a new .css file, paste in the text you just copied. Done.
The motion detecting, detection threshold Settings
Support& nbsp;Email, FTP etc alarm inform way
DC 5V/2.0A (EU,US,AU adapter or other types optional) ，
Power Consumption ﹤8 Watts
Audio Input/Output Interface
One audio input jack,One audio output jack.
One 10/100Mbps RJ-45
Horizontal:300° & Vertical: 120°
One& nbsp;SD CARD Instructions，One power Instructions
0° ~ 40°C (32°F ~ 104°F)
10% ~ 80% non-condensing
-10°C ~ 60°C(14°F ~ 140°F)
0% ~ 90% non-condensing
768g(color box size:200*120*175mm)
2.0GHz or above (suggested 3.0GHz)
256MB or above (suggested 1.0GHz)
64MB or above
Microsoft Windows 2000/XP, Vista, Windows7, Mac OS, Linux
IE6 and above version or compatible browser, Firefox or other standard browsers
Limited 2-year warranty
Like most of these things, they are OEM and then someone else makes them popular. Such is the case here – I have Wanscam ones (Model AJ-C2WA-C118 or JW0008 – they appear to be the same), but Foscam are the popular ones at 3 times the price. Go figure.
I wanted to update the firmware, but didn’t want to brick them. Turns out it doesn’t really matter – firmware from Wanscam is branded with Foscam logo. So for firmware or manuals, go to the Foscam site. Firmware for FI8918W (currently loaded 184.108.40.206) works well.
It’s worth noting that the WebUI firmware from Foscam (220.127.116.11.001) is worse than an older Wanscam one (18.104.22.168).
———- Update 27/01/2014 ——–
Just updated with the latest firmware firmware from Foscam’s Australian site, released on Jan 23. Now on Firmware 22.214.171.124 and WebUI 126.96.36.199 (both Foscam ‘official’), both working like a charm.
———- Update 23/06/2014 ——–
Firmware 188.8.131.52 and Web UI 184.108.40.206 are now available on the Foscam site. Both work fine for me. FWIW I can’t seem to find firmware from Wanscan anymore.
———- Update 02/01/2016 ——–
Firmware220.127.116.11 and Web UI 18.104.22.168 are now available on the Foscam site. Both work fine for me.
NOTE: This device probably works fine without the FTDI D2xx drivers. Test with sample code found here. I tested via the AdaFruit WebIDE.
You can find the ttyUSB device the RFID reader has been assigned to by doing ‘dmesg’ after plugging it in. You should see something like this, indicating I’m on ttyUSB4
[173832.871279] usb 1-1.3.4: new full-speed USB device number 13 using dwc_otg
[173832.995485] usb 1-1.3.4: New USB device found, idVendor=0403, idProduct=6001
[173832.995518] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[173832.995535] usb 1-1.3.4: Product: FT232R USB UART
[173832.995550] usb 1-1.3.4: Manufacturer: FTDI
[173832.995565] usb 1-1.3.4: SerialNumber: AD01SU55
[173834.105994] usbcore: registered new interface driver ftdi_sio [173834.112869] USB Serial support registered for FTDI USB Serial Device
[173834.120217] ftdi_sio 1-1.3.4:1.0: FTDI USB Serial Device converter detected
[173834.122730] usb 1-1.3.4: Detected FT232RL
[173834.122783] usb 1-1.3.4: Number of endpoints 2
[173834.122820] usb 1-1.3.4: Endpoint 1 MaxPacketSize 64
[173834.122839] usb 1-1.3.4: Endpoint 2 MaxPacketSize 64
[173834.122855] usb 1-1.3.4: Setting MaxPacketSize 64[173834.130135] usb 1-1.3.4: FTDI USB Serial Device converter now attached to ttyUSB4
[173834.130268] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
If you find everything is working fine, you probably don’t need to do the following steps. I had already done them before I figured our how to check ttyUSB value.
NOTE: as of this writing the RasPi compatible version did not work, so I used the one here.
During installation it says to do ‘sudo rmmod ftdi_sio’ and ‘sudo rmmod usbserial’. I did ‘sudo rmmod ftdi_sio’, but don’t know if it was required. ‘sudo rmmod usbserial’ threw an error saying it was in used by pl2303.
I couldn’t figure out which ttyUSB device was my reader and noticed in dmesg the following, indicating the device had been detached when I did ‘sudo rmmod ftdi_sio’. This also suggests it would have worked fine without the FTDI D2xx drivers. That caused me some problems during testing.
[193184.440517] USB Serial deregistering driver FTDI USB Serial Device
[193184.445448] ftdi_sio ttyUSB4: FTDI USB Serial Device converter now disconnected from ttyUSB4
[193184.445607] usbcore: deregistering interface driver ftdi_sio
[193184.445802] ftdi_sio 1-1.3.4:1.0: device disconnected
Once I restarted the Pi everything worked fine, found the ttyUSB ID from dmesg and tested with the sample code, which successfully printed the RFID tag number
‘dmesg | grep FTDI’ shows the following, showing that ftdi_sio is back in use again but on a different ttyUSB ID.
[ 5.010753] usb 1-1.3.4: Manufacturer: FTDI
[ 8.358161] USB Serial support registered for FTDI USB Serial Device
[ 8.546943] ftdi_sio 1-1.3.4:1.0: FTDI USB Serial Device converter detected
[ 9.222204] usb 1-1.3.4: FTDI USB Serial Device converter now attached to ttyUSB1
[ 9.375986] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
It’s probably a good idea to add persistent names for USB devices to overcome the ttyUSB issue in future. This can be done with udev rules, with a great article about it here
See related project here with sample code here, which will be handy starting point for my door lock project.
Install the latest version of Node.js – installed version is 10.5. This should be done last to override the version of Node installed by both WebIDE and PiJS.io, however only this step would be needed for the final build SD cards.