Arduino Example22
Pages:
1
![]() |
lkeyes private msg quote post Address this user | |
Hi...I've been experimenting with sending data from my Arduino Uno + Ethernet shield with the goal of sending real-time heart-rate data for charting in GroveStream. I got the example to run fine, but now seem to be having reports back that the connection couldn't be made after four tries; this after modifying the original example code. Didn't know if anyone else had been experimenting with Arduino and if so, I'd love hear of your experiences. |
||
Post 1 IP flag post |
![]() |
MikeMills private msg quote post Address this user | |
It seems like the biggest culprit for these types of errors is lack of memory on the board. That could be your issue. The Arduino forum has some threads on how to monitor memory. A large clue that memory is an issue that we've noticed in the past is that when we try and trace out the URL in our sketch, prior to it being used, only part of the URl is traced out. I imagine the lack of memory is causing memory to be overwritten in places. Also, avoid doing string appending like this: a = b + c + d; Do this instead: a = b; a += c; a += d; This lowers required peak memory. |
||
Post 2 IP flag post |
![]() |
ctmorrison private msg quote post Address this user | |
I did a fair amount of development with the Arduino Uno platform and implemented a production monitoring system using a Ruggeduino which is a bit more tolerant of real world mishaps. The device was fairly reliable at reading, packing up data and sending it off to a cloud service called ThingSpeak on a per minute basis. It ran for over a year with few issues. We then moved to the GroveStreams cloud platform for many reasons, but the micro-controller end of things is fairly similar. The next move was to the SolderCore micro-controller platform and had significantly greater success due to higher performance, more memory and a simple development environment. Most recently, I've made the move to the Electric Imp platform and don't see going back. The Imp is a pleasure to work with and my development has progressed at a much quicker pace. We've also found the cloud connectivity to be far superior to either the Arduino or SolderCore platforms. Yes, we're still on the GroveStreams cloud service have have never regretted that move! I'm not sure this is what you wanted to hear, but thought I'd offer the feedback. |
||
Post 3 IP flag post |
![]() |
steveb private msg quote post Address this user | |
I had the devil of trouble with the Arduino in the beginning - similar problems where the base example ran but when I tried to expand it ,"bad things" happened - it used to run for 30 minutes (6 posts) and then die. And as I put in more debugging (serial.prints etc), the worse it got - although sometimes it did print some corrupted data out which pointed me towards memory management. As the sample code suggests, I think that the problem is with the Arduino memory handling - something which I had to learn about (not being a C programmer I had no background in this) I fixed it eventually and now my much more advanced sketch, complete with calling in external libraries to decode infrared meter readings, has been rock solid for a number of weeks. Just as soon a I tidy what I did I will post it but the code is VERY messy as I don't know how to pass pointers into functions etc so the main grovestreams HTTP call is pieced together in one place, and I dropped a few unnecessary (to me) functions - getMacReadable and getIpReadable. So, I changed all of the "Strings" to char[] - and the ones in the header to to const char[] - the logic being that constants don't use memory, as the compiler compiles them in the code? (This may or may not be true, but makes sense in my mind) const char gsApiKey[] = "Your API key here"; I also defined char url[190] ; //note this needs to be long enough to hold your longest post. 190 is OK for me! char buf [10]; //our biggest number is 9 digits long when converted to strings then in UpdateGroveStreams I replaced the String addition with things like this. Strcopy makes the intial string (well, character array), then strcat appends the extra pieces. sprintf formats my unsigned long variables into the array "buf" which is then used in the strcat process.
You may be able to back-piece this into your solution, but I think the master arduino sample sketch could perhaps do with being updated by someone more competent that me, since it runs quite "close to the wire" on memory usage. -Steve --edit-- can't get rid of the smileys, sorry, even inside "code" tags |
||
Post 4 IP flag post |
![]() |
MikeMills private msg quote post Address this user | |
Thanks Steve. I think we'll eventually add a second Arduino example without String class usage as you suggest for advanced users. Ninja Post (our forum software) is looking into the smileys inside code tags issue. The code tag was just added by them. |
||
Post 5 IP flag post |
![]() |
mikew private msg quote post Address this user | |
Quote:Originally Posted by MikeMills Sorry about that @steveb and @MikeMills -- code should render much better now! |
||
Post 6 IP flag post |
![]() |
fixingthingsguy private msg quote post Address this user | |
I have been struggling with buffering data using strings as in the Ard. example. I'm trying to avoid the 10 sec. rule. I wish there is a GS workaround to help, but I have read the posts. The results using strings are not repeatable and inconsistent. I hard coded the data and sent it up in the URL and GS responded all the time accurately. So, I'm going to attempt Steveb's approach. I also endorse the suggestion to modify the GS/Arduino example to make things easier for new potential GS users. |
||
Post 7 IP flag post |
![]() |
ctmorrison private msg quote post Address this user | |
I've had the Ruggeduino (ruggedized Arduino) running for over a year, pushing data to GroveStreams every minute of the day and night. Would it help if I share that code? I'm simply pushing temperature and humidity now, but it could easily have sent several additional streams updates as well, as it did in the past at another site. I needed to do more sophisticated processing and didn't want to deal with what I perceived to be limitation of the Arduino Uno platform. That being said, it has been a rock solid platform! | ||
Post 8 IP flag post |
![]() |
JosAH private msg quote post Address this user | |
Greetings, I use an Arduino Yun for this purpose; I've been testing for some time now and all the glitches came from the embedded devices; not from the internet connection nor from the Grovestreams server. I personally think that 2.5KB or 4KB or RAM is too small to use for string manipulation (without hacking); I let the Yun's Linux side handle it all an leave the Arduino (a small AtMega 32U4 processor) do for what it's good at: control small devices. kind regards, Jos |
||
Post 9 IP flag post |
![]() |
fixingthingsguy private msg quote post Address this user | |
CTM,others: I'm using an Arduino UNO R3 and the problem I'm up against is that I am monitoring (testing now) door open/close, that can happen fairly fast. So during testing I noticed a number of events were being missed and found out(remembered,is more like it) that GS rejects anything more frequent than once in 10 secs. That's fair, thats the business/performance decision. So I tried to buffer these events and send them along after 10 sec had passed. Therein lies the problem(not at GS). I'm using the URL as a String from the example and its using up SRAM which is limited to 2048 bytes. I traced the usage and it keeps successively eating up SRAM and then fails. If you have a working example of not using strings to form the URL for the http message that would be useful to me and I'm sure others. I hear that working with characters is more reliable probably because you reserve that space and there is less fragmentation.That's the option I have to work with unless I chose a different processor, which I don't want. So, I'm going to take a break and dive into characters from scratch to see if this problem on the Arduino is solvable, for me, anyway. The code I wrote essentially says, if I last updated GS within 10 s, buffer the data. And that buffering kills the SRAM. I have another system running for months monitoring my garage door with no failures, of course, because I rarely break the 10 sec rule for an open and close. For an entry door, that's different and during testing I was being quite fast. Maybe I'm being too rigid in my requirements. Regards |
||
Post 10 IP flag post |
![]() |
steveb private msg quote post Address this user | |
this is my live system, been flawless for 6 months - all I removed was the API key let's see if ninjapost mangles this... first thing to do would be to remove some junk functions and comments - it REALLY hasn't been tidied, as you can see, but hopefully it explains how I handled the string to char problem. I also removed a load of "useless" functions like ip to string This is fairly SRAM light as it uses a large external library as well (ElsterA100C) to count infrared meter reading data and translate it into a reading. -Steve It mangles it - try here: the code hosted on google drive
|
||
Post 11 IP flag post |
![]() |
seckford private msg quote post Address this user | |
I've been running a test program using Python on a laptop as a preliminary to running some ex-Cosm Arduino code, and I'm getting dropouts up to four hours long, typically in the PM (GMT). At the moment I'm trying to work out where the dropouts occur - on the LAN, on the Internet, or within GroveStreams; when I find out more I'll post again. Will |
||
Post 12 IP flag post |
![]() |
seckford private msg quote post Address this user | |
Quote:Originally Posted by seckford In the end the problem was in either the local router, or the ISP connection; nothing to do with GroveStreams at all. Both the Python program and an Arduino version have now run for several days without problems. |
||
Post 13 IP flag post |
![]() |
ctmorrison private msg quote post Address this user | |
Fortunately, in (nearly?) every instance, the problems I've experienced had nothing to do with GroveStreams. | ||
Post 14 IP flag post |
![]() |
fixingthingsguy private msg quote post Address this user | |
Steve_b: Thanks for posting your code. I converted most of the code that was tracking state changes to characters, including use of PGMEM to store the large chunk of constant data in program space. Used strcat liberally. However, for testing the concept I stripped my streams down to 1 from 3. The results are good: -no pac_man effect on SRAM. Stays constant throughout my testing(at 740 bytes). -able to buffer multiple states and batch them to GS. Not hitting the 10sec limit, internally I have set to 10 sec, assuming there is some more time available in transmission,etc. -verified GS receiving them (in the same order naturally). -used &freq parameter to separate the batched data(don't know yet if I can use millis, I thought we had to use epoch, don't know how to do that yet). When I figure that out, the data will correspond to actual times the state change occurred. Next step is to clean up the code so I can present it here! Won't be a lot different than your code. Also will try to put back my additional streams but I'm not optimistic that I'll have enough SRAM. Thanks for inspiring me on. |
||
Post 15 IP flag post |
Pages:
1