Dexter NXTBee (NXC)

[HaWe]

yes I see, the delays of waiting in each cycle might become a problem in larger nets. Indeed I was surprised about the partially low data transfer rates - I had expected a much higher performance.
Acknowledging data would be optional in my model, not all data traffic will need it (e.g., heart beat signals, and all low-priority, non-time-sensitive data which can be sent redundantly once or twice every second).

So as you know it's actually not me who will program the net OS for NXC...

But the idea is, if now John now finnaly takes the efforts to set up such a net OS, it should be designed to fit also to future requirements, not to have a system that goes well with 1 master and 3 slaves but runs into severe limitations if one tries to use it for 1 or 2 dozens.

Why I attach great importance to "peer-to-peer" communication without a master?
It's about a hierarchical structure, e.g., for a swarm, all members communicating with each other ("broadcasting"), and each individual having 2 or 3 NXTs also communicating with each other ("intercom") for local sensor and motor multiplexing.

As I don't know anything about rs485 commands I can't help programming the net OS code, but I surely can check and test intermediate code, help to debug it, and possibly try to find improvements.

[mightor]

Better simply ignore my posts in future and move on.
If you don't need any enhancements, simply keep quiet.

Better yet, you can chose to ignore his replies. Like Matt said, this is a public forum. If you want a private audience with John, I suggest you use email.

- Xander

[afanofosc]

I will echo Xander's comment. Everyone is allowed to post in any thread. Nobody truly "owns" a thread. Matt has legitimate concerns about messing around with low level RS485 stuff in the firmware. If you don't like what he has to say please just ignore it and definitely try to refrain from complaining about what other people write, if at all possible.

John Hansen

[HaWe]

who is talking about low level stuff? Why should that be affected in any way?
It's just about a high level net operating system, I didn't ever mean to change existing low level stuff!

@Andy and @John:
I don't argue against sort of net server functionality of 1 of the NXTs: to provide a member list, monitor heart beats, keep the net round robin alive.
But this net "server" should not interfere to message traffic like a "master" does to keep the traffic as small as possible and as direct as possible (but correct me if I'm wrong).

Anyway, if Andy's performance/speed check results truly can not be substantially improved I actually doubt that really large nets still achieve real time behavior as I assumed.
(I expected that rs485 might be 100x as fast as Bluetooth, something like the USB to PC speed: >100 kB/sec. Then for about 1-2 ms time slice (time for sending in the token ring each) and over all 20 NXTs there could have been 20-50 sending cycles each second. Now this is looking quite different, speed now is really a big issue. )

[gloomyandy]

Hi Doc,
The results I published are not that unexpected. In that test the RS485 bus was running at the Lego standard of 921600 bps (bits per second). Which given the use of stop and start bits gives a maximum data rate of 92160 Bps (bytes per second) or approx 92KB/s which means that getting to the USB speed of 100KB/s is not possible, also USB transfers are only 10-20 times faster the Bluetooth not 100. In my test the obtained 26KB/s is just over a quarter of the available maximum. This is not that unusual when using simple send/ack protocols like that used by BitBus. I'm sure this can be improved (I did not spend much time trying to optimize data throughput) but given the amount of buffer space available I doubt if you will get much above 50KB/s or so without using faster base baud rates (which again is possible, but I've not tried it).

What sort of data rates do you need for the applications you are thinking of writing? It may be worth trying to come up with some sort of estimate to check that any sort of RS485 network will meet your needs...

Andy

[HaWe]

yes, I probably simply confused kbps (bit) by kBps (Byte).
I have no idea how it will work, I guess John has some ideas of doing this network thing by firmware extensions.
(I personally would prefer to have an header file to be included for this network extension.)
Speed in this case results from mechanisms against data collision and/or corruption: If any NXT may send, a TR is slow, but safe. If 20 NXT may send at any time to any member, then other anti-data-collision/corruption mechanisms are probably more difficult to establish but maybe we might have overall a faster data traffic.
I'll wait and see...

[tcwan]

yes, I probably simply confused kbps (bit) by kBps (Byte).

Speed in this case results from mechanisms against data collision and/or corruption: If any NXT may send, a TR is slow, but safe. If 20 NXT may send at any time to any member, then other anti-data-collision/corruption mechanisms are probably more difficult to establish but maybe we might have overall a faster data traffic.
I'll wait and see...

I really shouldn't jump into the middle of a heated discussion, but I'd like to point out that there is a cost to the 'safety' of Token Rings. Tokens can and do get lost, typically when something happens to a node that is holding the token. Hence the protocol has to deal with token loss and recovery, which adds a lot of complexity and code to the protocol. To reuse a common phrase: Fast, Simple, Reliable: choose any two.

I guess for most people, simplicity triumphed over performance, that is why Ethernet is pretty much the only LAN technology in use, and Token Ring/Bus is now a footnote of history (other than in specialized industrial settings).

Nonetheless, in the field of Wireless Sensor Network MAC Protocols, there are more protocols invented than there are letters of the English alphabet. You can
Google "wsn mac survey" to get some quick links. The main division is between TDMA-like (minimum or no collision) vs. Contention (collision-based) protocols.

[HaWe]

Tokens can and do get lost, typically when something happens to a node that is holding the token. Hence the protocol has to deal with token loss and recovery, which adds a lot of complexity and code to the protocol.

+1
I fully agree, that's just exactly what I already wrote some posts above: https://sourceforge.net/apps/phpbb/mind ... =10#p14740

I don't claim that the TR is the solution for all problems, but it was 1 simple approach that could work safely and reliably with only small programming efforts, so it was just a simple proposal, and it might probably be done without any firmware changes.

But I'm sure that for a larger net (1 or 2 dozens of NXTs where any member must be able to send commands and requests to any other member) you won't ever get a safe communication without any a network protocol. This question arose in John's post above https://sourceforge.net/apps/phpbb/mind ... =20#p14741 and the following replies.

The question is not, how many ways or net protocols may exist and could possibly be implemented, but: which one now will be actually finally implemented.

[HaWe]

John,
is this network project still in progress or did you meanwhile abandon it?

[HaWe]

so is it quite doubtful that it will be possible to get such a network for NXTbee and rs485? Then the Dexter NXTbee sensors make no sense for me.