Trying out the new sampling transmit mode. Does it actually work ? Every time I try it the light just stays on and the device appears to get stuck. Sending 0x0 5 times seems to reset it. Am i doing something wrong ?
Requests and idiots guide to the transmit mode.
The transmit mode works under debug, but it is not fully tested in real life. I'll do that today.
Here's the documentation:
http://dangerousprototypes.com/docs/USB ... .280x03.29 (http://dangerousprototypes.com/docs/USB_IR_Toy:_Sampling_mode#Transmit_.280x03.29)
Basically, go to sample mode (s), then send the transmit command (0x03), then send timing data, end with 0xffff during a blank period.
03 02 ff 02 ff 02 ff 02 ff 02 ff ff ff
That should give some results, but I'll validate it on a logic analyzer later today.
Ideally, when it receives a command to send it should block receiving infra-red until the send is finished. The serial port doesn't really work so well for asynchronous simultaneous transmissions :p Also if you don't block sending, the receiver will probably pick up whatever is sent, which won't be helpful.
[quote author="dukey"]if you don't block sending, the receiver will probably pick up whatever is sent, which won't be helpful.[/quote]Good point. I don't know of any IR remote that works well when more than one is used at the same instant, so there's not much benefit to IR reception while simultaneously transmitting. (Normally I favor supporting as many potential features as possible, just in case it might be useful, but in this case I agree with blocking)
The two systems do not operate independently. They share timer resources, and only one can operate while the other is active:
http://code.google.com/p/dangerous-prot ... /IRs.c#272 (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/USBIRtoy/IRtoy-firmware/IRs.c#272)
IR receive is triggered by change interrupt on a (PORTB) pin. That sets up timer 0 that counts until the next pin interrupt, each timer value is pushed into a buffer where it's passed to usb in the service loop. receive ends when timer 0 times out and fires an interrupt, then the 0xffff flag is sent.
Transmit disables the pin interrupt. It sets timer 0 at 0xffff-time, when it hits 0xffff it fires an interrupt, we invert the transmit state, and setup timer0 for the next transmit time period.
The code quite readable, it's 80% comments. You'll probably both see tons of stupid things I did :)
hm I think I've somehow broken mine
when i press T for test
it returns this
FAI2
Be sure to hold it next to something white. error 2 is a problem with the LED activating the receiver. The LED is very directional and it doesn't always reflect back into the receiver. Be sure to do it on a freshly reset device too, the irsample mode could be messed up and not returning the PWM to the correct state.
Here's the self-test documentation:
http://dangerousprototypes.com/docs/USB ... umentation (http://dangerousprototypes.com/docs/USB_IR_Toy:Self-test_documentation)
[quote author="ian"]Transmit disables the pin interrupt. It sets timer 0 at 0xffff-time, when it hits 0xffff it fires an interrupt, we invert the transmit state, and setup timer0 for the next transmit time period.[/quote]This is a quick note, so forgive me for not looking at the source or data sheets ... I believe that the timer works by setting it to 0x10000-time, or 0x0000-time with wrap-around. Or, looking at it the other way, the timer does not fire an interrupt until it counts past 0xffff, not when it first counts to 0xffff. If you have an accurate time reference, you can test this, or just double-check the Timer chapter in your handy PIC data sheet.
you're probably right! I'll look into this.
I think the released v06 firmware was compiled with the old irs mode.
On the 'correct' firmware:
Test string is play on RC5 remote:
00 2C 00 27 00 54 00 51 00 2A 00 27 00 2C 00 27 00 2A 00 27 00 54 00 51 00 2C 00 27 00 54 00 51 00 54 00 51 00 2A FF
Using the correct firmware, I sent this:
{03}{00}{2C}{00}{27}{00}{54}{00}{51}{00}{2A}{00}{27}{00}{2C}{00}{27}{00}{2A}{00}{27}{00}{54}{00}{51}{00}{2C}{00}{27}{00}{54}{00}{51}{00}{54}{00}{51}{00}{2A}{FF}
And got this back on a second IR toy:
-------------------{00}{28}{00}{54}{00}{53}{00}{29}{00}{28}{00}{2C}{00}{26}{00}{2D}{00}{28}{00}{54}{00}{53}{00}{2B}{00}{28}{00}{54}{00}{53}{00}{53}{00}{53}--------------{FF}
So there's something being missed still, I guess the first and last data are not being handled correctly (the ------- area).
------{00}{2E}{00}{27}{00}{56}{00}{50}{00}{2C}{00}{26}{00}{2E}{00}{27}{00}{2C}{00}{26}{00}{56}{00}{50}{00}{2E}{00}{27}{00}{56}{00}{50}{00}{56}{00}{51}{00}{2C}{FF}{FF}
{03}{00}{2C}{00}{27}{00}{54}{00}{51}{00}{2A}{00}{27}{00}{2C}{00}{27}{00}{2A}{00}{27}{00}{54}{00}{51}{00}{2C}{00}{27}{00}{54}{00}{51}{00}{54}{00}{51}{00}{2A}{FF}{FF}
There we go, RC5 decoder mode also decodes this without problem.
The on periods are consistently 2 periods shorter, so I'd guess that it is off by at least one.
I'm not sure the best way to subtract from 10000 since the data arrives (and goes to the timer) as 2 8bit bytes. Probably I'll need to put them in an array and then grab it as an INT and increment. I believe the timer has a 16bit mode, that might help.
Attached is a working firmware.
{03}{00}{2C}{00}{27}{00}{2A}{00}{27}{00}{2B}{00}{27}{00}{2A}{00}{27}{00}{2C}{00}{27}{00}{2A}{00}{27}{00}{54}{00}{51}{00}{2C}{00}{27}{00}{54}{00}{51}{00}{54}{00}{51}{00}{2A}{FF}
------{00}{2C}{00}{26}{00}{2B}{00}{25}{00}{2C}{00}{25}{00}{2B}{00}{25}{00}{2D}{00}{25}{00}{2B}{00}{25}{00}{54}{00}{50}{00}{2D}{00}{25}{00}{55}{00}{50}{00}{53}{00}{51}{00}{2B}{FF}
This is a little better, but the spaces are all too short.
There is a little echo from the IR receiver self-activating:
{00}{09}{FF}
It looks to be 9x21.2us long :) I need to work on that next.
Yeah I noticed too there was an acho from the receiver. Can you disable it until sending is finished ?
It is disabled until sending is finished, but there is some bounce on the receiver (it doesn't go back to 1 right away)
Well,
I've got sending working in my irtoydll for winlirc. However when you send a command. The light stays on, for like 30s after tranmission. And it won't receive until it turns itself off again, ie after 30s. lol
Not sure if this is my code or the receiver. Any ideas? :)
can you upload the DLL? I can test while connected to a logic analyzer. Part of it is that I have not added a debounce routine for the receiver. We nened to ignore it for at least 10x21.3uS after the transmission ends. If we looked at the datasheet for the receiver, I bet this is close to the average recovery period :)
http://rapidshare.com/files/415520275/IRToy.zip (http://rapidshare.com/files/415520275/IRToy.zip)
I must admit that I've always used the PIC Timer with static values, so I do the math on a hex calculator and then type in the constants (with a few comments in the code to remind me of where the magic numbers came from).
[quote author="ian"]The on periods are consistently 2 periods shorter, so I'd guess that it is off by at least one.
I'm not sure the best way to subtract from 10000 since the data arrives (and goes to the timer) as 2 8bit bytes.[/quote]For dynamic values, I would do a 16-bit unsigned subtract from 0x0000 instead of attempting a long 0x00010000.
Probably I'll need to put them in an array and then grab it as an INT and increment.
Combining the 2 8-bit bytes into a 16-bit variable should not be too difficult, although I tend to write the Timer stuff in assembly for interrupt speed rather than C. Isn't your data coming in from an array already? In C, I would use ((int)x << 8) to get the high byte. I don't recommend casting the actual 8-bit data to 16-bit because you're more likely to get the byte order wrong. Hope this makes sense.
I believe the timer has a 16bit mode, that might help.
You probably should use the 16-bit Timer mode. Actually, I don't understand how you're sending two 8-bit bytes to the Timer if you're not in 16-bit mode. ?
I don't recommend casting the actual 8-bit data to 16-bit because you're more likely to get the byte order wrong.
Yup, I went with the bit shift routine, but I thought some pointer and cast magic to 16bits would be cleaner than all the >> |= &0xff's:
//prepare the values for the timer
//subtract from 0x10000 (or 0x0000)
//this would be a lot nicer with a little pointer magic
//but for now we dance (test)
tmr16=tmr0_buf[0];
tmr16<<=8;
tmr16|=tmr0_buf[1];
tmr16=0x0000-tmr16;
tmr0_buf[1]=(tmr16 & 0xff);
tmr0_buf[0]=((tmr16>>8)&0xff);
Actually, I don't understand how you're sending two 8-bit bytes to the Timer if you're not in 16-bit mode. ?
My problem is I read 5 or 6 PIC datasheets a day now and can't keep them straight.... IR Toy does use a 16bit timer, currently loading L then H (or reverse, there's a specific order). Some PIC timers can be set for 16bit access too and you can give them the full 16bit value in 1 integer write. I thought I might be able to send the 16bit int to the timer without tearing it back apart. Not this PIC though, I checked after writing that above.
[quote author="ian"]I thought some pointer and cast magic to 16bits would be cleaner than all the >> |= &0xff's:[/quote]It could be. I retract my recommendation, since it was motivated by "portability" but you're not going to be able to port PIC code anywhere else without rewriting the Timer code anyway.
Since USB is supposed to be little-endian (provided the host app honors that when putting together the packets), you can probably safely do some casting, although I don't really know specifically how the PIC handles 16-bit data since it's an 8-bit.
My problem is I read 5 or 6 PIC datasheets a day now and can't keep them straight....
:-)
IR Toy does use a 16bit timer, currently loading L then H (or reverse, there's a specific order). Some PIC timers can be set for 16bit access too and you can give them the full 16bit value in 1 integer write. I thought I might be able to send the 16bit int to the timer without tearing it back apart. Not this PIC though, I checked after writing that above.
Ah, yes. There's two issues. First, whether the Timer is in 8-bit mode or 16-bit mode. Second, if it is in 16-bit mode, whether you access the count via two 8-bit accesses or one 16-bit access. I think that I tried accessing a 16-bit Timer count with a 16-bit access on the PIC18 with no luck. Obviously, it's a different story on one of the 16-bit PIC models like PIC24 or dsPIC3x
Hi everyone
Trying to get the transmit mode to work here to train my remote with RC5-codes to see if I can avoid all the hassle with decoding the NEC2/Pioneer protocol..
However nothing seems to be sent, and when I run the self test I receive FAI4 as the answer. If I press T repeatedly I sometimes also get FAI6.
Anyone know what 4 is? The documentation only lists 1, 2 and 3.
What I send to the IR Toy in order:
s, to set sample mode
bytearray with timing info
0xFF
0xFF
Am I sending the correct stuff or have I misunderstood anything?
I'm using the latest firmware posted in the "DEV: IR Toy firmware v07" thread.
Cheers,
/Shadowsoul
I think the transmit mode is still somewhat, broken.
The latest firmware from the dev thread should give some functionality, especially for your use. I still need to roll some debouncing routines into it, but lack of that shouldn't hurt what you're doing.
What I send to the IR Toy in order:
s, to set sample mode
bytearray with timing info
0xFF
0xFF
be sure to trigger the transmit mode with 0x03 first:
http://dangerousprototypes.com/docs/USB ... .280x03.29 (http://dangerousprototypes.com/docs/USB_IR_Toy:_Sampling_mode#Transmit_.280x03.29)
s, to set sample mode
0x03 - to start transmit mode
bytearray with timing info
0xFF 0xFF to end transmit mode (should be during a blank period)
when I run the self test I receive FAI4 as the answer. If I press T repeatedly I sometimes also get FAI6.
Anyone know what 4 is? The documentation only lists 1, 2 and 3.
If you hit 'v' you'll probably get v207 reply. It looks like the version detector isn't 100% yet, probably because a neighboring pin is high and holding it up. I'll improve the check routine in tomorrow's release.
The new error (100) is failure of the frequency detector, which the current hardware doesn't have :) 6 (110) is just the combination of error 4 (100) and 2 (010), like 3 (11) is the combination of 2 (10) and 1 (01). All errors would be 7.
[quote author="ian"]
[...]
be sure to trigger the transmit mode with 0x03 first:
http://dangerousprototypes.com/docs/USB ... .280x03.29 (http://dangerousprototypes.com/docs/USB_IR_Toy:_Sampling_mode#Transmit_.280x03.29)
[/quote]
When you say "trigger the transmit mode" what do you mean?
As it stands I have tried first sending "S", then 0x03, then a bunch of bytes for the timings, then finish with 2 0xFF to end it, I have also tried skipping the "S" in the beginning, the difference is without the "S" first, I get the "S01" response to 0x03 instead of to the "S".
The LED blinks every time I press send.
Could it be something as simple as the frequency? I saw that the command 0x02 were to set frequency modulation...what will it affect? I have not done anything about it, could it be that the default setting is outside the range accepted by my remote perhaps?
You are correct, I get v207 as response so the firmware is correct.
I noticed i missed the 0x03 part in my previous post, perhaps that was what you noticed missing?
Cheers,
/Shadowsoul
Isn't V207 for the upcoming IRToy 1.1?
v07 is still very much under development, I'll try to release a final version today.
When you say "trigger the transmit mode" what do you mean?...
I noticed i missed the 0x03 part in my previous post, perhaps that was what you noticed missing?
Yes, the 0x03 was missing from your previous post. What you did sounds correct. S for mode. then,once in sample mode, send 0x03 to start the transmitter, then data that ends with 0xffff repeat 0x03 data oxffff to send more packets.
I have also tried skipping the "S" in the beginning, the difference is without the "S" first, I get the "S01" response to 0x03 instead of to the "S".
until you hit 'S' it is in RC5 decoder mode, it has no transmit. Probably one of the bytes is an ASCII s/S and it just self-triggers.
Could it be something as simple as the frequency? I saw that the command 0x02 were to set frequency modulation...what will it affect? I have not done anything about it, could it be that the default setting is outside the range accepted by my remote perhaps?
The default is 36khz (38?), whatever the common standard is. There is a tutorial on how to use the frequency adjustment command under the IRIO mode documentation on the wiki.
You are correct, I get v207 as response so the firmware is correct.
Yup, the version detector is not working yet, will fix that today.
Isn't V207 for the upcoming IRToy 1.1?
No, it is a universal firmware for all versions.
adding... I've been testing with a logic analyzer and everything looks OK. Please post a sample packet and I'll test it here.
Well,
I think I finally got it working !
LIRC sends an actual space at the end of the transmission for the gap. This was needed for the serial plugin otherwise it actually left the transmitter in the on state :o Critical bug lol. But the space at the end for the ir toy was also causing a cataclysm. You just can't win sometimes. The transmitter seems a little weak though ?
Glad you got it working!
Thanks for the report on the transmitter, I'm looking into it.