Show Posts
Pages: [1] 2 3 ... 9
1  Development / Other Hardware Development / Re: Mosquino rev2, micropower / energy harvesting Arduino variant - feedback wanted! on: October 20, 2012, 05:26:21 pm
Hopefully it isn't necessary to scrap the board... with the schematic open you can probably trace power from the USB port down to Vcc and narrow down the source of the problem. E.g. is there ~5V on both the upstream and downstream side of fuse F1? (It will have high resistance if tripped, causing the downstream voltage to sag.) Does it change when the power switch is turned on/off? (suggesting the issue is downstream of the power switch, on Vcc)

(Note the FT232 and Tx/Rx LEDs  are powered directly from VUSB, so they will still blink if the power switch is off - this has gotten me before!)

2  Development / Other Hardware Development / Re: Mosquino rev2, micropower / energy harvesting Arduino variant - feedback wanted! on: October 12, 2012, 11:05:58 pm
You're right, that part is tricky to solder. This is good feedback - I don't always notice because I've been doing it for so long :p

Probing the crystal shouldn't damage anything, but depending on the probe capacitance it may stop oscillating as soon as the probe is applied, so seeing a 'flatline' would not necessarily mean it was dead (if working, it would come back when power-cycled or maybe just left alone for a bit). I've been able to probe this and see it running (YMMV), but I've also seen probing stop similar watch-crystal circuits.

