"even if they don't want to work for me. "

Once we figure out whats different we will do our best to implement some type of workaround. I discussed this with CisecoDev earlier today, he and I agree we think the reset doesn't seem to happen in the right place and having never seen such a thing before wonder if it being a mac has a bearing on things.

Why do people buy macs and use linux, what wrong with windows

hehehehehehehe

Miles wrote:


At this point, if you told me that doing a 3 hour long interpretative dance expressing how I imagined a rural station master felt about the brutal reduction of our National railway infrastructure under Dr Beeching would make OTA programming work, I'd say yes.

I'll send both of my modules back to the address I used before, and I'll drop you a line via email to confirm when I sent them.

We have been trying more OTAMP today on windows, all was good (well as good as the loader can do - 70-80% success) I hope Matt is reading this, perhaps he's tried it on the mac?

Just been told it was around 85% sucess, this was using a v1.5 and v0.48 firmware on a gateway (re shaped arduino) and a URF to an UNO chip @ 115K. The sketch was just a small LED blinky thing.

"upgrade" to windoze

I was already thinking about having a play around with all this tonight.
Now firmly on my todo list

Miles wrote:


what kind ? I can run XP under virtualbox, but I can hunt down a win7 license if you think that would help...

PS 85% sounds more than good enough for me. Bring it on.

OK so after a lot of testing here is what i have

Kit breakdown
URF v0.2
0.25B

XRF v1.5
0.47B
5v safe

2x XRF v1.4
v2bootloader
0.41
3.3v only

UNO smd with XBS005 shield
optiboot loader (115200baud)
5v

OpenKnotrol Gateway
328 old boot laoder (57600baud)
later tested with optiboot (115200baud)
3.3v

All AT configs default before testing as follows

For speed these setting were confirmed using XCM on windows
but all later changes were applied using AT commands via coolterm on OSX lion

Test details
XRF > XRF test done with an ebay USB xbee explorer (ftdi)
URF > XRF test did not need the ftdi
I only have 1 v1.5 XRF to hand so could not test 1.5 > 1.5
sketch's to uplaod, blink.ino (~1026bytes) and pinata.ino (~6600bytes)
blink for the OKG was changed to pin A3
ArduinoISP on the freeduino was used to upgrade the OKG bootloader to optiboot
range was ~7m and one brick wall for most
at least 3 suscesful uploaded's in each configurtion

remote XRF settings as OTAMP guide



local XRF setting as OTAMP guide
note URF does not support ATBD as its automaticly configuered on connect



Test Config's

• URF > 1.4 > OKG old loader pass
• URF > 1.5 > OKG old laoder pass
• 1.4 > 1.5 > OKG old loader pass
• 1.5 > 1.4 > OKG old loader pass
• 1.4 > 1.4 > OKG old loader pass
• URF > 1.4 > OKG optiboot pass
• URF > 1.5 > OKG optiboot pass
• 1.4 > 1.5 > OKG optiboot pass
• 1.5 > 1.4 > OKG optiboot pass
• 1.4 > 1.4 > OKG optiboot pass
• URF > 1.4 > XBS005-uno smd optiboot pass
• URF > 1.5 > XBS005-uno smd optiboot pass
• 1.4 > 1.5 > XBS005-uno smd optiboot pass
• 1.5 > 1.4 > XBS005-uno smd optiboot pass
• 1.4 > 1.4 > XBS005-uno smd optiboot pass

Results
First test with URF>1.4 were intresring results
First attemted to upload blink worked a treat, but after that sync errors, restarted Arduino1.0 and repluging urf produced same result
I saw simlar result with 1.4>1.4, again first upload ok but then nothing, i could see it revicing the reset (LED on gateway TX flashed) but still had sync error
I removed the ATRC 3 from my setup (ATRC0) since removeing the channel hope i've had much better result's in the URF>1.4 and 1.4>1.4 test

OK so after removing chanenel hope I got good results, i did least 5 suscesful uploaded's in each configurtion
there is still the odd uplaod error but its a protocol issue not the initial sync, so suspect onair collisions
URF > 1.5 > UNO and 1.4 > 15 > UNO did give me some trouble at first untill i reseated the XRF, and power cycled it

Just to comfirm I then went back and tested again with channel hope.
This time I use ATRC 2 and test's were URF > 1.5 & 1.4 > 1.5
Yet again they failed, so I'm kicking this issue back to CisecoDev
Im not sure how it's implmented but I suspect the reset should cause a channel hope at both ends but is failing to do so at one end right now.

So OTAMP works from OSX with Arduino 1.0, even did a quick test with 0022.
However ATRC seems to be need a fix

Thank you for spending so much time looking into this for me.

Blimey o'reiley that's a a test and a half, huge thanks from this end also. We will look to recreate channel hop and see what we can find with the debugger.

Hi Guys,

I am having the same difficulty. I have just received my XRF units (damn it was quick!) and I see that the reset is being sent (my arduino resets after I click the program button) but it seems as though the reset is sent through too early. I can manually trigger the reset on the arduino at the right time and it works fine but not over the wireless.

As I said, it is definitely doing the reset but not at the right time (it occurs much earlier than I would expect it to happen).

Arduino 1.0
OSX
Latest 0.56B firmware
Arduino Pro


Any help?

It's sounds a lot like the behaviour I was seeing when I used the ATRC channel hop,
Check and set ATRC at both ends to 0
Also double check which boot loader u have I think the arduino pro's use the older loader (not optiboot) and so speed will be 57600 baud

Matt

out of interest, how do you have the XRF hooked up to the Arduino ? I'm using XBBO's and for some reason I get the reset directly from the XRF pin, but not from the 5 pin connector on the XBBO. Wondered if you have the same issue.

FWIW I've gotten it to work once. But I'm not ready to give up yet.....

Sounds so close now, dont worry we'll get there by hook or by crook. The fact it resets and that it will program as you say means its just timing when to do the reset.

Dare I say this.........

Have you got a windows machine to try

I do have a Windows Virtual Machine so I downloaded Arduino 1.0 for that and tried it...

Instead I got a not-in-sync error. The arduino still reset but clearly not at the right time.

avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Recv:
avrdude: stk500_getsync(): not in sync: resp=0x00


I also tried changing the ATRC both to 0 (and of course writing it before anyone asks) and it made no difference.

avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

Do you get the LED dribble/flash to indicate a reset on 13 way before the three attempts?