New MessageRead feature in the enhanced NBC/NXC firmware

[HaWe]

I have no badly design, I just have to use BT send/receive which is fail-safe for multitsking (e.g., putting messages automatically into waiting queues as long as BT is busy by another task.
There's no way to do it other way as you may see at my try to queue all up into 1 single send/receive task: in that case lot more messages get dropped than before.

It would be better if we had
a faster BT protocol with auto-remove from mailboxes to prevent queues from getting too long
a safer BT protocol to prevent messages from being dropped if lines are currently busy

faster + safer + auto-queuing + auto-remove => no problems

But I don't see through your code either,
as you see, I already have defined
OUTBOX_1 1
INBOX_11 2
INBOX_12 3
OUTBOX_2 4
INBOX_21 5
INBOX_22 6
OUTBOX_3 7
INBOX_31 8
INBOX_32 9
on the master, it has to stay as it is.
So I have to think about your renamed boxes anyway.

[afanofosc]

Doc, I will shortly prove that the problems you are experiencing are caused by your code and not by the bluetooth support in the NXT firmware. Or I will apologize for doubting you. Hopefully this weekend.

In any case, if you used MAILBOX2 instead of 1 or MAILBOX10 instead 9 then it would be obvious what you have to do. The outboxes you are using are only used when you call an API function that also takes a connection number (SendRemoteString, for example) so they need no modification. The inboxes you are using are where you retrieve a message from a remote NXT on your master device using something like ReceiveRemoteString. In this case, if you know that you only want to read from connection 1 for inbox 11 and inbox 12 then you would set these constants to be 2+0x40 (i.e., 0x42) and 3+0x40 (i.e., 0x43) on your master. On your slave you would not do anything to your mailbox constants. For inbox 21 and inbox 22 you would add 0x80 to your existing mailbox numbers (i.e., 5 and 6 would become 0x85 and 0x86). For inbox 31 and 32 you would add 0xC0 to your existing mailbox numbers (i.e., 8 and 9 would become 0xC8 and 0xC9).

If it is easier for you then you can define a function like this:

Code: Select all

char ReceiveRemoteStringEx(byte conn, byte queue, bool clear, string & msg)
{
  queue += (conn << 6);
  return ReceiveRemoteString(queue, clear, msg);
}

John Hansen

[HaWe]

thank you for your patience, but I don't understand these bit arithmetics. I can't imagine what happens or how it works. This is probably stuff for professional programmers, but not for me as a layman. I can understand only things I can see and observe in reality by my eyes, touch by my hands, and simulate on a sheet of paper, but sadly I cannot understand this abstract low level value shifting.
I was only using mailboxes so far because I didn't see any way to do it without, honestly I don't understand anything what's actually happening when I'm using this mailbox thing.

What I need (and probably also many other non-professional programmers) are simple, quick, and thread-safe BT connection commands, at best something like

Code: Select all

GetBTSensorValue(SlaveID, port, variant &value[])
SetBTSensorType(SlaveID, port, SensorType)

GetBTVariable(SlaveID,  variantName, variant &value[]))
SetBTVariable(SlaveID,  variantName, variant &value[]))

BTMotorOnFwd(SlaveID, port, pwr)
GetBTEncoderValue(SlaveID, port, &counter)

a.s.o.
if we had something like this we could abandon all weird mailbox stuff at all, just sending to/receiving from slaves by calling their IDs, quick and fail-safe.

Anything else is too complicated, I don't understand this low level BT commands any more than e.g. i2c low level commands, they will keep to be a book with seven seals. I think I will have to abandon all my approaches to a BT network like the one I needed for 3 slaves calculating and acting alltogether, there is no failsafe sourcecode I can copy and paste and use for my own purposes, and I fail with my own experiments.

So I'm also really sorry that I won't be able to help you testing this.

Thank you for your participation.

[mcsummation]

Let me see if I can help.

In the Master NXT, if you want to send a string to the Slave that is connected on connection 1 into its Mailbox 2, you could use the following code:

Code: Select all

until (RemoteConnectionIdle(1))  Yield();
SendRemoteString(1, 2, "Hello World");

where you must specify both the connection number and the mailbox number.

What John has done, is make the receive (on the Master) similar. You could use code like this (using his function above):

Code: Select all

string sReturnedString;
ReceiveRemoteStringEx(1, 2, true, sReturnedString);

