 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
IBNobody
Joined: 06 May 2007
Posts: 124
|
 Posted: Tue Oct 23, 2007 9:03 am Post subject: Protocol Creation Help |
 |
|
I plan on creating a custom protocol for my IR to PS3-Bluetooth adapter.
The discussion is here, but I wanted to break the protocol discussion out because it directly involves JP1 remotes.
Synopsis:
I am currently running a 38kHz NEC2 protocol using a TSOP1738 IR receiver. I plan on creating a shorter protocol with a higher carrier frequency and faster pulse timing.
John recommended I switch to a TSOP7000, which operates at a carrier frequency of 455kHz.
Questions:
1. What is the highest carrier frequency that is supported on JP1 remotes?
2. Do newer remotes (ATLAS 1056 JP1.3) support higher carrier frequencies? |
|
| Back to top |
|
 |
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Tue Oct 23, 2007 10:00 am Post subject: Re: Protocol Creation Help |
|
|
| IBNobody wrote: | | I wanted to break the protocol discussion out |
Good idea.
| IBNobody wrote: | | I am currently running a 38kHz NEC2 protocol using a TSOP1738 IR receiver. I plan on creating a shorter protocol with a higher carrier frequency and faster pulse timing. |
I got the impression that NEC2 was nearly fast enough for you. So you might be able to create a fast enough protocol within the limits of a TSOP1738.
| IBNobody wrote: | | John recommended I switch to a TSOP7000, which operates at a carrier frequency of 455kHz. |
I don't think I "recommended". I meant to just point out the possibility, in case you wanted to make a protocol faster than the fastest TSOPxx56 can handle.
It is up to you whether to go a little faster than NEC2 within the limits of TSOP1738, or a lot faster with a TSOPxx56 (that can use fewer cycles at a faster frequency) or a LOT faster with a TSOP7000.
| IBNobody wrote: | 1. What is the highest carrier frequency that is supported on JP1 remotes?
2. Do newer remotes (ATLAS 1056 JP1.3) support higher carrier frequencies? |
Those don't sound like the questions you really mean, because there aren't a lot of choices for high frequency modulated IR detectors. 455Khz is pretty much the only high frequency for which you can get the modulated detector.
So your real questions are can JP1 remotes reliably generate 455Khz, and can JP1.3 remotes reliably generate 455Khz.
I expect the answer to both is yes. But I haven't ever done any significant testing of that.
Maybe someone else reading this thread actually has a device using 455Khz and a JP1 remote controlling it and can answer with more certainty.
I'll try to find some time to run a test myself. It's an interesting task, that I'd like to do to further test CaptureIR. I'm pretty sure my CaptureIR system on my faster computer can make sense of 455Khz with a raw IR sensor, to see some detail of what a JP1 remote sends when programmed to send 455Khz. I also have a TSOP7000, so I can connect that in place of the raw sensor to see what the signal looks like after it is processed by the TSOP7000. Of course, I'm not sure I'll find the time to do those things.
Regarding design of the protocol itself, read the datasheet for the TSOP you are considering. You will find the minimum number of cycles permitted in shortest period of modulation and the minimum gap permitted between such periods. That (possible with a little added margin) should define the shortest burst (typically the '0' bit) in your protocol definition.
In the datasheet, you won't find a spec for the minimum delta between two different burst lengths to allow those lengths to be meaningfully distinguished. For that you need to consider the (badly and incompletely documented) uncertainty in the timing of the leading edges, plus the uncertainty of the clock rate in your receiver and the uncertainty of the clock in your JP1 or JP1.3 remote.
With fairly stable clocks (which I think the S3c80 JP1 and JP1.3 remotes have), I expect you'll find a reasonable delta is equal to the minimum On time. For example, several fast protocols follow the specs of the faster TSOP parts with a minimum on of 6 cycles and a minimum off of 10 cycles. So the fastest burst is 16 cycles. Then they make the next slower burst 22 cycles by adding extra gap matching the on time.
Of course, if you choose a TSOP7000 rather than one of the faster TSOPxx56's, you can't be nearly as aggressive in selecting low cycle counts. But the higher frequency more than makes up for needing more cycles per burst. |
|
| Back to top |
|
|
IBNobody
Joined: 06 May 2007
Posts: 124
|
| Posted: Tue Oct 23, 2007 12:07 pm Post subject: |
|
|
Thank you, John.
From the extra research I've done, I think that the TSOP1156 would be a better choice over the TSOP7000. It would sidestep the 455kHz carrier question too.
The TSOP1156 shares many of the same characteristics as the TSOP1738, but is suitable for shorter bursts. The 1738 requires 10 carrier cycles on and 14 cycles off. As you stated before, the 1156 is 6 on / 10 off.
The reduction in times due to both the carrier and burst time changes is over 50%, reducing the repeat rate to roughly 50ms. If I remove the redundant sub-device bits, the rate is even lower.
I'm going to list the protocol in IRP notation. But before I continue... On your NEC2 IRP notation, you listed a 564us interval. How is this derived from the carrier frequency? |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Tue Oct 23, 2007 12:22 pm Post subject: |
|
|
| IBNobody wrote: | | On your NEC2 IRP notation, you listed a 564us interval. How is this derived from the carrier frequency? |
It isn't. I don't recall now whether it is derived (like most of the data I've posted in IRP notation) from averaging together a large number of samples captured in CCF files posted at RC, or whether (like a few of my posted IRP strings) it is taken from the nominal values given in some specification written by the developers of the protocol (NEC in this case).
All such values are approximate anyway. I'm sorry the value 564 looks like it is intended to be more exact than such a value actually can be.
The transmit logic in the JP1 remotes measures the On and Off durations in microseconds, rather than cycles. If that measure cuts the modulated On portion within its On phase, that will result in a truncated cycle, which doesn't matter at all if you're not pushing the limits of the IR receiver, but seems a bad idea if you are. If that measure cuts the modulation within its Off phase then nothing about the transmited signal will distinuguish it from a signal with a slightly different cut between On and Off within the same Off phase of the modulation.
I'm pretty sure that the On phase of modulation syncs well with the start of each burst. So if you want to carefully manage the number of On cycles, select an On duration that is divisble by 2uS and is less than the modulation cycle length times the desired number of cycles, but less by less than half a cycle. (If you want 6 cycles select a time greater than 5.5 cycles and less than 6). |
|
| Back to top |
|
|
IBNobody
Joined: 06 May 2007
Posts: 124
|
| Posted: Tue Oct 23, 2007 3:09 pm Post subject: |
|
|
So...
If I had a 56kHz signal and a min on count of 6.
[Carrier Period] = 17.86us
[On Time] = [Carrier Period] * 6 = 107.14us
[Off Time ] [Carrier Period] * 10 = 178.57us
I would need to choose an on-time of 100us, 102us, 104us, or 106us and an off time of 172us, 174us, 176us, or 178us. I would probably choose 104us / 176us.
But this may push the envelope of the IR receiver. I would be better off with a timing of 7 on, 11 off.
[Carrier Period] = 17.86us
[On Time] = [Carrier Period] * 7 = 125.00us (122us)
[Off Time ] [Carrier Period] * 11 = 196.43us (190us)
So if I keep with the NEC2 timings, I would end up with a 0 time of 321us (312us)and a 1 time of 714us at 7/11 (624us). This doesn't include the fudge times of 20%.
With a 4 ms lead in and the same structure as NEC2, this would give a minimum packet of 20.67ms. I'd double that to 40ms by adding in an extra 20ms of quiet time.
I can reduce things further by removing the subdevice byte. BUT I can't do that with Protocol Builder.
BTW: On PB, should I just keep the default processor or should I use something else? I'm developing for the newer Atlas OCAP remotes.
EDIT: Here's the protocol I came up with for the new IR receiver:
Upgrade protocol 0 = 01 DD (S3C8+) PB v3.12
29 62 11 8B 12 E5 45 08 08 00 3D 01 09 00 3D 00
4B 3A 98 03 E8 03 D4 8D 01 46
End |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Tue Oct 23, 2007 3:34 pm Post subject: |
|
|
| IBNobody wrote: | | So if I keep with the NEC2 timings, I would end up with a 0 time of 321us (312us)and a 1 time of 714us at 7/11 (624us). This doesn't include the fudge times of 20%. |
So you are saying '0' is 7-11 and '1' is 7-22.
I suspect the 6 cycle spec already had a margin for reliability and I'm even more sure the 10 cycle gap spec did, so I think 6-10 and 6-16 would be OK. 7-10 and 7-17 would have more than enough extra margin.
| IBNobody wrote: | | With a 4 ms lead in |
I have no good estimate whether a lead-in is helpful at all and if so, how much. Also be sure to check what the TSOP spec says about recovery time after long modulated periods.
| IBNobody wrote: |
I can reduce things further by removing the subdevice byte. BUT I can't do that with Protocol Builder. |
Why not?
| IBNobody wrote: | | On PB, should I just keep the default processor or should I use something else? I'm developing for the newer Atlas OCAP remotes. |
I've only used it for JP1 S3c80, so I don't know.
I think the protocol you're describing may be generic enough that most processor differences don't matter. |
|
| Back to top |
|
|
IBNobody
Joined: 06 May 2007
Posts: 124
|
| Posted: Tue Oct 23, 2007 4:00 pm Post subject: |
|
|
| johnsfine wrote: |
So you are saying '0' is 7-11 and '1' is 7-22.
I suspect the 6 cycle spec already had a margin for reliability and I'm even more sure the 10 cycle gap spec did, so I think 6-10 and 6-16 would be OK. 7-10 and 7-17 would have more than enough extra margin.
|
6-10 is a '0', and 6-16 is a '1', right?
I'll take your word on the reliability margin. As far as timings go, I'll see how things look after I apply the 20% fudge factor. I'd like to make sure that there is a gap between a '0' and a '1' acceptance time to make sure that a '0' can't become a '1'. With your NEC2 specs you gave me, a '0' could be 1.5ms, and a '1' could be 1.7ms. If the burst is inbetween the two, my current system throws an error. I'd like to preserve that.
| johnsfine wrote: | | I have no good estimate whether a lead-in is helpful at all and if so, how much. Also be sure to check what the TSOP spec says about recovery time after long modulated periods. |
It was 1.8ms on, 1.8ms off. 2ms on and 2ms off should work.
| johnsfine wrote: |
| IBNobody wrote: |
I can reduce things further by removing the subdevice byte. BUT I can't do that with Protocol Builder. |
Why not? |
It's not one of the dropdown options on the Signal Structure. I can do dev-cmd, dev-!dev-cmd-!cmd, and variations of this. There wasn't an option for dev-cmd-!cmd. I know you can probably do it, but it wasn't an easy option.
| johnsfine wrote: | | IBNobody wrote: | | On PB, should I just keep the default processor or should I use something else? I'm developing for the newer Atlas OCAP remotes. |
I've only used it for JP1 S3c80, so I don't know.
I think the protocol you're describing may be generic enough that most processor differences don't matter. |
Well... I'll be debugging the protocol before I start reworking my decoder. If it doesn't look right, I'll know. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
