PDA

View Full Version : Arcam AVP700 serial control question



kurtlewis
April 15th, 2006, 02:44 AM
OK Promixis team, I'm ready to take the gloves off and see if I can make real first use of G4 by serial controlling my Arcam AVP700. I recently picked it up from my business partner (who is an authorized dealer) and I have to say it sounds equally as sweet for movies and sounds better for music than my Theta CasaNova. A heck of a pre-pro for $2k retail, I highly recommend it. It even has balanced outputs.
Anyway, I digress... (I'm such a kid when I get new toys...)

Attached is the handbook for the AVP700. On page 35 it explains the serial format and specs out the commands. Should this work fine through G4?
I'm reading the docs on how to do this in G4, but I am a long ways off- anyone care to help or provide a similar lua / gml that i can mod?

If I can get this done i'll definitely post the files up on the site with an example ccf

-Kurt

Rob H
April 15th, 2006, 05:12 AM
Doesn't look too difficult - if Mike doesn't beat me to it later on today I'll post a simple serial device to get you going.

kurtlewis
April 15th, 2006, 09:49 AM
That would be awesome- Thanks!

-Kurt

Promixis
April 15th, 2006, 09:08 PM
Doesn't look too difficult - if Mike doesn't beat me to it later on today I'll post a simple serial device to get you going.

Maybe in the moring... still hung over from bday party last night :P

Rob H
April 16th, 2006, 04:47 AM
Okay - here's an example serial device which has functions defined for Mute, Unmute and AskMuteStatus.

It should be fairly straighforward to add the rest. If you need some help with handling responses let me know.

kurtlewis
April 16th, 2006, 11:25 AM
Awesome Rob, this is just what I needed. Many thanks!
I added a bunch of settings to the lua so I think I have the hang of it. (attached)

Now for some thick-headed questions...

I know to drop this lua into G4, - Do I need to set up a gml file as well, or will I call on this directly from NR?

How do I set up views for the responses from the arcam in NR? for instance, I'd like to have it display live status of volume, mute, surround mode, input- you know, the usual...

Do I need to add anything else in these below sections of the lua? you have commented to 'add stuff here' but i'm not sure what to add, if neccessary:

Initialize = function(self)
if serial.Classes.Simple.Initialize(self) then
-- add your own initializations here <--?
self.Status = 'Initialized'
return true
end
end,

ReceiveResponse = function(self, data, code)
if math.band(code, serial.RXCHAR) then
-- add code here to process the data parameter <--?
end
serial.Classes.Simple.ReceiveResponse(self, data, code) -- must call the parent's ReceiveResponse
end,

Rob H
April 16th, 2006, 12:06 PM
Now there's a lot of questions!

You'll need to add some code to ReceiveResponse() certainly.

The responses always start with "AV_"

So you'll start with code something like this :-


local _, _, replyCode, answerCode, p1, p2 = string.find&#40;data, 'AV_&#40;.&#41;&#40;.&#41;&#40;.&#41;&#40;.&#41;'&#41;

From then on you need to analyse the responses - you can either do this using a series of


if replyCode == '*' then
elseif replyCode == '.' then
...
end

or, you could set up a table indexed on the replyCode each entry of which would be a function that takes parameters answerCode, p1 and p2.
My preference would be for the second of these.

kurtlewis
April 16th, 2006, 12:42 PM
ok, that makes sense, but im still lost as what to do- Realize, I'm not a programmer at all- Can you write 1 example of each one so I know where to start? If i have a clear example i'm sure I can figure it out from there...

Rob H
April 16th, 2006, 01:18 PM
Okay, let's stick with the if then elseif chain as it's a bit easier to follow.

Source selection for example

assume that we have a table declared earlier as follows :-


local sources = &#123;
&#91;'0'&#93; = 'DVD',
&#91;'1'&#93; = 'SAT',
&#91;'2'&#93; = 'AV',
&#91;'3'&#93; = 'AUX',
&#91;'4'&#93; = 'VCR',
&#91;'5'&#93; = 'CD',
&#91;'6'&#93; = 'FM',
&#91;'7'&#93; = 'AM',
&#91;'8'&#93; = 'DVDA' ,
&#91;';'&#93; = 'TAPE',
&#125;

Then we have this code in ReceiveResponse :-


if replyCode == '1' then -- Source selection
if answerCode == 'P' then -- command was okay
local zone = p1
local source = p2
NetRemote.SetVariable&#40;'Arcam.Zone'..zone..'.Source ', sources&#91;source&#93;&#41;
else
-- report the error somehow e.g. using gir.LogMessage&#40;&#41;
end
end

Now, in this version I've put the calls to NetRemote.SetVariable in the code directly, but I wouldn't really recommend that approach.

It's better to use trigger a Girder event using e.g.


gir.TriggerEvent&#40;'Arcam.Source', ArcamDeviceId, zone, source&#41;
where ArcamDeviceId is a device id in the 10000+ range which you can claim in this thread - http://www.promixis.com/phpBB2/viewtopic.php?t=12510
That way you can do far more with the information than just send it on to NetRemote e.g. if someone switches the preamp to DVD mode manual or using the preamp's remote you could ensure that the DVD player is switched on too (assuming you have a discrete code for it or serial control).

kurtlewis
April 16th, 2006, 03:42 PM
Thanks for the extra time Rob- Man i'm so freaking green with this, it's pathetic. It is going to take me a while to wrap my brain around it b/c I'm just not familiar enough yet with the concepts of how everything inter-relates between G and NR.

The treescript DUI approach looks interesting, if I claim say 10033 for Arcam AVP700, that would be cool if it makes things easier, b/c I'm hoping that once this is done it will be something I can upload for anyone to use.- But I obviously don't have a clue how to set this up to call on it from NR. Are there any finished examples of other devices that use what you are describing, that I can take a look at? So far, that has been the easiest way for me to learn.

[edit]- I reserved 10032 - Arcam AV Receiver. Mike added it to the registry. Now how do I use it?

Apologies for the 200 questions- I hope this gets easier.. :-?

-Kurt

Rob H
April 16th, 2006, 04:52 PM
Re the device id - in the example I posted, add


local ArcamDeviceId = 10033

along with the table at the start of the file.

You may also want to add the following code to the Initialize function :-


if dui and dui.Devices then
dui.Devices&#91;ArcamDeviceId&#93; = 'Arcam AVP700'
end

That way any events that you trigger using your device ID will show in the logger as 'Arcam AVP700'

Not really sure about finished examples anywhere.

The simplest way to control this sort of thing is probably to come up with some suitable Girder event names in your CCF using NRD e.g. Arcam.Mute - then press that button in NR and it will appear in the logger.

If you have a node in the GML that calls on your serial device then you can drag that event from the logger to the node.

kurtlewis
April 16th, 2006, 05:23 PM
ok, slowly getting it.... I figured there might be a GML file involved here, so I'll have to learn how to do that.

So if I understand this correctly, the table goes at the beginning of my arcam.lua file, and I would create tables for the different functions- i.e. 'local power', 'local modes', is that correct?

The code gir.TriggerEvent('Arcam.Source', ArcamDeviceId, zone, source) works from NR side as an action right?

Is what I'm trying to accomplish really odd? I'm way surprised that no one else has done anything like this in G with their receiver yet.

Rob H
April 16th, 2006, 05:32 PM
ok, slowly getting it.... I figured there might be a GML file involved here, so I'll have to learn how to do that.

That bit is fairly straightforward.



So if I understand this correctly, the table goes at the beginning of my arcam.lua file, and I would create tables for the different functions- i.e. 'local power', 'local modes', is that correct?

These being the tables that convert from the single character codes to understandable text? Then, yes.



The code gir.TriggerEvent('Arcam.Source', ArcamDeviceId, zone, source) works from NR side as an action right?

Not quite, no. That will trigger an event in Girder, from Girder. The idea is that the event triggers a script that calls NetRemote.SetVariable().



Is what I'm trying to accomplish really odd? I'm way surprised that no one else has done anything like this in G with their receiver yet.
No, it's not particularly odd, I'm just not aware of any uploaded examples.
I've been doing something similar for my own receiver (a Denon), but you know how it goes - the cobbler's children run barefoot :)

