If we manage to get bluetooth to connect, it works great while RobotC stays running, but after we exit RobotC and start it again, we can't connect again on Bluetooth.

These are the errors we generally get:
45.215 create NXT Iterator FAILED (xFFFDD53F/-142017) 'Fantom Err: 'No More Items Found''
45.737 create NXT Iterator FAILED (xFFFDD53F/-142017) 'Fantom Err: 'No More Items Found''
46.282 Starting connection to BT brick (BTH::Hacksaw::00:16:53:06:A8:DC::5)
50.887 ...Created NXT handle for 'BTH::Hacksaw::00:16:53:06:A8:DC::5' FAILED (xFFFDD538/-142024) 'Fantom Err: 'Failed to connect. Power cycle NXT''
59.100 Closing communications link
59.100 'CCommLinkHandler' Destructor called
59.103 Destroying window


If we hit F5 again, NXT chirps, and then get
457.751 create NXT Iterator FAILED (xFFFDD53F/-142017) 'Fantom Err: 'No More Items Found''
458.015 create NXT Iterator FAILED (xFFFDD53F/-142017) 'Fantom Err: 'No More Items Found''
458.280 Starting connection to BT brick (BTH::Hacksaw::00:16:53:06:A8:DC::5)
459.214 ...Created NXT handle for 'BTH::Hacksaw::00:16:53:06:A8:DC::5' FAILED (xFFFDD539/-142023) 'Fantom Err: 'Retry the connection''
468.887 Closing communications link
468.887 'CCommLinkHandler' Destructor called
468.890 Destroying window

and a message box that says Fantom Err: 'Retry the connection'

I know a lot of people had these sorts of problems last year in FTC but we generally didn't. This year, we have a new(er) computer (Dell D410 XP SP3), just intalled the 2.00 version of RobotC (copyrighted in 2010, which I bet will amuse some lawyers) and now we can't reconnect for love nor money.

There is a certain shaking of the dead chicken ritual which seems 90% effective:
exit RobotC
In Bluetooth Control Panel, Remove the NXT.
On NXT Bluetooth, Trash the MyContacts entry.
Start RobotC
Link Setup
Click on NXT in the "Reachable" list (where it is displayed without ::5 suffix)
Select via BT
OK the prompt about the orange button (we have it set to default passkey)
NXT chirps
Windows says New Hardware found... yada yada ... ready to use
Close
F5 downloads and starts the debugger.

There are times where all this shaking of the chicken plus removing the USB dongle and NXT Bluetooth Reset were also needed, but in many attempts today, this was successful.


