Dexter NXTBee (NXC)

[mattallen37]

I haven't spent a lot of time researching how the NXTBees work, but I assume it's something like wireless wires (perhaps with AT commands for setup).

As you should recall, I was working on an RS485 library for you. I don't know for sure, but it can probably be made to work with the NXTBees fairly easily.

If I get some NXTBees sometime, I plan to build a fairly extensive library for them in NXC (mimicking a few direct commands (for setting sensor type and controlling motors), and providing a user buffer). However, I don't have the HW yet to make it specifically for the NXTBees, and I'm much too busy ATM to program it anyhow.

[doc-helmut]

Matt,
I'm not sure if I understand that correctly ... the nxtbee lib is nothing else but a rs485 lib ?
The problem so far always was Multi-Tasking-safe communication, chksum error checking, avoiding message dropping, and unambiguous identification of messages coming in from different senders a/o threads.
Mark's data format appears to be quite suitable for this:

Simple data format

The data format used by both the RobotC and Java Processing libraries is the same. A small header of 5 bytes is placed in front of the data you want to send. The header contains the following fields:


For example, sending a byte value 123 from address 5 to address 7 would be encoded as:
4 1 XX 7 5 123 where XX is the checksum value.
Packed data format

The packed data format retains the 5 byte header used by the simple data format, but adds a two byte packing header in front of each value so that the recipient knows how many bytes to extra and what type the value is. For example, sending a byte of value 123, an integer of value 5 and a string “abc” would be encoded in packed format as:

6 12 xx 7 5 4 1 123 2 2 0 5 0 3 a b c

(On the other hand, also a msg ID would be useful:
if NXT1 requests 3 different integer values from NXT2 (send request), and now the 3 integer values are coming in (maybe first value 2, then value 3, then value 1), then the NXT1 may distinguish the 3 values by it's IDs.)

But now you mean, you probably will be able to make Mark Crosbie's nxtbee network lib (or a similar one) work also for rs485 wired connection, too?
And so, the lib will work both for wired and nxtbee-wireless connected NXT's?
Do I understand that correctly?

[mattallen37]

According to what you just posted, Mark's library structure looks similar to my RS485 library structure (although it is slightly different).

I don't think that an RS485 library (mine or anybody else's) could be used with the NXTBees directly. It would need to be adapted to follow any specific requirements of the XBee, and also need to support XBee communication (AT commands?).

[doc-helmut]

Matt,
do you think you could probably - without too much efforts - align your structure to Mark's (just for potential future cross compatibility)?

As I sacrificied my current projects for making them BT- or rs485- network compatible (BT too slow and too shaky, for rs485 then missing 1 sensor port at each NXT) I would start at a new zero point with basic rs485 network experiments (I have 3 own NXTs plus 1 borrowed from a friend).

Maybe we together can try to set up an experimental platform to start from ( of NXTs, sensors, and motors which we both have).
As this is no special nxtbee issue we may start a new thread for this new topic .

What do you think?

(ps, edit: the msg ID probably could be integrated into the msg type field)

[mattallen37]

It looks like I will be very busy for the next 1-3 weeks (maybe longer), working for my brother (away from the house for 10+ hours a day). Making my library compatible with Mark's would be a good idea, but it won't be happening soon.

[afanofosc]

Doc,

I have tidied up this thread and unlocked it at your request. Let's all just try to ignore posts we don't like and focus on helping other people get the most out of LEGO MINDSTORMS.

One thing to keep in mind with respect to RS485 communication is that the hardware is half-duplex and highly prone to data corruption as a result. I don't know if Dick Swan has done something amazingly clever in the RobotC firmware that works around this hardware design flaw or not but if he hasn't then RobotC will suffer from the exact same problems that NXC suffers from with respect to RS485 communication.

I have two NXTBee devices and I would be happy to work with you, Doc, outside these forums to develop the best possible NXC library for them. But, like Matt, I do not have a ton of spare time available so I will have to warn you in advance that patience will be required. You can email me via the address shown in the BricxCC about box.

John Hansen

[doc-helmut]

John,
thank you for your obligingness!
I would be happy to help you developing a communication protocol, but actually I also have only very little time (as I have to lead my business company).

