Title: Quick Question about Raw IO mode
Post by: tomvdb on April 12, 2010, 06:07:57 pm
Post by: tomvdb on April 12, 2010, 06:07:57 pm
In the manual of how the IR toy works you have the picture which shows the two IR toys running and then sending data from the one to the other. You state that you only send the pink text, but judging on the screenshot, the pink text comprises of only bytes here and there. How did u determine which to send ?
I'm putting a little app together (IR Studio) with various functions for my own use. I could capture a mute from a rc6 remote but when I transmit it, it only works sometimes, I'm guessing that I don't understand something and I think it has something to do with my question (above). Another reason that I thought of was that 10 Khz was maybe too slow ?
I'm putting a little app together (IR Studio) with various functions for my own use. I could capture a mute from a rc6 remote but when I transmit it, it only works sometimes, I'm guessing that I don't understand something and I think it has something to do with my question (above). Another reason that I thought of was that 10 Khz was maybe too slow ?
Title: Re: Quick Question
Post by: ian on April 13, 2010, 08:06:07 am
Post by: ian on April 13, 2010, 08:06:07 am
Hey tom,
That demo works like this:
1. Capture the IR code in IRIO mode. This gives an 8bit/byte bitmap of the signal.
2. Put the transmitting IR Toy in 8bit IRIO mode. This is important because the default is 7bits of data per byte, this might be a problem area.
3. Send the bitmap to be transmitted.
In the demo I used an RC5 remote and the receiving IR Toy was in RC5 decoder mode, so the receiving IR Toy decoded the RC5 signal from the IR Toy the same as for the original remote control.
It is possible the 10kHz sampling rate is too slow for RC5, you can increase it to some extent. Also, the first batch of IR Toys has backwards LED, that would certainly limit your range.
Good luck with your app, I hope some of this is helpful. Give me a shout if you need more info or a repair for your IR Toy LED. Let us know when you finish the app and I'll post it up on the blog.
That demo works like this:
1. Capture the IR code in IRIO mode. This gives an 8bit/byte bitmap of the signal.
2. Put the transmitting IR Toy in 8bit IRIO mode. This is important because the default is 7bits of data per byte, this might be a problem area.
3. Send the bitmap to be transmitted.
In the demo I used an RC5 remote and the receiving IR Toy was in RC5 decoder mode, so the receiving IR Toy decoded the RC5 signal from the IR Toy the same as for the original remote control.
It is possible the 10kHz sampling rate is too slow for RC5, you can increase it to some extent. Also, the first batch of IR Toys has backwards LED, that would certainly limit your range.
Good luck with your app, I hope some of this is helpful. Give me a shout if you need more info or a repair for your IR Toy LED. Let us know when you finish the app and I'll post it up on the blog.
Title: Re: Quick Question
Post by: tomvdb on April 13, 2010, 10:54:05 am
Post by: tomvdb on April 13, 2010, 10:54:05 am
[quote author="ian"]
1. Capture the IR code in IRIO mode. This gives an 8bit/byte bitmap of the signal.
[/quote]
Yep, thats what I'm doing, although each key press has some values which are different. This is not when I keep the button pressed in but rather press the button, wait a few seconds and press the button again. But the difference could be due to the 10Khz not being quick enough.
[quote author="ian"]
2. Put the transmitting IR Toy in 8bit IRIO mode. This is important because the default is 7bits of data per byte, this might be a problem area.
[/quote]
Ahh, yes, that makes sense. I'll try it.
[quote author="ian"]
It is possible the 10kHz sampling rate is too slow for RC5, you can increase it to some extent.
[/quote]
Can u give me more information of how I would this please.
[quote author="ian"]
Also, the first batch of IR Toys has backwards LED, that would certainly limit your range.
[/quote]
I saw the post so I fixed this before I even plugged it in ;)
[quote author="ian"]
Good luck with your app, I hope some of this is helpful. Give me a shout if you need more info or a repair for your IR Toy LED. Let us know when you finish the app and I'll post it up on the blog.
[/quote]
Thanks, I'll let u know as soon as I have something more userfriendly ;)
1. Capture the IR code in IRIO mode. This gives an 8bit/byte bitmap of the signal.
[/quote]
Yep, thats what I'm doing, although each key press has some values which are different. This is not when I keep the button pressed in but rather press the button, wait a few seconds and press the button again. But the difference could be due to the 10Khz not being quick enough.
[quote author="ian"]
2. Put the transmitting IR Toy in 8bit IRIO mode. This is important because the default is 7bits of data per byte, this might be a problem area.
[/quote]
Ahh, yes, that makes sense. I'll try it.
[quote author="ian"]
It is possible the 10kHz sampling rate is too slow for RC5, you can increase it to some extent.
[/quote]
Can u give me more information of how I would this please.
[quote author="ian"]
Also, the first batch of IR Toys has backwards LED, that would certainly limit your range.
[/quote]
I saw the post so I fixed this before I even plugged it in ;)
[quote author="ian"]
Good luck with your app, I hope some of this is helpful. Give me a shout if you need more info or a repair for your IR Toy LED. Let us know when you finish the app and I'll post it up on the blog.
[/quote]
Thanks, I'll let u know as soon as I have something more userfriendly ;)
Title: Re: Quick Question about Raw IO mode
Post by: ian on April 14, 2010, 08:48:34 am
Post by: ian on April 14, 2010, 08:48:34 am
I use the PIC timer calculator linked in the how-to. The how-to also has all the key values:
http://users.picbasic.org/projects/PicT ... merCal.htm (http://users.picbasic.org/projects/PicTmrCalc/PicTimerCal.htm)
I set it up like the picture below to get 10khz. Move the slider up and down to find an offset for your desired sampling frequency. Then convert the number to HEX (64331=0xfb4b) and break it into a high (0xfb) and low (0x4b) byte. Send it to the IR Toy with the setup sample timer command (0x01):
0x01 0xfb 0x4b
http://users.picbasic.org/projects/PicT ... merCal.htm (http://users.picbasic.org/projects/PicTmrCalc/PicTimerCal.htm)
Quote
Setup sample timer
IRIO mode starts with a 10kHz sample and playback timer. This can be changed by sending the the setup timer command, followed by two bytes that set the timer 1 offset. The first byte is the high 8bits, the second byte is the low 8bits. Use a PIC timer calculator to find the values (key calculation constants: timer 1, 1:1 prescaler, 48MHz fosc, 12MHz fcyc).
I set it up like the picture below to get 10khz. Move the slider up and down to find an offset for your desired sampling frequency. Then convert the number to HEX (64331=0xfb4b) and break it into a high (0xfb) and low (0x4b) byte. Send it to the IR Toy with the setup sample timer command (0x01):
0x01 0xfb 0x4b
Title: Re: Quick Question about Raw IO mode
Post by: rsdio on April 15, 2010, 01:51:29 pm
Post by: rsdio on April 15, 2010, 01:51:29 pm
I'm quite certain that this PIC Timer Calculator is wrong. If someone wants to follow up with HighcoPic on the Proton forum, then feel free to direct the author back to this thread. I'm certainly willing to discuss it here.
If you want to understand the PIC Timer, then read the Data Sheet. It clearly states that the Timer generates an interrupt on overflow. So, where the author thinks the Timer counts to 255 (8-bit mode) or 65535 (16-bit mode), that's off by one. The Timer actually counts to 256 (0x100) or 65536 (0x10000).
Getting back to the specific example of the USB IR Toy, we have FOSC at 48 MHz, but the peripheral clock is at FOSC/4, or 12 MHz. If your target is 10 kHz, then you need a divider of 1200, which translates to a Timer1 starting count of 65536-1200=64336 (0xFB50). The good news is that this is a precise 10000.000 Hz (or how ever many zero digits the crystal is rated for). The bad news is that the 64331 (0xFB4B) value given by the Win32 program actually produces 9958.50622406 Hz, not the advertised 10006.8 Hz.
If you have a calculator with hex conversions, then you can do everything without downloading a program anyway. For a desired frequency, f, just use C=65536-(12000000/f), then convert the resulting timer starting count value C to hex.
If you want to reverse the calculation, f=12000000/(65536-C). These formulae assume 48 MHz for the USB PIC and a Timer1 prescaler ratio of 1:1.
I've painstakingly confirmed these calculations for the PIC18F87J50 by measuring waveforms on a logic analyzer and also comparing the results to other time references. I suppose it's possible that I made a mistake, so please point out any errors.
If you want to understand the PIC Timer, then read the Data Sheet. It clearly states that the Timer generates an interrupt on overflow. So, where the author thinks the Timer counts to 255 (8-bit mode) or 65535 (16-bit mode), that's off by one. The Timer actually counts to 256 (0x100) or 65536 (0x10000).
Getting back to the specific example of the USB IR Toy, we have FOSC at 48 MHz, but the peripheral clock is at FOSC/4, or 12 MHz. If your target is 10 kHz, then you need a divider of 1200, which translates to a Timer1 starting count of 65536-1200=64336 (0xFB50). The good news is that this is a precise 10000.000 Hz (or how ever many zero digits the crystal is rated for). The bad news is that the 64331 (0xFB4B) value given by the Win32 program actually produces 9958.50622406 Hz, not the advertised 10006.8 Hz.
If you have a calculator with hex conversions, then you can do everything without downloading a program anyway. For a desired frequency, f, just use C=65536-(12000000/f), then convert the resulting timer starting count value C to hex.
If you want to reverse the calculation, f=12000000/(65536-C). These formulae assume 48 MHz for the USB PIC and a Timer1 prescaler ratio of 1:1.
I've painstakingly confirmed these calculations for the PIC18F87J50 by measuring waveforms on a logic analyzer and also comparing the results to other time references. I suppose it's possible that I made a mistake, so please point out any errors.