GC100: Lag between repeated IR codes
GC100: Lag between repeated IR codes
Does anyone know how to decrease the interval between sent IR codes for the GC100. When I try to change channels on a motorola DCT6412 via the channel property, the lag time between IR codes being sent is so great that the DCT6412 times out between them. It is taking at least 1s between codes. I have repeat set to 1 under IR code configuration already...this didn't help the problem. Codes are chained together in the channel property as they are supposed to be (2,1,1,enter).
I have similar lag when I "test" codes. Once I hit test to send the code, it takes at least 1s before I can physically select another code, or the test button comes back to its up position.
I have similar lag when I "test" codes. Once I hit test to send the code, it takes at least 1s before I can physically select another code, or the test button comes back to its up position.
Here is the trace from a channel change. If you look at the time, it takes 4s between sending the chained IR codes.
Code: Select all
Mar 22 2006 06:09:58AM GC100-FR Debug Attempting to connect to CP-100 at address [192.168.1.10]
Mar 22 2006 06:09:58AM GC100-FR Debug Connection to CP-100 successful.
Mar 22 2006 06:09:58AM GC100-FR Debug "Received Data from GC-100 [device,1,1 SERIAL
device,2,3 IR
endlistdevices
]"
Mar 22 2006 06:09:58AM GC100-FR Debug Received Data from GC-100 [version,1,2.0.8-06r2]
Mar 22 2006 06:10:03AM GC100-FR Debug Received Data from GC-100 [version,2,2.0.8-06r2]
Mar 22 2006 06:12:39AM Meedio HouseBot application is terminating.
Mar 22 2006 08:12:53AM GC100-FR Debug Attempting to connect to CP-100 at address [192.168.1.10]
Mar 22 2006 08:12:54AM GC100-FR Debug Connection to CP-100 successful.
Mar 22 2006 08:12:54AM GC100-FR Debug "Received Data from GC-100 [device,1,1 SERIAL
device,2,3 IR
endlistdevices
]"
Mar 22 2006 08:12:54AM GC100-FR Debug Received Data from GC-100 [version,1,2.0.8-06r2]
Mar 22 2006 08:12:59AM GC100-FR Debug Received Data from GC-100 [version,2,2.0.8-06r2]
Mar 22 2006 08:15:19AM Meedio HouseBot application is terminating.
Mar 22 2006 08:55:40AM GC100-FR Debug Attempting to connect to CP-100 at address [192.168.1.10]
Mar 22 2006 08:55:40AM GC100-FR Debug Connection to CP-100 successful.
Mar 22 2006 08:55:40AM GC100-FR Debug "Received Data from GC-100 [device,1,1 SERIAL
device,2,3 IR
endlistdevices
]"
Mar 22 2006 08:55:40AM GC100-FR Debug Received Data from GC-100 [version,1,2.0.8-06r2]
Mar 22 2006 08:55:45AM GC100-FR Debug Received Data from GC-100 [version,2,2.0.8-06r2]
Mar 22 2006 08:56:04AM GC100-FR Debug "Received Data from GC-100 [completeir,2:1,1
]"
Mar 22 2006 08:56:08AM GC100-FR Debug Successfully transmitted IR Code [CableBox.2] to GC-100.
Mar 22 2006 08:56:09AM GC100-FR Debug "Received Data from GC-100 [completeir,2:1,1
]"
Mar 22 2006 08:56:13AM GC100-FR Debug Successfully transmitted IR Code [CableBox.1] to GC-100.
Mar 22 2006 08:56:14AM GC100-FR Debug "Received Data from GC-100 [completeir,2:1,1
]"
Mar 22 2006 08:56:18AM GC100-FR Debug Successfully transmitted IR Code [CableBox.1] to GC-100.
Mar 22 2006 08:56:19AM GC100-FR Debug "Received Data from GC-100 [completeir,2:1,1
]"
Mar 22 2006 08:56:23AM GC100-FR Debug Successfully transmitted IR Code [CableBox.Enter] to GC-100.
Mar 22 2006 08:56:34AM GC100-FR Debug "Received Data from GC-100 [completeir,2:1,1
]"
Mar 22 2006 08:56:39AM GC100-FR Debug Successfully transmitted IR Code [CableBox.Exit] to GC-100.
A couple of things to check:
- In the Serial Command Configuration for the GC100 (in the HouseBot hardware interface), make sure the Inter-Command Delay is set to 0 (or very low). A value of 1000, for example, will insert a one second delay between sends.
- Make sure the IR codes are short and clean. It is possible that the commands are sent quickly, but the IR that is being sent is very long. If you have a 'flasher' type IR emitter that lights up when the IR is being sent, this is a good way to visually see if there is a lag.
Scott
The Inter-Command Delay was set to 0. I loaded the Serial Sample Configuration with a delay of 200ms and I am still seeing the problem described in the posts above.
My codes are as clean as they get. For example, here is the code for "1":
I am at a loss here and this is a real show-stopper for me. Do you think this could be a GC problem. I notice that under GC-100 Information, HouseBot is not populating the Version fields for each of my modules.
My codes are as clean as they get. For example, here is the code for "1":
Code: Select all
0000 006D 0012 0002 0159 00AD 0013 00AD 0013 0057 0013 0057 0013 0057 0013 0057 0013 0057 0013 0057 0013 0057 0013 0057 0013 0057 0013 0057 0013 0057 0013 00AD 0013 00AD 0013 00AD 0013 00AD 0013 04A2 0159 0057 0013 0D23
I am at a loss here and this is a real show-stopper for me. Do you think this could be a GC problem. I notice that under GC-100 Information, HouseBot is not populating the Version fields for each of my modules.
There is a timeout (of 5 seconds) between commands if it doesn't receive the acknowledgment from the GC100 after sending IR.Osler wrote:I notice that under GC-100 Information, HouseBot is not populating the Version fields for each of my modules.
Since the module version info is also blank, I'm guessing that there's an issue with the RS-232 receive line and you're just not getting any data from the GC100 to the PC. You might want to try another cable.
Scott
I will try a different cable, but I thought the trace depicts the acknowledgement (completeir) from the GC-100. However, a 5s timeout would fit with what I am seeing. Perhaps I have a buggy GC-100 (or cable as you suggest).
Last edited by Osler on Thu Mar 23, 2006 5:25 pm, edited 1 time in total.
Ok. I think I know the problem. The format of the version response from the GC100 is not what the plugin is expecting. It's just missing a terminating line-feed character. However, it's enough to also kill the IR responses because the system is still waiting for the version response to complete.
I'm not sure why they would have changed that (all of their other responses end with the line-feed still). I don't really know of any workaround, unless there's something in the GC100 config that will do it. You may want to ask Global Cache.
I'm not sure why they would have changed that (all of their other responses end with the line-feed still). I don't really know of any workaround, unless there's something in the GC100 config that will do it. You may want to ask Global Cache.
Scott
The version checks are only done initially to populate the dialog (that is not being populated for you). However, the plugin doesn't process the version responses because it thinks there is more data to be received (since it didn't receive the newline character).
When IR codes are sent, the GC100 is also sending the completeir commands (correctly with the newline). However, since the receive buffer is still waiting for the version request to complete, it doesn't even see the complieteir response. So it thinks that no completeir has been received and does its 5 second timeout.
I looked at the Version 1.0 API spec (http://www.globalcache.com/files/Docume ... GC-100.pdf page 4), and it clearly shows the newline at the end (that's the little arrow symbol). So the plugin is still correct as per their spec.
Make sense?
When IR codes are sent, the GC100 is also sending the completeir commands (correctly with the newline). However, since the receive buffer is still waiting for the version request to complete, it doesn't even see the complieteir response. So it thinks that no completeir has been received and does its 5 second timeout.
I looked at the Version 1.0 API spec (http://www.globalcache.com/files/Docume ... GC-100.pdf page 4), and it clearly shows the newline at the end (that's the little arrow symbol). So the plugin is still correct as per their spec.
Make sense?
Scott
Ok...you are going to be relieved. They had a two-week production run with buggy firmware and have noted this lack of terminating character before. So it does appear to be a problem with the GC-100. Apparently there was limited production, but the module version posted in my trace is likely the version of buggy firmware. GC is dropshipping me a new unit to test and if it works then this is the answer to the problem in case others experience this issue.
Edit:
Oh and thank you Scott for your attention to this and walking through it with me. Also, support at GC was fantastic as well. Kudos to both.
Edit:
Oh and thank you Scott for your attention to this and walking through it with me. Also, support at GC was fantastic as well. Kudos to both.