Dexter Industries NXTBees & NXC

Discussion specific to the intelligent brick, sensors, motors, and more.
Post Reply
sparramc
Posts: 83
Joined: 29 Sep 2010, 08:44
Location: Launceston, Tasmania, Australia
Contact:

Dexter Industries NXTBees & NXC

Post by sparramc »

Hi,

I have a pair of Dexter NXTBees and am having a few software issues in regards to using NXC with them.

Image

After a lot of Protocol relate issues between NXTBees & the NXT initially which was followed by a lot of brainstorming with Xaander and Dexter Industries. That issue has now been sorted.

I there a reason why data exchange between the two Dexter NXTBees, will only work in RS485 Raw Mode? This makes for cumbersome programming.

Dear 'John Hansen', is it possible to have the RS485 Communications mimic that of the Bluetooth Mailbox Protocol?

I've found the NXTBees to be very frustrating too this point in time. They show great promise, but the programming needed to use them successfully is giving me a major headache.

Has anyone else managed to master the NXTBee communications between a pair of NXTs with NBC/NXC or any other language?
regards

Ray McNamara

www.rjmcnamara.com

'The Universe Consists of 1% Hydrogen, & the Rest is Ignorance!'
afanofosc
Site Admin
Posts: 1256
Joined: 26 Sep 2010, 19:36
Location: Nashville, TN
Contact:

Re: Dexter Industries NXTBees & NXC

Post by afanofosc »

It would be a whole lot easier to understand your concerns if you showed your code. Writing data to the RS485 port and reading data from it is extremely easy to do if you are using the enhanced NBC/NXC firmware.

I can't comment on what does or does not work with the NXTBees when you try to use one of the enhanced firmware's new features for automatically handling RS485 data like the firmware handles inbound data on its USB and Bluetooth channels. I can't think of any reason off hand why it would not work since in the end it's just a bunch of bytes sent out port 4 or received from port 4. If you showed me what you have tried I might be able to find something you are doing wrong or find and fix a bug in the enhanced firmware.

Since the NXT's mailbox system stinks badly I don't plan on building anything like that on top of RS485 in the enhanced firmware.

John Hansen
Multi-platform LEGO MINDSTORMS programming
http://bricxcc.sourceforge.net/
sparramc
Posts: 83
Joined: 29 Sep 2010, 08:44
Location: Launceston, Tasmania, Australia
Contact:

Re: Dexter Industries NXTBees & NXC

Post by sparramc »

Thanx for your prompt reply John.

The Bluetooth protocol was only a suggestion, I admit I've only used with the standard NXT remote control scenario. When I've needed an extra NXT previously for a project I've used RS485 Direct connection in Raw Mode, as I note that in the ex_RS485Send.nxc program in the (Latest Test Release) NXC Help File has these comments:

Code: Select all

    // the RS485 receiver sample program is not written 
    // in a way to handle these additional messages
    // so do not send them (yet)
But I would now prefer to use both SendRS485Bool(true/false); & SendRS485Number(i); I have also noted that the first Character of a received message is always missing. Send "Goofy and receive "oofy". I have previously got around this via appending an extra character to the front of the message.

My testing code is as follows:

RS-485 Transmitter program

Code: Select all

// RS-485 Transmitter program


inline void WaitForMessageToBeSent()
{
  // use hi level API functions (preferred)
  while (RS485SendingData())
    Wait(MS_1);
}

task main()
{
  // configure the S4 port as RS485
  UseRS485();

  // make sure the RS485 system is turned on
  // hi level API function call
  RS485Enable();

  // initialize the UART to default values
  // hi level API function call
  RS485Uart(HS_BAUD_9600, HS_MODE_DEFAULT); // use 9600 baud rather than default rate

  Wait(MS_10);
  int i;
  while (true) {
    int msg;
    msg = i;
    NumOut(0, LCD_LINE1, msg);
    SendRS485Number(msg);     // Send Number
    WaitForMessageToBeSent();
    i++;
    Wait(SEC_1);
  }
  // disable RS485 (not usually needed)
  RS485Disable();
}