So, here are the questions:
1. Why?
2. When you F5, there is a NXT chirp, and then it searches. What is the chirp? Why does it feel the need to search afterward? (i can disable the subsequent search via View->preferences, but it still doesn't connect).
3. Why does the "found new hardware" thing happen over and over? (i think I understand why in the case where I "Removed" them manually, but in the case where I just stop RobotC and start it again, the list of Bluetooth devices seems to go away first, then attempt to come back by Found new hardware.
4. What is the difference between "Select" and "Select via BT"?
5. Should anything happen if Help is pressed on Link Setup?
6. Does anyone know what happened to the SDK and HDK info that used to be on the Lego site? http://mindstorms.lego.com/Overview/nxtreme.aspx
7. Is there any relationship between particular computers and bluetooth/robotC problems? Certainly whatever was being used at the FTC competition last year gave our valiant volunteers unbelievable trouble. I would say it was bad enough to hurt the prospects of the FIRST Tech Challenge's future, and certainly resulted in the BYOC policy at Atlanta championships. Our team's dodgy old laptop seemed to work pretty well.
8. Does the RobotC 2.0 download include all the latest drivers?
9. If Bluetooth configuration is performed completely through the Windows ControlPanel GUI, is there a way to tell RobotC to just use COM5 and don't ask any questions?

I would really like to help get to the bottom of these issues, even if it means long hours on the phone with the folks at NI responsible for the fantom DLL. I can live with a wired connection for now, but the bluetooth wrestling match really needs to end for FTC to survive with this platform. Maybe having a computer, like ours, that repeatably acts up will help track it down.

Please let me know what I can do to help.

Thanks,
David Fort
Mentor, Team 1001

Unfortunately ROBOTC is at the mercy of the BT connection dependencies involved. That is Windows itself, the Fantom.dll developed by NI, and the ROM code in the BT chip on the NXT which is different from the downloadable firmware.

I can appreciate your pain. I spent most of an evening last week getting a BT connection working.

There is no precise "recipe" to get a paired connection established. There's a lot of uncertainity in the precise causes of the problems.

But I can suggest two things.

Make sure you're using either the Microsoft or WidComm BT software stacks / device drivers on Windows. These are the only two supported by the Fantom.dll. Some BT devices come with drivers from Toshiba, BlueSoleil, ...

Fantom has a fixed 10-second timeout for Windows to install device drivers. Windows does this as part of setting up a paired connection. 10 seconds is often too short. So system gets in a mismatched state where Fantom thinks pairing failed while Windows thinks it succeeded. If you're lucky a Windows restart and NXT power cycle will cure this and both devices will think they are properly paired.

If you can't get connection paired using ROBOTC which uses the Fantom.dll then try setting it up manually via the Windows Bluetooth Control Panel. Before trying to pair do the following:

• Use "Reset Bluetooth" command built into ROBOTC's firmware on-brick GUI. This is supposed to reset the BT chip to the original default configuration and erase all history.
• Power cycle the NXT
• Delete all paired connections known to Windows.
• Possibly restart Windows to sure BT is in a pristine state.
• Even better unjack the BT dongle and re-install it in a different USB port.
• Try to set up paired connection via Windows Control Panel.

The chirp you heard from the NXT is likely ROBOTC firmware saying "i've automatically responded to the password/PIN request for BT because you have enabled this feature". Alternatively it may be chirping to get your attention because you need to manually enter a PIN code via the NXT buttons.".

If you have NXT-G or LabVIEW installed you could try to set up BT using one of these environments. But I have never got this to work. If ROBOTC won't work then I've always found this to be the case for NXT-G as well.

Sorry I can't give you any better advise.

Do you know if the NI Fantom.dll "remembers" the state of Pairing and/or Connections?

i.e. it looks like Windows remembers Pairing in the Registry. Does Fantom.dll have its own idea of the Pairing?

(and fwiw, I agree with your hunch about 10 seconds not being enough time. On this new laptop (d410) it takes about exactly 10 seconds to go through the New Hardware wizard).


On the NXT end, there is a "My Contacts" entry displayed on the LCD in the Bluetooth settings. Is this the same thing/copy of/independent of Pairing information that is stored in the memory private on the Bluecore chip?

These questions are aimed at a better understanding of where the "mismatched state" is stored.


and fwiw, on this laptop at least, establishing the Pairing in Windows is actually the Opposite of the trick that makes it work. I have to Remove the pairing using Windows, then let RobotC establish it again (which will go through the New Hardware . . . )

Fantom uses the Windows registry entries.
On my VISTA desktop I've seen over 20 seconds.

"My contacts is different from the stored pairing list. It contains a list of actual connections that have been made. The Bluetooth chip on the NXT has a separate larger "invisible" list of paired connections. I suspect that the original design intent was that these were the same and not different. I also suspect when they get out of sync is one of the causes of the problems. They can get out of sync if pairing works but Fantom failed to recognize that it worked; because the next step after successful pairing is for Fantom to make a brief connection to get the "friendly name" and other parameters from the NXT.

This is why I recommend uses the "Reset Bluetooth" command in ROBOTC on-brick GUI. [This command is not exposed in NXT-G firmware].

Can RobotC programs access the CMD mode of the Bluecore chip?

e.g. can a RobotC program send the commands listed in the Appendix 8, Lego Mindstorms NXT ARM7 Bluetooth Interface Specification, such as DumpList or RemoveDevice?


Is documentation about writing applications using the Fantom.dll available? Is the source to the Fantom.dll available?

I would really like to develop an understanding of exactly what gets out of sync, in the hope of either developing a reliable work around, a set of tools that automatically fix it, or improvements to the Fantom.dll and/or NXT firmware to prevent it.

Thanks,
David

The simple answer is no.

The more complicated response is many of these messages are for internal use in firmware and for user to use them would screw up the internal firmware device drivers. For example, "DumpList" command then generates many internal reply messages that are processed by the device driver to create the "My Contacts" list. If a user program generated a "DumpList" it would undoubtedly crash the device driver.

Some of the Bluetooth commands are wrapped in ROBOTC function calls so that they are accessible to end user programs. I believe ROBOTC has similar functionality to NXT-G firmware in this area and above comments also apply to NXT-G.

Documentation is available. It is either in the LEGO supplied development kit or in one that you download from NI (National Instruments) web site. You'll find fantom.h and fantom.lib files there. And Doxygen documentation.

Source code is not available. It is proprietary to NI.


You are not the first to try. Good luck.

Assuming you're an experienced Windows programmer the first thing that I would suggest focussing on the Windows side. See if you can call the Windows drivers to enumerate BT devices, to pair devices, to unpair devices and to open and close the virtual serial port. And to clean the Windows registry of any associated BT entries related to NXTs. Once you have this working, then see if your routines when fantom does not.

On the NXT side, the ROBOTC GUI command to "reset BT" coupled with power cycling the NXT is supposed to totally reset BT to a pristine state. The ROBOTC (and NXT-G) firmware do not store any BT connection or pairing status across a power cycle. When NXT is powered on all this data (including "My Contacts" list) is retrieved from the NXT's BlueCore hardware chip. As far as the ROBOTC firmware is concerned, the Bluecore chip is a "black box".

The Bluecore chip has its own microprocessor, RAM and Flash. It stores pairing information there. It also stores the "My Contacts" list as well; but the NXT firmware tells it when to add and remove these entries.

Ok, I've got what seems to be a solution. If you don't want to wade through the process I used to get there, skip to the bottom.

First some cultural enrichment (obviously not for Mr. Swan - but perhaps useful to some FTC kids):
The description of Bluetooth on the NXT and the interface (aka API) for the Fantom.dll can be found in the software development kit here:
http://mindstorms.lego.com/en-us/suppor ... fault.aspx

Fantom.dll is library of functions useful for communicating to a NXT over Bluetooth or USB. It is written by National Instruments and uses some of their VISA or VXI interface libraries also. I'm willing to believe it doesn't really need to be this complicated.

Using the Fantom.dll, you can write programs that discover what NXTs are in the neighborhood (on USB or BT) and send them commands, or reprogram their firmware, or load files on, etc.

The functions are things like (names simplified to protect the innocent):
CreateIterator -- get a list of NXTs you can talk to. If you have a BT paired one, you will get it even if it is off.
GetName -- get the "BTH::Hacksaw::00:16:53:06:A8:DC::5" sort of name
isPaired -- Is the NXT already paired with Windows? (i think it just checks if there is a ::5 com port suffix on the name)
pairBluetooth -- Do the same thing as "Add" in the Bluetooth control panel (almost: it only sets up the outgoing COM port). Note this actually uses the bluetooth control panel, bthprops.cpl via OLE automation (i think).
getNXT -- This gets an object that can be used to send NXT commands, transfer files, etc. After you call it, you will see the "<>" symbol in the bluetooth display on NXT.
sendDirectCommand -- for example, make it beep
createFile -- make a file on the NXT - same as API exposed for same in RobotC pretty much.

There are others, but these are in the example C++ program in the documetation of the fantom.dll referenced above.

A couple of notes about using the example:
If you want to use Bluetooth, change the false to true in the CreateIterator and make the timeout not 0. 3 still seemed too short, but 5 works for me.
The help files say something like this for most of the functions: "The pairing is not done if the specified status is fatal".
That isn't awkward engineerspeak for "If it fails, we didn't do it". It really means if the status parameter you pass in already has an error code in it, then this function will return without doing anything. I think the intention of that is that you could string a big sequence of Fantom functions together and if the first on fails, the others won't bother to try. This alleviates the need to check the return status of every function, but also makes it so when you get to the bottom and you have a failure status, you have no clue which function was the one that failed. You can status.clear() to get rid of the error number so status can be passed in to a new function.

A good example of this "feature" is when you get an Iterator for your NXTs in range, and then Advance() through the list until you reach the end. At that point, your status variable will have an error code in it that means you reached the end of the list. If you re-use that status variable without status.clear() ing it, then subsequent functions won't attempt to do anything.

The Fantom.dll functions return 3 categories of error status values. Some are described in tStatus.h:
//! Error: Bluetooth pairing operation failed.
//! Warning: You have already paired with that Bluetooth device.
kStatusPairingFailed = (kStatusOffset + -5), // 0x54B
others are in the NI VISA Programmer Reference:
VI_ERROR_RSRC_NFOUND BFFF0011h

I ran more or less the example fantom program right out of the help file, and it works OK on one of my computers and not on the other. As when using RobotC, the bad one ONLY works if I manually Remove the NXT from Bluetooth ControlPanel and Reset BT and trash My Contacts on the NXT.

In my case, on my troublesome computer (Dell D410 XP SP2), I notice 2 things:
From the Unpaired condition, a pair() call will go through the "found new hardware" noise in the system tray, and it will return a 0 status (ok), but if I don't wait a few seconds after that before re-creating the Iterator and calling getNXT, then getNXT will fail with error 0xBFFF0000, which means "Unknown system error (miscellaneous error)." which I don't find particularly illuminating.

On a subsequent run, from the Paired condition (whether paired using the Fantom pair() function, or using the bluetooth control panel), the Iterator works fine, but getNXT fails with 0xBFFF0000.

So, at this point, we have reproduced the problem I see in RobotC without using RobotC at all. (I am getting a different error number than reported by RobotC, but I can imagine a lot of reasons that might be the case).

I did not achieve my goal of understanding exactly what gets out of sync or whatever.

This led to questions about versions of the pertinent DLLs, but I found them to be the same on both machines:
fantom.dll -- 1.0.2.49152
visa32.dll -- 3.4.0.49152
NiViAsrl.dll -- 3.4.2.49152
NiViUsb.dll -- 3.4.2.49153
(note: I didn't think to check the NiVi...dll file versions until later - so I'm not 100% sure this is what was there at the beginning).
Both machines had the same version of Microsoft Bluetooth drivers:
bluetooth enumerator 5.1.2600.5512
bluetooth radio 5.1.2600.5512
xp sp3


So I wondered if NXT-G would have this same problem with Bluetooth communication. I installed NXT-G from the disk that comes with the FTC kit this year, and voila, my example Fantom client program works. Works starting from unpaired state, paired by ControlPanel, and paired by Fantom pair() function.

The versions installed with NXT-G are:
fantom.dll -- 1.1.0.49153
visa32.dll -- 4.1.0.49152
NiViAsrl.dll -- 4.1.0.49152
NiViUsb.dll -- 4.1.0.49152

The dates on these are in 2007.

Conclusion:
1. Something is wrong with the NI dll's that causes a getNXT to fail if already paired (on some machines).
2. It has been fixed for a couple years, and Lego is currently shipping the fixed version.


David Fort
Mentor, FTC Team 1001
Rockwell Automation

p.s. i posted the example project with Visual Studio 2008 project files as an attached .zip file (in case anyone wants to tinker).

Great research and explanation. Thanks a lot for this

Two things.
1. This thread is now a sticky.
2. My FANTOM DLL version is actually 1.1.1.49152, as is Dick's when I talked to him on the phone this morning. Here's a link to download this version: http://www.robotc.net/downloads/fantom.dll

David:
Good analysis. A great piece of work.

I wish it were as easy as a simple out of date DLL. Unfottunately, I don't think this is the case and not my experience. The original NI + LEGO BT development team was re-assembled this past spring and were unable to resolve the BT issues. The BT problems have been confirmed to exist in both ROBOTC and NXT-G.

Part of the problem is that the issues are "soft" failures and it's not entirely clear what makes them go away. You may be on to something if re-installing Fantom is one way to clear them up.

Meanwhile I'm re-installing NXT-G 2.0 (which will include Fantom.dll) just to see if it will prevent me from getting this problem.

I just re-installed LEGO Education NXT 2.0 from CD. The version of Fantom.dll that it installed is
Fantom.dll
File Version: 1.1.1.49152
Product Version 1.1.1.49152

This is the same version that was on my computer where I have experienced BT issues before.

Just to add one more data point since David mentioned his laptop being DELL D410. I know there may be some issues with the USB Selective Suspend on that particular model. USB Selective Suspend is about putting a USB device in low power state when it is idling. In this case, it would be the USB Bluetooth device. I don't know if this is related at all but if you go to Windows Device Manager and open the properties of your Bluetooth device, click the Power Management tab and uncheck the "Allowing the system to put this device in low power state" (this is from my memory so it may not be the exact wording here), reboot windows and try to reproduce this issue again. If it doesn't reproduce any more, you have a Selective Suspend issue. If not, pardon my randomization.

Thanks for the suggestion on Power Management.

I didn't find a "Power Management" tab on the Properties for Bluetooth Radio nor Enumerator in Device Manager, so I'm not sure if what I'm going to say is relevant, but here goes.

I put back on the .dll's that came with RobotC 2.0.

I found a Power Management tab on "USB Root Hub", so I unchecked the box for
"Allow the computer to turn off this device to save power". (on all 5 instances)

Rebooted.

But still can't reconnect BT without manually Removing the NXT from the Bluetooth Control Panel and Reset-ing the Bluetooth on the NXT.

Put the DLL's from NXT back on, and it is fine again.


fwiw, (this next bit is especially unscientific) when I was running the D410 from batteries, I was unsuccessful making a bluetooth connection, even using my special magic dance and shaking of chicken.