Show Posts
Pages: [1] 2 3 ... 47
1  Topics / Home Automation and Networked Objects / Re: Automated Reptile Control System(webserver, Data Logging, RTC and much more) on: March 27, 2014, 10:01:32 am
i would like to make a quick update that the latest version of the code i have posted has been running on my system continuously for 2 months and 17 days (as of this posting) and going strong without a single hiccup.

as long as the system stays running and does not fault on its own (for example, if i loose power, then that is not the project's fault) i will update the post with the new run time to document the stability.

Good to hear it's working well. BTW, I did promise to let you know about some of the relatively minor bugs I found when porting your code. The most significant problem of those was in the input buffering routines -- some of that just wasn't robust (but I get the impression you may have revamped that code anyway.) The other problems I came across were in in the HTML. When I created external html files from your header file to play around with, I ran them through a HTML checker (the well-known "HTML Tidy"), and found a surprising number of issues with things like opening and closing tags out of order, things like that. Interestingly, it didn't seem to make much difference on the actual performance of the code, as you would be aware, as all the browsers seemed to cope OK. There was one instance when I fixed the order of the tags and something broke! But it wasn't a big deal, and I actually forget what it was now -- sorry.

Anyway, all relatively minor stuff, and just a heads up if you ever want to dive into the HTML again, a check tool like HTML TIdy is useful to have. My philosophy is that if the code is as close to text-book as possible when you write it, it should hold up for the foreseeable future no matter how browsers decide to change in how they support any "gray area" stuff.  

Thanks once again wallaceb for sharing your excellent project! Some extra karma points for you. :-)
2  Using Arduino / Networking, Protocols, and Devices / Re: nRF24L01+ PA and LNA with MCP1700/3v3 on: March 25, 2014, 04:16:46 am
I think I should have enough power, as I've put an ampmeter in-line and the most I've seen pulled (when it's working using the 3v3 external supply) was 50-60 mA.

Any ideas what I might be doing wrong?  Something wrong with connecting the MCP1700's?  Something else I'm missing?

Your problem is not the quantity of power available from your supply, but rather the quality.

In short, your power isn't clean enough. You can try adding some additional filtering  (an electrolytic, at least 10uF and maybe more -- up to 470uF, depending on how noisy your power supply is.)

The 1uF caps are consistent with the MCP1700 data sheet, so that should be fine. The 0.1uF across Vcc and Gnd near the module is also a good idea. Just add a nice fat filtering cap to reduce overall ripple and noise and see how that works.
 
Getting the power supply correct for the nRF2401+ modules is often the hardest part. When they are supplied correctly, they peform very well, but they like their power clean, clean, clean.

Let us know how you go.
 
3  Community / Bar Sport / Re: Marketing? on: March 21, 2014, 09:37:59 pm
Seems I usually end up throwing out the TV before I have to change the battery in the remote control.

Seems like there's something wrong right there. How long does a TV set last these days before it gets thrown out?
4  Community / Bar Sport / Re: Normal English phrase embarrassing in the US on: March 21, 2014, 09:36:08 pm
pronounciation, (big word  for the day).

A bit too big, actually!
5  Development / Other Software Development / Re: PSTR() flash string de-duplication -- a problem, a solution, and a question on: March 21, 2014, 10:30:02 am
This fails

That's likely a different issue. This wouldn't work for the "standard" version of PSTR() either, as the initialization of globals can't include calling the PSTR() routines. You'd normally have to use PROGMEM to initialise a global variable, e.g.

PROGMEM char c[] = "this is a flash string";

So I'd guess the asm version would likely suffer the same restrictions.

The potential issue I'm referring to involves code that first has the __COUNTER__ macro expanded as part of the declaration, such as it might be in a template definition, and then that code is copied with the expanded __COUNTER__ value to more than one place (as could conceivably happen with instantiation of a template). That would result in multiple instance of the same PSTR_x label, (x being the value of __COUNTER_ when the preproceesor got to the template definition), which would be fatal for the compilation. (To verify though, have to look at the asm output to see exactly what is being generated, which I haven't done.).
6  Development / Other Software Development / Re: PSTR() flash string de-duplication -- a problem, a solution, and a question on: March 21, 2014, 07:38:42 am
Strange, seems its not the templates fault. A simple object has the same error when you have multiple instances:

It would appear to be a macro expansion problem. __COUNTER__ gets expanded once for the definition, and then in these cases the code with that PSTR_x label gets copied to several places.
 
