PC Access 3.14a is out, along with OmniTouch FW 1.7

jcd

Active Member
We're testing now... hopefully this was "worth" the wait and fixes all that was broken :-\
 
Cheers,
Jcd
 
I upgraded firmware and software this morning.  Here are the release notes.
 
Personally here have not had any issues with my little microrouter fix.  Time, serial, network and other stuff have been stable.
 
Updates found:
    PC Access 3 (Dealer) English/Italiano/Espanol
    Version: 3.14.1.759

HAI OmniPro II Version 3.14a (English)
Checking for new OmniTouch 7 firmware files...
New OmniTouch 7 firmware found:
OmniTouch 7 Version 1.7 (99A00-1/2)

Checking for new Omni Notifier Board firmware files...
New Omni Notifier Board firmware found:
Omni Notifier Firmware Version 1.1

PC Access Version 3.14.1.759 (27/October/2014)

- Controller firmware 3.14a released:
  - Improved TCP connection handling.

- OmniTouch 7 firmware 1.7 released.
  - Improved TCP connection handling.
  - Added Pop-Up Camera support.
  - Added Dealer Info support.

- Fixed problem where E-Mail Notifier Board MAC address could be changed during a firmware update.
 
 
The camera pops work, but they are sluggish. For example, if the installation has multiple cameras, say around a perimeter of a home, and you're trying to track motion as someone walks from area to area, it doesn't really work because it's not fast enough. What happens is you'll get a black screen saying, "Establishing Connection" as the OT7 attempts to connect to the camera's IP. It takes about 4-5 seconds to connect each and every time.
 
So, it's workable if you have just a camera or two and use it for infrequent activity, but it's not usable for anything more robust.
 
If this is evidence of the "Improved TCP connection handling." then I'm not impressed! Maybe what they improved is that the OT7 units themselves don't drop connection as often. That remains to be seen...
 
Oh well. I'd like to say that at least it's something... but it took them six months to release this, so I'm not pleased and this doesn't really give me anything to "Wow" my customers.
 
One thing that that would be nice to tidy-up the code in PCA is if the touchscreen names carried over: you can name them in the setup (e.g. "Kitchen"), but then when you write events in the automation tab it only shows, "Touchscreen 1", "Touchscreen 2" etc - so you basically have to memorize the list of assigned camera locations (e.g. Touchscreen 1 = Kitchen, Touchscreen 2 = Office, etc.)
 
I would guess that IP camera issue would be standard with anything other than a dedicated server setup.
That is a difference between analog and IP cameras.
 
In order to have immediate hot switching among multiple IP cameras you would have to have an existing connection to the streams. 
That requires bandwidth. 
That would be wasted bandwidth 99% of the time.
 
The hardware on the touchscreen may not be able to handle multiple simultaneous connections either.
 
Yeah, Desert_AIP, good points.
 
When I install IP cameras, I install dedicated switch fabric for them so that they are off the main IP switch. Usually a Cisco POE switch feeds the cams and NVR, then a separate switch linked for regular IP traffic. I like analog for the reason you note, but POE is just too tempting and the cabling is so much easier to manage with Cat6 than coax and power.
 
I'm going to see if we can't come up with some clever coding to blunt the impact of switching from camera to camera quickly. For example, to start a timer/flag with each trigger and only have the code switch to that camera ever X seconds. Otherwise, what happens is if you have a motion sensor going off, then the OT tries to switch to that stream with every trigger, even though it may be the same sensor (and thus camera) over and over.
 
Cheers,
Jcd
 
UPDATE:
 
We've been testing this at one of our customer installations today and can confirm that the camera pop "feature" is essentially worthless.
 
The OT7's pop the cameras maybe 1 in 10 times at best - the rest of the time they just display the black screen with "Establishing Connection".
 
We've tried narrowing-down the code so that only a single OT7 pops for any given event, but that has no effect different than having 8-9 OT's pop at once (theoretically, since they rarely pop at all).  We wrote code so that they only pop once per trigger no more frequently than every 15 seconds or so, but this too had no performance improvement.
 
The OT7's are on a dedicated Cisco SG200-50P POE switch with the cameras and NVR. The cameras (6 at present - to be expanded IF we can get this working adequately) are Toshiba IK-WD80A and IK-WD81A - they are 2MP 1600x1200 POE IP cameras and they are also fed into a Toshiba ESV16U.  We have plenty of bandwidth on the LAN backbone.
 
Any ideas to give these "always on" connections? We'll do dedicated subnets if we have to. QOS?
 
This is incredibly frustrating and disappointing to have waited six months for this and have the problem not anywhere close to being solved. Thanks Leviton. Please "unsell" HAI...
 
