Excessive Intermittent Connection Loss with Crestron module version 4.3

[Eric]

I've finally begun testing Iviewer in-house with an iPad and have been
having excessive heartbeat connection loss issues using Crestron
firmware (v4.001.1012 build 7) with module v4.3. I can certainly make
this happen more frequently if pressing a fair amount digital joins in
succession (changing channels/guide surfing type of thing) but it will
even drop out on it's own at times just sitting idle.

I've tried quite a number of things to isolate the problem including:

- Swapped out our in-house PRO2 with a MP2e to rule out a physical
processor hardware problem
- Segmented/isolated the Crestron processor and wireless access point
from our primary network
- Experimented with autonegotiations on the Crestron processor
- Stripped down the running program to the point where I just use a
few interlocks and buffers for some basic logic experimentation. This
is just a test program.

Yesterday I decided to downgrade the processor and program to firmware
(v3.155.1240) and module v3.0 as an experiment. To my surprise it has
been rock solid with no connection dropouts. I'm curious of other
users experience and feedback using firmware v4.001.1012 and module
version 4.*

I'd really like to use version 4 as we do have a couple modules that
require it. Is there anything else I should be looking at? Any
feedback would be appreciated. Thanks.

[Jarrod Bell]

This error shows when Crestron is not replying to heartbeat messages
quick enough.
Not sure why you would be having excessive loss though, especially
using a basic program.

Can you share the full connection details, from iViewer settings,
guiDesigner connection settings, crestron settings, etc?

Do you have the 'System Manager' empty? Make sure only to define the
connection in the project properties when using a Control System
connection.

Jarrod

[Eric]

Like i mentioned, this is only when using firmware version 4 and
module v4.3. System Manager is empty. I am only communicating with a
Crestron processor (PRO2). Global Token Manager is empty.

iPad Settings:
-FW Version: 3.2
-WIFI: WPA2 (AES)
-DHCP (YES)
-IP: 192.168.1.108
-SN: 255.255.255.0
-GW: 192.168.1.254


iViewer Settings:

-Version: 3.4.0 build 115
-No Password
-File URL: http-://192.168.1.116:8019 (my workstation IP)
-Reload GUI File: ON
-Remember Last GUI File: OFF
-Preload Images: ON
-Button Press Sound: ON
-Auto Lock Delay: 1 Hour
-Proximity Sensor: OFF
-Multitasking: OFF



guiDesigner Connection Settings:

Version: 2.3.2.0
/Project Properties/Control System
-IP Address: 192.168.1.250
-Port: 8020
-Connection Join: 0
-Disconnected: 0
-Debug mode: Enabled



Crestron Processor/Project Settings:
-Model: PRO2
-Firmware: v4.001.1012
-IP: 192.168.1.250
-SN: 255.255.255.0
-GW: 192.168.1.254



iViewer Module
Version: 4.3
-Password: na
-Port: 8020
-Activity Timeout: 15d
-Debug Mode: 1


Anything I missed?

[Jarrod Bell]

That all looks perfect to me. The only thing I could think of trying
is a different iPad/iPhone.
We have had issues in the past where the culprit ended up being an iPod
Touch that didn't want to work correctly for some reason.

Also try restoring the iDevice to factory settings and reinstalling only
our app, nothing else, and see if that fixes any issues.

None of this makes sense that it works fine in Crestron firmware version
3 however, so not sure the above two steps will make any difference in
your case.

Can you check how often the heartbeat is coming in from iViewer and how
long it's taking for Crestron to send each heartbeat reply?
Perhaps a screenshot of debugger showing this info as well.

Jarrod

[Eric]

The heartbeat comes every 4 seconds and when it is responsive,
Crestron sends out the reply immediately. This screenshot was taken
with less than 5 minutes of program runtime on the PRO2 (had to re-
install fw v4.001.1012/edit program/compile/upload). I left the iPad
sit idle (no button presses) with CF iViewer open and the connection
timed out at [13:59:20]

https://dl.dropbox.com/u/608731/toolbox.jpg

I take it I'm the only one that has experienced this issue with v4?
I'll create a small program for my iphone4 and see if i get the same
connection dropout results.

[Eric]

Confirmed the iPhone 4 is also dropping out just as often so I don't
think it's a device problem.

[Jarrod Bell]

I will do some extensive testing tomorrow (AFL grand final today, zero
work happens usually) and get back to you on this one.
It does look like an issue on our side from everything you have shown
(thanks again for the detailed reports, wish everyone gave such detailed
info!)

Jarrod

[Jarrod Bell]

I just did some extensive testing and could not reproduce your
problem.
I had it running for over 10 minutes fine without an issue (iPad set
to never sleep).
Then I tried with iPad set to sleep after 2 mins and it disconnected
when the WiFi went to sleep.
Then as soon as I woke up the iPad it connected and worked fine. The
'intermittent connection' warning only showed for a split second when
reconnecting but promptly disappeared.

I also tried with 'reload GUI file' on and off. No difference, always
works perfect for me. This is when using the demo program available
from our Google code repo.

Just did another test, for over 40mins, with the 'auto lock delay' in
iViewer settings set to 1 hour, and no problems at all with the
connection.

