Having discused this, we have a useful idea. Pin 12 is normally low, however at remote reset it will do a 3ms high, so if you connect an LED between here and GND, you should see a very brief flash at the same point as pin 17 goes low.

I hope you are sitting down, because I can now program my Arduino over the air. F*&KING FINALLY I honestly thought this day would never come.

The solution -

1.I built the circuit I posted earlier today on some protoboard, and I am now getting a reliable reset every time. Yay. (Maybe the design of the XBBO needs to be tweaked ?)

2. Running WinXP under Virtualbox, I installed earlier versions of the Arduino IDE - 0022 and 0023.

Using both these IDE's I was successfully able to upload code. Moved back to the 1.0 IDE and the upload failed again. I'm off to see if I can install multiple versions of the IDE on OSX and do more tests.

Something obviously changed when the IDE went v1.0, if we can track it down we may be onto a winner.

FIREWORK PARTY

What fabulous news, I'm curoius which generation of mega is it? I want to go looking at the schematic. The FET giving a potentially stronger pull down is something I'd like to understand, we expect the I/O on the CC1110 to be more than man enough for the job.

Its is an Official Arduino Mega 2560 R3. It is also working on a cheap ebay clone from China of a Mega 2560 R2 (although it is less reliable than the official one. I think it has a different interface chip)

I can also test an Official Uno R2 if you want (had an R3, but there was a mixup at the hackspace) also a Nano 3.0 clone. Happy to do whatever testing you like, and as I said will have access to a fancy digital scope thingy on Thursday.

I've been doing this for my lightpainting stick, and in an ironic smack to the face, on of the LED's in the strip has failed. Right in the middle. What god/our new alien lords and masters giveth.....

PS For the record, I've taken the ground feed for my circuit right from the adruino, if that makes any difference.

I've had OTAMP running well on an R3 UNO, so I went a digging.

The schematic for the mega has a 10K pullup but also a diode and 22pf which I've never seen before. I'd be tempted to connect XRF pin 17 to the micro side of the reset switch or what looks like pin 3 on the power header (i assume thats where you connected the FET also).

You mentioned 0022/0023 vs 1, was this all on virtual windoze?

Miles wrote:


Yes - Win XP SP2 under Virtualbox 4.12 on an OSX 10.6.8 host.

To install multiple version on OSX just rename the app.

I have a bunch more test in mind based around the board I have access to and some schematics for ones I do not.
Given enuff logic traces and research I should find out exactly what's going on.

Unfortunatly I'm not able to start any more till monday night.

Miles wrote:


It doesn't work on my Mac or PC. so this tells me that something is amiss with the remote reset since I can do it manually.

Miles wrote:

Is this pin 12 on the host or remote end? If on the remote end I could wire that up through the existing transistor reset circuit which happens to be exactly what was posted earlier today.

I answered my own question. I see that pin12 is asserted on the receiving end.

I tried wiring it up to the existing reset circuit on the board (which goes through NPN transistor to pull rest line low), it resets but still no program. Still this looked to be too early (much earlier than I would be successfully doing it manually).

If you are correct that the reset is too early then there are only two explanations. Either the XRF modules have developed prescience and are anticipating the reset signal, or your setup is asserting the reset signal early.
I do hope it is the first explanation, I could get rich on that.

@edak - I think it is worth clarifying what is going on and why, now that you accept a reset is being sent and actioned at the other end by your LCD reseting and seeing pin 12 go high, I think we can conclude the obstacle isn't there.

The PC connected XRF first, when the state of pin 16 changes it sends a message to the remote (arduino) connected one to pull pin 17 low for 3ms. There's no interaction with anything else than that change, it has no awareness of the loader. You can test this by wibbling pin16 pin PC end manually and see it happen in tandem at the other end. There is no way on earth it can do this early.

So first question - is the XRF responsible for a difference in timing to make things "earlier"? no, it cannot be

Second question - if the reset cannot be early, then could it be that the loader is later ? more probable

Third question - If the loader is later, why is this? this is probably the million dollar question and what changed between IDE 0022/23 and 1 that Dave is seeing. Is there some exchange between pc and duino that isn't happening, does this perhaps cause a timeout which delays the loader, such that the time between reset and the loader starting is longer, but also could appear that the reset happens earlier, perhaps yes

Forth question - You stated "It doesn't work on my Mac or PC. so this tells me that something is amiss with the remote reset since I can do it manually." lets examine, you now know remote reset works just that the timing is wrong, as we do nothing to affect the timing then we can conclude "its the process" thats not right.

Conclusion - Help us to help you, accept we do nothing to affect timing and lets together figure out what in "the process" is happening differently in your environment to other peoples and if we can find a solution or workaround.

A question or two (sorry if any are repeats), the seed USB adapter, is pin 16 connected to CTS or DTR on the FTDI? What version of IDE are you running? What flavour of Mac OS is it.

A different approach perhaps, pop the seed in the post we'll get it working here (if we can) and send it you back.

hehehehe john, I see your point, clairvoyant XRF's would be so cool......predicting the lottery or horse races, we'd be rich!

One interesting thing I did see on the OSX logic traces was it actually sent a double rest before it started trying to talk to the bootloader, you can see to down spikes on the remote rst line of the trace i sent earlier.

Yet on a Windows trace it only reset once. i need to tie these up with some debug output from avrdude to see why but don't have the time of kit with me today.

Also form the trace i posted the pin16 of the sender was pulled low for 6ms, and the XRF produced a 3ms low on pin 17, this caused the TX line of the atmega to go instantly low, which suggest it caused an instant reset.

As i said i have more test planed but no time till monday.

So after all that I have finally reached the point where my project is complete - the reason I started on this over 2 months ago. I want to thank everyone who has spent time on this problem - a really nice community is building here, and I hope I can use my experience to help others.

My project is a lightpainting stick, and I took my first shots with the help of some of the people at the Hackspace. I think it was worth the effort.

http://www.flickr.com/photos/cancelmonday/7218344140/

PS I must have bad luck - as soon as I got the OTA working, 1 of the LED's on the strip failed. I grafted a new one on, and then the battery broke.......