You don't really need to be concerned with the bit shifting, just accept that it puts the connection number where John's underlying code expects it.

[HaWe]

but this is already what I am doing - or not?

Code: Select all

//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
task ReceiveSlaveData()    // NOS = Number of Slaves
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
{
   string slvmsg;
   int ack, ch;

   while(true)   {
     if (_NOS_>=1) {
       until(ReceiveRemoteString(INBOX_11, true, slvmsg) == NO_ERR);
       ParseBTResponseMsg(0, slvmsg) ;
       Wait(20);
     }

     if (_NOS_>=2) {
       until(ReceiveRemoteString(INBOX_21, true, slvmsg) == NO_ERR);
       ParseBTResponseMsg(1, slvmsg) ;
       Wait(20);
     }

     if (_NOS_==3) {
       until(ReceiveRemoteString(INBOX_31, true, slvmsg) == NO_ERR);
       ParseBTResponseMsg(2, slvmsg) ;
       Wait(20);
      }
      
      ack=0;
      if (_OUT_ != "") {
        ch=checksum(_OUT_);
        while(ack!=ch)  {
            do { Wait(1); } while (BluetoothStatus(_ID_) != NO_ERR);
            SendRemoteString(_ID_, _OUTBOX_, _OUT_);
            Wait(20);
            do { Wait(1); } while (BluetoothStatus(_ID_) != NO_ERR);
            ReceiveRemoteNumber(_INBOX_, true, ack);
            Wait(20);
        }
      }
      _OUT_="";

      Wait(20);
   }
}

[mcsummation]

Are you trying to get a response from all your NOS slaves? Or are you trying to get the response from a specific Slave? If "all", your code works. If only one, John's code works better.

[HaWe]

I have to get frequently and continuously 1 message from slave 1,
1 different msg from slave 2,
and another one from slave 3,
and I have to get them quickly (every 20ms),
and of course I have to know which message is from which slave,

and intermediately I have to send different messages from time to time by different threads (single ones or a whole bunch or series of them) to several slaves one after the other - which must not interfere with the received messages.

But I admit that I don't understand John's code and how I have to rewrite my code to use John's code instead.

Anyway, my approaches to queue up all sending and receiving messages into one thread failed completely across the board,
having independed receive-tasks and send-tasks over all worked much better.

[mcsummation]

I have to get frequently and continuously 1 message from slave 1,
1 different msg from slave 2,
and another one from slave 3,
and I have to get them quickly (every 20ms)

That may be part of the problem you are having. According to the "LEGO MINDSTORMS NXT Communication Protocol document, version 1.00, 2006, page 22", the Bluetooth radio requires approximately 30ms to switch between send and receive mode. One of those transitions is required for each ReceiveRemote call.

The current ReceiveRemote function polls each Slave until it gets a response, at 30ms each. This could cause a 90ms delay if Slave 3 is the only one with data. John's code lets you ask a specific Slave if it has data.

This above is the way I understand the BT protocol description and analysis documents that I have been reading lately. Many of my BT problems were caused by me trying to get data from the slave too fast.

[HaWe]

if we could access each single and any remote Sensor value and other remote variant values of any desired slave quickly, I wouldn't have to poll all slaves frequently and continuously one after the other to get all their values at once (and store them intermediatly in a master's array).
And if we could access all or any remote motors quickly and directly just as if they were local motors, there would be no interferences with frequently incoming messages.

That's why I wrote:
What we needed is a completely different BT messaging system instead of (or additional to) the current one which abandonds and drops all needs of mailboxes and gives a quick and threadsafe and failsafe remote access to all/any BT remote I/Os and any remote variants of interest (strings, long, float, large arrays of char or int or anything) which have to be sent to slaves or which have to be polled from slaves.

[mcsummation]

Does anyone know what protocol "Watch the brick" uses? You don't need any code running in the brick being watched.

Still, the 30ms between the "send the request" and the "get the answer" doesn't have anything to do with the mailbox system, that's a hardware restriction in the NXT Bluetooth implementation. You are simply trying to get data from the slave faster than the hardware can respond. The "watcher" system (whether a PC or another NXT) still has to poll the "watchee" at greater than a 30ms rate

Maybe you need to think about using another communication device, one that is faster and doesn't have the restrictions that the NXT Bluetooth has.