What I find helpful to solder parts like this is to place it off the pads slightly (e.g. toward the DS1337 or toward R16) so that there is enough pad peeking out to get the iron tip onto. More specifically, I place a bit of solder on ONE pad, heat it with the iron top and while it is liquid, slide the part into place ("mostly" or halfway onto the pads, if the iron tip isn't very small). This guarantees at least one side is soldered, then, solder added to the 2nd pad should flow underneath the part and produce a solid connection there too.
3  Development / Other Hardware Development / Re: Mosquino rev2, micropower / energy harvesting Arduino variant - feedback wanted! on: June 03, 2012, 01:10:54 pm
You built the current Mosquino version? Cool!

Did you run into any trouble with assembly? I tried to keep it as easily hand-solderable as possible (no parts smaller than 0805 / SOIC, with the exception of that USB chip there's just no good way around at the hobbyist level) but I'm wondering if there's anything else I can do to make it easier.

I'm not familiar with AVRISP - so far I've only burned bootloaders on using another Arduino via the 'ArduinoISP' sketch, and it's been mostly smooth sailing. What is the message that you get?

Some things to check:

Is the power switch on? (Silly, but I have to ask - I've tried to program it while powered off myself)

Does the crystal attached to the ATMega start up? (This may be hard to check without a scope - but they ship with the *internal* oscillator selected, so it shouldn't matter unless this chip has been successfully programmed at least once, and set to use the external crystal)

Is the RESET line (if any) from the programmer connected? On older versions of the mainboard, there wasn't a spot to connect it, so you'd have to e.g. touch it against a pin on the ATmega. In newer versions there is a RESET pin header near the reset switch.

Hope this helps!
4  Using Arduino / Networking, Protocols, and Devices / Re: Ant + protocol on: May 09, 2012, 08:33:30 pm
I have played with ANT a bit for my forthcoming micropower-Arduino project. I posted some very quick & dirty interface code here and an EAGLE breakout board for the pre-assembled modules, but got busy with some other stuff and haven't got around to making it into a library yet. That code does work though :-)

If you don't want to decode it on the device end, there is source code around for PC clients (such as libfitbit) that can probably serve as a starting point to interfacing a specific device. If you have a specific device in mind, check around in case someone has already done the work to reverse-engineer its protocol; may save you a lot of time!

So far I have only used ANT radios to talk between my own microcontroller boards (or microcontroller board to ANT USB radio stick); I haven't tried talking to an ANT+ (or any other 3rd-party) gadget. I also haven't looked much at the "+" standards, but I remember them being pretty well-defined for the published ANT+ profiles. If you can, dig up documentation for ".FIT file format" and "ANT-FS"; two related standards a given ANT+ device might use. You might have to sign up an account on their Web site or buy a development kit (or use google-fu...) to download those standards though.

As implied by the "not-quite-a-standard" rhetoric, if the device does not conform to one of the published ANT+ profiles (of which there are just a handful), including having vendor-defined fields you want to access, you will probably have to do some amount of device-specific coding for the particular ANT+ (sport, etc.) device you want to talk to. I don't know the rules on what gets to be marked as an "ANT+" device, but my understanding is that the data for any *published* profile device will be accessible by any ANT receiver using the 8-byte key defined by the profile. (Some ANT (non-"+") devices are on so-called private networks; to get anything from them you have to know - or reverse engineer - a *secret* 8-byte key. Fortunately these keys are a somewhat poorly-kept secret (google is your friend) for most of the well-known manufacturers, and many of those devices' protocols are reverse-engineered already.)
5  Using Arduino / Project Guidance / Re: Power saving in code for extended battery life. on: May 04, 2012, 12:32:42 am
Looks like people have beat me to all of the good answers ;-)

I was under the impression that running from a 9v and regulating it to 5v would produce a longer life as there is 5v it can drop whereas if i used a 6v hooked up without regulation there is only 2v to drop before its considered flat.

There is some truth to that (the discharge curve of alkalines is anything but flat), but also consider what a "9V" battery actually is: if you saw one open, it is 6 "AAA" cells (actually something much smaller) wired in series! So the internal resistance is higher, and a lot of the space in the battery is wasted (round cells in a square case), so the capacity (mAh rating) per $ and per volume is not great. You may get much better runtime from 4 "AA" (or larger if you have room) cells in series, even if the voltage "headroom" is less.

will a low voltage cut off draw more power? im not sure that it is entirely necessary, i have discovered already that with flat batteries the PIR trips constantly, so i will have a pretty good idea when the batteries run down.

In general a low-battery cutoff will draw "some" extra ("some" may not be enough to worry about; there are very efficient circuits/ICs for this nowadays), but it sounds like you wouldn't need it anyway :-)

any thoughts on the TDA3664? ive fond them on ebay and am waiting to hear before i buy some.

Here is the datasheet for TDA3664 - looks good! Some lesser leakage ones exist (I am partial to Microchip's MCP170x family, but not sure if you have easy access to those) but 15uA is pretty respectable. And sometimes "available" is the most important spec of all!
6  Using Arduino / Project Guidance / Re: Power saving in code for extended battery life. on: May 02, 2012, 01:47:02 pm
Which Arduino board are you using?

Putting the CPU to sleep between activities will save a little power (a few mA), but on many of the official Arduino boards (e.g. Duemilanove, Uno, Mega etc.), onboard features like the power LED and USB interface (powered all the time) are what eat up most of the power. Going to something like a BareBones (USB programming interface is a separate board and only plugged in when needed) will save a lot. Once these big guzzlers are taken care of, battery power savings from sleeping the CPU will be worth your attention :-) A more efficient voltage regulator would help too.

I am working on a low-power Arduino board called Mosquino (basically done, just a few software tweaks needed here and there) that integrates several 'easy' low-power tricks - no power LED, USB stuff unpowered when cable disconnected, low-leakage regulator, and a realtime clock to get the best use of the CPU deep sleep mode. Together this gets the sleep power consumption down to a few uA.

A handful of other things - I don't know whether or not the PIR module you are using has "smarts" builtin to detect motion (and so might need to be powered all the time to work). If not - if it draws less than about 20mA you may be able to power it directly from an I/O pin, sample it periodically (every second or two) and cut the power to it between measurements. Same for an ambient light sensor - assuming the sun does not rise or set too quickly ;-) you might only have to check this once per few minutes before deciding to use the PIR or not, and sleep in between. You can use one of the libraries using the watchdog timer trick mentioned above (rocketscream's Lightweight Low Power Arduino Library is another). But, if you don't mind Yet Another Chip, an external realtime clock (where you can set an alarm for any time in the future) will let you save more power by turning off the watchdog timer too (about 20uA difference in my tests).
7  Development / Other Hardware Development / Re: Making a Hardware Profile for Arduino on: May 01, 2012, 04:08:53 pm
I went through this process recently for my own custom Arduino-based board, and similarly couldn't find much real documentation on the subject. If all you are changing is DIGITAL pin numbers and bootloader stuff, there are only a couple files to modify. If you need to change other things for your board, like the CPU speed (other than a couple Arduino 'standards' e.g. 8, 16 or 20MHz) or analog pin numbers, it's a bit more work.

This page has an overview of the process, but it's a bit out of date.

For a basic variant, make a copy of the Arduino core folder (installed in a subfolder where your Arduino IDE is located e.g. arduino_IDE_folder\hardware\arduino), rename the folder to the name of your project, and move it to the 'Hardware' directory inside your personal Sketch folder (for Windows, this is usually something like C:\Documents and settings\yourname\My Documents\Arduino\hardware or C:\Users\yourname\Documents\Arduino\hardware) . Note, it is also possible to patch your board directly into the copy where the Arduino IDE is located, but there it risks being overwritten when a new IDE/core version is installed.

Go to your renamed copy. Inside here are two text files, "boards.txt" and "programmers.txt", and a handful of subfolders containing the core itself, bootloader files and pin mappings. MOST of the changes you need are in boards.txt. It contains a bunch of lines like:

Code: = Arduino Someboard w/ ATMega 168
someboard.someparameter = ...

Follow the instructions of the link above to change these as needed, e.g. with the correct name/baudrate/programmer for your bootloader, CPU speed, etc. As of 1.0, board-specific pin map data is stored in the 'variants' subfolder; in the example above the 'someboard' board would have its pin map in \variants\someboard\pins_arduino.h. Modify the pin mappings as needed for your board. Modify/replace the contents of the 'bootloaders' folder with your own bootloader files.

Assuming all went well ,when you close and re-open the Arduino IDE, your newly defined board should be listed.

If your board's differences go beyond digital pin mappings...
When doing this for my project, I wrote up a wiki page showing the locations of board-specific settings that I've found so far in the 1.0 and pre-1.0 cores. MOST of the changes will be centered in pins_arduino.h, but there are a few things like hard-coded CPU speeds (for e.g. delayMicroseconds()) and analog pin numbers scattered around the core.

8  Using Arduino / Programming Questions / digitalPinToPCICR() and other pin-change interrupt macros on: May 01, 2012, 09:31:04 am
When patching my Arduino-based project up to 1.0, I noticed a pile of macros pertaining to resolving pin-change interrupt port and bit values from Arduino pin numbers. But, this does not appear to be used anywhere (at least in the core). Does their inclusion hint that there is now official pin-change interrupt support in 1.0, similar to the PcInt library in the playground?

(If not, what's it for? These macros seem to largely duplicate the function of e.g. digitalPinToPort() and digitalPinToBitMask() (see the PCInt library above for an example of usage this way).)
9  Development / Suggestions for the Arduino Project / Re: INT2 pin verboten? (Arduino core) on: April 06, 2012, 04:00:00 pm
Problem description and updated files here :-)
10  Development / Suggestions for the Arduino Project / Re: INT2 pin verboten? (Arduino core) on: April 05, 2012, 09:34:56 pm
...on further inspection, the current repository version is still missing support for detachInterrupt() on INT2. Neither will it detect the '644p/a as having a 3rd interrupt pin. Maybe I'll try submitting a patch?
11  Development / Suggestions for the Arduino Project / Re: INT2 pin verboten? (Arduino core) on: April 05, 2012, 09:09:44 pm
Are you using the version straight from the repository?

Based on your reply I just dug for it (to link to and show how the INT2 support has been removed since 0022)... only to find the Github version has it again! The repository version is almost byte-for-byte identical to what I re-wrote into the release version last night :-/ (downloaded a few days ago). Just how stale is the release version on the Arduino homepage, anyway?
12  Development / Suggestions for the Arduino Project / INT2 pin verboten? (Arduino core) on: April 05, 2012, 12:23:16 am
Continuing porting the Mosquino project (ATmega644pa) to the 1.0 core, I finally decided to chase down the INT2 pin issue that's been bothering me since 0022. Lo and behold... only INT0 and INT1 are handled, or even allowed, in WInterrupts.c.

In fact, it looks like somebody went to some length to remove all support for INT2 for the non-ginormous chips (e.g. #define EXTERNAL_NUM_INTERRUPTS 2 in wiring_private.h). Based on the trouble gone to, I assume this was done for some kind of important reason. Does anyone have a clue what that reason is/was?

Does use of the INT2 pin break horribly on some old Arduino board / AVR flavor (chip erratum) / avr-gcc version?
Was a lead developer hurting for a couple bytes Flash/RAM and decided 2 interrupts were enough?
Could it really have just been an oversight after all?

I have re-added it and it seems to work fine on my board, but I'm curious if I'm undoing someone's significant research and some bizarre issue will come to bite later.

13  Using Arduino / Installation & Troubleshooting / Re: "Invalid device signature" (0x000000) since Arduino 1.0; works in 0022 on: April 02, 2012, 10:49:54 am
I understand it's just hearsay, but this sounds plausible. What you're saying is most likely this is an issue with avrdude itself...i.e. that the official STK500v1 protocol has supported the "universal command" always, but older versions of avrdude didn't make use of it until now (causing problems since the Arduino "STK500" serial bootloaders don't support it). Is the 'arduino' entry then some "STK500-like" protocol definition (that all Arduino projects should have been using all along) that forces the non-use of the "universal" commands?

David Mellis himself (*genuflection*) posted the fix in the thread linked above, so I've replied there in case he's still watching that thread and can give the answer definitively. Figuring he knows a thing or two ;-)
14  Using Arduino / Installation & Troubleshooting / Re: Arduino mini "yikes invalid device signature arduino mini avrdude" for blink on: April 02, 2012, 10:37:27 am
I also ran into this same problem when porting my own Arduino-derived project (Sanguino-based) from 0022 to 1.0 (same board = works in 0022, "Invalid device signature 0x000000" in 1.0), and the solution above seems to work for me.

