Here's a list of new firmware features I'm working on adding to the IR Toy:
------------------------
v10 todo:
*Ir-man compatible to multi-protocol decoder, mode selectable, set in EEPROM
Maybe:
*SUMP metadata string
*metadata string with stuff like crystal speed that can be used to calculate the constants
-----------------------
All to-dos:
New IR sample mode:
*move to USB interrupt and make ir sample the main mode
*make IR sample the default mode??
*add buffer underrun error for transmit mode
[s:]*liyin no 0xffff option
*Duty Cycle adjustment for Sample Mode Transmit
*add bitbang commands for new hardware (input/output, high/low). read/write pins, set direction[/s:]
*[s:]adjustable sample length timer (the 21.3333us timer)[/s:]
[s:]*LED blink on/off configuration (LED mute/silent operation)
*Byte order[/s:]
[s:]*transmit mode[/s:]
[s:]*transmit frequency adjust[/s:]
[s:]*sample multiple raw IR frequency periods, report on the 0x04 command (3)[/s:]
Other stuff:
*selectable mode irman decoder (store settings in EEPROM)
*SUMP metadata string
*metadata string with stuff like crystal speed that can be used to calculate the constants
*debug behavior on suspend/wake
*add ability to wake PC over USB if possible (store protocol and remote code in EEPROM)
[s:]*Self test command line utility[/s:]
[s:]*manufacturing version power-on self-test (updated branch too).[/s:]
[s:]*LED blink on/off configuration (LED mute/silent operation)[/s:]
[s:]*Support for Hack a Day infrared receiver (18F2550 and 18F2455 versions)[/s:]
Software support:
(free IR Toy updated version for contributing these)
Lirc native support for sample mode
[s:]EventGhost Python plugin[/s:]
Transmit frequency adjust seems like a good idea ?
For transmitting you can put the frequency in the lirc config and it'll send that to the device before it sends, if needed.
Yup, the functionality is already there, I just needed to test it. I tested it and it worked OK, so I crossed it off the list. The TX mode is almost done too, just needs to be integrated fully.
Wake PC over USB? It's already happening, and don't like it. Lately, I'm unloading WinLIRC to make sure it doesn't happen.
When it gets too hot, I put the PC to sleep, with the fans connected to the PSU still working, so it's not a good idea to have the PC wake up by itself when I'm away.
Maybe what you suggest works in a different way, but it would be best to make the feature off by default.
Yes, the new feature will only wake on a match to the stored IR code.
I plan to look at your bug too, it's listed as: *debug behavior on suspend/wake.
Two new features added on the USB IR Toy Firmware:
- IR Reflection mode
- USB to UART mode
I uploaded it on the SVN.
The front-page blog says "intruder detection mode" - can anyone elaborate on this?
[quote author="rsdio"]
The front-page blog says "intruder detection mode" - can anyone elaborate on this?
[/quote]
I used 38khz ir led and tsop as "proximity" sensor... so first thing that crossed my mind is that ir is pulsing and when "intruder" is near ir toy sensor picks reflection and detects "intruder" I guess I'm completely wrong :)
Seems like you could place an opaque barrier between the IR LED and detector so that no local bleed is possible, then arrange a mirror so that the IR beam is reflected back to the detector. This could work as an infrared trip wire to detect an intruder opening a door or walking past a certain point. But, as I said, you'd have to make sure that the detector doesn't just pick up IR directly from the LED next to it.
I used heat shrinking tubing over ir led to prevent sensor detecting light from led itself. Also if sensor is say 38khz changing slightly frequency of ir led you can decrease detecting distance and use it to detect object distance... but every object has different reflection so it can't be used to measure actual distance... maybe if object is closing or moving away...
The intruder detect mode, or reflection mode, looks for bounced IR signals and sends a warning ("DETECT") over USB when the detected pulses exceeds a threshold. It was just a fun novelty to add, basically a diagnostic mode version of the self-test.
Will it support the 18F2455 as used in the hackaday IR receiver? or was 2450 a typo?
btw will recompiling the current FW for the 2455 work?
Yes, whatever the HaD receiver is will be supported.
As far as I know, it should work fine when compiled already, you don't even need to remove the bootloader stuff. The settings are already there in the hardwareprofile.h, but some of the features might not work (sample mode?).
Hmm I cant even get it compiling for the 2550. i think some things have changed in the USB files from Microchip. I'll make a new topic
The latest version is up, it includes the 2455 compile for the Hack a Day version. There's always new comments on that post, could someone please let them know that there's an updated firmware? I don't want want to come off as a spammer.
v09 todo:
*Duty Cycle adjustment for Sample Mode Transmit
*add bitbang commands for new hardware (input/output, high/low).
*liyin no 0xffff option
Maybe:
*add buffer underrun error for transmit mode
The 2455 compile seems to work. I burned the firmware to the chip with no bootloader (as i couldn't find a binary for the 2455 and couldn't compile it either) i tested it with winLIRC and could receive IR. haven't tried sending yet
is there a tutorial on setting it up as a IR blaster under linux?
Hi yaywoop - We haven't made a bootloader for the 2455. Which hardware are you using? The Hack a Day hardware (intended platform for the 2455 compile) didn't have an IR LED transmitter.
The IR Toy doesn't imitate an IR Blaster, but it has a similar custom protocol. The various software setup guides are in the manual here: http://dangerousprototypes.com/docs/USB ... y#Software (http://dangerousprototypes.com/docs/USB_Infrared_Toy#Software)
Thanks Ian. yeh im using a 2455 with custom board. i was just going to solder on an LED and resistor to the appropriate pin, would it be the same pin as on the IRtoy?
Yes, that should work.
v09 is up now:
*Duty Cycle adjustment for Sample Mode Transmit
*added bitbang commands to IR sample mode
*added serial UART write to IR sample mode
*liyin no 0xffff option
Can you elaborate on why Duty Cycle adjustment would be useful? Are there IR remote protocols which use something other than 50%?
Someone requested it, so I added it :)
v10 <== v09?
??? I'm keeping a single development thread for the ir toy firmware. After upgrading I just change the topic title.
[quote author="rsdio"]
Can you elaborate on why Duty Cycle adjustment would be useful? Are there IR remote protocols which use something other than 50%?
[/quote]
Hello rsdio,
With a lower duty cycle you can pulse higher current through the IR LED via a lower value current limiting resistor, thus increasing the transmitting range. It is very common practice. If I'm not mistaken, you can do away with the resistor all together if the duty cycle is low enough. I was very much hoping this feature would be added. Thank you Ian.
Edit: I just wanted to add that the duty cycle isn't a protocol issue at all and that IR receivers don't respond any differently. (other than the range :)
[quote author="Sig239"]With a lower duty cycle you can pulse higher current through the IR LED via a lower value current limiting resistor, thus increasing the transmitting range. It is very common practice.[/quote]Excellent point, since this is true for visible light LEDs, too. Each LED, even IR, lists a maximum DC current and a maximum AC current. For the original USB IR Toy LED, the maximum DC current is 200 mA, but the maximum surge current is as high as 2.5 A! (but the IR LED also has its higher Vf of over 3.6 V at that current, so you better have plenty of voltage, too.
In fact, look for a new project idea from me elsewhere in this forum (hint: it's gonna be about finding the best current and pulse width for a given LED).
If I'm not mistaken, you can do away with the resistor all together if the duty cycle is low enough.
Actually, you should never do away with the current-limiting resistor, because you're more likely to burn out some part of your circuit. The reason for the problem is that no resistor means you're asking for infinite current! Sure, some part is going to hit it's maximum current limit and keep things short of infinity, but parts don't last very long when you hit their maximum limits on a regular basis. Good engineering design suggests that you stay at least 10% below the rated maximums just for safety.
At the very least, for the original IR LED, you'd want a current-limiting resistor that keeps below the 2.5 A maximum surge current.
I am also getting issues, when using the IRToy record/playback utility.
At first I thought it was the old slow P4 computer, but it does occur infrequently on a fast core2 duo.
Portmon shows that all data is being sent and received (from PC perspective).
The IRToy behaviour is that it becomes unresponsive and the LED remains on.
Investigation with Hercules terminal sw, shows that sending FFFF, 00 puts the IRToy back to default mode.
Another symptom that may be unrelated, is the USB coms port will "fail". This appears to occur after many open/closes either via sw or un/plugging the IRToy. This requires a reboot to fix, or maybe un/re/install the driver as suggested above (elsewhere in forum?), so I am not sure if the USB driver is involved. If it was, then I would expect other software would also trigger these errors.
I am still trying to debug further to work out the trigger/s and isolate if it is a PC side issue (sw or driver), or IRToy firmware.
One thing that would be very helpfull is if the IRToy would respond when in Sample Mode - Tranmsit, once the "end" FFFF has been received. Say it could respond "tNNN". Where T=Transmit and NNN is the number of byte just transmitted. This would allow teh controlling program to validate - bytes sent AND that IRToy not still waiting for FFFF & appears stuck/hung!!!
Maybe this could just be a debug option command.
I'll keep looking into this, but I am very keen to hear from anyone with stuck/frozen IRToy with the LED on. If this occurs to you, try sending the FF & 5x00 commands to see if IRToy will respond, and post your findings please!
This is untested, but it should do what you want. It counts the total bytes sent (including oxff) and returns three bytes
t x y
the letter t, then two bytes (Hi 8, lo 8) of a 16bit transmit byte count.
Hey - thanks heaps for this update and the really quick response.
I can see in EventGhost via the LIRC plugin that it does indeed return the specified T HH LL bytes representing the length of last transmission.
I am struggling to debug at the moment with the IRToy rec/play tool - stability has 'gone out the window' - so I thought my bad coding was the issue. However reverting back to v0.2 and even just using Hercules was also very unstable (ie transmit once and either the coms port could no longer be opened, or windows reports usb device error, or IRToy still waiting for FFFF, and once even left in bootloader mode!).
This new instability of v0.2 & Hercules for me, has me stripping my systems back to eliminate issues, especially with the USB driver as I have several devices (Arduino, other PICs, FTDI serial links etc) that have at times interfered with one another. I'll keep plugging away, including downloading VirtualBox, so I can try clean builds in a virtual pc with USB support (has anyone tried this? - or should I try VMWare?)
Any suggestions would be welcome.
It sounds like there's a problem with the firmware. If you can reproduce it reliably then I can probably watch it happen under debug.
I wish I could reliably reproduce this issue (s?). Please try the following and see how you go. My only other suggestion is that I post the actual files I am sending. I have tried several recordings, they all seem the same to me.
Configuration: IRToy FW 107 & FW 110 and rec/play v02.
Symptoms - both FW 107 & 110, and all versions of IRToy rec/play, and sometimes with Hercules.
1. error sending data. Sometimes resolve by sending x00 or xFF, x00 to IRToy, otherwise IRToy now has symptom 2.
2. can't open com port. Often fixed by un/plugging the IRToy, sometimes need a reboot.
3. Windows USB device has malfunctioned. Nearly always requires reboot of computer, occasionaly un/reinstall driver fix (did not try this often).
Symptom - only with FW 110
4. IRToy rec/play v0.2, 0.3 "hang" waiting for IRToy sample mode response "S01".
How to reproduce:
Using any combination of IRToy FW & IRToy rec/play above, just play several files that you have previously recorded.
V0.2 of IRToy rec/play will typically play 3-4 files before giving "error sending data" messages. Later versions tend to fail quicker, sometimes even during initialisation of sampling mode.
What I can't understand is why the even IRToy rec/play v0.2 and IRToy FW 107 now seems MORE unstable than before I started developing!
My only guess is that I did not test thoroughly enough at first.
SysInternals Portmon - does not seem to make issues worse, does help seeing comms data.
Hercules - sometimes can manually send commands to reproduce issues, sometimes the setup (hercules to IRtoy) seems MORE unstable!
Possible causes in best guess order:
- the simple comms library used by IRToy rec/play
- instability of windows / usb driver, especially given issues I have had with Arduino, and other USB comms.
- in some situations my code may have more frequently triggered these issues.
Note: - I think at times each of the causes is involved - which might explain the differences in behaviour experienced.
Most important information is that:
Both WinLIRC and WinLIRC + EventGhost are stable on both test computers, with FW 107 & 110.
With FW 110, can see the return string T0088 etc.
This also seems to fit with the post on what comms library to use, see:- http://dangerousprototypes.com/forum/index.php?topic=1145.msg11999#msg11999 (http://http://dangerousprototypes.com/forum/index.php?topic=1145.msg11999#msg11999)
Where to from here?
I would like to hear test results from others to help refine our thinking. This is especially so because of my very long history of breaking things (eg ten years ago a software installation (just the license was $US50,000 ) was ditched, despite best two visits by the suppliers experts (involved two America to Australia trips!).
Thanks for the update, I'll try to reproduce the issue to eliminate problems in the firmware.
You mention FW 107, that's pretty old, and i think it has some know buffer overflow problems. I'd experiment with v09 and the v10beta only, or it won't be possible to discount any bugs we've recently fixed.
For a simple C app like this, there isn't much of a comms library used, it's just low level serial port stuff. We could use the updated serial source from piratePICprog, which should support Mac/Linux better, but the IR Toy app was developed on (and for) the PC serial port. There also isn't much of a driver to speak of, the system CDC class driver is used, and I get the impression it's pretty stable (Arduino, the old one at least, used a driver from FTDI and not the CDC-ASM).
The IR Toy app doesn't expect the extra data at the end of transmitting (unless you're using a modded version), that could cause some instability after repeated plays.
What operating system are you using? You mentioned an old P4, so maybe XP?
FW 107, that's pretty old
I was trying minimise the variables and being cautious as in the last year I killed a motherboard (security patch clash with video driver, eventually led to BIOS update = dead motherboard, and my new bus pirate was out of action for a while when I updated it's FW - I kill my stuff too! ).
Trying v09 - same as v10beta - hangs entering sample mode. Which is a puzzle to me, as I'm sure it works for lots of others and also because the WinLIRC/EG config is stable!
v10 - was more unstable with the IRToy app - at first hanging on 1st/2nd transmission, then on both computers would not even confirm entry into sampling mode.
Winlirc / event ghost was stable.
IR Toy app doesn't expect the extra data at the end of transmitting
Portmon showed with v10, that IRtoy re/play v0.2 was waiting for the read "S01" from entering sampling mode - so that was not the issue.
What operating system
- XP SP3 on both computers, just getting virtual box running, will try a clean Win7 - hopefully this will eliminate issues with other USB drivers.
I really appreciate the effort and help you are putting into this, thanks.
if you are programming and using the serial port
sometimes you might want to read the buffer or at least empty the read buffer of data. I do that in my send function to flush any data that might be waiting I think. Not the perfect solution but it works.
Minor Feature Request, full set of Getters.
Ideally there should be a GET for each of the SET commands, so that it is possible for software to query the state of the connected IR toy instead of having hard coded assumptions about the settings. In particular, I'd like to be able to get the transmit modulation setting, sample period, and prescalar. A nice to have would be the ability to query the clock speed that the firmware was compiled for to eliminate another assumption in software for any code that wants to do the math itself. I think this should allow software to be more robust for future firmware & hardware changes.
A suggestion regarding the default transmit modulation frequency. The wiki says the default is 36 khz. I think a better default value would be 38 khz which is used by some other software like LIRC. 38 khz seems to be the most common and is the median for 36 khz to 40 khz. Those using IR receivers that have their bandpass filter at 40 khz, will see better distance if they are using a 38 khz default instead of a 36 khz default. I haven't tested this so please feel free to correct me if I'm wrong.
Thanks,
--Rob
I'll change the default TX tomorrow, and add GET commands for the big items you mentioned. It might not be elegant because the protocol is a little mish-match. Maybe we can use the MSB to indicate GET/SET since LSB is already taken.
Is it too late to stake out a cmd prefix byte that begins a multi-byte command that would be the same in every mode and would give you enough "name space" for a full, orthogonal set of getters an setters?
I can keep cramming stuff in this state machine forever, but it's ugly ugly code :) We are so close to a new distributable USB stack with interrupts, that I don't want to invest a lot in this current mess.
I just added one command that reports all the config:
#define IRIO_DESCRIPTOR 0x23
Format:
irToy.usbOut[0]=PR2; //PWM
irToy.usbOut[1]=CCPR1L; //duty cycle
irToy.usbOut[2]=T2CON; //PWM prescaler, 2 extra bits of duty cycle
irToy.usbOut[3]=T0CON; //transmit timer prescaler
irToy.usbOut[4]=0x2; //48000000Hz (4 bytes)
irToy.usbOut[5]=0xdc; //add to USB send buffer
irToy.usbOut[6]=0x6c; //add to USB send buffer
irToy.usbOut[7]=0x00; //add to USB send buffer
This is a 'descriptor', though if you define a nice protocol based on the logic sniffer protocol I'll implement that instead:
http://dangerousprototypes.com/docs/The ... P_protocol (http://dangerousprototypes.com/docs/The_Logic_Sniffer%27s_extended_SUMP_protocol)
Firmware with this, and the 38KHz default TX attached.
I would like to clarify about the prescaler it is 4 or 7(21.3333)? Or we are talking for different 'prescaler' definitions?
..../IRs.c:
128 /*
129 * PWM registers configuration
130 * Fosc = 48000000 Hz
131 * Fpwm = 37974.68 Hz (Requested : 38000 Hz)
132 * Duty Cycle = 50 %
133 * Resolution is 10 bits
134 * Prescaler is 4
135 * Ensure that your PWM pin is configured as digital output
136 * see more details on http://www.micro-examples.com/
137 * this source code is provided 'as is',
138 * use it at your own risks
139 */
That is the prescaler for the transmit PWM, not the sampling timer (T2). The sample timer (21.33333) is T0 (T0CON register contains the values). The actual bits to test have to be referenced int he datasheet or by checking the code. I will try to document it, but it might be easier to define a protocol and shift them all out in the descriptor in a usable order.
[quote author="rct"]A nice to have would be the ability to query the clock speed that the firmware was compiled for to eliminate another assumption in software for any code that wants to do the math itself. I think this should allow software to be more robust for future firmware & hardware changes.[/quote]The other suggestions are good ideas, but the way the PIC works you probably don't really need to know the crystal speed. A USB PIC always divides down the external clock speed to a standard 4 MHz, regardless of which crystal is attached. From this master 4 MHz internal clock, the 96 MHz and 48 MHz clocks are generated for USB purposes, and the 12 MHz peripheral clock is also derived. The 12 MHz peripheral clock feeds all timers. I assume that both versions of the DP firmware for the IR Toy have the peripheral clock at its maximum of 12 MHz.
Then again, I suppose someone could write a firmware for lower power usage, and could decide to set the peripheral clock slower than 12 MHz. In this case, it would help to know the clock speed for calculating the proper timer values.
I guess this is the long way of saying that this "nice to have" feature should be focused on reporting the peripheral clock speed, not the crystal speed.
True, though a protocol-compatible serial port version could be made with a different clock, then it would be helpful in calculating the timers.
where is the "Ir-man compatible to multi-protocol decoder"
is already implemented?
usage mode?
thx