2 replies to this topic

[Dredmanwalkin]

Hello all,

 

I've been reading your posts for a few months now.  Thank you all-the information here has been invaluable in getting my project off the ground.

 

I'm trying to use a Netduino 2 to emulate radar patterns at sunrise to an external analyzer-cool stuff. 

 

My short question is:

 

"Is there a limit to the amount of data that can be received via the following serial data handling method?"

 

 

        static void serial_DataReceived(object sender, SerialDataReceivedEventArgs e)

        {

            Thread.Sleep(4000);

            while (serial.BytesToRead > 0)

            {

                bytesread = serial.BytesToRead;

                serial.Read(bytes, 0, bytes.Length) ;//bytes[] is declared earler: //static byte[] bytes = new byte[4610];

            }

            FillWorkingArrays();

        }

 

 

I am using the Taltech SendFile application.  I am sending a text file with two columns of data to a Netduino2 (Nd2) connected via USB.  At the Netduino end the maximum number of bytes of data that I receive is 256.

 

Basically I have two columns of data that I need to put into the array bytes[].  It doesn't matter how long I let the event handler sleep, I only get 256 bytes of data.  I need a LOT more than that.  

 

Is the issue in my declaration for the bytes[] array or a limitation of the serial buffer?  Is there a better way to get the data?  This is the layout of the data:

 

111,1111

222,2222

333,3333

444,4444

 

 

Thank you for your help,

 

 

Miguel Ramirez

[rharding64]

hello there,

 

first off let's look at your datreceived event handler;

 

    static void serial_DataReceived(object sender, SerialDataReceivedEventArgs e)

        {

            Thread.Sleep(4000);

            while (serial.BytesToRead > 0)

            {

                bytesread = serial.BytesToRead;

                serial.Read(bytes, 0, bytes.Length) ;//bytes[] is declared earler: //static byte[] bytes = new byte[4610];

            }

            FillWorkingArrays();

        }

 

lose the Thread.sleep statement. 

//next if you are trying to parse out specific data in datareceived event handler

 

the place that you need to add the sleep statement is immediately AFTER sending to serial port.

in c# this would be

 

serialport.WriteLine("my data");

thread.sleep(300);

serialport.clearinputbuffer();

 

//now ready for next data

 

since you are using c# already anyways, it is not too hard to take file data, parse it out and push it to netduino.

that way you can lose the external file application and have your cake and eat it too, and not eat someone else's cake!

 

 

you are going to have to build a buffer, it is easiest to move the data as strings then once you push it to netduino, parse out to numbers at that end.

 

follow these steps;

 

string[] array = File.ReadAllLines(@"C:\path including your file");//this is VERY Fast file open, extract info, file close, all in one line!!!

 

the data; 111,2222 -- do you want this to be put into a lookup hash table, list<string.,string> or dictionary<string,string>? comma delimited.

or are you waiting to parse them out until you are on netduino?

 

next, you need a buffer, you can use a stack or a 256 level queue here.  , or

you can put a whole packet into queue.

 

anyhow, something for you to get started on, ask questions, have fun.

 

cheers

 

ron

 

[Dredmanwalkin]

Thanks Ron,

 

 

Funny, I also got a suggestion from a programmer at work that moving the data as strings would be easier.  I guess that's probably the more common way to do it; something I'm going to try.  

 

That sleep was basically only allowing the buffer to get filled once! Thanks for the advice.

 

The way i have been handling the data so far is parsing it out once it's in the Netduino.  I have a routine that looks through the bytes[] array and basically just walks through it and uses it the comma and the carriage return delimiters to determine whether the value is a power level (first column) or delay time (second column).  

 

I'll let you know how it goes-probably won't get back to this until after Wednesday of next week. But I'll definitely keep you posted.

 

 

Thanks again,

 

 

Miguel