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 .
People who have been long-time followers of this section will recall I said I would update it if or when the situation changed regarding availability of the Basic Interpreter FreeBas9k. Well, thanks to its author - Conrad Davis - it is now available again for download. I have not included a link to it from here just now, because it is liable to change soon, but anyone who needs it probably follows the relevant mailing lists and newsgroups, and will already have it or will know where to look. Anyway, once you have the interpreter safely installed, you may want a trivial Bas9k program I wrote called furby5.b9k (versions 1-4 never made it beyond the experimental stage) which goes in your 'Own Texts' directory. Remember to LOADOBJ COMM, otherwise it won't work. When you run it, simply push the keys according to the screen prompts. Range is limited - probably not more than 20-30 cm, but it appears to work fine, at least for me. Have fun, and I hope you think it was worth the wait. By the way, my program is not a textbook example of elegant programming - far from it, I was just interested in throwing something together that worked based on the approach outlined elsewhere on this page - I'm sure you can do better, and for the record I say again that anyone keen enough should be able to implement this method in a neat little stand-alone application for the 9110. Please tell me if you do!
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.
