I have installed the new firmwares in my TSU9400 and RFX9600 (obviously after having obtained the right version as per the other post).

On entering a page, my application sends a query command (ZM?) via RS232 to a Denon receiver. This appeared not to be working any more (command seems to be sent from a Prontoscript perspective, but the Denon is not responding) .

So I reverted the TSU firmware to the previous version (7.2.22) while leaving the RFX9600 at the new version (1.4.7) and and without even downloading a new configuration, the query command now works !

Further on, when I change the volume on the Denon using a standard RS232 action, I receive the volume feedback from the Denon properly using the new firmware. I will do some more testing to see if there is a timing issue involved and report here.

Paul

P.S. Same behaviour with the TSU9800 firmware, which was to be expected

Paul,

Did you email Belgium? I have not seen this issue on my system but then I don't use 232 for 2-way via ProntoScript with Denon. I do use 1-way actions and for sure, these are working.

I am seeing the same issue (also with a Denon amp) - my code is architected to call receive asynchronously from a timer thread to provide the polling and the onData handler is not being called. Deadlock somewhere from the new code?


OK - some further information. I have two devices I connect to in my activity onEntry script - both are controlled by RS-232 (a Denon Amp and CBUS Network). I have created a simple project that contains only the Denon and it works fine; add the CBUS into the mix and it deadlocks.

Both devices scripts (which I have written and worked under the old firmware) are written with scheduled timers to poll the port and have their own netlink status handlers to detect the connection being dropped. Will post more as I find it out...

I see my queue of commands for the port processed until I press a hard key at which point the serial port stops receiving data and, interestingly, pressing the button again you see the command queue get longer and not be processed.

OK - am now pretty certain there is a deadlock between the user interface thread and the timers. Have emailed a sample to Belgium.


Mark

There was a firmware change on allowing multiple outstanding match operations on the extender in this later release. Waiting for confirmation from Belgium on whether I can post the details.

With regard to Paul's issue. This firmware change was a side-effect that exposed a real bug in his scripting.

s.match(command + '\r',500); was indeed sending command and then waiting a default 250ms (undocumented timeout???) for a string of '500'.

The problem was that the extender was expecting to match on a string of "500" which will never be sent. The code should have issued something like:

s.match(command + '\r',\r',500);

When the timeout was occurring, match operation was not raising a timeout exception but rather attempting to call 'onError' on the serial object (which was not assigned).

Belgium has suggested:

s.match(command + '\r','\r', 0); for an immediate operation and no wait for completion.

If the 500 ms synchronous wait is required, I suggest:

s.match(command + '\r','\r',500);

OK - have now resolved this - issue was being caused by the amplifier being in standby and not responding to my command.