PICAXE handling GPS for robot boat

MartinM57

Moderator
Agree with Hippy...there's no reason to believe that...

hi2csetup i2cmaster, $43, i2cslow, i2cbyte
hi2cout 0, ($41 ,"A")
hi2cin 0, (b1, b0)

...would work at all from reading the data sheet, but there are allegedly two projects out there that are working with this compass.

hi2cout 0, ($41 ,"A") is the same as hi2cout 0, ("A" ,"A") and there seems no reason to send either the address as 0 or two "A"s

hi2cin 0, (b1, b0) sends an intervening address value (of 0) before receiving the the heading bytes, which doesn't seem to correspond to the data sheet

Hippy/I/others would just jump in with our Saleae's and try to work out what's going on electrically - the $FF byte is usually symptomatic of bad i2c wiring, but I've no idea where the $43 (= "C") is coming from

Tricky...don't really know what to suggest...you could try carefully to read the EEPROM values to see if you can get sensible/meaningful numbers back from the individual bytes e.g. they're not all coming back as $FF as well
 

hippy

Technical Support
Staff member
I've no idea where the $43 (= "C") is coming from
It seems the PICmicro hardware puts the device address into the I2C SSPBUF data register for sending ( $42 with read bit set = $43 ), if the transaction then fails, and nothing comes back, when the PICAXE reads the data register for the expected returned data SSPPBUF has not been overwritten so it actually reads what was previously sent which is the device address plus read bit, that $43.

I recall similar behaviour reported before on the forum. It reveals something is not working right and it shows that no read data transaction completed but does not explain why not. A logic analyser will show what actually happened on the bus.
 

MartinM57

Moderator
Makes sense - $43 (should have twigged it's the device address for a read, not a "C") from the internal PIC register and $FF from the bus...the latter normally occurring when the bus operation/wiring is incorrect/the slave device is not pulling down the bus/the pull up resistors are causing the data to be read as all '1's (=$FF)

...minimal hardware on a breadboard - just the PICAXE, minimum operating circuit, 2x pull up resistors and the compass?
...Try reading the compass EEPROM for sensible values?
...Try an i2c EEPROM as a controlled test - lots of code around for them?
...Get a logic analyser/scope on the bus?
 

hippy

Technical Support
Staff member
@ Robin : Try your code for post #279 but use $13 as the device address, that is -

hi2csetup i2cmaster, $13, i2cslow, i2cbyte

What result does that deliver ?

My expectation would be 65535 ( b1=255, b0=255 ) or 5119 ( b1=19, b0=255 ).

If 65535 it would be behaving differently when addressing the compass which exists to when addressing a device which does not exist, which would suggest the compass is ACKing the device address, the non-existant device is not.

If 5119 it is behaving the same whether the device exists or not, probably the same lack of ACK in both cases. That suggests a wiring issue or the compass actually being at a different I2C address. The later is possible because the address is programmable and the compass EEPROM may have been inadvertently written to.

Testing with an I2C EEPROM would help confirm behaviour which seems to be the next step.
 

Robin Lovelock

Senior Member
Thanks Hippy. Your software idea first: YES - I then get 5119 back if we use $13 in setup call.

Now what I did earlier, prompted by the earlier posts: shorted both 330R - same result of 17407.
Then I wired directly to pins 5 and 6, assuming I may have wrongly traced the wiring in the very early posts: same 17407 result. If I look at the AXE024 board at the back, with the jack at the top (as is the indent on the chip) then I have pins 5 and 6 as being on the low left corner, furthest from the servo pins - now only used for power. Pin 5 being lowest, and connected to SDA on the Compass chip. SCL goes direct to Pin 6. Both have 10k pull up resistors still.

On questions of how much time do I have budgeted for this: not enough to include trying something other than an AXE024 on the off chance it might work or give some clues :) I was hoping it would have been minutes to have got a simple test program working like that below, to prove that the AXE024 I2C will work with the HMC6352. It's still worth a good few hours work over the coming days, especially with the help of you guys :)

I'm assuming, based on past experience like mixing of RS232 GPS SERINs and SERVO output, that, after we get that simple test program to work, other things will "jump out to bite us" like restrictions or bugs in the picaxe firmware - or more basic restrictions such as use of pins for other things. But one step at a time: let's get this working first - if it can work ! :)

I very much value your help on this, as I have in the past. The supplier of the HMC6352 got back to me, and asked me for the AXE024 data sheet. I'll not embarras him by saying more here, but we obviously have the situation that PICAXE I2C guys (assuming they are available) will probably not have access to an HMC6352, in the same way as those with HMC6352 may not be familiar with PICAXE. I guess I might be able to arrange for an HMC6352 to be supplied to the PICAXE company - if there is expertise available on the I2C implementation: hopefully the software engineer who did it, is still available.

Meanwhile, I'm guessing I've made some wiring mistake somewhere, or the PICAXE I2C is not able to support the HMC6352. But, it seems that we still may have some chance of getting it working, after getting the wiring right - if it is not already, then finding the correct statements to use from all those possible variations :)
Robin
www.gpss.co.uk/rbdesign.htm - now a footnote and link to this thread where it talks about Compass at bottom of page.

Code:
'COMPASS.BAS test for HMC6352 Compass Module with PICAXE AXE024 Servo Controller
 hi2csetup i2cmaster, $13, i2cslow, i2cbyte 'Hippy test
