From the outset, I must say that this page is somewhat of a work-in-progress, and rather than hold back until I can get it _just_ the way I want it, I've decided the priority must be to share some of this stuff while it's fresh. So, it might get nicer, eventually. Topics more or less covered here are -
Since the beginning of time, mankind has speculated as to just how much fun could be had by using infrared to mess with his Furby. As you know, Furbys (correct plural) have an IR port (hidden behind that little dark plastic window between and just above the eyes) to enable them to interact with other Furbys. Since there is only one Furby chez Blank Frank (not true any more - Furby Baby arrived at Christmas, since this was first written), he decided to get out the scope and some junk bits and pieces to see whether there was another way of stimulating the furry automaton, and more specifically, to explore ways of making the thing go to sleep at the push of a button rather than using the masonic clapping and prodding sequence (which is a pain, and takes ages). The results of his efforts are presented below. Using methods to be described, Blank Frank can make Furby dance, sing, sneeze, burp, hide, some other things, and GO TO SLEEP. Please note that the hardware, software, methods and theory below apply to FURBY BABIES as well as the standard Furby. There is some supplementary technical information specific to Furby Babies at the bottom of the page.
And so . . .
Got a laptop or PC with an IRDA port? Good. Download furby.exe (V1.2, 17/10/99, 29.9k) and away you go. This is a dos app, but seems to work ok from Win95/98, though the timing is a bit less accurate. Doesn't seem to matter though. Run it in Dos Mode if you have problems. Stick the file anywhere - it's completely self-contained and defaults to COM2 (which is where BF's irda port lives) but you can change it from the command line ('furby ?' from command line tells you how). Plonk the Furby within maybe 50cm of the irda port and do what it says on the screen. Usual disclaimers apply. Suggest you give your PC a good reset before switching back to life-critical applications, just in case. Don't make Furby sneeze too often, or you'll give it a cold (that's what BF did). Note that on my laptop, the irda port can be set at bios screen for 1.0 or 1.1 mode. This does not make any difference to the software, either in dos mode or under Win98. As a precaution, when in Win98, I keep the irda port enabled but switch off the automatic hunting for other devices, in case the periodic pulsing upsets Furby. Even with IR disabled at the taskbar, the program still works the port, because the hardware is still there, only the higher level protocol stuff that Win98 likes is disabled. This section constitutes the entire documentation package either required or provided with furby.exe. Check back here from time to time for newer versions. At this time mainly bugfixes I expect, but I might add some other features eventually. Please report problems.
Furby.exe V1.2 has now been tested with a selection of PCs ranging from a 286 up to various speeds of Pentia and found in all cases to function with the IRDA Thingy (explained below) connected to normal RS232 ports. The speed of your machine is unlikely to be an issue. What can give rise to some confusion is exactly the number of COM port you use. This has to be given to the program with the logical name that the bios sees, not what might be reported in Windows. For example, my laptop has the irda port located address-wise where COM2 would be, and dos reports it as such - however, Win98 has it identified as COM4, so to run furby.exe I tell it to use COM2 whether I run the program from Windows or dos. The situation is different with a pure Windows program, about which more info below. Another thing which can cause problems is the irda port itself. Under Windows98 (and presumably other OSs), irda is more than just a wireless 232 port - it is a living, breathing thing with layers of drivers and protocol. Should you choose to try to use furby.exe from Windows, be aware that your irda port may already be active and firing out long packets as it hunts for remote devices to talk to, even though you have not been trying to use it. This will (at least) prevent furby.exe from sending recognisable packets to the Furby, but probably not cause any error report. You may be able to diagnose this problem by looking at your irda port through a camcorder or digital camera. The simplest way round it is to find out where the irda port lives from the bios point of view, switch your machine off and on and boot your machine to dos command prompt from a floppy, or do the F8-command-prompt-only thing at startup, to make sure you have exclusive use of the port, then try running the program. Lastly, some irda ports map to COM5 - 8. Sorry, but furby.exe can only handle the 'conventional' COM1 - 4 base addresses 0x03f8, 0x02f8, 0x03E8 and 0x02E8. If there is sufficient interest, I will modify the program to allow the port base address to be passed as a command line parameter. The problem of more 'exotic' COM numbers can be dealt with another way - see below.
FURBY.EXE REVISION HISTORY
06/10/1999 V1.0 First public release
09/10/1999 V1.1 Bugfix - baud rate not set correctly - no problems seen or reported, but if V1.0 doesn't work for you, V1.1 should.
17/10/1999 V1.2 Added Command Line option to launch the program, issue a Furby command then exit, without any screen output. So FURBY C1 /P would send the sleep command out COM1 then exit. It is intended to allow the program to be launched from other programs. If you don't need this function then there is no need to shift to this version.
The answer is a conditional YES, depending on your definition of 'proper', but there are brick-wall limitations the way I've done it. I decided to produce a proof-of-concept thrown-together sort of thing in Visual Basic (VB5) which we'll get to in a moment, but read this first. Because furby.exe is a brute-force dos app which is an objectionable approach to some, I thought it would be good to do to try to make something which could live in peace and harmony with the rest of the Windows desktop, using only nice polite requests for regular system resources. Hence the choice of VB5, which would slap my wrists if I tried to do something inconsiderate. VB allows a much wider range of COM ports to be accessed by name only (it takes care of the low level stuff) so I provided radio buttons for COM1 - 8 selection (could go higher if needed). It bombs out with a meaningful error message if you try to select one that you haven't got, or that is already in use - no problem, just try again and select a different port next time. It all appears to work fine with the IRDA Thingy below. The real fly in the ointment is (of course) the irda port, which WILL NOT WORK for the following reason. If the port is disabled from the contol panel (to stop all the protocol junk), VB can't open it, so the program fails. If the port is enabled, you get the junk, and VB can't open it because it's already open (doing the protocol junk) and the program fails with a different error. Catch 22, I think. Sure, there may be ways round this, by programming in c or something and handling the hardware directly, but that is a job for someone else - there's enough information in the Technical section to tell you exactly what's required from the serial port / timing point of view, if you want to do it yourself.
The other consideration is a practical one of bandwith allocation for this web site. My VB program is less then 50k, but if I try to make a proper distribution package of it, it grows to megs, and this would kill my monthly bandwidth allowance in just a few downloads, so I'm sorry, but I'm not able to provide the package. All you get here is the .exe file. If you don't already have VB5, or don't already have the necessary components installed (you may already have them from other installations you've done) DON'T BOTHER downloading the file - it will not run properly.
Right. If all the above hasn't managed to put you off, and if you want to have a 'proper' Windows application, and if you appreciate that this was an effort to prove a point, not to look good and be user-friendly, and you're happy to use the IRDA Thingy or equivalent rather than your irda port, here it is. Download vbfurby.exe (proof of concept V1.0, 11/11/99, 49k) and enjoy.
You need to build yourself Blank Frank's Little Furby IRDA Thingy, consisting of 2 resistors, a pp3 battery (with clip or on/off switch if bothered, but idle battery drain is virtually nothing), vmos (mosfet) transistor and IR led. Put the led on a long wire and stick the rest of the stuff except the battery (which dangles outside) in the D-connector shell (you want it to look nice) which covers the connector which plugs into a normal serial port (see diagram below). Then get the software above and play. The more sophisticated constructor may wish to steal power from a games port, the USB connector or tap into the keyboard cable. Whatever. Adjust the 100R resistor accordingly. Note that this is not a proper compliant irda port, but works a treat with Furby
A kind correspondent has just informed me that the the IR podule used for Lego Mindstorm makes a satisfactory substitute for the IRDA Thingy. If you have one to hand, this would definitely be worth trying.
Note that the transistor above (2N7000) is a mosfet. As far as substitutes go, VN10LM and VN46AF spring to mind as likely candidates but there are lots of others. There are good design reasons for choosing this device technology. If you wish to use a bog-ordinary NPN device or something, you'll need to make appropriate changes to the circuit, and, no, I can't give you details because I haven't had the need to work them out. The circuit and components as given have always worked fine for me.
Actually, two. Both battery-powered, based on a single chip micro. The deluxe model is built into a hollowed-out PC mouse, and allows various commands to be issued by fiddling with button combinations. The other is built into a keyfob, and is intended as a tool for weary parents, to put Furby into sleep mode pronto. Blank Frank would like 10% of net profit from anyone developing this commercially. It's all about packaging and cost. Here are pictures of the mouse-based one closed and open, and the keyfob one built into a converted RF car alarm thing, to give you inspiration. The mouse could do with a fancy paint job or fur, and the keyfob could do with a good clean. If you want the lowdown on how to build your own Furby Zapper click here .
Furby communicates using ir pulses approx 150-200 microseconds wide, which repeat every 1 or 2 ms depending on the logical value of the data bit being sent. That is, one bit time is 2ms; there will always be a pulse at the start of the bit time, and there may or may not be a second pulse halfway through the bit time. I have arbitrarily decided that a double pulse represents a logic 1 and a single pulse represents a logic 0 for the purposes of this description. In fact, it doesn't matter which is which, so long as consistency is maintained throughout. Furby comms packets consist of 9 bits sent six times, with silence between each set of 9 bits to give a repeat rate of about 100ms. The nine bits consist of a start bit (always a 1), 4 data bits, then the same 4 data bits inverted. The data bits form the logical payload, so there are only 16 possible packets. Packets which do not adhere to the 4bits/4bits inverted rule are ignored. Packets are ignored if Furby is doing something at the time. Example - 'sleep' is 4 ones, so from a binary point of view the packet would look like 111110000 sent 6 times. Furby is not very particular about the actual pulse widths it receives - anything from 8us to 208us has been seen to work - nor is it too fussy about the inter-pulse gaps - I have observed it working with packet times of 50% and 200% of nominal, but I haven't noted the exact tolerance on the inter-packet gaps, nor the minimum number of packets required - if anybody needs this info, it's easy to find out. I suspect Furby calibrates a timer based on the start bit timings, and so long as the timing is fairly consistent within a packet (or possibly set of packets) it is happy. The length of silences between sets of 9 bits does appear to be highly non-critical, but overall, it makes sense to try to send data which has a timing structure similar to what the Furby sends. The way an irda port works to transmit a character of asynchronous data, it sends a short ir pulse (pulse width will usually vary with baud rate [meant to be 3/16 of a bit time in the simpler modes], but anyway longer than nothing and not longer than one bit time - this is why the IRDA Thingy above manages to work too) at the start of the character start bit, and a pulse at the start of each following zero data bit (and not a pulse if the bit is a one), then not a pulse for the stop bit.
When you put all the above together, it follows that you can talk to the Furby by sending appropriate data from an irda port (or standard port with the Thingy), if the port is set for 4800 baud, 8 bit data, no parity, one stop. A character value of 0xff will result in one pulse (the start bit) and represents a Furby zero, and a character value of 0xef will result in two pulses (the start bit and the 5th bit) and represent a Furby one. As long as the uart is kept stuffed so there are no gaps between characters the timing works out very nicely. So, to send the 111110000 above, you would transmit 0xef, 0xef, 0xef, 0xef, 0xef, 0xff, 0xff, 0xff, 0xff as quickly as possible, then wait perhaps 80ms, and repeat, till it has been sent 6 times. Piece of cake, really. That's what furby.exe does, and the keys A to P represent each of the data patterns from 0000, 0001, 0010 . . . up to 1110, 1111. My descriptions of the commands are somewhat lacking in detail but tie in with what I've observed. Some of the commands elicit different responses if repeated - Furby cycles (or pseudo-randomly skips) through a pre-programmed set of possible responses to each command. You can email me with better descriptions if you wish, and I'll work on improving the on-screen info.
This picture spells out packet timing.
Looking at packets sent to and from Furbys (using an unfinished bit of software and some hardware not included on this page), it can be seen that Furbys sometimes send back the same packet that they receive, and sometimes they don't, and sometimes they don't send anything back at all. The fact that they sometimes give something different from what they get means that conversations can progress through various stages. Having considered mapping the whole thing out, Blank Frank has decided - for the time being at least - to place the project on the back burner due to pressure of time and other interests, but here is a general sort of observation of what appears to happen when the same packet is sent back to Furby that it has just transmitted. Starting with command code A (that is 0xf0, as in furby.exe), the conversation generally moves up through the command codes until it reaches P, when Furby goes to sleep. Progress is jerky and hesitant, often skipping some codes and sometimes backtracking a bit, but sleep is inevitably reached - no big surprise really, when you think about it. The only exception is if you happen to engage Furby in one of its games, in which case it appears to ignore all infrared stimulation until command mode is restored by ending the game.
In addition to the 16 comms packets used by standard Furbys, Furby babies recognise another 15 packets which do not follow the 4 bits / 4 bits inverted rule. These have a pattern 4 bits / the same 4 bits, and are recognised by other Furby Babies and ignored by original Furbys. Where the original packets corresponding to furby.exe letters A - P have equivalent data content 0xf0, 0xe1, 0xd2 . . 0x0f, the babies also support 0x11, 0x22, 0x33 . . 0xff. 0x11 seems to have a similar effect to B, 0x22 to C, 0x33 to D etc but a bit different, giving an extra richness to the range of conversations possible, and also allowing private conversations between babies in mixed groups. Also, pressing the rear switch on the baby elicits the response 0xff, and the front switch 0xdd.