Re: 2 questions - on feedback received from a device

I think once you have the GUI designed, it will be much easier to help
out with the prorgramming side of it.
The GUI will give great insight into exactly what you want to be able
to control.

Jarrod

On Feb 4, 3:19 pm, Carl Underwood <carleto...@gmail.com> wrote:
> On Feb 3, 10:59 pm, Jarrod Bell <jar...@guilink.com> wrote:
>
> > Hi Carl,
>
> > What is the actual device?
>
> It's an AudioBox AB64 - the command structure is detailed in section
> 11 of this document:http://hfi.richmondsounddesign.com/commandset.htm
>
> I can do basic control of the device by assuming a lot about it but,
> of course, I can't populate the lists w/o being able to parse the
> returned data.
>
> However, what you have described below bears watching; in the
> meantime, I'll work on the layout and design spec.
>
> Many thanks,
>
> Carl
>
>
>
>
>
> > There is no way to use an IP address dynamically anyway. So even if
> > you could parse it, you can't connect to it.
> > This all has to be programmed in from the start.
>
> > Generally this is where a helper app comes in which does the discovery
> > for you. guiDesigner 2.3 will be released in the coming weeks which
> > allows for people to write plugins which would be perfect for this.
> > For instance, we have written a plugin which searches for GlobalCache
> > devices on the network, then allows you to automatically add the
> > system details to your guiDesigner project, as well as automatically
> > add commands for controlling the relays, etc. All without ever knowing
> > the protocol.
>
> > If you are a .NET programmer (VB.NET or C#) you will be able to write
> > a plugin for guiDesigner to acheive this. Then once the project is
> > programmed, its just a matter of sending the correct commands to the
> > discovered devices.
>
> > This sort of protocol makes it extremely hard to use the information
> > to show feedback of data due to the complexity involved in deciphering
> > the data. In this case, we recommend using a middle-man control
> > processor, such as a Crestron box, or anything that has the power to
> > do this (even a PC running some custom software would suffice). The
> > only other option is to write an iPhone app specifically to handle the
> > protocol, which we can of course offer - but it wouldn't be cheap.
>
> > Parsing hex data to string data is perfectly fine - when the hex data
> > is captured to a serial value, it displays in plain text (so long as
> > the actual bytes are the ascii equivalents, and not some mixture of
> > bit shifting).
> > Eg. "Hello World!" would be displayed if the following hex bytes were
> > captured: \x48\x65\x6c\x6c\x6f\x20\x77\x6f\x72\x6c\x64\x21
>
> > Jarrod
>
> > On Feb 4, 2:47 pm, Carl Underwood <carleto...@gmail.com> wrote:
>
> > > Hello,
>
> > > I have a device that is controlled by sending 4 byte hex strings with
> > > the first 2 bytes as the command and the second 2 bytes as the length
> > > of the command plus the length bytes.
>
> > > Example - to scan for this device on the network, you issue to a
> > > specific port via UDP a 6EA70004 where the 6EA7 is the command and the
> > > 0004 is the length in bytes of the command plus length bytes.
>
> > > The device returns the command - 6EA7 and the total length of the
> > > returned data.
> > > For the command 6EA7 the first 4 bytes of the string is 6EA70060 and
> > > the remaining bytes are the IP address of the device and other product
> > > information.
>
> > > There are no line terminators. All commands are 2 bytes and all
> > > lengths sent and returned are 2 bytes. The returned data will vary
> > > based on the command issued.
>
> > > Question 1 - I'm at a loss on how to convert the returned data into
> > > information to display and reuse - i.e. Command 6EA7 returns the IP
> > > address of the device in hex as bytes 5 thru 8. It actually returns
> > > quite a bit more data than that but this is the current hurdle.
>
> > > C0A80102 works out to 192.168 1 2 which happens to be the IP of the
> > > device on my network.
>
> > > I'd like to dynamically use the returned IP in other commands as well
> > > as display it on the iPhone, or at some point, an iPad.
>
> > > Question 2 - Because this device is a cue based device, many of these
> > > commands return the current Show name, list, path and cue as the
> > > result of an inquiry - in hex - that would need to be converted to
> > > something humans can read and used to populate lists.
>
> > > Are these tasks possible with the current release of GuiDesigner or
> > > possible in the near future with another release?
>
> > > Or, have you a product available that would be a better fit?
>
> > > Thank you very much for any insight.
>
> > > Carl Underwood- Hide quoted text -
>
> > - Show quoted text -

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