kurtlewis
April 16th, 2006, 05:45 PM
yup, i understand how it goes.. heh. And i feel like I'm venturing into territory reserved strictly for developers, not for the 'scriptingly-challenged' newcomer..

So I just need to know where these code pieces go, in what files?
1. gir.TriggerEvent('Arcam.Source', ArcamDeviceId, zone, source) - I assume i'll need to make more of these entries, replacing Arcam.Source for Arcam.Power, Arcam.Modes, etc)
[edit] looking at it again, this goes under 'ReceiveResponse' in the arcam.lua correct?

2. NetRemote.SetVariable()

3. What defines the statement 'Arcam.Source' - I can't see what that maps to in the lua for the 'Source'

Rob H
April 16th, 2006, 05:57 PM
The gir.TriggerEvent() goes in the various branches of the ReceiveResponse() function.

The events that are triggered by gir.TriggerEvent() are connected to nodes in your GML.

The nodes in the GML contain the calls to NetRemote.SetVariable.

It may seem a bit roundabout, but decoupling the serial device from NetRemote means that people who aren't using NetRemote can still use your serial device.

kurtlewis
April 16th, 2006, 06:33 PM
One thing I'm still hung on- I know I have to define Arcam.Source, Arcam.Power, etc in the GML. What I'm not clear on is how Arcam.Power maps to the receiver code of "*", and Arcam.Source maps to receiver code of "1".