@mellis, if you still happen to be watching this thread :-) - do you have any additional information as to why this works, what changed or what the underlying problem was/is? I'm hesitant to start distributing what seems like a "voodoo fix" with the project without any understanding of the underlying problem, or whether these ("stk500"/"arduino") definitions will flip again in 1.0001, etc. (@Coding Badly has a possible explanation in the thread linked above, but it's just a guess so far.)

15  Using Arduino / Installation & Troubleshooting / "Invalid device signature" (0x000000) since Arduino 1.0; works in 0022 on: April 01, 2012, 11:32:46 pm
I am (finally) patching my Arduino-derived project up to 1.0 and ran into an oddity; it seems 1.0 (or the version of avrdude that comes with it?) no longer recognizes the Arduino serial (Duemilanove and earlier) bootloader's protocol (stk500), or at least has altered its implementation in such a way that it no longer recognizes the chip. The Mosquino (Sanguino-based) board uses an ATmega644pa with the Sanguino's 'adaboot' bootloader. Its boards.txt file specifies the upload protocol as follows:


Randomly changing this from 'stk500' to 'arduino' (as mentioned in this thread) gets it working again, but for a published project, I'm wary of relying on what seems to be a 'voodoo' fix without understanding how or why it works, or what the problem was in the first place. Does anyone know more about this - e.g. is the underlying problem/solution/change documented anywhere, and is this a 'stable' fix that I can safely push out? What actually changed?