top:
 w0=123 'to confirm w0 is changed by READI2C 
 hi2cout 0, ($41 ,"A")
 PAUSE 10
 hi2cin 0, (b1, b0) 'w0 should now hold binary Heading 0-3590 tenths of degrees
 SERTXD ( "  H=",#w0 ) 'e.g. H=17407 (b1=67 b0=255) - GIVES 5119 due to $13
 PAUSE 100
 goto top
 

Armp

Senior Member
To read the compass the master needs to send Start : $43 : get 2 bytes :Stop

I have worked with this module before on another platform. Maybe you can check that hi2cin (b1, b0) does not do a write before read if the location parameter is omitted, and does allow clock stretching by the slave?

I'll be happy to do the tests if the OP wants to donate a module...
 

hippy

Technical Support
Staff member
Thanks Hippy. Your software idea first: YES - I then get 5119 back if we use $13 in setup call.
It looks like the priority is to try an I2C EEPROM. If that does not work then nothing else will.

Your AXE024 wiring sounds correct, noting it's looked at from the back of a board, but it may be better to build the circuit on breadboard or use an AXE091.

Perhaps post photos of how you have things wired up then others can double-check those.
 

Robin Lovelock

Senior Member
Thanks Hippy. I'll continue to try ideas, prompted by comments on this forum. e.g. I just tried a DELAY 1000 before and after the I2CWRITE but with same result.

The supplier has kindly suggested I send him the HMC6352 module, so they can at least check it out, including - I assume - that the factory default settings in it's EPROM are still OK. I've offered to send him the PICAXE AXE024 wired into it, on the outside chance that they have the time to look into PICAXE-HMC6352 I2C themselves.

I'm interested to know more about what engineering resources are behind PICAXE and/or Tech Supplies/Revolution Education. I think it was years ago that I spoke to someone at the head office, and things may have changed. I understand that some of the guys on this Forum (Technical? Hippy?) may be more than "enthusiasts" offering free advice. e.g. they may have access to documentation and/or engineers involved in the PICAXE I2C firmware. Of course, no such luxury may exist - I'm very familiar with advanced products, coming out of China, where the engineer who wrote the firmware is somewhere else by now :) BUT, maybe the right guy is still available ? If so, maybe he has the time to look into this, if I send him my spare HMC6352 Compass Module ?

Robin
www.gpss.co.uk

p.s. I've added a picture under "e. Alternative Designs ..." on my www.gpss.co.uk/rbdesign.htm and I'll try and add it here.
p.p.s picture a bit too big for this Forum, but can go direct to it here: www.gpss.co.uk/hmc6352p.gif
 
Last edited:

hippy

Technical Support
Staff member

Robin Lovelock

Senior Member
Thanks Hippy - and Great News from me - the spare chip works ! Below is a program now being used. Now I hope to make faster progress ! :)

Earlier, I spoke to the supplier, and posted off the first HMC6352 module, snipped off my PICAXE AXE024, with just the 22k pull-up resistors. I then soldered on the spare module, and it worked first time. i.e. different numbers, in the correct range, as I turned the module. I obviously followed up with my friendly distributor, so now all he has to do is see what I screwed up - maybe the default values in eprom, during my early (wrong?) connections. He said he has some picaxe bits, and was even going to spend time trying to get it to work with a picaxe - if the chip was OK. I guess it isn't :)

Now I intend to see how easily I can put in things like SERVO statements, maybe SERIN, and run at different clock rates, needed in the past for the Autopilot. We will see what "jumps out to bite us". At least we are now making progress. Thanks for your advice so far - extremely valuable.

Robin
www.gpss.co.uk/rbdesign.htm

Code:
'COMPASS.BAS test for HMC6352 Compass Module with PICAXE AXE024 Servo Controller
 HI2CSETUP I2CMASTER, $42, I2CSLOW, I2CBYTE