I like your logic with decoupling the commands and making it more generally accessable, if I followed your instructions on adding things correctly the arcam.lua should look something like this:

Beginning of arcam.lua:

local ArcamDeviceId = 10033
local sources = {
['0'] = 'DVD',
['1'] = 'SAT',
['2'] = 'AV',
['3'] = 'AUX',
['4'] = 'VCR',
['5'] = 'CD',
['6'] = 'FM',
['7'] = 'AM',
['8'] = 'DVDA' ,
[';'] = 'TAPE',
}
local power = {
['0'] = 'Standby',
['1'] = 'PowerOn',
}
local device = serial.Classes.Simple:New({
Name = "Arcam AVP700",
GlobalName = "Arcam",
Description = "Arcam AVP700 Pre-amp and processor",

LogLevel = 0,-- change this to a higher number or nil when the device is working

BaudRate = 38400,
Parity = 0,
DataBits = 8,
StopBits = 0,
FlowControl = 'N',

CallbackType = serial.CB_TERMINATED,
ReceiveTerminator = '\r',

SendStartByte = 'PC_',
SendTerminator = '\r',
IncompleteResponseTimeout = 500,
NoResponseTimeout = 3000,

Initialize = function(self)
if serial.Classes.Simple.Initialize(self) then
-- add your own initializations here
if dui and dui.Devices then
dui.Devices[ArcamDeviceId] = 'Arcam AVP700'
end
self.Status = 'Initialized'
return true
end
end,

ReceiveResponse = function(self, data, code)
if math.band(code, serial.RXCHAR) then
-- add code here to process the data parameter
gir.TriggerEvent('Arcam.Source', ArcamDeviceId, 1, 0) -- zone 1 is on DVD
gir.TriggerEvent('Arcam.Source', ArcamDeviceId, 1, 1) -- zone 1 is on Sat
gir.TriggerEvent('Arcam.Power', ArcamDeviceId, 1, 0) -- zone 1 is in standby
end
serial.Classes.Simple.ReceiveResponse(self, data, code) -- must call the parent's ReceiveResponse
end,

Command = function(self, cmd, param1, param2)
self:SendCommand(cmd..param1..param2)
end,

-- Zone 1 live commands start here

-- power
Standby = function(self, zone)
self:Command('*', 1, 0)
end,

PowerOn = function(self, zone)
self:Command('*', 1, 1)
end,

AskPowerStatus = function(self, zone)
self:Command('*', 1, 9)
end,

-- Source Selection
SAT = function(self, zone)
self:Command('1', 1, 1)
end,

DVD = function(self, zone)
self:Command('1', 1, 0)
end,

Tuner = function(self, zone)
self:Command('1', 1, 0)
end,

AskInputStatus = function(self, zone)
self:Command('1', 1, 9)
end,

kurtlewis
April 16th, 2006, 07:58 PM
Rob- I just found this, posted by FearTheDentist. It's a G4 control setup for Denon receivers and looks about like what we're trying to do here. fwiw I thought you might find it particularly useful since you said you were setting up something for your Denon. Includes a ccf, lua and gml

kurtlewis
April 16th, 2006, 09:01 PM
I'm afraid i'm going to have to throw the towel in on this project, admittedly this is way over my head as it seems I need to learn the programming language and structure in order really make anything work. -With work and family It's just time that I unfortunately do not have.

I have been trying to load up the lua file in G4 as you originally wrote it, with a few more device commands added- G4 errors on loading it and the lua console shows an error about '}' needing to close '{' at the end of line 1. - Which is odd b/c viewing the lua in Notepad++ the structure looks ok. I re-attached it below for ref.

Can I put in a request w/ promixis to have a driver written for Arcam receivers? This should work for all of the DiVA models including the new AV9.

Thank you anyway Rob for taking the time to answer my numerous questions and try to walk me through it.

-Kurt

Promixis
April 16th, 2006, 09:03 PM
I'm afraid i'm going to have to throw the towel in on this project, admittedly this is way over my head as it seems I need to learn the programming language and structure in order really make anything work. -With work and family It's just time that I unfortunately do not have.

I have been trying to load up the lua file in G4 as you originally wrote it, with a few more device commands added- G4 errors on loading it and the lua console shows an error about '{' needing to close '}' at the end of line 1. - Which is odd b/c viewing the lua in Notepad++ the structure looks ok. I re-attached it below for ref.

Can I put in a request w/ promixis to have a driver written for Arcam receivers? This should work for all of the DiVA models including the new AV9.

Thank you anyway Rob for taking the time to answer my numerous questions and try to walk me through it.

-Kurt

Kurt, can you let us know what you need in terms of functionality?

kurtlewis
April 16th, 2006, 09:23 PM
Hi Mike- I pretty much have the functionality items listed out in the attached lua file of my last post, with addition of:
menu and menu nav, channel trim, ability to pre-set volume to a specifc db for an input before switching to it (it's a feature in the Arcam).

I would like to be able to show status in NR for vol, zone, surround mode, effect, power.

Thanks, if you could put something together that would be awesome. -wish I could do it myself....

Rob H
April 17th, 2006, 03:41 AM
I've corrected the (very minor) errors in your original file. They were :-

1) You can't start an identifier with a digit
2) You were trying to pass '/' as a parameter without the quotes

Here's the corrected file.

kurtlewis
April 18th, 2006, 09:05 PM
Hi Rob- Thanks for the corrections.

I added pretty much all of the functions for the Arcam receiver to the lua file. I'm hoping it will help with getting a Promixis driver created. (pretty, pretty please...)

kurtlewis
April 19th, 2006, 10:21 AM
ok so i've been messing around with this a bit (because I can't leave well enough alone..)
I dropped the lua file into the G4 serial directory and enabled the device on the com port. logger shows everything as kosher and I see the device in the variables window.
I've also created a gml named 'Arcam' and set up some categories.