RS-485 receiver program

Code: Select all

// RS-485 receiver program

task main()
{
  byte mlen;
  int buffer;
  // configure the S4 port as RS485
  UseRS485(); 
  // make sure the RS485 system is turned on
  RS485Enable(); 
  // initialize the UART to default values
  RS485Initialize(); 
  RS485Uart(HS_BAUD_9600, HS_MODE_DEFAULT); // use 9600 baud rather than default rate

  Wait(MS_10);
  while (true) {
    // wait for a message to arrive.
    until(RS485DataAvailable());
    RS485Read(buffer);
    // display message
    NumOut(0, LCD_LINE2, buffer);
    Wait(SEC_1);
  }
  // shut down the RS485 system
  RS485Disable();
  bool sendingData, dataAvail;
  // check RS485 status
  RS485Status(sendingData, dataAvail); 
  // turn the system back on (this is equivalent to RS485Enable)
  RS485Control(HS_CTRL_INIT, HS_BAUD_DEFAULT, HS_MODE_DEFAULT);
  // configure the UART (this is equivalent to RS485Initialize)
  RS485Uart(HS_BAUD_DEFAULT, HS_MODE_DEFAULT);
 
}
I'm putting together an ordering system where I want to send an order for different coloured balls between two NXTs. e.g.
  • 4x Red
    1x Magenta
    6x Yellow
    0x Aqua

I then need confirmation that the order is received as well as confirmation that the order was delivered, etc.
My programming Genius is also holding me back somewhat which doesn't always help! "Old Dogs: New Tricks!"
regards

Ray McNamara

www.rjmcnamara.com

'The Universe Consists of 1% Hydrogen, & the Rest is Ignorance!'
afanofosc
Site Admin
Posts: 1256
Joined: 26 Sep 2010, 19:36
Location: Nashville, TN
Contact:

Re: Dexter Industries NXTBees & NXC

Post by afanofosc »

I don't recall getting any reports about 1st character missing. That's not something to just work around. It definitely did not use to do that. My hunch is it started happening when I changed the firmware to interpret the first byte of RS485 data as an address of an NXT so that you could send messages to up to 8 separate NXTs and have only the addressed NXT actually handle the message. I think it may be that you upgraded to a new firmware but did not update to a new compiler. Or I have a defect in either the API functions or the firmware that I need to fix.

The comment in the sample program is just referring to the code in the sample receiving program not having code in place to read additional messages so I left those additional messages commented out in the sending program.

John Hansen
Multi-platform LEGO MINDSTORMS programming
http://bricxcc.sourceforge.net/
mattallen37
Posts: 1818
Joined: 02 Oct 2010, 02:19
Location: Michigan USA
Contact:

Re: Dexter Industries NXTBees & NXC

Post by mattallen37 »

My RS-485 programs and lib. are based on raw strings, please keep supporting it, or I will have to rewrite my code. I don't mind the idea of direct commands, and all this new jazz, but please do not drop the only part I use.
Matt
http://mattallen37.wordpress.com/

I'm all for gun control... that's why I use both hands when shooting ;)
sparramc
Posts: 83
Joined: 29 Sep 2010, 08:44
Location: Launceston, Tasmania, Australia
Contact:

Re: Dexter Industries NXTBees & NXC

Post by sparramc »

Thanx John,

I'll wait to hear more on your findings.
regards

Ray McNamara

www.rjmcnamara.com

'The Universe Consists of 1% Hydrogen, & the Rest is Ignorance!'
afanofosc_99
Posts: 15
Joined: 26 Sep 2010, 18:18

Re: Dexter Industries NXTBees & NXC

Post by afanofosc_99 »

