Bluetooth sniffer

[mcsummation]

Does anyone have any information about how I can "sniff" (from my PC) the Bluetooth data flowing between my 2 NXTs?

I have an Ethernet sniffer (Ethereal) installed which I have used to debug Ethernet problems. This time, I want to be able to look at the Bluetooth data flowing between my 2 NXTs, so I can tell if data is being dropped before it has a chance to leave the sending NXT. It must run on a Windows XP Pro SP3 system with a Cambridge Radio USB adapter. There are lots of hits on Google for this, but they are either old or from untrusted sources. One requires a separate hardware analyzer which costs many thousands of dollars.

[mattallen37]

I have never heard of such a thing. If you want the NXT data (serial streams), I would try accessing it by opening the NXT and connecting the RX and TX lines to a couple RX lines of a serial (UART) port (TTL most likely).

[mcsummation]

I didn't really want to go that far. Since the data is obviously flowing through the aether, my USB dongle should be seeing it. I just want to snatch it out of the air and let me look at it. If packets are being lost between my SendRemote... BT call and it showing up at a ReceiveRemote... on the other end, which end of the stream is loosing them. The only way I know is for a 3rd party to see what actually flowed between the 2 machines.

Or, is there a way to get the packet count out of the low levels of the stuff running in the NXT? (I hesitate to say FW or any other term that might prejudice the answer.)

[mattallen37]

I'm sure programming at the FW level would allow you to access the BT UART port, but I'm fairly certain you can't access the RAW buffers directly with "standard" FW. The closest to that would be to use the BT functions (which is what you are trying to debug).

[mcsummation]

I should have told you the explicit "want". I'm running BT stress tests between 2 NXTs. I have 3 threads running in the master, one doing several sends through several mailboxes, followed by a poll/response. One of the mailboxes is sending sequential long numbers. That one never looses any any packets. I have 2 other threads each running as hard as they can, each sending sequential longs through their own mailboxes. On the slave side, I have the 3 long receiving mailboxes monitoring for lost packets (missing numbers in the sequence). The slave is running a single thread receiving the BT data. The 2 mailboxes for the "running as hard as they can" looses packets occasionally. So, the question is: are the packets being lost on the master side or the slave side? I suspect it is on the slave side because the thread can't process all the other data and get back to the "long" mailboxes soon enough. But, I would like proof. (I don't suspect the master side because the SendRemoteNumber calls never get a non-zero return on the call.)

I know my tests violate the things John has been saying about "send all the data from a single task". I'm trying to see just how bad it is when you violate what he has recommended. These are stress tests, not "production" code. My "production" code is working like a charm following his guidelines.

[linusa]

There's at least a way to sniff Bluetooth data being sent to/from your PC. Using software tools called "serial port splitter" or "serial port multiplexer", you can get virtual COM-ports with echo or join data. I've been using this successfully with a variety of Bluetooth-Adapters. If you hook up a terminal or similar program (I've testet a variety, Putty works well) to that serial port, you can sniff / debug / manually send data.

Unfortunately, I can't remember which exact serial port splitter software I've been using, but I do know I didn't pay for it (so it was free- or shareware or a demo version). It was something like this: http://www.fabulatech.com/serial-port-splitter.html . I'll find out.

Now my idea: Can't you use a combination of port splitting and port joining for your sniffer? You'd create an INCOMING serial port and split that to a debug output and a "real output". You'd then go ahead and let your master NXT manually connect to the INCOMIGN serial port on your computer (it's possible, I've done it and tested it before). Then you need your Bluetooth software to connect to the slave NXT with the OUTPUT port. This part is very common for all software that uses direct commands.

If the forwarding on your PC between incoming and outgoing serial ports works correctly (it should, I can vaguely remember I tried something similar), you should be able to see anything on your debug serial port that's send forth between the two NXTs.

[linusa]

Another thing, more on the point of what you actually want to do (I've always been a big fan of NXT performance and stress tests, especially for Bluetooth performance):

- Can you just protect all the Bluetooth operations from different tasks with a single "BT-access-mutex" to see if the packet loss goes away? I know this mutex will kill performance, BUT: If the firmware does these Bluetooth calls "async" and processes them internally with its own modules etc., then the mutex won't be acquired for too long during your sends...

- I've been experimenting with "data-logging to memory" before. Can't you just put a unique message number, the mailbox number, and a timestamp (CurrentTick()) in a log-queue /array inside memory? And then inspect these data later? A short example how to data-log to memory (big word, it's just filling an array -- I'm sure you could've done this on your own) is here: http://www.mindstorms.rwth-aachen.de/tr ... ataLogging

- If I remember correctly, each mailbox has its own message-queue, and it's very short. So you could do some sort of "mailbox round-robin" to keep the mailboxes from overflowing.

- You said your production code is running smoothly. How did you solve it? Do you have one "bluetooth task" which handles all BT stuff, and other tasks just defer their data sending to this task via some protected channel (vars/structs/flags with mutexes or some sort of queue)?

- You probably know the groundbreaking analysis of the NXT bluetooth protocol by Silvan Toledo? http://www.tau.ac.il/~stoledo/lego/btperformance.html

[mcsummation]

Welllll, that introduces a delay in the packet transit time between the 2 NXTs. I'm already running pretty tight timings in the NXTs. I'm not sure I would believe the answers I got.

That's an interesting idea, though. I need to pursue that for the "normal" debugging cases.

[linusa]

Yep, the additional Bluetooth latency will be horrible -- NXT-to-NXT messages are not exactly fast anyway.

Have you thought about the simple way of debugging this with acousting tones? You could beep on every lost message, or beep on every sent/received message, maybe with a different frequency for each mailbox?

Anyway, or the other things I said above minutes before you posted your reply

[mcsummation]

I know I'm losing messages because the slave has detected that it has missed a number. Remember that the master is sending sequential numbers through the mailbox. The question I'm trying to answer is: Are the messages being lost in the master or slave? If I could see the actual Bluetooth messages as they flow through the air, I would know fore sure.

John has explained about the queue in the slave. It's 5 entries long. So, if the master is stuffing messages at the slave faster than the slave can process them, eventually the slave will loose a message. What I'm wondering is - can the master loose messages somewhere in the path between my SendRemoteNumber call and the actual radio? I think the answer is "no", but I would like to confirm that.