It's not showing up in my actions list / window, so I cannot assign actions- Do I need to add some sort of GlobalName line to the lua?

n/m - there is a GlobalName string in the lua... so it must be something else.
[edit]I can select the Arcam as a serial device in the 'Edit\Serial Send' menu and can type a string to send (verified it in lua console) - but I'm mystified how to get to the arcam function settings that were specified in the lua. I thought they would show up in the Event Devices list when editing a 'New' node under 'Serial Send'? -Or in the 'Actions' tree?

kurtlewis
April 19th, 2006, 11:40 AM
Mike- Found this in one of the other forum threads, that you had posted. Should I be seeing something similar to this?


ok, drop this in the serial folder, restart girder and select it via the serial page.

send via the action tree. select hex as send as, you do not need to add the start byte (1c). show me the console output ;-)

I also added:
local ArcamDeviceNumber = 10032
local ArcamDeviceName = 'Arcam'

to the top of my lua but that didn't help

kurtlewis
April 20th, 2006, 09:26 PM
I have Girder controlling the Arcam by -manually- selecting 'send serial' from the action tree into my GML and typing out the ASCII commands for the send serial action.

So i'm wondering why the time was spent specifiying out all of the commands in the lua, when these commands are (or appear to be) innaccessible from within Girder.

I realize everyone is busy and all, and I am far from wanting to be a nuisance- however my options are very limited with where to turn for assistance. I've read all of the docs that I could find / scoured the forums, and I'm afraid I do need help to make this work. I still have not paid for G4 yet, but I'm happy to do so once I see how it can provide value to my HA / HT setup.

