Your Universal Remote Control Center
RemoteCentral.com
Philips Pronto Professional Forum - View Post
Previous section Next section Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Topic:
Issue with Firmware 7.3.3
This thread has 4 replies. Displaying all posts.
Post 1 made on Sunday July 11, 2010 at 08:37
Paul Biron
Founding Member
Joined:
Posts:
August 2001
142
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

Last edited by Paul Biron on July 11, 2010 08:59.
___________________
Pronto Level II Certified
Post 2 made on Sunday July 11, 2010 at 12:15
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
12,390
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.
Lyndel McGee
Philips Pronto Addict/Beta Tester
Post 3 made on Tuesday July 13, 2010 at 13:28
MCFH
Long Time Member
Joined:
Posts:
December 2009
35
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

Last edited by MCFH on July 13, 2010 17:23.
Post 4 made on Tuesday July 13, 2010 at 18:36
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
12,390
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);
Lyndel McGee
Philips Pronto Addict/Beta Tester
Post 5 made on Wednesday July 14, 2010 at 01:52
MCFH
Long Time Member
Joined:
Posts:
December 2009
35
OK - have now resolved this - issue was being caused by the amplifier being in standby and not responding to my command.
 
 


Jump to


Protected Feature Before you can reply to a message...
You must first register for a Remote Central user account - it's fast and free! Or, if you already have an account, please login now.

Please read the following: Unsolicited commercial advertisements are absolutely not permitted on this forum. Other private buy & sell messages should be posted to our Marketplace. For information on how to advertise your service or product click here. Remote Central reserves the right to remove or modify any post that is deemed inappropriate.

Hosting Services by ipHouse