Setting up DI Wifi Sensor --Problems

[afanofosc]

Sadly, that doesn't help me since sending the echo off one byte at a time, following each byte send by an attempt to read any response, is exactly what my code does. And Mark Crosbie's NXC code apparently works fairly well with the DIWIFI he has and it does not send the bytes one at a time once he has the echo turned off.

Either I have changed the enhanced firmware in some critical way more recently than the firmware Mark Crosbie was using and that you are using or the hardware that you and Mark have in your possession is in some important way different from the hardware I have and possibly the hardware that Matt Richardson has. Could you try your NXT-G block with the very, very latest NBC/NXC firmware (see http://bricxcc.sourceforge.net/test_releases/). I've tried the latest firmware as well as much older firmwares and in neither case do I get any response from the DIWIFI device that I have.

Earlier today I heard that my diwifi library routines have been tested on an NXT running the very latest NBC/NXC firmware talking to a PC running HyperTerminal and the code worked flawlessly at several different baud rates from 2400 to 57600.

John Hansen

[mattallen37]

Okay, interesting. I guess I didn't know you could send serial commands one byte at a time like that. I wouldn't think the device would like all those individual byte messages. Did you try byte-by-byte for just turning off the echo, and then using full strings? If so, what were the results?

So it sounds as though the WIFI module doesn't start echoing until it has received a complete byte, which is good in this application.

I can hardly wait to get back to an NXT and my DIWIFI.

[markcrosbie]

Hi guys,

Wow everyone has been really busy looking into this issue! I'll take John's code and test it out, and share some more of my code. I wonder if it will still work!

It is bizarre that my code and device worked, but that no-one can get their's to work. I did see that happen and had to do the RobotC reset to make the device talk to the NXT. I'll have to dig through my notebook as I had some very bizarre incantations that seemed to make it work. My biggest problem was once it was up and running a web server it would drop serial characters constantly making parsing the HTTP request a hit-of-miss affair. I ended up writing a lot of code to deal with lost content.

As a note; I found that the DiWifi is very sensitive to a weak battery. For example, after about 2 hours of constant work the 9V cell I was using had dropped voltage so that the WPAPSK key computation failed and I got a "Soft reset" error message from the wifi chip. The sensor started to behave very erratically after that. So I hacked a wall-wart transformer to power the 9V line on the board so that I could keep working. So if you are seeing strange behaviour try putting a fresh 9V cell in the sensor.

I'll report back later on once I try John's code...

All the best,
Mark

[mattallen37]

That's interesting, because DI said it can be powered with USB (5v). Maybe it's such a current hog, that the "9v" battery is dipping below 5v.

[jdc2106]

If you're having trouble with batteries and the wifi sensor, we've posted a quick hack on how to power the sensor while programming it. Indeed, wifi can require some power. If you're running out of batteries or experiencing the problems Mark has mentioned, you can try this:

http://dexterindustries.com/blog/2011/12/27/wifi-power/

[jdc2106]

Hello Folks,

I really appreciate everyone pitching in on their opinions here. I think I have the start of a solution.

I just ran the below code and get a consistent "OK" response from the Wifi sesor. I am using a DI Wifi sensor, that has been factory-reset and should resemble what comes out of the box. For NXC, I am using the latest firmware, and I am using Bricx Command center Version 3.3 (Build 3.3.8.10). I've commented the code out to try to help explain what we're doing here.

A word of caution: this should only be used to turn the echo off (the first of a few house-keeping setup tasks that need to be done to start up the wifi sensor). I worked hard pauses in here that give the sensor enough time to spit back an echo (the default is a serial echo, meaning if you send an "a" it returns that "a" back to you). After turning the echo off, you can send commands at a much more rapid pace.

Code: Select all

#define USE_RS485READ_EX 0

byte __HSBuffer[];

char nxtReadRawHS(byte & data[], byte count) {
  char result;

  // read up to count bytes from HiSpeed port
  byte p1[0], p2[0];
  // are there bytes already in our intermediate buffer?
  int len = ArrayLen(__HSBuffer);
  if (len <= count) {
    // empty out the intermediate buffer into a temp buffer
    p1 = __HSBuffer; // part one is everything from intermediate buffer
    count -= len; // reduce count by bytes already copied
    ArrayInit(__HSBuffer, 0, 0); // make sure it is empty
    // get more data from port
    result = RS485Read(__HSBuffer);
  }
  // are there more bytes to get?
  if (count > 0) {
    // copy from intermediate buffer (which may still be empty)
    ArraySubset(p2, __HSBuffer, 0, count);
    // resize the intermediate buffer
    byte tmp[];
    ArraySubset(tmp, __HSBuffer, count, NA); // returns empty if count > array length
    __HSBuffer = tmp;
    ArrayInit(tmp, 0, 0);
  }
  // now build data from p1 and p2 (one or both of which could be empty
  ArrayBuild(data, p1, p2);
  ArrayInit(p1, 0, 0);
  ArrayInit(p2, 0, 0);
//#endif
  return result;
}

void writeRawHS(string msg, bool eatEcho = false) {
  byte buf[];
  msg += "\r";                                    // Add a carriage return

  StrToByteArray(msg, buf);
    msg = "";
    for (int i=0; i < ArrayLen(buf); i++) {       // Send the string out, byte by byte.
      byte tbuf[];                                // Pick one byte.
      ArraySubset(tbuf, buf, i, 1);               // Isolate one byte from the array of bytes.
      RS485Write(tbuf);                           // Fire in the hole!  Send one byte on RS485 line.
      nxtReadRawHS(tbuf, 8);                      // Read the buffer, clear the echo out.
      Wait(100);                                  // Hard pause.  Don't mess with this!!  you need This when the echo is on!
      string tmp;                                 // Confusing leftovers I don't want to mess with.
      tmp = ByteArrayToStr(tbuf);                 // Confusing leftovers I don't want to mess with.
      msg += tmp;                                 // Confusing leftovers I don't want to mess with.
    }
    string message_out = msg;

  TextOut(0, LCD_LINE7, "Message Sent.");         // Tell everyone.
  ArrayInit(buf, 0, 0);                           // Healthy memory.
  Wait(100);                                      // Bask in the glory.
}

byte BytesRead[1];

////////////////////////////////////////////////////////////////////////////////////////////////////////
//      Clear Read Buffer
//      Run this to clear out the reading buffer.
//      Simply sends a carriage return, then clears the buffer out.  Necessary not to combine errors
//      and avoid collisions.
////////////////////////////////////////////////////////////////////////////////////////////////////////
void ClearReadBuffer()
{
  writeRawHS(""); // Send an invalid command
  string msg = "";
  while (RS485DataAvailable() > 0) {
    nxtReadRawHS(BytesRead, 1);                // Read the response.  Probably an error.
    string tmp;
    tmp = ByteArrayToStr(BytesRead);
    msg += tmp;
  }
  PlayTone(500, 100);                          // Victory beep.
  Wait(SEC_1);                                 // Bask in the aural glory.
}

void ReadWifi()
{
    string buffer;                             // This code was copied from NXTBee Code
    // wait for a message to arrive.
    until(RS485DataAvailable());
    RS485Read(buffer);
    // display message
    TextOut(0, LCD_LINE4, "Buffer Reads:");    // Tell them what you know in string format.
    TextOut(0, LCD_LINE5, buffer);             // And here's what we know.
    Wait(SEC_5);                               // Bask in your glory.
}

// 4.1.2 Echo
void SetEcho()
{
  TextOut(0, LCD_LINE1, "Turn Echo Off.");     // Tell them what we're going to do.
  Wait(SEC_2);                                 // Bask in the anticipation.
  writeRawHS("ate0", true);                    // Send the command, byte by byte.
  TextOut(0, LCD_LINE2, "Bytes Available:");   // Wait for it.
  NumOut(0, LCD_LINE3, RS485DataAvailable());  // Tell the good folks how many bytes are in the RS485 buffer.
  Wait(5000);                                  // Bask in the glory.
  ReadWifi();                                  // Read the buffer.
}

void setupHighSpeedLink()
{
  UseRS485();
  Wait(MS_10);
  SetHSDataMode(DATA_MODE_RAW);
  // SetHSDataMode(DATA_MODE_NXT);
  RS485Enable();
  Wait(MS_10);
  RS485Uart(HS_BAUD_9600, HS_MODE_DEFAULT);
  Wait(MS_10);
}

bool bTestDone = false;

task main()
{
  setupHighSpeedLink();   // Turns on RS485 Functionality
  ClearReadBuffer();      // Clear out the buffer and test TX/RX.
  ClearScreen();          // Housekeeping
  SetEcho();              // This will turn the echo off.  First housekeeping task
                          // when starting up the NXT
}

[markcrosbie]

My non-functional NXC code is attached. I think it is written "correctly" and should work but it does not. Mark, could you try working with my code to see if it works with your device? I should say, actually, that my diwifi.h file is not 100% complete and "correct". I haven't finished hooking up the functions that return a string type so that the code would work correctly, if I ever code convince the DIWIFI to say anything. Basically where I return msg these functions should instead return Receive(true);

John Hansen

Hi John (and everyone),

I tried your code out John but don't know for sure if it is working I see a new device appear on my wifi network with an assigned IP address, so I assume that it worked. I had to modify it to use WPA security and not WEP as you originally wrote it. I also changed the baud to 115200 as that is what my sensor is working at.

The screen of my NXT looks like the attached screenshot.

Does this indicate a working device?

Regards,
Mark

[afanofosc]

Mark,

That looks great. I wish my device would show something other than zeros at the bottom. Can you do me another favor and try changing the #define at the start of the diwifi.h header file from 0 to 1? This will test my new RS485ReadEx function that you prodded me into adding to the enhanced NBC/NXC firmware. It lets you specify the number of bytes to read instead of reading the whole buffer like RS485Read does. If in your case it is set to 1 already then can you try it with 0 - to see if my alternate version written in NXC also works. One more thing I would like to confirm is which enhanced firmware filename did you download and install on your NXT? I'd like to verify if there are any changes in behavior between the early July test release and the late October test release (both in http://bricxcc.sourceforge.net/test_releases/).

It seems more and more likely that my device is just plain broken. That's entirely possible since I think it was a very early version of the device and may have hardware problems - or I could have broken it somehow since I got it.

John Hansen

[markcrosbie]

Mark,

That looks great. I wish my device would show something other than zeros at the bottom. Can you do me another favor and try changing the #define at the start of the diwifi.h header file from 0 to 1? This will test my new RS485ReadEx function that you prodded me into adding to the enhanced NBC/NXC firmware. It lets you specify the number of bytes to read instead of reading the whole buffer like RS485Read does. If in your case it is set to 1 already then can you try it with 0 - to see if my alternate version written in NXC also works. One more thing I would like to confirm is which enhanced firmware filename did you download and install on your NXT? I'd like to verify if there are any changes in behavior between the early July test release and the late October test release (both in http://bricxcc.sourceforge.net/test_releases/).

John Hansen

Hi John,

I could not get the code to compile with the call to the RS485ReadEx function in it - my 1.2.1r5 Mac OS X NXC compiler chokes on that. I had to comment out the #define USE_RS485READ_EX line at the top of diwifi.h. If I left that in the source code, regardless of whether it is set to 0 or 1, I get the following error:

Code: Select all

# Error: Undefined Identifier RS485ReadEx
File "diwifi.h" ; line 9
#    result = RS485ReadEx(

Note that the line-numbers are off by one in any error message generated by the NXC compiler on the Mac. No idea why that is but it's been that way for over a year.

Here's my NXC version:

Code: Select all

Next Byte Codes Compiler version 1.2 (1.2.1.r5, built Sun Jul 24 04:30:44 CDT 2011)
     Copyright (c) 2006-2011, John Hansen
Use "nbc -help" for more information.

I downloaded the lms_arm_nbcnxc_131_20110708_2348.rfw firmware into my NXT to test this. Is a different version you would prefer I use - let me know and I'll test it out.

Note that my DiWifi sensor was working before I tested your code. It was set to 115200 baud by my RobotC program.

Regards,
Mark

[markcrosbie]

I just ran the below code and get a consistent "OK" response from the Wifi sesor. I am using a DI Wifi sensor, that has been factory-reset and should resemble what comes out of the box. For NXC, I am using the latest firmware, and I am using Bricx Command center Version 3.3 (Build 3.3.8.10). I've commented the code out to try to help explain what we're doing here.

Hi John,

I compiled and ran this using the v1.2.1r5 NXC compiler on Mac OS and it does return OK. I've attached a screenshot I took in png format. If it doesn't open then just append a .png to the end of the filename.

Regards,
Mark