Mike / Rob-
If what I'm trying to accomplish is unreasonable, or you feel is outside the scope of what I should be asking assistance for from the Promixis team, or if everyone is just plain too busy to help out, then let me know. Otherwise I would (again saying please) love some help with making this work like it should....

also attached is an updated guide doc from Arcam with new serial commands added / changed for new firmware version 3.36. This was really hard to get so hang on to it.

Rob H
April 21st, 2006, 05:48 AM
For some reason I missed your earlier messages - sorry about that.


I have Girder controlling the Arcam by -manually- selecting 'send serial' from the action tree into my GML and typing out the ASCII commands for the send serial action.

So i'm wondering why the time was spent specifiying out all of the commands in the lua, when these commands are (or appear to be) innaccessible from within Girder.

You can access them from a scripting action, in much the same way as you would using the Lua console.

Alternatively, you (or someone else) could use the DUI designer to create real actions that would appear in the action tree, but that might be overkill in this case.

Promixis
April 21st, 2006, 06:05 AM
For some reason I missed your earlier messages - sorry about that.


I have Girder controlling the Arcam by -manually- selecting 'send serial' from the action tree into my GML and typing out the ASCII commands for the send serial action.

So i'm wondering why the time was spent specifiying out all of the commands in the lua, when these commands are (or appear to be) innaccessible from within Girder.

You can access them from a scripting action, in much the same way as you would using the Lua console.

Alternatively, you (or someone else) could use the DUI designer to create real actions that would appear in the action tree, but that might be overkill in this case.

Kurtis, this is definitely most easily done from the action tree. There are some advantages to do this from the lua side as was done in the denon file and we are considering ways to do the lua side and then have it appear on the action tree. For now, I would do with the action tree as it is the quickest and easiest way to get started.

We are you at in terms of functionality otherwise?

kurtlewis
April 21st, 2006, 10:03 AM
I'm confused guys-I thought the goal was to have it working correctly via a lua file, in order to receive status / display in NR- And the end product could be published as a working driver file for anyone to use. At least that seemed to be the direction per our previous posts. Besides sending commands, getting feedback from the receiver / showing function status in NR is pretty important.

Mike- In terms of functionality specifics I had posted that above:


Posted: Sun Apr 16, 2006 6:22 pm Post subject:

--------------------------------------------------------------------------------