jcdavis,
 
- Have you tried going to each camera manually? Does it work each time switching between cameras?
- I'm not familiar with the ESV16U. Have you tried a different NVR or IP Camera?
- Many IP Cameras and DVR's have a limit on the number of simultaneous MJPEG connections, have you verified with Toshiba that this NVR can support multiple MJPEG sessions?
-----One way to test would be to manually change it OT7 to the same camera feed and see if they all can connect.
-When you say "pop the camera", do you mean you see video? And other times it jumps to the camera display page, but no video?  If so, that tells me that each OT7 is actually receiving the command from the Omni to display the camera, just for some reason they are unable to connect to the NVR.
 
aard3 said:
Hi Aaron,
 
Thank you for your reply. Comments below:
 
- Have you tried going to each camera manually? Does it work each time switching between cameras?
Yes. Each and every OT7 connects to each and every camera very quickly when selected directly. It takes maybe a second, usually half that when selecting the camera directly from the OT7: they come right up, and users can switch between them with no problems.
 
- I'm not familiar with the ESV16U. Have you tried a different NVR or IP Camera?
No - only because this is what we installed for the client, so that's what is there. There IS actually a Panasonic PTZ camera on the system as well. This one takes longer to connect (as it always has) because it needs to login and be authenticated whereas the Toshiba cameras are not authenticated so they just connect right in. But none of this behaviour is affected by the attempt to get the OT7 screen pops working.
 
- Many IP Cameras and DVR's have a limit on the number of simultaneous MJPEG connections, have you verified with Toshiba that this NVR can support multiple MJPEG sessions?
-----One way to test would be to manually change it OT7 to the same camera feed and see if they all can connect.
The Toshiba cameras support 4 simultaneous streams. We have one stream being pulled by the NVR, while the OT7's pull from another stream. The thinking was that stream 1, for example, would be used by the NVR in full 1600x1200 resolution for recording and archival, while stream 2 would be pulled from the OT7 in lower resolution of 640x480. We've tried multiple different resolutions though, and both JPEG and MJPEG and there is no difference. It would seem that even if a stream if set to 1600x1200 that the OT7 will downscale it to its native resolution. But in any case, ALL settings work perfectly fine directly from the OT7, but just won't reliably connect when using the new 3.14a and 1.7 camera pop functionality. 
 
-When you say "pop the camera", do you mean you see video? And other times it jumps to the camera display page, but no video?  If so, that tells me that each OT7 is actually receiving the command from the Omni to display the camera, just for some reason they are unable to connect to the NVR.
No, we just get the black screen saying "Establishing Connection". Sometimes we'll get video after a second or a few seconds, but if we do, it'll show up on one OT7 but not all of them. A different one each time. Mind you, the cameras do NOT go first to the NVR, and then to the OT7; the NVR and the OT7's are all on the same POE switch, segregated from the regular LAN traffic, but each is in a discrete "star topology" if you will.
 
Are the OT7's pulling these video streams natively, or are they going first through the OmniPro II controller? I ask because I could see that being a bottleneck if all of this bandwidth needed to first funnel into the OmniPro before being distributed out to the OT7's.
Anyone else out there having similar issues? If not, and the screen pops are working without problems, would you kindly share your details of camera type(s), settings, NVR presence/details, and switch topography?  I'd be very keen to know if other installers/users are having similar issues and if this is NOT the case and it's just this particular configuration, then I think we're happy to look at replacing the cameras and/or NVR we use for these systems - I just need some feedback from others on what actually works please.
 
Many thanks,
Jcd
 
Here I am still using the Omnitouch 5.7e's with a mixture of using direct IP DVR camera and IP HD camera links and all is fine. 
 
NVR = = > IP camera links configured in PCA == > Omnitouch 5.7e's
 
I also utilize the old HAI camera hub going to the Omnitouch 5.7's.  This is to a mixture of analog and HD IP feeds back into the hub using a Grandstream encoder / decoder. 
 
There is a lag to the first camera view; then afterwards its quick.  I am using the over the shelf Omnitouch 5.7e configurations with no mods.
 
Omnitouch Pro (for wintel) doesn't work with any cameras. (I have made mention of this for the last couple of years).
 
OT7's are pulling the streams directly from the URL that is provided in Extended Setup. (It should be from a NVR or directly from IP Camera depending). The Omni just acts as a repository for the URL, Username, and Password information.
OT7's will scale down the images, but
1.) It takes more bandwidth to send those big JPEGS
2.) It takes processing power to render them.
I don't think that is your issue, but theoretically it could slow things down some, I wouldn't expect it to have the type of impact you are reporting though.
 