7  Using Arduino / Networking, Protocols, and Devices / Re: Playing with NRF24L01, not working, need help debugging on: March 21, 2014, 12:48:07 am
hi Pico  , I want to know how to use interrupt pin as  receiving interrupt. pls give idea or a sample code pls.

Starting a new thread for a different topic would be appropriate, I think.
8  Using Arduino / Networking, Protocols, and Devices / Re: Playing with NRF24L01, not working, need help debugging on: March 21, 2014, 12:46:45 am
I was getting late and I gave up for the night with the impression I was going to need a high power module.

Either that, or you may be able to use a central node as a relay to get extra range. Also, if you do get one or more of the high power modules, be aware that you will have to tend even more carefully to power supply issues for them. The low power modules are fussy, but the high power modules even more so. I'd recommend considering getting some LD1117v33 regulators to run them from. NiMH batteries could work, too, but make sure you provide enough in the way of filtering caps (at least 10uF, maybe more, depending).
9  Development / Other Software Development / Re: [MOD] Arduino Enhanced Release 1.0.5 for Windows (installer, drivers, etc) +SRC on: March 19, 2014, 10:10:17 am
Yeah, this might be related with https://github.com/eried/Arduino/issues/13

But, I have an Leonardo now to test now smiley

That's good. While I was in there, I've fixed another nasty and long standing bug that has bothered me for ages (added option immediately after "Verify code after upload"):


10  Community / Bar Sport / Re: Oh My Gawd. Arudino 2600 on: March 18, 2014, 10:16:17 am
Yeah ok, I'll have to mull over that for a couple days.

I could care less.
11  Community / Bar Sport / Re: teaching debugging on: March 18, 2014, 10:15:26 am
Yep, debugging IS programming, if you can't do one you can't do the other.

If only this were true. In that case, there would certainly be a lot less buggy code about.

12  Community / Bar Sport / Re: whats with the attitude on: March 18, 2014, 09:28:31 am
now don't anyone call me an insect...

I think using "entomology" when you mean "etymology" can be classified as a bug, technically.
13  Development / Other Software Development / Re: [MOD] Arduino Enhanced Release 1.0.5 for Windows (installer, drivers, etc) +SRC on: March 18, 2014, 06:25:00 am
Thanks a lot smiley I just added that code from a forgotten suggestion to the official one smiley-grin but certainly I will update that.

I've just found another bug! (The conservation of bugs principle at work.) The ERW 1.0.5 IDE serial monitor does not seem to work for Leonardo. Try running the "ASCII Table" demo sketch for example to see the problem... Serial.print() output does not show in the monitor.

This is true whether the "open the serial window automatically..." option is selected or not.

OTOH, Leonardo output seems to work properly in "official" IDE 1.0.5.
14  Development / Other Software Development / Re: [MOD] Arduino Enhanced Release 1.0.5 for Windows (installer, drivers, etc) +SRC on: March 18, 2014, 01:51:05 am

Thanks for the link. I found and fixed that build size bug we discussed, The problem was you were reporting the size of the build as the size of the .text section from the .elf output, when the size of the build is actually the size of the .text section + the size of the .data section.

So, in Sizer.java, I changed

Code:
size+=checkTag(s," .text ");
data+=checkTag(s," .data ");
data+=checkTag(s," .bss ");

to

Code:
        int d = checkTag(s," .data ");
        size+=d;
        data+=d;
size+=checkTag(s," .text ");
data+=checkTag(s," .bss ");

and that fixed it.

15  Using Arduino / Networking, Protocols, and Devices / Re: Playing with NRF24L01, not working, need help debugging on: March 13, 2014, 09:42:07 am
people assume the limited range and general performance they see are down to the limitations of the modules, rather than the fact they aren't operating anywhere near their potential.

So could I still be in that situation, do you think?

I don't think so -- what you are getting sounds like normal range for a good setup. With a bad setup, I doubt you'd be doing anywhere near as well.

250kbps *might* do the trick to get enough extra range... but it may be that you will need to upgrade to at least one higher power module, maybe two.

So, upgrading just one of a pair to higher power should give some range improvements, even if the other is low power? That's handy to know. I suppose if the more expensive module has a more sensitive receiver circuit as well as a higher power transmit circuit, it must be able to make up for the weaker transmit power of the cheaper module, to a degree.

You got it. :-)

Thanks again pico (Mark, is it?)

Now, what's the point of having a forum handle if everyone just goes around using your real name? Sheesh!

;-)
Pages: [1] 2 3 ... 47