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.
Are there any other similar services like Pachube? It's a fantastic idea, but it's a bit to expensive. If I want to monitor my whole house and keep a infinite history, $99 is to much for me.
ThingSpeak looks promising, but I don't see anything about costs yet!
Also, check out sen.se
No POST yet, the version above for Innocactive uses the socket version. On the flush issue, have you changed the UART rate? I have not noticed flush issues, aasuming that you have ssen incomplete/garbled outgoing traffic. You may also try to upgrade the firmware, for example, by uncommenting the two SendCommand() below (the second one displaying everything, including your firmware version):
Most of the WiFly samples (from the User Guide) use something like 'set comm remote GET [rest of get data]'. My GET string (mostly the parms) is ~90 characters long. When I use the 'set comm remote' approach, only the first ~30 characters are sent to the remote host. I'm having pretty good success with the following config settings:
And then using the following to send data through the UART:
leaveCommandMode();
enterCommandMode();
Send("\r");
SendCommand("set dns name " + DnsName);
SendCommand("set ip remote 80");
SendCommand("set comm remote 0");
SendCommand("set comm time 1000");
SendCommand("open");
Thread.Sleep(2000);
Write(GetCommand);
My GET string looks sort of like this:
GET /api/record/?status_code=running&serial_id=12345 HTTP/1.1\r\nUser-Agent: Netduino\r\nHost: myhost.mydomain.com\r\n
With these settings, I'm running two boards concurrently on two different IP networks. They've been running for ~ 20 hours as of this morning. No issue. I send the reboot command through the board about every two hours, and I'm making the GET call once every 2 minutes.
I'm relatively new to this (lots of C# experience, but little experience with the WiFly, the board commands and UART/SPI), so when you ask if I've changed the UART rate, I think the answer is "yes". I used your HTTP library sample to set up the board/used your Init function more or less as-in but changed the baud to 38400.
I do see junk moving through the UART. I think it's because I turned flow control off. When I leave it on, after maybe 10 posts, I'd run into what I think is the issue described in the WiFly user manual where the CTS pin gets set to high and I can't move stuff through the UART. I think it's just a matter of finding the right combination of settings. Thanks for the help.
I do see junk moving through the UART. I think it's because I turned flow control off. When I leave it on, after maybe 10 posts, I'd run into what I think is the issue described in the WiFly user manual where the CTS pin gets set to high and I can't move stuff through the UART. I think it's just a matter of finding the right combination of settings.
Quick note: the very first mandatory thing with WiFly, as I learned the hard way, is hardware flow control at this high speed! So please turn it on, and then allow some Thread.Sleep() to allow the WiFly to consume what it needs to absorb. If necessary, attach your standalone test program to your reply
Quick note: the very first mandatory thing with WiFly, as I learned the hard way, is hardware flow control at this high speed! So please turn it on, and then allow some Thread.Sleep() to allow the WiFly to consume what it needs to absorb. If necessary, attach your standalone test program to your reply
JP
Thanks. I'll batch something up this weekend and attach.
RE: flow control...I hear you, and I've tried with flow control on and off. I'm clearly getting junk in the buffer with flow control off, but it seems like, overall, my results are better when flow control is off. That said, I think the issue I'm running into with flow control on is that the CTS pin is getting out of whack.
I'm going to keep tinkering with the settings and see if I can find an ideal.
Is there anything on the UART/Register side that causes the buffer to send to the host whatever is in the buffer? Like I also wrote below, seems like a my longer GET string creates some inconsistency in the time in which it takes to flush the buffer.
Quick note: the very first mandatory thing with WiFly, as I learned the hard way, is hardware flow control at this high speed! So please turn it on, and then allow some Thread.Sleep() to allow the WiFly to consume what it needs to absorb. If necessary, attach your standalone test program to your reply
JP
Test program attached (you'd need to add your own ssid/pass in the Wifly implementation; I left out the Socket implementation to keep things simple). I have flow control OFF in the code attached. Also, I'm using a Netduino board and not an N+, so you may have to switch the SecretLab reference to an N+ board.
The behavior I see: on the first loop, no GET call occurs; I assume this is because the UART isn't loaded or emptied properly or because I'm not filling/emptying the UART properly; subsequent loops produce a GET (I assume it's reading from the buffer I loaded on the previous loop), but - in general - the app runs sort of "one behind". If you switch flow control on, a GET occurs every other loop and doubles up the data (e.g., the card sends two GET statements). So instead of being one behind, you get not GET, two gets, no GET, two gets, etc.
Neither of these behaviors is the end of the world for my app, but I'm curious if anyone sees something obvious or unobvious!
I've tried a lot of permutations including the set comm remote <string> which works pretty well except that, as I noted in another post, it chops my GET call off around the 30th character; my GET string is about 90 characters.
Test program attached (you'd need to add your own ssid/pass in the Wifly implementation; I left out the Socket implementation to keep things simple). I have flow control OFF in the code attached. Also, I'm using a Netduino board and not an N+, so you may have to switch the SecretLab reference to an N+ board.
I'll take a look when back from business trip, in 8 days from now. Maybe you'll know more since
Got it working. It ended up being an issue with the open command/getting in and out of command mode at the right time(s). The following changes to the SendGetCommand method in the sample I posted above works well:
The code needs some improvements (I need to check results; can probably call SendCommand on the "close" which will also empty the POST buffer, I'm probably too cautious with the Sleeps, etc.), but it's doing what I'd expect. I see the buffer emptying every ~500 ms, and my GET/POST commands are working (almost) perfectly. There are still some occasional issues where it doesn't seem like the close/exit is happening and that sort of leaves the thing in an unknown state on the next loop, but I fixed the root of my problem.
Nice job with the HTTP lib, however the webserver chokes if I refresh the repeatedly (ie refresh before a response is fully received), see attached for the exception.
Any ideas how that could be solved?
I saw you define a backlog of 10 when you new up the HttpSocketImpl:
m_listeningSocket.Listen(10);
but maybe that doesn't help?
I think you based your listener on Fred's nonblocking webserver (http://forums.netdui...ted-web-server/), which by the way has the same issue.
I haven't tried any changes to your code but what if the webserver was threaded?
RE: flow control...I hear you, and I've tried with flow control on and off. I'm clearly getting junk in the buffer with flow control off, but it seems like, overall, my results are better when flow control is off. That said, I think the issue I'm running into with flow control on is that the CTS pin is getting out of whack.
I think I'm having the same issue jd - did you ever solve the flow control problem? I'm staying back at 19200 baud for the time being and the board seems to work fine but I would like the extra speed.
I think I'm having the same issue jd - did you ever solve the flow control problem? I'm staying back at 19200 baud for the time being and the board seems to work fine but I would like the extra speed.
James,
I have flow control on, and I'm running @ 38400 without issues. In my applications, I'm rarely receiving requests. I'm mostly POSTing and GETting. As such, my use case might not be applicable to you. The trickiest thing with the WiFly board, in my opinion, is getting it in and out of command mode at the right time(s).
I don't want to sound too cheep, however sparkfun has the WiFly shield listed for $90, but you can purchase the RN-131C from mouser for $39. As far as I can tell, not purchasing the WiFly board, I would loose the actual printed board, which isn't an issue for me as I don't intend to mount as a shield. And I would loose the SC16IS750 SPI-to-UART chip. The statement on sparkfun is: The SPI-to-UART bridge is used to allow for faster transmission speed and to free up the Arduino's UART.
I'm not sure I care about the pins, though if I use a NetDuino Mini, not sure how to switch between the 131 and my PC for programming/debugging. As for the faster speed, does anyone have an idea how much slower it would be? Any idea how hard it would be to modify the WiFly driver to talk over a COM port rather than SPI? Anything else I'm missing being new to this world? If I really need the SPI - UART chip, looks like sparkfun sells that standalone for < $15.
Thanks,
Chad
I don't want to sound too cheep, however sparkfun has the WiFly shield listed for $90, but you can purchase the RN-131C from mouser for $39. As far as I can tell, not purchasing the WiFly board, I would loose the actual printed board, which isn't an issue for me as I don't intend to mount as a shield. And I would loose the SC16IS750 SPI-to-UART chip. The statement on sparkfun is: The SPI-to-UART bridge is used to allow for faster transmission speed and to free up the Arduino's UART.
I'm not sure I care about the pins, though if I use a NetDuino Mini, not sure how to switch between the 131 and my PC for programming/debugging. As for the faster speed, does anyone have an idea how much slower it would be? Any idea how hard it would be to modify the WiFly driver to talk over a COM port rather than SPI? Anything else I'm missing being new to this world? If I really need the SPI - UART chip, looks like sparkfun sells that standalone for < $15.
Thanks,
Chad
Apart from the UART needed to control the RN-131C directly, the other difference is the support for hardware flow-control (RTS/CTS). When is flow-control needed? As an indication the datasheet says "The UART receive buffer is approx. 1500 bytes, and at lower baudrates (less than 115K) the system can send data over TCP/IP without the need for flow control."
I have done some testing with flow-control disabled (at 19200 bauds) and observed characters loss when receiving data from the router alone, for example after emitting the command "get everything". So my advise is to have hardware flow-control enabled, hence support for RTS/CTS, to stay safe in all cases. This means that your need the controlling UART to support RTS/CTS, which is not the case on the Mini. This is where a chip like the SC16IS750 comes to play.
Apart from the UART needed to control the RN-131C directly, the other difference is the support for hardware flow-control (RTS/CTS). When is flow-control needed? As an indication the datasheet says "The UART receive buffer is approx. 1500 bytes, and at lower baudrates (less than 115K) the system can send data over TCP/IP without the need for flow control."
I have done some testing with flow-control disabled (at 19200 bauds) and observed characters loss when receiving data from the router alone, for example after emitting the command "get everything". So my advise is to have hardware flow-control enabled, hence support for RTS/CTS, to stay safe in all cases. This means that your need the controlling UART to support RTS/CTS, which is not the case on the Mini. This is where a chip like the SC16IS750 comes to play.
Good to know, when you tested, was that directly to the 131 or between the SC16IS750?
I tested via the SC16IS750 still, as I used the Sparkfun's WiFly shield (with flow-control disabled)
Thanks, I think I understand. The netduino doesn't support hardware flow control. The 131 doesn't support software flow control. The SC16IS750 talks to the 131 using hardware flow control and the NetDuino via SPI which allows the NetDunio to control the clock and explicitly transmit the bits.
Here's a patch to StringBuilder that makes it much less of a memory hazard and also adds support for any object as with the full framework. It just calls arg.ToString() same as the full framework. Boxing means this ought to work for ints and floats although I haven't tried it out yet. At some point I may add support for format strings within tokens.
The significant changes are the forcing of garbage collection in the substitute(string format, String key, object val) and Append(char c) methods, both of which are called in a loop by other methods and both of which allocate objects.
I found that this and putting an #ifdef block around the entire HttpWiflyImpl code block was the difference between OoMem and having 18K free. I just checked and the WIFLY code only costs another 250 bytes. I'm not sure how that can be but that's what the GC reports.
/*
/*
* A custom StringBuilder implementation that also does formattting ("{0}...{1}..." etc)
*
* Use this code for whatever you want. Modify it, redistribute it, at will
* Just keep this header intact, however, and add your own modifications to it!
*
* 10 Jan 2011 -- Quiche31 - Added suppport for AppendFormat
* 12 Jan 2012 -- Arbiter - Added aggressive garbage collection
* - AppendFormat now accepts any class of arg
* - Fix buffer extension for short buffers
*
* */
using System;
using System.Text;
using System.Threading;
using System.Net.Sockets;
using System.Net;
using System.Collections;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using System.IO.Ports;
namespace astra.http
{
public class StringBuilder
{
char[] buffer = null;
int size = 0;
public StringBuilder(int size = 20)
{
buffer = new char[size];
}
public void Append(char c)
{
if (size + 1 >= buffer.Length)
{
char[] buffer2 = new char[(buffer.Length * 4 / 3) + 1];
Array.Copy(buffer, buffer2, buffer.Length);
buffer = buffer2;
Debug.GC(true);
}
buffer[size++] = c;
buffer[size] = '\0';
}
public void Append(String s)
{
foreach (char c in s)
Append(c);
}
public void Clear()
{
size = 0;
buffer[0] = '\0';
}
public override String ToString()
{
return new String(buffer);
}
public void AppendFormat(String format, params object[] args)
{
int i = 0;
foreach (object arg in args)
format = substitute(format, "{" + (i++) + "}", arg);
Clear();
Append(format);
}
String substitute(string format, String key, object val)
{
int i;
if (val == null) val = string.Empty;
if ((i = format.IndexOf(key)) != -1)
format = format.Substring(0, i) + val.ToString() + format.Substring(i + key.Length);
Debug.GC(true);
return format;
}
}
}
Here's a patch to StringBuilder that makes it much less of a memory hazard and also adds support for any object as with the full framework. It just calls arg.ToString() same as the full framework. Boxing means this ought to work for ints and floats although I haven't tried it out yet. At some point I may add support for format strings within tokens.
The significant changes are the forcing of garbage collection in the substitute(string format, String key, object val) and Append(char c) methods, both of which are called in a loop by other methods and both of which allocate objects.
Thanks a bunch Arbiter. I have updated the library in my original post with your change (and name on it); have not tested it but seems a safe fix that can only improve how the library and client app work.
Wouldn't it be nice if Servers in the Cloud such as Pachube supported open-ssl, with the minimum set of associated services, and that could issue certificates to authenticate either endpoints (the triggers that user configure and the devices that update feeds or receive trigger events)?
You would run out of memory before you got started. A more practical solution is to run your own server. It can still be in the cloud - think Windows Azure. The device can then periodically connect to your server and download an updated configuration file. You are still vulnerable to DNS and spoofing attacks but how much can you seriously expect from a $70 device?
The FEZ Hydra with 16M of RAM would be another matter; plenty of elbow room to use all the mod cons without constant OutOfMemory exceptions (I'm not bitter). SSL also becomes possible, but you will find it doubles the size of your traffic. This is fine for tinkering but inadvisable for a fleet deployment.The Hydra is also very new and no doubt riddled with the bugs inevitable in a 1.0 release.
Had a look at this Aug 2012, looks like COSM (was Pachube) is now free. Will be trying this in the next few days, just updated my N+ to 4.2 ... cheers, W