jcdavis said:
Anyone else out there having similar issues? If not, and the screen pops are working without problems, would you kindly share your details of camera type(s), settings, NVR presence/details, and switch topography?  I'd be very keen to know if other installers/users are having similar issues and if this is NOT the case and it's just this particular configuration, then I think we're happy to look at replacing the cameras and/or NVR we use for these systems - I just need some feedback from others on what actually works please.
 
Many thanks,
Jcd
 
For what it's worth, this is my install at home:
 
Leviton 8 Port POE switch (10/100), which is connected to a Cisco 100/1000 24 Port switch. Leviton mini Dome POE cameras and OT7's are connected to the POE switch.
 
I did some testing last night, and changed my programming so that when just about any Zone goes NOT READY, I display a camera on an OT7. The camera pops up so quickly that you barely see the "Establishing Connection" image.
 
Can you run a test with one OT7 connecting to a camera? Basically turn off the NVR, and have only one OT7 connecting to the camera, and see if the performance is there, then start adding things back one at a time?
 
Just an aside, I use cameras with multiple streams and I use a very low resolution stream with my 5.7es but record a high resolution stream to the NAS.
 
UPDATE:
 
I stopped by only briefly to the client late today but didn't have a lot of time. I just wanted to check a few things to try to get them going but set aside time tomorrow for another visit. Here's what we did today:
 
1) Reconfirmed that camera selection and switching between cameras manually right from the OT7 works fine. It's almost instant when we select the "thumbnail" view, and when the image is clicked for a full-screen render it takes maybe a half-second at most (i.e., we see the black "Establishing Connection" screen for a fraction of a second and then the camera image.)  This works dead-reliably every single time from any touchscreen and for any camera. 
 
2) We disconnected the DVR and tested again, same performance.
 
3) We tried changing every variable on the PCA setup screen - changing MJPEG to JPEG, changing the FPS rate to as low as one, changing the quality to "low" or "medium", and even tried changing the resolution. None of these changes had any effect whatsoever on the reliability of the touchscreen connecting to the camera stream.
 
4) We tried each of the following format strings for the URL (changing MJPEG to JPEG where needed):
I've attached a partial screenshot of a few lines of the PCA Setup screen just to show how things were setup originally (before the changes noted above, and this is the configuration that otherwise works perfectly for manual selection from the touchscreens)
 
None of the above changed the problem. Directly from the touchscreens, the cameras access fine, but when triggered by logic events they connect maybe 1 in 10 times and if/when they do, it is only on some screens.
 
The only thing we did NOT do today is muck around with the network switch cabling.  Even the high-end Cisco 50-port gigabit POE switch we installed, like most POE switches has only a partial # of ports that are actually POE and because of this and the vast # of POE devices on the network, we have the system split into two POE switches - one of which has the IP cameras on it, while the other one has the touchscreens and some other network equipment like access points, etc.
 
I don't know why it would matter, but when we go back tomorrow, we can try to put a camera and a touchscreen on the same physical POE switch and see if this has any impact. While the switches are "managed", they are in stock configuration and we have done nothing to set up any traffic rules, etc, so I would think that from an IP perspective all the connections are peer-to-peer regardless if they are on different physical switches. And besides, as mentioned, everything works perfectly when selected right from the touchscreen, it just doesn't work through events driven from PCAccess - so I can't see this as being a network fabric issue, or frankly even a bandwidth issue.  It's very strange.
 
We'll be onsite tomorrow afternoon again.  I warmly embrace any other ideas or suggestions for troubleshooting!
 
Many thanks,
Jcd
 
 

Attachments

  • Capture.PNG
    Capture.PNG
    21.3 KB · Views: 33
Okay, this afternoon we reconfigured the switches such that ALL the HAI stuff was on the same Cisco SG-200-48 POE Managed switch. This means that all the OmniTouch screens, all the IP cameras, the OmniPro II, the HiFi2 and the NVR were all on the same piece of physical switch hardware.
 
No difference.  The cameras still connect on events only once in a while.  They all connect instantly when selected directly from the touchscreen.
 
HAI, would you PLEASE test this and see if there are other configuration parameters required to get this to work? The fact that they work instantly and consistently when selected directly from the touchscreen implies that there is something about the way the OmniProII and/or PC Access event code is hailing these when triggered. I can see no other cause given the circumstances we've tested out.
 
Or maybe this system is just not designed for a sophisticated multi-touchscreen, multi-camera installation? If the HAI design target is a very simple system with only a touchscreen or two and a couple of cameras, this would be good to know also.
 
Thanks,
Jcd
 
I finally got a chance to update everything to the latest and try out the pop ups on my OT7. Works really well. SJ
 
Back
Top