To produce pulse output is not difficult at all – simply do this:

Pulsed Time-Duration Output

Outputs may also be set to deliver a time-duration “pulse”, changing the state of an output for a brief period, then resuming the original state. The format for pulsed output is shown below, with a number — and the number represents pulse duration in 10’s of microseconds.

Example:
..to set channel H low for 1/2 second, then resume high state, the “msgbody” entry would be:
ALH 50000

For further details, please refer to the AlphaSense 14-Channel I.O module instruction page in your AlphaSense online users manual.

Simply enable the “heartbeat data not-found” feature in the AlphaSense configuration file, define a time interval for the desired data to be received, and set up message delivery using a ruleset with the activeflag value set to “6″ (see the AlphaSense “rules file details” provided with the product, or on our website, for details).

If the data you specify is not received by AlphaSense  withing the specified recurring time interval, the messaging you define will be activated.

This is a very powerful feature to insure that equipment connected to AlphaSense is “alive” and can be used to verify many things, totally automatically, and deliver status mesages to designated recipients, no matter where they are.

Of course!

Just use the AlphaSense email entries within any ruleset, and in the ruleset emaddr field, enter the recipient’s address in the following format: 10digitphonenumber@txt.att.net

easy and done!!

This feature may be enabled or disabled at any time for each separate messaging rule. When enabled, a timestamp text block is appended to the end of the designated message content.

Details on how to manage the email timestamp feature may be found in the (always helpful) Ruleset Detail File version 4.60 or higher.

The Direct-Connect feature package provides support for direct-connection to paging and other wireless messaging transmitters. While previous AlphaSense versions have also supported interfacing to in-house and on-site messaging sytems via their modem interfaces, the AFN_DCP will enhance AlphaSense for these applications. The overall performance elements of AFN_DCP are the same as the Dialout feature package, with the dialout modem support being replaced with direct-connection capabilities.

AlphaSense has been designed using a modular approach, and various “feature packages” allow customers to populate their AlphaSense system with just the features and capabilities that suit their application, and not be burdened with the costs of unwanted features being included in a “one platform does it all” solution.

Feature packages may be added at any time, and the overall AlphaSense firmware is also upgradeable at any time.

AlphaSense features have included the capability to deliver message content in the form of an SNMP v1 Trap among the choices of format and method of sending message content data from AlphaSense units. That has now been expanded to include the trap constructs Notification and Inform.

The Inform traps are especially powerful, in that they expect a response from the receiving destination machine, which serves to validate reception of the original sent trap containing message data. If no response is received within a timeout period, AlphaSense will look for and process a ruleset having its activeflag field set to 7, so that an alert message can be delivered via an alternative method to a different recipient. This can provide realtime monitoring function for the network and even for the SNMP host itself.

Complete information on the AlphaSense SNMP  inbound and outbound features may be found here.

If your AlphaSense application needs non-printable characters included in certain message content, contact Compuquest, Inc. and we will assist you. We can easily generate the required message string for you, and if you are technically inclined and can work with hex characters and binary editors, we can show you how to do it yourself. Once the message string with the desired special character(s) is created, it may be saved and simply pasted in the ruleset msgbody field the same as any other fixed-content message.

AlphaSense MIB

An additional and expanded use of this feature is to provide for “failover” messaging within a regular messaging ruleset. If, for example, the desired method of messaging is via network email, and the connectivity daemon currently indicates that network connectivity for the outbound email delivery server is not available at the time the message needs to be sent, AlphaSense will “failover” and deliver the message using modem dialout instead. Otherwise, if network connectivity was ok, the message would be delivered using a network delivery method, and no modem dialout messaging would be done.
The next (and each) time message delivery is triggered for that particular ruleset, message delivery will be made using network email or other network method – unless network and/or server connectivity is lost. In that case, modem dialout will continute to be used until network and server connectivity is restored.
Of course, modem dialout delivery may be specified as a message delivery method in any ruleset (with or without some other network delivery method being included), but setting the rule for “failover” provides an added dimension of insurance to get the message delivered.

The answer is an emphatic YES, and there are many who are and have been doing just that.

There is high security designed into AlphaSense, ports not required are stealthed, and the user has complete ability to choose and implement strong password protection for browser access.