All Activity
- Yesterday
-
HKC Quantum 70 Alarm - Full Set not working - not arming
al-yeti replied to hootenanny321's topic in !!..DIY Installers..!!
They would also need to setup your account However you would need to find someone willing to do it without a contract After all if they update your software, the 4g module you might find hard to get as no stolen ones in eBay yet lol Then you have the monthly cost of the app Will someone do it for a day rate , probably not , but maybe..... -
HKC Quantum 70 Alarm - Full Set not working - not arming
al-yeti replied to hootenanny321's topic in !!..DIY Installers..!!
Ok cool it will do a job for you then to an extent -
HKC Quantum 70 Alarm - Full Set not working - not arming
al-yeti replied to hootenanny321's topic in !!..DIY Installers..!!
By the way when you set your alarm , and trigger it as intruder , does it let you turn off the alarm straight away , or does it wait , set off the siren and then let you unset ? -
HKC Quantum 70 Alarm - Full Set not working - not arming
al-yeti replied to hootenanny321's topic in !!..DIY Installers..!!
Not really , the alarm wasn't really designed for a DIY user and ususally installed by alarm companies and installers Eg your software version is proper old , adding new devices will be troublesome , so you will probably only be able to use version 2 and below to make things work I don't think you can get the app system either without an installer or something one with access -
Thanks, I just had a nosey an looked in the System Overview On there it showed a setting called Infinite Exit - ON This peaked my curiosity even more and I went and looked in the engineers manual. I turned it OFF and now the alarm countdown works and it arms succesfully. Such a stupid thing to have turned on by default, wasted about 5 hours of my time, oh well. Thanks for rubber ducking
-
HKC Quantum 70 Alarm - Full Set not working - not arming
al-yeti replied to hootenanny321's topic in !!..DIY Installers..!!
It's waiting for you to open and close the door , because system is set to final set on the door -
Long story short, a family member used to be in the alarm industry. They had a HKC 70 Quantum kit (2 x PIRs, 1 x Door contract, 1 x SABB) they gave me for free. I setup the alarm using the engineering manual. Here is what I have done: Setup 3 zones (Hall, Lounge, Kitchen) Added RF devices (PIR 1, PIR 2, Door contact) Assigned RF devices to each zone Door Contact => Hall Zone => Entry / Exit PIR => Lounge => Alarm PIR => Kitchen => Alarm Assigned two users (each with different codes) Added proxy FOBs for each user Did a walk test, all devices work, no faults Checked battery levels on all RF devices - 100% Timers - Entry / Exit - Unchanged (default 15 seconds) When I type in my user code and select "Full Set" it just has a constant tone and doesn't seem to arm, I waited 10 minutes until my ears started to bleed, but it wouldn't arm. However if I select "Quick Arm" and test the door contacts or PIRs, it works and triggers the countdown, or alarm respectively. The software version is : 1.1.10 Any ideas?
-
hootenanny321 joined the community
-
Morning gents, We’ve been pushing hard to migrate most of our commercial clients away from legacy Wiegand and over to OSDP v2 (Secure Channel) for the obvious encryption benefits. However, I'm running into a frustrating real-world issue. In a perfect lab environment, the RS-485 backbone handles the two-way OSDP handshake beautifully. But on actual retrofits—where we are forced to reuse the client's existing, ancient 22/6 untwisted alarm wire—I'm noticing a slight, but perceptible, latency when swiping the card before the door actually fires. It feels like the reader and controller are struggling with packet loss/retries over the degraded cable before finally authenticating the secure channel. I know the textbook says RS-485 is good for 4,000 feet, but what is your actual safe distance limit when pushing OSDP over crappy legacy wire? Do you guys just bite the bullet and pull new shielded twisted pair, or are there any termination tricks (besides the standard 120-ohm resistor) to clean up the signal on old cables? Curious to hear your field experiences.
- Last week
-
Haha, well that’s a classic translation error on my end! I completely read 'home office' as a residential WFH setup, not the UK Gov Home Office. That context makes way more sense now. Thanks for the clarification, @sixwheeledbeast. You hit the nail on the head regarding liability, @sixwheeledbeast. 'You get what you pay for' is the universal truth in this industry. If a client insists on running a heavy CCTV load over their aging IT infrastructure against our recommendations, getting that formal sign-off in writing is the only way to sleep at night. @al-yeti - I'm glad (well, not glad, but you know what I mean) that you've seen that exact same issue. Murphy's Law guarantees the switch buffer will choke exactly when the incident occurs, never when the frame is empty! Appreciate the insights, gents. Good to know the headaches of existing infrastructure are universal.
- 7 replies
-
- poe
- networking
-
(and 2 more)
Tagged with:
-
Lol I meant gov home office @sixwheeledbeast However yes, agreed, I have seen this a few frames dropped just when you need it on some setups
- 7 replies
-
- 1
-
-
- poe
- networking
-
(and 2 more)
Tagged with:
-
I took "home office" as Home Office or a government building. You get what you pay for at the end of the day. If the agreement is to use existing infra, even if you don't recommend it and you have that in writing; that's up to them.
- 7 replies
-
- 1
-
-
- poe
- networking
-
(and 2 more)
Tagged with:
-
Fair point, @al-yeti. For a standard home office or a couple of basic 2MP cams, the 'plug and play' approach usually holds up fine. However, we're seeing more residential clients pushing for high-bitrate 4K/8K deployments and multi-node mesh setups where the margin for error is much smaller. In those cases, that 'constanish feed' starts to stutter during high-motion events if the hardware can't handle the micro-bursts. I guess I'm just trying to build a more predictable baseline so we’re not the ones getting called back when the owner notices a few dropped frames during a security event. In your experience, at what camera count or resolution do you usually start seeing these 'non-critical' systems actually start to break down?
- 7 replies
-
- poe
- networking
-
(and 2 more)
Tagged with:
-
Ammaari Stones joined the community
-
What setup will any of this matter? Many systems are just not that critical, even some sites which require feeds for the home office are using the existing networks they don't care that much either as long as there's a constanish feed
- 7 replies
-
- 1
-
-
- poe
- networking
-
(and 2 more)
Tagged with:
-
Just to add to my original post - I’ve been digging into the chipset specs of some common entry-level 16-port switches. It seems many share the same Realtek silicon with very limited ingress buffer depth. Has anyone noticed if moving to Broadcom-based hardware actually mitigates those 4K frame drops, or is it purely a firmware-level QoS issue? Also, I’ve been looking into STP/FTP grounding on another project today. Could induced noise from poor shielding be a 'hidden' contributor that pushes these shallow buffers over the edge during burst traffic? Curious if anyone has seen a correlation there.
- 7 replies
-
- poe
- networking
-
(and 2 more)
Tagged with:
-
sanhaowangluo started following al-yeti
-
Just to add to my original post - I’ve been digging into the chipset specs of some common entry-level 16-port switches. It seems many share the same Realtek silicon with very limited ingress buffer depth. Has anyone noticed if moving to Broadcom-based hardware actually mitigates those 4K frame drops, or is it purely a firmware-level QoS issue?
- 7 replies
-
- poe
- networking
-
(and 2 more)
Tagged with:
-
Following up on my recent post about IGMP Snooping, I wanted to share some field data regarding a performance killer that many budget managed switches hide in their spec sheets: Packet Buffer Memory. We often focus on the total PoE budget, but when deploying high-bitrate 4K or even 8K cameras, I’ve found that small buffers (under 1.5MB) on 8-port "web-managed" switches are the primary cause of random "no signal" or stuttering issues during high-motion events. My Recent Findings: Burst Traffic: When multiple cameras trigger H.265 I-frames simultaneously (e.g., a car driving through multiple FOVs), the switch buffer fills up instantly. If the buffer is shallow, the switch just drops frames, causing the NVR to lose the stream briefly. Management Lag: As I mentioned to al-yeti previously, this buffer congestion often spills over to the CPU of the switch, making the web management UI completely unresponsive until the traffic drops. The "Hull Logic" Workaround: Sometimes, strictly separating the uplinks and disabling flow control on the camera ports actually helped stability, as it forced the NVR to handle the packet pacing instead of relying on a weak switch CPU. Question for the group: > Does anyone have a "go-to" brand for 8-port or 16-port switches that actually lists their packet buffer specs and handles micro-bursts without choking? I’m trying to move away from some of the cheaper units I’ve been testing lately. Curious to hear your experiences with 4K deployments on mid-range gear.
- 7 replies
-
- poe
- networking
-
(and 2 more)
Tagged with:
- Earlier
-
Big Canary Bird joined the community
-
Following up on a great discussion I had here recently about physical network separation, I wanted to share some bench-test results regarding budget-friendly managed switches (the kind we often see coming out of the Asian markets recently). We’ve all been tempted by the price point of 'web-managed' switches for small-to-medium CCTV jobs. However, I’ve found that their implementation of IGMP Snooping and STP (Spanning Tree Protocol) is often inconsistent under heavy multicast load from 4K/8MP cameras. A few things I’ve noticed in the field: Buffer Overflow: On some 128MB buffer models, once you hit about 60% backplane capacity with constant video streams, the management interface becomes unresponsive, even if the traffic keeps flowing. Multicast Leaks: Despite IGMP being 'On', some budget firmware fails to correctly prune ports, leading to packet flooding on the uplink to the NVR. The 'Hull' Logic Fix: As al-yeti jokingly mentioned 'any old how' recently, I’ve found that for these specific budget units, disabling all 'smart' features and treating them as unmanaged (or strictly using physical separation) actually results in higher uptime. Has anyone else found a specific 'budget' brand that actually handles Layer 2 management properly without a full Cisco/Juniper price tag? Curious to hear your field experiences.
-
Haha, the 'any old how' approach definitely has its place when you're in a pinch, but physical separation is still my gold standard for sleeping soundly at night. My main reason for pushing physical over VLAN in these multi-node PoE setups is troubleshooting speed. If the client’s IT guy decides to ‘optimize’ the main office network and resets a core switch, I don't want my camera backbone going down with it. There’s nothing quite like the simplicity of a dedicated pipe that doesn't care what the rest of the building is doing. Out of curiosity, when you do go the VLAN route for these, do you usually stick with Layer 2 at the edge or do you prefer routing it at the core to keep the broadcast traffic completely isolated?
- 9 replies
-
- networking
- cctv
-
(and 2 more)
Tagged with:
-
Seperate physical network, occasionally vlan it Or think of how they do it in hull and get it to work any old how lol
- 9 replies
-
- 1
-
-
- networking
- cctv
-
(and 2 more)
Tagged with:
-
Spot on, James. It’s always the STP (Spanning Tree) or IGMP Snooping that bites you when you least expect it with managed gear. In a high-traffic CCTV environment, I’ve seen those 'optimizations' cause more heartaches than they solve. For these types of multi-node builds, I’ve found that a solid, high-backplane unmanaged switch at the edge—and keeping the 'smart' stuff strictly at the core—tends to keep the ghost in the machine away. Appreciate the feedback, guys! Spot on. 'Removing variables' is the best piece of advice anyone can give in this trade. The moment you share a backbone with a client's generic IT traffic, you're at the mercy of their firmware updates and VLAN misconfigurations. I've been pushing for fibre backbones on larger residential and commercial sites specifically for that reason—it future-proofs the bandwidth and eliminates EMI issues in one go. There’s nothing worse than an intermittent 'ghost' lag that only happens when the site IT decides to run a backup during peak monitoring hours. Dedicated is definitely the way to go for peace of mind.
- 9 replies
-
- networking
- cctv
-
(and 2 more)
Tagged with:
-
Totally get that. Managed switches can be a nightmare if the IGMP snooping or STP isn't dialed in perfectly for multicast video traffic—suddenly you're chasing 'network' issues that are actually just configuration headaches. For those budget-conscious builds, I've started leaning towards high-bandwidth 'unmanaged plus' or web-managed gear. It gives just enough visibility to see if a port is flapping without the complexity of a full enterprise stack. Keeps the project on budget and the service calls to a minimum. Do you guys usually go with a separate physical network for the CCTV, or just VLAN it off on the main house/office net?
- 9 replies
-
- networking
- cctv
-
(and 2 more)
Tagged with:
-
IrnBruMan joined the community
-
Separate network and unmanaged switches. Consider fibre for backbone. You're removing variables that way. Sharing the sites network will only mean liaising with IT departments and intermittent issues you have no control over. Fine, if your site IT on a job creation scheme not so good for us.
- 9 replies
-
- 1
-
-
- networking
- cctv
-
(and 2 more)
Tagged with:
-
Who's Online 0 Members, 0 Anonymous, 34 Guests (See full list)
- There are no registered users currently online
-
Member Statistics
-
Forum Statistics
33.5k
Total Topics448k
Total Posts