I don't own nxtBees so far, so with nxtBees I can't help or do anything (as I wrote, I wanted to buy some, but only if such a NXC network & remote control protocol is already completely available - otherwise it's too risky to loose much money because it possibly might never work as expected ).

Because I also have much too little knowledge about rs485 I can't develop anything new, but I can test your code and then report you (just rs485, of course).
So if there is already something new with rs485 to test, I will gladly do this. But rs485 software is maybe another issue than nxtBee software (I can't oerlook what's similar or different).

You may mail me any code at any time via PM or my email account, I will then send you a mail back ASAP.

[doc-helmut]

found this about nxtBee:

The XBees; They are a step up from bluetooth on the NXT, but the reliability was disappointing. I first ran them out of the box, and was getting many data dropouts. Its one thing to deal with corrupt data, you can recover or worse case plot a bad value. But when you are expecting 5 bytes and get 4, not only does it mess up that data sample, but every data sample following it. I spent a week seeking answers to no avail. Finally I ran across an article that discussed broadcast versus direct addressing, and how broadcast often dropped data. This is the default configuration :( So, I then changed to direct addressing and the communications were a lot better. Better, but not error free, the problem remained, drop a byte, !@%&#%. Eventually I did write the code to recover. As a software guy this is something I have never had to do in 35+ years of programming. There has always been a layer provided for me that dealt with it. It’s a shame that programmers have to deal with stuff in the 21st century. </soapbox>

http://www.spiked3.com/?p=473

I think, 1 more good reason why to establish a TOKEN RING network using acknowledge bytes and checksums transfered by any message in header of several bytes.
Also the TOKEN would be nothing more than a special flag within 1 byte of this universal header.
my favorite header model so far is the following :

Code: Select all

0 msg_type (0 byte, 1 int, 2 long, 3 float, 4 data string, 5 direct command string, 6 (vacant), 7 TOKEN)
1 byte_count
2 checksum (low byte of weighted sum = [sub][size=85]index[/size][/sub][size=200]Σ[/size] byte_value * index)
3 dest_addr
4 src_addr
5 var_ID (to distinguish similar requested variables by their IDs)
6 priority (priority 0x0...0xF)
7 request (request for confirmation by checksum: 0x01; request for a special data value to be sent back: 0x10)

[gloomyandy]

Doc/Folks. There are a number of protocols already out there that are reasonably well documented, and there are international standards for some very good error detection schemes, that you may find of interest. The error detection schemes in particular tend to provide a much higher chance of error detection than simple checksums. in leJOS for RS485 we make use of the BitBus protocol:
http://www.bitbus.org/
For error detection we make use of CRC-16-CITT:
http://en.wikipedia.org/wiki/Cyclic_redundancy_check
http://www.nongnu.org/avr-libc/user-man ... __crc.html
http://www.ross.net/crc/download/crc_v3.txt

[doc-helmut]

thx for the advice, but checksum or better alternatives for error detection are not the point in the moment and I don't understand anything about bitbus and so on...
The main problems are data corruption, dropping messages, message crashing, mailbox overflow, timing issues, multi-tasking-safety.
Maybe bitbus is sort of network protocol?

the point is:
you might have maybe 20 NXTs in your network and everyone has to send and to receive and there are urgent requests and direct commands and many messages of major or minor significance cross over from any to any.
And the connection is only half-duplex.
So the problem first of all is to prevent messages from crashing (2 NXTs must not send at the same time never!) and to canalize the msg traffic in a way that only 1 NXT can send at 1 time and all the others have to listen. Then the next NXT in line is to send.

So my approach first of all would be to establish a token ring network.
For the TR many problems may occur, e.g., what if the NXT which should get the token next is suddenly offline (low batteries, loose connection)? (my suggest: heart beat signals as signs of life, and time-outs to pass the token to the next after the next).
How can a NXT know which is the next in line, and the next after the next (and the next after this one)? (my suggest a member list of all members - but static or dynamic...?)
What if one NXT is addressed to send a value or an acknowlege message but he doesn't reply - how often should the request be sent, when should the traffic be cancelled?
What about urgent messages or commands - should there be established sort of "Red Telephone Line" for quick request-response-messages with tokens sent back and forth regardless of other members of the ring?
What if - let's say - NXT No.20 gets lots of requests and data messages of all 19 other NXTs in the ring, maybe over all 4 dozens - how to prevent his inbox from overflow? Remember, he can't reply while he hasn't got the token (my suggest: a big 2nd-level FIFO-inbox buffer, an inbox thread quickly clearing the inboxes, and a big outbox-FIFO-stack to gather the outgoing messages until it's his turn).
What if 1 NXT is online again if he was offline at times? How can he join the runnning queue again (e.g., if he got new batteries)?
What if the NXT which got the token suddenly hangs up so that he can't pass the token to any other any more? Who will fill in for him?
What if a new NXT No.21 wants to join the ring which had not been integrated before? Can the ring be dynamically enlarged?

So this is the footing of all message traffic: a network operation system. If it works for 20, it will also work for 3 or 32, and it will work both for rs485 and for nxtBee (and maybe partly also for BT).

If that once works fine we can talk about how the messages can be addressed safely and detected and interpreted reliably and about better error detection algorithms.
But I think for this purpose the 8-byte-message-header described above could be a very good start.