The only thing I can think of is your networking hardware. Can you try
with a different access point and/or router? All our testing is done
with an Airport Extreme access point and linksys routers.

Jarrod

[Eric]

I've tried it on a standalone,segmented Buffalo Technologies (WHR-HP-
G54) as well as an Asus (RT-N16) and on our own primary WLAN using a
Ruckus (Zoneflex 7363). All 3 are using (WPA2 AES) encryption. Do you
use the same?

I'll start a new Crestron project from scratch to ensure there's no
odd corruption that could have occurred and will also re-compile the
iviewer usp module. Will report back....

[Jarrod Bell]

I use WPA/WPA2 Personal mode in my Airport Extreme settings.
But I'm sure many customers would have had the same issues if it's a
common wireless security setting that's at fault, which we haven't had
reports of.

Very keen to figure this one out, as I'm sure you are too.

Jarrod

[Josh]

I am also experiencing this same issue. Has there been any
resolution?

> >>>> Theheartbeatcomes every 4 seconds and when it is responsive,

> >>>> Crestron sends out the reply immediately. This screenshot was taken
> >>>> with less than 5 minutes of program runtime on the PRO2 (had to re-
> >>>> install fw v4.001.1012/edit program/compile/upload). I left the iPad
> >>>> sit idle (no button presses) with CF iViewer open and the connection
> >>>> timed out at [13:59:20]
> >>>>https://dl.dropbox.com/u/608731/toolbox.jpg
> >>>> I take it I'm the only one that has experienced this issue with v4?
> >>>> I'll create a small program for my iphone4 and see if i get the same
> >>>> connection dropout results.
> >>>> On Sep 24, 2:23 pm, Jarrod Bell<jar...@guilink.com>  wrote:
> >>>>>    That all looks perfect to me. The only thing I could think of trying
> >>>>> is a different iPad/iPhone.
> >>>>> We have had issues in the past where the culprit ended up being an iPod
> >>>>> Touch that didn't want to work correctly for some reason.
> >>>>> Also try restoring the iDevice to factory settings and reinstalling only
> >>>>> our app, nothing else, and see if that fixes any issues.
> >>>>> None of this makes sense that it works fine in Crestron firmware version
> >>>>> 3 however, so not sure the above two steps will make any difference in
> >>>>> your case.

> >>>>> Can you check how often theheartbeatis coming in from iViewer and how

> >>>>>>>> having excessiveheartbeatconnection loss issues using Crestron

[Jarrod Bell]

I havent been able to reproduce the issue. If someone can come up with
a test case (without any fluff in a program so we can clearly see the
problem) then we can get it fixed.
But everything works fine for me (and just about everyone else I assume,
no other reports of this yet)

Jarrod

[Adam Zatorski]

I would turn encryption off and re-test. I didn't see this in the
earlier post, sorry if its been done already. If it works use a
combination of WEP + mac filtering for security. I had to do this with
my iPad when it first came out as a workaround for the wifi issues.

Adam Zatorski
King Systems LLC
Audio/Video Design & Installation
Certified DBE, MWBE & SBE
www.kingsystemsllc.com

> --
> You received this message because you are subscribed to the Google
> Groups "CommandFusion" group.
> To post to this group, send email to comman...@googlegroups.com.
> To unsubscribe from this group, send email to commandfusio...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/commandfusion?hl=en
> .
>

[Eric]

I didn't want to post until I've found a conclusive answer why but
since others are having the same problem, here's what I've found to
this point:

I've started out developing our CF template for multi-room audio
control. While I had very little logic in my program, I am using a
BIPAD8/PAD8A.umc module, which I've used for years, in the program and
developed the rest of the UI logic around this. This module appears to
be what causes the iPad to drop offline frequently. Removing it
solidifies the connection. I've used this module numerous times in the
last year on Crestron firmware 4.0+ with no problems.

I have yet to get one in-house to rule out this theory but I actually
do NOT have a BIPAD8 or PAD8A connected to our PRO2 processor.
Obviously feedback doesn't function correctly but I wouldn't have
thought I'd have ethernet socket connection issues because there was
no switcher on the Cresnet bus.

As soon as I get a switcher for testing, I'll report back my results.

[Jarrod Bell]

If there is a endless loop in the MAIN function of the module, such as
a while(1), this will not allow the processor to jump to our module fast
enough for heartbeat replies.
Bad programming practice by the module writer by the sounds.

Jarrod

[Eric]

This is a completely SIMPL based user module, no SIMPL+ logic at all.
If you'd like to look it over, I made it available:

http://dl.dropbox.com/u/608731/BIPAD8-v1.5.umc

[Jarrod Bell]

Just testing Josh's GUI again, he had a system on 255.255.255.255 TCP
maintain connection - this was causing issues. Never use
255.255.255.255 on TCP, only UDP.
For loopback systems, use 127.0.0.1

Jarrod

[Eric]

I had a chance to test my code and module with a physical PAD8A
connected and still had the same result. I'll have to further diagnose
that SIMPL user module and see what I can find. It just seems really
odd that Crestron firmware (v3/CF v3.0) is stable but (Crestron v4/CF
v4.3) is not.