@ Alex Glad to hear, that it works now.
@ dobova Thanks for your help and the bug report. Please tell me if you find more issues. I’ll collect them for a while and will post an improved version eventually on the new weekend. Did you see any data corruption? I’m curious to see if it is free of data corruption for large files too
@ Alex Bilityuk -
There are a couple of limitation to take in consideration. The RN-XV is NOT capable to manage more than 1 connection at time. So you need to know exactly what’s going on and who is connecting to it. When it’s transferring bitmap, you can’t contact module to send/rcv commands or infos until the end of transfer (or abort). If you need this behaviour, it is better to go for other type of Wifi modules. Remember that most browser call 2 times in sequence for bitmaps (e.g. Firefox), once for real bitmap and then a second time for thumbnail.
@ RoShmi - I will post eventually other bugs I will found. Thank you for your great job!
Ok dobova thank you for valuable information… i didn’t know that. i don’t need this behavior for now… maybe later i will… It would be nice to be able to send/recv commands to the robot if the L2 camera can do a real videostreaming to windows browser without delay and you can see what is going on on the way and control robot behavior…
Do you have an experience with other types of Wifi modules you talking about with more than 1 connection?
And can you advice how to make a GUI for browser to control robot?
@ Alex
Hi,
I would prefer to use a Windows App that sends http-requests to the robot instead of using a browser. So you can implement some kind of handshaking and you can manipulate the picture data as you want. As another idea I would propose to split the pictures in chunks, so that you can send steering commands to your robot in the gaps between the picture transmission chunks. Real-time video will not be possible, I think. Our NETMF devices are far too slow for this task.
@ RoSchmi - I’ve deployed project on FEZ Raptor and I see some issue with serial port. Unless the module is used on a K socket (not working on Raptor) after 30-40k of trasmission data seems to be jammed or truncated. Have you experienced this problem ? It seems very strange, becouse rn-xv module is set with no handshake flow… 
Some months ago there was this post of jston05
https://www.ghielectronics.com/community/forum/topic?id=14736&page=5
I’m not yet got far enough to say something definitely, but in preliminaly tests when I tried to transfer pictures from SD-Card over http request from a raptor I saw that small files worked but with large files transmission was not complete (stopped).
I think to remember that I read something in the manual that for baudrates of more than 115200 Hardware handshake is necessary.
Additionally one must keep in mind, that the bytes always must have their place to be. If you can not take them fast enough away on the receiver-side, you can not unlimited push them in the wire on the Sender - side.
Arghh… yes I can confirm. To make trasmission on FEZ Raptor I had to change some stuff in your original driver and set baudrate to 38400 … ???
Nice, will this changes be in the next revision of the driver?
Hi Alex,
no I don’t think so. I just found a trick that is not accettable for a board like G400, becouse I change speed and chunks length adding delays so TX to the board is “mostly” working but it’s not reliable in any way. I hope GHI will release CTS/RTS handshake soon for serial port (K socket) on the G400 series boards. This is not a problem on other boards.
I use FEZ Spider when testing some idea becouse it’s the most reliable, rock solid netmf board (now it’s a bit slow…).
Ok dobova… Thank you.
@ dobova - If you found more bugs in the driver, please let me know. I want to post a revised Version tomorrow.
RoSchmi, whats new in Revision 4?
@ Alex Bilityuk - The bug reported from dobova was eliminated.
I added a PC Windows Forms application to transfer a picture or text over the wireless connection by http-Request.
RoSchmi, thanks for your update… I upgraded my firmware to 2014 R5 and downloaded the Revision 4 and now i am having a problems with picture sending over network…
And it seems like the problem is not in your driver for sure, the problem is in new firmware… I read that GHI improved a networking issues in new firmware and now on my http client side i can’t make an Image from byte stream… When i am using a 2014 R3 firmware and your latest driver revision 4 everything is good and i am able to load a picture sended by robot on my http program client side… also your http client load it successfully, but when i load a new firmware to my robot and create a new gadgeteer project 2014 R5 and copy all the same working code to it i cant create a bitmap image from stream on the http client side (my http windows client) it throws a System.ArgumentException on this line of code:
Stream pictureStream = response.GetResponseStream();
img = Image.FromStream(pictureStream); // HERE IS A System.ArgumentException
I am sure that my problem is in the latest firmware update because all the same code works
very stable in 2014 R3…
Does anybody meet the situation like me? Maybe GHI made a changes in networking and i should use another approach or anything else?
And one more strange thing, i was able to load an image in browser with 2014 R5 firmware, but not in my or your’s http clients…
@ Alex - There is a bug in the latest SDK regarding bitmaps. Take a look at https://www.ghielectronics.com/community/forum/topic?id=17180&page=1#msg171149
@ Alex Bilityuk - Do you have the issues as well if you use my Apps on Cerbuino- and PC- side and load the picture Beautiful.jpg which is included in the Resources of the Cerbuino App?
Thank you for reply
I dont know why, but after i load gadgeteer project in debug moode and reload it in the release… everything works well for now…
Here is my assemblies info:
Is it ok that some dll’s goes with new 4.3.6.0, but some comes with different 4.3.1.0 and so on?
@ Alex Bilityuk - I have the same Assembly Versions. I think that you had old assemblies in your release version.
Just for my information: What is the size of your pictures? Did you try with large pictures of 100 Kbyte or more?
I hadn’t for sure, because i double checked it…
The size of my pictures is about 10-12 kbytes (very small). I didn’t try with 100 kbytes and more.
Yesterday i tested your http client sample with continues streaming of small pictures from L2 camera i just put one additional line of code to your sample at the end of myDownloadWorker_New_Data_Received eventhandler i added startRequest(); method to start requesting for picture after previous was recived
void myDownloadWorker_New_Data_Received(object sender, DownloadWorker.Received_EventArgs e)
{
if (this.InvokeRequired)
{
this.BeginInvoke(new EventHandler<DownloadWorker.Received_EventArgs>(myDownloadWorker_New_Data_Received), new object[] { sender, e });
return;
}
Console.WriteLine("Page downloaded");
if (e.contentType == "text/html")
{
textBoxResult.Text = e.stringContent;
pictureBox1.Image = null;
pictureBox1.Invalidate();
}
if (e.contentType == "image/bmp")
{
textBoxResult.Text = "";
pictureBox1.Image = myImageConverter.byteArrayToImage(e.binContent);
}
HttpRequestIsRunning = false;
startRequest();
}
and i have a System.Threading.Tasks.TaskCanceledException after about 4-5 continious pictures requests.
Here is debug output and we can see that sometimes after request we have a lot of thread exits and finally the TaskCanceledException is thrown:
Downloading page...
Page downloaded
Downloading page...
Page downloaded
Downloading page...
Page downloaded
Downloading page...
The thread '<No Name>' (0xa4c) has exited with code 0 (0x0).
The thread '<No Name>' (0x17c0) has exited with code 0 (0x0).
The thread '<No Name>' (0x1370) has exited with code 0 (0x0).
The thread '<No Name>' (0x15dc) has exited with code 0 (0x0).
The thread '<No Name>' (0x127c) has exited with code 0 (0x0).
The thread '<No Name>' (0x1250) has exited with code 0 (0x0).
A first chance exception of type 'System.Threading.Tasks.TaskCanceledException' occurred in mscorlib.dll
The thread '<No Name>' (0x420) has exited with code 0 (0x0).
I have the same behavior in my http client (after about 5-6 times streaming holds on the client side and the green light on the wifly holds with no blinking), i am using creating new threads instead of Tasks like you and when i need to stop streaming i use a stop bool parameter to abort the thread, like this:
private void BUTTON_CAPTURE_IMAGE_Click(object sender, EventArgs e)
{
try
{
PictureStreamingThread = new Thread(DoWork);
PictureStreamingThread.Start();
while (!PictureStreamingThread.IsAlive);
}
catch (Exception exp)
{
}
}
// This method will be called when the thread is started.
public void DoWork()
{
_shouldStop = false;
try
{
while (_shouldStop == false)
{
StreamingPictureMethod();
}
}
catch (ThreadAbortException exception)
{
MessageBox.Show(exception.Message.ToString());
}
}
public void RequestStop()
{
_shouldStop = true;
}
Do you know how to adjust streaming to achieve a stable http client behavior?
@ Alex Bilityuk - it’s not a good idea to start the next request in the eventhandler. So the first request will never finish. You should set up a timer to start new requests or a Loop in another thread that continuously asks the “request running flag”