Thanks in advance!

More info:
With Arduino IDE versions up through 0022, uploading a sketch proceeds normally. Abridged verbose output:

avrdude: Version 5.4-arduino, compiled on Oct 11 2007 at 19:12:32
         Copyright (c) 2000-2005 Brian Dean,

         System wide configuration file is "J:\arduino-0022\hardware/tools/avr/etc/avrdude.conf"

         Using Port            : \\.\COM18
         Using Programmer      : stk500v1
         Overriding Baud Rate  : 19200
avrdude: AVR device initialized and ready to accept instructions

Reading | avrdude: Send: u [75]   [20]
avrdude: Recv:
################################################## | 100% 0.02s

avrdude: Device signature = 0x1e960a

But with 1.0, upload produces:
avrdude: Version 5.11, compiled on Sep  2 2011 at 19:38:36
         Copyright (c) 2000-2005 Brian Dean,
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "J:\arduino-1.0\hardware/tools/avr/etc/avrdude.conf"

         Using Port                    : \\.\COM18
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
avrdude: AVR device initialized and ready to accept instructions

Reading | avrdude: Send: V [56] 0 [30] . [00] . [00] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
avrdude: Send: V [56] 0 [30] . [00] . [01] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
################avrdude: Send: V [56] 0 [30] . [00] . [02] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
################################## | 100% 0.05s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.

It seems to use a different method to read the signature(?).

Pages: [1] 2 3 ... 9