Hi Mike- I pretty much have the functionality items listed out in the attached lua file of my last post, with addition of:
menu and menu nav, channel trim, ability to pre-set volume to a specifc db for an input before switching to it (it's a feature in the Arcam).

I would like to be able to show status in NR for vol, zone, surround mode, effect, power.

Thanks, if you could put something together that would be awesome. -wish I could do it myself....


Now, from what I have learned there is really no way to accomplish this in G4 / NR for any 2-way serial controlled equiment without either (a) becoming a development expert and intuitively knowing all of the 'undocumented' stuff, or (b) requesting a complete driver file be written by Promixis. I'm sure that I'm not the first customer with this problem, so how can this be made easier for us non-dev folks to fully use the best features of G4?

Thanks - Kurt

Promixis
April 21st, 2006, 08:42 PM
Kurt,

We have a few things around the corner that will make this much easier. But you still have to have the core pieces in place ie sending/receiving and decoding/encoding commands. There is just no pnp solution.

kurtlewis
April 21st, 2006, 09:09 PM
totally understandable Mike- But the fact remains that the full functionality of G4 with device control is not easily accessible to the general enthusiast. I'm sure you guys have considered this fact already, and i'm sure you guys will evolve the product into a bit more 'pnp' - but given the diveristy of equipment and 'behind the scenes' parameters involved with making them work, I'm sure it will be a bit of a challenge to do so.

Might I make a suggestion, from a consumer / marketing point of view? How about opening up a 'driver request' queue, that customers can submit requests to in order to have their serial control equipment supported?
In the process you build up your 'device driver' database and make the overall G4 / NR / NRD products that much more enticing to the average and high-end enthusuast. -And possibly offer some level of professional services 'pay by time' to have custom solutions developed?
I notice that some of the other HA product companies are doing these very things. Knowing that an HA product readily supports control of popular equipment makes it all the more compelling to invest in.
Unless you do something along these lines, (just my opinion), you will continue to end up with a bunch of 'one-off' device builds that the next guy can't easilty use without learning coding (or bugging the piss out of the Promixis team...heh). And this may cost you potential customers as they turn to products which already have a substantial driver base built up (CQC as an example, within similar price range)

Really, even though i'm having a tough time with some of this I still firmly believe you have the best product on the market, period. Adding this last piece would make it perfect, and mark my words would open up a whole new range of customers to you.

In my case, is there any hope of having something for my Arcam written?

Promixis
April 21st, 2006, 09:15 PM
Great comments, and we agree. We are still mostly focused on smoothing G4's rough edges. It was a massive project. As we finish our Device Manager - device control and between G4 and NR and NRD will be really slick.

We also will have too look at doing driver requests as you suggest. They can get expensive (for us) very quickly as a single device (even a relatively simple one) can easily burn 10 - 20 hours of development time.

Thanks for sticking with G4/NR. You won't regret it :D

kurtlewis
April 21st, 2006, 10:25 PM
Thanks for sticking with G4/NR. You won't regret it :D

I'm sure I won't- I looked at everything else on the market already.
I'd rather stick with something bad-ass and in it's growth phase than something already finished, over priced and lame.

But I'd be much happier if I could fully use my Arcam's available features though... :roll:

kurtlewis
April 21st, 2006, 10:56 PM
We also will have too look at doing driver requests as you suggest. They can get expensive (for us) very quickly as a single device (even a relatively simple one) can easily burn 10 - 20 hours of development time.


Of course, I know this problem very well. I run the IT department for the #2 largest online dating site, and one of our biggest time consumers in our Dev group is writing small applets and site feature widgets.

Why don't you do what we do and hire some low $ entry-level kids to do just the driver stuff. I don't know how tough it is to find LUA talent so this may / may not be feasable for you- Just a suggestion, it works for us.
Or maybe have an incentive program for potential customers that know how to code- Like, write and submit a device driver and get free product.


Any way you slice it, if you want to make your product more accessible to the average schmoe with $ to spend on HA and HT, you are going to have to have a basket of commonly supported devices that are reasonably easy for the end-user or professional services installer to set up. -And you will have to have a path to continually add more in order to keep up.
You may complain about the internal 'time and cost' of writing that driver- but how many more sales will having that driver available translate to? Think about that- I mean, I would have already bought G4 for nothing other than to bi-directionally control my Arcam if I saw that the driver was available. Why would I want to buy G4 just to get weather on my NR? All it takes is one or two devices to be supported that someone owns, and the cash register rings...

Development of the driver is a one time cost and is expensable against received income. Once the drivers are out there, they keep making money for you by increasing sales and sales potential- because they now add a much greater value to your product.
Look at it more as an investment in the success of your product, rather than a negative thing.

As an example, I initially passed on trying out your product becasue after looking through the site, I didn't see any real equipment that was readily supported. The download section is great, but it's a mixed-bag of stuff- some of it works, some of it doesn't. Fortunately i'm at least technical to a level where I felt brave enough to try it out- And of course just seeing the gui flexibility with NR / NRD won me over. So cool!

anyway, enough out of me :)

kurtlewis
May 1st, 2006, 09:52 AM
By chance does anyone have time to help me out with getting received events from my Arcam to NR? Like, reported volume level - surround mode - on-off status - input selection?

Rob H
May 2nd, 2006, 02:56 AM
Can you post the latest version of your serial device and I'll see what I can do.

GusKerr
May 2nd, 2006, 07:38 AM
Kurt / Promixis Team,

I would also agree that the availability of pre-written drivers would really make this an even better product with the potential of a much larger market share.

It is currently aimed at the technical user (and by this I mean someone with a lot of time but a decent amount of programming experience). Yes you can use the Tree View to create some basic functionality. I think this misses the point of Girder / NR - It is a really powerful flexible product and to get the most out of it requires use of LUA.