top:
 hi2cout 0, ("A")
 PAUSE 10
 hi2cin 0, (b1, b0) 'w0 should now hold binary Heading 0-3590 tenths of degrees
 w0 = w0 / 10 'degrees
 SERTXD ( "  H=",#w0 ) 'e.g. H=180 for south
 PAUSE 100
 goto top
 

Robin Lovelock

Senior Member
Hi Folks - even better news: no apparent problem in use with SERVO and higher clock rate. My simple APSTEER test program is below. I obviously needed to use the correct I2CSLOW_16 parameter for the setup, but just a few minutes work, and a few lines of code, meant that it could move the rudder servo to steer (towards South). Easy to modify this logic, or exploit what is already in my Autopilot program.

Now I can look to see what options we have of exploiting this compass, towards some first "water trials" on Bray Lake. Probably the next thing to try is to see if we can do a SERIN, to read "rs232" serial data, already coming out of the PICAXE Autopilot, to an optional Text-To-Speech module. i.e. read the Target heading (we need to steer towards) coming out of the Autopilot. Who's a Happy Bunny :)
Robin

Code:
'APSTEER.BAS based on AUTOP2TTS.BAS simple auto pilot for robot boat - with TTS
'v1a 1 August 2013 for testing with rudder servo and I2C Compass Module
'based on COMPASS.BAS test for HMC6352 Compass Module with PICAXE AXE024 Servo Controller
' 
 #picaxe 08M2  
 setfreq M16
 
 symbol CENTRE = 150 'Servo middle position
 symbol THROW = 50
 symbol LEFT = CENTRE + THROW 'Servo left
 symbol RIGHT = CENTRE - THROW 'Servo right
 symbol FOR1SEC = 4000 'pause value at 16MHz for 1 sec
 symbol FOR1P5SEC = 6000 'pause value at 16MHz for 1.5 sec
 symbol FOR2SEC = 8000 'pause value at 16MHz for 2 sec
 symbol FOR3SEC = 12000 'pause value at 16MHz for 3 sec
 symbol FOR4SEC = 16000 'pause value at 16MHz for 4 sec
 symbol FORP5SEC = 2000 'pause value at 16MHz for 0.5 sec
 symbol FORP1SEC = 400 'pause value at 16MHz for 0.1 sec
 symbol FORP2SEC = 800 'pause value at 16MHz for 0.2 sec


 sertxd ( "APSTEER",10,13 ) 'test output back to PC at 19200


 'waggle rudder servo 4 (RHS position) on startup to show that working.
 SERVO 4,CENTRE 'start servo control process - middle
 PAUSE FORP5SEC ' 0.5 sec
 SERVOPOS 4,LEFT 'move servo to position 1
 PAUSE FOR1SEC ' 1 sec
 SERVOPOS 4,CENTRE  'move servo to middle position
 PAUSE FOR1SEC
 SERVOPOS 4,RIGHT  'move servo to position 2
 PAUSE FOR1SEC
 SERVOPOS 4,CENTRE  'move servo to middle position
 PAUSE FOR1SEC
 

 HI2CSETUP I2CMASTER, $42, I2CSLOW_16, I2CBYTE
top:
 hi2cout 0, ("A")
 PAUSE 10
 hi2cin 0, (b1, b0) 'w0 should now hold binary Heading 0-3590 tenths of degrees
 w0 = w0 / 10 'degrees
 SERTXD ( "  H=",#w0 ) 'e.g. H=180 for south
 PAUSE 100
 if w0<175 then SERVOPOS 4,RIGHT endif
 if w0>185 then SERVOPOS 4,LEFT endif
 if w0>=175 and w0<=185 then SERVOPOS 4,CENTRE endif
 goto top
 

Robin Lovelock

Senior Member
Hi Folks ! It didn't take long for something to jump out and bite me :) My best guess is that I've overwritten the factory settings inside eprom of the HMC6352 as a side effect of using other things like SERVO or SEROUT, on pins that might be shared with the I2C system. Hopefully this will be confirmed by my friendly supplier, after he gets that first module in the post tomorrow. We may then see a simple one or two statements, to put the correct settings back into eprom. After those programs that worked above, I tried controlling a servo on a different output socket: maybe that is what done it :) Soon after that, I tried SEROUT, to output text to the Text-To-Speech module, so that I might hear the compass heading spoken, as I walked around outside. Anyway, I soon found that the compass module was not working, and always giving 65535.

The Good News is that we know this HMC6352 can be used with the Picaxe AXE024 - we probably just need to be careful. Hopefully, the HMC6352 is not damaged, and we just need to know what to put into it upon initialisation, and - maybe by experiment - we will discover what works, what doesn't, and what screws it up :)

Robin
www.gpss.co.uk

Code:
'COMPASS.BAS test for HMC6352 Compass Module with PICAXE AXE024 Servo Controller
 HI2CSETUP I2CMASTER, $42, I2CSLOW, I2CBYTE
top:
 hi2cout 0, ("A")
 PAUSE 10
 hi2cin 0, (b1, b0) 'w0 should now hold binary Heading 0-3590 tenths of degrees
 SERTXD ( "  H=",#w0 ) 'now gives 65535 (after Robin overwrote eprom?)
 PAUSE 100
 goto top
 

Armp

Senior Member
My best guess is that I've overwritten the factory settings inside eprom of the HMC6352 as a side effect of using other things like SERVO or SEROUT, on pins that might be shared with the I2C system.
What did you add to the I2C pins? I think we need a schematic. And the code?
 

hippy

Technical Support
Staff member
I soon found that the compass module was not working, and always giving 65535.
You could put your program in a loop which tries each possible I2C device address and reads until it finds a reading which is not 65535.

One question is what battery supply are you using ? The earlier photo is not exactly clear, whether 2 x AA or more than that ?

If you are putting more than 5.2V into the compass you could have burned it out.
 

Robin Lovelock

Senior Member
Thanks Armp and Hippy. To answer Armp first: I think your "What did you add to the I2C pins? I think we need a schematic. And the code?" is answered in the earlier postings, but in brief: the PICAXE-08M2 pins 5 and 6 are wired direct to the HMC6352 SDA and SCL pads, with 10k pull-up resistors to the shared 5v supply.

Thanks Hippy. I might give that a try, but I will also take a look at the datasheet for HMC6352 to see what it says about the default factory settings in eprom. I may be wise to wait until I hear back from the supplier, who should get that first HMC6352 this afternoon. He may confirm what eprom setting has been overwritten - possibly as a side effect of a SERIN or SERVO onto a shared pin*. On subject of voltage supply: absolutely - I was very careful on this: 4 x AA NiMHd Maplin re-chargable batteries - BUT checked to be only 5v before tests started. Since then, dropped to 4.6v - but still plenty enough for PICAXE and Compass Module. *after the APSTEER program (earlier posting) worked with a servo on the RHS slot, I tried the centre servo position (mentioned in earlier posting).

Robin
www.gpss.co.uk/rbdesign.htm

p.s. the HMC6352 data sheet is on https://www.sparkfun.com/datasheets/Components/HMC6352.pdf
I see the possibility that we may only need to use the G command to write the $43 read address back into RAM, or use the command to write into eprom. OR, I wonder if the PICAXE I2C read command might permit explicit reading from $43. I may try a few tests later today.

p.p.s. Hippy - looks like your idea provides more evidence that eprom factory defaults were screwed up earlier. After some time trying other things, this code below shows 6553 being returned from all between $42 and 255 - except for 126 and 127. If I then use the old test program, which did work for a while, with HI2CSETUP I2CMASTER, 126, I2CSLOW, I2CBYTE (or 127) then I get the return of typically 73 or 74 - but not effected by turning the compass. But that might be that other factory setting, used in the chips calculation of heading, were also overwritten. Let's hope I've not done anything irreversible :)

Code:
for w3=$42 to 255
  HI2CSETUP I2CMASTER, w3, I2CSLOW, I2CBYTE
  hi2cout 0, ("A")
  PAUSE 10
  hi2cin 0, (b1, b0) 'w0 should now hold binary Heading 0-3590 tenths of degrees
  w0 = w0 / 10 'degrees
  PAUSE 100
  SERTXD ( "  w0=",#w0,"@",#w3, 10 ) 'e.g. w0=6553@255 but 73@126 and 73@127
next w3
stop
Hi Folks. Some more information, after receiving a call from Roy at Proto-pic - my friendly supplier :) The Compass Module they received works OK, but Roy suggested I remove those 10k resistors, since they should not be needed. He also thought it unlikely that the factory settings like bus address had been screwed up earlier. I've snipped the two 10k pull-up resistors, but my program, which worked before - for a while - still gives the value of 6553. The program is below - which worked yesterday.
Code:
'COMPASS.BAS test for HMC6352 Compass Module with PICAXE AXE024 Servo Controller
 HI2CSETUP I2CMASTER, $42, I2CSLOW, I2CBYTE
top:
 hi2cout 0, ("A")
 PAUSE 10
 hi2cin 0, (b1, b0) 'w0 should now hold binary Heading 0-3590 tenths of degrees
 w0 = w0 / 10 'degrees
 SERTXD ( "  H=",#w0 ) 'e.g. H=180 for south
 PAUSE 100
 goto top
Any ideas ?
 
Last edited:

Armp

Senior Member
but in brief: the PICAXE-08M2 pins 5 and 6 are wired direct to the HMC6352 SDA and SCL pads, with 10k pull-up resistors to the shared 5v supply.
So what did you mean by:
"My best guess is that I've overwritten the factory settings inside eprom of the HMC6352 as a side effect of using other things like SERVO or SEROUT, on pins that might be shared with the I2C system"?
 

Robin Lovelock

Senior Member
I just got a call from Roy at Protopic to say my test program, repeated again below, works OK with the compass chip I sent back. I'm now looking carefully for something like a dry joint on my AXE024 board. Roy kindly suggests, if I cannot find the problem, to send him the very same AXE024 board, so they can do thorough tests there, with the compass module I sent them - that works. For Armp: I edited the earlier post with a *.
Robin

Code:
'COMPASS.BAS test for HMC6352 Compass Module with PICAXE AXE024 Servo Controller
 HI2CSETUP I2CMASTER, $42, I2CSLOW, I2CBYTE
top:
 hi2cout 0, ("A")
 PAUSE 10
 hi2cin 0, (b1, b0) 'w0 should now hold binary Heading 0-3590 tenths of degrees
 w0 = w0 / 10 'degrees
 SERTXD ( "  H=",#w0 ) 'e.g. H=180 for south
 PAUSE 100
 goto top
p.s. AXE024 board inspected, and looks OK. Popped in the post to Roy for tests. New AXE024 board gives same bad result with program above.
 
Last edited:

hippy

Technical Support
Staff member
Any ideas ?
Hard to say. Valid device addresses can be $10 to $F6 but the EEPROM could potentially be set to anything between $00 and $FF, and I don't know how those would behave. It seems unlikely that 'random I/O activity' would interfere with the compass but perhaps not impossible.

With the "HI2CIN 0,(b1,b0)" not matching what the datasheet says should be used but seemingly having worked to some extent it's again hard to tell what is going on. In continuous mode it doesn't seem it is necessary to send the "A" and "HI2COUT, ("A")" doesn't seem to match what would be required either.

It may simply be luck that it worked and now you are out of luck that it no longer does. In trying different code it is possible to create a version which works on download but won't work after a power cycle. It's luck in hitting a sweet spot that seems to have things seeming to work okay even though things aren't quite right.

We are back to needing more analysis and data to work with. Back to what I posted in post #280 -

"My approach would be to connect a byte-address I2C EEPROM and check that works. Write bit-banged code to access the bus and check it works with the EEPROM, then try using the compass with that. Implement exactly as the datasheet says it should be, check what's happening with a logic analyser, and then tweak to make it work".

From that one can determine what the corresponding HI2C-using code should be, and then investigate why that doesn't work if it doesn't.

It's always easier to compare something which does not work against something which does and find what the issue is, compare what is happening against what would be expected to happen, than abstractly try and guess why something is not working.
 

Robin Lovelock

Senior Member
Thanks Hippy: my sentiments exactly, but I'm really glad we got it working, for a short time, including with a servo. If that had not happened, I think I would have given up by now. Hopefully Roy, when he gets the same AXE024 board next week (see p.s. edited in above), will be able to see better what the problem is, and how we can fix it. Meanwhile, I still have the second compass module, connected to another AXE024 Servo Controller, so if anyone has any bright ideas, I may be able to try them.
Have a nice weekend ! :)
Robin
www.gpss.co.uk/rbdesign.htm
 

hippy

Technical Support
Staff member
Having tested the HI2C commands on an 08M2 they seem to be doing exactly as would be expected, and exactly as required by the compass module.

HI2COUT ( <data> )

START | device write adr | ACK | out data | ACK | STOP

HI2CIN ( <msb>, <lsb> )

START | device read adr | ACK | in msb | ACK | in lsb | NAK | STOP

If the compass is in continuous mode (2) then it seems there should be no reason that this would not work -

Code:
#Picaxe 08M2
#Terminal 4800
HI2cSetup I2CMASTER, $42, I2CSLOW, I2CBYTE
Do
  HI2cIn  ( b1, b0 )
  SerTxd( #w0, 9, #b1, " ", #b0, CR, LF )
  Pause 1000
Loop
In Query mode (1) ...

Code:
#Picaxe 08M2
#Terminal 4800
HI2cSetup I2CMASTER, $42, I2CSLOW, I2CBYTE
HI2cOut ( "A" )
Pause 100
Do
  HI2cIn  ( b1, b0 )
  SerTxd( #w0, 9, #b1, " ", #b0, CR, LF )
  Pause 1000
Loop
And in standby mode (0) ...

Code:
#Picaxe 08M2
#Terminal 4800
HI2cSetup I2CMASTER, $42, I2CSLOW, I2CBYTE
Do
  HI2cOut ( "A" )
  Pause 100
  HI2cIn  ( b1, b0 )
  SerTxd( #w0, 9, #b1, " ", #b0, CR, LF )
  Pause 900
Loop
 

Robin Lovelock

Senior Member
Many Thanks Hippy. I pasted each of your above programs in, and ran each. All gave the same output of "65535 255 255".

A little while ago, I got an interesting result, using that address of 126 instead of $42 in the HI2CSETUP. You will remember you suggested looping to see what address gave something different to 65535 and I found smaller values from 126 and 127.

I've seen that if I use 126, the values I get back DO depend on rotation of the compass module. Not a lot - but enough to see something is happening. Values are typically from 730, increasing as I rotate the module, but tilting it also has similar effect. Maybe on of the X,Y, or Z components. I obviously want to exploit their calculation inside the module, of it calculating the compass direction 0 to 359. Here is the modified program below.

Code:
'COMPASS.BAS test for HMC6352 Compass Module with PICAXE AXE024 Servo Controller
 HI2CSETUP I2CMASTER, 160, I2CSLOW, I2CBYTE   '160 instead of $72
top:
 hi2cout 0, ("A")
 PAUSE 10
 hi2cin 0, (b1, b0) 'w0 should now hold binary Heading 0-3590 tenths of degrees
 w0 = w0 - 730   'instead of /10 gives ballpark of 1 to 10 depending on rotation
 SERTXD ( "  H=",#w0 ) 'e.g. H=180 for south (if worked OK)
 PAUSE 100
 goto top
 
Last edited:

Armp

Senior Member
Having tested the HI2C commands on an 08M2 they seem to be doing exactly as would be expected, and exactly as required by the compass module.
Thanks Hippy - that's what I expected.

IMHO it would also indicate that using the location parameter would generate an invalid datastream for the Compass - the OPs hi2cout 0, ("A") and hi2cin 0, (b1, b0) would write 0,"A",0 to the compass before the read, and that's not a valid command.

Maybe the chip's in sleep mode and needs a "W" to wake up....
 

hippy

Technical Support
Staff member
HI2CSETUP I2CMASTER, 160, I2CSLOW, I2CBYTE '160 instead of $72
160 is actually $A0 which is the usual base address for I2C EEPROM.

I think we may just be digging further down into the rabbit hole. Something's going on but it's not possible to tell what. Maybe it's gone into calibration mode or a different output mode.
 

Robin Lovelock

Senior Member
Good idea Armp. I just tried several variations but all with the same "all ones" response. Variations included adding hi2cout 0, ("W") after the setup, and without the preceeding "0," before this and the later hi2cout and h2cin calls. These variations would have been tried yesterday - before we "struck lucky" and it worked - immediately I swapped the compass module for it's spare. Sadly, none of these variations were tried, to see if they also worked, before it stopped working. As I've mentioned before, my best guess so far is that I upset the compass module when I tried a servo in the centre, instead of RHS position, and used SERVO/SERVOPOS on that position. It was either that or the SEROUT that I tried, to send text to the Text-To-Speech module. When these failed to work, I tried that trusted little test program - and that too no longer worked.
Yea Hippy - who has access to ferrets ? :)
p.s. I2C Eprom ? On the Compass Module I guess ? If on the Picaxe chip, that could be very useful for other things.
 
Last edited:

Armp

Senior Member
As I've mentioned before, my best guess so far is that I upset the compass module when I tried a servo in the centre, instead of RHS position, and used SERVO/SERVOPOS on that position.
Doesn't that go to one of the i2c pins? And which pin did you use for SEROUT?
 

Robin Lovelock

Senior Member
Exactly Armp. The two i2c pins connect through 330 ohm resistors to the LHS and Centre servo sockets. That's why I used the RHS socket for that APSTEER.BAS program that also worked yesterday - combining the compass input with rudder servo output. My concern has been that, when I tried the centre servo position, and made the appropriate change to use SERVO and SERVOPOS on that servo, the resulting pulse trains from the picaxe servo firmware MIGHT have upset the Compass Module. e.g. overwritten it's default factory settings. Roy at Proto-pic thinks this very unlikely, and he found that the compass module I was using yesterday, worked OK - including with my picaxe program that had worked here briefly. I cannot recall easily the exact SEROUT I tried, soon after, for TTS, but same principles would apply. It seems likely to me that the problem I had with the first compass module, sent back, is probably the same problem I have now with the second one - but nothing can be completely certain.
Robin
 

premelec

Senior Member
Recently I've seen two articles on GPS spoofing - on land and ocean - PICAXE controlled sextant may be useful yet.... :)
 

srnet

Senior Member
I love this comment on the Scout, it failed after 2 days;

"After cutting a hole near the SCOUT’s engine, they found the culprit of the electrical failure: a fried servo.
It seems like a one-in-a-million kind of failure," said Rodriguez, who is ca student at Worcester Polytechnic Institute."

I dont know which servos they are using, but would have been planning on the basis that servo failure on a journey of that length, was almost inevitable.
 

Robin Lovelock

Senior Member
Hi Folks (old friends) ! Good to hear from you, even if slightly "off topic" :)

Interesting link on Fishpi - very relevant to my friend John of Team-Joker, interested in an electrically powered craft. Of course - but I'll stick to sails.

Fried servo eh ? With all these attempts I'd ask "how many weeks of 24/7 testing, in as realistic conditions as possible ?" For me that tends to be the back garden or Bray Lake, but those near the sea can do better. My little Acoms servos have always run for many months, steering the boat on water, without failure. The only time they have failed, is when water got in.

GPS Spoofing. Now that's an interesting subject, I've been well aware of from my military systems days. I'll be interested what has been said publicly on this subject. i.e. unclassified. For those that need to know: "spoofing" would be electronic measures by which deliberate position errors can be fed in from outside, rather than simply jamming. e.g. in the days when the yanks may have been worried about Saddam siting his scuds or artillery using GPS (so that they could be delivered accurately onto a target) they (allegedly) had the option of jamming GPS locally, without denying it's use for themselves. "Spoofing" would mean making Sadam's GPS think it was some distance from where it really was, so he still fired the stuff - but not onto the right target :) A direct analogy with radar and radar counter-measures.

Sorry that I too, am going off topic - but I'm looking forward to hearing from Roy early this coming week. e.g. if that Picaxe AXE024 that I sent him, works with the Compass Module that I sent back. But if anyone has any bright ideas, I've got another Picaxe-Compass here for tests.

Robin
www.gpss.co.uk/rbdesign.htm

p.s. it's interesting what is now in the Public Domain: http://en.wikipedia.org/wiki/Spoofing_attack
I had thought this a remote possibility, when Snoopy Sloop strayed onto The Needles in November 2012, but - even if anyone did have the capability, outside the military - it would not be worth the hassle. e.g. if there were a coincidental "incident" in the same area, think of the "stink" that could be kicked up. It's always the simplest explanations that are probably true :)
 
Last edited:

Armp

Senior Member
The two i2c pins connect through 330 ohm resistors to the LHS and Centre servo sockets. That's why I used the RHS socket for that APSTEER.BAS program that also worked yesterday - combining the compass input with rudder servo output. My concern has been that, when I tried the centre servo position, and made the appropriate change to use SERVO and SERVOPOS on that servo, the resulting pulse trains from the picaxe servo firmware MIGHT have upset the Compass Module.
No code, no schematic for the failing configuration - sorry can't offer an opinion, but certainly not a good idea.

"It is a capital mistake to theorize before one has data" S. Holmes
 

hippy

Technical Support
Staff member
"It is a capital mistake to theorize before one has data" S. Holmes
It is difficult to theorise when there's a lack of useful data. Such theories become no better than blind stabs in the dark.

I too would say that SERVO, SERVOPOS or SEROUT commands were unlikely to have overwritten any EEPROM settings in the compass. You would need to match the exact sequence required to achieve that, and whilst not impossible, it seems unlikely. But then there's Sod's Law.

We cannot escape the inescapable; that what should work does not, what would not be expected to work does ( in some cases, or to some degree, but not always ) and we have no explanation for either.

It seems rather pointless to me to pursue investigating or even reflecting upon why what wasn't expected to work no longer works, and the wrong issue to focus on when there are more fundamental issues which need resolving.
 

Armp

Senior Member
We cannot escape the inescapable; that what should work does not, what would not be expected to work does ( in some cases, or to some degree, but not always ) and we have no explanation for either.
It seems rather pointless to me to pursue investigating or even reflecting upon why what wasn't expected to work no longer works.
Two absolute gems to add to the collection! Thanks Hippy...
 

Robin Lovelock

Senior Member
Thanks Hippy. I agree, and we will see what Roy uncovers this coming week. I must admit I'm confused by Armp's "No code, no schematic for the failing configuration " which has been provided clearly, and in several ways, earlier in the thread. e.g. code = that simple program above, that worked briefly. e.g. schematic = AXE024 data sheet, and information on how the Compass Module was simply connected. It's interesting that Armp did not follow-up on my suggestion that he contact me directly, telling me a little about himself. I'm sure he is not a 10 year old kid, with little technical experience. My guess is that he is even older, grumpier, and - maybe - as arrogant as myself :)
Robin
www.gpss.co.uk/history.htm
 

Robin Lovelock

Senior Member
Hippy. If I were to purchase and send one of those HMC6352 Compass Module's to you, might you have the time to investigate it connected to an AXE024 board ? If so, I could order another from Proto-pic and have them send it to you, if you provide me with your address. I assume you have access to an AXE024 - preferably the same 3 servo type as I've used - purchased recently. When did the AXE024 last change*, if it has ? If you do have the time, the information above should make it a simple task. i.e. 5 or 10 minutes to solder the 4 wires directly into the AXE024 board. You would obviously need to take care that the supply is no more than about 5v. You could start with those two simple programs above that worked here briefly: COMPASS.BAS and APSTEER.BAS - or change those few statements to what you think should work. It would be good to know that the standard AXE024 will work directly with the HMC6352 - and if it does not, you guys should know why.
Robin
p.s.* I don't think the AXE024 has changed. My confusion was fact that the schematic shows 4 servos and kit seems to be for 3.
p.p.s. I see there WAS a change in the AXE024, comparing kits I've assembled in past years. All worked first time, in the way I've used them, typically taking GPS data from the GPS, driving the rudder servo, and output of text to the optional TTS unit (see www.gpss.co.uk/rbdesign.htm) I see the one I'm using for this compass testing is the latest, with only two instead of three capacitors. This is just "for the record" since I'm sure it has no relevance to our problem.
http://www.sparkfun.com/datasheets/C...ts/HMC6352.pdf - data sheet for HMC6352 Compass Module
http://www.picaxe.com/docs/axe024.pdf - PICAXE AXE024 Servo Controller kit
Looks to me if the AXE024 data sheet above has a photo for the old design, but the schematic for the new ?
Yep - there was a version 2. See http://www.picaxe.com/docs/axe024v2.pdf
 
Last edited:

PADJ

Member
Have you even tried Hippy's suggestions in posts 280,284 and 287, or are you just waiting for someone else to do it for you? This is a great to place to come for help but you have to participate as well.
 

Robin Lovelock

Senior Member
Yes Padj, I think I've tried all the software variations suggested, but I just tried the two alternatives from Technical again:
Code:
 i2cslave $42, i2cslow, i2cbyte
 main:
 pause 100
 i2cread $41,(b1,b0)
 debug w0
 goto main
and
Code:
 i2cslave $42, i2cslow, i2cbyte
 main:
 i2cwrite ($41)
 pause 7
 i2cread (b1,b0)
 debug w0
 pause 100
 goto main
- and both give the usual 255,255 response. I've obviously only been able to do tests with the hardware I have: the AXE024 and HMC6352. I could order more hardware, such as eeprom from Rev'Ed' but it would seem much more sensible to give Hippy an HMC6352.
 

flyingnunrt

Senior Member
Code:
 i2cslave $42, i2cslow, i2cbyte
 main:
 i2cwrite ($41)
 pause 7
 i2cread (b1,b0)
 debug w0
 pause 100
 goto main
I have used code almost identical to this but with an additional 10 pause after the i2cread instruction with a HMC6352 and a 20X2 and it worked fine for me.
 

Robin Lovelock

Senior Member
Many Thanks flyingnunrt. I just tried your code, without then with the extra pause 10, and got the usual 255,255 response.

My guess is that most of these alternatives will work with a fresh HMC6352, if it has not been "upset" by, maybe, sending SERVO pulses to the I2C pins (even though all agree this seems unlikely). I'm hoping that Roy and/or Hippy will be able to repeat my tests above, and will find that my COMPASS.BAS program, and then APSTEER.BAS (they will need a servo for this) work as they did for me. Then running a modified APSTEER.BAS, doing SERVO/SERVOPOS to the "wrong servo" will "upset" the chip. Hopefully, this is reversible, such as re-writing factory defaults into the HMC6352 eprom. If Hippy is given a fresh HMC6352, I'm confident it will work first time. After it has been "upset", I'm sure he will get the same symptoms - of all alternative programs giving 255,255. If I am correct, all we then need to find out, is what extra setup calls to make at the start of the program, to put the HMC6352 into a "fresh" condition. Roy may have done this already, because his first good tests were with a non-picaxe platform (Arduino?) and this may have done the extra set ups. Lots of possible other explanations, including bugs/restrictions in the AXE024 I2C, but I'm sure Hippy will quickly find this out - if he has a HMC6352.

Below are the programs that should work OK, with a fresh HMC6352:

Code:
'COMPASS.BAS test for HMC6352 Compass Module with PICAXE AXE024 Servo Controller
 HI2CSETUP I2CMASTER, $42, I2CSLOW, I2CBYTE
top:
 hi2cout 0, ("A")
 PAUSE 10
 hi2cin 0, (b1, b0) 'w0 should now hold binary Heading 0-3590 tenths of degrees
 w0 = w0 / 10 'degrees
 SERTXD ( "  H=",#w0 ) 'e.g. H=180 for south
 PAUSE 100
 goto top
The following needs a servo plugged into the RHS servo position.
Code:
'APSTEER.BAS based on AUTOP2TTS.BAS simple auto pilot for robot boat - with TTS
'v1a 1 August 2013 for testing with rudder servo and I2C Compass Module
'based on COMPASS.BAS test for HMC6352 Compass Module with PICAXE AXE024 Servo Controller
' 
 #picaxe 08M2  
 setfreq M16
 
 symbol CENTRE = 150 'Servo middle position
 symbol THROW = 50
 symbol LEFT = CENTRE + THROW 'Servo left
 symbol RIGHT = CENTRE - THROW 'Servo right
 symbol FOR1SEC = 4000 'pause value at 16MHz for 1 sec
 symbol FOR1P5SEC = 6000 'pause value at 16MHz for 1.5 sec
 symbol FOR2SEC = 8000 'pause value at 16MHz for 2 sec
 symbol FOR3SEC = 12000 'pause value at 16MHz for 3 sec
 symbol FOR4SEC = 16000 'pause value at 16MHz for 4 sec
 symbol FORP5SEC = 2000 'pause value at 16MHz for 0.5 sec
 symbol FORP1SEC = 400 'pause value at 16MHz for 0.1 sec
 symbol FORP2SEC = 800 'pause value at 16MHz for 0.2 sec


 sertxd ( "APSTEER",10,13 ) 'test output back to PC at 19200


 'waggle rudder servo 4 (RHS position) on startup to show that working.
 SERVO 4,CENTRE 'start servo control process - middle
 PAUSE FORP5SEC ' 0.5 sec
 SERVOPOS 4,LEFT 'move servo to position 1
 PAUSE FOR1SEC ' 1 sec
 SERVOPOS 4,CENTRE  'move servo to middle position
 PAUSE FOR1SEC
 SERVOPOS 4,RIGHT  'move servo to position 2
 PAUSE FOR1SEC
 SERVOPOS 4,CENTRE  'move servo to middle position
 PAUSE FOR1SEC
 
 SEROUT 2, T9600_16, ( "N1",10,"V10",10,"W300", 10 ) 'N1=Deep Male, loud, fast
 SEROUT 2, T9600_16, ( "S I am Snoopy's Steering Picaxe Computer.",10 ) 'test TTS output
 PAUSE FOR4SEC
 

 HI2CSETUP I2CMASTER, $42, I2CSLOW_16, I2CBYTE
top:
 hi2cout 0, ("A")
 PAUSE 10
 hi2cin 0, (b1, b0) 'w0 should now hold binary Heading 0-3590 tenths of degrees
 w0 = w0 / 10 'degrees
 SERTXD ( "  H=",#w0 ) 'e.g. H=180 for south
 PAUSE 100
 SEROUT 2, T9600_16, ( "S ",#w0," degrees.",10 ) 'test TTS output

 if w0<175 then SERVOPOS 4,RIGHT endif
 if w0>185 then SERVOPOS 4,LEFT endif
 if w0>=175 and w0<=185 then SERVOPOS 4,CENTRE endif
 goto top
The following may "screw up" the HMC6352, stopping the above two programs from working. i.e. they return 255,255. (SERVO to 1 instead of 4). For this test, the servo plugs into the centre position on the AXE024, instead of the RHS position.

Code:
'APSTEER.BAS based on AUTOP2TTS.BAS simple auto pilot for robot boat - with TTS
'The following may "screw up" the HMC6352, stopping the above two programs from working. i.e. they return 255,255. (SERVO to 1 instead of 4) 
'based on COMPASS.BAS test for HMC6352 Compass Module with PICAXE AXE024 Servo Controller
' 
 #picaxe 08M2  
 setfreq M16
 
 symbol CENTRE = 150 'Servo middle position
 symbol THROW = 50
 symbol LEFT = CENTRE + THROW 'Servo left
 symbol RIGHT = CENTRE - THROW 'Servo right
 symbol FOR1SEC = 4000 'pause value at 16MHz for 1 sec
 symbol FOR1P5SEC = 6000 'pause value at 16MHz for 1.5 sec
 symbol FOR2SEC = 8000 'pause value at 16MHz for 2 sec
 symbol FOR3SEC = 12000 'pause value at 16MHz for 3 sec
 symbol FOR4SEC = 16000 'pause value at 16MHz for 4 sec
 symbol FORP5SEC = 2000 'pause value at 16MHz for 0.5 sec
 symbol FORP1SEC = 400 'pause value at 16MHz for 0.1 sec
 symbol FORP2SEC = 800 'pause value at 16MHz for 0.2 sec


 sertxd ( "APSTEER",10,13 ) 'test output back to PC at 19200


 'waggle rudder servo 4 (RHS position) on startup to show that working.
 SERVO 1,CENTRE 'start servo control process - middle
 PAUSE FORP5SEC ' 0.5 sec
 SERVOPOS 1,LEFT 'move servo to position 1
 PAUSE FOR1SEC ' 1 sec
 SERVOPOS 1,CENTRE  'move servo to middle position
 PAUSE FOR1SEC
 SERVOPOS 1,RIGHT  'move servo to position 2
 PAUSE FOR1SEC
 SERVOPOS 1,CENTRE  'move servo to middle position
 PAUSE FOR1SEC
 
 SEROUT 2, T9600_16, ( "N1",10,"V10",10,"W300", 10 ) 'N1=Deep Male, loud, fast
 SEROUT 2, T9600_16, ( "S I am Snoopy's Steering Picaxe Computer.",10 ) 'test TTS output
 PAUSE FOR4SEC
 

 HI2CSETUP I2CMASTER, $42, I2CSLOW_16, I2CBYTE
top:
 hi2cout 0, ("A")
 PAUSE 10
 hi2cin 0, (b1, b0) 'w0 should now hold binary Heading 0-3590 tenths of degrees
 w0 = w0 / 10 'degrees
 SERTXD ( "  H=",#w0 ) 'e.g. H=180 for south
 PAUSE 100
 SEROUT 2, T9600_16, ( "S ",#w0," degrees.",10 ) 'test TTS output

 if w0<175 then SERVOPOS 1,RIGHT endif
 if w0>185 then SERVOPOS 1,LEFT endif
 if w0>=175 and w0<=185 then SERVOPOS 1,CENTRE endif
 goto top
Robin
www.gpss.co.uk
www.gpss.co.uk/autop.htm - robot boat "front page" with latest news, etc. Amusing videos :)
www.gpss.co.uk/rbdesign.htm - what serves as a "design" page, including the picaxe based autopilot
www.sparkfun.com/datasheets/C...ts/HMC6352.pdf - data sheet for HMC6352 Compass Module
www.picaxe.com/docs/axe024.pdf - PICAXE AXE024 Servo Controller kit (v1)
www.picaxe.com/docs/axe024v2.pdf - PICAXE AXE024 Servo Controller kit (v2) - as used in tests above.
www.gpss.co.uk/phmc6352.gif - link to picture showing wiring of HMC6352 to AXE024 v2 (or v1).

p.s. for those that have difficulty understanding what the purpose of this work is:
a) to confirm that a PICAXE AXE024 can be used with a HMC6352 Compass (and how?). Probably yes (COMPASS.BAS)
b) to identify complete setup process needed for HMC6352. e.g. restoration of HMC6352 factory defaults if needed. ???
c) to determine what pins can be used for things like Rudder Servo (Prob. yes), serial I/O, analogue input.
d) to identify design limitations and side-effects (analogous to those existing with SERIN and SERVO solutions)
- to help identify design options for including compass in Autopilot. e.g. one AXE024 or more.
APSTEER.BAS indicates AXE024 can reliably combine compass reading and rudder servo output.
It seems that SERVO or SEROUT to the I2C pins can upset the HMC6352. More information needed.

Sorry that I will not respond to all postings in this thread, but anyone is welcome to contact me directly via my robin@gpss.co.uk or contact page www.gpss.co.uk/contact.htm
 
Last edited:

PADJ

Member
I've obviously only been able to do tests with the hardware I have: the AXE024 and HMC6352. I could order more hardware, such as eeprom from Rev'Ed' but it would seem much more sensible to give Hippy an HMC6352.
More sensible??? I'm not sure you're in the right forum.
Go spend a couple of bucks on a small eeprom. wire it on a breadbord, and see if it works.
If it doesn't post your code, schematic and a clear photo and maybe learn something. Sheesh

So Roy confirmed the module you returned was good, and flyingnunrt says his code is good, but you can't make it work. Looks like your hardware to me.
 
Last edited:
Top