mattallen37 wrote:My RS-485 programs and lib. are based on raw strings, please keep supporting it, or I will have to rewrite my code. I don't mind the idea of direct commands, and all this new jazz, but please do not drop the only part I use.
Other users may be having problems but are you having any trouble with the latest compiler and firmware combinations? I suspect not, having just reviewed the firmware source code and the NXC API function changes that I made recently.

As far as I can see, the changes I made to the firmware for addressable NXT messaging over RS485 only apply when you set the NXT into DATA_MODE_NXT for RS485. By default its data mode is RAW and the firmware code should work like it has always worked in this mode. You can look at the enhanced NBC/NXC firmware source code that I just uploaded to the mindboards SVN repository.

http://mindboards.svn.sourceforge.net/v ... rsion_131/

If you want to use raw RS485 messaging (as opposed to System and Direct commands via RS485) then don't change the RS485 data mode to DATA_MODE_NXT. Leave it in its default state of DATA_MODE_RAW.

If you want to have the firmware automatically handle system and direct commands with addressable recipients (up to 8 NXTs) via RS485 then switch to DATA_MODE_NXT and use the API functions that allow you to pass a connection number that is used as the NXT address for RS485 communication. If the receiving NXT is in DATA_MODE_NXT then it will support inbound messages containing a single byte address that is checked before processing the inbound data. If it is not the correct address the data is discarded. If it is the correct address then the remainder of the message is copied into the Comm module IOMap HiSpeed InBuf array. If you want to send the data via the raw mode RS485Write or the SendRS485String functions then you'll need to stick an address byte at the start of the outbound data buffer if your receiving NXTs are running with their data mode set to DATA_MODE_NXT. The SendRS485Bool and SendRS485Number functions aren't built to handle an address byte and aren't able to be used with receivers with a data mode of DATA_MODE_NXT unless you write your own versions of these API functions. I will probably work on API alternatives that would allow sending "raw" addressable data to NXTs running in the NXT data mode. For now, though, the existing raw functions are only supported for use with NXTs in raw data mode.

John Hansen
mattallen37
Posts: 1818
Joined: 02 Oct 2010, 02:19
Location: Michigan USA
Contact:

Re: Dexter Industries NXTBees & NXC

Post by mattallen37 »

I haven't been having issues, no, but I don't want them to start ;) Actually, I have had frustration with getting RS-485 to work, but then I realized I forgot to initialize at the beginning of the program :oops:

Wow, cool. I have wondered for a long time what some of the source code looked like... now I know :D Thanks for posting it!
Matt
http://mattallen37.wordpress.com/

I'm all for gun control... that's why I use both hands when shooting ;)
afanofosc
Site Admin
Posts: 1256
Joined: 26 Sep 2010, 19:36
Location: Nashville, TN
Contact:

Re: Dexter Industries NXTBees & NXC

Post by afanofosc »

sparramc wrote: I'll wait to hear more on your findings.
Based on the firmware source code I think you are using a program that is not what you posted. Can you post a pair of programs that demonstrate the problem with dropping the first byte of a message? Run these programs after powering on your NXT. Make sure you have the latest enhanced firmware installed in case an older version had a problem that no longer exists in the latest build.

As I mentioned in my previous response, you should not be sending raw RS485 messages (i.e., without an address byte) when you have your NXT running with its RS485 data mode set to DATA_MODE_NXT. Only use the Direct and System command API functions that take a connection number as the first parameter when your receiving NXT is running with its RS485 data mode set to DATA_MODE_NXT.

I still do not understand what any of this has to do with the NXTBee. The code you posted earlier doesn't seem to have anything to do with the NXTBee at all. Can you post code you have tried that gives you a major headache and that is very cumbersome? Also code that demonstrates that you can't use the NXTBees when the two NXTs have their RS485 data mode set to DATA_MODE_NXT? I don't see how that could be true.

John Hansen
Multi-platform LEGO MINDSTORMS programming
http://bricxcc.sourceforge.net/
Post Reply

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 2 guests