I think the idea of creating a library of tested Plug-ins is a great idea. Rather than rely on just customers or just techy kids, why not develop a model framework for customers to place there code and then get the techy kids to test the drivers before stamping their approval. This is kind of the way Unix has grown up whereby the code is open source but someone oversees it all and ensures some level of quality.

Saying all that, there is a fantastic active community here on the Forum and it is through the help of you guys that I have the incentive and the ability to actually develop my end game.

Cheers

Gus

Promixis
May 2nd, 2006, 10:32 AM
Gus,

We will be rolling out a Device Manager the encapsulates much of what you and Kurt are taling about. This will make G and NR much easier to use.

kurtlewis
May 2nd, 2006, 10:57 AM
Can you post the latest version of your serial device and I'll see what I can do.

Thanks Rob- Attached Arcam.zip which includes:

-Arcam.gml
-Arcam.lua
-Arcam latest firmware programming guide for v3.36
-Arcam software release notes for v3.36
-G4 lua console log of all volume response codes from 08db to 90db (my Arcam starts volume at 08db, and anything over 90db my neighbors will be calling the cops...heh)

As always, anything you can do would be appreciated- This device control should work for all of the newer Arcam receivers and processors from AVP8, AVR250 on up..

GusKerr
May 2nd, 2006, 02:40 PM
Great to hear.......

Gus

kurtlewis
May 2nd, 2006, 04:03 PM
Gus,

We will be rolling out a Device Manager the encapsulates much of what you and Kurt are taling about. This will make G and NR much easier to use.

That is awesome Mike- can't wait to see it!

kurtlewis
May 10th, 2006, 05:31 PM
Hi Rob- just wondering if you've had any time to tinker with the Arcam driver. I noticed my attachments are now gone since the site incident, should I re-post?

Rob H
May 10th, 2006, 06:40 PM
Not had a chance to look at this yet I'm afraid Kurt. Mike's been keeping me busy doing other things. No need to repost since you sent me the Arcam stuff along with your CCF didn't you? Incidentally, I've not been able to reproduce the crashes that you've been getting, although I did find something unusual with a debug build of NR - may not be related though.

kurtlewis
May 10th, 2006, 07:13 PM
Thanks Rob- Ya that's right I did email you my stuff, but not sure if I posted the Arcam docs here or sent them in email. I work too much, early alzheimers is setting in....

So I'm still having the crashes, it's way odd. The only thing I see happening prior to a crash is the MB exception log entry, and weather updates from Girder. Do you think a weather update to the NR client could be a cause?

Anyway, hopefully Mike to free up your time (pleeease mike!!)- I'm sure working on my driver is not your idea of fun, but I would super greatly appreciate it. If I even had a remote chance of where to begin to figure it all out for the NR display of status / vol / etc, believe me I would have done so.....

Promixis
May 10th, 2006, 07:59 PM
Hi Kurt,

Would like to know exactly the errors you are seeing. We are working very hard to torture test NR and to iron out the few remaining issues. There is a definite issue in the NR Girder plugin we have not nailed yet.

kurtlewis
May 10th, 2006, 08:49 PM
Hi Mike- I've been regularly posting everything here in a thread I started: http://www.promixis.com/forums/showthread.php?t=14365

Let me know what else I can do to assist

kurtlewis
May 22nd, 2006, 03:06 AM
Hi guys- Again requesting help with setting up visible feedback in NR for my Arcam. At least for volume / mute / on / off ?

Mike.... Rob... Bueller..... anyone have time to help?

Rob H
May 22nd, 2006, 03:22 AM
Sorry Kurt, most of my efforts of late have been directed toward reproducing the crashes you've been experiencing. I'll try to get to this device this week.

kurtlewis
May 22nd, 2006, 10:03 AM
no worries Rob- fixing that damn crash is pretty important! Do you have any idea on what might be causing it or does my situation seem unique?

Rob H
May 22nd, 2006, 10:19 AM
It's related to networking somehow, but beyond that I'm a little stumped :(

When it crashes, do you get the standard windows error dialog?

If you do then you should be able to get more information about the error from it. Apologies if you've already posted that information.

kurtlewis
May 22nd, 2006, 10:51 AM
Yep, standard windows error dialogue- I did post it before but I'll put it up again next time I get a crash.
I've been posting all of my logs / info here in the NR forum: http://www.promixis.com/forums/showthread.php?t=14365