Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Wifly rn-xv + XBee shield


  • Please log in to reply
28 replies to this topic

#21 fritzE

fritzE

    Member

  • Members
  • PipPip
  • 11 posts

Posted 23 June 2012 - 01:19 AM

Though I feel like I'm masking symptoms, this seems to correct that particular problem:

private void _SerialPort_LineReceived(string Text)
        {
            _DebugPrint('I', Text + "\r\n");

            

            // Did we enter command mode?
            if (Text == "CMD" && this._Mode == Modes.Idle)
            {
                this._Mode = Modes.CommandMode;
                _DebugPrint('D', "Successfully enterred the command mode");
                return;
            }
            else
            {
                if (Text.IndexOf("CMD") >= 0)
                {
                    Debug.Print("FOUND CMD IN STRING: " + Text);
                    this._Mode = Modes.CommandMode;
                    _DebugPrint('D', "Pretending to Successfully enterred the command mode");
                    return;
                }
            }

There are couple other issues... I'll post when i have more to say about..
thx

Hi.
2 issues, first it appeared there was a race condition that sometimes truncated the last string, if you set Mode to idle before setting the _SerialPort_StreamBuffer. Here the code:
private void _SerialPort_DataReceived(object sender, SerialDataReceivedEventArgs e)
        {
            if (this._SerialPort.BytesToRead == 0) return;

            // Reads out the data and converts it to a string
            byte[] ReadBytes = new byte[this._SerialPort.BytesToRead];
            this._SerialPort.Read(ReadBytes, 0, ReadBytes.Length);
            string ReadBuffer = new string(Tools.Bytes2Chars(ReadBytes));

            // While in Streaming mode, we need to handle the data differently
            if (this._Mode == Modes.StreamingMode)
            {
                bool newModeIdle = false;
                _DebugPrint('I', ReadBuffer);
                string NewBuffer = this._SerialPort_StreamBuffer + ReadBuffer;

                // Fixes the "*CLOS*" issue as described below
                this._SerialPort_EndStreamCheck += ReadBuffer;
                if (this._SerialPort_EndStreamCheck.Length > this._SocketCloseString.Length)
                    this._SerialPort_EndStreamCheck = this._SerialPort_EndStreamCheck.Substring(this._SerialPort_EndStreamCheck.Length - this._SocketCloseString.Length);

                // Do we need to leave Streaming Mode?
                int CheckPos = NewBuffer.IndexOf(this._SocketCloseString);
                if (CheckPos >= 0)
                {
                    this._SerialPort_TextBuffer = NewBuffer.Substring(CheckPos + this._SocketCloseString.Length);
                    NewBuffer = NewBuffer.Substring(0, CheckPos);
                    //this._Mode = Modes.Idle;
                    newModeIdle = true;
                    _DebugPrint('D', "1 Left streaming mode");
                    _DebugPrint('D', NewBuffer);
                }
                // The closing string (default: "*CLOS*") is many times sent in multiple packets.
                // This causes annoying issues of connections not shutting down well.
                // This fixes that issue, but it's possible the last few bytes of the stream contain something like "*CL" or something.
                else if (_SerialPort_EndStreamCheck == this._SocketCloseString)
                {
                    //this._Mode = Modes.Idle;
                    newModeIdle = true;
                    _DebugPrint('D', "2 Left streaming mode");
                    NewBuffer = "";
                }
                this._SerialPort_StreamBuffer = NewBuffer;
                if (newModeIdle)
                    this._Mode = Modes.Idle;
                return;
            }
The other thing is just a nicety to remove extraneous *CLOS from the last string (assuming that's not really part of the message).
In HTTP_Client
private HTTP_Response _DoRequest(string RequestData)
        {

            // Opens the connection
            this._Socket.Connect();
            // Sends out the request
            this._Socket.Send(RequestData);
            // Fetches the returned data
            string ResponseData = "";
            string tmp = "";
            while (this._Socket.IsConnected || this._Socket.BytesAvailable > 0)
            {
                tmp = this._Socket.Receive();
                if (tmp.IndexOf("HTTP/1.1 200 OK") >= 0)
                {
                    Debug.Print("found OK HEADER at " + tmp.IndexOf("HTTP/1.1 200 OK") + ", resetting input string");
                    ResponseData = tmp;
                }
                else
                    ResponseData += tmp;
            }
            // Closes the connection
            this._Socket.Close();
            Debug.Print("RESPONSE: " + ResponseData[ResponseData.Length-1]);
            string ending = ResponseData.Substring(ResponseData.Length-5);
            string foo = ending.Substring(1, 4);
            string foo2 = ending.Substring(2, 3);
            string foo3 = ending.Substring(3, 2);
            if (ending == "*CLOS") ResponseData = ResponseData.Substring(0, ResponseData.Length - 5);
            else if (ending.Substring(1, 4) == "*CLO") ResponseData = ResponseData.Substring(0, ResponseData.Length - 4);
            else if (ending.Substring(2, 3) == "*CL") ResponseData = ResponseData.Substring(0, ResponseData.Length - 3);
            else if (ending.Substring(3, 2) == "*C") ResponseData = ResponseData.Substring(0, ResponseData.Length - 2);
            else if (ending.Substring(4, 1) == "*") ResponseData = ResponseData.Substring(0, ResponseData.Length - 1);
            // Parses the response data
            HTTP_Response RetVal = new HTTP_Response(ResponseData);
            // Parses cookies and such
            this._ParseHeaders(RetVal.GetAllHeaders());

            return RetVal;
        }
looks OK now, but cursory checks.. will do more checking
Fritz

Edited by Stefan, 23 June 2012 - 08:09 AM.
Added [code] tags


#22 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 04 July 2012 - 05:35 PM

Hi Fritz, I can't reproduce the redirect issue with cookies. See the attached project. It just works as expected. It follows a few redirects, all setting a cookie, and in the end all cookies are still there. Maybe I try to reproduce it in the wrong way, could you send me a small project that can reproduce the issue?

Attached Files


"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#23 fritzE

fritzE

    Member

  • Members
  • PipPip
  • 11 posts

Posted 18 July 2012 - 02:44 PM

Stefan, do you happen to have an HTTP server for this Wifly? or point me to one? I'd like to use it as a straight socket, HTTP server or relay (yaler) server. Any suggestions? thanks.

#24 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 18 July 2012 - 02:49 PM

Stefan, do you happen to have an HTTP server for this Wifly? or point me to one? I'd like to use it as a straight socket, HTTP server or relay (yaler) server. Any suggestions?
thanks.

I haven't written the option to use a socket listener yet. Also, I don't think using the wifly rn-xv module as webserver would be great performing.
For example it can handle only one connection at the time. That's one of the reasons I haven't developed the socket listener feature for the wifly module.
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#25 fritzE

fritzE

    Member

  • Members
  • PipPip
  • 11 posts

Posted 18 July 2012 - 04:59 PM

OK. Can you point me to where I could learn about how to do the socket listener? I want to remote control a vehicle so can live with one connection, but the http client approach is too slow (polling, etc.).

#26 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 18 July 2012 - 05:23 PM

OK. Can you point me to where I could learn about how to do the socket listener? I want to remote control a vehicle so can live with one connection, but the http client approach is too slow (polling, etc.).

The user manual should be a good reference: http://dlnmh9ip6v2uc...WiFly-RN-UM.pdf
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#27 fritzE

fritzE

    Member

  • Members
  • PipPip
  • 11 posts

Posted 21 July 2012 - 04:51 PM

OK. Will work on that... Question: The default baud is 9600. have you tested higher rates?? Do you think that is a bottleneck?

#28 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 21 July 2012 - 07:38 PM

OK. Will work on that...
Question: The default baud is 9600. have you tested higher rates?? Do you think that is a bottleneck?

Wouldn't be a problem, but you also have to configure the module to a higher baud rate. It must be in sync.
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#29 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 21 July 2012 - 09:06 PM

One note on Zigbee/XBee... Because it's using RF, the available bandwidth inherently fluctuates. As you use higher speeds, you may need to also enable hardware or software flow control. This should keep the XBee's serial buffers from overflowing when RF bandwidth is in shorter supply, when retransmitting failed data frames, etc. Chris




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.